linux-toradex.git, branch v2.6.22.15

Linux 2.6.22.15

2007-12-14T18:34:15+00:00

BRIDGE: Properly dereference the br_should_route_hook

2007-12-14T18:32:01+00:00

[BRIDGE]: Properly dereference the br_should_route_hook

[ Upstream commit: 82de382ce8e1c7645984616728dc7aaa057821e4 ]

This hook is protected with the RCU, so simple

if (br_should_route_hook)
	br_should_route_hook(...)

is not enough on some architectures.

Use the rcu_dereference/rcu_assign_pointer in this case.

Fixed Stephen's comment concerning using the typeof().

Signed-off-by: Pavel Emelyanov 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

libata: kill spurious NCQ completion detection

2007-12-14T18:32:01+00:00

patch 459ad68893a84fb0881e57919340b97edbbc3dc7 in mainline.

Spurious NCQ completion detection implemented in ahci was incorrect.
On AHCI receving and processing FISes and raising interrupts are not
interlocked and spurious interrupts are expected.

For example, if an interrupt occurs while interrupt handler is running
and the running interrupt handler handles the event the new IRQ
indicated, after IRQ handler finishes, it will be executed again
because IRQ pending bit is set by the new interrupt but there won't be
anything to process.

Please read the following message for more information.

  http://article.gmane.org/gmane.linux.ide/26012

This patch...

* Removes all spurious IRQ whining from ahci.  Spurious NCQ completion
  detection was completely wrong.  Spurious D2H Register FIS taught us
  that some early drives send spurious D2H Register FIS with I bit set
  while NCQ commands are in progress but none of recent drives does
  that and even the ones which show such behavior can do NCQ fine.

* Kills all NCQ blacklist entries which were added because of spurious
  NCQ completions.  I tracked down each commit and verified all
  removed ones are actually added because of spurious completions.

  WD740ADFD-00NLR1 wasn't deleted but moved upward because the drive
  not only had spurious NCQ completions but also is slow on sequential
  data transfers if NCQ is enabled.

  Maxtor 7V300F0 was added by 0e3dbc01d53940fe10e5a5cfec15ede3e929c918
  from Alan Cox.  I can only find evidences that the drive only had
  troubles with spuruious completions by searching the mailing list.
  This entry needs to be verified and removed if it doesn't have other
  NCQ related problems.

Signed-off-by: Tejun Heo 
Cc: Alan Cox 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: xt_TCPMSS: remove network triggerable WARN_ON

2007-12-14T18:32:00+00:00

[NETFILTER]: xt_TCPMSS: remove network triggerable WARN_ON

[ Upstream commit: 9dc0564e862b1b9a4677dec2c736b12169e03e99 ]

ipv6_skip_exthdr() returns -1 for invalid packets. don't WARN_ON
that.

Signed-off-by: Patrick McHardy 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

XFRM: Fix leak of expired xfrm_states

2007-12-14T18:32:00+00:00

[XFRM]: Fix leak of expired xfrm_states

[ Upstream commit: 5dba4797115c8fa05c1a4d12927a6ae0b33ffc41 ]

The xfrm_timer calls __xfrm_state_delete, which drops the final reference
manually without triggering destruction of the state. Change it to use
xfrm_state_put to add the state to the gc list when we're dropping the
last reference. The timer function may still continue to use the state
safely since the final destruction does a del_timer_sync().

Signed-off-by: Patrick McHardy 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

Revert "Fix SMP poweroff hangs"

2007-12-14T18:32:00+00:00

This reverts the following changeset in 2.6.22.10 that caused a lot of
reported problems.

	From: Mark Lord 

	commit 4047727e5ae33f9b8d2b7766d1994ea6e5ec2991 from upstream

	We need to disable all CPUs other than the boot CPU (usually 0) before
	attempting to power-off modern SMP machines.  This fixes the
	hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's
	new toybox.

	Signed-off-by: Mark Lord 
	Acked-by: Thomas Gleixner 
	Cc: "Rafael J. Wysocki" 
	Signed-off-by: Andrew Morton 
	Signed-off-by: Linus Torvalds 
	Signed-off-by: Greg Kroah-Hartman 

There still is a remaining shutdown problem in 2.6.22 with old APM based
systems, but this fix is not the correct one

Signed-off-by: Greg Kroah-Hartman

knfsd: Validate filehandle type in fsid_source

2007-12-14T18:32:00+00:00

patch b8da0d1c27f144bce999c653467106f3f0d5a308 in mainline.

fsid_source decided where to get the 'fsid' number to
return for a GETATTR based on the type of filehandle.
It can be from the device, from the fsid, or from the
UUID.

It is possible for the filehandle to be inconsistent
with the export information, so make sure the export information
actually has the info implied by the value returned by
fsid_source.

Signed-off-by: Neil Brown 
Cc: "Luiz Fernando N. Capitulino" 
Signed-off-by: "J. Bruce Fields" 
Signed-off-by: Linus Torvalds 
Cc: Oliver Pintr 
Signed-off-by: Greg Kroah-Hartman

BRIDGE: Lost call to br_fdb_fini() in br_init() error path

2007-12-14T18:32:00+00:00

[BRIDGE]: Lost call to br_fdb_fini() in br_init() error path

[ Upstream commit: 17efdd45755c0eb8d1418a1368ef7c7ebbe98c6e ]
 
In case the br_netfilter_init() (or any subsequent call)
fails, the br_fdb_fini() must be called to free the allocated
in br_fdb_init() br_fdb_cache kmem cache.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

DECNET: dn_nl_deladdr() almost always returns no error

2007-12-14T18:32:00+00:00

[DECNET]: dn_nl_deladdr() almost always returns no error

[ Upstream commit: 3ccd86241b277249d5ac08e91eddfade47184520 ]

As far as I see from the err variable initialization
the dn_nl_deladdr() routine was designed to report errors
like "EADDRNOTAVAIL" and probaby "ENODEV".

But the code sets this err to 0 after the first nlmsg_parse
and goes on, returning this 0 in any case.

Signed-off-by: Pavel Emelyanov 
Acked-by: Steven Whitehouse 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

IPV6: Restore IPv6 when MTU is big enough

2007-12-14T18:31:59+00:00

[IPV6]: Restore IPv6 when MTU is big enough

[ Upstream commit: d31c7b8fa303eb81311f27b80595b8d2cbeef950 ]

Avaid provided test application, so bug got fixed.

IPv6 addrconf removes ipv6 inner device from netdev each time cmu
changes and new value is less than IPV6_MIN_MTU (1280 bytes).
When mtu is changed and new value is greater than IPV6_MIN_MTU,
it does not add ipv6 addresses and inner device bac.

This patch fixes that.

Tested with Avaid's application, which works ok now.

Signed-off-by: Evgeniy Polyakov 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman