Greg Banks [Thu, 26 Mar 2009 15:32:47 +0000 (02:32 +1100)]
Fix a build warning about leaking CONFIG_NFSD to userspace.
Fix a build warning about leaking CONFIG_NFSD to userspace.
The nfsd_stats data structure does not need to be available to
userspace; no kernel interface uses it. So move it inside #ifdef
__KERNEL__ and the warning goes away.
Signed-off-by: Greg Banks <gnb@sgi.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
ideawu [Thu, 26 Mar 2009 04:55:29 +0000 (12:55 +0800)]
sunrpc/svc.c: Remove unused line 'rqstp->rq_server = serv;' in svc_process
There is no need to set rqstp->rq_server to serv, while serv is initialized as rqstp->rq_server at previous line. And between these two lines, there is no change to rqstp->rq_server.
Signed-off-by: ideawu <ideawu@163.com> Reviewed-by: Tom Tucker <tom@opengridcomputing.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Sachin S. Prabhu [Mon, 23 Feb 2009 16:22:03 +0000 (16:22 +0000)]
Inconsistent setattr behaviour
There is an inconsistency seen in the behaviour of nfs compared to other local
filesystems on linux when changing owner or group of a directory. If the
directory has SUID/SGID flags set, on changing owner or group on the directory,
the flags are stripped off on nfs. These flags are maintained on other
filesystems such as ext3.
To reproduce on a nfs share or local filesystem, run the following commands
mkdir test; chmod +s+g test; chown user1 test; ls -ld test
On the nfs share, the flags are stripped and the output seen is
drwxr-xr-x 2 user1 root 4096 Feb 23 2009 test
On other local filesystems(ex: ext3), the flags are not stripped and the output
seen is
drwsr-sr-x 2 user1 root 4096 Feb 23 13:57 test
chown_common() called from sys_chown() will only strip the flags if the inode is
not a directory.
static int chown_common(struct dentry * dentry, uid_t user, gid_t group)
{
..
if (!S_ISDIR(inode->i_mode))
newattrs.ia_valid |=
ATTR_KILL_SUID | ATTR_KILL_SGID | ATTR_KILL_PRIV;
..
}
"If the path argument refers to a regular file, the set-user-ID (S_ISUID) and
set-group-ID (S_ISGID) bits of the file mode are cleared upon successful return
from chown(), unless the call is made by a process with appropriate privileges,
in which case it is implementation-dependent whether these bits are altered. If
chown() is successfully invoked on a file that is not a regular file, these
bits may be cleared. These bits are defined in <sys/stat.h>."
The behaviour as it stands does not appear to violate POSIX. However the
actions performed are inconsistent when comparing ext3 and nfs.
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Allow the NFSv4 server to make use of TCP autotuning behaviour, which
was previously disabled by setting the sk_userlocks variable.
Set the receive buffers to be big enough to receive the whole RPC
request, and set this for the listening socket, not the accept socket.
Remove the code that readjusts the receive/send buffer sizes for the
accepted socket. Previously this code was used to influence the TCP
window management behaviour, which is no longer needed when autotuning
is enabled.
This can improve IO bandwidth on networks with high bandwidth-delay
products, where a large tcp window is required. It also simplifies
performance tuning, since getting adequate tcp buffers previously
required increasing the number of nfsd threads.
Signed-off-by: Olga Kornievskaia <aglo@citi.umich.edu> Cc: Jim Rees <rees@umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
J. Bruce Fields [Wed, 18 Mar 2009 19:06:26 +0000 (15:06 -0400)]
nfsd4: don't check ip address in setclientid
The spec allows clients to change ip address, so we shouldn't be
requiring that setclientid always come from the same address. For
example, a client could reboot and get a new dhcpd address, but still
present the same clientid to the server. In that case the server should
revoke the client's previous state and allow it to continue, instead of
(as it currently does) returning a CLID_INUSE error.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Greg Banks [Tue, 13 Jan 2009 10:26:36 +0000 (21:26 +1100)]
knfsd: add file to export stats about nfsd pools
Add /proc/fs/nfsd/pool_stats to export to userspace various
statistics about the operation of rpc server thread pools.
This patch is based on a forward-ported version of
knfsd-add-pool-thread-stats which has been shipping in the SGI
"Enhanced NFS" product since 2006 and which was previously
posted:
http://article.gmane.org/gmane.linux.nfs/10375
It has also been updated thus:
* moved EXPORT_SYMBOL() to near the function it exports
* made the new struct struct seq_operations const
* used SEQ_START_TOKEN instead of ((void *)1)
* merged fix from SGI PV 990526 "sunrpc: use dprintk instead of
printk in svc_pool_stats_*()" by Harshula Jayasuriya.
* merged fix from SGI PV 964001 "Crash reading pool_stats before
nfsds are started".
Signed-off-by: Greg Banks <gnb@sgi.com> Signed-off-by: Harshula Jayasuriya <harshula@sgi.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Greg Banks [Tue, 13 Jan 2009 10:26:35 +0000 (21:26 +1100)]
knfsd: avoid overloading the CPU scheduler with enormous load averages
Avoid overloading the CPU scheduler with enormous load averages
when handling high call-rate NFS loads. When the knfsd bottom half
is made aware of an incoming call by the socket layer, it tries to
choose an nfsd thread and wake it up. As long as there are idle
threads, one will be woken up.
If there are lot of nfsd threads (a sensible configuration when
the server is disk-bound or is running an HSM), there will be many
more nfsd threads than CPUs to run them. Under a high call-rate
low service-time workload, the result is that almost every nfsd is
runnable, but only a handful are actually able to run. This situation
causes two significant problems:
1. The CPU scheduler takes over 10% of each CPU, which is robbing
the nfsd threads of valuable CPU time.
2. At a high enough load, the nfsd threads starve userspace threads
of CPU time, to the point where daemons like portmap and rpc.mountd
do not schedule for tens of seconds at a time. Clients attempting
to mount an NFS filesystem timeout at the very first step (opening
a TCP connection to portmap) because portmap cannot wake up from
select() and call accept() in time.
Disclaimer: these effects were observed on a SLES9 kernel, modern
kernels' schedulers may behave more gracefully.
The solution is simple: keep in each svc_pool a counter of the number
of threads which have been woken but have not yet run, and do not wake
any more if that count reaches an arbitrary small threshold.
Testing was on a 4 CPU 4 NIC Altix using 4 IRIX clients, each with 16
synthetic client threads simulating an rsync (i.e. recursive directory
listing) workload reading from an i386 RH9 install image (161480
regular files in 10841 directories) on the server. That tree is small
enough to fill in the server's RAM so no disk traffic was involved.
This setup gives a sustained call rate in excess of 60000 calls/sec
before being CPU-bound on the server. The server was running 128 nfsds.
Profiling showed schedule() taking 6.7% of every CPU, and __wake_up()
taking 5.2%. This patch drops those contributions to 3.0% and 2.2%.
Load average was over 120 before the patch, and 20.9 after.
This patch is a forward-ported version of knfsd-avoid-nfsd-overload
which has been shipping in the SGI "Enhanced NFS" product since 2006.
It has been posted before:
http://article.gmane.org/gmane.linux.nfs/10374
Signed-off-by: Greg Banks <gnb@sgi.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Greg Banks [Tue, 13 Jan 2009 10:26:34 +0000 (21:26 +1100)]
knfsd: remove the nfsd thread busy histogram
Stop gathering the data that feeds the 'th' line in /proc/net/rpc/nfsd
because the questionable data provided is not worth the scalability
impact of calculating it. Instead, always report zeroes. The current
approach suffers from three major issues:
1. update_thread_usage() increments buckets by call service
time or call arrival time...in jiffies. On lightly loaded
machines, call service times are usually < 1 jiffy; on
heavily loaded machines call arrival times will be << 1 jiffy.
So a large portion of the updates to the buckets are rounded
down to zero, and the histogram is undercounting.
2. As seen previously on the nfs mailing list, the format in which
the histogram is presented is cryptic, difficult to explain,
and difficult to use.
3. Updating the histogram requires taking a global spinlock and
dirtying the global variables nfsd_last_call, nfsd_busy, and
nfsdstats *twice* on every RPC call, which is a significant
scaling limitation.
Testing on a 4 CPU 4 NIC Altix using 4 IRIX clients each doing
1K streaming reads at full line rate, shows the stats update code
(inlined into nfsd()) takes about 1.7% of each CPU. This patch drops
the contribution from nfsd() into the profile noise.
This patch is a forward-ported version of knfsd-remove-nfsd-threadstats
which has been shipping in the SGI "Enhanced NFS" product since 2006.
In that time, exactly one customer has noticed that the threadstats
were missing. It has been previously posted:
http://article.gmane.org/gmane.linux.nfs/10376
and more recently requested to be posted again.
Signed-off-by: Greg Banks <gnb@sgi.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
J. Bruce Fields [Fri, 13 Mar 2009 20:02:59 +0000 (16:02 -0400)]
nfsd4: don't do lookup within readdir in recovery code
The main nfsd code was recently modified to no longer do lookups from
withing the readdir callback, to avoid locking problems on certain
filesystems.
This (rather hacky, and overdue for replacement) NFSv4 recovery code has
the same problem. Fix it to build up a list of names (instead of
dentries) and do the lookups afterwards.
Reported symptoms were a deadlock in the xfs code (called from
nfsd4_recdir_load), with /var/lib/nfs on xfs.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Reported-by: David Warren <warren@atmos.washington.edu>
J. Bruce Fields [Mon, 9 Mar 2009 16:17:29 +0000 (12:17 -0400)]
nfsd4: support putpubfh operation
Currently putpubfh returns NFSERR_OPNOTSUPP, which isn't actually
allowed for v4. The right error is probably NFSERR_NOTSUPP.
But let's just implement it; though rarely seen, it can be used by
Solaris (with a special mount option), is mandated by the rfc, and is
trivial for us to support.
Thanks to Yang Hongyang for pointing out the original problem, and to
Mike Eisler, Tom Talpey, Trond Myklebust, and Dave Noveck for further
argument....
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
David Shaw [Fri, 6 Mar 2009 01:16:14 +0000 (20:16 -0500)]
Short write in nfsd becomes a full write to the client
If a filesystem being written to via NFS returns a short write count
(as opposed to an error) to nfsd, nfsd treats that as a success for
the entire write, rather than the short count that actually succeeded.
For example, given a 8192 byte write, if the underlying filesystem
only writes 4096 bytes, nfsd will ack back to the nfs client that all
8192 bytes were written. The nfs client does have retry logic for
short writes, but this is never called as the client is told the
complete write succeeded.
There are probably other ways it could happen, but in my case it
happened with a fuse (filesystem in userspace) filesystem which can
rather easily have a partial write.
Here is a patch to properly return the short write count to the
client.
Signed-off-by: David Shaw <dshaw@jabberwocky.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
J. Bruce Fields [Sun, 22 Feb 2009 22:51:34 +0000 (14:51 -0800)]
nfsd4: remove use of mutex for file_hashtable
As part of reducing the scope of the client_mutex, and in order to
remove the need for mutexes from the callback code (so that callbacks
can be done as asynchronous rpc calls), move manipulations of the
file_hashtable under the recall_lock.
Update the relevant comments while we're here.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Cc: Alexandros Batsakis <batsakis@netapp.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com>
J. Bruce Fields [Sat, 21 Feb 2009 23:39:54 +0000 (15:39 -0800)]
nfsd4: put_nfs4_client does not require state lock
Since free_client() is guaranteed to only be called once, and to only
touch the client structure itself (not any common data structures), it
has no need for the state lock.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Cc: Alexandros Batsakis <batsakis@netapp.com>
J. Bruce Fields [Sat, 21 Feb 2009 21:32:28 +0000 (13:32 -0800)]
nfsd4: fail when delegreturn gets a non-delegation stateid
Previous cleanup reveals an obvious (though harmless) bug: when
delegreturn gets a stateid that isn't for a delegation, it should return
an error rather than doing nothing.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
J. Bruce Fields [Sat, 21 Feb 2009 20:13:24 +0000 (12:13 -0800)]
nfsd4: remove some dprintk's
I can't recall ever seeing these printk's used to debug a problem. I'll
happily put them back if we see a case where they'd be useful. (Though
if we do that the find_XXX() errors would probably be better
reported in find_XXX() functions themselves.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
J. Bruce Fields [Sat, 21 Feb 2009 19:14:43 +0000 (11:14 -0800)]
nfsd4: remove redundant "if" in nfs4_preprocess_stateid_op
Note that we exit this first big "if" with stp == NULL if and only if we
took the first branch; therefore, the second "if" is redundant, and we
can just combine the two, simplifying the logic.
Reviewed-by: Yang Hongyang <yanghy@cn.fujitsu.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Harvey Harrison [Thu, 12 Feb 2009 01:16:58 +0000 (17:16 -0800)]
nfs: replace uses of __constant_{endian}
The base versions handle constant folding now, none of these headers
are exported to userspace, so the __ prefixed versions are not
necessary.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Reviewed-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
wengang wang [Tue, 10 Feb 2009 03:27:51 +0000 (11:27 +0800)]
nfsd(v2/v3): fix the failure of creation from HPUX client
sometimes HPUX nfs client sends a create request to linux nfs server(v2/v3).
the dump of the request is like:
obj_attributes
mode: value follows
set_it: value follows (1)
mode: 00
uid: no value
set_it: no value (0)
gid: value follows
set_it: value follows (1)
gid: 8030
size: value follows
set_it: value follows (1)
size: 0
atime: don't change
set_it: don't change (0)
mtime: don't change
set_it: don't change (0)
note that mode is 00(havs no rwx privilege even for the owner) and it requires
to set size to 0.
as current nfsd(v2/v3) implementation, the server does mainly 2 steps:
1) creates the file in mode specified by calling vfs_create().
2) sets attributes for the file by calling nfsd_setattr().
at step 2), it finally calls file system specific setattr() function which may
fail when checking permission because changing size needs WRITE privilege but
it has none since mode is 000.
for this case, a new file created, we may simply ignore the request of
setting size to 0, so that WRITE privilege is not needed and the open
succeeds.
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
--
vfs.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+) Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
nfsd: lock state around put client and delegation in nfsd4_cb_recall
not having the state locked before putting the client/delegation causes a bug.
Also removed the comment from the function header about the state being already locked
Signed-off-by: Alexandros Batsakis <batsakis@netapp.com> Signed-off-by: Benny Halevy <bhalevy@panasas.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
J. Bruce Fields [Sun, 11 Jan 2009 20:24:04 +0000 (15:24 -0500)]
nfsd4: split open/lockowner release code
The caller always knows specifically whether it's releasing a lockowner
or an openowner, and the code is simpler if we use separate functions
(and the apparent recursion is gone).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The flags here attempt to make the code more general, but I find it
actually just adds confusion.
I think it's clearer to separate the logic for the open and lock cases
entirely. And eventually we may want to separate the stateowner and
stateid types as well, as many of the fields aren't shared between the
lock and open cases.
Also move to eliminate forward references.
Start with the stateid's.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Reviewed-by: Benny Halevy <bhalevy@panasas.com>
Linus Torvalds [Wed, 18 Mar 2009 14:39:11 +0000 (07:39 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: Fix vunmap and free order in snd_free_sgbuf_pages()
ALSA: mixart, fix lock imbalance
ALSA: pcm_oss, fix locking typo
ALSA: oss-mixer - Fixes recording gain control
ALSA: hda - Workaround for buggy DMA position on ATI controllers
ALSA: hda - Fix DMA mask for ATI controllers
ALSA: opl3sa2 - Fix NULL dereference when suspending snd_opl3sa2
Takashi Iwai [Tue, 17 Mar 2009 13:00:06 +0000 (14:00 +0100)]
ALSA: Fix vunmap and free order in snd_free_sgbuf_pages()
In snd_free_sgbuf_pags(), vunmap() is called after releasing the SG
pages, and it causes errors on Xen as Xen manages the pages
differently. Although no significant errors have been reported on
the actual hardware, this order should be fixed other way round,
first vunmap() then free pages.
Cc: Jan Beulich <jbeulich@novell.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Viral Mehta [Tue, 10 Mar 2009 14:43:18 +0000 (15:43 +0100)]
ALSA: oss-mixer - Fixes recording gain control
At the time of initialization, SNDRV_MIXER_OSS_PRESENT_PVOLUME bit is not
set for MIC (slot 7).
So, the same should not be checked when an application tries to do gain
control for audio recording devices.
Just check slot->present for SNDRV_MIXER_OSS_PRESENT_CVOLUME independently.
Verified with a simple application which opens /dev/dsp for recording and
/dev/mixer for volume control.
Takashi Iwai [Tue, 17 Mar 2009 06:49:14 +0000 (07:49 +0100)]
ALSA: hda - Workaround for buggy DMA position on ATI controllers
The position-buffer on ATI controllers are unreliable as well as
on VIA chips, thus the same workaround for DMA position reading as
VIA is useful for ATI.
Takashi Iwai [Tue, 17 Mar 2009 06:47:18 +0000 (07:47 +0100)]
ALSA: hda - Fix DMA mask for ATI controllers
ATI controllers (at least some SB0600 models) appear buggy to handle
64bit DMA. As a workaround, reset GCAP bit0 and let the driver to
use only 32bit DMA on these controllers.
Linus Torvalds [Wed, 18 Mar 2009 03:55:40 +0000 (20:55 -0700)]
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: fix bb_prealloc_list corruption due to wrong group locking
ext4: fix bogus BUG_ONs in in mballoc code
ext4: Print the find_group_flex() warning only once
ext4: fix header check in ext4_ext_search_right() for deep extent trees.
Masami Hiramatsu [Mon, 16 Mar 2009 22:13:36 +0000 (18:13 -0400)]
module: fix refptr allocation and release order
Impact: fix ref-after-free crash on failed module load
Fix refptr bug: Change refptr allocation and release order not to access a module
data structure pointed by 'mod' after freeing mod->module_core.
This bug will cause kernel panic(e.g. failed to find undefined symbols).
This bug was reported on systemtap bugzilla.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=9927
Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com> Cc: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Thomas Bartosik [Mon, 16 Mar 2009 15:04:38 +0000 (16:04 +0100)]
USB: storage: Unusual USB device Prolific 2507 variation added
The "c-enter" USB to Toshiba 1.8" IDE enclosure needs special treatment
to work flawlessly. This patch is absolutely trivial, as the integrated
USB-IDE bridge is already identified to be an "unusual" device, only the
bcdDevice is different (lower) to the bcdDeviceMin already included in
the kernel.
It is a Prolific 2507 bridge.
Dirk Hohndel [Sun, 15 Mar 2009 03:47:39 +0000 (20:47 -0700)]
USB: Add Vendor/Product ID for new CDMA U727 to option driver
* newer versions of the Novatel Wireless U727 CDMA 3G USB stick
have a different Product ID (0x5010); adding this ID makes them
work just fine with the option driver
Signed-off-by: Moritz Muehlenhoff <jmm@debian.org> Tested-by: Jan Heitkoetter <devnull@heitkoetter.net> Cc: stable <stable@kernel.org> Signed-off-by: Phil Dibowitz <phil@ipom.com>
Dan Williams [Thu, 12 Mar 2009 10:53:00 +0000 (06:53 -0400)]
USB: Option: let cdc-acm handle Sony Ericsson F3507g / Dell 5530
The generic cdc-acm driver is now the best one to handle Sony Ericsson
F3507g-based devices (which the Dell 5530 is a rebrand of), now that all
the pieces are in place (ie, cac477e8f1038c41b6f29d3161ce351462ef3df7).
Removing the IDs from option allows cdc-acm to handle the device.
Signed-off-by: Dan Williams <dcbw@redhat.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Mon, 16 Mar 2009 18:21:56 +0000 (14:21 -0400)]
USB: EHCI: expedite unlinks when the root hub is suspended
This patch (as1225) fixes a bug in ehci-hcd. The condition for
whether unlinked QHs can become IDLE should not be that the controller
is halted, but rather that the controller isn't running. In other
words when the root hub is suspended, the hardware doesn't own any
QHs.
This fixes a problem that can show up during hibernation: If a QH is
only partially unlinked when the root hub is frozen, then when the
root hub is thawed the QH won't be in the IDLE state. As a result it
can't be used properly for new URB submissions.
Karsten Wiese [Thu, 26 Feb 2009 00:47:48 +0000 (01:47 +0100)]
USB: EHCI: Fix isochronous URB leak
ehci-hcd uses usb_get_urb() and usb_put_urb() in an unbalanced way causing
isochronous URB's kref.counts incrementing once per usb_submit_urb() call.
The culprit is *usb being set to NULL when usb_put_urb() is called after URB
is given back.
Due to other fixes there is no need for ehci-hcd to deal with usb_get_urb()
nor usb_put_urb() anymore, so patch removes their usages in ehci-hcd.
Patch also makes ehci_to_hcd(ehci)->self.bandwidth_allocated adjust, if a
stream finishes.
Jan Dumon [Tue, 10 Mar 2009 16:29:47 +0000 (17:29 +0100)]
USB: unusual_devs: Add support for GI 0431 SD-Card interface
Enable the SD-Card interface on the GI 0431 HSUPA stick from Option.
The unusual_devs.h entry is necessary because the device descriptor is
vendor-specific. That prevents usb-storage from binding to it as an
interface driver.
Alan Stern [Mon, 9 Mar 2009 17:44:02 +0000 (13:44 -0400)]
USB: usbfs: keep async URBs until the device file is closed
The usbfs driver manages a list of completed asynchronous URBs. But
it is too eager to free the entries on this list: destroy_async() gets
called whenever an interface is unbound or a device is removed, and it
deallocates the outstanding struct async entries for all URBs on that
interface or device. This is wrong; the user program should be able
to reap an URB any time after it has completed, regardless of whether
or not the interface is still bound or the device is still present.
This patch (as1222) moves the code for deallocating the completed list
entries from destroy_async() to usbdev_release(). The outstanding
entries won't be freed until the user program has closed the device
file, thereby eliminating any possibility that the remaining URBs
might still be reaped.
This fixes a bug in which a program can hang in the USBDEVFS_REAPURB
ioctl when the device is unplugged.
Reported-and-tested-by: Martin Poupe <martin.poupe@upek.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
J. Bruce Fields [Mon, 16 Mar 2009 22:34:20 +0000 (18:34 -0400)]
nfsd: nfsd should drop CAP_MKNOD for non-root
Since creating a device node is normally an operation requiring special
privilege, Igor Zhbanov points out that it is surprising (to say the
least) that a client can, for example, create a device node on a
filesystem exported with root_squash.
So, make sure CAP_MKNOD is among the capabilities dropped when an nfsd
thread handles a request from a non-root user.
Reported-by: Igor Zhbanov <izh1979@gmail.com> Cc: stable@kernel.org Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Benny Halevy [Wed, 4 Mar 2009 21:05:35 +0000 (23:05 +0200)]
NFSD: provide encode routine for OP_OPENATTR
Although this operation is unsupported by our implementation
we still need to provide an encode routine for it to
merely encode its (error) status back in the compound reply.
Thanks for Bill Baker at sun.com for testing with the Sun
OpenSolaris' client, finding, and reporting this bug at
Connectathon 2009.
This bug was introduced in 2.6.27
Signed-off-by: Benny Halevy <bhalevy@panasas.com> Cc: stable@kernel.org Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Linus Torvalds [Tue, 17 Mar 2009 17:02:35 +0000 (10:02 -0700)]
Avoid 64-bit "switch()" statements on 32-bit architectures
Commit ee6f779b9e0851e2f7da292a9f58e0095edf615a ("filp->f_pos not
correctly updated in proc_task_readdir") changed the proc code to use
filp->f_pos directly, rather than through a temporary variable. In the
process, that caused the operations to be done on the full 64 bits, even
though the offset is never that big.
That's all fine and dandy per se, but for some unfathomable reason gcc
generates absolutely horrid code when using 64-bit values in switch()
statements. To the point of actually calling out to gcc helper
functions like __cmpdi2 rather than just doing the trivial comparisons
directly the way gcc does for normal compares. At which point we get
link failures, because we really don't want to support that kind of
crazy code.
Fix this by just casting the f_pos value to "unsigned long", which
is plenty big enough for /proc, and avoids the gcc code generation issue.
Masami Hiramatsu [Mon, 16 Mar 2009 22:57:22 +0000 (18:57 -0400)]
prevent boosting kprobes on exception address
Don't boost at the addresses which are listed on exception tables,
because major page fault will occur on those addresses. In that case,
kprobes can not ensure that when instruction buffer can be freed since
some processes will sleep on the buffer.
Kumar Gala [Tue, 17 Mar 2009 15:17:50 +0000 (09:17 -0600)]
powerpc/mm: Respect _PAGE_COHERENT on classic ppc32 SW
Since we now set _PAGE_COHERENT in the Linux PTE we shouldn't be clearing
it out before we setup the SW TLB. Today all the SW TLB machines
(603/e300) that we support are non-SMP, however there are some errata on
some devices that cause us to set _PAGE_COHERENT via CPU_FTR_NEED_COHERENT.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Piotr Ziecik [Tue, 17 Mar 2009 15:17:50 +0000 (09:17 -0600)]
powerpc/5200: Enable CPU_FTR_NEED_COHERENT for MPC52xx
BestComm, a DMA engine in MPC52xx SoC, requires snooping when
CPU caches are enabled to work properly.
Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup
code' (sha1: 4c456a67f501b8b15542c7c21c28812bf88f484b).
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Linus Torvalds [Tue, 17 Mar 2009 15:13:17 +0000 (08:13 -0700)]
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc> Cc: john stultz <johnstul@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Tue, 17 Mar 2009 14:58:26 +0000 (07:58 -0700)]
Fix potential fast PIT TSC calibration startup glitch
During bootup, when we reprogram the PIT (programmable interval timer)
to start counting down from 0xffff in order to use it for the fast TSC
calibration, we should also make sure to delay a bit afterwards to allow
the PIT hardware to actually start counting with the new value.
That will happens at the next CLK pulse (1.193182 MHz), so the easiest
way to do that is to just wait at least one microsecond after
programming the new PIT counter value. We do that by just reading the
counter value back once - which will take about 2us on PC hardware.
Reported-and-tested-by: john stultz <johnstul@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
so it's critical that we get the right group number back for
this prealloc context, to lock the right group (the one
associated with this pa) and prevent concurrent list manipulation.
however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a
comment, "-1 is to protect from crossing allocation group".
This makes sense for the group_pa, where pa_pstart is advanced
by the length which has been used (in ext4_mb_release_context()),
and when the entire length has been used, pa_pstart has been
advanced to the first block of the next group.
However, for inode_pa, pa_pstart is never advanced; it's just
set once to the first block in the group and not moved after
that. So in this case, if we subtract one in ext4_mb_put_pa(),
we are actually locking the *previous* group, and opening the
race with the other threads which do not subtract off the extra
block.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Linus Torvalds [Mon, 16 Mar 2009 19:49:12 +0000 (12:49 -0700)]
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
acpi-wmi: unsigned cannot be less than 0
thinkpad-acpi: fix module autoloading for older models
acer-wmi: Unmark as 'experimental'
acpi-wmi: Unmark as 'experimental'
acer-wmi: double free in acer_rfkill_exit()
platform/x86: depends instead of select for laptop platform drivers
asus-laptop: use select instead of depends on
eeepc-laptop: restore acpi_generate_proc_event()
asus-laptop: restore acpi_generate_proc_event()
acpi: check for pxm_to_node_map overflow
ACPI: remove doubled status checking
ACPI suspend: Blacklist Toshiba Satellite L300 that requires to set SCI_EN directly on resume
Revert "ACPI: make some IO ports off-limits to AML"
suspend: switch the Asus Pundit P1-AH2 to old ACPI sleep ordering
When a table is being replaced, it waits for I/O to complete
before destroying the mempool, but the endio function doesn't
call mempool_free() until after completing the bio.
Fix it by swapping the order of those two operations.
The same problem occurs in dm.c with md referenced after dec_pending.
Again, we swap the order.
Cc: stable@kernel.org Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Huang Ying [Mon, 16 Mar 2009 17:44:33 +0000 (17:44 +0000)]
dm crypt: fix kcryptd_async_done parameter
In the async encryption-complete function (kcryptd_async_done), the
crypto_async_request passed in may be different from the one passed to
crypto_ablkcipher_encrypt/decrypt. Only crypto_async_request->data is
guaranteed to be same as the one passed in. The current
kcryptd_async_done uses the passed-in crypto_async_request directly
which may cause the AES-NI-based AES algorithm implementation to panic.
This patch fixes this bug by only using crypto_async_request->data,
which points to dm_crypt_request, the crypto_async_request passed in.
The original data (convert_context) is gotten from dm_crypt_request.
[mbroz@redhat.com: reworked] Cc: stable@kernel.org Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Mikulas Patocka [Mon, 16 Mar 2009 17:44:30 +0000 (17:44 +0000)]
dm io: respect BIO_MAX_PAGES limit
dm-io calls bio_get_nr_vecs to get the maximum number of pages to use
for a given device. It allocates one additional bio_vec to use
internally but failed to respect BIO_MAX_PAGES, so fix this.
This was the likely cause of:
https://bugzilla.redhat.com/show_bug.cgi?id=173153
Milan Broz [Mon, 16 Mar 2009 16:56:01 +0000 (16:56 +0000)]
dm ioctl: validate name length when renaming
When renaming a mapped device validate the length of the new name.
The rename ioctl accepted any correctly-terminated string enclosed
within the data passed from userspace. The other ioctls enforce a
size limit of DM_NAME_LEN. If the name is changed and becomes longer
than that, the device can no longer be addressed by name.
Fix it by properly checking for device name length (including
terminating zero).
Cc: stable@kernel.org Signed-off-by: Milan Broz <mbroz@redhat.com> Reviewed-by: Jonathan Brassow <jbrassow@redhat.com> Reviewed-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Rusty Russell [Sun, 15 Mar 2009 22:35:07 +0000 (09:05 +1030)]
linux.conf.au 2009: Tuz
Impact: help prevent extinction of species
The Tasmanian Devil is a shy iconic Australian creature named for its
spine-chilling screech. It is threatened with extinction due to a
scientifically interesting but horrific transmissible facial cancer.
This one is standing in for Tux for one release using the far less-known
Devil Facial Tux Disguise.
Save The Tasmanian Devil http://tassiedevil.com.au
Signed-off-by: Linux.conf.au Hobart Team <contact@marchsouth.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / linux-2.6-omap-h63xx.git / log