[00/12] 2.6.24-stable review

[00/12] 2.6.24-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.24-stable release.
There are 12 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.

These patches are sent out with a number of different people on the
Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Thursday, May 1 16:00:00 UTC.  Anything
received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.24.6-rc1.gz
and the diffstat can be found below.


thanks,

the -stable release team


------------------------

 Makefile                              |    2 +-
 arch/x86/kernel/io_apic_32.c          |    1 +
 drivers/isdn/capi/capidrv.c           |    9 +++++----
 drivers/isdn/i4l/isdn_net.c           |    1 +
 drivers/media/video/cx88/cx88-cards.c |    4 ++++
 drivers/media/video/ivtv/ivtv-ioctl.c |    3 ++-
 drivers/net/tehuti.c                  |   15 +++++++++++++++
 drivers/usb/gadget/ether.c            |    1 +
 drivers/usb/serial/usb-serial.c       |    2 ++
 fs/jffs2/erase.c                      |   18 ++++++++----------
 fs/splice.c                           |    2 +-
 include/net/tcp.h                     |    7 +++++--
 12 files changed, 46 insertions(+), 19 deletions(-)

[01/12] splice: use mapping_gfp_mask

[Greg KH]

[-- Attachment #1: splice-use-mapping_gfp_mask.patch --]
[-- Type: text/plain, Size: 1079 bytes --]

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

------------------


upstream commit: 4cd13504652d28e16bf186c6bb2bbb3725369383

The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its
mapping_gfp_mask, to avoid hangs under memory pressure.  But nowadays
it uses splice, usually going through __generic_file_splice_read.  That
must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/splice.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/splice.c
+++ b/fs/splice.c
@@ -314,7 +314,7 @@ __generic_file_splice_read(struct file *
 				break;
 
 			error = add_to_page_cache_lru(page, mapping, index,
-					      GFP_KERNEL);
+						mapping_gfp_mask(mapping));
 			if (unlikely(error)) {
 				page_cache_release(page);
 				if (error == -EEXIST)

-- 

[02/12] fix oops on rmmod capidrv

[Greg KH]

[-- Attachment #1: fix-oops-on-rmmod-capidrv.patch --]
[-- Type: text/plain, Size: 1224 bytes --]

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

------------------

From: Karsten Keil <kkeil@suse.de>

commit eb36f4fc019835cecf0788907f6cab774508087b upstream.

Fix overwriting the stack with the version string
(it is currently 10 bytes + zero) when unloading the
capidrv module. Safeguard against overwriting it
should the version string grow in the future.

Should fix Kernel Bug Tracker Bug 9696.

Signed-off-by: Gerd v. Egidy <gerd.von.egidy@intra2net.com>
Acked-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/isdn/capi/capidrv.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -2332,13 +2332,14 @@ static int __init capidrv_init(void)
 
 static void __exit capidrv_exit(void)
 {
-	char rev[10];
+	char rev[32];
 	char *p;
 
 	if ((p = strchr(revision, ':')) != 0) {
-		strcpy(rev, p + 1);
-		p = strchr(rev, '$');
-		*p = 0;
+		strncpy(rev, p + 1, sizeof(rev));
+		rev[sizeof(rev)-1] = 0;
+		if ((p = strchr(rev, '$')) != 0)
+			*p = 0;
 	} else {
 		strcpy(rev, " ??? ");
 	}

-- 

[03/12] x86: Fix 32-bit x86 MSI-X allocation leakage

[Greg KH]

[-- Attachment #1: x86-fix-32-bit-x86-msi-x-allocation-leakage.patch --]
[-- Type: text/plain, Size: 1278 bytes --]

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

------------------

From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>

commit 9d9ad4b51d2b29b5bbeb4011f5e76f7538119cf9 upstream

This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where
MSI-X vector allocation will eventually fail.  The cause is the new
bit array tracking used vectors is not getting cleared properly on
IRQ destruction on the 32-bit APIC code.

This can be seen easily using the ixgbe 10 GbE driver on multi-core
systems by simply loading and unloading the driver a few times.
Depending on the number of available vectors on the host system, the
MSI-X allocation will eventually fail, and the driver will only be
able to use legacy interrupts.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/io_apic_32.c |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/kernel/io_apic_32.c
+++ b/arch/x86/kernel/io_apic_32.c
@@ -2478,6 +2478,7 @@ void destroy_irq(unsigned int irq)
 	dynamic_irq_cleanup(irq);
 
 	spin_lock_irqsave(&vector_lock, flags);
+	clear_bit(irq_vector[irq], used_vectors);
 	irq_vector[irq] = 0;
 	spin_unlock_irqrestore(&vector_lock, flags);
 }

-- 

[04/12] tehuti: check register size (CVE-2008-1675)

[Greg KH]

[-- Attachment #1: tehuti-check-register-size.patch --]
[-- Type: text/plain, Size: 1457 bytes --]

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

------------------

From: Francois Romieu <romieu@fr.zoreil.com>

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/tehuti.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -625,6 +625,12 @@ static void __init bdx_firmware_endianes
 		s_firmLoad[i] = CPU_CHIP_SWAP32(s_firmLoad[i]);
 }
 
+static int bdx_range_check(struct bdx_priv *priv, u32 offset)
+{
+	return (offset > (u32) (BDX_REGS_SIZE / priv->nic->port_num)) ?
+		-EINVAL : 0;
+}
+
 static int bdx_ioctl_priv(struct net_device *ndev, struct ifreq *ifr, int cmd)
 {
 	struct bdx_priv *priv = ndev->priv;
@@ -646,6 +652,9 @@ static int bdx_ioctl_priv(struct net_dev
 	switch (data[0]) {
 
 	case BDX_OP_READ:
+		error = bdx_range_check(priv, data[1]);
+		if (error < 0)
+			return error;
 		data[2] = READ_REG(priv, data[1]);
 		DBG("read_reg(0x%x)=0x%x (dec %d)\n", data[1], data[2],
 		    data[2]);
@@ -655,6 +664,11 @@ static int bdx_ioctl_priv(struct net_dev
 		break;
 
 	case BDX_OP_WRITE:
+		if (!capable(CAP_NET_ADMIN))
+			return -EPERM;
+		error = bdx_range_check(priv, data[1]);
+		if (error < 0)
+			return error;
 		WRITE_REG(priv, data[1], data[2]);
 		DBG("write_reg(0x%x, 0x%x)\n", data[1], data[2]);
 		break;

-- 

[05/12] tehuti: move ioctl perm check closer to function start (CVE-2008-1675)

[Greg KH]

[-- Attachment #1: tehuti-move-ioctl-perm-check-closer-to-function-start.patch --]
[-- Type: text/plain, Size: 900 bytes --]

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

------------------

From: Jeff Garzik <jeff@garzik.org>

Commit f946dffed6334f08da065a89ed65026ebf8b33b4 upstream

Noticed by davem.

Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/tehuti.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -649,6 +649,9 @@ static int bdx_ioctl_priv(struct net_dev
 		DBG("%d 0x%x 0x%x\n", data[0], data[1], data[2]);
 	}
 
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
 	switch (data[0]) {
 
 	case BDX_OP_READ:
@@ -664,8 +667,6 @@ static int bdx_ioctl_priv(struct net_dev
 		break;
 
 	case BDX_OP_WRITE:
-		if (!capable(CAP_NET_ADMIN))
-			return -EPERM;
 		error = bdx_range_check(priv, data[1]);
 		if (error < 0)
 			return error;

-- 

[06/12] USB: gadget: queue usb USB_CDC_GET_ENCAPSULATED_RESPONSE message

[Greg KH]

[-- Attachment #1: usb-gadget-queue-usb-usb_cdc_get_encapsulated_response-message.patch --]
[-- Type: text/plain, Size: 1100 bytes --]

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

------------------

From: Jan Altenberg <jan.altenberg@linutronix.de>

backport of 41566bcf35a8b23ce4715dadb5acfd1098c1d3e4

commit 0cf4f2de0a0f4100795f38ef894d4910678c74f8 introduced a bug, which
prevents sending an USB_CDC_GET_ENCAPSULATED_RESPONSE message. This
breaks the RNDIS initialization (especially / only Windoze machines
dislike this behavior...).

Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Signed-off-by: Jan Altenberg <jan.altenberg@linutronix.de>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/gadget/ether.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1561,6 +1561,7 @@ done_set_intf:
 				memcpy(req->buf, buf, n);
 				req->complete = rndis_response_complete;
 				rndis_free_response(dev->rndis_config, buf);
+				value = n;
 			}
 			/* else stalls ... spec says to avoid that */
 		}

-- 

[07/12] JFFS2: Fix free space leak with in-band cleanmarkers

[Greg KH]

[-- Attachment #1: jffs2-fix-free-space-leak-with-in-band-cleanmarkers.patch --]
[-- Type: text/plain, Size: 2445 bytes --]

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

------------------

From: David Woodhouse <dwmw2@infradead.org>

We were accounting for the cleanmarker by calling jffs2_link_node_ref()
(without locking!), which adjusted both superblock and per-eraseblock
accounting, subtracting the size of the cleanmarker from {jeb,c}->free_size
and adding it to {jeb,c}->used_size.

But only _then_ were we adding the size of the newly-erased block back
to the superblock counts, and we were adding each of jeb->{free,used}_size
to the corresponding superblock counts. Thus, the size of the cleanmarker
was effectively subtracted from the superblock's free_size _twice_.

Fix this, by always adding a full eraseblock size to c->free_size when
we've erased a block. And call jffs2_link_node_ref() under the proper
lock, while we're at it.

Thanks to Alexander Yurchenko and/or Damir Shayhutdinov for (almost)
pinpointing the problem.

[Backport of commit 014b164e1392a166fe96e003d2f0e7ad2e2a0bb7]

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/jffs2/erase.c |   18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

--- a/fs/jffs2/erase.c
+++ b/fs/jffs2/erase.c
@@ -419,9 +419,6 @@ static void jffs2_mark_erased_block(stru
 			if (jffs2_write_nand_cleanmarker(c, jeb))
 				goto filebad;
 		}
-
-		/* Everything else got zeroed before the erase */
-		jeb->free_size = c->sector_size;
 	} else {
 
 		struct kvec vecs[1];
@@ -449,18 +446,19 @@ static void jffs2_mark_erased_block(stru
 
 			goto filebad;
 		}
-
-		/* Everything else got zeroed before the erase */
-		jeb->free_size = c->sector_size;
-		/* FIXME Special case for cleanmarker in empty block */
-		jffs2_link_node_ref(c, jeb, jeb->offset | REF_NORMAL, c->cleanmarker_size, NULL);
 	}
+	/* Everything else got zeroed before the erase */
+	jeb->free_size = c->sector_size;
 
 	down(&c->erase_free_sem);
 	spin_lock(&c->erase_completion_lock);
+
 	c->erasing_size -= c->sector_size;
-	c->free_size += jeb->free_size;
-	c->used_size += jeb->used_size;
+	c->free_size += c->sector_size;
+
+	/* Account for cleanmarker now, if it's in-band */
+	if (c->cleanmarker_size && !jffs2_cleanmarker_oob(c))
+		jffs2_link_node_ref(c, jeb, jeb->offset | REF_NORMAL, c->cleanmarker_size, NULL);
 
 	jffs2_dbg_acct_sanity_check_nolock(c,jeb);
 	jffs2_dbg_acct_paranoia_check_nolock(c, jeb);

-- 

[09/12] USB: remove broken usb-serial num_endpoints check

[Greg KH]

[-- Attachment #1: usb-remove-broken-usb-serial-num_endpoints-check.patch --]
[-- Type: text/plain, Size: 1363 bytes --]

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

------------------

From: Greg Kroah-Hartman <gregkh@suse.de>

commit: 07c3b1a1001614442c665570942a3107a722c314

The num_interrupt_in, num_bulk_in, and other checks in the usb-serial
code are just wrong, there are too many different devices out there with
different numbers of endpoints.  We need to just be sticking with the
device ids instead of trying to catch this kind of thing.  It broke too
many different devices.

This fixes a large number of usb-serial devices to get them working
properly again.


Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/usb-serial.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -844,6 +844,7 @@ int usb_serial_probe(struct usb_interfac
 	serial->num_interrupt_in = num_interrupt_in;
 	serial->num_interrupt_out = num_interrupt_out;
 
+#if 0
 	/* check that the device meets the driver's requirements */
 	if ((type->num_interrupt_in != NUM_DONT_CARE &&
 				type->num_interrupt_in != num_interrupt_in)
@@ -857,6 +858,7 @@ int usb_serial_probe(struct usb_interfac
 		kfree(serial);
 		return -EIO;
 	}
+#endif
 
 	/* found all that we need */
 	dev_info(&interface->dev, "%s converter detected\n",

-- 

[09/12] USB: remove broken usb-serial num_endpoints check

[Greg KH]

[-- Attachment #1: usb-remove-broken-usb-serial-num_endpoints-check.patch --]
[-- Type: text/plain, Size: 1363 bytes --]

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

------------------

From: Greg Kroah-Hartman <gregkh@suse.de>

commit: 07c3b1a1001614442c665570942a3107a722c314

The num_interrupt_in, num_bulk_in, and other checks in the usb-serial
code are just wrong, there are too many different devices out there with
different numbers of endpoints.  We need to just be sticking with the
device ids instead of trying to catch this kind of thing.  It broke too
many different devices.

This fixes a large number of usb-serial devices to get them working
properly again.


Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/usb-serial.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -844,6 +844,7 @@ int usb_serial_probe(struct usb_interfac
 	serial->num_interrupt_in = num_interrupt_in;
 	serial->num_interrupt_out = num_interrupt_out;
 
+#if 0
 	/* check that the device meets the driver's requirements */
 	if ((type->num_interrupt_in != NUM_DONT_CARE &&
 				type->num_interrupt_in != num_interrupt_in)
@@ -857,6 +858,7 @@ int usb_serial_probe(struct usb_interfac
 		kfree(serial);
 		return -EIO;
 	}
+#endif
 
 	/* found all that we need */
 	dev_info(&interface->dev, "%s converter detected\n",

-- 

[10/12] V4L: Fix VIDIOCGAP corruption in ivtv

[Greg KH]

[-- Attachment #1: v4l-fix-vidiocgap-corruption-in-ivtv.patch --]
[-- Type: text/plain, Size: 1548 bytes --]


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

------------------

From: Alan Cox <alan@lxorguk.ukuu.org.uk>

Frank Bennett reported that ivtv was causing skype to crash. With help
from one of their developers he showed it was a kernel problem.
VIDIOCGCAP copies a name into a fixed length buffer - ivtv uses names
that are too long and does not truncate them so corrupts a few bytes of
the app data area.

Possibly the names also want trimming but for now this should fix the
corruption case.

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
(cherry picked from commit d2b213f7b76f187c4391079c7581d3a08b940133)
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/ivtv/ivtv-ioctl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -727,7 +727,8 @@ int ivtv_v4l2_ioctls(struct ivtv *itv, s
 
 		memset(vcap, 0, sizeof(*vcap));
 		strcpy(vcap->driver, IVTV_DRIVER_NAME);     /* driver name */
-		strcpy(vcap->card, itv->card_name); 	    /* card type */
+		strncpy(vcap->card, itv->card_name,
+				sizeof(vcap->card)-1); 	    /* card type */
 		strcpy(vcap->bus_info, pci_name(itv->dev)); /* bus info... */
 		vcap->version = IVTV_DRIVER_VERSION; 	    /* version */
 		vcap->capabilities = itv->v4l2_cap; 	    /* capabilities */

-- 

[11/12] V4L: cx88: enable radio GPIO correctly

[Greg KH]

[-- Attachment #1: v4l-cx88-enable-radio-gpio-correctly.patch --]
[-- Type: text/plain, Size: 1242 bytes --]


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

------------------

From: Steven Toth <stoth@hauppauge.com>

This patch fixes an issue on the HVR1300, where GPIO is blown away due to
the radio input being undefined, breaking the functionality of the DVB
demodulator and MPEG2 encoder used on the cx8802 mpeg TS port.

This is a minimal patch for 2.6.26 and the -stable series.  This must be
fixed a better way for 2.6.27.

Signed-off-by: Steven Toth <stoth@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
(cherry picked from commit 6b92b3bd7ac91b7e255541f4be9bfd55b12dae41)
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/cx88/cx88-cards.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -1349,6 +1349,10 @@ static const struct cx88_board cx88_boar
 		}},
 		/* fixme: Add radio support */
 		.mpeg           = CX88_MPEG_DVB | CX88_MPEG_BLACKBIRD,
+		.radio = {
+			.type   = CX88_RADIO,
+			.gpio0	= 0xe780,
+		},
 	},
 	[CX88_BOARD_ADSTECH_PTV_390] = {
 		.name           = "ADS Tech Instant Video PCI",

-- 

[12/12] ISDN: Do not validate ISDN net device address prior to interface-up

[Greg KH]

[-- Attachment #1: isdn-do-not-validate-isdn-net-device-address-prior-to-interface-up.patch --]
[-- Type: text/plain, Size: 947 bytes --]

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

------------------

Commit bada339 (Validate device addr prior to interface-up) caused a regression
in the ISDN network code, see: http://bugzilla.kernel.org/show_bug.cgi?id=9923
The trivial fix is to remove the pointer to eth_validate_addr() in the
net_device struct in isdn_net_init().

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/isdn/i4l/isdn_net.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/isdn/i4l/isdn_net.c
+++ b/drivers/isdn/i4l/isdn_net.c
@@ -2010,6 +2010,7 @@ isdn_net_init(struct net_device *ndev)
 	ndev->flags = IFF_NOARP|IFF_POINTOPOINT;
 	ndev->type = ARPHRD_ETHER;
 	ndev->addr_len = ETH_ALEN;
+	ndev->validate_addr = NULL;
 
 	/* for clients with MPPP maybe higher values better */
 	ndev->tx_queue_len = 30;

-- 

Re: [00/12] 2.6.24-stable review

[Jörg-Volker Peetz]

How about this one?

http://lkml.org/lkml/2008/4/7/55

-- 
Regards,
Jörg-Volker.

Re: [00/12] 2.6.24-stable review

[Willy Tarreau]

On Tue, Apr 29, 2008 at 11:27:02PM +0200, Jörg-Volker Peetz wrote:
> How about this one?
> 
> http://lkml.org/lkml/2008/4/7/55

looks good indeed, and needs to be fixed in 2.4 too.
However it's still not in mailine, so the author needs
to ping the stable team when this gets merged (or repost
with stable on a CC line in the commit message, as Greg
recently told me :-))

Willy

Re: [00/12] 2.6.24-stable review

[Darren Salt]

I demand that Jörg-Volker Peetz may or may not have written...

> How about this one?
> http://lkml.org/lkml/2008/4/7/55

And this one? http://lkml.org/lkml/2008/3/13/232
(commit 03c086a747d0b242878eb881971ec61c1555869d)

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less.          BE MORE ENERGY EFFICIENT.

<!-- Message headers are taken from the ussg lkml archive ;-) -->

Re: [stable] [00/12] 2.6.24-stable review

[Greg KH]

On Wed, Apr 30, 2008 at 04:21:44AM +0100, Darren Salt wrote:
> I demand that J??rg-Volker Peetz may or may not have written...
> 
> > How about this one?
> > http://lkml.org/lkml/2008/4/7/55
> 
> And this one? http://lkml.org/lkml/2008/3/13/232
> (commit 03c086a747d0b242878eb881971ec61c1555869d)

Did anyone send it to stable@kernel.org and ask for it to be included?

thanks,

greg k-h

Re: [stable] [00/12] 2.6.24-stable review

[Darren Salt]

I demand that Greg KH may or may not have written...

> On Wed, Apr 30, 2008 at 04:21:44AM +0100, Darren Salt wrote:
>> I demand that J??rg-Volker Peetz may or may not have written...
>>> How about this one?
>>> http://lkml.org/lkml/2008/4/7/55
>> And this one? http://lkml.org/lkml/2008/3/13/232
>> (commit 03c086a747d0b242878eb881971ec61c1555869d)

> Did anyone send it to stable@kernel.org and ask for it to be included?

I sent it to stable@ when I originally submitted the patch. The message ID is
<4F84E87BA4%linux@youmustbejoking.demon.co.uk>.

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Let's keep the pound sterling

You will triumph over your enemy.

Re: [stable] [00/12] 2.6.24-stable review

[Greg KH]

On Fri, May 02, 2008 at 04:24:31PM +0100, Darren Salt wrote:
> I demand that Greg KH may or may not have written...
> 
> > On Wed, Apr 30, 2008 at 04:21:44AM +0100, Darren Salt wrote:
> >> I demand that J??rg-Volker Peetz may or may not have written...
> >>> How about this one?
> >>> http://lkml.org/lkml/2008/4/7/55
> >> And this one? http://lkml.org/lkml/2008/3/13/232
> >> (commit 03c086a747d0b242878eb881971ec61c1555869d)
> 
> > Did anyone send it to stable@kernel.org and ask for it to be included?
> 
> I sent it to stable@ when I originally submitted the patch. The message ID is
> <4F84E87BA4%linux@youmustbejoking.demon.co.uk>.

Ok, I see it now.

In it you did not mention if this change was already in Linus's tree,
and if so, what git id it was.  As you sent it primarily to lkml, I
assumed that it was not upstream at this time, hence I did not apply it.

As 2.6.24 is pretty much not being maintained anymore, I don't think
this is an issue anymore :)

thanks,

greg k-h