Trond Myklebust [Tue, 14 Oct 2008 23:24:50 +0000 (19:24 -0400)]
NFS: Fix a resolution problem with nfs_inode->cache_change_attribute
The cache_change_attribute is used to decide whether or not a directory has
changed, in which case we may need to look it up again. Again, the use of
'jiffies' leads to an issue of resolution.
Once again, the fix is to change nfs_inode->cache_change_attribute, and
just make it a simple counter.
Trond Myklebust [Tue, 14 Oct 2008 23:16:07 +0000 (19:16 -0400)]
NFS: Fix the resolution problem with nfs_inode_attrs_need_update()
It appears that 'jiffies' timestamps do not have high enough resolution for
nfs_inode_attrs_need_update(). One problem is that a GETATTR can be
launched within < 1 jiffy of the last operation that updated the attribute.
Another problem is that RPC calls can take < 1 jiffy to execute.
We can fix this by switching the variables to use a simple global counter
that gets incremented every time we start another GETATTR call.
Tom Talpey [Fri, 10 Oct 2008 15:32:34 +0000 (11:32 -0400)]
RPC/RDMA: correct the reconnect timer backoff
The RPC/RDMA code had a constant 5-second reconnect backoff, and
always performed it, even when re-establishing a connection to a
server after the RPC layer closed it due to being idle. Make it
an geometric backoff (up to 30 seconds), and don't delay idle
reconnect.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 19:01:41 +0000 (15:01 -0400)]
RPC/RDMA: harden connection logic against missing/late rdma_cm upcalls.
Add defensive timeouts to wait_for_completion() calls in RDMA
address resolution, and make them interruptible. Fix the timeout
units to milliseconds (formerly jiffies) and move to private header.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 19:01:31 +0000 (15:01 -0400)]
RPC/RDMA: fix connect/reconnect resource leak.
The RPC/RDMA code can leak RDMA connection manager endpoints in
certain error cases on connect. Don't signal unwanted events,
and be certain to destroy any allocated qp.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 19:01:21 +0000 (15:01 -0400)]
RPC/RDMA: return a consistent error, when connect fails.
The xprt_connect call path does not expect such errors as ECONNREFUSED
to be returned from failed transport connection attempts, otherwise it
translates them to EIO and signals fatal errors. For example, mount.nfs
prints simply "internal error". Translate all such errors to ENOTCONN
from RPC/RDMA to match sockets behavior.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 19:01:11 +0000 (15:01 -0400)]
RPC/RDMA: adhere to protocol for unpadded client trailing write chunks.
The RPC/RDMA protocol allows clients and servers to avoid RDMA
operations for data which is purely the result of XDR padding.
On the client, automatically insert the necessary padding for
such server replies, and optionally don't marshal such chunks.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 19:01:00 +0000 (15:01 -0400)]
RPC/RDMA: avoid an oops due to disconnect racing with async upcalls.
RDMA disconnects yield an upcall from the RDMA connection manager,
which can race with rpc transport close, e.g. on ^C of a mount.
Ensure any rdma cm_id and qp are fully destroyed before continuing.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Tucker [Thu, 9 Oct 2008 19:00:30 +0000 (15:00 -0400)]
RPC/RDMA: fix connection IRD/ORD setting
This logic sets the connection parameter that configures the local device
and informs the remote peer how many concurrent incoming RDMA_READ
requests are supported. The original logic didn't really do what was
intended for two reasons:
- The max number supported by the device is typically smaller than
any one factor in the calculation used, and
- The field in the connection parameter structure where the value is
stored is a u8 and always overflows for the default settings.
So what really happens is the value requested for responder resources
is the left over 8 bits from the "desired value". If the desired value
happened to be a multiple of 256, the result was zero and it wouldn't
connect at all.
Given the above and the fact that max_requests is almost always larger
than the max responder resources supported by the adapter, this patch
simplifies this logic and simply requests the max supported by the device,
subject to a reasonable limit.
This bug was found by Jim Schutt at Sandia.
Signed-off-by: Tom Tucker <tom@opengridcomputing.com> Acked-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 19:00:09 +0000 (15:00 -0400)]
RPC/RDMA: check selected memory registration mode at runtime.
At transport creation, check for, and use, any local dma lkey.
Then, check that the selected memory registration mode is in fact
supported by the RDMA adapter selected for the mount. Fall back
to best alternative if not.
Signed-off-by: Tom Talpey <talpey@netapp.com> Acked-by: Tom Tucker <tom@opengridcomputing.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tom Talpey [Thu, 9 Oct 2008 18:59:49 +0000 (14:59 -0400)]
RPC/RDMA: refactor the inline memory registration code.
Refactor the memory registration and deregistration routines.
This saves stack space, makes the code more readable and prepares
to add the new FRMR registration methods.
Signed-off-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Chuck Lever [Wed, 8 Oct 2008 19:38:10 +0000 (15:38 -0400)]
NFS: fix nfs_parse_ip_address() corner case
Bruce observed that nfs_parse_ip_address() will successfully parse an
IPv6 address that looks like this:
"::1%"
A scope delimiter is present, but there is no scope ID following it.
This is harmless, as it would simply set the scope ID to zero. However,
in some cases we would like to flag this as an improperly formed
address.
We are now also careful to reject addresses where garbage follows the
address (up to the length of the string), instead of ignoring the
non-address characters; and where the scope ID is nonsense (not a valid
device name, but also not numeric). Before, both of these cases would
result in a harmless zero scope ID.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Trond Myklebust [Thu, 9 Oct 2008 17:27:55 +0000 (13:27 -0400)]
NFS: Fix attribute updates
This fixes a regression seen when running the Connectathon testsuite
against an ext3 filesystem. The reason was that the inode was constantly
being marked as 'just updated' by the jiffy wraparound test.
This again meant that newer GETATTR calls were failing to pass the
nfs_inode_attrs_need_update() test unless the changes caused a ctime update
on the server, since they were perceived as having been started before the
latest inode update.
Given that nfs_inode_attrs_need_update() already checks for wraparound
of nfsi->last_updated, we can drop the buggy "protection" in
nfs_update_inode().
Also make a slight micro-optimisation of nfs_inode_attrs_need_update(): we
are more often going to see time_after(fattr->time_start, nfsi->last_updated)
be true, rather than seeing an update of ctime/size, so put that test
first to ensure that we optimise away the ctime/size tests.
sunrpc: fix oops in rpc_create when the mount namespace is unshared
On a system with nfs mounts, if a task unshares its mount namespace,
a oops can occur when the system is rebooted if the task is the last
to unreference the nfs mount. It will try to create a rpc request
using utsname() which has been invalidated by free_nsproxy().
The patch fixes the issue by using the global init_utsname() which is
always valid. the capability of identifying rpc clients per uts namespace
stills needs some extra work so this should not be a problem.
BUG: unable to handle kernel NULL pointer dereference at 00000004
IP: [<c024c9ab>] rpc_create+0x332/0x42f
Oops: 0000 [#1] DEBUG_PAGEALLOC
Steve Dickson [Sat, 12 Apr 2008 00:03:06 +0000 (20:03 -0400)]
NFS: Client mounts hang when exported directory do not exist
This patch fixes a regression that was introduced by the string based mounts.
nfs_mount() statically returns -EACCES for every error returned
by the remote mounted. This is incorrect because -EACCES is
an non-fatal error to the mount.nfs command. This error causes
mount.nfs to retry the mount even in the case when the exported
directory does not exist.
This patch maps the errors returned by the remote mountd into
valid errno values, exactly how it was done pre-string based
mounts. By returning the correct errno enables mount.nfs
to do the right thing.
Signed-off-by: Steve Dickson <steved@redhat.com>
[Trond.Myklebust@netapp.com: nfs_stat_to_errno() now correctly returns
negative errors, so remove the sign change.] Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Trond Myklebust [Fri, 3 Oct 2008 20:48:34 +0000 (16:48 -0400)]
SUNRPC: Fix autobind on cloned rpc clients
Despite the fact that cloned rpc clients won't have the cl_autobind flag
set, they may still find themselves calling rpcb_getport_async(). For this
to happen, it suffices for a _parent_ rpc_clnt to use autobinding, in which
case any clone may find itself triggering the !xprt_bound() case in
call_bind().
The correct fix for this is to walk back up the tree of cloned rpc clients,
in order to find the parent that 'owns' the transport, either because it
has clnt->cl_autobind set, or because it originally created the
transport...
Chuck Lever [Thu, 25 Sep 2008 15:57:12 +0000 (11:57 -0400)]
NFS: SETCLIENTID truncates client ID and netid
The sc_name field is currently 56 bytes long. This is not large enough
to hold a pair of IPv6 addresses, the authentication type, the protocol
name, and a uniquifier number. The maximum possible size of the name
string using IPv6 addresses is just under 110 bytes, so I increased the
size of the sc_name field to accomodate this maximum.
In addition, the strings in the nfs4_setclientid structure are
constructed with scnprintf(), which wants to terminate its output with
'\0'. The sc_netid field was large enough only for a three byte netid
string and a '\0' so inet6 netids were being truncated. Perhaps we
don't need the overhead of scnprintf() to do a simple string copy, but
I fixed this by increasing the size of the buffer by one byte.
Since all three of the string buffers in nfs4_setclientid are
constructed with scnprintf(), I increased the size of all three by one
byte to document the requirement, although I don't think either the
universal address field or the name field will be so small that these
strings get truncated in this way.
The size of the Linux client's client ID on the wire will be larger
than before. RFC 3530 suggests the size limit for client IDs is 1024,
and we are still well below that.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Richard Kennedy [Tue, 26 Aug 2008 15:23:20 +0000 (16:23 +0100)]
NFS: remove 8 bytes of padding from struct nfs_fattr on 64 bit builds
remove 8 bytes of padding from struct nfs_fattr on 64 bit builds
This also removes padding from several nfs structures, including
16 bytes from nfs4_opendata, nfs4_createdata,nfs3_createdata
& 8 bytes from nfs_read_data,nfs_write_data,nfs_removeres,nfs4_closedata
This also reduces the reported stack usage of many nfs functions (30+).
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
----
This patch is against the latest git 2.6.27-rc4.
I've built & run this on my AMD64 desktop, & successfully run _simple_
tests with a 64 bit client => 32 bit server & 32 bit client to 64 bit
server.
On fedora with gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) checkpatch
reports 33 functions with reduced stack usage.
e.g.
__nfs_revalidate_inode [nfs] 216 => 200
_nfs4_proc_access [nfs] 304 => 288
_nfs4_proc_link [nfs] 536 => 504
_nfs4_proc_remove [nfs] 304 => 288
_nfs4_proc_rename [nfs] 584 => 552
nfs3_proc_access [nfs] 272 => 256
nfs3_proc_getacl [nfs] 384 => 368
nfs3_proc_link [nfs] 496 => 464
etc
I can supply the complete list if anyone is interested.
regards
Richard Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
EG Keizer [Tue, 19 Aug 2008 20:34:36 +0000 (16:34 -0400)]
nfs: authenticated deep mounting
Allow mount to do authenticated mounts below the root of the exported tree.
The wording in RFC 2623, sec 2.3.2. allows fsinfo with UNIX authentication
on the root of the export. Mounts are not always done on the root
of the exported tree. Especially autoumounts often mount below the root of
the exported tree.
Some server implementations (justly) require full authentication for the
so-called deep mounts. The old code used AUTH_SYS only. This caused deep
mounts to fail on systems requiring stronger authentication..
The client should try both authentication types and use the first one that
succeeds.
This method was already partially implemented. This patch completes
the implementation for NFS2 and NFS3.
This patch was developed to allow Debian systems to automount home directories
on Solaris servers with krb5 authentication.
Tested on kernel 2.6.24-etchnhalf.1
Signed-off-by: E.G. Keizer <keie@few.vu.nl> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Jeff Layton [Mon, 18 Aug 2008 13:17:58 +0000 (09:17 -0400)]
NFS: missing nfs_fattr_init in nfs3_proc_getacl and nfs3_proc_setacls (resend #2)
The fattrs used in the NFSv3 getacl/setacl calls are not being properly
initialized. This occasionally causes nfs_update_inode to fall into
NFSv4 specific codepaths when handling post-op attrs from these calls.
Thanks to Cai Qian for noticing the spurious NFSv4 messages in debug
output from a v3 mount...
Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Denis V. Lunev [Mon, 11 Aug 2008 08:02:34 +0000 (12:02 +0400)]
nfs: BUG_ON in nfs_follow_mountpoint
Unfortunately, BUG_ON(IS_ROOT(dentry)) can happen inside
nfs_follow_mountpoint with NFS running Fedora 8 using a
specific setup.
https://bugzilla.redhat.com/show_bug.cgi?id=458622
So, the situation should be handled on NFS client gracefully.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Trond Myklebust <Trond.Myklebust@netapp.com> CC: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Trond Myklebust [Sun, 5 Oct 2008 18:48:22 +0000 (14:48 -0400)]
NFS: Allow concurrent inode revalidation
Currently, if two processes are both trying to revalidate metadata for the
same inode, they will find themselves being serialised. There is no good
justification for this now that we have improved our ability to detect
stale attribute data, so we should remove that serialisation.
Trond Myklebust [Sun, 5 Oct 2008 17:31:21 +0000 (13:31 -0400)]
NFS: Don't clear nfsi->cache_validity in nfs_check_inode_attributes()
If we're merely checking the inode attributes because we suspect that the
'updated' attributes returned by the RPC call are stale, then we shouldn't
be doing weak cache consistency updates or clearing the cache_validity
flags.
NFS: Convert __nfs_revalidate_inode() to use nfs_refresh_inode()
In the case where there are parallel RPC calls to the same inode, we may
receive stale metadata due to the lack of ordering, hence the sanity
checking of metadata in nfs_refresh_inode().
Currently, __nfs_revalidate_inode() is calling nfs_update_inode() directly,
without any further sanity checks, and hence may end up setting the inode
up with stale metadata.
Fix is to use nfs_refresh_inode() instead of nfs_update_inode().
Trond Myklebust [Sun, 5 Oct 2008 16:27:55 +0000 (12:27 -0400)]
NFS: Fix nfs_post_op_update_inode_force_wcc()
If we believe that the attributes are old (see nfs_refresh_inode()), then
we shouldn't force an update.
Also ensure that we hold the inode->i_lock across attribute checks and the
call to nfs_refresh_inode_locked() to ensure that we don't race with other
attribute updates.
Currently nfs_refresh_inode() will only update the inode metadata if it
sees that the RPC call that returned the nfs_fattr was started
after the last update of the inode. This means that if we have parallel
RPC calls to the same inode (when sending WRITE calls, for instance), we
may often miss updates.
This patch attempts to recover those missed updates by also accepting
them if the ctime in the nfs_fattr is more recent than the inode's
cached ctime.
It also recovers the case where the file size has increased, but the
ctime has not been updated due to limited ctime resolution.
Trond Myklebust [Sun, 5 Oct 2008 16:07:23 +0000 (12:07 -0400)]
NFS: Clean up nfs_refresh_inode() and nfs_post_op_update_inode()
Try to avoid taking and dropping the inode->i_lock more than once. Do so by
moving the code in nfs_refresh_inode() that needs to be done under the
spinlock into a function nfs_refresh_inode_locked(), and then having both
nfs_refresh_inode() and nfs_post_op_update_inode() call it directly.
Trond Myklebust [Fri, 15 Aug 2008 20:59:14 +0000 (16:59 -0400)]
NFS: Don't apply NFS_MOUNT_FLAGMASK to text-based mounts
The point of introducing text-based mounts was to allow us to add
functionality without having to worry about legacy binary mount formats.
The mask should be there in order to ensure that binary formats don't start
enabling features that they cannot support. There is no justification for
applying it to the text mount path.
NFS: Add options for finer control of the lookup cache
Add the flag NFS_MOUNT_LOOKUP_CACHE_NONEG to turn off the caching of
negative dentries. In reality what we do is to force
nfs_lookup_revalidate() to always discard negative dentries.
Add the flag NFS_MOUNT_LOOKUP_CACHE_NONE for enforcing stricter
revalidation of dentries. It forces the revalidate code to always do a
lookup instead of just checking the cached mtime of the parent directory.
Instead of causing umount requests to block on server->active_wq while the
asynchronous sillyrename deletes are executing, we can use the sb->s_active
counter to obtain a reference to the super_block, and then release that
reference in nfs_async_unlink_release().
After the BKL removal patches were applied to the rest of the NFS code, the
BKL protection in nfs_file_llseek() is no longer sufficient to ensure that
inode->i_size is read safely in generic_file_llseek_unlocked().
In order to fix the situation, we either have to replace the naked read of
inode->i_size in generic_file_llseek_unlocked() with i_size_read(), or the
whole thing needs to be executed under the inode->i_lock;
In order to avoid disrupting other filesystems, avoid touching
generic_file_llseek_unlocked() for now...
* Theodore Ts'o (tytso@mit.edu) wrote:
>
> I've been playing with adding some markers into ext4 to see if they
> could be useful in solving some problems along with Systemtap. It
> appears, though, that as of 2.6.27-rc8, markers defined in code which is
> compiled directly into the kernel (i.e., not as modules) don't show up
> in Module.markers:
>
> kvm_trace_entryexit arch/x86/kvm/kvm-intel %u %p %u %u %u %u %u %u
> kvm_trace_handler arch/x86/kvm/kvm-intel %u %p %u %u %u %u %u %u
> kvm_trace_entryexit arch/x86/kvm/kvm-amd %u %p %u %u %u %u %u %u
> kvm_trace_handler arch/x86/kvm/kvm-amd %u %p %u %u %u %u %u %u
>
> (Note the lack of any of the kernel_sched_* markers, and the markers I
> added for ext4_* and jbd2_* are missing as wel.)
>
> Systemtap apparently depends on in-kernel trace_mark being recorded in
> Module.markers, and apparently it's been claimed that it used to be
> there. Is this a bug in systemtap, or in how Module.markers is getting
> built? And is there a file that contains the equivalent information
> for markers located in non-modules code?
Linus Torvalds [Mon, 6 Oct 2008 21:29:16 +0000 (14:29 -0700)]
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: gart iommu have direct mapping when agp is present too
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
ide: workaround for bogus gcc warning in ide_sysfs_register_port()
ide-cd: Optiarc DVD RW AD-7200A does play audio
IDE: Fix platform device registration in Swarm IDE driver (v2)
ide-dma: fix ide_build_dmatable() for TRM290
ide-cd: temporary tray close fix
Linus Torvalds [Mon, 6 Oct 2008 21:27:39 +0000 (14:27 -0700)]
Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] IP27: Fix build errors if CONFIG_MAPPED_KERNEL=y
[MIPS] Fix CMP Kconfig configuration and mark as broken.
Linus Torvalds [Mon, 6 Oct 2008 21:27:15 +0000 (14:27 -0700)]
Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb: (33 commits)
V4L/DVB (9103): em28xx: HVR-900 B3C0 - fix audio clicking issue
V4L/DVB (9099): em28xx: Add detection for K-WORLD DVB-T 310U
V4L/DVB (9092): gspca: Bad init values for sonixj ov7660.
V4L/DVB (9080): gspca: Add a delay after writing to the sonixj sensors.
V4L/DVB (9075): gspca: Bad check of returned status in i2c_read() spca561.
V4L/DVB (9053): fix buffer overflow in uvc-video
V4L/DVB (9043): S5H1420: Fix size of shadow-array to avoid overflow
V4L/DVB (9037): Fix support for Hauppauge Nova-S SE
V4L/DVB (9029): Fix deadlock in demux code
V4L/DVB (8979): sms1xxx: Add new USB product ID for Hauppauge WinTV MiniStick
V4L/DVB (8978): sms1xxx: fix product name for Hauppauge WinTV MiniStick
V4L/DVB (8967): Use correct XC3028L firmware for AMD ATI TV Wonder 600
V4L/DVB (8963): s2255drv field count fix
V4L/DVB (8961): zr36067: Fix RGBR pixel format
V4L/DVB (8960): drivers/media/video/cafe_ccic.c needs mm.h
V4L/DVB (8958): zr36067: Return proper bytes-per-line value
V4L/DVB (8957): zr36067: Restore the default pixel format
V4L/DVB (8955): bttv: Prevent NULL pointer dereference in radio_open
V4L/DVB (8935): em28xx-cards: Remove duplicate entry (EM2800_BOARD_KWORLD_USB2800)
V4L/DVB (8933): gspca: Disable light frquency for zc3xx cs2102 Kokom.
...
atmel-mci: Initialize BLKR before sending data transfer command
The atmel-mci driver sometimes fails data transfers like this:
mmcblk0: error -5 transferring data
end_request: I/O error, dev mmcblk0, sector 2749769
end_request: I/O error, dev mmcblk0, sector 2749777
It turns out that this might be caused by the BLKR register (which
contains the block size and the number of blocks being transfered) being
initialized too late. This patch moves the initialization of BLKR so
that it contains the correct value before the block transfer command is
sent.
This error is difficult to reproduce, but if you insert a long delay
(mdelay(10) or thereabouts) between the calls to atmci_start_command()
and atmci_submit_data(), all transfers seem to fail without this patch,
while I haven't seen any failures with this patch.
Jason Wessel [Mon, 6 Oct 2008 18:50:59 +0000 (13:50 -0500)]
kgdb: call touch_softlockup_watchdog on resume
The softlockup watchdog needs to be touched when resuming the from the
kgdb stopped state to avoid the printk that a CPU is stuck if the
debugger was active for longer than the softlockup threshold.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Jan Kiszka [Mon, 6 Oct 2008 18:50:59 +0000 (13:50 -0500)]
kgdb, x86: Avoid invoking kgdb_nmicallback twice per NMI
Stress-testing KVM's latest NMI support with kgdbts inside an SMP guest,
I came across spurious unhandled NMIs while running the singlestep test.
Looking closer at the code path each NMI takes when KGDB is enabled, I
noticed that kgdb_nmicallback is called twice per event: One time via
DIE_NMI_IPI notification, the second time on DIE_NMI. Removing the first
invocation cures the unhandled NMIs here.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
x86 ACPI: Blacklist two HP machines with buggy BIOSes
There is a bug in the BIOSes of some HP boxes with AMD Turions which
connects IO-APIC pins with ACPI thermal trip points in such a way that
if the state of the IO-APIC is not as expected by the (buggy) BIOS, the
thermal trip points are set to insanely low values (usually all of them
become 16 degrees Celsius). As a result, thermal throttling kicks in
and knock the system down to its shoes.
Unfortunately some of the recent IO-APIC changes made the bug show up.
To prevent this from happening, blacklist machines that are known to be
affected (nx6115 and 6715b in this particular case).
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11516 listed as
a regression from 2.6.26.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
and the whole story is described in this (huge) thread:
As far as the Dmitry's and Jason's boxes are concerned, I recognized the
symptoms and asked them to verify that the blacklisting helped.
It appears that the buggy BIOS code has been copy-pasted to the entire
range of machines, for no good reason.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Jason Vas Dias <jason.vas.dias@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ralf Baechle [Sun, 5 Oct 2008 16:23:28 +0000 (18:23 +0200)]
IDE: Fix platform device registration in Swarm IDE driver (v2)
The Swarm IDE driver uses a release method which is defined in the driver
itself thus potentially oopsable. The simple fix would be to just leak
the device but this patch goes the full length and moves the entire
handling of the platform device in the platform code and retains only
the platform driver code in drivers/ide/mips/swarm.c.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[bart: remove no longer needed BLK_DEV_IDE_SWARM from ide/Kconfig] Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Apparently, 'xcount' being 0 does not mean 0 bytes for TRM290; it means 4 bytes,
judging from the code immediately preceding this check. So, we must never try
to "split" the PRD for TRM290.
This is probably never hit anyway -- with the DMA buffers aligned to at least
512 bytes and ATAPI DMA not being used for non block I/O commands...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Borislav Petkov [Sun, 5 Oct 2008 16:23:27 +0000 (18:23 +0200)]
ide-cd: temporary tray close fix
This one fixes http://bugzilla.kernel.org/show_bug.cgi?id=11602.
A more generic fix for drives which cannot autoclose tray will follow.
Signed-off-by: Borislav Petkov <petkovbb@gmail.com> Cc: Jens Axboe <jens.axboe@oracle.com>
[bart: add an extra parentheses for consistency with the rest of kernel code] Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
V4L/DVB (9099): em28xx: Add detection for K-WORLD DVB-T 310U
Correct firmware type to MTS
Correct audio routing for composite/s-video
Add DVB-T detection.
This patch uses the eeprom hash method for detection as the vendor/product
ids are also used for the DIGIVOX_AD. This may be a clone of the same
product. Explanatory text has been added prior to the hask look-up in
anticipation that it may help others.
The following has been tested to work:
Analogue TV (PAL-I)
Composite In
DVB-T (UK Crystal Palace)
USB AUDIO
The following has not been tested but probably works:
S-Video In
Ralph Loader [Tue, 23 Sep 2008 00:06:48 +0000 (21:06 -0300)]
V4L/DVB (9053): fix buffer overflow in uvc-video
There is a buffer overflow in drivers/media/video/uvc/uvc_ctrl.c:
INFO: 0xf2c5ce08-0xf2c5ce0b. First byte 0xa1 instead of 0xcc
INFO: Allocated in uvc_query_v4l2_ctrl+0x3c/0x239 [uvcvideo] age=13 cpu=1 pid=4975
...
A fixed size 8-byte buffer is allocated, and a variable size field is read
into it; there is no particular bound on the size of the field (it is
dependent on hardware and configuration) and it can overflow [also
verified by inserting printk's.]
The patch attempts to size the buffer to the correctly.
V4L/DVB (9037): Fix support for Hauppauge Nova-S SE
Different backends have different input busses (saa7146, flexcop).
To reflect that a config-option to the s5h1420-driver was added which makes
the output mode selectable.
Furthermore the s5h1420-driver is now doing the same i2c-method as it was done
before adding support for other i2c-users.
This patch needs to go into the current release of the kernel, as this driver
is currently broken.
(Thanks to Eberhard Kaltenhaeuser for helping out to debug this issue.)
Signed-off-by: Patrick Boettcher <pb@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The functions dvb_dmxdev_section_callback, dvb_dmxdev_ts_callback,
dvb_dmx_swfilter_packet, dvb_dmx_swfilter_packets, dvb_dmx_swfilter and
dvb_dmx_swfilter_204 may be called from both interrupt and process
context. Therefore they need to be protected by spin_lock_irqsave()
instead of spin_lock().
This fixes a deadlock discovered by lockdep.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare [Fri, 5 Sep 2008 13:39:27 +0000 (10:39 -0300)]
V4L/DVB (8961): zr36067: Fix RGBR pixel format
The zr36067 driver is improperly declaring pixel format RGBP twice,
once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
actually RGBR. Fix the code to properly map both pixel formats.
drivers/media/video/cafe_ccic.c: In function 'cafe_setup_siobuf':
drivers/media/video/cafe_ccic.c:1192: error: implicit declaration of function 'PAGE_ALIGN'
drivers/media/video/cafe_ccic.c: At top level:
drivers/media/video/cafe_ccic.c:1430: error: variable 'cafe_v4l_vm_ops' has initializer but incomplete type
drivers/media/video/cafe_ccic.c:1431: error: unknown field 'open' specified in initializer
drivers/media/video/cafe_ccic.c:1431: warning: excess elements in struct initializer
drivers/media/video/cafe_ccic.c:1431: warning: (near initialization for 'cafe_v4l_vm_ops')
drivers/media/video/cafe_ccic.c:1432: error: unknown field 'close' specified in initializer
drivers/media/video/cafe_ccic.c:1433: warning: excess elements in struct initializer
drivers/media/video/cafe_ccic.c:1433: warning: (near initialization for 'cafe_v4l_vm_ops')
drivers/media/video/cafe_ccic.c: In function 'cafe_v4l_mmap':
drivers/media/video/cafe_ccic.c:1444: error: 'VM_WRITE' undeclared (first use in this function)
drivers/media/video/cafe_ccic.c:1444: error: (Each undeclared identifier is reported only once
drivers/media/video/cafe_ccic.c:1444: error: for each function it appears in.)
drivers/media/video/cafe_ccic.c:1444: error: 'VM_SHARED' undeclared (first use in this function)
drivers/media/video/cafe_ccic.c:1461: error: 'VM_DONTEXPAND' undeclared (first use in this function)
This build breakage is caused by some header file shuffle in linux-next. But
I suggest that this patch be merged ahead of linux-next to avoid bisection
breakage.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare [Sun, 7 Sep 2008 08:56:55 +0000 (05:56 -0300)]
V4L/DVB (8958): zr36067: Return proper bytes-per-line value
The zr36067 driver should return the actual bytes-per-line value when
queried with ioctl VIDIOC_G_FMT, instead of 0. Otherwise user-space
applications can get confused.
Likewise, with ioctl VIDIOC_S_FMT, we are supposed to fill the
bytes-per-line value. And we shouldn't fail if the caller sets the
initial value to something different from 0. This is perfectly valid
for applications to pre-fill this field with the value they expect.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare [Sun, 7 Sep 2008 08:21:34 +0000 (05:21 -0300)]
V4L/DVB (8957): zr36067: Restore the default pixel format
Restore the default pixel format to YUYV as it used to be before
kernel 2.6.23. It was accidentally changed to BGR3 by commit 603d6f2c8f9f3604f9c6c1f8903efc2df30a000f.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This happens because radio_open assumes that all present bttv devices
have a radio function. If a bttv device without radio and one with
radio are installed on the same system, and the one without radio is
registered first, then radio_open checks for the radio device number
of a bttv device that has no radio function, and this breaks. All we
have to do to fix it is to skip bttv devices without a radio function.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Linus Torvalds [Sat, 4 Oct 2008 19:15:13 +0000 (12:15 -0700)]
Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
clockevents: check broadcast tick device not the clock events device
Linus Torvalds [Sat, 4 Oct 2008 19:14:46 +0000 (12:14 -0700)]
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86 setup: correct segfault in generation of 32-bit reloc kernel
Thomas Gleixner [Sat, 4 Oct 2008 08:51:07 +0000 (10:51 +0200)]
clockevents: check broadcast tick device not the clock events device
Impact: jiffies increment too fast.
Hugh Dickins noted that with NOHZ=n and HIGHRES=n jiffies get
incremented too fast. The reason is a wrong check in the broadcast
enter/exit code, which keeps the local apic timer in periodic mode
when the switch happens.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Linus Torvalds [Sat, 4 Oct 2008 01:22:36 +0000 (18:22 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
selinux: Fix an uninitialized variable BUG/panic in selinux_secattr_to_sid()
ACPI: Make /proc/acpi/wakeup interface handle PCI devices (again)
Make the ACPI /proc/acpi/wakeup interface set the appropriate wake-up bits
of physical devices corresponding to the ACPI devices and make those bits
be set initially for devices that are enabled to wake up by default. This
is needed to restore the 2.6.26 and earlier behavior for the PCI devices
that were previously handled correctly with the help of the
/proc/acpi/wakeup interface.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sven Wegener [Fri, 3 Oct 2008 22:23:48 +0000 (15:23 -0700)]
leds-pca955x: add proper error handling and fix bogus memory handling
Check the return value of led_classdev_register and unregister all
registered devices, if registering one device fails. Also the dynamic
memory handling is totally bogus. You can't allocate multiple chunks via
kzalloc() and expect them to be in order later. I wonder how this ever
worked.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net> Acked-by: Nate Case <ncase@xes-inc.com> Tested-by: Nate Case <ncase@xes-inc.com> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / linux-2.6-omap-h63xx.git / log