linux-toradex.git, branch v2.6.27.47

Linux 2.6.27.47

2010-05-26T21:27:20+00:00

nfsd: fix vm overcommit crash fix #2

2010-05-26T21:27:09+00:00

commit 1b79cd04fab80be61dcd2732e2423aafde9a4c1c upstream.

The previous patch from Alan Cox ("nfsd: fix vm overcommit crash",
commit 731572d39fcd3498702eda4600db4c43d51e0b26) fixed the problem where
knfsd crashes on exported shmemfs objects and strict overcommit is set.

But the patch forgot supporting the case when CONFIG_SECURITY is
disabled.

This patch copies a part of his fix which is mainly for detecting a bug
earlier.

Acked-by: James Morris 
Signed-off-by: Alan Cox 
Signed-off-by: Junjiro R. Okajima 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nfsd: fix vm overcommit crash

2010-05-26T21:27:09+00:00

commit 731572d39fcd3498702eda4600db4c43d51e0b26 upstream.

Junjiro R.  Okajima reported a problem where knfsd crashes if you are
using it to export shmemfs objects and run strict overcommit.  In this
situation the current->mm based modifier to the overcommit goes through a
NULL pointer.

We could simply check for NULL and skip the modifier but we've caught
other real bugs in the past from mm being NULL here - cases where we did
need a valid mm set up (eg the exec bug about a year ago).

To preserve the checks and get the logic we want shuffle the checking
around and add a new helper to the vm_ security wrappers

Also fix a current->mm reference in nommu that should use the passed mm

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix build]
Reported-by: Junjiro R. Okajima 
Acked-by: James Morris 
Signed-off-by: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

i2c-tiny-usb: Fix on big-endian systems

2010-05-26T21:27:09+00:00

commit 1c010ff8912cbc08d80e865aab9c32b6b00c527d upstream.

The functionality bit vector is always returned as a little-endian
32-bit number by the device, so it must be byte-swapped to the host
endianness.

On the other hand, the delay value is handled by the USB stack, so no
byte swapping is needed on our side.

This fixes bug #15105:
http://bugzilla.kernel.org/show_bug.cgi?id=15105

Reported-by: Jens Richter 
Signed-off-by: Jean Delvare 
Tested-by: Jens Richter 
Cc: Till Harbaum 
Signed-off-by: Greg Kroah-Hartman

i2c-i801: Don't use the block buffer for I2C block writes

2010-05-26T21:27:08+00:00

commit c074c39d62306efa5ba7c69c1a1531bc7333d252 upstream.

Experience has shown that the block buffer can only be used for SMBus
(not I2C) block transactions, even though the datasheet doesn't
mention this limitation.

Reported-by: Felix Rubinstein 
Signed-off-by: Jean Delvare 
Cc: Oleg Ryjkov 
Signed-off-by: Greg Kroah-Hartman

hwmon: (w83781d) Request I/O ports individually for probing

2010-05-26T21:27:08+00:00

commit b0bcdd3cd0adb85a7686b396ba50493871b1135c upstream.

Different motherboards have different PNP declarations for
W83781D/W83782D chips. Some declare the whole range of I/O ports (8
ports), some declare only the useful ports (2 ports at offset 5) and
some declare fancy ranges, for example 4 ports at offset 4. To
properly handle all cases, request all ports individually for probing.
After we have determined that we really have a W83781D or W83782D
chip, the useful port range will be requested again, as a single
block.

I did not see a board which needs this yet, but I know of one for lm78
driver and I'd like to keep the logic of these two drivers in sync.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

svc: Clean up deferred requests on transport destruction

2010-05-26T21:27:08+00:00

commit 22945e4a1c7454c97f5d8aee1ef526c83fef3223 upstream.

A race between svc_revisit and svc_delete_xprt can result in
deferred requests holding references on a transport that can never be
recovered because dead transports are not enqueued for subsequent
processing.

Check for XPT_DEAD in revisit to clean up completing deferrals on a dead
transport and sweep a transport's deferred queue to do the same for queued
but unprocessed deferrals.

Signed-off-by: Tom Tucker 
Signed-off-by: J. Bruce Fields 
Cc: roma1390 
Signed-off-by: Greg Kroah-Hartman

libata: retry FS IOs even if it has failed with AC_ERR_INVALID

2010-05-26T21:27:08+00:00

commit 534ead709235b967b659947c55d9130873a432c4 upstream.

libata currently doesn't retry if a command fails with AC_ERR_INVALID
assuming that retrying won't get it any further even if retried.
However, a failure may be classified as invalid through hardware
glitch (incorrect reading of the error register or firmware bug) and
there isn't whole lot to gain by not retrying as actually invalid
commands will be failed immediately.  Also, commands serving FS IOs
are extremely unlikely to be invalid.  Retry FS IOs even if it's
marked invalid.

Transient and incorrect invalid failure was seen while debugging
firmware related issue on Samsung n130 on bko#14314.

  http://bugzilla.kernel.org/show_bug.cgi?id=14314

Signed-off-by: Tejun Heo 
Reported-by: Johannes Stezenbach 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: ensure NCQ error result taskfile is fully initialized before returning it via qc->result_tf.

2010-05-26T21:27:08+00:00

commit a09bf4cd53b8ab000197ef81f15d50f29ecf973c upstream.

Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

i2c: Fix probing of FSC hardware monitoring chips

2010-05-26T21:27:08+00:00

commit b1d4b390ea4bb480e65974ce522a04022608a8df upstream.

Some FSC hardware monitoring chips (Syleus at least) doesn't like
quick writes we typically use to probe for I2C chips. Use a regular
byte read instead for the address they live at (0x73). These are the
only known chips living at this address on PC systems.

For clarity, this fix should not be needed for kernels 2.6.30 and
later, as we started instantiating the hwmon devices explicitly based
on DMI data. Still, this fix is valuable in the following two cases:
* Support for recent FSC chips on older kernels. The DMI-based device
  instantiation is more difficult to backport than the device support
  itself.
* Case where the DMI-based device instantiation fails, whatever the
  reason. We fall back to probing in that case, so it should work.

This fixes kernel bug #15634:
https://bugzilla.kernel.org/show_bug.cgi?id=15634

Signed-off-by: Jean Delvare 
Acked-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman