Skip to contentSkip to conversation

-stable review

PATCH In review Greg KH 15 participants 48 messages Aug 4, 2006 – Nov 17, 2006

Subsystems (15)
lore
Share & tools
lore
author
#9 lore raw

PATCH 9/23 : Update frag_list in pskb_trim

In reply to Greg KH

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

------------------
From: Herbert Xu <[email protected]>

[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 :)

---
 include/linux/skbuff.h |   24 +++++------
 net/core/skbuff.c      |  106 ++++++++++++++++++++++++++++++++++---------------
 2 files changed, 86 insertions(+), 44 deletions(-)
include/linux/skbuff.h +12 -12
@@ -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)
net/core/skbuff.c +74 -32

140 lines not on this page · raw message

--

author
#19 lore raw

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

In reply to Greg KH

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

------------------
From: Neil Brown <[email protected]>

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 <[email protected]> for reporting the problem.

---
 net/sunrpc/cache.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
net/sunrpc/cache.c +5 -1
@@ -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++;

--

author
#1 lore raw

PATCH 1/23 PCI: fix issues with extended conf space when MMCONFIG disabled because of e820

In reply to Greg KH

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

------------------
From: Chuck Ebbert <[email protected]>

Quoted 2 lines · Andi Kleen

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.

---
 arch/i386/pci/mmconfig.c   |    9 ++++++---
 arch/x86_64/pci/mmconfig.c |   13 +++++++++----
 2 files changed, 15 insertions(+), 7 deletions(-)
arch/i386/pci/mmconfig.c +6 -3
@@ -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;
 	}
arch/x86_64/pci/mmconfig.c +9 -4
@@ -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);

--

author
#2 lore raw

PATCH 2/23 Dont allow chmod() on the /proc/<pid>/ files

In reply to Greg KH

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

------------------
From: Marcel Holtmann <[email protected]>

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.

---
 fs/proc/base.c |   33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)
fs/proc/base.c +32 -1
@@ -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,
 };
 
 /**

--

author
#3 lore raw

PATCH 3/23 : H.323 helper: fix possible NULL-ptr dereference

In reply to Greg KH

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

------------------
From: Patrick McHardy <[email protected]>

[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 <[email protected]> and Isil Dillig <[email protected]>.

---
 net/ipv4/netfilter/ip_conntrack_helper_h323.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/netfilter/ip_conntrack_helper_h323.c +1 -1
@@ -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;
 }

--

author
#4 lore raw

PATCH 4/23 scx200_acb: Fix the state machine

In reply to Greg KH

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

------------------
From: Thomas Andrews <[email protected]>

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.

---
 drivers/i2c/busses/scx200_acb.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/i2c/busses/scx200_acb.c +6 -6
@@ -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:

--

author
#7 lore raw

PATCH 7/23 sky2: NAPI bug

In reply to Greg KH

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

------------------
From: Stephen Hemminger <[email protected]>

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.

---
 drivers/net/sky2.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/net/sky2.c +1 -4
@@ -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);

--

author
#8 lore raw

PATCH 8/23 UHCI: Fix handling of short last packet

In reply to Greg KH

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

------------------
From: Alan Stern <[email protected]>

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.

---
 drivers/usb/host/uhci-q.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/host/uhci-q.c +4 -2
@@ -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;

--

author
#5 lore raw

PATCH 5/23 scx200_acb: Fix the block transactions

In reply to Greg KH

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

------------------
From: Jean Delvare <[email protected]>

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 :)

---
 drivers/i2c/busses/scx200_acb.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/i2c/busses/scx200_acb.c +6 -2
@@ -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) */

--

author
#11 lore raw

PATCH 11/23 Sparc64 quad-float emulation fix

In reply to Greg KH

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

------------------
From: David Miller <[email protected]>

[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

---
 include/asm-sparc64/sfp-machine.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/asm-sparc64/sfp-machine.h +1 -1
@@ -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)

--

author
#18 lore raw

PATCH 13/23 ieee1394: sbp2: enable auto spin-up for Maxtor disks

In reply to Greg KH

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

------------------
From: Stefan Richter <[email protected]>

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.

---
 drivers/ieee1394/sbp2.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/ieee1394/sbp2.c +3 -0
@@ -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;
 }
 

--

author
#30 lore raw

PATCH 17/23 e1000: add forgotten PCI ID for supported device

In reply to Greg KH

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

------------------
From: Auke Kok <[email protected]>

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.

---
 drivers/net/e1000/e1000_hw.c |    1 +
 drivers/net/e1000/e1000_hw.h |    1 +
 2 files changed, 2 insertions(+)
drivers/net/e1000/e1000_hw.c +1 -0
@@ -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:
drivers/net/e1000/e1000_hw.h +1 -0
@@ -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

--

author
#31 lore raw

PATCH 18/23 cond_resched() fix

In reply to Greg KH

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

------------------
From: Andrew Morton <[email protected]>

[PATCH] cond_resched() fix

Fix a bug identified by Zou Nan hai <[email protected]>:

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.

---
 kernel/sched.c |   25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)
kernel/sched.c +13 -12
@@ -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.
  *

--

author
#37 lore raw

PATCH 23/23 Have ext2 reject file handles with bad inode numbers early.

In reply to Greg KH

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

------------------
From: Neil Brown <[email protected]>

This prevents bad inode numbers from triggering errors in ext2_get_inode.

---
 fs/ext2/super.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
fs/ext2/super.c +41 -0
@@ -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)

--

author
#35 lore raw

PATCH 21/23 tty serialize flush_to_ldisc

In reply to Greg KH

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

------------------
From: Paul Fulghum <[email protected]>

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

---
 drivers/char/tty_io.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/char/tty_io.c +9 -5
@@ -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);
 	}

--

author
#32 lore raw

PATCH 19/23 Fix budget-av compile failure

In reply to Greg KH

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

------------------
From: Andrew de Quincey <[email protected]>

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. :(

---
 drivers/media/dvb/ttpci/budget-av.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/media/dvb/ttpci/budget-av.c +5 -5
@@ -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));

--

author
#36 lore raw

PATCH 22/23 Add stable branch to maintainers file

In reply to Greg KH

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

------------------
From: Steven Rostedt <[email protected]>

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 ([email protected]).

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.

---
 MAINTAINERS |    8 ++++++++
 1 file changed, 8 insertions(+)
MAINTAINERS +8 -0
@@ -2572,6 +2572,14 @@ M:	[email protected]
 L:	[email protected]
 S:	Maintained
 
+STABLE BRANCH:
+P:	Greg Kroah-Hartman
+M:	[email protected]
+P:	Chris Wright
+M:	[email protected]
+L:	[email protected]
+S:	Maintained
+
 TPM DEVICE DRIVER
 P:	Kylene Hall
 M:	[email protected]

--

author
#20 lore raw

PATCH 15/23 ext3 -nobh option causes oops

In reply to Greg KH

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

------------------
From: Badari Pulavarty <[email protected]>

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().

---
 fs/ext3/inode.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext3/inode.c +3 -3
@@ -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);

--

author
#24 lore raw

PATCH 16/23 ext3: avoid triggering ext3_error on bad NFS file handle

In reply to Greg KH

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

------------------
From: Neil Brown <[email protected]>

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.

[[email protected]: fix off-by-one error]
Cc Marcel Holtmann <[email protected]>
Cc "Stephen C. Tweedie" <[email protected]>
Cc Eric Sandeen <[email protected]>
---
 fs/ext3/inode.c         |   13 +++++++------
 fs/ext3/namei.c         |   15 +++++++++++++--
 include/linux/ext3_fs.h |    9 +++++++++
 3 files changed, 29 insertions(+), 8 deletions(-)
fs/ext3/inode.c +7 -6
@@ -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");
fs/ext3/namei.c +13 -2
@@ -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);
include/linux/ext3_fs.h +9 -0
@@ -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

--

author
#33 lore raw

PATCH 20/23 S390: fix futex_atomic_cmpxchg_inatomic

In reply to Greg KH

-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.

---
 include/asm-s390/futex.h |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
include/asm-s390/futex.h +3 -2
@@ -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"

--

author
#12 lore raw

PATCH 12/23 invalidate_bdev() speedup

In reply to Greg KH

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

------------------
From: Andrew Morton <[email protected]>

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.

---
 fs/buffer.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
fs/buffer.c +6 -1
@@ -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);
 }
 
 /*

--

author
#6 lore raw

PATCH 6/23 i2c: Fix ignore module parameter handling in i2c-core

In reply to Greg KH

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

------------------
From: "Mark M. Hoffman" <[email protected]>

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

---
 drivers/i2c/i2c-core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/i2c-core.c +2 -2
@@ -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;

--

author
#10 lore raw

PATCH 10/23 VLAN state handling fix

In reply to Greg KH

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

------------------
From: Stefan Rompf <[email protected]>

[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.

---
 net/8021q/vlan.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
net/8021q/vlan.c +3 -5
@@ -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.

--

Greg KH

author
#0 lore raw

cover -stable review

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 [email protected] 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

#38 lore raw
Quoted 11 lines · 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 [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Quoted 7 lines

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.

author
#39 lore raw
Quoted 8 lines · Grant Coady
Quoted 4 lines · Greg KH

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 ;)

Quoted 7 lines

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.

Quoted 1 line

On the bright side, it compiled and runs ;)

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

greg k-h

#13 lore raw

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

In reply to Greg KH
Quoted 1 line · Greg KH

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

This is a feature. Definitly not -stable material.

#40 lore raw
In reply to Greg KH
Quoted 11 lines · 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 [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Quoted 8 lines

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.

Signature · 3 lines
Jesper Juhl <[email protected]>
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
#14 lore raw

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

In reply to Christoph Hellwig
Quoted 4 lines · On Fri, 4 Aug 2006 09:50:13 +0100 Christoph Hellwig <[email protected]> wrote:
Quoted 1 line · Greg KH

-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.

#41 lore raw
In reply to Jesper Juhl
Quoted 7 lines · Jesper Juhl

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"?

#42 lore raw
Quoted 4 lines · Patrick McHardy
Quoted 3 lines · Jesper Juhl

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

Quoted 8 lines
Quoted 4 lines

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

Signature · 3 lines
Jesper Juhl <[email protected]>
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
#45 lore raw
In reply to Jesper Juhl
Quoted 15 lines · On Fri, 4 Aug 2006 11:04:36 +0200 "Jesper Juhl" <[email protected]> wrote:
Quoted 14 lines · 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 [email protected] 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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 10 lines

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?

#46 lore raw
Quoted 21 lines · Andrew Morton
Quoted 18 lines · On Fri, 4 Aug 2006 11:04:36 +0200 "Jesper Juhl" <[email protected]> wrote:
Quoted 17 lines · 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 [email protected] 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:

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
        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.

Quoted 9 lines
Quoted 9 lines

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.

Quoted 6 lines
Quoted 1 line

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...

Quoted 2 lines

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)

Signature · 3 lines
Jesper Juhl <[email protected]>
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
#43 lore raw
In reply to Jesper Juhl
Quoted 11 lines · Jesper Juhl
Quoted 9 lines · Patrick McHardy
Quoted 7 lines · Jesper Juhl

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.

Quoted 4 lines
Quoted 3 lines

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".

#44 lore raw
Quoted 12 lines · Patrick McHardy
Quoted 11 lines · Jesper Juhl
Quoted 9 lines · Patrick McHardy
Quoted 7 lines · Jesper Juhl

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.

Quoted 7 lines
Quoted 4 lines
Quoted 3 lines

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.

Signature · 3 lines
Jesper Juhl <[email protected]>
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
#15 lore raw

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

In reply to Andrew Morton
Quoted 10 lines · Andrew Morton
Quoted 4 lines · On Fri, 4 Aug 2006 09:50:13 +0100 Christoph Hellwig <[email protected]> wrote:
Quoted 1 line · Greg KH

-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 :)

Quoted 2 lines

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?

Signature · 1 line
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
#16 lore raw

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

Quoted 6 lines · Arjan van de Ven
Quoted 2 lines · Andrew Morton

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 ....

Quoted 12 lines
Quoted 2 lines

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?

fs/buffer.c +5 -0
+       struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+       if (mapping->nrpages == 0)
+               return;
+
        invalidate_bh_lrus();
Quoted 4 lines

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

#47 lore raw
In reply to Jesper Juhl
Quoted 50 lines · Jesper Juhl
Quoted 29 lines · Andrew Morton
Quoted 2 lines · On Fri, 4 Aug 2006 11:04:36 +0200 "Jesper Juhl" <[email protected]> wrote:
Quoted 1 line · Greg KH

This is the start of the stable review cycle for the 2.6.17.8

release.

Quoted 1 line
Quoted 1 line

There are 23 patches in this series, all will be posted as a

response to

Quoted 1 line
Quoted 1 line

this one. If anyone has any issues with these being applied,

please let

Quoted 1 line
Quoted 1 line

us know. If anyone is a maintainer of the proper subsystem, and

wants

Quoted 3 lines
Quoted 3 lines

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:

Quoted 1 line
Quoted 1 line

line. If you wish to be a reviewer, please email

[email protected] to

Quoted 7 lines
Quoted 7 lines

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

Quoted 3 lines
Quoted 3 lines

to test it out. It can be found at:

Quoted 8 lines

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

Quoted 4 lines
Quoted 1 line

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.

Quoted 9 lines
Quoted 9 lines

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.

Quoted 8 lines
Quoted 7 lines
Quoted 1 line

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\[email protected]>
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.

drivers/net/e1000/e1000_main.c +9 -1
index 1c6bcad..0074a3a 100644
@@ -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

#25 lore raw

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

In reply to Greg KH
Quoted 5 lines · Greg KH

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

------------------
From: Neil Brown <[email protected]>

Quoted 8 lines

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

#26 lore raw

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

Quoted 12 lines · Eric Sandeen
Quoted 11 lines · Greg KH

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

------------------
From: Neil Brown <[email protected]>

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.

Quoted 8 lines
Quoted 2 lines

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.

#17 lore raw

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

In reply to Arjan van de Ven
Quoted 7 lines · On Fri, 04 Aug 2006 15:08:49 +0200 Arjan van de Ven <[email protected]> wrote:
Quoted 6 lines · Andrew Morton
Quoted 3 lines · On Fri, 4 Aug 2006 09:50:13 +0100 Christoph Hellwig <[email protected]> wrote:
Quoted 1 line · Greg KH

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

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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.

Quoted 13 lines
Quoted 2 lines

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?

fs/buffer.c +5 -0
+       struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+       if (mapping->nrpages == 0)
+               return;
+
        invalidate_bh_lrus();
Quoted 4 lines

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).

#27 lore raw

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

In reply to Christoph Hellwig
Quoted 13 lines · Christoph Hellwig
Quoted 12 lines · Eric Sandeen
Quoted 11 lines · Greg KH

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

------------------
From: Neil Brown <[email protected]>

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.

Quoted 6 lines
Quoted 3 lines
Quoted 2 lines

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

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

fs/ext3/super.c +40 -0
Index: 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 {
#34 lore raw

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

In reply to Greg KH
Quoted 7 lines · Greg KH

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

Quoted 8 lines

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.

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!

Signature · 8 lines
blue skies,
  Martin.

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

"Reality continues to ruin my life." - Calvin.
#29 lore raw

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

In reply to Eric Sandeen
Quoted 25 lines · Eric Sandeen
Quoted 15 lines · Christoph Hellwig
Quoted 14 lines · Eric Sandeen
Quoted 13 lines · Greg KH

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

------------------
From: Neil Brown <[email protected]>

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 8 lines

so how's this? (compile tested)

Thanks,
-Eric

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

Thanks, I've queued this up.

greg k-h

#21 lore raw

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

In reply to Greg KH

It seems this patch that went into 2.6.17.8 should also be included in the 2.6.16.x branch, or do I miss anything?

TIA
Adrian

Quoted 47 lines · Greg KH

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

------------------
From: Badari Pulavarty <[email protected]>

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().

---
 fs/ext3/inode.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext3/inode.c +3 -3
@@ -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);
#22 lore raw

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

Quoted 3 lines · Adrian Bunk

It seems this patch that went into 2.6.17.8 should also be included in the 2.6.16.x branch, or do I miss anything?

Yes. This is needed for 2.6.16.x branch also.

Thanks,
Badari

Quoted 48 lines · Greg KH
Quoted 47 lines

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

------------------
From: Badari Pulavarty <[email protected]>

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().

---
 fs/ext3/inode.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext3/inode.c +3 -3
@@ -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);
#23 lore raw

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

Quoted 7 lines · Badari Pulavarty
Quoted 3 lines · Adrian Bunk

It seems this patch that went into 2.6.17.8 should also be included in the 2.6.16.x branch, or do I miss anything?

Yes. This is needed for 2.6.16.x branch also.

Thanks, I've applied it.

Quoted 2 lines

Thanks,
Badari

cu
Adrian

Signature · 4 lines
       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed