[0/9] -stable review

[0/9] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.11.5 release.  There
are 9 patches in this series, all will be posted as a response to this one.
If anyone has any issues with these being applied, please let us know.  If
anyone is a maintainer of the proper subsystem, and wants to add a
Signed-off-by: line to the patch, please respond with it.

If you wish to be added or removed from the reviewer list please email
stable@kernel.org.

Responses should be made by Fri, March 18, 23:00 UTC.  Anything received after
that time, might be too late.

thanks,

the -stable release team (i.e. the ones wearing the joker hat in the corner...)

[1/9] [ALSA] Fix stereo mutes on Surround volume control

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Daniel Drake <dsd@gentoo.org>

As of 2.6.11, I have no output out of the rear right speaker of my 4.1 
surround sound setup. I am using snd-intel8x0 based on a Realtek ALC650F chip 
on an nvidia motherboard.

A gentoo user with completely different hardware also ran into this:
http://bugs.gentoo.org/84276

2.6.11-mm3 fixes this problem and I've identified the specific fix, which is 
already in the ALSA development tree. An ALSA developer asked me to submit the 
fix for 2.6.11.x when I'd found it, so here it is :)

--
AC97 Codec
Fix stereo mutes on Surround volume control.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff -Naru a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c
--- a/sound/pci/ac97/ac97_codec.c	2005-03-14 08:24:04 -08:00
+++ b/sound/pci/ac97/ac97_codec.c	2005-03-14 08:24:04 -08:00
@@ -1184,7 +1184,7 @@
 /*
  * create mute switch(es) for normal stereo controls
  */
-static int snd_ac97_cmute_new(snd_card_t *card, char *name, int reg, ac97_t *ac97)
+static int snd_ac97_cmute_new_stereo(snd_card_t *card, char *name, int reg, int check_stereo, ac97_t *ac97)
 {
 	snd_kcontrol_t *kctl;
 	int err;
@@ -1195,7 +1195,7 @@
 
 	mute_mask = 0x8000;
 	val = snd_ac97_read(ac97, reg);
-	if (ac97->flags & AC97_STEREO_MUTES) {
+	if (check_stereo || (ac97->flags & AC97_STEREO_MUTES)) {
 		/* check whether both mute bits work */
 		val1 = val | 0x8080;
 		snd_ac97_write(ac97, reg, val1);
@@ -1253,7 +1253,7 @@
 /*
  * create a mute-switch and a volume for normal stereo/mono controls
  */
-static int snd_ac97_cmix_new(snd_card_t *card, const char *pfx, int reg, ac97_t *ac97)
+static int snd_ac97_cmix_new_stereo(snd_card_t *card, const char *pfx, int reg, int check_stereo, ac97_t *ac97)
 {
 	int err;
 	char name[44];
@@ -1264,7 +1264,7 @@
 
 	if (snd_ac97_try_bit(ac97, reg, 15)) {
 		sprintf(name, "%s Switch", pfx);
-		if ((err = snd_ac97_cmute_new(card, name, reg, ac97)) < 0)
+		if ((err = snd_ac97_cmute_new_stereo(card, name, reg, check_stereo, ac97)) < 0)
 			return err;
 	}
 	check_volume_resolution(ac97, reg, &lo_max, &hi_max);
@@ -1276,6 +1276,8 @@
 	return 0;
 }
 
+#define snd_ac97_cmix_new(card, pfx, reg, ac97)	snd_ac97_cmix_new_stereo(card, pfx, reg, 0, ac97)
+#define snd_ac97_cmute_new(card, name, reg, ac97)	snd_ac97_cmute_new_stereo(card, name, reg, 0, ac97)
 
 static unsigned int snd_ac97_determine_spdif_rates(ac97_t *ac97);
 
@@ -1326,7 +1328,8 @@
 
 	/* build surround controls */
 	if (snd_ac97_try_volume_mix(ac97, AC97_SURROUND_MASTER)) {
-		if ((err = snd_ac97_cmix_new(card, "Surround Playback", AC97_SURROUND_MASTER, ac97)) < 0)
+		/* Surround Master (0x38) is with stereo mutes */
+		if ((err = snd_ac97_cmix_new_stereo(card, "Surround Playback", AC97_SURROUND_MASTER, 1, ac97)) < 0)
 			return err;
 	}
 

[2/9] Possible AMD8111e free irq issue

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

---- 

From: Andres Salomon <dilinger@debian.org>

It seems to me that if in the amd8111e_open() fuction dev->irq isn't
zero and the irq request succeeds it might not get released anymore.

Specifically, on failure of the amd8111e_restart() call the function
returns -ENOMEM without releasing the irq. The amd8111e_restart()
function can fail because of various pci_alloc_consistent() and
dev_alloc_skb() calls in amd8111e_init_ring() which is being
called by amd8111e_restart.

1374     if(dev->irq ==0 || request_irq(dev->irq, amd8111e_interrupt, SA_SHIRQ,
1375                      dev->name, dev))
1376         return -EAGAIN;

Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff -Naru a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
--- a/drivers/net/amd8111e.c	2005-03-09 20:29:47 -08:00
+++ b/drivers/net/amd8111e.c	2005-03-09 20:29:47 -08:00
@@ -1381,6 +1381,8 @@
 
 	if(amd8111e_restart(dev)){
 		spin_unlock_irq(&lp->lock);
+		if (dev->irq)
+			free_irq(dev->irq, dev);
 		return -ENOMEM;
 	}
 	/* Start ipg timer */

Re: [2/9] Possible AMD8111e free irq issue

[Ian Pilcher]

Chris Wright wrote:
> 
> From: Andres Salomon <dilinger@debian.org>
> 
> It seems to me that if in the amd8111e_open() fuction dev->irq isn't
> zero and the irq request succeeds it might not get released anymore.
> 

Based on the wording above, I can't help wondering if this fixes a
problem that anyone is actually seeing.

-- 
========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

Re: [2/9] Possible AMD8111e free irq issue

[Chris Wright]

* Ian Pilcher (i.pilcher@comcast.net) wrote:
> Chris Wright wrote:
> >
> >From: Andres Salomon <dilinger@debian.org>
> >
> >It seems to me that if in the amd8111e_open() fuction dev->irq isn't
> >zero and the irq request succeeds it might not get released anymore.
> 
> Based on the wording above, I can't help wondering if this fixes a
> problem that anyone is actually seeing.

I had same hesitation, but it's easy to see how lowmem could trigger
this latent bug (so it's not a highly theoretical race condition, for
example), and the fix is both quite simple and accepted upstream already.
Anyway that's what the review cycle is for, it can be rejected.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [2/9] Possible AMD8111e free irq issue

[Ian Pilcher]

Chris Wright wrote:
> * Ian Pilcher (i.pilcher@comcast.net) wrote:
>>
>>Based on the wording above, I can't help wondering if this fixes a
>>problem that anyone is actually seeing.
> 
> 
> I had same hesitation, but it's easy to see how lowmem could trigger
> this latent bug (so it's not a highly theoretical race condition, for
> example), and the fix is both quite simple and accepted upstream already.
> Anyway that's what the review cycle is for, it can be rejected.
> 

Well, what does the current draft of the stable series rules say?

-- 
========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

Re: [2/9] Possible AMD8111e free irq issue

[Jeff Garzik]

Ian Pilcher wrote:
> Chris Wright wrote:
> 
>>
>> From: Andres Salomon <dilinger@debian.org>
>>
>> It seems to me that if in the amd8111e_open() fuction dev->irq isn't
>> zero and the irq request succeeds it might not get released anymore.
>>
> 
> Based on the wording above, I can't help wondering if this fixes a
> problem that anyone is actually seeing.


Maybe the wording is wrong, but the patch fixes an obvious 
leak-on-error.  Allocations in amd8111e_init_ring() could certainly fail.

	Jeff

[3/9] [IPSEC]: Fix __xfrm_find_acq_byseq()

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: "David S. Miller" <davem@davemloft.net>

This function, as it's name implies, is supposed to only
return IPSEC objects which are in the XFRM_STATE_ACQ
("acquire") state.  But it returns any object with the
matching sequence number.

This is wrong and confuses IPSEC daemons to no end.

[XFRM]: xfrm_find_acq_byseq should only return XFRM_STATE_ACQ states.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>

diff -Nru a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
--- a/net/xfrm/xfrm_state.c	2005-03-16 14:27:04 -08:00
+++ b/net/xfrm/xfrm_state.c	2005-03-16 14:27:04 -08:00
@@ -609,7 +609,7 @@
 
 	for (i = 0; i < XFRM_DST_HSIZE; i++) {
 		list_for_each_entry(x, xfrm_state_bydst+i, bydst) {
-			if (x->km.seq == seq) {
+			if (x->km.seq == seq && x->km.state == XFRM_STATE_ACQ) {
 				xfrm_state_hold(x);
 				return x;
 			}

[4/9] NetROM locking

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Ralf Baechle <ralf@linux-mips.org>

Fix deadlock in NetROM due to double locking.  I was sent the patch by
Alan and have doublechecked it.  This bug hits Net/ROM users really hard.
It's accepted by DaveM - but just too late to make it into 2.6.11.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- bk-afu.orig/net/netrom/nr_in.c	2005-02-05 22:16:25.553987776 +0000
+++ bk-afu/net/netrom/nr_in.c	2005-02-05 22:16:25.555987472 +0000
@@ -74,7 +74,6 @@
 static int nr_state1_machine(struct sock *sk, struct sk_buff *skb,
 	int frametype)
 {
-	bh_lock_sock(sk);
 	switch (frametype) {
 	case NR_CONNACK: {
 		nr_cb *nr = nr_sk(sk);
@@ -103,8 +102,6 @@
 	default:
 		break;
 	}
-	bh_unlock_sock(sk);
-
 	return 0;
 }
 
@@ -116,7 +113,6 @@
 static int nr_state2_machine(struct sock *sk, struct sk_buff *skb,
 	int frametype)
 {
-	bh_lock_sock(sk);
 	switch (frametype) {
 	case NR_CONNACK | NR_CHOKE_FLAG:
 		nr_disconnect(sk, ECONNRESET);
@@ -132,8 +128,6 @@
 	default:
 		break;
 	}
-	bh_unlock_sock(sk);
-
 	return 0;
 }
 
@@ -154,7 +148,6 @@
 	nr = skb->data[18];
 	ns = skb->data[17];
 
-	bh_lock_sock(sk);
 	switch (frametype) {
 	case NR_CONNREQ:
 		nr_write_internal(sk, NR_CONNACK);
@@ -265,8 +258,6 @@
 	default:
 		break;
 	}
-	bh_unlock_sock(sk);
-
 	return queued;
 }
 

[5/9] [TUN] Fix check for underflow

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Stephen Hemminger <shemminger@osdl.org>

http://bugme.osdl.org/show_bug.cgi?id=4279
Summary: When I try to start vpnc the net/core/skbuff.c:91 crash

This check is wrong, gcc optimizes it away:

                if ((len -= sizeof(pi)) > len)
			return -EINVAL;

This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI
isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or
1 byte. skb_reserve tries to reserve 2 bytes and things explode in
skb_put.

[TUN]: Fix check for underflow

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c
--- a/drivers/net/tun.c	2005-03-04 19:41:56 +01:00
+++ b/drivers/net/tun.c	2005-03-04 19:41:56 +01:00
@@ -229,7 +229,7 @@
 	size_t len = count;
 
 	if (!(tun->flags & TUN_NO_PI)) {
-		if ((len -= sizeof(pi)) > len)
+		if ((len -= sizeof(pi)) > count)
 			return -EINVAL;
 
 		if(memcpy_fromiovec((void *)&pi, iv, sizeof(pi)))

Re: [5/9] [TUN] Fix check for underflow

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Chris Wright wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> 

I agree to both patches and additionally propose this one.
It fixes a crash when reading /proc/net/route (netstat -rn)
while routes are changed. I've seen two bugreports of users
beeing hit by this bug, one for 2.6.10, one for 2.6.11.

Regards
Patrick

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1266 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/03/10 18:20:44-08:00 kaber@trash.net 
#   [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
#   
#   Signed-off-by: Patrick McHardy <kaber@trash.net>
#   Signed-off-by: David S. Miller <davem@davemloft.net>
# 
# net/ipv4/fib_hash.c
#   2005/03/10 18:20:30-08:00 kaber@trash.net +11 -1
#   [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
#   
#   Signed-off-by: Patrick McHardy <kaber@trash.net>
#   Signed-off-by: David S. Miller <davem@davemloft.net>
# 
diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
--- a/net/ipv4/fib_hash.c	2005-03-17 00:58:42 +01:00
+++ b/net/ipv4/fib_hash.c	2005-03-17 00:58:42 +01:00
@@ -919,13 +919,23 @@
 	return fa;
 }
 
+static struct fib_alias *fib_get_idx(struct seq_file *seq, loff_t pos)
+{
+	struct fib_alias *fa = fib_get_first(seq);
+
+	if (fa)
+		while (pos && (fa = fib_get_next(seq)))
+			--pos;
+	return pos ? NULL : fa;
+}
+
 static void *fib_seq_start(struct seq_file *seq, loff_t *pos)
 {
 	void *v = NULL;
 
 	read_lock(&fib_hash_lock);
 	if (ip_fib_main_table)
-		v = *pos ? fib_get_next(seq) : SEQ_START_TOKEN;
+		v = *pos ? fib_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
 	return v;
 }
 

Re: [5/9] [TUN] Fix check for underflow

[Chris Wright]

* Patrick McHardy (kaber@trash.net) wrote:
> Chris Wright wrote:
> >-stable review patch.  If anyone has any objections, please let us know.
> >
> 
> I agree to both patches and additionally propose this one.
> It fixes a crash when reading /proc/net/route (netstat -rn)
> while routes are changed. I've seen two bugreports of users
> beeing hit by this bug, one for 2.6.10, one for 2.6.11.

Thank you Patrick, I think we can sneak this in as 10/9 ;-)

thanks,
-chris

[6/9] tasklist left locked

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Hugh Dickins <hugh@veritas.com>

On 4-way SMP, about one reboot in twenty hangs while killing processes:
exit needs exclusive tasklist_lock, but something still holds read_lock.
do_signal_stop race case misses unlock, and fixing it fixes the symptom.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>

--- 2.6.11/kernel/signal.c	2005-03-02 07:38:56.000000000 +0000
+++ linux/kernel/signal.c	2005-03-16 18:10:17.000000000 +0000
@@ -1728,6 +1728,7 @@ do_signal_stop(int signr)
 			 * with another processor delivering a stop signal,
 			 * then the SIGCONT that wakes us up should clear it.
 			 */
+			read_unlock(&tasklist_lock);
 			return 0;
 		}
 

[7/9] Timercode race in AX.25

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Ralf Baechle DL5RB <ralf@linux-mips.org>

When destroying a socket ax25_destroy_socket tries to stop the protocol's
T1 timer before freeing the memory.  If things are just right using the
non-sync variant of del_timer means the timer will continue to run even
after the del_timer because it's adding itself again which is likely to
result in a crash when the timer is executed again a few seconds later.

del_timer_sync can be expensive, so I don't want this one to go into 2.6
mainline where I'll try to cook something that is less intrusive than
regular calls to del_timer_sync.

Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- bk-afu.orig/net/ax25/ax25_timer.c	2005-03-08 13:54:06.000000000 +0000
+++ bk-afu/net/ax25/ax25_timer.c	2005-03-08 16:43:34.790532976 +0000
@@ -106,7 +106,7 @@
 
 void ax25_stop_t1timer(ax25_cb *ax25)
 {
-	del_timer(&ax25->t1timer);
+	del_timer_sync(&ax25->t1timer);
 }
 
 void ax25_stop_t2timer(ax25_cb *ax25)

[8/9] Possible VIA-Rhine free irq issue

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Andres Salomon <dilinger@debian.org>

It seems to me that in the VIA Rhine device driver the requested irq might
not be freed in case the alloc_ring() function fails. alloc_ring()
can fail with a ENOMEM return value because of possible
pci_alloc_consistent() failures.
   
Updated to CodingStyle.

Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- 1.89/drivers/net/via-rhine.c	2005-01-10 08:52:27 -08:00
+++ edited/drivers/net/via-rhine.c	2005-03-11 15:18:25 -08:00
@@ -1197,8 +1197,10 @@ static int rhine_open(struct net_device 
 		       dev->name, rp->pdev->irq);
 
 	rc = alloc_ring(dev);
-	if (rc)
+	if (rc) {
+		free_irq(rp->pdev->irq, dev);
 		return rc;
+	}
 	alloc_rbufs(dev);
 	alloc_tbufs(dev);
 	rhine_chip_reset(dev);

[9/9] Fix kernel panic on receive with WAN Hitachi SCA HD6457x

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.

----

From: Krzysztof Halasa <khc@pm.waw.pl>

Another patch for 2.6.11.x: already in main tree, fixes kernel panic on
receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101, PCI200SYN.
The attached patch fixes NULL pointer dereference on RX.

Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- linux/drivers/net/wan/hd6457x.c	28 Oct 2004 06:16:08 -0000	1.15
+++ linux/drivers/net/wan/hd6457x.c	1 Mar 2005 00:58:08 -0000
@@ -315,7 +315,7 @@
 #endif
 	stats->rx_packets++;
 	stats->rx_bytes += skb->len;
-	skb->dev->last_rx = jiffies;
+	dev->last_rx = jiffies;
 	skb->protocol = hdlc_type_trans(skb, dev);
 	netif_rx(skb);
 }