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
[email protected].
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...)
-stable review patch. If anyone has any objections, please let us know.
----
From: Andres Salomon <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 */
-stable review patch. If anyone has any objections, please let us know.
----
From: "David S. Miller" <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
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;
}
-stable review patch. If anyone has any objections, please let us know.
----
From: Ralf Baechle DL5RB <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- 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)
-stable review patch. If anyone has any objections, please let us know.
----
From: Krzysztof Halasa <[email protected]>
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 <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- 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);
}
-stable review patch. If anyone has any objections, please let us know.
----
From: Stephen Hemminger <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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)))
-stable review patch. If anyone has any objections, please let us know.
----
From: Ralf Baechle <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- 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;
}
-stable review patch. If anyone has any objections, please let us know.
----
From: Daniel Drake <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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;
}
-stable review patch. If anyone has any objections, please let us know.
----
From: Andres Salomon <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- 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);
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/10 18:20:44-08:00 [email protected]
# [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
#
# Signed-off-by: Patrick McHardy <[email protected]>
# Signed-off-by: David S. Miller <[email protected]>
#
# net/ipv4/fib_hash.c
# 2005/03/10 18:20:30-08:00 [email protected] +11 -1
# [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
#
# Signed-off-by: Patrick McHardy <[email protected]>
# Signed-off-by: David S. Miller <[email protected]>
#
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;
}
-stable review patch. If anyone has any objections, please let us know.
----
From: Hugh Dickins <[email protected]>
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 <[email protected]>
Acked-by: Roland McGrath <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
--- 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;
}
* Patrick McHardy ([email protected]) 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
Chris Wright wrote:
>
> From: Andres Salomon <[email protected]>
>
> 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 [email protected]
========================================================================
* Ian Pilcher ([email protected]) wrote:
> Chris Wright wrote:
> >
> >From: Andres Salomon <[email protected]>
> >
> >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
Chris Wright wrote:
> * Ian Pilcher ([email protected]) 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 [email protected]
========================================================================
Ian Pilcher wrote:
> Chris Wright wrote:
>
>>
>> From: Andres Salomon <[email protected]>
>>
>> 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