linux-toradex.git, branch v2.6.23.10 Linux kernel for Apalis and Colibri modules Linux 2.6.23.10 2007-12-14T18:01:59+00:00 Greg Kroah-Hartman gregkh@suse.de 2007-12-14T18:01:59+00:00 3d4f61b2f111e894534710e2c668410316339dee 






XFS: Make xfsbufd threads freezable
2007-12-14T17:51:17+00:00

Rafael J. Wysocki
rjw@sisk.pl

2007-12-07T03:09:02+00:00

d112668e7fc0e25e33c774e33c66b4de02c85282

patch 978c7b2ff49597ab76ff7529a933bd366941ac25 in mainline

Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69
that did not introduce the necessary call to set_freezable() in
xfs/linux-2.6/xfs_buf.c .

SGI-PV: 974224
SGI-Modid: xfs-linux-melb:xfs-kern:30203a

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Cc: Oliver Pintr <oliver.pntr@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






patch 978c7b2ff49597ab76ff7529a933bd366941ac25 in mainline

Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69
that did not introduce the necessary call to set_freezable() in
xfs/linux-2.6/xfs_buf.c .

SGI-PV: 974224
SGI-Modid: xfs-linux-melb:xfs-kern:30203a

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Cc: Oliver Pintr <oliver.pntr@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








BRIDGE: Properly dereference the br_should_route_hook
2007-12-14T17:51:17+00:00

Pavel Emelyanov
xemul@openvz.org

2007-12-13T04:57:24+00:00

3f69a38c97c5864e6e01a584e6389eb4aa637706

[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 <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[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 <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








NETFILTER: xt_TCPMSS: remove network triggerable WARN_ON
2007-12-14T17:51:16+00:00

Patrick McHardy
kaber@trash.net

2007-12-13T04:42:34+00:00

5de724036762b8a4c03c4979f19b01a98529a601

[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 <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[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 <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








XFRM: Fix leak of expired xfrm_states
2007-12-14T17:51:16+00:00

Patrick McHardy
kaber@trash.net

2007-11-29T12:07:57+00:00

9aa67118c51d60af7b048be6e4a8b8bad2191555

[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 <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[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 <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








libata: kill spurious NCQ completion detection
2007-12-14T17:51:15+00:00

Tejun Heo
htejun@gmail.com

2007-12-08T00:25:31+00:00

9ee303ef4e582f2f8b4f08e58ced6ba44debfb64

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 <htejun@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






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 <htejun@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








NETFILTER: fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK
2007-12-14T17:51:08+00:00

Jan Engelhardt
jengelh@computergmbh.de

2007-12-11T01:39:40+00:00

3e3deae8d7a9e5b73804dca55252bcf3aea19504

[NETFILTER]: fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

[ Upstream commit: 67b4af297033f5f65999885542f95ba7b562848a ]

Fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

When xt_CONNMARK is used outside the mangle table and the user specified
"--restore-mark", the connmark_tg_check() function will (correctly)
error out, but (incorrectly) forgets to release the L3 conntrack module.
Same for xt_CONNSECMARK.

Fix is to move the call to acquire the L3 module after the basic
constraint checks.

Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[NETFILTER]: fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

[ Upstream commit: 67b4af297033f5f65999885542f95ba7b562848a ]

Fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

When xt_CONNMARK is used outside the mangle table and the user specified
"--restore-mark", the connmark_tg_check() function will (correctly)
error out, but (incorrectly) forgets to release the L3 conntrack module.
Same for xt_CONNSECMARK.

Fix is to move the call to acquire the L3 module after the basic
constraint checks.

Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








UNIX: EOF on non-blocking SOCK_SEQPACKET
2007-12-14T17:51:07+00:00

Florian Zumbiehl
florz@florz.de

2007-12-11T01:39:39+00:00

5b5581b721cdc76fe1fe8f89f22ae613198acdbd

[UNIX]: EOF on non-blocking SOCK_SEQPACKET

[ Upstream commit: 0a11225887fe6cbccd882404dc36ddc50f47daf9 ]

I am not absolutely sure whether this actually is a bug (as in: I've got
no clue what the standards say or what other implementations do), but at
least I was pretty surprised when I noticed that a recv() on a
non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
oriented, after all) where the remote end has closed the connection
returned -1 (EAGAIN) rather than 0 to indicate end of file.

This is a test case:

| #include <sys/types.h>
| #include <unistd.h>
| #include <sys/socket.h>
| #include <sys/un.h>
| #include <fcntl.h>
| #include <string.h>
| #include <stdlib.h>
|
| int main(){
| 	int sock;
| 	struct sockaddr_un addr;
| 	char buf[4096];
| 	int pfds[2];
|
| 	pipe(pfds);
| 	sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
| 	addr.sun_family=AF_UNIX;
| 	strcpy(addr.sun_path,"/tmp/foobar_testsock");
| 	bind(sock,(struct sockaddr *)&addr,sizeof(addr));
| 	listen(sock,1);
| 	if(fork()){
| 		close(sock);
| 		sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
| 		connect(sock,(struct sockaddr *)&addr,sizeof(addr));
| 		fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
| 		close(pfds[1]);
| 		read(pfds[0],buf,sizeof(buf));
| 		recv(sock,buf,sizeof(buf),0); // <-- this one
| 	}else accept(sock,NULL,NULL);
| 	exit(0);
| }

If you try it, make sure /tmp/foobar_testsock doesn't exist.

The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a
patch that fixes that.

Signed-off-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[UNIX]: EOF on non-blocking SOCK_SEQPACKET

[ Upstream commit: 0a11225887fe6cbccd882404dc36ddc50f47daf9 ]

I am not absolutely sure whether this actually is a bug (as in: I've got
no clue what the standards say or what other implementations do), but at
least I was pretty surprised when I noticed that a recv() on a
non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
oriented, after all) where the remote end has closed the connection
returned -1 (EAGAIN) rather than 0 to indicate end of file.

This is a test case:

| #include <sys/types.h>
| #include <unistd.h>
| #include <sys/socket.h>
| #include <sys/un.h>
| #include <fcntl.h>
| #include <string.h>
| #include <stdlib.h>
|
| int main(){
| 	int sock;
| 	struct sockaddr_un addr;
| 	char buf[4096];
| 	int pfds[2];
|
| 	pipe(pfds);
| 	sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
| 	addr.sun_family=AF_UNIX;
| 	strcpy(addr.sun_path,"/tmp/foobar_testsock");
| 	bind(sock,(struct sockaddr *)&addr,sizeof(addr));
| 	listen(sock,1);
| 	if(fork()){
| 		close(sock);
| 		sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
| 		connect(sock,(struct sockaddr *)&addr,sizeof(addr));
| 		fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
| 		close(pfds[1]);
| 		read(pfds[0],buf,sizeof(buf));
| 		recv(sock,buf,sizeof(buf),0); // <-- this one
| 	}else accept(sock,NULL,NULL);
| 	exit(0);
| }

If you try it, make sure /tmp/foobar_testsock doesn't exist.

The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a
patch that fixes that.

Signed-off-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








TCP: illinois: Incorrect beta usage
2007-12-14T17:51:07+00:00

Stephen Hemminger
shemminger@linux-foundation.org

2007-12-11T01:39:37+00:00

931c8cbed400a72c0da0756594154504b4634a2a

[TCP] illinois: Incorrect beta usage

[ Upstream commit: a357dde9df33f28611e6a3d4f88265e39bcc8880 ]

Lachlan Andrew observed that my TCP-Illinois implementation uses the
beta value incorrectly:
The parameter  beta  in the paper specifies the amount to decrease
*by*:  that is, on loss,
 W <-  W -  beta*W
but in   tcp_illinois_ssthresh() uses  beta  as the amount
to decrease  *to*: W <- beta*W

This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
hurting performance. Note: since the base beta value is .5, it has no
impact on a congested network.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[TCP] illinois: Incorrect beta usage

[ Upstream commit: a357dde9df33f28611e6a3d4f88265e39bcc8880 ]

Lachlan Andrew observed that my TCP-Illinois implementation uses the
beta value incorrectly:
The parameter  beta  in the paper specifies the amount to decrease
*by*:  that is, on loss,
 W <-  W -  beta*W
but in   tcp_illinois_ssthresh() uses  beta  as the amount
to decrease  *to*: W <- beta*W

This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
hurting performance. Note: since the base beta value is .5, it has no
impact on a congested network.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








IPV6: Restore IPv6 when MTU is big enough
2007-12-14T17:51:06+00:00

Evgeniy Polyakov
johnpol@2ka.mipt.ru

2007-12-11T01:39:34+00:00

978cf44ec452e8fa359b2562a98977d0f76a5b6a

[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 <johnpol@2ka.mipt.ru>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






[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 <johnpol@2ka.mipt.ru>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>