[patch 00/20] 2.6.17-stable review

[patch 00/20] 2.6.17-stable review

[Greg KH]

This is the start of the stable review cycle for the next 2.6.17.y
release.  There are 20 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 Wed, Auguest 23, 18:00:00 UTC.  Anything
received after that time might be too late.

thanks,

the -stable release team

[patch 01/20] Have ext3 reject file handles with bad inode numbers early

[Greg KH]

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

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

------------------
blatantly ripped off from Neil Brown's ext2 patch.


Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ext3/super.c |   40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

--- linux-2.6.17.8.orig/fs/ext3/super.c
+++ linux-2.6.17.8/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 {

--

[patch 02/20] sky2: phy power problem on 88e805x

[Greg KH]

[-- Attachment #1: sky2-phy-power-problem-on-88e805x.patch --]
[-- Type: text/plain, Size: 1118 bytes --]

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

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

On the 88E805X chipsets (used in laptops), the PHY was not getting powered
out of shutdown properly. The variable reg1 was getting reused incorrectly.
This is probably the cause of the bug.
	http://bugzilla.kernel.org/show_bug.cgi?id=6471

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- linux-2.6.17.8.orig/drivers/net/sky2.c
+++ linux-2.6.17.8/drivers/net/sky2.c
@@ -233,6 +233,8 @@ static void sky2_set_power_state(struct 
 			if (hw->ports > 1)
 				reg1 |= PCI_Y2_PHY2_COMA;
 		}
+		sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
+		udelay(100);
 
 		if (hw->chip_id == CHIP_ID_YUKON_EC_U) {
 			sky2_write16(hw, B0_CTST, Y2_HW_WOL_ON);
@@ -243,8 +245,6 @@ static void sky2_set_power_state(struct 
 			sky2_pci_write32(hw, PCI_DEV_REG5, 0);
 		}
 
-		sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
-
 		break;
 
 	case PCI_D3hot:

--

[patch 03/20] Kill HASH_HIGHMEM from route cache hash sizing

[Greg KH]

[-- Attachment #1: kill-hash_highmem-from-route-cache-hash-sizing.patch --]
[-- Type: text/plain, Size: 1204 bytes --]

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

------------------
From: Kirill Korotaev <dev@sw.ru>

[IPV4]: Limit rt cache size properly.

During OpenVZ stress testing we found that UDP traffic with random src
can generate too much excessive rt hash growing leading finally to OOM
and kernel panics.

It was found that for 4GB i686 system (having 1048576 total pages and
225280 normal zone pages) kernel allocates the following route hash:
syslog: IP route cache hash table entries: 262144 (order: 8, 1048576
bytes) => ip_rt_max_size = 4194304 entries, i.e.  max rt size is
4194304 * 256b = 1Gb of RAM > normal_zone

Attached the patch which removes HASH_HIGHMEM flag from
alloc_large_system_hash() call.

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

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

--- linux-2.6.17.8.orig/net/ipv4/route.c
+++ linux-2.6.17.8/net/ipv4/route.c
@@ -3144,7 +3144,7 @@ int __init ip_rt_init(void)
 					rhash_entries,
 					(num_physpages >= 128 * 1024) ?
 					15 : 17,
-					HASH_HIGHMEM,
+					0,
 					&rt_hash_log,
 					&rt_hash_mask,
 					0);

--

[patch 04/20] Fix timer race in dst GC code

[Greg KH]

[-- Attachment #1: fix-timer-race-in-dst-gc-code.patch --]
[-- Type: text/plain, Size: 2076 bytes --]

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

------------------
From: Dmitry Mishin <dim@openvz.org>

[NET]: add_timer -> mod_timer() in dst_run_gc()

Patch from Dmitry Mishin <dim@openvz.org>:

Replace add_timer() by mod_timer() in dst_run_gc
in order to avoid BUG message.

   CPU1                            CPU2
dst_run_gc()  entered           dst_run_gc() entered
spin_lock(&dst_lock)                   .....
del_timer(&dst_gc_timer)         fail to get lock
   ....                         mod_timer() <--- puts
					     timer back
					     to the list
add_timer(&dst_gc_timer) <--- BUG because timer is in list already.

Found during OpenVZ internal testing.

At first we thought that it is OpenVZ specific as we
added dst_run_gc(0) call in dst_dev_event(),
but as Alexey pointed to me it is possible to trigger
this condition in mainstream kernel.

F.e. timer has fired on CPU2, but the handler was preeempted
by an irq before dst_lock is tried.
Meanwhile, someone on CPU1 adds an entry to gc list and
starts the timer.
If CPU2 was preempted long enough, this timer can expire
simultaneously with resuming timer handler on CPU1, arriving
exactly to the situation described.

Signed-off-by: Dmitry Mishin <dim@openvz.org>
Signed-off-by: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/core/dst.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.17.8.orig/net/core/dst.c
+++ linux-2.6.17.8/net/core/dst.c
@@ -95,12 +95,11 @@ static void dst_run_gc(unsigned long dum
 		dst_gc_timer_inc = DST_GC_INC;
 		dst_gc_timer_expires = DST_GC_MIN;
 	}
-	dst_gc_timer.expires = jiffies + dst_gc_timer_expires;
 #if RT_CACHE_DEBUG >= 2
 	printk("dst_total: %d/%d %ld\n",
 	       atomic_read(&dst_total), delayed,  dst_gc_timer_expires);
 #endif
-	add_timer(&dst_gc_timer);
+	mod_timer(&dst_gc_timer, jiffies + dst_gc_timer_expires);
 
 out:
 	spin_unlock(&dst_lock);

--

[patch 05/20] Fix IFLA_ADDRESS handling

[Greg KH]

[-- Attachment #1: fix-ifla_address-handling.patch --]
[-- Type: text/plain, Size: 1484 bytes --]

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

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

[RTNETLINK]: Fix IFLA_ADDRESS handling.

The ->set_mac_address handlers expect a pointer to a
sockaddr which contains the MAC address, whereas
IFLA_ADDRESS provides just the MAC address itself.

So whip up a sockaddr to wrap around the netlink
attribute for the ->set_mac_address call.

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

---
 net/core/rtnetlink.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- linux-2.6.17.8.orig/net/core/rtnetlink.c
+++ linux-2.6.17.8/net/core/rtnetlink.c
@@ -395,6 +395,9 @@ static int do_setlink(struct sk_buff *sk
 	}
 
 	if (ida[IFLA_ADDRESS - 1]) {
+		struct sockaddr *sa;
+		int len;
+
 		if (!dev->set_mac_address) {
 			err = -EOPNOTSUPP;
 			goto out;
@@ -406,7 +409,17 @@ static int do_setlink(struct sk_buff *sk
 		if (ida[IFLA_ADDRESS - 1]->rta_len != RTA_LENGTH(dev->addr_len))
 			goto out;
 
-		err = dev->set_mac_address(dev, RTA_DATA(ida[IFLA_ADDRESS - 1]));
+		len = sizeof(sa_family_t) + dev->addr_len;
+		sa = kmalloc(len, GFP_KERNEL);
+		if (!sa) {
+			err = -ENOMEM;
+			goto out;
+		}
+		sa->sa_family = dev->type;
+		memcpy(sa->sa_data, RTA_DATA(ida[IFLA_ADDRESS - 1]),
+		       dev->addr_len);
+		err = dev->set_mac_address(dev, sa);
+		kfree(sa);
 		if (err)
 			goto out;
 		send_addr_notify = 1;

--

[patch 06/20] Fix BeFS slab corruption

[Greg KH]

[-- Attachment #1: fix-befs-slab-corruption.patch --]
[-- Type: text/plain, Size: 2207 bytes --]

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

------------------
From: Diego Calleja <diegocg@gmail.com>

In bugzilla #6941, Jens Kilian reported:

"The function befs_utf2nls (in fs/befs/linuxvfs.c) writes a 0 byte past the
end of a block of memory allocated via kmalloc(), leading to memory
corruption.  This happens only for filenames which are pure ASCII and a
multiple of 4 bytes in length.  [...]

Without DEBUG_SLAB, this leads to further corruption and hard lockups; I
believe this is the bug which has made kernels later than 2.6.8 unusable
for me.  (This must be due to changes in memory management, the bug has
been in the BeFS driver since the time it was introduced (AFAICT).)

Steps to reproduce:
Create a directory (in BeOS, naturally :-) with files named, e.g.,
"1", "22", "333", "4444", ...  Mount it in Linux and do an "ls" or "find""

This patch implements the suggested fix. Credits to Jens Kilian for
debugging the problem and finding the right fix.

Signed-off-by: Diego Calleja <diegocg@gmail.com>
Cc: Jens Kilian <jjk@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/befs/linuxvfs.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- linux-2.6.17.8.orig/fs/befs/linuxvfs.c
+++ linux-2.6.17.8/fs/befs/linuxvfs.c
@@ -512,7 +512,11 @@ befs_utf2nls(struct super_block *sb, con
 	wchar_t uni;
 	int unilen, utflen;
 	char *result;
-	int maxlen = in_len; /* The utf8->nls conversion can't make more chars */
+	/* The utf8->nls conversion won't make the final nls string bigger
+	 * than the utf one, but if the string is pure ascii they'll have the
+	 * same width and an extra char is needed to save the additional \0
+	 */
+	int maxlen = in_len + 1;
 
 	befs_debug(sb, "---> utf2nls()");
 
@@ -588,7 +592,10 @@ befs_nls2utf(struct super_block *sb, con
 	wchar_t uni;
 	int unilen, utflen;
 	char *result;
-	int maxlen = 3 * in_len;
+	/* There're nls characters that will translate to 3-chars-wide UTF-8
+	 * characters, a additional byte is needed to save the final \0
+	 * in special cases */
+	int maxlen = (3 * in_len) + 1;
 
 	befs_debug(sb, "---> nls2utf()\n");
 

--

[patch 07/20] disable debugging version of write_lock()

[Greg KH]

[-- Attachment #1: disable-debugging-version-of-write_lock.patch --]
[-- Type: text/plain, Size: 1917 bytes --]

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

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

We've confirmed that the debug version of write_lock() can get stuck for long
enough to cause NMI watchdog timeouts and hence a crash.

We don't know why, yet.   Disable it for now.

Also disable the similar read_lock() code.  Just in case.

Thanks to Dave Olson <olson@unixfolk.com> for reporting and testing.

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

---
 lib/spinlock_debug.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- linux-2.6.17.8.orig/lib/spinlock_debug.c
+++ linux-2.6.17.8/lib/spinlock_debug.c
@@ -137,6 +137,7 @@ static void rwlock_bug(rwlock_t *lock, c
 
 #define RWLOCK_BUG_ON(cond, lock, msg) if (unlikely(cond)) rwlock_bug(lock, msg)
 
+#if 0		/* __write_lock_debug() can lock up - maybe this can too? */
 static void __read_lock_debug(rwlock_t *lock)
 {
 	int print_once = 1;
@@ -159,12 +160,12 @@ static void __read_lock_debug(rwlock_t *
 		}
 	}
 }
+#endif
 
 void _raw_read_lock(rwlock_t *lock)
 {
 	RWLOCK_BUG_ON(lock->magic != RWLOCK_MAGIC, lock, "bad magic");
-	if (unlikely(!__raw_read_trylock(&lock->raw_lock)))
-		__read_lock_debug(lock);
+	__raw_read_lock(&lock->raw_lock);
 }
 
 int _raw_read_trylock(rwlock_t *lock)
@@ -210,6 +211,7 @@ static inline void debug_write_unlock(rw
 	lock->owner_cpu = -1;
 }
 
+#if 0		/* This can cause lockups */
 static void __write_lock_debug(rwlock_t *lock)
 {
 	int print_once = 1;
@@ -232,12 +234,12 @@ static void __write_lock_debug(rwlock_t 
 		}
 	}
 }
+#endif
 
 void _raw_write_lock(rwlock_t *lock)
 {
 	debug_write_lock_before(lock);
-	if (unlikely(!__raw_write_trylock(&lock->raw_lock)))
-		__write_lock_debug(lock);
+	__raw_write_lock(&lock->raw_lock);
 	debug_write_lock_after(lock);
 }
 

--

[patch 08/20] ipx: header length validation needed

[Greg KH]

[-- Attachment #1: ipx-header-length-validation-needed.patch --]
[-- Type: text/plain, Size: 882 bytes --]

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

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

This patch will linearize and check there is enough data.
It handles the pprop case as well as avoiding a whole audit of
the routing code.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>

---
 net/ipx/af_ipx.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.17.8.orig/net/ipx/af_ipx.c
+++ linux-2.6.17.8/net/ipx/af_ipx.c
@@ -1647,7 +1647,8 @@ static int ipx_rcv(struct sk_buff *skb, 
 	ipx_pktsize	= ntohs(ipx->ipx_pktsize);
 	
 	/* Too small or invalid header? */
-	if (ipx_pktsize < sizeof(struct ipxhdr) || ipx_pktsize > skb->len)
+	if (ipx_pktsize < sizeof(struct ipxhdr)
+	   || !pskb_may_pull(skb, ipx_pktsize))
 		goto drop;
                         
 	if (ipx->ipx_checksum != IPX_NO_CHECKSUM &&

--

[patch 09/20] tpm: interrupt clear fix

[Greg KH]

[-- Attachment #1: tpm-interrupt-clear-fix.patch --]
[-- Type: text/plain, Size: 802 bytes --]

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

------------------
From: Kylene Jo Hall <kjhall@us.ibm.com>

Under stress testing I found that the interrupt is not always cleared.
This is a bug and this patch should go into 2.6.18 and 2.6.17.x.

Signed-off-by: Kylene Hall <kjhall@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/tpm/tpm_tis.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.17.8.orig/drivers/char/tpm/tpm_tis.c
+++ linux-2.6.17.8/drivers/char/tpm/tpm_tis.c
@@ -424,6 +424,7 @@ static irqreturn_t tis_int_handler(int i
 	iowrite32(interrupt,
 		  chip->vendor.iobase +
 		  TPM_INT_STATUS(chip->vendor.locality));
+	ioread32(chip->vendor.iobase + TPM_INT_STATUS(chip->vendor.locality));
 	return IRQ_HANDLED;
 }
 

--

[patch 10/20] : ulog: fix panic on SMP kernels

[Greg KH]

[-- Attachment #1: ulog-fix-panic-on-smp-kernels.patch --]
[-- Type: text/plain, Size: 2114 bytes --]

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

------------------
From: Mark Huang <mlhuang@cs.princeton.edu>

[NETFILTER]: ulog: fix panic on SMP kernels

Fix kernel panic on various SMP machines. The culprit is a null
ub->skb in ulog_send(). If ulog_timer() has already been scheduled on
one CPU and is spinning on the lock, and ipt_ulog_packet() flushes the
queue on another CPU by calling ulog_send() right before it exits,
there will be no skbuff when ulog_timer() acquires the lock and calls
ulog_send(). Cancelling the timer in ulog_send() doesn't help because
it has already been scheduled and is running on the first CPU.

Similar problem exists in ebt_ulog.c and nfnetlink_log.c.

Signed-off-by: Mark Huang <mlhuang@cs.princeton.edu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/bridge/netfilter/ebt_ulog.c |    3 +++
 net/ipv4/netfilter/ipt_ULOG.c   |    5 +++++
 net/netfilter/nfnetlink_log.c   |    3 +++
 3 files changed, 11 insertions(+)

--- linux-2.6.17.9.orig/net/bridge/netfilter/ebt_ulog.c
+++ linux-2.6.17.9/net/bridge/netfilter/ebt_ulog.c
@@ -75,6 +75,9 @@ static void ulog_send(unsigned int nlgro
 	if (timer_pending(&ub->timer))
 		del_timer(&ub->timer);
 
+	if (!ub->skb)
+		return;
+
 	/* last nlmsg needs NLMSG_DONE */
 	if (ub->qlen > 1)
 		ub->lastnlh->nlmsg_type = NLMSG_DONE;
--- linux-2.6.17.9.orig/net/ipv4/netfilter/ipt_ULOG.c
+++ linux-2.6.17.9/net/ipv4/netfilter/ipt_ULOG.c
@@ -116,6 +116,11 @@ static void ulog_send(unsigned int nlgro
 		del_timer(&ub->timer);
 	}
 
+	if (!ub->skb) {
+		DEBUGP("ipt_ULOG: ulog_send: nothing to send\n");
+		return;
+	}
+
 	/* last nlmsg needs NLMSG_DONE */
 	if (ub->qlen > 1)
 		ub->lastnlh->nlmsg_type = NLMSG_DONE;
--- linux-2.6.17.9.orig/net/netfilter/nfnetlink_log.c
+++ linux-2.6.17.9/net/netfilter/nfnetlink_log.c
@@ -366,6 +366,9 @@ __nfulnl_send(struct nfulnl_instance *in
 	if (timer_pending(&inst->timer))
 		del_timer(&inst->timer);
 
+	if (!inst->skb)
+		return 0;
+
 	if (inst->qlen > 1)
 		inst->lastnlh->nlmsg_type = NLMSG_DONE;
 

--

[patch 11/20] sys_getppid oopses on debug kernel

[Greg KH]

[-- Attachment #1: sys_getppid-oopses-on-debug-kernel.patch --]
[-- Type: text/plain, Size: 2427 bytes --]

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

------------------
From: Kirill Korotaev <dev@sw.ru>

sys_getppid() optimization can access a freed memory.  On kernels with
DEBUG_SLAB turned ON, this results in Oops.  As Dave Hansen noted, this
optimization is also unsafe for memory hotplug.

So this patch always takes the lock to be safe.

[oleg@tv-sign.ru: simplifications]

Signed-off-by: Kirill Korotaev <dev@openvz.org>
Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/timer.c |   41 +++++++----------------------------------
 1 file changed, 7 insertions(+), 34 deletions(-)

--- linux-2.6.17.9.orig/kernel/timer.c
+++ linux-2.6.17.9/kernel/timer.c
@@ -975,46 +975,19 @@ asmlinkage long sys_getpid(void)
 }
 
 /*
- * Accessing ->group_leader->real_parent is not SMP-safe, it could
- * change from under us. However, rather than getting any lock
- * we can use an optimistic algorithm: get the parent
- * pid, and go back and check that the parent is still
- * the same. If it has changed (which is extremely unlikely
- * indeed), we just try again..
- *
- * NOTE! This depends on the fact that even if we _do_
- * get an old value of "parent", we can happily dereference
- * the pointer (it was and remains a dereferencable kernel pointer
- * no matter what): we just can't necessarily trust the result
- * until we know that the parent pointer is valid.
- *
- * NOTE2: ->group_leader never changes from under us.
+ * Accessing ->real_parent is not SMP-safe, it could
+ * change from under us. However, we can use a stale
+ * value of ->real_parent under rcu_read_lock(), see
+ * release_task()->call_rcu(delayed_put_task_struct).
  */
 asmlinkage long sys_getppid(void)
 {
 	int pid;
-	struct task_struct *me = current;
-	struct task_struct *parent;
 
-	parent = me->group_leader->real_parent;
-	for (;;) {
-		pid = parent->tgid;
-#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
-{
-		struct task_struct *old = parent;
+	rcu_read_lock();
+	pid = rcu_dereference(current->real_parent)->tgid;
+	rcu_read_unlock();
 
-		/*
-		 * Make sure we read the pid before re-reading the
-		 * parent pointer:
-		 */
-		smp_rmb();
-		parent = me->group_leader->real_parent;
-		if (old != parent)
-			continue;
-}
-#endif
-		break;
-	}
 	return pid;
 }
 

--

[patch 12/20] SERIAL: icom: select FW_LOADER

[Greg KH]

[-- Attachment #1: serial-icom-select-fw_loader.patch --]
[-- Type: text/plain, Size: 827 bytes --]

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

------------------
From: Olaf Hering <olaf@aepfle.de>

The icom driver uses request_firmware()
and thus needs to select FW_LOADER.

Signed-off-by: maximilian attems <maks@sternwelten.at>
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/serial/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.17.9.orig/drivers/serial/Kconfig
+++ linux-2.6.17.9/drivers/serial/Kconfig
@@ -803,6 +803,7 @@ config SERIAL_MPC52xx
 	tristate "Freescale MPC52xx family PSC serial support"
 	depends on PPC_MPC52xx
 	select SERIAL_CORE
+	select FW_LOADER
 	help
 	  This drivers support the MPC52xx PSC serial ports. If you would
 	  like to use them, you must answer Y or M to this option. Not that

--

[patch 13/20] PCI: fix ICH6 quirks

[Greg KH]

[-- Attachment #1: pci-fix-ich6-quirks.patch --]
[-- Type: text/plain, Size: 1720 bytes --]

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

------------------
From: Daniel Ritz <daniel.ritz-ml@swissonline.ch>

[PATCH] PCI: fix ICH6 quirks

- add the ICH6(R) LPC to the ICH6 ACPI quirks. currently only the ICH6-M is
  handled. [ PCI_DEVICE_ID_INTEL_ICH6_1 is the ICH6-M LPC, ICH6_0 is the ICH6(R) ]
- remove the wrong quirk calling asus_hides_smbus_lpc() for ICH6. the register
  modified in asus_hides_smbus_lpc() has a different meaning in ICH6.

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/pci/quirks.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.9.orig/drivers/pci/quirks.c
+++ linux-2.6.17.9/drivers/pci/quirks.c
@@ -427,6 +427,7 @@ static void __devinit quirk_ich6_lpc_acp
 	pci_read_config_dword(dev, 0x48, &region);
 	quirk_io_region(dev, region, 64, PCI_BRIDGE_RESOURCES+1, "ICH6 GPIO");
 }
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc_acpi );
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc_acpi );
 
 /*
@@ -1043,7 +1044,6 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801CA_12,	asus_hides_smbus_lpc );
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801DB_12,	asus_hides_smbus_lpc );
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801EB_0,	asus_hides_smbus_lpc );
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1,	asus_hides_smbus_lpc );
 
 static void __init asus_hides_smbus_lpc_ich6(struct pci_dev *dev)
 {

--

[patch 14/20] : ip_tables: fix table locking in ipt_do_table

[Greg KH]

[-- Attachment #1: ip_tables-fix-table-locking-in-ipt_do_table.patch --]
[-- Type: text/plain, Size: 1989 bytes --]

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

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

[NETFILTER]: ip_tables: fix table locking in ipt_do_table

table->private might change because of ruleset changes, don't use it without
holding the lock.

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

---
 net/ipv4/netfilter/arp_tables.c |    3 ++-
 net/ipv4/netfilter/ip_tables.c  |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

--- linux-2.6.17.9.orig/net/ipv4/netfilter/arp_tables.c
+++ linux-2.6.17.9/net/ipv4/netfilter/arp_tables.c
@@ -237,7 +237,7 @@ unsigned int arpt_do_table(struct sk_buf
 	struct arpt_entry *e, *back;
 	const char *indev, *outdev;
 	void *table_base;
-	struct xt_table_info *private = table->private;
+	struct xt_table_info *private;
 
 	/* ARP header, plus 2 device addresses, plus 2 IP addresses.  */
 	if (!pskb_may_pull((*pskb), (sizeof(struct arphdr) +
@@ -249,6 +249,7 @@ unsigned int arpt_do_table(struct sk_buf
 	outdev = out ? out->name : nulldevname;
 
 	read_lock_bh(&table->lock);
+	private = table->private;
 	table_base = (void *)private->entries[smp_processor_id()];
 	e = get_entry(table_base, private->hook_entry[hook]);
 	back = get_entry(table_base, private->underflow[hook]);
--- linux-2.6.17.9.orig/net/ipv4/netfilter/ip_tables.c
+++ linux-2.6.17.9/net/ipv4/netfilter/ip_tables.c
@@ -231,7 +231,7 @@ ipt_do_table(struct sk_buff **pskb,
 	const char *indev, *outdev;
 	void *table_base;
 	struct ipt_entry *e, *back;
-	struct xt_table_info *private = table->private;
+	struct xt_table_info *private;
 
 	/* Initialization */
 	ip = (*pskb)->nh.iph;
@@ -248,6 +248,7 @@ ipt_do_table(struct sk_buff **pskb,
 
 	read_lock_bh(&table->lock);
 	IP_NF_ASSERT(table->valid_hooks & (1 << hook));
+	private = table->private;
 	table_base = (void *)private->entries[smp_processor_id()];
 	e = get_entry(table_base, private->hook_entry[hook]);
 

--

[patch 15/20] IA64: local DoS with corrupted ELFs

[Greg KH]

[-- Attachment #1: ia64-local-dos-with-corrupted-elfs.patch --]
[-- Type: text/plain, Size: 7804 bytes --]

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

------------------
From: Kirill Korotaev <dev@sw.ru>

This patch prevents cross-region mappings
on IA64 and SPARC which could lead to system crash.

davem@ confirmed: "This looks fine to me." :)

Signed-Off-By: Pavel Emelianov <xemul@openvz.org>
Signed-Off-By: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 arch/ia64/kernel/sys_ia64.c     |   28 ++++++++++++++++------------
 arch/sparc/kernel/sys_sparc.c   |   27 +++++++++++++++------------
 arch/sparc64/kernel/sys_sparc.c |   36 ++++++++++++++++++++----------------
 include/asm-generic/mman.h      |    6 ++++++
 include/asm-ia64/mman.h         |    6 ++++++
 include/asm-sparc/mman.h        |    6 ++++++
 include/asm-sparc64/mman.h      |    6 ++++++
 mm/mmap.c                       |   13 +++++++++++--
 8 files changed, 86 insertions(+), 42 deletions(-)

--- linux-2.6.17.9.orig/arch/ia64/kernel/sys_ia64.c
+++ linux-2.6.17.9/arch/ia64/kernel/sys_ia64.c
@@ -164,10 +164,25 @@ sys_pipe (void)
 	return retval;
 }
 
+int ia64_map_check_rgn(unsigned long addr, unsigned long len,
+		unsigned long flags)
+{
+	unsigned long roff;
+
+	/*
+	 * Don't permit mappings into unmapped space, the virtual page table
+	 * of a region, or across a region boundary.  Note: RGN_MAP_LIMIT is
+	 * equal to 2^n-PAGE_SIZE (for some integer n <= 61) and len > 0.
+	 */
+	roff = REGION_OFFSET(addr);
+	if ((len > RGN_MAP_LIMIT) || (roff > (RGN_MAP_LIMIT - len)))
+		return -EINVAL;
+	return 0;
+}
+
 static inline unsigned long
 do_mmap2 (unsigned long addr, unsigned long len, int prot, int flags, int fd, unsigned long pgoff)
 {
-	unsigned long roff;
 	struct file *file = NULL;
 
 	flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
@@ -189,17 +204,6 @@ do_mmap2 (unsigned long addr, unsigned l
 		goto out;
 	}
 
-	/*
-	 * Don't permit mappings into unmapped space, the virtual page table of a region,
-	 * or across a region boundary.  Note: RGN_MAP_LIMIT is equal to 2^n-PAGE_SIZE
-	 * (for some integer n <= 61) and len > 0.
-	 */
-	roff = REGION_OFFSET(addr);
-	if ((len > RGN_MAP_LIMIT) || (roff > (RGN_MAP_LIMIT - len))) {
-		addr = -EINVAL;
-		goto out;
-	}
-
 	down_write(&current->mm->mmap_sem);
 	addr = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
 	up_write(&current->mm->mmap_sem);
--- linux-2.6.17.9.orig/arch/sparc/kernel/sys_sparc.c
+++ linux-2.6.17.9/arch/sparc/kernel/sys_sparc.c
@@ -219,6 +219,21 @@ out:
 	return err;
 }
 
+int sparc_mmap_check(unsigned long addr, unsigned long len, unsigned long flags)
+{
+	if (ARCH_SUN4C_SUN4 &&
+	    (len > 0x20000000 ||
+	     ((flags & MAP_FIXED) &&
+	      addr < 0xe0000000 && addr + len > 0x20000000)))
+		return -EINVAL;
+
+	/* See asm-sparc/uaccess.h */
+	if (len > TASK_SIZE - PAGE_SIZE || addr + len > TASK_SIZE - PAGE_SIZE)
+		return -EINVAL;
+
+	return 0;
+}
+
 /* Linux version of mmap */
 static unsigned long do_mmap2(unsigned long addr, unsigned long len,
 	unsigned long prot, unsigned long flags, unsigned long fd,
@@ -233,25 +248,13 @@ static unsigned long do_mmap2(unsigned l
 			goto out;
 	}
 
-	retval = -EINVAL;
 	len = PAGE_ALIGN(len);
-	if (ARCH_SUN4C_SUN4 &&
-	    (len > 0x20000000 ||
-	     ((flags & MAP_FIXED) &&
-	      addr < 0xe0000000 && addr + len > 0x20000000)))
-		goto out_putf;
-
-	/* See asm-sparc/uaccess.h */
-	if (len > TASK_SIZE - PAGE_SIZE || addr + len > TASK_SIZE - PAGE_SIZE)
-		goto out_putf;
-
 	flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
 
 	down_write(&current->mm->mmap_sem);
 	retval = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
 	up_write(&current->mm->mmap_sem);
 
-out_putf:
 	if (file)
 		fput(file);
 out:
--- linux-2.6.17.9.orig/arch/sparc64/kernel/sys_sparc.c
+++ linux-2.6.17.9/arch/sparc64/kernel/sys_sparc.c
@@ -549,6 +549,26 @@ asmlinkage long sparc64_personality(unsi
 	return ret;
 }
 
+int sparc64_mmap_check(unsigned long addr, unsigned long len,
+		unsigned long flags)
+{
+	if (test_thread_flag(TIF_32BIT)) {
+		if (len >= STACK_TOP32)
+			return -EINVAL;
+
+		if ((flags & MAP_FIXED) && addr > STACK_TOP32 - len)
+			return -EINVAL;
+	} else {
+		if (len >= VA_EXCLUDE_START)
+			return -EINVAL;
+
+		if ((flags & MAP_FIXED) && invalid_64bit_range(addr, len))
+			return -EINVAL;
+	}
+
+	return 0;
+}
+
 /* Linux version of mmap */
 asmlinkage unsigned long sys_mmap(unsigned long addr, unsigned long len,
 	unsigned long prot, unsigned long flags, unsigned long fd,
@@ -564,27 +584,11 @@ asmlinkage unsigned long sys_mmap(unsign
 	}
 	flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
 	len = PAGE_ALIGN(len);
-	retval = -EINVAL;
-
-	if (test_thread_flag(TIF_32BIT)) {
-		if (len >= STACK_TOP32)
-			goto out_putf;
-
-		if ((flags & MAP_FIXED) && addr > STACK_TOP32 - len)
-			goto out_putf;
-	} else {
-		if (len >= VA_EXCLUDE_START)
-			goto out_putf;
-
-		if ((flags & MAP_FIXED) && invalid_64bit_range(addr, len))
-			goto out_putf;
-	}
 
 	down_write(&current->mm->mmap_sem);
 	retval = do_mmap(file, addr, len, prot, flags, off);
 	up_write(&current->mm->mmap_sem);
 
-out_putf:
 	if (file)
 		fput(file);
 out:
--- linux-2.6.17.9.orig/include/asm-generic/mman.h
+++ linux-2.6.17.9/include/asm-generic/mman.h
@@ -39,4 +39,10 @@
 #define MAP_ANON	MAP_ANONYMOUS
 #define MAP_FILE	0
 
+#ifdef __KERNEL__
+#ifndef arch_mmap_check
+#define arch_mmap_check(addr, len, flags)	(0)
+#endif
+#endif
+
 #endif
--- linux-2.6.17.9.orig/include/asm-ia64/mman.h
+++ linux-2.6.17.9/include/asm-ia64/mman.h
@@ -8,6 +8,12 @@
  *	David Mosberger-Tang <davidm@hpl.hp.com>, Hewlett-Packard Co
  */
 
+#ifdef __KERNEL__
+#define arch_mmap_check	ia64_map_check_rgn
+int ia64_map_check_rgn(unsigned long addr, unsigned long len,
+		unsigned long flags);
+#endif
+
 #include <asm-generic/mman.h>
 
 #define MAP_GROWSDOWN	0x00100		/* stack-like segment */
--- linux-2.6.17.9.orig/include/asm-sparc/mman.h
+++ linux-2.6.17.9/include/asm-sparc/mman.h
@@ -2,6 +2,12 @@
 #ifndef __SPARC_MMAN_H__
 #define __SPARC_MMAN_H__
 
+#ifdef __KERNEL__
+#define arch_mmap_check	sparc_mmap_check
+int sparc_mmap_check(unsigned long addr, unsigned long len,
+		unsigned long flags);
+#endif
+
 #include <asm-generic/mman.h>
 
 /* SunOS'ified... */
--- linux-2.6.17.9.orig/include/asm-sparc64/mman.h
+++ linux-2.6.17.9/include/asm-sparc64/mman.h
@@ -2,6 +2,12 @@
 #ifndef __SPARC64_MMAN_H__
 #define __SPARC64_MMAN_H__
 
+#ifdef __KERNEL__
+#define arch_mmap_check	sparc64_mmap_check
+int sparc64_mmap_check(unsigned long addr, unsigned long len,
+		unsigned long flags);
+#endif
+
 #include <asm-generic/mman.h>
 
 /* SunOS'ified... */
--- linux-2.6.17.9.orig/mm/mmap.c
+++ linux-2.6.17.9/mm/mmap.c
@@ -913,6 +913,10 @@ unsigned long do_mmap_pgoff(struct file 
 	if (!len)
 		return -EINVAL;
 
+	error = arch_mmap_check(addr, len, flags);
+	if (error)
+		return error;
+
 	/* Careful about overflows.. */
 	len = PAGE_ALIGN(len);
 	if (!len || len > TASK_SIZE)
@@ -1852,6 +1856,7 @@ unsigned long do_brk(unsigned long addr,
 	unsigned long flags;
 	struct rb_node ** rb_link, * rb_parent;
 	pgoff_t pgoff = addr >> PAGE_SHIFT;
+	int error;
 
 	len = PAGE_ALIGN(len);
 	if (!len)
@@ -1860,6 +1865,12 @@ unsigned long do_brk(unsigned long addr,
 	if ((addr + len) > TASK_SIZE || (addr + len) < addr)
 		return -EINVAL;
 
+	flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
+
+	error = arch_mmap_check(addr, len, flags);
+	if (error)
+		return error;
+
 	/*
 	 * mlock MCL_FUTURE?
 	 */
@@ -1900,8 +1911,6 @@ unsigned long do_brk(unsigned long addr,
 	if (security_vm_enough_memory(len >> PAGE_SHIFT))
 		return -ENOMEM;
 
-	flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
-
 	/* Can we just expand an old private anonymous mapping? */
 	if (vma_merge(mm, prev, addr, addr + len, flags,
 					NULL, NULL, pgoff, NULL))

--

[patch 16/20] Fix ipv4 routing locking bug

[Greg KH]

[-- Attachment #1: fix-ipv4-routing-locking-bug.patch --]
[-- Type: text/plain, Size: 2499 bytes --]

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

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

From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>

[IPV4]: severe locking bug in fib_semantics.c

Found in 2.4 by Yixin Pan <yxpan@hotmail.com>.

> When I read fib_semantics.c of Linux-2.4.32, write_lock(&fib_info_lock) =
> is used in fib_release_info() instead of write_lock_bh(&fib_info_lock).  =
> Is the following case possible: a BH interrupts fib_release_info() while =
> holding the write lock, and calls ip_check_fib_default() which calls =
> read_lock(&fib_info_lock), and spin forever.

Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ipv4/fib_semantics.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.17.9.orig/net/ipv4/fib_semantics.c
+++ linux-2.6.17.9/net/ipv4/fib_semantics.c
@@ -160,7 +160,7 @@ void free_fib_info(struct fib_info *fi)
 
 void fib_release_info(struct fib_info *fi)
 {
-	write_lock(&fib_info_lock);
+	write_lock_bh(&fib_info_lock);
 	if (fi && --fi->fib_treeref == 0) {
 		hlist_del(&fi->fib_hash);
 		if (fi->fib_prefsrc)
@@ -173,7 +173,7 @@ void fib_release_info(struct fib_info *f
 		fi->fib_dead = 1;
 		fib_info_put(fi);
 	}
-	write_unlock(&fib_info_lock);
+	write_unlock_bh(&fib_info_lock);
 }
 
 static __inline__ int nh_comp(const struct fib_info *fi, const struct fib_info *ofi)
@@ -599,7 +599,7 @@ static void fib_hash_move(struct hlist_h
 	unsigned int old_size = fib_hash_size;
 	unsigned int i, bytes;
 
-	write_lock(&fib_info_lock);
+	write_lock_bh(&fib_info_lock);
 	old_info_hash = fib_info_hash;
 	old_laddrhash = fib_info_laddrhash;
 	fib_hash_size = new_size;
@@ -640,7 +640,7 @@ static void fib_hash_move(struct hlist_h
 	}
 	fib_info_laddrhash = new_laddrhash;
 
-	write_unlock(&fib_info_lock);
+	write_unlock_bh(&fib_info_lock);
 
 	bytes = old_size * sizeof(struct hlist_head *);
 	fib_hash_free(old_info_hash, bytes);
@@ -822,7 +822,7 @@ link_it:
 
 	fi->fib_treeref++;
 	atomic_inc(&fi->fib_clntref);
-	write_lock(&fib_info_lock);
+	write_lock_bh(&fib_info_lock);
 	hlist_add_head(&fi->fib_hash,
 		       &fib_info_hash[fib_info_hashfn(fi)]);
 	if (fi->fib_prefsrc) {
@@ -841,7 +841,7 @@ link_it:
 		head = &fib_info_devhash[hash];
 		hlist_add_head(&nh->nh_hash, head);
 	} endfor_nexthops(fi)
-	write_unlock(&fib_info_lock);
+	write_unlock_bh(&fib_info_lock);
 	return fi;
 
 err_inval:

--

[patch 16/20] Fix ipv4 routing locking bug

[Greg KH]

[-- Attachment #1: fix-ipv4-routing-locking-bug.patch --]
[-- Type: text/plain, Size: 2499 bytes --]

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

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

From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>

[IPV4]: severe locking bug in fib_semantics.c

Found in 2.4 by Yixin Pan <yxpan@hotmail.com>.

> When I read fib_semantics.c of Linux-2.4.32, write_lock(&fib_info_lock) =
> is used in fib_release_info() instead of write_lock_bh(&fib_info_lock).  =
> Is the following case possible: a BH interrupts fib_release_info() while =
> holding the write lock, and calls ip_check_fib_default() which calls =
> read_lock(&fib_info_lock), and spin forever.

Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ipv4/fib_semantics.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.17.9.orig/net/ipv4/fib_semantics.c
+++ linux-2.6.17.9/net/ipv4/fib_semantics.c
@@ -160,7 +160,7 @@ void free_fib_info(struct fib_info *fi)
 
 void fib_release_info(struct fib_info *fi)
 {
-	write_lock(&fib_info_lock);
+	write_lock_bh(&fib_info_lock);
 	if (fi && --fi->fib_treeref == 0) {
 		hlist_del(&fi->fib_hash);
 		if (fi->fib_prefsrc)
@@ -173,7 +173,7 @@ void fib_release_info(struct fib_info *f
 		fi->fib_dead = 1;
 		fib_info_put(fi);
 	}
-	write_unlock(&fib_info_lock);
+	write_unlock_bh(&fib_info_lock);
 }
 
 static __inline__ int nh_comp(const struct fib_info *fi, const struct fib_info *ofi)
@@ -599,7 +599,7 @@ static void fib_hash_move(struct hlist_h
 	unsigned int old_size = fib_hash_size;
 	unsigned int i, bytes;
 
-	write_lock(&fib_info_lock);
+	write_lock_bh(&fib_info_lock);
 	old_info_hash = fib_info_hash;
 	old_laddrhash = fib_info_laddrhash;
 	fib_hash_size = new_size;
@@ -640,7 +640,7 @@ static void fib_hash_move(struct hlist_h
 	}
 	fib_info_laddrhash = new_laddrhash;
 
-	write_unlock(&fib_info_lock);
+	write_unlock_bh(&fib_info_lock);
 
 	bytes = old_size * sizeof(struct hlist_head *);
 	fib_hash_free(old_info_hash, bytes);
@@ -822,7 +822,7 @@ link_it:
 
 	fi->fib_treeref++;
 	atomic_inc(&fi->fib_clntref);
-	write_lock(&fib_info_lock);
+	write_lock_bh(&fib_info_lock);
 	hlist_add_head(&fi->fib_hash,
 		       &fib_info_hash[fib_info_hashfn(fi)]);
 	if (fi->fib_prefsrc) {
@@ -841,7 +841,7 @@ link_it:
 		head = &fib_info_devhash[hash];
 		hlist_add_head(&nh->nh_hash, head);
 	} endfor_nexthops(fi)
-	write_unlock(&fib_info_lock);
+	write_unlock_bh(&fib_info_lock);
 	return fi;
 
 err_inval:

--

[patch 17/20] dm: BUG/OOPS fix

[Greg KH]

[-- Attachment #1: dm-bug-oops-fix.patch --]
[-- Type: text/plain, Size: 2568 bytes --]

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

------------------
From: Michal Miroslaw <mirq-linux@rere.qmqm.pl>

Fix BUG I tripped on while testing failover and multipathing.

BUG shows up on error path in multipath_ctr() when parse_priority_group()
fails after returning at least once without error.  The fix is to
initialize m->ti early - just after alloc()ing it.

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c027c3d2
*pde = 00000000
Oops: 0000 [#3]
Modules linked in: qla2xxx ext3 jbd mbcache sg ide_cd cdrom floppy
CPU:    0
EIP:    0060:[<c027c3d2>]    Not tainted VLI
EFLAGS: 00010202   (2.6.17.3 #1)
EIP is at dm_put_device+0xf/0x3b
eax: 00000001   ebx: ee4fcac0   ecx: 00000000   edx: ee4fcac0
esi: ee4fc4e0   edi: ee4fc4e0   ebp: 00000000   esp: c5db3e78
ds: 007b   es: 007b   ss: 0068
Process multipathd (pid: 15912, threadinfo=c5db2000 task=ef485a90)
Stack: ec4eda40 c02816bd ee4fc4c0 00000000 f7e89498 f883e0bc c02816f6 f7e89480
       f7e8948c c0281801 ffffffea f7e89480 f883e080 c0281ffe 00000001 00000000
       00000004 dfe9cab8 f7a693c0 f883e080 f883e0c0 ca4b99c0 c027c6ee 01400000
Call Trace:
 <c02816bd> free_pgpaths+0x31/0x45  <c02816f6> free_priority_group+0x25/0x2e
 <c0281801> free_multipath+0x35/0x67  <c0281ffe> multipath_ctr+0x123/0x12d
 <c027c6ee> dm_table_add_target+0x11e/0x18b  <c027e5b4> populate_table+0x8a/0xaf
 <c027e62b> table_load+0x52/0xf9  <c027ec23> ctl_ioctl+0xca/0xfc
 <c027e5d9> table_load+0x0/0xf9  <c0152146> do_ioctl+0x3e/0x43
 <c0152360> vfs_ioctl+0x16c/0x178  <c01523b4> sys_ioctl+0x48/0x60
 <c01029b3> syscall_call+0x7/0xb
Code: 97 f0 00 00 00 89 c1 83 c9 01 80 e2 01 0f 44 c1 88 43 14 8b 04 24 59 5b 5e 5f 5d c3 53 89 c1 89 d3 ff 4a 08 0f 94 c0 84 c0 74 2a <8b> 01 8b 10 89 d8 e8 f6 fb ff ff 8b 03 8b 53 04 89 50 04 89 02
EIP: [<c027c3d2>] dm_put_device+0xf/0x3b SS:ESP 0068:c5db3e78

Signed-off-by: Michal Miroslaw <mirq-linux@rere.qmqm.pl>
Acked-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/dm-mpath.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.17.9.orig/drivers/md/dm-mpath.c
+++ linux-2.6.17.9/drivers/md/dm-mpath.c
@@ -711,6 +711,8 @@ static int multipath_ctr(struct dm_targe
 		return -EINVAL;
 	}
 
+	m->ti = ti;
+
 	r = parse_features(&as, m, ti);
 	if (r)
 		goto bad;
@@ -752,7 +754,6 @@ static int multipath_ctr(struct dm_targe
 	}
 
 	ti->private = m;
-	m->ti = ti;
 
 	return 0;
 

--

[patch 18/20] swsusp: Fix swap_type_of

[Greg KH]

[-- Attachment #1: swsusp-fix-swap_type_of.patch --]
[-- Type: text/plain, Size: 1061 bytes --]

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

------------------
From: "Rafael J. Wysocki" <rjw@sisk.pl>

There is a bug in mm/swapfile.c#swap_type_of() that makes swsusp only be
able to use the first active swap partition as the resume device.  Fix it.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Hugh Dickins <hugh@veritas.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/swapfile.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.17.9.orig/mm/swapfile.c
+++ linux-2.6.17.9/mm/swapfile.c
@@ -440,11 +440,12 @@ int swap_type_of(dev_t device)
 
 		if (!(swap_info[i].flags & SWP_WRITEOK))
 			continue;
+
 		if (!device) {
 			spin_unlock(&swap_lock);
 			return i;
 		}
-		inode = swap_info->swap_file->f_dentry->d_inode;
+		inode = swap_info[i].swap_file->f_dentry->d_inode;
 		if (S_ISBLK(inode->i_mode) &&
 		    device == MKDEV(imajor(inode), iminor(inode))) {
 			spin_unlock(&swap_lock);

--

[patch 19/20] MD: Fix a potential NULL dereference in md/raid1

[Greg KH]

[-- Attachment #1: md-fix-a-potential-null-dereference-in-md-raid1.patch --]
[-- Type: text/plain, Size: 1297 bytes --]

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

------------------
From: NeilBrown <neilb@suse.de>

At the point where this 'atomic_add' is, rdev could be NULL, as seen by
the fact that we test for this in the very next statement.

Further is it is really the wrong place of the add.  We could add to the
count of corrected errors once the are sure it was corrected, not before
trying to correct it.

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


diff .prev/drivers/md/raid1.c ./drivers/md/raid1.c
---
 drivers/md/raid1.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.17.9.orig/drivers/md/raid1.c
+++ linux-2.6.17.9/drivers/md/raid1.c
@@ -1486,7 +1486,6 @@ static void raid1d(mddev_t *mddev)
 							d = conf->raid_disks;
 						d--;
 						rdev = conf->mirrors[d].rdev;
-						atomic_add(s, &rdev->corrected_errors);
 						if (rdev &&
 						    test_bit(In_sync, &rdev->flags)) {
 							if (sync_page_io(rdev->bdev,
@@ -1509,6 +1508,9 @@ static void raid1d(mddev_t *mddev)
 									 s<<9, conf->tmppage, READ) == 0)
 								/* Well, this device is dead */
 								md_error(mddev, rdev);
+							else
+								atomic_add(s, &rdev->corrected_errors);
+
 						}
 					}
 				} else {

--

[patch 20/20] 1394: fix for recently added firewire patch that breaks things on ppc

[Greg KH]

[-- Attachment #1: 1394-fix-for-recently-added-firewire-patch-that-breaks-things-on-ppc.patch --]
[-- Type: text/plain, Size: 1371 bytes --]

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

------------------
From: Danny Tholen <obiwan@mailmij.org>

Recently a patch was added for preliminary suspend/resume handling on
!PPC_PMAC.  However, this broke both suspend and firewire on powerpc
because it saves the pci state after the device has already been disabled.

This moves the save state to before the pmac specific code.

Signed-off-by: Danny Tholen <obiwan@mailmij.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ben Collins <bcollins@ubuntu.com>
Cc: Jody McIntyre <scjody@modernduck.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- linux-2.6.17.9.orig/drivers/ieee1394/ohci1394.c
+++ linux-2.6.17.9/drivers/ieee1394/ohci1394.c
@@ -3548,6 +3548,8 @@ static int ohci1394_pci_resume (struct p
 
 static int ohci1394_pci_suspend (struct pci_dev *pdev, pm_message_t state)
 {
+	pci_save_state(pdev);
+
 #ifdef CONFIG_PPC_PMAC
 	if (machine_is(powermac)) {
 		struct device_node *of_node;
@@ -3559,8 +3561,6 @@ static int ohci1394_pci_suspend (struct 
 	}
 #endif
 
-	pci_save_state(pdev);
-
 	return 0;
 }
 

--

Re: [patch 20/20] 1394: fix for recently added firewire patch that breaks things on ppc

[Stefan Richter]

Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Danny Tholen <obiwan@mailmij.org>
> 
> Recently a patch was added for preliminary suspend/resume handling on
> !PPC_PMAC.  However, this broke both suspend and firewire on powerpc
> because it saves the pci state after the device has already been disabled.
> 
> This moves the save state to before the pmac specific code.
> 
> Signed-off-by: Danny Tholen <obiwan@mailmij.org>
> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>

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

> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Ben Collins <bcollins@ubuntu.com>
> Cc: Jody McIntyre <scjody@modernduck.com>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  drivers/ieee1394/ohci1394.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- linux-2.6.17.9.orig/drivers/ieee1394/ohci1394.c
> +++ linux-2.6.17.9/drivers/ieee1394/ohci1394.c
> @@ -3548,6 +3548,8 @@ static int ohci1394_pci_resume (struct p
>  
>  static int ohci1394_pci_suspend (struct pci_dev *pdev, pm_message_t state)
>  {
> +	pci_save_state(pdev);
> +
>  #ifdef CONFIG_PPC_PMAC
>  	if (machine_is(powermac)) {
>  		struct device_node *of_node;
> @@ -3559,8 +3561,6 @@ static int ohci1394_pci_suspend (struct 
>  	}
>  #endif
>  
> -	pci_save_state(pdev);
> -
>  	return 0;
>  }
>  
> 
> --


-- 
Stefan Richter
-=====-=-==- =--- =-==-
http://arcgraph.de/sr/

Re: [patch 00/20] 2.6.17-stable review

[Dave Jones]

On Mon, Aug 21, 2006 at 11:45:27AM -0700, Greg KH wrote:
 > This is the start of the stable review cycle for the next 2.6.17.y
 > release.  There are 20 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.

Any chance of a 2.6.17.10-rc1 rollup patch again, like you did for .8?

		Dave

-- 
http://www.codemonkey.org.uk

Re: [patch 00/20] 2.6.17-stable review

[Greg KH]

On Mon, Aug 21, 2006 at 03:46:16PM -0400, Dave Jones wrote:
> On Mon, Aug 21, 2006 at 11:45:27AM -0700, Greg KH wrote:
>  > This is the start of the stable review cycle for the next 2.6.17.y
>  > release.  There are 20 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.
> 
> Any chance of a 2.6.17.10-rc1 rollup patch again, like you did for .8?

Oops, forgot to do that, thanks for reminding me.  It can be found at:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/stable/patch-2.6.17.10-rc1.gz

And yes, it's not in the "main" v2.6 subdirectories, I'm not going to
put it there anymore as it confuses too many scripts/people.

thanks,

greg k-h

Re: [patch 00/20] 2.6.17-stable review

[John Stoffel]

>>>>> "Greg" == Greg KH <gregkh@suse.de> writes:

Greg> On Mon, Aug 21, 2006 at 03:46:16PM -0400, Dave Jones wrote:
>> On Mon, Aug 21, 2006 at 11:45:27AM -0700, Greg KH wrote:
>> > This is the start of the stable review cycle for the next 2.6.17.y
>> > release.  There are 20 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.
>> 
>> Any chance of a 2.6.17.10-rc1 rollup patch again, like you did for .8?

Greg> Oops, forgot to do that, thanks for reminding me.  It can be
Greg> found at:
Greg> http://www.kernel.org/pub/linux/kernel/people/gregkh/stable/patch-2.6.17.10-rc1.gz

Greg> And yes, it's not in the "main" v2.6 subdirectories, I'm not going to
Greg> put it there anymore as it confuses too many scripts/people.

So what if they're confused?  If they're official releases, blessed
with holy penguin pee, then shouldn't they be in the standard release
area?  

	http://www.kernel.org/pub/linux/kernel/v2.6/

could just be extended down with a directory for each version
released, and the directory holds the ChangeLog, linux-... and
patch-... files.  

Thanks for doing the stable branch in any case!

John

Re: [patch 00/20] 2.6.17-stable review

[Kyle Moffett]

On Aug 22, 2006, at 09:49:29, John Stoffel wrote:
> "Greg" == Greg KH <gregkh@suse.de> writes:
>> On Mon, Aug 21, 2006 at 03:46:16PM -0400, Dave Jones wrote:
>>> Any chance of a 2.6.17.10-rc1 rollup patch again, like you did  
>>> for .8?
>
>> Oops, forgot to do that, thanks for reminding me.  It can be found  
>> at:
>> http://www.kernel.org/pub/linux/kernel/people/gregkh/stable/ 
>> patch-2.6.17.10-rc1.gz
>
>> And yes, it's not in the "main" v2.6 subdirectories, I'm not going  
>> to put it there anymore as it confuses too many scripts/people.
>
> So what if they're confused?  If they're official releases, blessed  
> with holy penguin pee, then shouldn't they be in the standard  
> release area?

Well, except for the fact that the pre-stable RC patches are neither  
"official" nor "releases".  They're just a combo rollup patch of all  
of the proposed stable patches before they've been batch reviewed on  
the LKML. (IOW: just for ease of testing)

Cheers,
Kyle Moffett

Re: [patch 00/20] 2.6.17-stable review

[John Stoffel]

>>>>> "Kyle" == Kyle Moffett <mrmacman_g4@mac.com> writes:

Kyle> On Aug 22, 2006, at 09:49:29, John Stoffel wrote:
>> "Greg" == Greg KH <gregkh@suse.de> writes:
>>> On Mon, Aug 21, 2006 at 03:46:16PM -0400, Dave Jones wrote:
>>>> Any chance of a 2.6.17.10-rc1 rollup patch again, like you did  
>>>> for .8?
>> 
>>> Oops, forgot to do that, thanks for reminding me.  It can be found  
>>> at:
>>> http://www.kernel.org/pub/linux/kernel/people/gregkh/stable/ 
>>> patch-2.6.17.10-rc1.gz
>> 
>>> And yes, it's not in the "main" v2.6 subdirectories, I'm not going  
>>> to put it there anymore as it confuses too many scripts/people.
>> 
>> So what if they're confused?  If they're official releases, blessed  
>> with holy penguin pee, then shouldn't they be in the standard  
>> release area?

Kyle> Well, except for the fact that the pre-stable RC patches are
Kyle> neither "official" nor "releases".  They're just a combo rollup
Kyle> patch of all of the proposed stable patches before they've been
Kyle> batch reviewed on the LKML. (IOW: just for ease of testing)

Doh.  Never mind, excuse the egg on my face please...

John

Herbert Xu's paged unique skb trimming patch?

[Nix]

On 21 Aug 2006, Greg KH stipulated:
> Responses should be made by Wed, Auguest 23, 18:00:00 UTC.  Anything
> received after that time might be too late.

Dave Miller suggested that Herbert Xu's pskb trimming patch (commit
e9fa4f7bd291c29a785666e2fa5a9cf3241ee6c3) should go into -stable: did it
get lost? Without it, network stalls (at least) are quite possible.

-- 
scsi/atp870u.c: panic("Foooooooood fight!");
  --- linux-2.6.17/drivers/scsi/atp870u.c

Re: Herbert Xu's paged unique skb trimming patch?

[Greg KH]

On Tue, Aug 22, 2006 at 08:13:23PM +0100, Nix wrote:
> On 21 Aug 2006, Greg KH stipulated:
> > Responses should be made by Wed, Auguest 23, 18:00:00 UTC.  Anything
> > received after that time might be too late.
> 
> Dave Miller suggested that Herbert Xu's pskb trimming patch (commit
> e9fa4f7bd291c29a785666e2fa5a9cf3241ee6c3) should go into -stable: did it
> get lost? Without it, network stalls (at least) are quite possible.

It must have gotten lost, I don't see it in our queue, nor in the few
patches I have recevied yesterday.  Care to bounce it to
stable@kernel.org and we can add it to the next release?

thanks,

greg k-h

Re: Herbert Xu's paged unique skb trimming patch?

[David Miller]

From: Greg KH <gregkh@suse.de>
Date: Tue, 22 Aug 2006 12:17:23 -0700

> On Tue, Aug 22, 2006 at 08:13:23PM +0100, Nix wrote:
> > On 21 Aug 2006, Greg KH stipulated:
> > > Responses should be made by Wed, Auguest 23, 18:00:00 UTC.  Anything
> > > received after that time might be too late.
> > 
> > Dave Miller suggested that Herbert Xu's pskb trimming patch (commit
> > e9fa4f7bd291c29a785666e2fa5a9cf3241ee6c3) should go into -stable: did it
> > get lost? Without it, network stalls (at least) are quite possible.
> 
> It must have gotten lost, I don't see it in our queue, nor in the few
> patches I have recevied yesterday.  Care to bounce it to
> stable@kernel.org and we can add it to the next release?

I've done this, thanks for catching it.