linux-toradex.git, branch v2.6.30.3

Linux 2.6.30.3

2009-07-24T21:47:51+00:00

fbmon: work around compiler bug in gcc-4.2.4

2009-07-24T21:35:42+00:00

commit 3730793d457fed79a6d49bae72996d458c8e4f2d upstream.

There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent
he loop counter is of type 'unsigned char' and it should count to 128.

The compiler will incorrectly decide that a trivial loop like this:

	unsigned char i, ...

	for (i = 0; i < 128; i++) {
		..

is endless, and will compile it to a single instruction that just
branches to itself.

This was triggered by the addition of '-fno-strict-overflow', and we
could play games with compiler versions and go back to '-fwrapv'
instead, but the trivial way to avoid it is to just make the loop
induction variable be an 'int' instead.

Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure
for digging through assembler differences and finding it.

Reported-and-tested-by: Krzysztof Oledzki 
Found-by: Troy Moure 
Gcc-bug-acked-by: Ian Lance Taylor 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Linux 2.6.30.2

2009-07-20T03:39:19+00:00

Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x

2009-07-20T03:38:56+00:00

commit a137802ee839ace40079bebde24cfb416f73208a upstream.

This causes kernel images that don't run init to completion with certain
broken gcc versions.

This fixes kernel bugzilla entry:
	http://bugzilla.kernel.org/show_bug.cgi?id=13012

I suspect the gcc problem is this:
	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230

Fix the problem by using the -fno-strict-overflow flag instead, which
not only does not exist in the known-to-be-broken versions of gcc (it
was introduced later than fwrapv), but seems to be much less disturbing
to gcc too: the difference in the generated code by -fno-strict-overflow
are smaller (compared to using neither flag) than when using -fwrapv.

Reported-by: Barry K. Nathan 
Pushed-by: Frans Pop 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fuse: fix return value of fuse_dev_write()

2009-07-20T03:38:56+00:00

commit b4c458b3a23d76936e76678f2074b1528f129f7a upstream.

On 64 bit systems -- where sizeof(ssize_t) > sizeof(int) -- the following test
exposes a bug due to a non-careful return of an int or unsigned value:

implement a FUSE filesystem which sends an unsolicited notification to
the kernel with invalid opcode. The respective write to /dev/fuse
will return (1 << 32) - EINVAL with errno == 0 instead of -1 with
errno == EINVAL.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: fix bad return value in fuse_file_poll()

2009-07-20T03:38:55+00:00

commit 201fa69a2849536ef2912e8e971ec0b01c04eff4 upstream.

Fix fuse_file_poll() which returned a -errno value instead of a poll
mask.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

Fix iommu address space allocation

2009-07-20T03:38:55+00:00

commit a15a519ed6e5e644f5a33c213c00b0c1d3cfe683 upstream.

This fixes kernel.org bug #13584. The IOVA code attempted to optimise
the insertion of new ranges into the rbtree, with the unfortunate result
that some ranges just didn't get inserted into the tree at all. Then
those ranges would be handed out more than once, and things kind of go
downhill from there.

Introduced after 2.6.25 by ddf02886cbe665d67ca750750196ea5bf524b10b
("PCI: iova RB tree setup tweak").

Signed-off-by: David Woodhouse 
Cc: mark gross 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Fix pci_unmap_addr() et al on i386.

2009-07-20T03:38:54+00:00

commit 788d84bba47ea3eb377f7a3ae4fd1ee84b84877b upstream.

We can run a 32-bit kernel on boxes with an IOMMU, so we need
pci_unmap_addr() etc. to work -- without it, drivers will leak mappings.

To be honest, this whole thing looks like it's more pain than it's
worth; I'm half inclined to remove the no-op #else case altogether.

But this is the minimal fix, which just does the right thing if
CONFIG_DMAR is set.

Signed-off-by: David Woodhouse 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

floppy: fix lock imbalance

2009-07-20T03:38:54+00:00

commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream.

A crappy macro prevents us unlocking on a fail path.

Expand the macro and unlock appropriatelly.

Signed-off-by: Jiri Slaby 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "ipv4: arp announce, arp_proxy and windows ip conflict verification"

2009-07-20T03:38:54+00:00

commit f8a68e752bc4e39644843403168137663c984524 upstream.

This reverts commit 73ce7b01b4496a5fbf9caf63033c874be692333f.

After discovering that we don't listen to gratuitious arps in 2.6.30
I tracked the failure down to this commit.

The patch makes absolutely no sense.  RFC2131 RFC3927 and RFC5227.
are all in agreement that an arp request with sip == 0 should be used
for the probe (to prevent learning) and an arp request with sip == tip
should be used for the gratitous announcement that people can learn
from.

It appears the author of the broken patch got those two cases confused
and modified the code to drop all gratuitous arp traffic.  Ouch!

Signed-off-by: Eric W. Biederman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman