linux-toradex.git, branch v2.6.27.39

Linux 2.6.27.39

2009-11-10T00:59:38+00:00

x86/amd-iommu: Workaround for erratum 63

2009-11-10T00:52:48+00:00

commit c5cca146aa03e1f60fb179df65f0dbaf17bc64ed upstream.

There is an erratum for IOMMU hardware which documents
undefined behavior when forwarding SMI requests from
peripherals and the DTE of that peripheral has a sysmgt
value of 01b. This problem caused weird IO_PAGE_FAULTS in my
case.
This patch implements the suggested workaround for that
erratum into the AMD IOMMU driver.  The erratum is
documented with number 63.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: Un__init function required on shutdown

2009-11-10T00:52:46+00:00

commit ca0207114f1708b563f510b7781a360ec5b98359 upstream.

The function iommu_feature_disable is required on system
shutdown to disable the IOMMU but it is marked as __init.
This may result in a panic if the memory is reused. This
patch fixes this bug.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

bonding: fix a race condition in calls to slave MII ioctls

2009-11-10T00:52:45+00:00

commit d9d5283228d0c752f199c901fff6e1405dc91bcb upstream.

In mii monitor mode, bond_check_dev_link() calls the the ioctl
handler of slave devices. It stores the ndo_do_ioctl function
pointer to a static (!) ioctl variable and later uses it to call the
handler with the IOCTL macro.

If another thread executes bond_check_dev_link() at the same time
(even with a different bond, which none of the locks prevent), a
race condition occurs. If the two racing slaves have different
drivers, this may result in one driver's ioctl handler being
called with a pointer to a net_device controlled with a different
driver, resulting in unpredictable breakage.

Unless I am overlooking something, the "static" must be a
copy'n'paste error (?).

Signed-off-by: Jiri Bohac 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

printk: robustify printk

2009-11-10T00:52:43+00:00

commit b845b517b5e3706a3729f6ea83b88ab85f0725b0 upstream.

Avoid deadlocks against rq->lock and xtime_lock by deferring the klogd
wakeup by polling from the timer tick.

Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

NFSv4: The link() operation should return any delegation on the file

2009-11-10T00:52:41+00:00

commit 9a3936aac133037f65124fcb2d676a6c201a90a4 upstream.

Otherwise, we have to wait for the server to recall it.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: Fix a problem whereby a buggy server can oops the kernel

2009-11-10T00:52:39+00:00

commit d953126a28f97ec965d23c69fd5795854c048f30 upstream.

We just had a case in which a buggy server occasionally returns the wrong
attributes during an OPEN call. While the client does catch this sort of
condition in nfs4_open_done(), and causes the nfs4_atomic_open() to return
-EISDIR, the logic in nfs_atomic_lookup() is broken, since it causes a
fallback to an ordinary lookup instead of just returning the error.

When the buggy server then returns a regular file for the fallback lookup,
the VFS allows the open, and bad things start to happen, since the open
file doesn't have any associated NFSv4 state.

The fix is firstly to return the EISDIR/ENOTDIR errors immediately, and
secondly to ensure that we are always careful when dereferencing the
nfs_open_context state pointer.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: Kill nfs4_renewd_prepare_shutdown()

2009-11-10T00:52:37+00:00

commit 3050141bae57984dd660e6861632ccf9b8bca77e upstream.

The NFSv4 renew daemon is shared between all active super blocks that refer
to a particular NFS server, so it is wrong to be shutting it down in
nfs4_kill_super every time a super block is destroyed.

This patch therefore kills nfs4_renewd_prepare_shutdown altogether, and
leaves it up to nfs4_shutdown_client() to also shut down the renew daemon
by means of the existing call to nfs4_kill_renewd().

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

nfs: Avoid overrun when copying client IP address string

2009-11-10T00:52:36+00:00

commit f4373bf9e67e4a653c8854acd7b02dac9714c98a upstream.

As seen in , nfs4_init_client() can
overrun the source string when copying the client IP address from
nfs_parsed_mount_data::client_address to nfs_client::cl_ipaddr.  Since
these are both treated as null-terminated strings elsewhere, the copy
should be done with strlcpy() not memcpy().

Signed-off-by: Ben Hutchings 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: Fix a bug when the server returns NFS4ERR_RESOURCE

2009-11-10T00:52:34+00:00

commit 52567b03ca38b6e556ced450d64dba8d66e23b0e upstream.

RFC 3530 states that when we recieve the error NFS4ERR_RESOURCE, we are not
supposed to bump the sequence number on OPEN, LOCK, LOCKU, CLOSE, etc
operations. The problem is that we map that error into EREMOTEIO in the XDR
layer, and so the NFSv4 middle-layer routines like seqid_mutating_err(),
and nfs_increment_seqid() don't recognise it.

The fix is to defer the mapping until after the middle layers have
processed the error.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman