[patch 00/23] -stable review

[patch 00/23] -stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.17.8 release.
There are 23 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 Sunday, August 6, 05:00:00 UTC.  Anything
received after that time might be too late.

I've also posted a roll-up patch with all changes in it if people want
to test it out.  It can be found at:

	kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz

thanks,

the -stable release team

[patch 01/23] PCI: fix issues with extended conf space when MMCONFIG disabled because of e820

[Greg KH]

[-- Attachment #1: pci-fix-issues-with-extended-conf-space-when-mmconfig-disabled-because-of-e820.patch --]
[-- Type: text/plain, Size: 4208 bytes --]

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

------------------
From: Chuck Ebbert <76306.1226@compuserve.com>

On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:
> Anyways I would say that if the BIOS can't get MCFG right then
> it's likely not been validated on that board and shouldn't be used.

According to Petr Vandrovec:

 ... "What is important (and checked) is address of MMCONFIG reported by MCFG
 table...  Unfortunately code does not bother with printing that address :-(

 "Another problem is that code has hardcoded that MMCONFIG area is 256MB large.
 Unfortunately for the code PCI specification allows any power of two between 2MB
 and 256MB if vendor knows that such amount of busses (from 2 to 128) will be
 sufficient for system.  With notebook it is quite possible that not full 8 bits
 are implemented for MMCONFIG bus number."

So here is a patch.  Unfortunately my system still fails the test because
it doesn't reserve any part of the MMCONFIG area, but this may fix others.

Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
(256MB) even though only 2MB is checked... but 2.6.16 had no check at all
so it is still better.

PCI: reduce size of x86 MMCONFIG reserved area check

1.  Print the address of the MMCONFIG area when the test for that area
    being reserved fails.

2.  Only check if the first 2MB is reserved, as that is the minimum.

Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/i386/pci/mmconfig.c   |    9 ++++++---
 arch/x86_64/pci/mmconfig.c |   13 +++++++++----
 2 files changed, 15 insertions(+), 7 deletions(-)

--- linux-2.6.17.7.orig/arch/i386/pci/mmconfig.c
+++ linux-2.6.17.7/arch/i386/pci/mmconfig.c
@@ -15,7 +15,9 @@
 #include <asm/e820.h>
 #include "pci.h"
 
-#define MMCONFIG_APER_SIZE (256*1024*1024)
+/* aperture is up to 256MB but BIOS may reserve less */
+#define MMCONFIG_APER_MIN	(2 * 1024*1024)
+#define MMCONFIG_APER_MAX	(256 * 1024*1024)
 
 /* Assume systems with more busses have correct MCFG */
 #define MAX_CHECK_BUS 16
@@ -197,9 +199,10 @@ void __init pci_mmcfg_init(void)
 		return;
 
 	if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
-			pci_mmcfg_config[0].base_address + MMCONFIG_APER_SIZE,
+			pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
 			E820_RESERVED)) {
-		printk(KERN_ERR "PCI: BIOS Bug: MCFG area is not E820-reserved\n");
+		printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not E820-reserved\n",
+				pci_mmcfg_config[0].base_address);
 		printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
 		return;
 	}
--- linux-2.6.17.7.orig/arch/x86_64/pci/mmconfig.c
+++ linux-2.6.17.7/arch/x86_64/pci/mmconfig.c
@@ -13,7 +13,10 @@
 
 #include "pci.h"
 
-#define MMCONFIG_APER_SIZE (256*1024*1024)
+/* aperture is up to 256MB but BIOS may reserve less */
+#define MMCONFIG_APER_MIN	(2 * 1024*1024)
+#define MMCONFIG_APER_MAX	(256 * 1024*1024)
+
 /* Verify the first 16 busses. We assume that systems with more busses
    get MCFG right. */
 #define MAX_CHECK_BUS 16
@@ -175,9 +178,10 @@ void __init pci_mmcfg_init(void)
 		return;
 
 	if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
-			pci_mmcfg_config[0].base_address + MMCONFIG_APER_SIZE,
+			pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
 			E820_RESERVED)) {
-		printk(KERN_ERR "PCI: BIOS Bug: MCFG area is not E820-reserved\n");
+		printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not E820-reserved\n",
+				pci_mmcfg_config[0].base_address);
 		printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
 		return;
 	}
@@ -190,7 +194,8 @@ void __init pci_mmcfg_init(void)
 	}
 	for (i = 0; i < pci_mmcfg_config_num; ++i) {
 		pci_mmcfg_virt[i].cfg = &pci_mmcfg_config[i];
-		pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address, MMCONFIG_APER_SIZE);
+		pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address,
+							 MMCONFIG_APER_MAX);
 		if (!pci_mmcfg_virt[i].virt) {
 			printk("PCI: Cannot map mmconfig aperture for segment %d\n",
 			       pci_mmcfg_config[i].pci_segment_group_number);

--

[patch 02/23] Dont allow chmod() on the /proc/<pid>/ files

[Greg KH]

[-- Attachment #1: don-t-allow-chmod-on-the-proc-pid-files.patch --]
[-- Type: text/plain, Size: 3794 bytes --]

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

------------------
From: Marcel Holtmann <marcel@holtmann.org>

Don't allow chmod() on the /proc/<pid>/ files

This just turns off chmod() on the /proc/<pid>/ files, since there is no
good reason to allow it, and had we disallowed it originally, the nasty
/proc race exploit wouldn't have been possible.

The other patches already fixed the problem chmod() could cause, so this
is really just some final mop-up..

This particular version is based off a patch by Eugene and Marcel which
had much better naming than my original equivalent one.

Signed-off-by: Eugene Teo <eteo@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/proc/base.c |   33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

--- linux-2.6.17.7.orig/fs/proc/base.c
+++ linux-2.6.17.7/fs/proc/base.c
@@ -596,6 +596,27 @@ static int proc_permission(struct inode 
 	return proc_check_root(inode);
 }
 
+static int proc_setattr(struct dentry *dentry, struct iattr *attr)
+{
+	int error;
+	struct inode *inode = dentry->d_inode;
+
+	if (attr->ia_valid & ATTR_MODE)
+		return -EPERM;
+
+	error = inode_change_ok(inode, attr);
+	if (!error) {
+		error = security_inode_setattr(dentry, attr);
+		if (!error)
+			error = inode_setattr(inode, attr);
+	}
+	return error;
+}
+
+static struct inode_operations proc_def_inode_operations = {
+	.setattr	= proc_setattr,
+};
+
 static int proc_task_permission(struct inode *inode, int mask, struct nameidata *nd)
 {
 	struct dentry *root;
@@ -987,6 +1008,7 @@ static struct file_operations proc_oom_a
 
 static struct inode_operations proc_mem_inode_operations = {
 	.permission	= proc_permission,
+	.setattr	= proc_setattr,
 };
 
 #ifdef CONFIG_AUDITSYSCALL
@@ -1184,7 +1206,8 @@ out:
 
 static struct inode_operations proc_pid_link_inode_operations = {
 	.readlink	= proc_pid_readlink,
-	.follow_link	= proc_pid_follow_link
+	.follow_link	= proc_pid_follow_link,
+	.setattr	= proc_setattr,
 };
 
 #define NUMBUF 10
@@ -1356,6 +1379,7 @@ static struct inode *proc_pid_make_inode
 	ei->task = NULL;
 	inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
 	inode->i_ino = fake_ino(task->pid, ino);
+	inode->i_op = &proc_def_inode_operations;
 
 	if (!pid_alive(task))
 		goto out_unlock;
@@ -1579,11 +1603,13 @@ static struct file_operations proc_task_
 static struct inode_operations proc_fd_inode_operations = {
 	.lookup		= proc_lookupfd,
 	.permission	= proc_permission,
+	.setattr	= proc_setattr,
 };
 
 static struct inode_operations proc_task_inode_operations = {
 	.lookup		= proc_task_lookup,
 	.permission	= proc_task_permission,
+	.setattr	= proc_setattr,
 };
 
 #ifdef CONFIG_SECURITY
@@ -1873,10 +1899,12 @@ static struct file_operations proc_tid_b
 
 static struct inode_operations proc_tgid_base_inode_operations = {
 	.lookup		= proc_tgid_base_lookup,
+	.setattr	= proc_setattr,
 };
 
 static struct inode_operations proc_tid_base_inode_operations = {
 	.lookup		= proc_tid_base_lookup,
+	.setattr	= proc_setattr,
 };
 
 #ifdef CONFIG_SECURITY
@@ -1918,10 +1946,12 @@ static struct dentry *proc_tid_attr_look
 
 static struct inode_operations proc_tgid_attr_inode_operations = {
 	.lookup		= proc_tgid_attr_lookup,
+	.setattr	= proc_setattr,
 };
 
 static struct inode_operations proc_tid_attr_inode_operations = {
 	.lookup		= proc_tid_attr_lookup,
+	.setattr	= proc_setattr,
 };
 #endif
 
@@ -1946,6 +1976,7 @@ static void *proc_self_follow_link(struc
 static struct inode_operations proc_self_inode_operations = {
 	.readlink	= proc_self_readlink,
 	.follow_link	= proc_self_follow_link,
+	.setattr	= proc_setattr,
 };
 
 /**

--

[patch 03/23] : H.323 helper: fix possible NULL-ptr dereference

[Greg KH]

[-- Attachment #1: h.323-helper-fix-possible-null-ptr-dereference.patch --]
[-- Type: text/plain, Size: 1000 bytes --]

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

------------------
From: Patrick McHardy <kaber@trash.net>

[NETFILTER]: H.323 helper: fix possible NULL-ptr dereference

An RCF message containing a timeout results in a NULL-ptr dereference if
no RRQ has been seen before.

Noticed by the "SATURN tool", reported by Thomas Dillig <tdillig@stanford.edu>
and Isil Dillig <isil@stanford.edu>.

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

---
 net/ipv4/netfilter/ip_conntrack_helper_h323.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.7.orig/net/ipv4/netfilter/ip_conntrack_helper_h323.c
+++ linux-2.6.17.7/net/ipv4/netfilter/ip_conntrack_helper_h323.c
@@ -1092,7 +1092,7 @@ static struct ip_conntrack_expect *find_
 	tuple.dst.protonum = IPPROTO_TCP;
 
 	exp = __ip_conntrack_expect_find(&tuple);
-	if (exp->master == ct)
+	if (exp && exp->master == ct)
 		return exp;
 	return NULL;
 }

--

[patch 04/23] scx200_acb: Fix the state machine

[Greg KH]

[-- Attachment #1: i2c-01-scx200_acb-fix-state-machine.patch --]
[-- Type: text/plain, Size: 1233 bytes --]

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

------------------
From: Thomas Andrews <tandrews@grok.co.za>

Fix the scx200_acb state machine:

* Nack was sent one byte too late on reads >= 2 bytes.
* Stop bit was set one byte too late on reads.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/i2c/busses/scx200_acb.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.17.7.orig/drivers/i2c/busses/scx200_acb.c
+++ linux-2.6.17.7/drivers/i2c/busses/scx200_acb.c
@@ -181,21 +181,21 @@ static void scx200_acb_machine(struct sc
 		break;
 
 	case state_read:
-		/* Set ACK if receiving the last byte */
-		if (iface->len == 1)
+		/* Set ACK if _next_ byte will be the last one */
+		if (iface->len == 2)
 			outb(inb(ACBCTL1) | ACBCTL1_ACK, ACBCTL1);
 		else
 			outb(inb(ACBCTL1) & ~ACBCTL1_ACK, ACBCTL1);
 
-		*iface->ptr++ = inb(ACBSDA);
-		--iface->len;
-
-		if (iface->len == 0) {
+		if (iface->len == 1) {
 			iface->result = 0;
 			iface->state = state_idle;
 			outb(inb(ACBCTL1) | ACBCTL1_STOP, ACBCTL1);
 		}
 
+		*iface->ptr++ = inb(ACBSDA);
+		--iface->len;
+
 		break;
 
 	case state_write:

--

[patch 05/23] scx200_acb: Fix the block transactions

[Greg KH]

[-- Attachment #1: i2c-02-scx200_acb-fix-block-transactions.patch --]
[-- Type: text/plain, Size: 1560 bytes --]

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

------------------
From: Jean Delvare <khali@linux-fr.org>

The scx200_acb i2c bus driver pretends to support SMBus block
transactions, but in fact it implements the more simple I2C block
transactions. Additionally, it lacks sanity checks on the length
of the block transactions, which could lead to a buffer overrun.

This fixes an oops reported by Alexander Atanasov:
http://marc.theaimsgroup.com/?l=linux-kernel&m=114970382125094

Thanks to Ben Gardner for fixing my bugs :)

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/i2c/busses/scx200_acb.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- linux-2.6.17.7.orig/drivers/i2c/busses/scx200_acb.c
+++ linux-2.6.17.7/drivers/i2c/busses/scx200_acb.c
@@ -304,8 +304,12 @@ static s32 scx200_acb_smbus_xfer(struct 
 		buffer = (u8 *)&cur_word;
 		break;
 
-	case I2C_SMBUS_BLOCK_DATA:
+	case I2C_SMBUS_I2C_BLOCK_DATA:
+		if (rw == I2C_SMBUS_READ)
+			data->block[0] = I2C_SMBUS_BLOCK_MAX; /* For now */
 		len = data->block[0];
+		if (len == 0 || len > I2C_SMBUS_BLOCK_MAX)
+			return -EINVAL;
 		buffer = &data->block[1];
 		break;
 
@@ -369,7 +373,7 @@ static u32 scx200_acb_func(struct i2c_ad
 {
 	return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
 	       I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
-	       I2C_FUNC_SMBUS_BLOCK_DATA;
+	       I2C_FUNC_SMBUS_I2C_BLOCK;
 }
 
 /* For now, we only handle combined mode (smbus) */

--

[patch 06/23] i2c: Fix ignore module parameter handling in i2c-core

[Greg KH]

[-- Attachment #1: i2c-03-fix-ignore-module-parameter-handling.patch --]
[-- Type: text/plain, Size: 836 bytes --]

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

------------------
From: "Mark M. Hoffman" <mhoffman@lightlink.com>

This patch fixes a bug in the handling of 'ignore' module parameters of I2C
client drivers.

Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/i2c/i2c-core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17.7.orig/drivers/i2c/i2c-core.c
+++ linux-2.6.17.7/drivers/i2c/i2c-core.c
@@ -756,9 +756,9 @@ int i2c_probe(struct i2c_adapter *adapte
 					"parameter for adapter %d, "
 					"addr 0x%02x\n", adap_id,
 					address_data->ignore[j + 1]);
+				ignore = 1;
+				break;
 			}
-			ignore = 1;
-			break;
 		}
 		if (ignore)
 			continue;

--

[patch 07/23] sky2: NAPI bug

[Greg KH]

[-- Attachment #1: sky2-napi-bug.patch --]
[-- Type: text/plain, Size: 968 bytes --]

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

------------------
From: Stephen Hemminger <shemminger@osdl.org>

If the sky2 driver decides to defer processing because it's NAPI
packet quota is done, then it won't correctly handle the rest
when it is rescheduled.

Signed-off-by: Stephen Hemminger <sch@sch-laptop.localdomain>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/sky2.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

--- linux-2.6.17.7.orig/drivers/net/sky2.c
+++ linux-2.6.17.7/drivers/net/sky2.c
@@ -2187,9 +2187,6 @@ static int sky2_poll(struct net_device *
 	int work_done = 0;
 	u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
 
-	if (!~status)
-		goto out;
-
 	if (status & Y2_IS_HW_ERR)
 		sky2_hw_intr(hw);
 
@@ -2226,7 +2223,7 @@ static int sky2_poll(struct net_device *
 
 	if (sky2_more_work(hw))
 		return 1;
-out:
+
 	netif_rx_complete(dev0);
 
 	sky2_read32(hw, B0_Y2_SP_LISR);

--

[patch 08/23] UHCI: Fix handling of short last packet

[Greg KH]

[-- Attachment #1: uhci-fix-handling-of-short-last-packet.patch --]
[-- Type: text/plain, Size: 1684 bytes --]

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

------------------
From: Alan Stern <stern@rowland.harvard.edu>

This patch (as753) fixes the way uhci-hcd handles a short packet when it
is the last packet of an URB.  Right now the driver handles short packets
the same no matter when they occur.  However, the controller stops
transferring packets when the short packet is not the last one (otherwise
it would be reading beyond the end of the device's data) and needs to be
restarted, whereas no such need occurs when the short packet is the last
one.

The result of the bug is that USB endpoint queues experience intermittent
hangs, a regression in 2.6.17 with respect to earlier kernels.  The bug
was raised in Bugzilla #6752 and this patch fixed it.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/usb/host/uhci-q.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- linux-2.6.17.7.orig/drivers/usb/host/uhci-q.c
+++ linux-2.6.17.7/drivers/usb/host/uhci-q.c
@@ -896,12 +896,14 @@ static int uhci_result_common(struct uhc
 			/*
 			 * This URB stopped short of its end.  We have to
 			 * fix up the toggles of the following URBs on the
-			 * queue and restart the queue.
+			 * queue and restart the queue.  But only if this
+			 * TD isn't the last one in the URB.
 			 *
 			 * Do this only the first time we encounter the
 			 * short URB.
 			 */
-			if (!urbp->short_transfer) {
+			if (!urbp->short_transfer &&
+					&td->list != urbp->td_list.prev) {
 				urbp->short_transfer = 1;
 				urbp->qh->initial_toggle =
 						uhci_toggle(td_token(td)) ^ 1;

--

[patch 09/23] : Update frag_list in pskb_trim

[Greg KH]

[-- Attachment #1: update-frag_list-in-pskb_trim.patch --]
[-- Type: text/plain, Size: 6091 bytes --]

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

------------------
From: Herbert Xu <herbert@gondor.apana.org.au>

[NET]: Update frag_list in pskb_trim

When pskb_trim has to defer to ___pksb_trim to trim the frag_list part of
the packet, the frag_list is not updated to reflect the trimming.  This
will usually work fine until you hit something that uses the packet length
or tail from the frag_list.

Examples include esp_output and ip_fragment.

Another problem caused by this is that you can end up with a linear packet
with a frag_list attached.

It is possible to get away with this if we audit everything to make sure
that they always consult skb->len before going down onto frag_list.  In
fact we can do the samething for the paged part as well to avoid copying
the data area of the skb.  For now though, let's do the conservative fix
and update frag_list.

Many thanks to Marco Berizzi for helping me to track down this bug.

This 4-year old bug took 3 months to track down.  Marco was very patient
indeed :)

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/linux/skbuff.h |   24 +++++------
 net/core/skbuff.c      |  106 ++++++++++++++++++++++++++++++++++---------------
 2 files changed, 86 insertions(+), 44 deletions(-)

--- linux-2.6.17.7.orig/include/linux/skbuff.h
+++ linux-2.6.17.7/include/linux/skbuff.h
@@ -967,15 +967,16 @@ static inline void skb_reserve(struct sk
 #define NET_SKB_PAD	16
 #endif
 
-extern int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc);
+extern int ___pskb_trim(struct sk_buff *skb, unsigned int len);
 
 static inline void __skb_trim(struct sk_buff *skb, unsigned int len)
 {
-	if (!skb->data_len) {
-		skb->len  = len;
-		skb->tail = skb->data + len;
-	} else
-		___pskb_trim(skb, len, 0);
+	if (unlikely(skb->data_len)) {
+		WARN_ON(1);
+		return;
+	}
+	skb->len  = len;
+	skb->tail = skb->data + len;
 }
 
 /**
@@ -985,6 +986,7 @@ static inline void __skb_trim(struct sk_
  *
  *	Cut the length of a buffer down by removing data from the tail. If
  *	the buffer is already under the length specified it is not modified.
+ *	The skb must be linear.
  */
 static inline void skb_trim(struct sk_buff *skb, unsigned int len)
 {
@@ -995,12 +997,10 @@ static inline void skb_trim(struct sk_bu
 
 static inline int __pskb_trim(struct sk_buff *skb, unsigned int len)
 {
-	if (!skb->data_len) {
-		skb->len  = len;
-		skb->tail = skb->data+len;
-		return 0;
-	}
-	return ___pskb_trim(skb, len, 1);
+	if (skb->data_len)
+		return ___pskb_trim(skb, len);
+	__skb_trim(skb, len);
+	return 0;
 }
 
 static inline int pskb_trim(struct sk_buff *skb, unsigned int len)
--- linux-2.6.17.7.orig/net/core/skbuff.c
+++ linux-2.6.17.7/net/core/skbuff.c
@@ -251,11 +251,11 @@ nodata:
 }
 
 
-static void skb_drop_fraglist(struct sk_buff *skb)
+static void skb_drop_list(struct sk_buff **listp)
 {
-	struct sk_buff *list = skb_shinfo(skb)->frag_list;
+	struct sk_buff *list = *listp;
 
-	skb_shinfo(skb)->frag_list = NULL;
+	*listp = NULL;
 
 	do {
 		struct sk_buff *this = list;
@@ -264,6 +264,11 @@ static void skb_drop_fraglist(struct sk_
 	} while (list);
 }
 
+static inline void skb_drop_fraglist(struct sk_buff *skb)
+{
+	skb_drop_list(&skb_shinfo(skb)->frag_list);
+}
+
 static void skb_clone_fraglist(struct sk_buff *skb)
 {
 	struct sk_buff *list;
@@ -802,49 +807,86 @@ struct sk_buff *skb_pad(struct sk_buff *
 	return nskb;
 }	
  
-/* Trims skb to length len. It can change skb pointers, if "realloc" is 1.
- * If realloc==0 and trimming is impossible without change of data,
- * it is BUG().
+/* Trims skb to length len. It can change skb pointers.
  */
 
-int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc)
+int ___pskb_trim(struct sk_buff *skb, unsigned int len)
 {
+	struct sk_buff **fragp;
+	struct sk_buff *frag;
 	int offset = skb_headlen(skb);
 	int nfrags = skb_shinfo(skb)->nr_frags;
 	int i;
+	int err;
 
-	for (i = 0; i < nfrags; i++) {
+	if (skb_cloned(skb) &&
+	    unlikely((err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC))))
+		return err;
+
+	i = 0;
+	if (offset >= len)
+		goto drop_pages;
+
+	for (; i < nfrags; i++) {
 		int end = offset + skb_shinfo(skb)->frags[i].size;
-		if (end > len) {
-			if (skb_cloned(skb)) {
-				BUG_ON(!realloc);
-				if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
-					return -ENOMEM;
-			}
-			if (len <= offset) {
-				put_page(skb_shinfo(skb)->frags[i].page);
-				skb_shinfo(skb)->nr_frags--;
-			} else {
-				skb_shinfo(skb)->frags[i].size = len - offset;
-			}
+
+		if (end < len) {
+			offset = end;
+			continue;
+		}
+
+		skb_shinfo(skb)->frags[i++].size = len - offset;
+
+drop_pages:
+		skb_shinfo(skb)->nr_frags = i;
+
+		for (; i < nfrags; i++)
+			put_page(skb_shinfo(skb)->frags[i].page);
+
+		if (skb_shinfo(skb)->frag_list)
+			skb_drop_fraglist(skb);
+		goto done;
+	}
+
+	for (fragp = &skb_shinfo(skb)->frag_list; (frag = *fragp);
+	     fragp = &frag->next) {
+		int end = offset + frag->len;
+
+		if (skb_shared(frag)) {
+			struct sk_buff *nfrag;
+
+			nfrag = skb_clone(frag, GFP_ATOMIC);
+			if (unlikely(!nfrag))
+				return -ENOMEM;
+
+			nfrag->next = frag->next;
+			kfree_skb(frag);
+			frag = nfrag;
+			*fragp = frag;
 		}
-		offset = end;
+
+		if (end < len) {
+			offset = end;
+			continue;
+		}
+
+		if (end > len &&
+		    unlikely((err = pskb_trim(frag, len - offset))))
+			return err;
+
+		if (frag->next)
+			skb_drop_list(&frag->next);
+		break;
 	}
 
-	if (offset < len) {
+done:
+	if (len > skb_headlen(skb)) {
 		skb->data_len -= skb->len - len;
 		skb->len       = len;
 	} else {
-		if (len <= skb_headlen(skb)) {
-			skb->len      = len;
-			skb->data_len = 0;
-			skb->tail     = skb->data + len;
-			if (skb_shinfo(skb)->frag_list && !skb_cloned(skb))
-				skb_drop_fraglist(skb);
-		} else {
-			skb->data_len -= skb->len - len;
-			skb->len       = len;
-		}
+		skb->len       = len;
+		skb->data_len  = 0;
+		skb->tail      = skb->data + len;
 	}
 
 	return 0;

--

[patch 10/23] VLAN state handling fix

[Greg KH]

[-- Attachment #1: vlan-state-handling-fix.patch --]
[-- Type: text/plain, Size: 1543 bytes --]

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

------------------
From: Stefan Rompf <stefan@loplof.de>

[VLAN]: Fix link state propagation

When the queue of the underlying device is stopped at initialization time
or the device is marked "not present", the state will be propagated to the
vlan device and never change. Based on an analysis by Patrick McHardy.

Signed-off-by: Stefan Rompf <stefan@loplof.de>
ACKed-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/8021q/vlan.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

--- linux-2.6.17.7.orig/net/8021q/vlan.c
+++ linux-2.6.17.7/net/8021q/vlan.c
@@ -67,10 +67,6 @@ static struct packet_type vlan_packet_ty
 	.func = vlan_skb_recv, /* VLAN receive method */
 };
 
-/* Bits of netdev state that are propagated from real device to virtual */
-#define VLAN_LINK_STATE_MASK \
-	((1<<__LINK_STATE_PRESENT)|(1<<__LINK_STATE_NOCARRIER)|(1<<__LINK_STATE_DORMANT))
-
 /* End of global variables definitions. */
 
 /*
@@ -470,7 +466,9 @@ static struct net_device *register_vlan_
 	new_dev->flags = real_dev->flags;
 	new_dev->flags &= ~IFF_UP;
 
-	new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
+	new_dev->state = (real_dev->state & ((1<<__LINK_STATE_NOCARRIER) |
+					     (1<<__LINK_STATE_DORMANT))) |
+			 (1<<__LINK_STATE_PRESENT);
 
 	/* need 4 bytes for extra VLAN header info,
 	 * hope the underlying device can handle it.

--

[patch 11/23] Sparc64 quad-float emulation fix

[Greg KH]

[-- Attachment #1: sparc64-quad-float-emulation-fix.patch --]
[-- Type: text/plain, Size: 1098 bytes --]

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

------------------
From: David Miller <davem@davemloft.net>

[SPARC64]: Fix quad-float multiply emulation.

Something is wrong with the 3-multiply (vs. 4-multiply) optimized
version of _FP_MUL_MEAT_2_*(), so just use the slower version
which actually computes correct values.

Noticed by Rene Rebe

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

---
 include/asm-sparc64/sfp-machine.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.7.orig/include/asm-sparc64/sfp-machine.h
+++ linux-2.6.17.7/include/asm-sparc64/sfp-machine.h
@@ -34,7 +34,7 @@
 #define _FP_MUL_MEAT_D(R,X,Y)					\
   _FP_MUL_MEAT_1_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
 #define _FP_MUL_MEAT_Q(R,X,Y)					\
-  _FP_MUL_MEAT_2_wide_3mul(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)
+  _FP_MUL_MEAT_2_wide(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)
 
 #define _FP_DIV_MEAT_S(R,X,Y)	_FP_DIV_MEAT_1_imm(S,R,X,Y,_FP_DIV_HELP_imm)
 #define _FP_DIV_MEAT_D(R,X,Y)	_FP_DIV_MEAT_1_udiv_norm(D,R,X,Y)

--

[patch 12/23] invalidate_bdev() speedup

[Greg KH]

[-- Attachment #1: invalidate_bdev-speedup.patch --]
[-- Type: text/plain, Size: 1129 bytes --]

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

------------------
From: Andrew Morton <akpm@osdl.org>

We can immediately bale from invalidate_bdev() if the blockdev has no
pagecache.

This solves the huge IPI storms which hald is causing on the big ia64
machines when it polls CDROM drives.

Acked-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/buffer.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- linux-2.6.17.7.orig/fs/buffer.c
+++ linux-2.6.17.7/fs/buffer.c
@@ -473,13 +473,18 @@ out:
    pass does the actual I/O. */
 void invalidate_bdev(struct block_device *bdev, int destroy_dirty_buffers)
 {
+	struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+	if (mapping->nrpages == 0)
+		return;
+
 	invalidate_bh_lrus();
 	/*
 	 * FIXME: what about destroy_dirty_buffers?
 	 * We really want to use invalidate_inode_pages2() for
 	 * that, but not until that's cleaned up.
 	 */
-	invalidate_inode_pages(bdev->bd_inode->i_mapping);
+	invalidate_inode_pages(mapping);
 }
 
 /*

--

Re: [patch 12/23] invalidate_bdev() speedup

[Christoph Hellwig]

On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.

This is a feature.  Definitly not -stable material.

Re: [patch 12/23] invalidate_bdev() speedup

[Andrew Morton]

On Fri, 4 Aug 2006 09:50:13 +0100
Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> 
> This is a feature.  Definitly not -stable material.

Apparently that regular IPI storm is causing the SGI machines some
significant problems.  I assume it's the interrupt latency problem again.
Jes would know.

It's not the biggest problem we've ever had, but if this patch is wrong,
the pagecache/buffer_head layer is utterly busted.  And it isn't.

Re: [patch 12/23] invalidate_bdev() speedup

[Arjan van de Ven]

On Fri, 2006-08-04 at 02:04 -0700, Andrew Morton wrote:
> On Fri, 4 Aug 2006 09:50:13 +0100
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> > > -stable review patch.  If anyone has any objections, please let us know.
> > 
> > This is a feature.  Definitly not -stable material.
> 
> Apparently that regular IPI storm is causing the SGI machines some
> significant problems. 

a tiny performance drop :) If that meets the stable policy.. open
question :)

> It's not the biggest problem we've ever had, but if this patch is wrong,
> the pagecache/buffer_head layer is utterly busted.  And it isn't.


are you sure?

+       struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+       if (mapping->nrpages == 0)
+               return;
+
        invalidate_bh_lrus();

what happens if a bdev used to have pagecache and at some point stops
having that due to page reclaim... will that page reclaim call
invalidate_bh_lrus() ? If not, who will ? If the answer is "nobody", is
that really the right answer?



-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com

Re: [patch 12/23] invalidate_bdev() speedup

[Jes Sorensen]

Arjan van de Ven wrote:
> On Fri, 2006-08-04 at 02:04 -0700, Andrew Morton wrote:
>> Apparently that regular IPI storm is causing the SGI machines some
>> significant problems. 
> 
> a tiny performance drop :) If that meets the stable policy.. open
> question :)

It's visible on any SMP machine, but the more CPUs the worse it gets,
this isn't an SGI only problem. Whether the performance degredation
warrants putting it into stable is another question ....

>> It's not the biggest problem we've ever had, but if this patch is wrong,
>> the pagecache/buffer_head layer is utterly busted.  And it isn't.
> 
> are you sure?
> 
> +       struct address_space *mapping = bdev->bd_inode->i_mapping;
> +
> +       if (mapping->nrpages == 0)
> +               return;
> +
>         invalidate_bh_lrus();
> 
> what happens if a bdev used to have pagecache and at some point stops
> having that due to page reclaim... will that page reclaim call
> invalidate_bh_lrus() ? If not, who will ? If the answer is "nobody", is
> that really the right answer?

Well what happens if the pagecache doesn't remove the page from the lru
on reclaim and we do a lookup for it later? I'm not an expert in the LRU
usage or page reclaim, but it seems to me we could end up with a stable
reference if that was the case.

Cheers,
Jes

Re: [patch 12/23] invalidate_bdev() speedup

[Andrew Morton]

On Fri, 04 Aug 2006 15:08:49 +0200
Arjan van de Ven <arjan@infradead.org> wrote:

> On Fri, 2006-08-04 at 02:04 -0700, Andrew Morton wrote:
> > On Fri, 4 Aug 2006 09:50:13 +0100
> > Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > > On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> > > > -stable review patch.  If anyone has any objections, please let us know.
> > > 
> > > This is a feature.  Definitly not -stable material.
> > 
> > Apparently that regular IPI storm is causing the SGI machines some
> > significant problems. 
> 
> a tiny performance drop :) If that meets the stable policy.. open
> question :)

The interrupt holdoff problem is one which is important to Altix users (for
reasons which I've never understood).  Apparently, quite important - this
is I think the third time we've fixed problems in this area for Altix.

> > It's not the biggest problem we've ever had, but if this patch is wrong,
> > the pagecache/buffer_head layer is utterly busted.  And it isn't.
> 
> 
> are you sure?
> 
> +       struct address_space *mapping = bdev->bd_inode->i_mapping;
> +
> +       if (mapping->nrpages == 0)
> +               return;
> +
>         invalidate_bh_lrus();
> 
> what happens if a bdev used to have pagecache and at some point stops
> having that due to page reclaim... will that page reclaim call
> invalidate_bh_lrus() ? If not, who will ? If the answer is "nobody", is
> that really the right answer?

invalidate_bdev() calls invalidate_bh_lrus() to release any references
which the bh lru has against the the bdev's pagecache, so that
invalidate_inode_pages() can take down the bdev's pagecache.

If the bdev has no pagecache then there's no need to call
invalidate_bh_lrus(). (or invalidate_inode_pages, or truncate_inode_pages, btw)

(In fact, even if the inode _does_ have pagecache, we still don't need to
call invalidate_bh_lrus(): both invalidate_inodes_pages() and
truncate_inode_pages() will still remove this page from the inode.  The bh
lru is left holding the last reference to the now-anonymous page, and this
will later expire, finally freeing the page).

[patch 13/23] ieee1394: sbp2: enable auto spin-up for Maxtor disks

[Greg KH]

[-- Attachment #1: ieee1394-sbp2-enable-auto-spin-up-for-maxtor-disks.patch --]
[-- Type: text/plain, Size: 1101 bytes --]

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

------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>

At least Maxtor OneTouch III require a "start stop unit" command after
auto spin-down before the next access can proceed.  This patch activates
the responsible code in scsi_mod for all Maxtor SBP-2 disks.
https://bugzilla.novell.com/show_bug.cgi?id=183011

Maybe that should be done for all SBP-2 disks, but better be cautious.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ieee1394/sbp2.c |    3 +++
 1 file changed, 3 insertions(+)

--- linux-2.6.17.7.orig/drivers/ieee1394/sbp2.c
+++ linux-2.6.17.7/drivers/ieee1394/sbp2.c
@@ -2541,6 +2541,9 @@ static int sbp2scsi_slave_configure(stru
 		sdev->skip_ms_page_8 = 1;
 	if (scsi_id->workarounds & SBP2_WORKAROUND_FIX_CAPACITY)
 		sdev->fix_capacity = 1;
+	if (scsi_id->ne->guid_vendor_id == 0x0010b9 && /* Maxtor's OUI */
+	    (sdev->type == TYPE_DISK || sdev->type == TYPE_RBC))
+		sdev->allow_restart = 1;
 	return 0;
 }
 

--

[patch 14/23] Fix race related problem when adding items to and svcrpc auth cache.

[Greg KH]

[-- Attachment #1: fix-race-related-problem-when-adding-items-to-and-svcrpc-auth-cache.patch --]
[-- Type: text/plain, Size: 1467 bytes --]

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

------------------
From: Neil Brown <neilb@suse.de>

Fix race related problem when adding items to and svcrpc auth cache.

If we don't find the item we are lookng for, we allocate a new one,
and then grab the lock again and search to see if it has been added
while we did the alloc.
If it had been added we need to 'cache_put' the newly created item
that we are never going to use.  But as it hasn't been initialised
properly, putting it can cause an oops.

So move the ->init call earlier to that it will always be fully
initilised if we have to put it.

Thanks to Philipp Matthias Hahn <pmhahn@svs.Informatik.Uni-Oldenburg.de>
for reporting the problem.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 net/sunrpc/cache.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- linux-2.6.17.7.orig/net/sunrpc/cache.c
+++ linux-2.6.17.7/net/sunrpc/cache.c
@@ -71,7 +71,12 @@ struct cache_head *sunrpc_cache_lookup(s
 	new = detail->alloc();
 	if (!new)
 		return NULL;
+	/* must fully initialise 'new', else
+	 * we might get lose if we need to
+	 * cache_put it soon.
+	 */
 	cache_init(new);
+	detail->init(new, key);
 
 	write_lock(&detail->hash_lock);
 
@@ -85,7 +90,6 @@ struct cache_head *sunrpc_cache_lookup(s
 			return tmp;
 		}
 	}
-	detail->init(new, key);
 	new->next = *head;
 	*head = new;
 	detail->entries++;

--

[patch 15/23] ext3 -nobh option causes oops

[Greg KH]

[-- Attachment #1: ext3-nobh-option-causes-oops.patch --]
[-- Type: text/plain, Size: 1637 bytes --]

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

------------------
From: Badari Pulavarty <pbadari@us.ibm.com>

For files other than IFREG, nobh option doesn't make sense.  Modifications
to them are journalled and needs buffer heads to do that.  Without this
patch, we get kernel oops in page_buffers().

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ext3/inode.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.17.7.orig/fs/ext3/inode.c
+++ linux-2.6.17.7/fs/ext3/inode.c
@@ -1159,7 +1159,7 @@ retry:
 		ret = PTR_ERR(handle);
 		goto out;
 	}
-	if (test_opt(inode->i_sb, NOBH))
+	if (test_opt(inode->i_sb, NOBH) && ext3_should_writeback_data(inode))
 		ret = nobh_prepare_write(page, from, to, ext3_get_block);
 	else
 		ret = block_prepare_write(page, from, to, ext3_get_block);
@@ -1245,7 +1245,7 @@ static int ext3_writeback_commit_write(s
 	if (new_i_size > EXT3_I(inode)->i_disksize)
 		EXT3_I(inode)->i_disksize = new_i_size;
 
-	if (test_opt(inode->i_sb, NOBH))
+	if (test_opt(inode->i_sb, NOBH) && ext3_should_writeback_data(inode))
 		ret = nobh_commit_write(file, page, from, to);
 	else
 		ret = generic_commit_write(file, page, from, to);
@@ -1495,7 +1495,7 @@ static int ext3_writeback_writepage(stru
 		goto out_fail;
 	}
 
-	if (test_opt(inode->i_sb, NOBH))
+	if (test_opt(inode->i_sb, NOBH) && ext3_should_writeback_data(inode))
 		ret = nobh_writepage(page, ext3_get_block, wbc);
 	else
 		ret = block_write_full_page(page, ext3_get_block, wbc);

--

[patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle

[Greg KH]

[-- Attachment #1: ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle.patch --]
[-- Type: text/plain, Size: 3529 bytes --]

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

------------------
From: Neil Brown <neilb@suse.de>

The inode number out of an NFS file handle gets passed eventually to
ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
allows it to trigger an error, then bad filehandles can have unpleasant
effect - ext3_error() will usually cause a forced read-only remount, or a
panic if `errors=panic' was used.

So remove the call to ext3_error there and put a matching check in
ext3/namei.c where inode numbers are read off storage.

[akpm@osdl.org: fix off-by-one error]
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Eric Sandeen <esandeen@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ext3/inode.c         |   13 +++++++------
 fs/ext3/namei.c         |   15 +++++++++++++--
 include/linux/ext3_fs.h |    9 +++++++++
 3 files changed, 29 insertions(+), 8 deletions(-)

--- linux-2.6.17.7.orig/fs/ext3/inode.c
+++ linux-2.6.17.7/fs/ext3/inode.c
@@ -2402,14 +2402,15 @@ static unsigned long ext3_get_inode_bloc
 	struct buffer_head *bh;
 	struct ext3_group_desc * gdp;
 
-
-	if ((ino != EXT3_ROOT_INO && ino != EXT3_JOURNAL_INO &&
-		ino != EXT3_RESIZE_INO && ino < EXT3_FIRST_INO(sb)) ||
-		ino > le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count)) {
-		ext3_error(sb, "ext3_get_inode_block",
-			    "bad inode number: %lu", ino);
+	if (!ext3_valid_inum(sb, ino)) {
+		/*
+		 * This error is already checked for in namei.c unless we are
+		 * looking at an NFS filehandle, in which case no error
+		 * report is needed
+		 */
 		return 0;
 	}
+
 	block_group = (ino - 1) / EXT3_INODES_PER_GROUP(sb);
 	if (block_group >= EXT3_SB(sb)->s_groups_count) {
 		ext3_error(sb,"ext3_get_inode_block","group >= groups count");
--- linux-2.6.17.7.orig/fs/ext3/namei.c
+++ linux-2.6.17.7/fs/ext3/namei.c
@@ -1000,7 +1000,12 @@ static struct dentry *ext3_lookup(struct
 	if (bh) {
 		unsigned long ino = le32_to_cpu(de->inode);
 		brelse (bh);
-		inode = iget(dir->i_sb, ino);
+		if (!ext3_valid_inum(dir->i_sb, ino)) {
+			ext3_error(dir->i_sb, "ext3_lookup",
+				   "bad inode number: %lu", ino);
+			inode = NULL;
+		} else
+			inode = iget(dir->i_sb, ino);
 
 		if (!inode)
 			return ERR_PTR(-EACCES);
@@ -1028,7 +1033,13 @@ struct dentry *ext3_get_parent(struct de
 		return ERR_PTR(-ENOENT);
 	ino = le32_to_cpu(de->inode);
 	brelse(bh);
-	inode = iget(child->d_inode->i_sb, ino);
+
+	if (!ext3_valid_inum(child->d_inode->i_sb, ino)) {
+		ext3_error(child->d_inode->i_sb, "ext3_get_parent",
+			   "bad inode number: %lu", ino);
+		inode = NULL;
+	} else
+		inode = iget(child->d_inode->i_sb, ino);
 
 	if (!inode)
 		return ERR_PTR(-EACCES);
--- linux-2.6.17.7.orig/include/linux/ext3_fs.h
+++ linux-2.6.17.7/include/linux/ext3_fs.h
@@ -495,6 +495,15 @@ static inline struct ext3_inode_info *EX
 {
 	return container_of(inode, struct ext3_inode_info, vfs_inode);
 }
+
+static inline int ext3_valid_inum(struct super_block *sb, unsigned long ino)
+{
+	return ino == EXT3_ROOT_INO ||
+		ino == EXT3_JOURNAL_INO ||
+		ino == EXT3_RESIZE_INO ||
+		(ino >= EXT3_FIRST_INO(sb) &&
+		 ino <= le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count));
+}
 #else
 /* Assume that user mode programs are passing in an ext3fs superblock, not
  * a kernel struct super_block.  This will allow us to call the feature-test

--

Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle

[Eric Sandeen]

Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Neil Brown <neilb@suse.de>
> 
> The inode number out of an NFS file handle gets passed eventually to
> ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
> allows it to trigger an error, then bad filehandles can have unpleasant
> effect - ext3_error() will usually cause a forced read-only remount, or a
> panic if `errors=panic' was used.
> 
> So remove the call to ext3_error there and put a matching check in
> ext3/namei.c where inode numbers are read off storage.

This patch and the ext2 patch (23/23) are accomplishing the same thing in 2 
different ways, I think, and introducing unnecessary differences between ext2 
and ext3.  I'd personally prefer to see both ext2 and ext3 handled with the 
get_dentry op addition, and I'd be happy to quickly whip up the ext3 patch to do 
this if there's agreement on this path.

(there's nothing technically wrong with either approach, it just seems 
inconsistent to me).

Thanks,

-Eric

Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle

[Christoph Hellwig]

On Fri, Aug 04, 2006 at 09:45:52AM -0500, Eric Sandeen wrote:
> Greg KH wrote:
> >-stable review patch.  If anyone has any objections, please let us know.
> >
> >------------------
> >From: Neil Brown <neilb@suse.de>
> >
> >The inode number out of an NFS file handle gets passed eventually to
> >ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
> >allows it to trigger an error, then bad filehandles can have unpleasant
> >effect - ext3_error() will usually cause a forced read-only remount, or a
> >panic if `errors=panic' was used.
> >
> >So remove the call to ext3_error there and put a matching check in
> >ext3/namei.c where inode numbers are read off storage.
> 
> This patch and the ext2 patch (23/23) are accomplishing the same thing in 2 
> different ways, I think, and introducing unnecessary differences between 
> ext2 and ext3.  I'd personally prefer to see both ext2 and ext3 handled 
> with the get_dentry op addition, and I'd be happy to quickly whip up the 
> ext3 patch to do this if there's agreement on this path.

I completly agree with Eric here.  Also pushing out only the fix for one
(and today probably the lesser used) filesystems to -stable seems wrong.

Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle

[Eric Sandeen]

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

Christoph Hellwig wrote:
> On Fri, Aug 04, 2006 at 09:45:52AM -0500, Eric Sandeen wrote:
>> Greg KH wrote:
>>> -stable review patch.  If anyone has any objections, please let us know.
>>>
>>> ------------------
>>> From: Neil Brown <neilb@suse.de>
>>>
>>> The inode number out of an NFS file handle gets passed eventually to
>>> ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
>>> allows it to trigger an error, then bad filehandles can have unpleasant
>>> effect - ext3_error() will usually cause a forced read-only remount, or a
>>> panic if `errors=panic' was used.
>>>
>>> So remove the call to ext3_error there and put a matching check in
>>> ext3/namei.c where inode numbers are read off storage.
>> This patch and the ext2 patch (23/23) are accomplishing the same thing in 2 
>> different ways, I think, and introducing unnecessary differences between 
>> ext2 and ext3.  I'd personally prefer to see both ext2 and ext3 handled 
>> with the get_dentry op addition, and I'd be happy to quickly whip up the 
>> ext3 patch to do this if there's agreement on this path.
> 
> I completly agree with Eric here.  Also pushing out only the fix for one
> (and today probably the lesser used) filesystems to -stable seems wrong.

so how's this? (compile tested)

Thanks,
-Eric

[-- Attachment #2: have-ext3-reject-file-handles-with-bad-inode-numbers-early.patch --]
[-- Type: text/plain, Size: 1562 bytes --]

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>

(tho blatantly ripped off from Neil Brown's ext2 patch)

Index: linux-2.6.17/fs/ext3/super.c
===================================================================
--- linux-2.6.17.orig/fs/ext3/super.c
+++ linux-2.6.17/fs/ext3/super.c
@@ -620,8 +620,48 @@ static struct super_operations ext3_sops
 #endif
 };
 
+static struct dentry *ext3_get_dentry(struct super_block *sb, void *vobjp)
+{
+	__u32 *objp = vobjp;
+	unsigned long ino = objp[0];
+	__u32 generation = objp[1];
+	struct inode *inode;
+	struct dentry *result;
+
+	if (ino != EXT3_ROOT_INO && ino < EXT3_FIRST_INO(sb))
+		return ERR_PTR(-ESTALE);
+	if (ino > le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count))
+		return ERR_PTR(-ESTALE);
+
+	/* iget isn't really right if the inode is currently unallocated!!
+	 * ext3_read_inode currently does appropriate checks, but
+	 * it might be "neater" to call ext3_get_inode first and check
+	 * if the inode is valid.....
+	 */
+	inode = iget(sb, ino);
+	if (inode == NULL)
+		return ERR_PTR(-ENOMEM);
+	if (is_bad_inode(inode)
+	    || (generation && inode->i_generation != generation)
+		) {
+		/* we didn't find the right inode.. */
+		iput(inode);
+		return ERR_PTR(-ESTALE);
+	}
+	/* now to find a dentry.
+	 * If possible, get a well-connected one
+	 */
+	result = d_alloc_anon(inode);
+	if (!result) {
+		iput(inode);
+		return ERR_PTR(-ENOMEM);
+	}
+	return result;
+}
+
 static struct export_operations ext3_export_ops = {
 	.get_parent = ext3_get_parent,
+	.get_dentry = ext3_get_dentry,
 };
 
 enum {

Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle

[Theodore Tso]

On Fri, Aug 04, 2006 at 10:35:34AM -0500, Eric Sandeen wrote:
> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
> 
> (tho blatantly ripped off from Neil Brown's ext2 patch)

Looks good!

Acked-by: "Theodore Ts'o" <tytso@mit.edu>

					- Ted

Re: [stable] [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle

[Greg KH]

On Fri, Aug 04, 2006 at 10:35:34AM -0500, Eric Sandeen wrote:
> Christoph Hellwig wrote:
> >On Fri, Aug 04, 2006 at 09:45:52AM -0500, Eric Sandeen wrote:
> >>Greg KH wrote:
> >>>-stable review patch.  If anyone has any objections, please let us know.
> >>>
> >>>------------------
> >>>From: Neil Brown <neilb@suse.de>
> >>>
> >>>The inode number out of an NFS file handle gets passed eventually to
> >>>ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
> >>>allows it to trigger an error, then bad filehandles can have unpleasant
> >>>effect - ext3_error() will usually cause a forced read-only remount, or a
> >>>panic if `errors=panic' was used.
> >>>
> >>>So remove the call to ext3_error there and put a matching check in
> >>>ext3/namei.c where inode numbers are read off storage.
> >>This patch and the ext2 patch (23/23) are accomplishing the same thing in 
> >>2 different ways, I think, and introducing unnecessary differences 
> >>between ext2 and ext3.  I'd personally prefer to see both ext2 and ext3 
> >>handled with the get_dentry op addition, and I'd be happy to quickly whip 
> >>up the ext3 patch to do this if there's agreement on this path.
> >
> >I completly agree with Eric here.  Also pushing out only the fix for one
> >(and today probably the lesser used) filesystems to -stable seems wrong.
> 
> so how's this? (compile tested)
> 
> Thanks,
> -Eric

> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
> 
> (tho blatantly ripped off from Neil Brown's ext2 patch)

Thanks, I've queued this up.

greg k-h

[patch 17/23] e1000: add forgotten PCI ID for supported device

[Greg KH]

[-- Attachment #1: e1000-add-forgotten-pci-id-for-supported-device.patch --]
[-- Type: text/plain, Size: 1439 bytes --]

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

------------------
From: Auke Kok <auke-jan.h.kok@intel.com>

The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and
onward.  Add the device ID so this card works with 2.6.17.y onward. This
device ID was accidentally omitted.

Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/e1000/e1000_hw.c |    1 +
 drivers/net/e1000/e1000_hw.h |    1 +
 2 files changed, 2 insertions(+)

--- linux-2.6.17.7.orig/drivers/net/e1000/e1000_hw.c
+++ linux-2.6.17.7/drivers/net/e1000/e1000_hw.c
@@ -353,6 +353,7 @@ e1000_set_mac_type(struct e1000_hw *hw)
     case E1000_DEV_ID_82572EI_COPPER:
     case E1000_DEV_ID_82572EI_FIBER:
     case E1000_DEV_ID_82572EI_SERDES:
+    case E1000_DEV_ID_82572EI:
         hw->mac_type = e1000_82572;
         break;
     case E1000_DEV_ID_82573E:
--- linux-2.6.17.7.orig/drivers/net/e1000/e1000_hw.h
+++ linux-2.6.17.7/drivers/net/e1000/e1000_hw.h
@@ -462,6 +462,7 @@ int32_t e1000_check_phy_reset_block(stru
 #define E1000_DEV_ID_82572EI_COPPER      0x107D
 #define E1000_DEV_ID_82572EI_FIBER       0x107E
 #define E1000_DEV_ID_82572EI_SERDES      0x107F
+#define E1000_DEV_ID_82572EI             0x10B9
 #define E1000_DEV_ID_82573E              0x108B
 #define E1000_DEV_ID_82573E_IAMT         0x108C
 #define E1000_DEV_ID_82573L              0x109A

--

[patch 18/23] cond_resched() fix

[Greg KH]

[-- Attachment #1: cond_resched-fix.patch --]
[-- Type: text/plain, Size: 3212 bytes --]


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

------------------
From: Andrew Morton <akpm@osdl.org>

[PATCH] cond_resched() fix

Fix a bug identified by Zou Nan hai <nanhai.zou@intel.com>:

If the system is in state SYSTEM_BOOTING, and need_resched() is true,
cond_resched() returns true even though it didn't reschedule.  Consequently
need_resched() remains true and JBD locks up.

Fix that by teaching cond_resched() to only return true if it really did call
schedule().

cond_resched_lock() and cond_resched_softirq() have a problem too.  If we're
in SYSTEM_BOOTING state and need_resched() is true, these functions will drop
the lock and will then try to call schedule(), but the SYSTEM_BOOTING state
will prevent schedule() from being called.  So on return, need_resched() will
still be true, but cond_resched_lock() has to return 1 to tell the caller that
the lock was dropped.  The caller will probably lock up.

Bottom line: if these functions dropped the lock, they _must_ call schedule()
to clear need_resched().   Make it so.

Also, uninline __cond_resched().  It's largeish, and slowpath.

Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/sched.c |   25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

--- linux-2.6.17.7.orig/kernel/sched.c
+++ linux-2.6.17.7/kernel/sched.c
@@ -4044,17 +4044,22 @@ asmlinkage long sys_sched_yield(void)
 	return 0;
 }
 
-static inline void __cond_resched(void)
+static inline int __resched_legal(int expected_preempt_count)
+{
+	if (unlikely(preempt_count() != expected_preempt_count))
+		return 0;
+	if (unlikely(system_state != SYSTEM_RUNNING))
+		return 0;
+	return 1;
+}
+
+static void __cond_resched(void)
 {
 	/*
 	 * The BKS might be reacquired before we have dropped
 	 * PREEMPT_ACTIVE, which could trigger a second
 	 * cond_resched() call.
 	 */
-	if (unlikely(preempt_count()))
-		return;
-	if (unlikely(system_state != SYSTEM_RUNNING))
-		return;
 	do {
 		add_preempt_count(PREEMPT_ACTIVE);
 		schedule();
@@ -4064,13 +4069,12 @@ static inline void __cond_resched(void)
 
 int __sched cond_resched(void)
 {
-	if (need_resched()) {
+	if (need_resched() && __resched_legal(0)) {
 		__cond_resched();
 		return 1;
 	}
 	return 0;
 }
-
 EXPORT_SYMBOL(cond_resched);
 
 /*
@@ -4091,7 +4095,7 @@ int cond_resched_lock(spinlock_t *lock)
 		ret = 1;
 		spin_lock(lock);
 	}
-	if (need_resched()) {
+	if (need_resched() && __resched_legal(1)) {
 		_raw_spin_unlock(lock);
 		preempt_enable_no_resched();
 		__cond_resched();
@@ -4100,14 +4104,13 @@ int cond_resched_lock(spinlock_t *lock)
 	}
 	return ret;
 }
-
 EXPORT_SYMBOL(cond_resched_lock);
 
 int __sched cond_resched_softirq(void)
 {
 	BUG_ON(!in_softirq());
 
-	if (need_resched()) {
+	if (need_resched() && __resched_legal(0)) {
 		__local_bh_enable();
 		__cond_resched();
 		local_bh_disable();
@@ -4115,10 +4118,8 @@ int __sched cond_resched_softirq(void)
 	}
 	return 0;
 }
-
 EXPORT_SYMBOL(cond_resched_softirq);
 
-
 /**
  * yield - yield the current processor to other threads.
  *

--

[patch 19/23] Fix budget-av compile failure

[Greg KH]

[-- Attachment #1: fix-budget-av-compile-failure.patch --]
[-- Type: text/plain, Size: 2143 bytes --]

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

------------------
From: Andrew de Quincey <adq_dvb@lidskialf.net>

Currently I am doing lots of refactoring work in the dvb tree. This
bugfix became necessary to fix 2.6.17 whilst I was in the middle of this
work. Unfortunately after I tested the original code for the patch, I
generated the diff against the wrong tree (I accidentally used a tree
with part of the refactoring code in it). This resulted in the reported
compile errors because that tree (a) was incomplete, and (b) used
features which are simply not in the mainline kernel yet.

Many apologies for the error and problems this has caused. :(

Signed-off-by: Andrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/dvb/ttpci/budget-av.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

--- linux-2.6.17.7.orig/drivers/media/dvb/ttpci/budget-av.c
+++ linux-2.6.17.7/drivers/media/dvb/ttpci/budget-av.c
@@ -58,6 +58,7 @@ struct budget_av {
 	struct tasklet_struct ciintf_irq_tasklet;
 	int slot_status;
 	struct dvb_ca_en50221 ca;
+	u8 reinitialise_demod:1;
 };
 
 /* GPIO Connections:
@@ -214,8 +215,9 @@ static int ciintf_slot_reset(struct dvb_
 	while (--timeout > 0 && ciintf_read_attribute_mem(ca, slot, 0) != 0x1d)
 		msleep(100);
 
-	/* reinitialise the frontend */
-	dvb_frontend_reinitialise(budget_av->budget.dvb_frontend);
+	/* reinitialise the frontend if necessary */
+	if (budget_av->reinitialise_demod)
+		dvb_frontend_reinitialise(budget_av->budget.dvb_frontend);
 
 	if (timeout <= 0)
 	{
@@ -1064,12 +1066,10 @@ static void frontend_init(struct budget_
 		fe = tda10021_attach(&philips_cu1216_config,
 				     &budget_av->budget.i2c_adap,
 				     read_pwm(budget_av));
-		if (fe) {
-			fe->ops.tuner_ops.set_params = philips_cu1216_tuner_set_params;
-		}
 		break;
 
 	case SUBID_DVBC_KNC1_PLUS:
+		budget_av->reinitialise_demod = 1;
 		fe = tda10021_attach(&philips_cu1216_config,
 				     &budget_av->budget.i2c_adap,
 				     read_pwm(budget_av));

--

[patch 20/23] S390: fix futex_atomic_cmpxchg_inatomic

[Greg KH]

[-- Attachment #1: s390-fix-futex_atomic_cmpxchg_inatomic.patch --]
[-- Type: text/plain, Size: 1027 bytes --]


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

------------------
[S390] fix futex_atomic_cmpxchg_inatomic

futex_atomic_cmpxchg_inatomic has the same bug as the other
atomic futex operations: the operation needs to be done in the
user address space, not the kernel address space. Add the missing
sacf 256 & sacf 0.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/asm-s390/futex.h |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.17.7.orig/include/asm-s390/futex.h
+++ linux-2.6.17.7/include/asm-s390/futex.h
@@ -98,9 +98,10 @@ futex_atomic_cmpxchg_inatomic(int __user
 
 	if (! access_ok (VERIFY_WRITE, uaddr, sizeof(int)))
 		return -EFAULT;
-	asm volatile("   cs   %1,%4,0(%5)\n"
+	asm volatile("   sacf 256\n"
+		     "   cs   %1,%4,0(%5)\n"
 		     "0: lr   %0,%1\n"
-		     "1:\n"
+		     "1: sacf 0\n"
 #ifndef __s390x__
 		     ".section __ex_table,\"a\"\n"
 		     "   .align 4\n"

--

Re: [patch 20/23] S390: fix futex_atomic_cmpxchg_inatomic

[Martin Schwidefsky]

On Thu, 2006-08-03 at 22:40 -0700, Greg KH wrote:
> plain text document attachment
> (s390-fix-futex_atomic_cmpxchg_inatomic.patch)
> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> [S390] fix futex_atomic_cmpxchg_inatomic
> 
> futex_atomic_cmpxchg_inatomic has the same bug as the other
> atomic futex operations: the operation needs to be done in the
> user address space, not the kernel address space. Add the missing
> sacf 256 & sacf 0.
> 
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 

Hi Greg,
sorry for the late answer. Stable version 2.6.17.8 contains the
necessary patches to fix the futex hole and I currently do not know of
any other critical bugs that need fixing. Thanks!

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.

[patch 21/23] tty serialize flush_to_ldisc

[Greg KH]

[-- Attachment #1: tty-serialize-flush_to_ldisc.patch --]
[-- Type: text/plain, Size: 1702 bytes --]

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

------------------
From: Paul Fulghum <paulkf@microgate.com>

Serialize processing of tty buffers in flush_to_ldisc
to fix (very rare) corruption of tty buffer free list
on SMP systems.

Signed-off-by: Paul Fulghum <paulkf@microgate.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/char/tty_io.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

--- linux-2.6.17.7.orig/drivers/char/tty_io.c
+++ linux-2.6.17.7/drivers/char/tty_io.c
@@ -2776,7 +2776,7 @@ static void flush_to_ldisc(void *private
 	struct tty_struct *tty = (struct tty_struct *) private_;
 	unsigned long 	flags;
 	struct tty_ldisc *disc;
-	struct tty_buffer *tbuf;
+	struct tty_buffer *tbuf, *head;
 	int count;
 	char *char_buf;
 	unsigned char *flag_buf;
@@ -2793,7 +2793,9 @@ static void flush_to_ldisc(void *private
 		goto out;
 	}
 	spin_lock_irqsave(&tty->buf.lock, flags);
-	while((tbuf = tty->buf.head) != NULL) {
+	head = tty->buf.head;
+	tty->buf.head = NULL;
+	while((tbuf = head) != NULL) {
 		while ((count = tbuf->commit - tbuf->read) != 0) {
 			char_buf = tbuf->char_buf_ptr + tbuf->read;
 			flag_buf = tbuf->flag_buf_ptr + tbuf->read;
@@ -2802,10 +2804,12 @@ static void flush_to_ldisc(void *private
 			disc->receive_buf(tty, char_buf, flag_buf, count);
 			spin_lock_irqsave(&tty->buf.lock, flags);
 		}
-		if (tbuf->active)
+		if (tbuf->active) {
+			tty->buf.head = head;
 			break;
-		tty->buf.head = tbuf->next;
-		if (tty->buf.head == NULL)
+		}
+		head = tbuf->next;
+		if (head == NULL)
 			tty->buf.tail = NULL;
 		tty_buffer_free(tty, tbuf);
 	}

--

[patch 22/23] Add stable branch to maintainers file

[Greg KH]

[-- Attachment #1: add-stable-branch-to-maintainers-file.patch --]
[-- Type: text/plain, Size: 1134 bytes --]

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

------------------
From: Steven Rostedt <rostedt@goodmis.org>

While helping someone to submit a patch to the stable branch, I noticed
that the stable branch is not listed in the MAINTAINERS file.  This was
after I went there to look for the email addresses for the stable branch
list (stable@kernel.org).

This patch adds the stable branch to the maintainers file so that people
can find where to send patches when they have a fix for the stable team.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 MAINTAINERS |    8 ++++++++
 1 file changed, 8 insertions(+)

--- linux-2.6.17.7.orig/MAINTAINERS
+++ linux-2.6.17.7/MAINTAINERS
@@ -2572,6 +2572,14 @@ M:	dbrownell@users.sourceforge.net
 L:	spi-devel-general@lists.sourceforge.net
 S:	Maintained
 
+STABLE BRANCH:
+P:	Greg Kroah-Hartman
+M:	greg@kroah.com
+P:	Chris Wright
+M:	chrisw@sous-sol.org
+L:	stable@kernel.org
+S:	Maintained
+
 TPM DEVICE DRIVER
 P:	Kylene Hall
 M:	kjhall@us.ibm.com

--

[patch 23/23] Have ext2 reject file handles with bad inode numbers early.

[Greg KH]

[-- Attachment #1: have-ext2-reject-file-handles-with-bad-inode-numbers-early.patch --]
[-- Type: text/plain, Size: 2019 bytes --]

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

------------------
From: Neil Brown <neilb@suse.de>

This prevents bad inode numbers from triggering errors in
ext2_get_inode.


Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ext2/super.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

--- linux-2.6.17.7.orig/fs/ext2/super.c
+++ linux-2.6.17.7/fs/ext2/super.c
@@ -252,6 +252,46 @@ static struct super_operations ext2_sops
 #endif
 };
 
+static struct dentry *ext2_get_dentry(struct super_block *sb, void *vobjp)
+{
+	__u32 *objp = vobjp;
+	unsigned long ino = objp[0];
+	__u32 generation = objp[1];
+	struct inode *inode;
+	struct dentry *result;
+
+	if (ino != EXT2_ROOT_INO && ino < EXT2_FIRST_INO(sb))
+		return ERR_PTR(-ESTALE);
+	if (ino > le32_to_cpu(EXT2_SB(sb)->s_es->s_inodes_count))
+		return ERR_PTR(-ESTALE);
+
+	/* iget isn't really right if the inode is currently unallocated!!
+	 * ext2_read_inode currently does appropriate checks, but
+	 * it might be "neater" to call ext2_get_inode first and check
+	 * if the inode is valid.....
+	 */
+	inode = iget(sb, ino);
+	if (inode == NULL)
+		return ERR_PTR(-ENOMEM);
+	if (is_bad_inode(inode)
+	    || (generation && inode->i_generation != generation)
+		) {
+		/* we didn't find the right inode.. */
+		iput(inode);
+		return ERR_PTR(-ESTALE);
+	}
+	/* now to find a dentry.
+	 * If possible, get a well-connected one
+	 */
+	result = d_alloc_anon(inode);
+	if (!result) {
+		iput(inode);
+		return ERR_PTR(-ENOMEM);
+	}
+	return result;
+}
+
+
 /* Yes, most of these are left as NULL!!
  * A NULL value implies the default, which works with ext2-like file
  * systems, but can be improved upon.
@@ -259,6 +299,7 @@ static struct super_operations ext2_sops
  */
 static struct export_operations ext2_export_ops = {
 	.get_parent = ext2_get_parent,
+	.get_dentry = ext2_get_dentry,
 };
 
 static unsigned long get_sb_block(void **data)

--

Re: [patch 00/23] -stable review

[Grant Coady]

On Thu, 3 Aug 2006 22:38:07 -0700, Greg KH <gregkh@suse.de> wrote:

>This is the start of the stable review cycle for the 2.6.17.8 release.
>There are 23 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 Sunday, August 6, 05:00:00 UTC.  Anything
>received after that time might be too late.
>
>I've also posted a roll-up patch with all changes in it if people want
>to test it out.  It can be found at:
>
>	kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz

It wasn't clear that this is a delta 2.6.17.7 -> 2.6.17.8 patch ;)

Didn't bump version:
grant@sempro:~/linux/linux-2.6.17.8-rc1$ head -5 Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = .7
NAME=Crazed Snow-Weasel

On the bright side, it compiled and runs ;)

Grant.

Re: [patch 00/23] -stable review

[Greg KH]

On Fri, Aug 04, 2006 at 05:18:44PM +1000, Grant Coady wrote:
> On Thu, 3 Aug 2006 22:38:07 -0700, Greg KH <gregkh@suse.de> wrote:
> >I've also posted a roll-up patch with all changes in it if people want
> >to test it out.  It can be found at:
> >
> >	kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
> 
> It wasn't clear that this is a delta 2.6.17.7 -> 2.6.17.8 patch ;)
> 
> Didn't bump version:
> grant@sempro:~/linux/linux-2.6.17.8-rc1$ head -5 Makefile
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 17
> EXTRAVERSION = .7
> NAME=Crazed Snow-Weasel

Ugh, you are right, I normally don't bump the version until I commit the
patches to the tree.  Sorry about that, I'll fix that up next time.

> On the bright side, it compiled and runs ;)

Great, thanks for testing and letting us know, I really appreciate it.

greg k-h

Re: [patch 00/23] -stable review

[Jesper Juhl]

On 04/08/06, Greg KH <gregkh@suse.de> wrote:
> This is the start of the stable review cycle for the 2.6.17.8 release.
> There are 23 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 Sunday, August 6, 05:00:00 UTC.  Anything
> received after that time might be too late.
>
> I've also posted a roll-up patch with all changes in it if people want
> to test it out.  It can be found at:
>
>         kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
>

Any chance that the fixes in the (latest) e1000 driver version
7.1.9-k4 will get backported?

I can't run 2.6.17.7 on at least one of my servers due to bugs in the
driver that are fixed in the latest e1000 version.
I looked through the -stable patches but didn't find anything that
would fix my problem.
I get messages along the lines of "kernel: Virtual device XXX asks to
queue packet!" and the device then refuses to work.
The last kernel where I know for a fact that it worked OK is 2.6.11,
so that's what the server is currently running.

Getting the fix for that problem backported to -stable would really make my day.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [patch 00/23] -stable review

[Patrick McHardy]

Jesper Juhl wrote:
> Any chance that the fixes in the (latest) e1000 driver version
> 7.1.9-k4 will get backported?
> 
> I get messages along the lines of "kernel: Virtual device XXX asks to
> queue packet!" and the device then refuses to work.
> The last kernel where I know for a fact that it worked OK is 2.6.11,
> so that's what the server is currently running.

That message should never be seen on a device with a queue. What device
exactly is "XXX"?

Re: [patch 00/23] -stable review

[Jesper Juhl]

On 04/08/06, Patrick McHardy <kaber@trash.net> wrote:
> Jesper Juhl wrote:
> > Any chance that the fixes in the (latest) e1000 driver version
> > 7.1.9-k4 will get backported?
> >
> > I get messages along the lines of "kernel: Virtual device XXX asks to
> > queue packet!" and the device then refuses to work.
> > The last kernel where I know for a fact that it worked OK is 2.6.11,
> > so that's what the server is currently running.
>
> That message should never be seen on a device with a queue. What device
> exactly is "XXX"?
>
eth0.20


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [patch 00/23] -stable review

[Patrick McHardy]

Jesper Juhl wrote:
> On 04/08/06, Patrick McHardy <kaber@trash.net> wrote:
> 
>> Jesper Juhl wrote:
>> > Any chance that the fixes in the (latest) e1000 driver version
>> > 7.1.9-k4 will get backported?
>> >
>> > I get messages along the lines of "kernel: Virtual device XXX asks to
>> > queue packet!" and the device then refuses to work.
>> > The last kernel where I know for a fact that it worked OK is 2.6.11,
>> > so that's what the server is currently running.
>>
>> That message should never be seen on a device with a queue. What device
>> exactly is "XXX"?
>>
> eth0.20

This problem is fixed by "[patch 10/23] VLAN state handling fix".

Re: [patch 00/23] -stable review

[Jesper Juhl]

On 04/08/06, Patrick McHardy <kaber@trash.net> wrote:
> Jesper Juhl wrote:
> > On 04/08/06, Patrick McHardy <kaber@trash.net> wrote:
> >
> >> Jesper Juhl wrote:
> >> > Any chance that the fixes in the (latest) e1000 driver version
> >> > 7.1.9-k4 will get backported?
> >> >
> >> > I get messages along the lines of "kernel: Virtual device XXX asks to
> >> > queue packet!" and the device then refuses to work.
> >> > The last kernel where I know for a fact that it worked OK is 2.6.11,
> >> > so that's what the server is currently running.
> >>
> >> That message should never be seen on a device with a queue. What device
> >> exactly is "XXX"?
> >>
> > eth0.20
>
> This problem is fixed by "[patch 10/23] VLAN state handling fix".
>
Ahh, ok, I didn't realize that. That's great news, then there's a
chance that 2.6.17.8 will work for me - I'll certainly test that and
report back. I can't test on that server until monday though, so I
won't be able to test it before 2.6.17.8 is out.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [patch 00/23] -stable review

[Andrew Morton]

On Fri, 4 Aug 2006 11:04:36 +0200
"Jesper Juhl" <jesper.juhl@gmail.com> wrote:

> On 04/08/06, Greg KH <gregkh@suse.de> wrote:
> > This is the start of the stable review cycle for the 2.6.17.8 release.
> > There are 23 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 Sunday, August 6, 05:00:00 UTC.  Anything
> > received after that time might be too late.
> >
> > I've also posted a roll-up patch with all changes in it if people want
> > to test it out.  It can be found at:
> >
> >         kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
> >
> 
> Any chance that the fixes in the (latest) e1000 driver version
> 7.1.9-k4 will get backported?

The post-2.6.17 e1000 changes are massive.

> I can't run 2.6.17.7 on at least one of my servers due to bugs in the
> driver that are fixed in the latest e1000 version.
> I looked through the -stable patches but didn't find anything that
> would fix my problem.
> I get messages along the lines of "kernel: Virtual device XXX asks to
> queue packet!" and the device then refuses to work.
> The last kernel where I know for a fact that it worked OK is 2.6.11,
> so that's what the server is currently running.
> 
> Getting the fix for that problem backported to -stable would really make my day.


Perhaps the e1000 developers can help us to identify the particular fix for
this problem.

That's assuming that it is actually fixed.  Does 2.6.18-current fix the bug?

Re: [patch 00/23] -stable review

[Jesper Juhl]

On 04/08/06, Andrew Morton <akpm@osdl.org> wrote:
> On Fri, 4 Aug 2006 11:04:36 +0200
> "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>
> > On 04/08/06, Greg KH <gregkh@suse.de> wrote:
> > > This is the start of the stable review cycle for the 2.6.17.8 release.
> > > There are 23 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 Sunday, August 6, 05:00:00 UTC.  Anything
> > > received after that time might be too late.
> > >
> > > I've also posted a roll-up patch with all changes in it if people want
> > > to test it out.  It can be found at:
> > >
> > >         kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
> > >
> >
> > Any chance that the fixes in the (latest) e1000 driver version
> > 7.1.9-k4 will get backported?
>
> The post-2.6.17 e1000 changes are massive.
>
I know, I tried backporting the new driver but gave up.


> > I can't run 2.6.17.7 on at least one of my servers due to bugs in the
> > driver that are fixed in the latest e1000 version.
> > I looked through the -stable patches but didn't find anything that
> > would fix my problem.
> > I get messages along the lines of "kernel: Virtual device XXX asks to
> > queue packet!" and the device then refuses to work.
> > The last kernel where I know for a fact that it worked OK is 2.6.11,
> > so that's what the server is currently running.
> >
> > Getting the fix for that problem backported to -stable would really make my day.
>
>
> Perhaps the e1000 developers can help us to identify the particular fix for
> this problem.
>
That's what I was hoping for...


> That's assuming that it is actually fixed.  Does 2.6.18-current fix the bug?
>
I tested 2.6.18-rc3-git3 and that did indeed fix the e1000 bug, but I
can't run that kernel since xfs crashes :-(  (I've send a sepperate
bug report for that)


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [patch 00/23] -stable review

[Auke Kok]

Jesper Juhl wrote:
> On 04/08/06, Andrew Morton <akpm@osdl.org> wrote:
>> On Fri, 4 Aug 2006 11:04:36 +0200
>> "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>>
>> > On 04/08/06, Greg KH <gregkh@suse.de> wrote:
>> > > This is the start of the stable review cycle for the 2.6.17.8 
>> release.
>> > > There are 23 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 Sunday, August 6, 05:00:00 UTC.  Anything
>> > > received after that time might be too late.
>> > >
>> > > I've also posted a roll-up patch with all changes in it if people 
>> want
>> > > to test it out.  It can be found at:
>> > >
>> > >         
>> kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
>> > >
>> >
>> > Any chance that the fixes in the (latest) e1000 driver version
>> > 7.1.9-k4 will get backported?
>>
>> The post-2.6.17 e1000 changes are massive.
>>
> I know, I tried backporting the new driver but gave up.
> 
> 
>> > I can't run 2.6.17.7 on at least one of my servers due to bugs in the
>> > driver that are fixed in the latest e1000 version.
>> > I looked through the -stable patches but didn't find anything that
>> > would fix my problem.
>> > I get messages along the lines of "kernel: Virtual device XXX asks to
>> > queue packet!" and the device then refuses to work.
>> > The last kernel where I know for a fact that it worked OK is 2.6.11,
>> > so that's what the server is currently running.
>> >
>> > Getting the fix for that problem backported to -stable would really 
>> make my day.
>>
>>
>> Perhaps the e1000 developers can help us to identify the particular 
>> fix for
>> this problem.
>>
> That's what I was hoping for...

I suspect that this will have fixed it, but this is a followup to a patch that 
disables HW CRC stripping. perhaps commit eb0f805... might be involved as 
well, allthough I doubt that.

---
diff-tree f235a2abb27b9396d2108dd2987fb8262cb508a3 (from d3d9e484b2ca502c87156b6
Author: Auke Kok <auke\-jan.h.kok@intel.com>
Date:   Fri Jul 14 16:14:34 2006 -0700

     e1000: remove CRC bytes from measured packet length

     After removing the hardware CRC stripping which causes problems with
     SOL and related issues, we need to compensate for this changed size.

     Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
     Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 1c6bcad..0074a3a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3673,6 +3673,9 @@ #endif

                 length = le16_to_cpu(rx_desc->length);

+               /* adjust length to remove Ethernet CRC */
+               length -= 4;
+
                 if (unlikely(!(status & E1000_RXD_STAT_EOP))) {
                         /* All receives must fit into a single buffer */
                         E1000_DBG("%s: Receive packet consumed multiple"
@@ -3877,8 +3880,9 @@ #endif
                         pci_dma_sync_single_for_device(pdev,
                                 ps_page_dma->ps_page_dma[0],
                                 PAGE_SIZE, PCI_DMA_FROMDEVICE);
+                       /* remove the CRC */
+                       l1 -= 4;
                         skb_put(skb, l1);
-                       length += l1;
                         goto copydone;
                 } /* if */
                 }
@@ -3896,6 +3900,10 @@ #endif
                         skb->data_len += length;
                         skb->truesize += length;
                 }
+
+               /* strip the ethernet crc, problem is we're using pages now so
+                * this whole operation can get a little cpu intensive */
+               pskb_trim(skb, skb->len - 4);

  copydone:
                 e1000_rx_checksum(adapter, staterr,
---

hth,

Auke