Skip to contentSkip to conversation

2.6.24-stable review

PATCH In review Chris Wright 14 participants 86 messages Apr 17, 2008 – Apr 23, 2008

Subsystems (42)
lore
Share & tools
lore
#0 lore raw

cover 2.6.24-stable review

This is the start of the stable review cycle for the 2.6.24.5 release. There are 66 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 Sat April 19 01:00 UTC Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.24.5-rc1.gz

and the diffstat can be found below.

thanks,

the -stable release team

Signature · 85 lines
 Makefile                                  |    4 -
 arch/parisc/kernel/firmware.c             |   27 +++++++----
 arch/parisc/kernel/pdc_cons.c             |   19 +++++++-
 arch/parisc/kernel/signal.c               |    3 -
 arch/sparc64/kernel/ptrace.c              |    4 +
 arch/sparc64/kernel/signal.c              |    2 
 arch/sparc64/mm/tlb.c                     |    3 -
 arch/x86/kernel/machine_kexec_64.c        |    1 
 arch/x86/xen/enlighten.c                  |   42 ++++++++++--------
 arch/x86/xen/xen-asm.S                    |    9 +++
 crypto/xcbc.c                             |   17 +++----
 drivers/acpi/bus.c                        |    7 +--
 drivers/acpi/processor_core.c             |    2 
 drivers/ata/libata-core.c                 |   38 ++++++++++------
 drivers/firmware/dmi_scan.c               |    2 
 drivers/hwmon/w83781d.c                   |   21 ++++++---
 drivers/macintosh/via-pmu.c               |    2 
 drivers/md/md.c                           |   12 -----
 drivers/md/raid5.c                        |   51 ++++++++++++----------
 drivers/media/dvb/dvb-usb/ttusb2.c        |    1 
 drivers/media/dvb/frontends/tda10086.c    |   28 +++++++++---
 drivers/media/dvb/frontends/tda10086.h    |    3 +
 drivers/media/dvb/ttpci/budget.c          |    1 
 drivers/media/video/ivtv/ivtv-driver.c    |    3 +
 drivers/media/video/saa7134/saa7134-dvb.c |    1 
 drivers/mtd/chips/cfi_cmdset_0001.c       |   10 ++--
 drivers/mtd/devices/block2mtd.c           |    1 
 drivers/net/macb.c                        |    2 
 drivers/net/plip.c                        |    7 +--
 drivers/net/pppol2tp.c                    |   69 ++++++++++++++++--------------
 drivers/net/sis190.c                      |   15 ++++--
 drivers/net/sungem.c                      |    2 
 drivers/pci/quirks.c                      |   11 ++--
 drivers/pnp/pnpacpi/rsparser.c            |    8 +--
 drivers/uio/uio.c                         |    2 
 drivers/usb/core/message.c                |    5 +-
 drivers/usb/core/quirks.c                 |    3 +
 drivers/usb/serial/keyspan.h              |    4 +
 drivers/usb/serial/ti_usb_3410_5052.c     |    4 -
 drivers/usb/serial/visor.c                |    2 
 drivers/usb/storage/transport.c           |    3 -
 drivers/usb/storage/unusual_devs.h        |   11 ++++
 drivers/video/fbmem.c                     |    1 
 fs/buffer.c                               |   13 ++---
 fs/dcache.c                               |    3 -
 fs/hfsplus/dir.c                          |   23 ++++++----
 fs/inotify.c                              |   30 ++++++-------
 fs/locks.c                                |   48 ++++++++++++--------
 fs/signalfd.c                             |    7 ++-
 include/asm-parisc/futex.h                |   10 +++-
 include/asm-parisc/pdc.h                  |    3 -
 include/asm-sparc64/backoff.h             |    3 -
 include/linux/ethtool.h                   |    1 
 include/linux/percpu.h                    |    2 
 include/linux/sched.h                     |    6 ++
 include/linux/security.h                  |    3 -
 include/linux/time.h                      |    4 +
 include/linux/usb/quirks.h                |    3 +
 include/linux/usb_usual.h                 |    4 +
 kernel/sched.c                            |   43 ++++++++++++++++++
 kernel/timer.c                            |   10 +++-
 mm/allocpercpu.c                          |   15 ++++++
 mm/slab.c                                 |    4 -
 net/8021q/vlan.c                          |    2 
 net/ax25/ax25_out.c                       |   13 ++++-
 net/bluetooth/hci_core.c                  |    4 -
 net/core/dev.c                            |    4 -
 net/core/netpoll.c                        |    6 +-
 net/ipv4/tcp.c                            |    4 -
 net/ipv4/tcp_output.c                     |    2 
 net/ipv6/netfilter/nf_conntrack_reasm.c   |    2 
 net/llc/af_llc.c                          |    3 +
 net/sched/sch_generic.c                   |   18 ++++++-
 net/sched/sch_htb.c                       |   13 +++--
 net/sctp/bind_addr.c                      |    4 +
 net/sctp/ipv6.c                           |    4 +
 net/sctp/protocol.c                       |    4 +
 net/sunrpc/clnt.c                         |    4 -
 scripts/Makefile.modpost                  |    6 ++
 scripts/mod/file2alias.c                  |    4 +
 scripts/mod/modpost.c                     |    5 +-
 scripts/mod/modpost.h                     |    1 
 security/capability.c                     |    1 
 security/commoncap.c                      |   39 ----------------
 84 files changed, 533 insertions(+), 308 deletions(-)
#1 lore raw

PARISC futex: special case cmpxchg NULL in kernel space

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

From: Kyle McMartin <[email protected]>

upstream commit: c20a84c91048c76c1379011c96b1a5cee5c7d9a0

commit f9e77acd4060fefbb60a351cdb8d30fca27fe194

Author: Thomas Gleixner <[email protected]>
Date:   Sun Feb 24 02:10:05 2008 +0000

futex: runtime enable pi and robust functionality

which was backported to stable based on mainline Commit a0c1e9073ef7428a14309cba010633a6cd6719ea added code to futex.c to detect whether futex_atomic_cmpxchg_inatomic was implemented at run time:

+ curval = cmpxchg_futex_value_locked(NULL, 0, 0);
+ if (curval == -EFAULT)
+ futex_cmpxchg_enabled = 1;

This is bogus on parisc, since page zero in kernel virtual space is the gateway page for syscall entry, and should not be read from the kernel. (That, and we really don't like the kernel faulting on its own address
space...)

---
 include/asm-parisc/futex.h |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
include/asm-parisc/futex.h +8 -2
@@ -56,6 +56,12 @@ futex_atomic_cmpxchg_inatomic(int __user
 	int err = 0;
 	int uval;
 
+	/* futex.c wants to do a cmpxchg_inatomic on kernel NULL, which is
+	 * our gateway page, and causes no end of trouble...
+	 */
+	if (segment_eq(KERNEL_DS, get_fs()) && !uaddr)
+		return -EFAULT;
+
 	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
 		return -EFAULT;
 
@@ -67,5 +73,5 @@ futex_atomic_cmpxchg_inatomic(int __user
 	return uval;
 }
 
-#endif
-#endif
+#endif /*__KERNEL__*/
+#endif /*_ASM_PARISC_FUTEX_H*/
#2 lore raw

PARISC pdc_console: fix bizarre panic on boot

In reply to Chris Wright

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

From: Kyle McMartin <[email protected]>

upstream commit ef1afd4d79f0479960ff36bb5fe6ec6eba1ebff2

commit 721fdf34167580ff98263c74cead8871d76936e6

Author: Kyle McMartin <[email protected]>
Date:   Thu Dec 6 09:32:15 2007 -0800

[PARISC] print more than one character at a time for pdc console

introduced a subtle bug by accidentally removing the "static" from iodc_dbuf. This resulted in, what appeared to be, a trap without *current set to a task. Probably the result of a trap in real mode while calling firmware.

Also do other misc clean ups. Since the only input from firmware is non blocking, share iodc_dbuf between input and output, and spinlock the only callers.

[jejb: fixed up rejections against the stable tree]

---
 arch/parisc/kernel/firmware.c |   27 +++++++++++++++++----------
 arch/parisc/kernel/pdc_cons.c |   19 +++++++++++++++++--
 include/asm-parisc/pdc.h      |    3 +--
 3 files changed, 35 insertions(+), 14 deletions(-)
arch/parisc/kernel/firmware.c +17 -10
@@ -1080,6 +1080,9 @@ void pdc_io_reset_devices(void)
 	spin_unlock_irqrestore(&pdc_lock, flags);
 }
 
+/* locked by pdc_console_lock */
+static int __attribute__((aligned(8)))   iodc_retbuf[32];
+static char __attribute__((aligned(64))) iodc_dbuf[4096];
 
 /**
  * pdc_iodc_print - Console print using IODC.
@@ -1091,24 +1094,20 @@ void pdc_io_reset_devices(void)
  * Since the HP console requires CR+LF to perform a 'newline', we translate
  * "\n" to "\r\n".
  */
-int pdc_iodc_print(unsigned char *str, unsigned count)
+int pdc_iodc_print(const unsigned char *str, unsigned count)
 {
-	/* XXX Should we spinlock posx usage */
 	static int posx;        /* for simple TAB-Simulation... */
-	int __attribute__((aligned(8)))   iodc_retbuf[32];
-	char __attribute__((aligned(64))) iodc_dbuf[4096];
 	unsigned int i;
 	unsigned long flags;
 
-	memset(iodc_dbuf, 0, 4096);
-	for (i = 0; i < count && i < 2048;) {
+	for (i = 0; i < count && i < 79;) {
 		switch(str[i]) {
 		case '\n':
 			iodc_dbuf[i+0] = '\r';
 			iodc_dbuf[i+1] = '\n';
 			i += 2;
 			posx = 0;
-			break;
+			goto print;
 		case '\t':
 			while (posx & 7) {
 				iodc_dbuf[i] = ' ';
@@ -1124,6 +1123,16 @@ int pdc_iodc_print(unsigned char *str, u
 		}
 	}
 
+	/* if we're at the end of line, and not already inserting a newline,
+	 * insert one anyway. iodc console doesn't claim to support >79 char
+	 * lines. don't account for this in the return value.
+	 */
+	if (i == 79 && iodc_dbuf[i-1] != '\n') {
+		iodc_dbuf[i+0] = '\r';
+		iodc_dbuf[i+1] = '\n';
+	}
+
+print:
         spin_lock_irqsave(&pdc_lock, flags);
         real32_call(PAGE0->mem_cons.iodc_io,
                     (unsigned long)PAGE0->mem_cons.hpa, ENTRY_IO_COUT,
@@ -1142,11 +1151,9 @@ int pdc_iodc_print(unsigned char *str, u
  */
 int pdc_iodc_getc(void)
 {
-	unsigned long flags;
-        static int __attribute__((aligned(8)))   iodc_retbuf[32];
-        static char __attribute__((aligned(64))) iodc_dbuf[4096];
 	int ch;
 	int status;
+	unsigned long flags;
 
 	/* Bail if no console input device. */
 	if (!PAGE0->mem_kbd.iodc_io)
arch/parisc/kernel/pdc_cons.c +17 -2
@@ -52,10 +52,18 @@
 #include <linux/tty.h>
 #include <asm/pdc.h>		/* for iodc_call() proto and friends */
 
+static spinlock_t pdc_console_lock = SPIN_LOCK_UNLOCKED;
 
 static void pdc_console_write(struct console *co, const char *s, unsigned count)
 {
-	pdc_iodc_print(s, count);
+	int i = 0;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pdc_console_lock, flags);
+	do {
+		i += pdc_iodc_print(s + i, count - i);
+	} while (i < count);
+	spin_unlock_irqrestore(&pdc_console_lock, flags);
 }
 
 void pdc_printf(const char *fmt, ...)
@@ -73,7 +81,14 @@ void pdc_printf(const char *fmt, ...)
 
 int pdc_console_poll_key(struct console *co)
 {
-	return pdc_iodc_getc();
+	int c;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pdc_console_lock, flags);
+	c = pdc_iodc_getc();
+	spin_unlock_irqrestore(&pdc_console_lock, flags);
+
+	return c;
 }
 
 static int pdc_console_setup(struct console *co, char *options)
include/asm-parisc/pdc.h +1 -2
@@ -645,8 +645,7 @@ int pdc_soft_power_button(int sw_control
 void pdc_io_reset(void);
 void pdc_io_reset_devices(void);
 int pdc_iodc_getc(void);
-int pdc_iodc_print(unsigned char *str, unsigned count);
-void pdc_printf(const char *fmt, ...);
+int pdc_iodc_print(const unsigned char *str, unsigned count);
 
 void pdc_emergency_unlock(void);
 int pdc_sti_call(unsigned long func, unsigned long flags,
#3 lore raw

pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."

In reply to Chris Wright

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

From: Len Brown <[email protected]>

upstream commit 33fd7afd66ffdc6addf1b085fe6403b6af532f8e

We have been printing these messages at KERN_ERR since 2.6.24, per http://bugzilla.kernel.org/show_bug.cgi?id=9535

But KERN_ERR pops up on a console booted with "quiet" and causes users to get alarmed and file bugs about the message itself:
https://bugzilla.redhat.com/show_bug.cgi?id=436589

So reduce the severity of these messages to KERN_WARNING, which is not printed by "quiet".

This message will still be seen without "quiet", but a lot of messages are printed in that mode and it will be less likely to cause undue alarm.

We could go all the way to KERN_DEBUG, but this is a real warning after all, so it seems prudent not to require "debug" to see it.

---
 drivers/pnp/pnpacpi/rsparser.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/pnp/pnpacpi/rsparser.c +4 -4
@@ -85,7 +85,7 @@ static void pnpacpi_parse_allocated_irqr
 	       i < PNP_MAX_IRQ)
 		i++;
 	if (i >= PNP_MAX_IRQ && !warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of IRQ "
 				"resources: %d \n", PNP_MAX_IRQ);
 		warned = 1;
 		return;
@@ -187,7 +187,7 @@ static void pnpacpi_parse_allocated_dmar
 		res->dma_resource[i].start = dma;
 		res->dma_resource[i].end = dma;
 	} else if (!warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of DMA "
 				"resources: %d \n", PNP_MAX_DMA);
 		warned = 1;
 	}
@@ -213,7 +213,7 @@ static void pnpacpi_parse_allocated_iore
 		res->port_resource[i].start = io;
 		res->port_resource[i].end = io + len - 1;
 	} else if (!warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of IO "
 				"resources: %d \n", PNP_MAX_PORT);
 		warned = 1;
 	}
@@ -241,7 +241,7 @@ static void pnpacpi_parse_allocated_memr
 		res->mem_resource[i].start = mem;
 		res->mem_resource[i].end = mem + len - 1;
 	} else if (!warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of mem "
 				"resources: %d\n", PNP_MAX_MEM);
 		warned = 1;
 	}
#4 lore raw

Re: pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."

drivers/pnp/pnpacpi/rsparser.c static void pnpacpi_parse_allocated_irqr · line 89

Quoted 3 lines · Chris Wright
drivers/pnp/pnpacpi/rsparser.c +1 -1
-		printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of IRQ "
 				"resources: %d \n", PNP_MAX_IRQ);

This is a good time to delete that whitespace before the newline in this hunk plus the two following. Unless you're going to go to dynamic memory allocation for these arrays in a month and wipe out all this code.

Nick.

#5 lore raw

Re: pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."

Quoted 9 lines · * Nick Andrew ([email protected]) wrote:

drivers/pnp/pnpacpi/rsparser.c static void pnpacpi_parse_allocated_irqr · line 89

Quoted 3 lines · Chris Wright
drivers/pnp/pnpacpi/rsparser.c +1 -1
-		printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of IRQ "
 				"resources: %d \n", PNP_MAX_IRQ);

This is a good time to delete that whitespace before the newline in this hunk plus the two following. Unless you're going to go to dynamic memory allocation for these arrays in a month and wipe out all this code.

Not for -stable...maybe upstream, send Len a patch.

#6 lore raw

Re: pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."

In reply to Chris Wright
Quoted 1 line · Chris Wright

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

I don't object to the point of the patch (changing KERN_ERR to KERN_WARNING), but there is a more serious bug lurking here that corrupts memory, and if we're doing a -stable patch, we should fix it.

The test is:

	if (i >= PNP_MAX_IRQ && !warned) {
		printk(...);
		warned = 1;
		return;
	}

But it should be:

	if (i >= PNP_MAX_IRQ) {
		if (!warned) {
			printk(...);
			warned = 1;
		}
		return;
	}
Quoted 39 lines
drivers/pnp/pnpacpi/rsparser.c +4 -4
@@ -85,7 +85,7 @@ static void pnpacpi_parse_allocated_irqr
 	       i < PNP_MAX_IRQ)
 		i++;
 	if (i >= PNP_MAX_IRQ && !warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of IRQ "
 				"resources: %d \n", PNP_MAX_IRQ);
 		warned = 1;
 		return;
@@ -187,7 +187,7 @@ static void pnpacpi_parse_allocated_dmar
 		res->dma_resource[i].start = dma;
 		res->dma_resource[i].end = dma;
 	} else if (!warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of DMA "
 				"resources: %d \n", PNP_MAX_DMA);
 		warned = 1;
 	}
@@ -213,7 +213,7 @@ static void pnpacpi_parse_allocated_iore
 		res->port_resource[i].start = io;
 		res->port_resource[i].end = io + len - 1;
 	} else if (!warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of IO "
 				"resources: %d \n", PNP_MAX_PORT);
 		warned = 1;
 	}
@@ -241,7 +241,7 @@ static void pnpacpi_parse_allocated_memr
 		res->mem_resource[i].start = mem;
 		res->mem_resource[i].end = mem + len - 1;
 	} else if (!warned) {
-		printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
+		printk(KERN_WARNING "pnpacpi: exceeded the max number of mem "
 				"resources: %d\n", PNP_MAX_MEM);
 		warned = 1;
 	}
reviewer
#7 lore raw

PATCH 1/1 pnpacpi: fix potential corruption on "pnpacpi: exceeded the max number of IRQ resources 2"

From: Len Brown <[email protected]>

PNP_MAX_IRQ is 2
If a device invokes pnpacpi_parse_allocated_irqresource() 0, 1, or 2 times, we are happy. The 3rd time, we will fail and print "pnpacpi: exceeded the max number of IRQ resources: 2" The 4th and subsequent calls (if this ever happened) would silently scribble on irq_resource[2], which doesn't actualy exist.

drivers/pnp/pnpacpi/rsparser.c +6 -4
index 2dcd196..98cbc9f 100644
@@ -84,10 +84,12 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
 	while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
 	       i < PNP_MAX_IRQ)
 		i++;
-	if (i >= PNP_MAX_IRQ && !warned) {
-		printk(KERN_WARNING "pnpacpi: exceeded the max number of IRQ "
-				"resources: %d \n", PNP_MAX_IRQ);
-		warned = 1;
+	if (i >= PNP_MAX_IRQ) {
+		if (!warned) {
+			printk(KERN_WARNING "pnpacpi: exceeded the max number"
+				" of IRQ resources: %d\n", PNP_MAX_IRQ);
+			warned = 1;
+		}
 		return;
 	}
 	/*
#8 lore raw

md: remove the super sysfs attribute from devices in an md array

In reply to Chris Wright

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

From: NeilBrown <[email protected]>

upstream commit: 0e82989d95cc46cc58622381eafa54f7428ee679

Exposing the binary blob which is the md 'super-block' via sysfs doesn't really fit with the whole sysfs model, and ever since commit 8118a859dc7abd873193986c77a8d9bdb877adc8 ("sysfs: fix off-by-one error in fill_read_buffer()") it doesn't actually work at all (as the size of the blob is often one page).

(akpm: as in, fs/sysfs/file.c:fill_read_buffer() goes BUG)

So just remove it altogether. It isn't really useful.

---
 drivers/md/md.c |   12 ------------
 1 file changed, 12 deletions(-)
drivers/md/md.c +0 -12
@@ -1847,17 +1847,6 @@ static struct rdev_sysfs_entry rdev_stat
 __ATTR(state, S_IRUGO|S_IWUSR, state_show, state_store);
 
 static ssize_t
-super_show(mdk_rdev_t *rdev, char *page)
-{
-	if (rdev->sb_loaded && rdev->sb_size) {
-		memcpy(page, page_address(rdev->sb_page), rdev->sb_size);
-		return rdev->sb_size;
-	} else
-		return 0;
-}
-static struct rdev_sysfs_entry rdev_super = __ATTR_RO(super);
-
-static ssize_t
 errors_show(mdk_rdev_t *rdev, char *page)
 {
 	return sprintf(page, "%d\n", atomic_read(&rdev->corrected_errors));
@@ -1959,7 +1948,6 @@ __ATTR(size, S_IRUGO|S_IWUSR, rdev_size_
 
 static struct attribute *rdev_default_attrs[] = {
 	&rdev_state.attr,
-	&rdev_super.attr,
 	&rdev_errors.attr,
 	&rdev_slot.attr,
 	&rdev_offset.attr,
#9 lore raw

pci: revert SMBus unhide on HP Compaq nx6110

In reply to Chris Wright

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

From: Jean Delvare <[email protected]>

upstream commit: a99acc832de1104afaba02d7c2576fd9b9fd6422

This reverts commit 3c0a654e390d00fef9d8faed758f5e1e8078adb5 and fixes kernel bug #10245:

	http://bugzilla.kernel.org/show_bug.cgi?id=10245

The HP Compaq nc6120 has the same PCI sub-device ID as the nx6110, and the SMBus is used by ACPI for thermal management on the nc6120, so Linux should not attach a native driver to it. This means that this quirk is unsafe and has to be removed.

I also added a comment to help developers realize that adding new IDs to this SMBus unhiding quirk table should be done only with great care, and in particular only after checking that ACPI is not making use of the SMBus.

---
 drivers/pci/quirks.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/pci/quirks.c +6 -5
@@ -950,6 +950,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
  * accesses to the SMBus registers, with potentially bad effects. Thus you
  * should be very careful when adding new entries: if SMM is accessing the
  * Intel SMBus, this is a very good reason to leave it hidden.
+ *
+ * Likewise, many recent laptops use ACPI for thermal management. If the
+ * ACPI DSDT code accesses the SMBus, then Linux should not access it
+ * natively, and keeping the SMBus hidden is the right thing to do. If you
+ * are about to add an entry in the table below, please first disassemble
+ * the DSDT and double-check that there is no code accessing the SMBus.
  */
 static int asus_hides_smbus;
 
@@ -1022,11 +1028,6 @@ static void __init asus_hides_smbus_host
 			case 0x12bd: /* HP D530 */
 				asus_hides_smbus = 1;
 			}
-		else if (dev->device == PCI_DEVICE_ID_INTEL_82915GM_HB)
-			switch (dev->subsystem_device) {
-			case 0x099c: /* HP Compaq nx6110 */
-				asus_hides_smbus = 1;
-			}
        } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_SAMSUNG)) {
                if (dev->device ==  PCI_DEVICE_ID_INTEL_82855PM_HB)
                        switch(dev->subsystem_device) {
#10 lore raw

fbdev: fix /proc/fb oops after module removal

In reply to Chris Wright

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

From: Alexey Dobriyan <[email protected]>

upstream commit: c43f89c2084f46e3ec59ddcbc52ecf4b1e9b015a

/proc/fb is not removed during rmmod.

Steps to reproduce:

modprobe fb
rmmod fb
ls /proc

BUG: unable to handle kernel paging request at ffffffffa0094370
IP: [<ffffffff802b92a1>] proc_get_inode+0x101/0x130
PGD 203067 PUD 207063 PMD 17e758067 PTE 0
Oops: 0000 [1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:05:02.0/resource
CPU 1
Modules linked in: nf_conntrack_irc xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables vfat fat usbhid ehci_hcd uhci_hcd usbcore sr_mod cdrom [last unloaded: fb]
Pid: 21205, comm: ls Not tainted 2.6.25-rc8-mm2 #14
RIP: 0010:[<ffffffff802b92a1>]  [<ffffffff802b92a1>] proc_get_inode+0x101/0x130
RSP: 0018:ffff81017c4bfc78  EFLAGS: 00010246
RAX: 0000000000008000 RBX: ffff8101787f5470 RCX: 0000000048011ccc
RDX: ffffffffa0094320 RSI: ffff810006ad43b0 RDI: ffff81017fc2cc00
RBP: ffff81017e450300 R08: 0000000000000002 R09: ffff81017c5d1000
R10: 0000000000000000 R11: 0000000000000246 R12: ffff81016b903a28
R13: ffff81017f822020 R14: ffff81017c4bfd58 R15: ffff81017f822020
FS:  00007f08e71696f0(0000) GS:ffff81017fc06480(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffffa0094370 CR3: 000000017e54a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ls (pid: 21205, threadinfo ffff81017c4be000, task ffff81017de48770)
Stack:  ffff81017c5d1000 00000000ffffffea ffff81017e450300 ffffffff802bdd1e
 ffff81017f802258 ffff81017c4bfe48 ffff81016b903a28 ffff81017f822020
 ffff81017c4bfd48 ffffffff802b9ba0 ffff81016b903a28 ffff81017f802258
Call Trace:
 [<ffffffff802bdd1e>] ? proc_lookup_de+0x8e/0x100
 [<ffffffff802b9ba0>] ? proc_root_lookup+0x20/0x60
 [<ffffffff802882a7>] ? do_lookup+0x1b7/0x210
 [<ffffffff8028883d>] ? __link_path_walk+0x53d/0x7f0
 [<ffffffff80295eb8>] ? mntput_no_expire+0x28/0x130
 [<ffffffff80288b4a>] ? path_walk+0x5a/0xc0
 [<ffffffff80288dd3>] ? do_path_lookup+0x83/0x1c0
 [<ffffffff80287785>] ? getname+0xe5/0x210
 [<ffffffff80289adb>] ? __user_walk_fd+0x4b/0x80
 [<ffffffff8028236c>] ? vfs_lstat_fd+0x2c/0x70
 [<ffffffff8028bf1e>] ? filldir+0xae/0xf0
 [<ffffffff802b92e9>] ? de_put+0x9/0x50
 [<ffffffff8029633d>] ? mnt_want_write+0x2d/0x80
 [<ffffffff8029339f>] ? touch_atime+0x1f/0x170
 [<ffffffff802b9b1d>] ? proc_root_readdir+0x7d/0xa0
 [<ffffffff802825e7>] ? sys_newlstat+0x27/0x50
 [<ffffffff8028bffb>] ? vfs_readdir+0x9b/0xd0
 [<ffffffff8028c0fe>] ? sys_getdents+0xce/0xe0
 [<ffffffff8020b39b>] ? system_call_after_swapgs+0x7b/0x80

Code: b7 83 b2 00 00 00 25 00 f0 00 00 3d 00 80 00 00 74 19 48 89 93 f0 00 00 00 48 89 df e8 39 9a fd ff 48 89 d8 48 83 c4 08 5b 5d c3 <48> 83 7a 50 00 48 c7 c0 60 16 45 80 48 c7 c2 40 17 45 80 48 0f
RIP  [<ffffffff802b92a1>] proc_get_inode+0x101/0x130
 RSP <ffff81017c4bfc78>
CR2: ffffffffa0094370
---[ end trace c71hiarjan8ab739 ]---

"Antonino A. Daplas" <[email protected]>

---
 drivers/video/fbmem.c |    1 +
 1 file changed, 1 insertion(+)
drivers/video/fbmem.c +1 -0
@@ -1521,6 +1521,7 @@ module_init(fbmem_init);
 static void __exit
 fbmem_exit(void)
 {
+	remove_proc_entry("fb", NULL);
 	class_destroy(fb_class);
 	unregister_chrdev(FB_MAJOR, "fb");
 }
#11 lore raw

USB: new quirk flag to avoid Set-Interface

In reply to Chris Wright

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

From: Alan Stern <[email protected]>

upstream commit: 392e1d9817d0024c96aae237c3c4349e47c976fd

This patch (as1057) fixes a problem with the X-Rite/Gretag-Macbeth Eye-One Pro display colorimeter; the device crashes when it receives a Set-Interface request. A new quirk (USB_QUIRK_NO_SET_INTF) is introduced and a quirks entry is created for this device.

---
 drivers/usb/core/message.c |    5 ++++-
 drivers/usb/core/quirks.c  |    3 +++
 include/linux/usb/quirks.h |    3 +++
 3 files changed, 10 insertions(+), 1 deletion(-)
drivers/usb/core/message.c +4 -1
@@ -1189,7 +1189,10 @@ int usb_set_interface(struct usb_device 
 		return -EINVAL;
 	}
 
-	ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+	if (dev->quirks & USB_QUIRK_NO_SET_INTF)
+		ret = -EPIPE;
+	else
+		ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
 				   USB_REQ_SET_INTERFACE, USB_RECIP_INTERFACE,
 				   alternate, interface, NULL, 0, 5000);
 
drivers/usb/core/quirks.c +3 -0
@@ -39,6 +39,9 @@ static const struct usb_device_id usb_qu
 	/* M-Systems Flash Disk Pioneers */
 	{ USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* X-Rite/Gretag-Macbeth Eye-One Pro display colorimeter */
+	{ USB_DEVICE(0x0971, 0x2000), .driver_info = USB_QUIRK_NO_SET_INTF },
+
 	/* Philips PSC805 audio device */
 	{ USB_DEVICE(0x0471, 0x0155), .driver_info = USB_QUIRK_RESET_RESUME },
 
include/linux/usb/quirks.h +3 -0
@@ -9,3 +9,6 @@
 
 /* device can't resume correctly so reset it instead */
 #define USB_QUIRK_RESET_RESUME		0x00000002
+
+/* device can't handle Set-Interface requests */
+#define USB_QUIRK_NO_SET_INTF		0x00000004
#12 lore raw

V4L: ivtv: Add missing sg_init_table()

In reply to Chris Wright

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

From: Ian Armstrong <[email protected]>

upstream commit: 165e1213e13b49761f8b3fd9314701f83cf3db3a

If a dma transfer is attempted for either yuv or framebuffer output, a missing sg_init_table() call causes a kernel BUG in scatterlist.h if CONFIG_DEBUG_SG is set.

---
 drivers/media/video/ivtv/ivtv-driver.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/media/video/ivtv/ivtv-driver.c +3 -0
@@ -687,6 +687,9 @@ static int __devinit ivtv_init_struct1(s
 	itv->vbi.in.type = V4L2_BUF_TYPE_SLICED_VBI_CAPTURE;
 	itv->vbi.sliced_in = &itv->vbi.in.fmt.sliced;
 
+	/* Init the sg table for osd/yuv output */
+	sg_init_table(itv->udma.SGlist, IVTV_DMA_SG_OSD_ENT);
+
 	/* OSD */
 	itv->osd_global_alpha_state = 1;
 	itv->osd_global_alpha = 255;
#13 lore raw

UIO: add pgprot_noncached() to UIO mmap code

In reply to Chris Wright

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

From: Jean-Samuel Chenard <[email protected]>

upstream commit: c9698d6b1a90929e427a165bd8283f803f57d9bd

Mapping of physical memory in UIO needs pgprot_noncached() to ensure that IO memory is not cached. Without pgprot_noncached(), it (accidentally) works on x86 and arm, but fails on PPC.

---
 drivers/uio/uio.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/uio/uio.c +2 -0
@@ -447,6 +447,8 @@ static int uio_mmap_physical(struct vm_a
 
 	vma->vm_flags |= VM_IO | VM_RESERVED;
 
+	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
 	return remap_pfn_range(vma,
 			       vma->vm_start,
 			       idev->info->mem[mi].addr >> PAGE_SHIFT,
#14 lore raw

acpi: bus: check once more for an empty list after locking it

In reply to Chris Wright

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

From: Chuck Ebbert <[email protected]>

upstream commit: f0a37e008750ead1751b7d5e89d220a260a46147

List could have become empty after the unlocked check that was made earlier, so check again inside the lock.

Should fix https://bugzilla.redhat.com/show_bug.cgi?id=427765

---
 drivers/acpi/bus.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/acpi/bus.c +4 -3
@@ -350,10 +350,11 @@ int acpi_bus_receive_event(struct acpi_b
 	}
 
 	spin_lock_irqsave(&acpi_bus_event_lock, flags);
-	entry =
-	    list_entry(acpi_bus_event_list.next, struct acpi_bus_event, node);
-	if (entry)
+	if (!list_empty(&acpi_bus_event_list)) {
+		entry = list_entry(acpi_bus_event_list.next,
+				   struct acpi_bus_event, node);
 		list_del(&entry->node);
+	}
 	spin_unlock_irqrestore(&acpi_bus_event_lock, flags);
 
 	if (!entry)
#15 lore raw

LLC: Restrict LLC sockets to root

In reply to Chris Wright

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

From: Patrick McHardy <[email protected]>

Upstream commit: 3480c63bdf008e9289aab94418f43b9592978fff

LLC currently allows users to inject raw frames, including IP packets encapsulated in SNAP. While Linux doesn't handle IP over SNAP, other systems do. Restrict LLC sockets to root similar to packet sockets.

[ Modified Patrick's patch to use CAP_NEW_RAW --DaveM ]

---
 net/llc/af_llc.c |    3 +++
 1 file changed, 3 insertions(+)
net/llc/af_llc.c +3 -0
@@ -155,6 +155,9 @@ static int llc_ui_create(struct net *net
 	struct sock *sk;
 	int rc = -ESOCKTNOSUPPORT;
 
+	if (!capable(CAP_NET_RAW))
+		return -EPERM;
+
 	if (net != &init_net)
 		return -EAFNOSUPPORT;
 
#16 lore raw

netpoll: zap_completion_queue: adjust skb->users counter

In reply to Chris Wright

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

From: Jarek Poplawski <[email protected]>

Upstream commit: 8a455b087c9629b3ae3b521b4f1ed16672f978cc

zap_completion_queue() retrieves skbs from completion_queue where they have zero skb->users counter. Before dev_kfree_skb_any() it should be non-zero yet, so it's increased now.

---
 net/core/netpoll.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
net/core/netpoll.c +4 -2
@@ -219,10 +219,12 @@ static void zap_completion_queue(void)
 		while (clist != NULL) {
 			struct sk_buff *skb = clist;
 			clist = clist->next;
-			if (skb->destructor)
+			if (skb->destructor) {
+				atomic_inc(&skb->users);
 				dev_kfree_skb_any(skb); /* put this one back */
-			else
+			} else {
 				__kfree_skb(skb);
+			}
 		}
 	}
 
#17 lore raw

vfs: fix data leak in nobh_write_end()

In reply to Chris Wright

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

From: Dmitri Monakhov <[email protected]>

upstream commit: 5b41e74ad1b0bf7bc51765ae74e5dc564afc3e48

Current nobh_write_end() implementation ignore partial writes(copied < len) case if page was fully mapped and simply mark page as Uptodate, which is totally wrong because area [pos+copied, pos+len) wasn't updated explicitly in previous write_begin call. It simply contains garbage from pagecache and result in data leakage.

#TEST_CASE_BEGIN:
~~~~~~~~~~~~~~~~
In fact issue triggered by classical testcase

	open("/mnt/test", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
	ftruncate(3, 409600)                    = 0
	writev(3, [{"a", 1}, {NULL, 4095}], 2)  = 1

##TESTCASE_SOURCE:
~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/uio.h>
#include <sys/mman.h>
#include <errno.h>
int main(int argc, char **argv)

{
	int fd,  ret;
	void* p;
	struct iovec iov[2];
	fd = open(argv[1], O_RDWR|O_CREAT|O_TRUNC, 0666);
	ftruncate(fd, 409600);
	iov[0].iov_base="a";
	iov[0].iov_len=1;
	iov[1].iov_base=NULL;
	iov[1].iov_len=4096;
	ret = writev(fd, iov, sizeof(iov)/sizeof(struct iovec));
	printf("writev  = %d, err = %d\n", ret, errno);
	return 0;
}

##TESTCASE RESULT:
~~~~~~~~~~~~~~~~~~
[root@ts63 ~]# mount | grep mnt2
/dev/mapper/test on /mnt2 type ext2 (rw,nobh)
[root@ts63 ~]# /tmp/writev /mnt2/test
writev = 1, err = 0
[root@ts63 ~]# hexdump -C /mnt2/test

00000000  61 65 62 6f 6f 74 00 00  f0 b9 b4 59 3a 00 00 00  |aeboot.....Y:...|
00000010  20 00 00 00 00 00 00 00  21 00 00 00 00 00 00 00  | .......!.......|
00000020  df df df df df df df df  df df df df df df df df  |................|
00000030  3a 00 00 00 2a 00 00 00  21 00 00 00 00 00 00 00  |:...*...!.......|
00000040  60 c0 8c 00 00 00 00 00  40 4a 8d 00 00 00 00 00  |`.......@J......|
00000050  00 00 00 00 00 00 00 00  41 00 00 00 00 00 00 00  |........A.......|
00000060  74 69 6d 65 20 64 64 20  69 66 3d 2f 64 65 76 2f  |time dd if=/dev/|
00000070  6c 6f 6f 70 30 20 20 6f  66 3d 2f 64 65 76 2f 6e  |loop0  of=/dev/n|
skip..
00000f50  00 00 00 00 00 00 00 00  31 00 00 00 00 00 00 00  |........1.......|
00000f60  6d 6b 66 73 2e 65 78 74  33 20 2f 64 65 76 2f 76  |mkfs.ext3 /dev/v|
00000f70  7a 76 67 2f 74 65 73 74  20 2d 62 34 30 39 36 00  |zvg/test -b4096.|
00000f80  a0 fe 8c 00 00 00 00 00  21 00 00 00 00 00 00 00  |........!.......|
00000f90  23 31 32 30 35 39 35 30  34 30 34 00 3a 00 00 00  |#1205950404.:...|
00000fa0  20 00 8d 00 00 00 00 00  21 00 00 00 00 00 00 00  | .......!.......|
00000fb0  d0 cf 8c 00 00 00 00 00  10 d0 8c 00 00 00 00 00  |................|
00000fc0  00 00 00 00 00 00 00 00  41 00 00 00 00 00 00 00  |........A.......|
00000fd0  6d 6f 75 6e 74 20 2f 64  65 76 2f 76 7a 76 67 2f  |mount /dev/vzvg/|
00000fe0  74 65 73 74 20 20 2f 76  7a 20 2d 6f 20 64 61 74  |test  /vz -o dat|
00000ff0  61 3d 77 72 69 74 65 62  61 63 6b 00 00 00 00 00  |a=writeback.....|
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

As you can see file's page contains garbage from pagecache instead of zeros. #TEST_CASE_END

Attached patch:
- Add sanity check BUG_ON in order to prevent incorrect usage by caller, This is function invariant because page can has buffers and in no zero *fadata pointer at the same time.
- Always attach buffers to page is it is partial write case.
- Always switch back to generic_write_end if page has buffers.
This is reasonable because if page already has buffer then generic_write_begin was called previously.

---
 fs/buffer.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)
fs/buffer.c +6 -7
@@ -2565,14 +2565,13 @@ int nobh_write_end(struct file *file, st
 	struct inode *inode = page->mapping->host;
 	struct buffer_head *head = fsdata;
 	struct buffer_head *bh;
+	BUG_ON(fsdata != NULL && page_has_buffers(page));
 
-	if (!PageMappedToDisk(page)) {
-		if (unlikely(copied < len) && !page_has_buffers(page))
-			attach_nobh_buffers(page, head);
-		if (page_has_buffers(page))
-			return generic_write_end(file, mapping, pos, len,
-						copied, page, fsdata);
-	}
+	if (unlikely(copied < len) && !page_has_buffers(page))
+		attach_nobh_buffers(page, head);
+	if (page_has_buffers(page))
+		return generic_write_end(file, mapping, pos, len,
+					copied, page, fsdata);
 
 	SetPageUptodate(page);
 	set_page_dirty(page);
#18 lore raw

USB: add support for Motorola ROKR Z6 cellphone in mass storage mode

In reply to Chris Wright

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

From: Constantin Baranov <[email protected]>

upstream commit: cc36bdd47ae51b66780b317c1fa519221f894405

Motorola ROKR Z6 cellphone has bugs in its USB, so it is impossible to use it as mass storage. Patch describes new "unusual" USB device for it with FIX_INQUIRY and FIX_CAPACITY flags and new BULK_IGNORE_TAG flag. Last flag relaxes check for equality of bcs->Tag and us->tag in usb_stor_Bulk_transport routine.

---
 drivers/usb/storage/transport.c    |    3 ++-
 drivers/usb/storage/unusual_devs.h |   11 +++++++++++
 include/linux/usb_usual.h          |    4 +++-
 3 files changed, 16 insertions(+), 2 deletions(-)
drivers/usb/storage/transport.c +2 -1
@@ -1010,7 +1010,8 @@ int usb_stor_Bulk_transport(struct scsi_
 	US_DEBUGP("Bulk Status S 0x%x T 0x%x R %u Stat 0x%x\n",
 			le32_to_cpu(bcs->Signature), bcs->Tag, 
 			residue, bcs->Status);
-	if (bcs->Tag != us->tag || bcs->Status > US_BULK_STAT_PHASE) {
+	if (!(bcs->Tag == us->tag || (us->flags & US_FL_BULK_IGNORE_TAG)) ||
+		bcs->Status > US_BULK_STAT_PHASE) {
 		US_DEBUGP("Bulk logical error\n");
 		return USB_STOR_TRANSPORT_ERROR;
 	}
drivers/usb/storage/unusual_devs.h +11 -0
@@ -1557,6 +1557,17 @@ UNUSUAL_DEV(  0x22b8, 0x4810, 0x0001, 0x
 		US_SC_DEVICE, US_PR_DEVICE, NULL,
 		US_FL_FIX_CAPACITY),
 
+/*
+ * Patch by Constantin Baranov <[email protected]>
+ * Report by Andreas Koenecke.
+ * Motorola ROKR Z6.
+ */
+UNUSUAL_DEV(  0x22b8, 0x6426, 0x0101, 0x0101,
+		"Motorola",
+		"MSnc.",
+		US_SC_DEVICE, US_PR_DEVICE, NULL,
+		US_FL_FIX_INQUIRY | US_FL_FIX_CAPACITY | US_FL_BULK_IGNORE_TAG),
+
 /* Reported by Radovan Garabik <[email protected]> */
 UNUSUAL_DEV(  0x2735, 0x100b, 0x0000, 0x9999,
 		"MPIO",
include/linux/usb_usual.h +3 -1
@@ -50,7 +50,9 @@
 	US_FLAG(CAPACITY_HEURISTICS,	0x00001000)		\
 		/* sometimes sizes is too big */		\
 	US_FLAG(MAX_SECTORS_MIN,0x00002000)			\
-		/* Sets max_sectors to arch min */
+		/* Sets max_sectors to arch min */		\
+	US_FLAG(BULK_IGNORE_TAG,0x00004000)			\
+		/* Ignore tag mismatch in bulk operations */
 
 
 #define US_FLAG(name, value)	US_FL_##name = value ,
#19 lore raw

slab: fix cache_cache bootstrap in kmem_cache_init()

In reply to Chris Wright

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

From: Daniel Yeisley <[email protected]>

upstream commit: ec1f5eeeb5a79a0d48036de649a3498da42db565

Commit 556a169dab38b5100df6f4a45b655dddd3db94c1 ("slab: fix bootstrap on memoryless node") introduced bootstrap-time cache_cache list3s for all nodes but forgot that initkmem_list3 needs to be accessed by [somevalue + node]. This patch fixes list_add() corruption in mm/slab.c seen on the ES7000.

---
 mm/slab.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/slab.c +2 -2
@@ -1484,7 +1484,7 @@ void __init kmem_cache_init(void)
 	list_add(&cache_cache.next, &cache_chain);
 	cache_cache.colour_off = cache_line_size();
 	cache_cache.array[smp_processor_id()] = &initarray_cache.cache;
-	cache_cache.nodelists[node] = &initkmem_list3[CACHE_CACHE];
+	cache_cache.nodelists[node] = &initkmem_list3[CACHE_CACHE + node];
 
 	/*
 	 * struct kmem_cache size depends on nr_node_ids, which
@@ -1605,7 +1605,7 @@ void __init kmem_cache_init(void)
 		int nid;
 
 		for_each_online_node(nid) {
-			init_list(&cache_cache, &initkmem_list3[CACHE_CACHE], nid);
+			init_list(&cache_cache, &initkmem_list3[CACHE_CACHE + nid], nid);
 
 			init_list(malloc_sizes[INDEX_AC].cs_cachep,
 				  &initkmem_list3[SIZE_AC + nid], nid);
#20 lore raw

PPPOL2TP: Fix SMP issues in skb reorder queue handling

In reply to Chris Wright

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

From: James Chapman <[email protected]>

Upstream commit: e653181dd6b3ad38ce14904351b03a5388f4b0f7

When walking a session's packet reorder queue, use skb_queue_walk_safe() since the list could be modified inside the loop.

Rearrange the unlinking skbs from the reorder queue such that it is done while the queue lock is held in pppol2tp_recv_dequeue() when walking the skb list.

A version of this patch was suggested by Jarek Poplawski.

---
 drivers/net/pppol2tp.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/net/pppol2tp.c +8 -3
@@ -342,10 +342,11 @@ static struct pppol2tp_tunnel *pppol2tp_
 static void pppol2tp_recv_queue_skb(struct pppol2tp_session *session, struct sk_buff *skb)
 {
 	struct sk_buff *skbp;
+	struct sk_buff *tmp;
 	u16 ns = PPPOL2TP_SKB_CB(skb)->ns;
 
 	spin_lock_bh(&session->reorder_q.lock);
-	skb_queue_walk(&session->reorder_q, skbp) {
+	skb_queue_walk_safe(&session->reorder_q, skbp, tmp) {
 		if (PPPOL2TP_SKB_CB(skbp)->ns > ns) {
 			__skb_insert(skb, skbp->prev, skbp, &session->reorder_q);
 			PRINTK(session->debug, PPPOL2TP_MSG_SEQ, KERN_DEBUG,
@@ -371,10 +372,9 @@ static void pppol2tp_recv_dequeue_skb(st
 	int length = PPPOL2TP_SKB_CB(skb)->length;
 	struct sock *session_sock = NULL;
 
-	/* We're about to requeue the skb, so unlink it and return resources
+	/* We're about to requeue the skb, so return resources
 	 * to its current owner (a socket receive buffer).
 	 */
-	skb_unlink(skb, &session->reorder_q);
 	skb_orphan(skb);
 
 	tunnel->stats.rx_packets++;
@@ -469,6 +469,11 @@ static void pppol2tp_recv_dequeue(struct
 				goto out;
 			}
 		}
+		__skb_unlink(skb, &session->reorder_q);
+
+		/* Process the skb. We release the queue lock while we
+		 * do so to let other contexts process the queue.
+		 */
 		spin_unlock_bh(&session->reorder_q.lock);
 		pppol2tp_recv_dequeue_skb(session, skb);
 		spin_lock_bh(&session->reorder_q.lock);
#21 lore raw

SUNGEM: Fix NAPI assertion failure.

In reply to Chris Wright

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

From: David S. Miller <[email protected]>

Upstream commit: da990a2402aeaee84837f29054c4628eb02f7493

As reported by Johannes Berg:

I started getting this warning with recent kernels:

[  773.908927] ------------[ cut here ]------------
[  773.908954] Badness at net/core/dev.c:2204
 ...

If we loop more than once in gem_poll(), we'll use more than the real budget in our gem_rx() calls, thus eventually trigger the caller's assertions in net_rx_action().

Subtract "work_done" from "budget" for the second arg to gem_rx() to fix the bug.

---
 drivers/net/sungem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/sungem.c +1 -1
@@ -910,7 +910,7 @@ static int gem_poll(struct napi_struct *
 		 * rx ring - must call napi_disable(), which
 		 * schedule_timeout()'s if polling is already disabled.
 		 */
-		work_done += gem_rx(gp, budget);
+		work_done += gem_rx(gp, budget - work_done);
 
 		if (work_done >= budget)
 			return work_done;
#22 lore raw

NET: Add preemption point in qdisc_run

In reply to Chris Wright

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

From: Herbert Xu <[email protected]>

Upstream commit: 2ba2506ca7ca62c56edaa334b0fe61eb5eab6ab0

The qdisc_run loop is currently unbounded and runs entirely in a softirq. This is bad as it may create an unbounded softirq run.

This patch fixes this by calling need_resched and breaking out if necessary.

It also adds a break out if the jiffies value changes since that would indicate we've been transmitting for too long which starves other softirqs.

---
 net/sched/sch_generic.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)
net/sched/sch_generic.c +15 -3
@@ -178,10 +178,22 @@ static inline int qdisc_restart(struct n
 
 void __qdisc_run(struct net_device *dev)
 {
-	do {
-		if (!qdisc_restart(dev))
+	unsigned long start_time = jiffies;
+
+	while (qdisc_restart(dev)) {
+		if (netif_queue_stopped(dev))
+			break;
+
+		/*
+		 * Postpone processing if
+		 * 1. another process needs the CPU;
+		 * 2. we've been doing it for too long.
+		 */
+		if (need_resched() || jiffies != start_time) {
+			netif_schedule(dev);
 			break;
-	} while (!netif_queue_stopped(dev));
+		}
+	}
 
 	clear_bit(__LINK_STATE_QDISC_RUNNING, &dev->state);
 }
#23 lore raw

NET: Fix multicast device ioctl checks

In reply to Chris Wright

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

From: Patrick McHardy <[email protected]>

Upstream commit: 61ee6bd487b9cc160e533034eb338f2085dc7922

SIOCADDMULTI/SIOCDELMULTI check whether the driver has a set_multicast_list method to determine whether it supports multicast. Drivers implementing secondary unicast support use set_rx_mode however.

Check for both dev->set_multicast_mode and dev->set_rx_mode to determine multicast capabilities.

---
 net/core/dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/core/dev.c +2 -2
@@ -3240,7 +3240,7 @@ static int dev_ifsioc(struct net *net, s
 			return -EOPNOTSUPP;
 
 		case SIOCADDMULTI:
-			if (!dev->set_multicast_list ||
+			if ((!dev->set_multicast_list && !dev->set_rx_mode) ||
 			    ifr->ifr_hwaddr.sa_family != AF_UNSPEC)
 				return -EINVAL;
 			if (!netif_device_present(dev))
@@ -3249,7 +3249,7 @@ static int dev_ifsioc(struct net *net, s
 					  dev->addr_len, 1);
 
 		case SIOCDELMULTI:
-			if (!dev->set_multicast_list ||
+			if ((!dev->set_multicast_list && !dev->set_rx_mode) ||
 			    ifr->ifr_hwaddr.sa_family != AF_UNSPEC)
 				return -EINVAL;
 			if (!netif_device_present(dev))
#24 lore raw

TCP: Let skbs grow over a page on fast peers

In reply to Chris Wright

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

From: Herbert Xu <[email protected]>

Upstream commit: 69d1506731168d6845a76a303b2c45f7c05f3f2c

While testing the virtio-net driver on KVM with TSO I noticed that TSO performance with a 1500 MTU is significantly worse compared to the performance of non-TSO with a 16436 MTU. The packet dump shows that most of the packets sent are smaller than a page.

Looking at the code this actually is quite obvious as it always stop extending the packet if it's the first packet yet to be sent and if it's larger than the MSS. Since each extension is bound by the page size, this means that (given a 1500 MTU) we're very unlikely to construct packets greater than a page, provided that the receiver and the path is fast enough so that packets can always be sent immediately.

The fix is also quite obvious. The push calls inside the loop is just an optimisation so that we don't end up doing all the sending at the end of the loop. Therefore there is no specific reason why it has to do so at MSS boundaries. For TSO, the most natural extension of this optimisation is to do the pushing once the skb exceeds the TSO size goal.

This is what the patch does and testing with KVM shows that the TSO performance with a 1500 MTU easily surpasses that of a 16436 MTU and indeed the packet sizes sent are generally larger than 16436.

I don't see any obvious downsides for slower peers or connections, but it would be prudent to test this extensively to ensure that those cases don't regress.

---
 net/ipv4/tcp.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/ipv4/tcp.c +2 -2
@@ -583,7 +583,7 @@ new_segment:
 		if (!(psize -= copy))
 			goto out;
 
-		if (skb->len < mss_now || (flags & MSG_OOB))
+		if (skb->len < size_goal || (flags & MSG_OOB))
 			continue;
 
 		if (forced_push(tp)) {
@@ -829,7 +829,7 @@ new_segment:
 			if ((seglen -= copy) == 0 && iovlen == 0)
 				goto out;
 
-			if (skb->len < mss_now || (flags & MSG_OOB))
+			if (skb->len < size_goal || (flags & MSG_OOB))
 				continue;
 
 			if (forced_push(tp)) {
#25 lore raw

NOHZ: reevaluate idle sleep length after add_timer_on()

In reply to Chris Wright

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

From: Thomas Gleixner <[email protected]>

upstream commit: 06d8308c61e54346585b2691c13ee3f90cb6fb2f

add_timer_on() can add a timer on a CPU which is currently in a long idle sleep, but the timer wheel is not reevaluated by the nohz code on that CPU. So a timer can be delayed for quite a long time. This triggered a false positive in the clocksource watchdog code.

To avoid this we need to wake up the idle CPU and enforce the reevaluation of the timer wheel for the next timer event.

Add a function, which checks a given CPU for idle state, marks the idle task with NEED_RESCHED and sends a reschedule IPI to notify the other CPU of the change in the timer wheel.

Call this function from add_timer_on().

--

 include/linux/sched.h |    6 ++++++
 kernel/sched.c        |   43 +++++++++++++++++++++++++++++++++++++++++++
 kernel/timer.c        |   10 +++++++++-
 3 files changed, 58 insertions(+), 1 deletion(-)

---

include/linux/sched.h +6 -0
@@ -1449,6 +1449,12 @@ static inline void idle_task_exit(void) 
 
 extern void sched_idle_next(void);
 
+#if defined(CONFIG_NO_HZ) && defined(CONFIG_SMP)
+extern void wake_up_idle_cpu(int cpu);
+#else
+static inline void wake_up_idle_cpu(int cpu) { }
+#endif
+
 #ifdef CONFIG_SCHED_DEBUG
 extern unsigned int sysctl_sched_latency;
 extern unsigned int sysctl_sched_min_granularity;
kernel/sched.c +43 -0

49 lines not on this page · raw message

kernel/timer.c +9 -1
@@ -453,10 +453,18 @@ void add_timer_on(struct timer_list *tim
 	spin_lock_irqsave(&base->lock, flags);
 	timer_set_base(timer, base);
 	internal_add_timer(base, timer);
+	/*
+	 * Check whether the other CPU is idle and needs to be
+	 * triggered to reevaluate the timer wheel when nohz is
+	 * active. We are protected against the other CPU fiddling
+	 * with the timer by holding the timer base lock. This also
+	 * makes sure that a CPU on the way to idle can not evaluate
+	 * the timer wheel.
+	 */
+	wake_up_idle_cpu(cpu);
 	spin_unlock_irqrestore(&base->lock, flags);
 }
 
-
 /**
  * mod_timer - modify a timer's timeout
  * @timer: the timer to be modified
#26 lore raw

inotify: fix race

In reply to Chris Wright

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

From: Nick Piggin <[email protected]>

upstream commit: d599e36a9ea85432587f4550acc113cd7549d12a

There is a race between setting an inode's children's "parent watched" flag when placing the first watch on a parent, and instantiating new children of that parent: a child could miss having its flags set by set_dentry_child_flags, but then inotify_d_instantiate might still see !inotify_inode_watched.

The solution is to set_dentry_child_flags after adding the watch. Locking is taken care of, because both set_dentry_child_flags and inotify_d_instantiate hold dcache_lock and child->d_locks.

---
 fs/inotify.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
fs/inotify.c +10 -3
@@ -627,6 +627,7 @@ s32 inotify_add_watch(struct inotify_han
 		      struct inode *inode, u32 mask)
 {
 	int ret = 0;
+	int newly_watched;
 
 	/* don't allow invalid bits: we don't want flags set */
 	mask &= IN_ALL_EVENTS | IN_ONESHOT;
@@ -653,12 +654,18 @@ s32 inotify_add_watch(struct inotify_han
 	 */
 	watch->inode = igrab(inode);
 
-	if (!inotify_inode_watched(inode))
-		set_dentry_child_flags(inode, 1);
-
 	/* Add the watch to the handle's and the inode's list */
+	newly_watched = !inotify_inode_watched(inode);
 	list_add(&watch->h_list, &ih->watches);
 	list_add(&watch->i_list, &inode->inotify_watches);
+	/*
+	 * Set child flags _after_ adding the watch, so there is no race
+	 * windows where newly instantiated children could miss their parent's
+	 * watched flag.
+	 */
+	if (newly_watched)
+		set_dentry_child_flags(inode, 1);
+
 out:
 	mutex_unlock(&ih->mutex);
 	mutex_unlock(&inode->inotify_mutex);
#27 lore raw

xen: fix UP setup of shared_info

In reply to Chris Wright

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

From: Jeremy Fitzhardinge <[email protected]>

upstream commit: 2e8fe719b57bbdc9e313daed1204bb55fed3ed44

We need to set up the shared_info pointer once we've mapped the real shared_info into its fixmap slot. That needs to happen once the general pagetable setup has been done. Previously, the UP shared_info was set up one in xen_start_kernel, but that was left pointing to the dummy shared info. Unfortunately there's no really good place to do a later setup of the shared_info in UP, so just do it once the pagetable setup has been done.

---
 arch/x86/xen/enlighten.c |   39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)
arch/x86/xen/enlighten.c +22 -17
@@ -103,6 +103,7 @@ static void __init xen_vcpu_setup(int cp
 	int err;
 	struct vcpu_info *vcpup;
 
+	BUG_ON(HYPERVISOR_shared_info == &dummy_shared_info);
 	per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 
 	if (!have_vcpu_info_placement)
@@ -792,30 +793,40 @@ static __init void xen_pagetable_setup_s
 	xen_write_cr3(__pa(base));
 }
 
-static __init void xen_pagetable_setup_done(pgd_t *base)
+static __init void setup_shared_info(void)
 {
-	/* This will work as long as patching hasn't happened yet
-	   (which it hasn't) */
-	pv_mmu_ops.alloc_pt = xen_alloc_pt;
-	pv_mmu_ops.set_pte = xen_set_pte;
-
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+		unsigned long addr = fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+
 		/*
 		 * Create a mapping for the shared info page.
 		 * Should be set_fixmap(), but shared_info is a machine
 		 * address with no corresponding pseudo-phys address.
 		 */
-		set_pte_mfn(fix_to_virt(FIX_PARAVIRT_BOOTMAP),
+		set_pte_mfn(addr,
 			    PFN_DOWN(xen_start_info->shared_info),
 			    PAGE_KERNEL);
 
-		HYPERVISOR_shared_info =
-			(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
-
+		HYPERVISOR_shared_info = (struct shared_info *)addr;
 	} else
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+#ifndef CONFIG_SMP
+	/* In UP this is as good a place as any to set up shared info */
+	xen_setup_vcpu_info_placement();
+#endif
+}
+
+static __init void xen_pagetable_setup_done(pgd_t *base)
+{
+	/* This will work as long as patching hasn't happened yet
+	   (which it hasn't) */
+	pv_mmu_ops.alloc_pt = xen_alloc_pt;
+	pv_mmu_ops.set_pte = xen_set_pte;
+
+	setup_shared_info();
+
 	/* Actually pin the pagetable down, but we can't set PG_pinned
 	   yet because the page structures don't exist yet. */
 	{
@@ -1166,15 +1177,9 @@ asmlinkage void __init xen_start_kernel(
 	x86_write_percpu(xen_cr3, __pa(pgd));
 	x86_write_percpu(xen_current_cr3, __pa(pgd));
 
-#ifdef CONFIG_SMP
 	/* Don't do the full vcpu_info placement stuff until we have a
-	   possible map. */
+	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
-#else
-	/* May as well do it now, since there's no good time to call
-	   it later on UP. */
-	xen_setup_vcpu_info_placement();
-#endif
 
 	pv_info.kernel_rpl = 1;
 	if (xen_feature(XENFEAT_supervisor_mode_kernel))
#28 lore raw

time: prevent the loop in timespec_add_ns() from being optimised away

In reply to Chris Wright

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

From: Segher Boessenkool <[email protected]>

upstream commit: 38332cb98772f5ea757e6486bed7ed0381cb5f98

Since some architectures don't support __udivdi3().

---
 include/linux/time.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/time.h +4 -0
@@ -173,6 +173,10 @@ static inline void timespec_add_ns(struc
 {
 	ns += a->tv_nsec;
 	while(unlikely(ns >= NSEC_PER_SEC)) {
+		/* The following asm() prevents the compiler from
+		 * optimising this loop into a modulo operation.  */
+		asm("" : "+r"(ns));
+
 		ns -= NSEC_PER_SEC;
 		a->tv_sec++;
 	}
#29 lore raw

TCP: Fix shrinking windows with window scaling

In reply to Chris Wright

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

From: Patrick McHardy <[email protected]>

Upstream commit: 607bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723

When selecting a new window, tcp_select_window() tries not to shrink the offered window by using the maximum of the remaining offered window size and the newly calculated window size. The newly calculated window size is always a multiple of the window scaling factor, the remaining window size however might not be since it depends on rcv_wup/rcv_nxt. This means we're effectively shrinking the window when scaling it down.

The dump below shows the problem (scaling factor 2^7):

- Window size of 557 (71296) is advertised, up to 3111907257:

IP 172.2.2.3.33000 > 172.2.2.2.33000: . ack 3111835961 win 557 <...>

- New window size of 514 (65792) is advertised, up to 3111907217, 40 bytes below the last end:

IP 172.2.2.3.33000 > 172.2.2.2.33000: . 3113575668:3113577116(1448) ack 3111841425 win 514 <...>

The number 40 results from downscaling the remaining window:

3111907257 - 3111841425 = 65832
65832 / 2^7 = 514
65832 % 2^7 = 40

If the sender uses up the entire window before it is shrunk, this can have chaotic effects on the connection. When sending ACKs, tcp_acceptable_seq() will notice that the window has been shrunk since tcp_wnd_end() is before tp->snd_nxt, which makes it choose tcp_wnd_end() as sequence number. This will fail the receivers checks in tcp_sequence() however since it is before it's tp->rcv_wup, making it respond with a dupack.

If both sides are in this condition, this leads to a constant flood of ACKs until the connection times out.

Make sure the window is never shrunk by aligning the remaining window to the window scaling factor.

---
 net/ipv4/tcp_output.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/tcp_output.c +1 -1
@@ -258,7 +258,7 @@ static u16 tcp_select_window(struct sock
 		 *
 		 * Relax Will Robinson.
 		 */
-		new_win = cur_win;
+		new_win = ALIGN(cur_win, 1 << tp->rx_opt.rcv_wscale);
 	}
 	tp->rcv_wnd = new_win;
 	tp->rcv_wup = tp->rcv_nxt;
#30 lore raw

alloc_percpu() fails to allocate percpu data

In reply to Chris Wright

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

From: Eric Dumazet <[email protected]>

upstream commit: be852795e1c8d3829ddf3cb1ce806113611fa555

Some oprofile results obtained while using tbench on a 2x2 cpu machine were very surprising.

For example, loopback_xmit() function was using high number of cpu cycles to perform the statistic updates, supposed to be real cheap since they use percpu data

        pcpu_lstats = netdev_priv(dev);
        lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
        lb_stats->packets++;  /* HERE : serious contention */
        lb_stats->bytes += skb->len;

struct pcpu_lstats is a small structure containing two longs. It appears that on my 32bits platform, alloc_percpu(8) allocates a single cache line, instead of giving to each cpu a separate cache line.

Using the following patch gave me impressive boost in various benchmarks ( 6 % in tbench)
(all percpu_counters hit this bug too)

Long term fix (ie >= 2.6.26) would be to let each CPU allocate their own block of memory, so that we dont need to roudup sizes to L1_CACHE_BYTES, or merging the SGI stuff of course...

Note : SLUB vs SLAB is important here to *show* the improvement, since they dont have the same minimum allocation sizes (8 bytes vs 32 bytes). This could very well explain regressions some guys reported when they switched to SLUB.

---
 mm/allocpercpu.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

This is appropriate for 2.6.24.y

mm/allocpercpu.c +14 -1
@@ -6,6 +6,10 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 
+#ifndef cache_line_size
+#define cache_line_size()	L1_CACHE_BYTES
+#endif
+
 /**
  * percpu_depopulate - depopulate per-cpu data for given cpu
  * @__pdata: per-cpu data to depopulate
@@ -52,6 +56,11 @@ void *percpu_populate(void *__pdata, siz
 	struct percpu_data *pdata = __percpu_disguise(__pdata);
 	int node = cpu_to_node(cpu);
 
+	/*
+	 * We should make sure each CPU gets private memory.
+	 */
+	size = roundup(size, cache_line_size());
+
 	BUG_ON(pdata->ptrs[cpu]);
 	if (node_online(node))
 		pdata->ptrs[cpu] = kmalloc_node(size, gfp|__GFP_ZERO, node);
@@ -98,7 +107,11 @@ EXPORT_SYMBOL_GPL(__percpu_populate_mask
  */
 void *__percpu_alloc_mask(size_t size, gfp_t gfp, cpumask_t *mask)
 {
-	void *pdata = kzalloc(nr_cpu_ids * sizeof(void *), gfp);
+	/*
+	 * We allocate whole cache lines to avoid false sharing
+	 */
+	size_t sz = roundup(nr_cpu_ids * sizeof(void *), cache_line_size());
+	void *pdata = kzalloc(sz, gfp);
 	void *__pdata = __percpu_disguise(pdata);
 
 	if (unlikely(!pdata))
#31 lore raw

hwmon: (w83781d) Fix I/O resource conflict with PNP

In reply to Chris Wright

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

From: Jean Delvare <[email protected]>

upstream commit: 2961cb22ef02850d90e7a12c28a14d74e327df8d

Only request I/O ports 0x295-0x296 instead of the full I/O address range. This solves a conflict with PNP resources on a few motherboards.

Also request the I/O ports in two parts (4 low ports, 4 high ports) during device detection, otherwise the PNP resource makes the request (and thus the detection) fail.

This fixes lm-sensors ticket #2306:
http://www.lm-sensors.org/ticket/2306

---
 drivers/hwmon/w83781d.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)
drivers/hwmon/w83781d.c +16 -5
@@ -1380,7 +1380,8 @@ w83781d_isa_probe(struct platform_device
 
 	/* Reserve the ISA region */
 	res = platform_get_resource(pdev, IORESOURCE_IO, 0);
-	if (!request_region(res->start, W83781D_EXTENT, "w83781d")) {
+	if (!request_region(res->start + W83781D_ADDR_REG_OFFSET, 2,
+			    "w83781d")) {
 		err = -EBUSY;
 		goto exit;
 	}
@@ -1432,7 +1433,7 @@ w83781d_isa_probe(struct platform_device
 	device_remove_file(&pdev->dev, &dev_attr_name);
 	kfree(data);
  exit_release_region:
-	release_region(res->start, W83781D_EXTENT);
+	release_region(res->start + W83781D_ADDR_REG_OFFSET, 2);
  exit:
 	return err;
 }
@@ -1446,7 +1447,7 @@ w83781d_isa_remove(struct platform_devic
 	sysfs_remove_group(&pdev->dev.kobj, &w83781d_group);
 	sysfs_remove_group(&pdev->dev.kobj, &w83781d_group_opt);
 	device_remove_file(&pdev->dev, &dev_attr_name);
-	release_region(data->client.addr, W83781D_EXTENT);
+	release_region(data->client.addr + W83781D_ADDR_REG_OFFSET, 2);
 	kfree(data);
 
 	return 0;
@@ -1820,8 +1821,17 @@ w83781d_isa_found(unsigned short address
 {
 	int val, save, found = 0;
 
-	if (!request_region(address, W83781D_EXTENT, "w83781d"))
+	/* We have to request the region in two parts because some
+	   boards declare base+4 to base+7 as a PNP device */
+	if (!request_region(address, 4, "w83781d")) {
+		pr_debug("w83781d: Failed to request low part of region\n");
 		return 0;
+	}
+	if (!request_region(address + 4, 4, "w83781d")) {
+		pr_debug("w83781d: Failed to request high part of region\n");
+		release_region(address, 4);
+		return 0;
+	}
 
 #define REALLY_SLOW_IO
 	/* We need the timeouts for at least some W83781D-like
@@ -1896,7 +1906,8 @@ w83781d_isa_found(unsigned short address
 			val == 0x30 ? "W83782D" : "W83781D", (int)address);
 
  release:
-	release_region(address, W83781D_EXTENT);
+	release_region(address + 4, 4);
+	release_region(address, 4);
 	return found;
 }
 
#32 lore raw

POWERPC: Fix build of modular drivers/macintosh/apm_emu.c

In reply to Chris Wright

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

From: Guido Guenther <[email protected]>

upstream commit: 620a245978d007279bc5c7c64e15f5f63af9af98

Currently, if drivers/macintosh/apm_emu is a module and the config doesn't have CONFIG_SUSPEND we get:

ERROR: "pmu_batteries" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: "pmu_battery_count" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: "pmu_power_flags" [drivers/macintosh/apm_emu.ko] undefined!

on PPC32. The variables aren't wrapped in '#if defined(CONFIG_SUSPEND)' so we probably shouldn't wrap the exports either. This removes the CONFIG_SUSPEND part of the export, which fixes compilation on ppc32.

[email protected] notes:

The details can be found at http://bugs.gentoo.org/show_bug.cgi?id=217629.

---
 drivers/macintosh/via-pmu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/macintosh/via-pmu.c +1 -1
@@ -2842,7 +2842,7 @@ EXPORT_SYMBOL(pmu_wait_complete);
 EXPORT_SYMBOL(pmu_suspend);
 EXPORT_SYMBOL(pmu_resume);
 EXPORT_SYMBOL(pmu_unlock);
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_PPC32)
 EXPORT_SYMBOL(pmu_enable_irled);
 EXPORT_SYMBOL(pmu_battery_count);
 EXPORT_SYMBOL(pmu_batteries);
#33 lore raw

USB: Allow initialization of broken keyspan serial adapters.

In reply to Chris Wright

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

From: Clark Rawlins <[email protected]>

upstream commit: 822470537d0fc1dee38a2a9c8b8c398bfbb332bb

Fixes the keyspan driver after the addition of additional checking of driver requirements introduced in usb-serial.c commit 063a2da8f01806906f7d7b1a1424b9afddebc443. The initialization of the keyspan usb_serial_driver structs were not initializing the num_interrupt_out field and the additional checking was rejecting the end point so the driver wouldn't finish initializing.

This commit initializes the fields to NUM_DONT_CARE. It works for the keyspan USA-49WG and doesn't break the USA-19HS which are the two keyspan devices I have to test with.

---
 drivers/usb/serial/keyspan.h |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/serial/keyspan.h +4 -0
@@ -637,6 +637,7 @@ static struct usb_serial_driver keyspan_
 	.description		= "Keyspan - (without firmware)",
 	.id_table		= keyspan_pre_ids,
 	.num_interrupt_in	= NUM_DONT_CARE,
+	.num_interrupt_out	= NUM_DONT_CARE,
 	.num_bulk_in		= NUM_DONT_CARE,
 	.num_bulk_out		= NUM_DONT_CARE,
 	.num_ports		= 1,
@@ -651,6 +652,7 @@ static struct usb_serial_driver keyspan_
 	.description		= "Keyspan 1 port adapter",
 	.id_table		= keyspan_1port_ids,
 	.num_interrupt_in	= NUM_DONT_CARE,
+	.num_interrupt_out	= NUM_DONT_CARE,
 	.num_bulk_in		= NUM_DONT_CARE,
 	.num_bulk_out		= NUM_DONT_CARE,
 	.num_ports		= 1,
@@ -678,6 +680,7 @@ static struct usb_serial_driver keyspan_
 	.description		= "Keyspan 2 port adapter",
 	.id_table		= keyspan_2port_ids,
 	.num_interrupt_in	= NUM_DONT_CARE,
+	.num_interrupt_out	= NUM_DONT_CARE,
 	.num_bulk_in		= NUM_DONT_CARE,
 	.num_bulk_out		= NUM_DONT_CARE,
 	.num_ports		= 2,
@@ -705,6 +708,7 @@ static struct usb_serial_driver keyspan_
 	.description		= "Keyspan 4 port adapter",
 	.id_table		= keyspan_4port_ids,
 	.num_interrupt_in	= NUM_DONT_CARE,
+	.num_interrupt_out	= NUM_DONT_CARE,
 	.num_bulk_in		= NUM_DONT_CARE,
 	.num_bulk_out		= NUM_DONT_CARE,
 	.num_ports		= 4,
#34 lore raw

AX25 ax25_out: check skb for NULL in ax25_kick()

In reply to Chris Wright

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

From: Jarek Poplawski <[email protected]>

Upstream commit: f47b7257c7368698eabff6fd7b340071932af640

According to some OOPS reports ax25_kick tries to clone NULL skbs sometimes. It looks like a race with ax25_clear_queues(). Probably there is no need to add more than a simple check for this yet. Another report suggested there are probably also cases where ax25 ->paclen == 0 can happen in ax25_output(); this wasn't confirmed during testing but let's leave this debugging check for some time.

---
 net/ax25/ax25_out.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
net/ax25/ax25_out.c +11 -2
@@ -117,6 +117,12 @@ void ax25_output(ax25_cb *ax25, int pacl
 	unsigned char *p;
 	int frontlen, len, fragno, ka9qfrag, first = 1;
 
+	if (paclen < 16) {
+		WARN_ON_ONCE(1);
+		kfree_skb(skb);
+		return;
+	}
+
 	if ((skb->len - 1) > paclen) {
 		if (*skb->data == AX25_P_TEXT) {
 			skb_pull(skb, 1); /* skip PID */
@@ -251,8 +257,6 @@ void ax25_kick(ax25_cb *ax25)
 	if (start == end)
 		return;
 
-	ax25->vs = start;
-
 	/*
 	 * Transmit data until either we're out of data to send or
 	 * the window is full. Send a poll on the final I frame if
@@ -261,8 +265,13 @@ void ax25_kick(ax25_cb *ax25)
 
 	/*
 	 * Dequeue the frame and copy it.
+	 * Check for race with ax25_clear_queues().
 	 */
 	skb  = skb_dequeue(&ax25->write_queue);
+	if (!skb)
+		return;
+
+	ax25->vs = start;
 
 	do {
 		if ((skbn = skb_clone(skb, GFP_ATOMIC)) == NULL) {
#35 lore raw

SPARC64: Fix atomic backoff limit.

In reply to Chris Wright

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

From: David S. Miller <[email protected]>

Upstream commit: 4cfea5a7dfcc2766251e50ca30271a782d5004ad

4096 will not fit into the immediate field of a compare instruction, in fact it will end up being -4096 causing the check to fail every time and thus disabling backoff.

---
 include/asm-sparc64/backoff.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/asm-sparc64/backoff.h +2 -1
@@ -12,7 +12,8 @@
 	mov	reg, tmp; \
 88:	brnz,pt	tmp, 88b; \
 	 sub	tmp, 1, tmp; \
-	cmp	reg, BACKOFF_LIMIT; \
+	set	BACKOFF_LIMIT, tmp; \
+	cmp	reg, tmp; \
 	bg,pn	%xcc, label; \
 	 nop; \
 	ba,pt	%xcc, label; \
#36 lore raw

SCTP: Fix local_addr deletions during list traversals.

In reply to Chris Wright

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

From: Chidambar 'ilLogict' Zinnoury <[email protected]>

Upstream commit: 22626216c46f2ec86287e75ea86dd9ac3df54265

Since the lists are circular, we need to explicitely tag the address to be deleted since we might end up freeing the list head instead. This fixes some interesting SCTP crashes.

---
 net/sctp/bind_addr.c |    4 +++-
 net/sctp/ipv6.c      |    4 +++-
 net/sctp/protocol.c  |    4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)
net/sctp/bind_addr.c +3 -1
@@ -209,6 +209,7 @@ int sctp_add_bind_addr(struct sctp_bind_
 int sctp_del_bind_addr(struct sctp_bind_addr *bp, union sctp_addr *del_addr)
 {
 	struct sctp_sockaddr_entry *addr, *temp;
+	int found = 0;
 
 	/* We hold the socket lock when calling this function,
 	 * and that acts as a writer synchronizing lock.
@@ -216,13 +217,14 @@ int sctp_del_bind_addr(struct sctp_bind_
 	list_for_each_entry_safe(addr, temp, &bp->address_list, list) {
 		if (sctp_cmp_addr_exact(&addr->a, del_addr)) {
 			/* Found the exact match. */
+			found = 1;
 			addr->valid = 0;
 			list_del_rcu(&addr->list);
 			break;
 		}
 	}
 
-	if (addr && !addr->valid) {
+	if (found) {
 		call_rcu(&addr->rcu, sctp_local_addr_free);
 		SCTP_DBG_OBJCNT_DEC(addr);
 		return 0;
net/sctp/ipv6.c +3 -1
@@ -89,6 +89,7 @@ static int sctp_inet6addr_event(struct n
 	struct inet6_ifaddr *ifa = (struct inet6_ifaddr *)ptr;
 	struct sctp_sockaddr_entry *addr = NULL;
 	struct sctp_sockaddr_entry *temp;
+	int found = 0;
 
 	switch (ev) {
 	case NETDEV_UP:
@@ -111,13 +112,14 @@ static int sctp_inet6addr_event(struct n
 					&sctp_local_addr_list, list) {
 			if (ipv6_addr_equal(&addr->a.v6.sin6_addr,
 					     &ifa->addr)) {
+				found = 1;
 				addr->valid = 0;
 				list_del_rcu(&addr->list);
 				break;
 			}
 		}
 		spin_unlock_bh(&sctp_local_addr_lock);
-		if (addr && !addr->valid)
+		if (found)
 			call_rcu(&addr->rcu, sctp_local_addr_free);
 		break;
 	}
net/sctp/protocol.c +3 -1
@@ -626,6 +626,7 @@ static int sctp_inetaddr_event(struct no
 	struct in_ifaddr *ifa = (struct in_ifaddr *)ptr;
 	struct sctp_sockaddr_entry *addr = NULL;
 	struct sctp_sockaddr_entry *temp;
+	int found = 0;
 
 	switch (ev) {
 	case NETDEV_UP:
@@ -645,13 +646,14 @@ static int sctp_inetaddr_event(struct no
 		list_for_each_entry_safe(addr, temp,
 					&sctp_local_addr_list, list) {
 			if (addr->a.v4.sin_addr.s_addr == ifa->ifa_local) {
+				found = 1;
 				addr->valid = 0;
 				list_del_rcu(&addr->list);
 				break;
 			}
 		}
 		spin_unlock_bh(&sctp_local_addr_lock);
-		if (addr && !addr->valid)
+		if (found)
 			call_rcu(&addr->rcu, sctp_local_addr_free);
 		break;
 	}
#37 lore raw

libata: assume no device is attached if both IDENTIFYs are aborted

In reply to Chris Wright

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

From: Tejun Heo <[email protected]>

upstream commit: 1ffc151fcddf524d0c76709d7e7a2af0255acb6b

This is to fix bugzilla #10254. QSI cdrom attached to pata_sis as secondary master appears as phantom device for the slave. Interestingly, instead of not setting DRQ after IDENTIFY which triggers NODEV_HINT, it aborts both IDENTIFY and IDENTIFY PACKET which makes EH retry.

Modify EH such that it assumes no device is attached if both flavors of IDENTIFY are aborted by the device. There really isn't much point in retrying when the device actively aborts the commands.

While at it, convert NODEV detection message to ata_dev_printk() to help debugging obscure detection problems.

This problem was reported by Jan Bücken.

[email protected] notes:

This patch fixes http://bugs.gentoo.org/211369

---
 drivers/ata/libata-core.c |   38 ++++++++++++++++++++++++--------------
 1 file changed, 24 insertions(+), 14 deletions(-)
drivers/ata/libata-core.c +24 -14
@@ -1936,24 +1936,34 @@ int ata_dev_read_id(struct ata_device *d
 				     id, sizeof(id[0]) * ATA_ID_WORDS, 0);
 	if (err_mask) {
 		if (err_mask & AC_ERR_NODEV_HINT) {
-			DPRINTK("ata%u.%d: NODEV after polling detection\n",
-				ap->print_id, dev->devno);
+			ata_dev_printk(dev, KERN_DEBUG,
+				       "NODEV after polling detection\n");
 			return -ENOENT;
 		}
 
-		/* Device or controller might have reported the wrong
-		 * device class.  Give a shot at the other IDENTIFY if
-		 * the current one is aborted by the device.
-		 */
-		if (may_fallback &&
-		    (err_mask == AC_ERR_DEV) && (tf.feature & ATA_ABORTED)) {
-			may_fallback = 0;
+		if ((err_mask == AC_ERR_DEV) && (tf.feature & ATA_ABORTED)) {
+			/* Device or controller might have reported
+			 * the wrong device class.  Give a shot at the
+			 * other IDENTIFY if the current one is
+			 * aborted by the device.
+			 */
+			if (may_fallback) {
+				may_fallback = 0;
 
-			if (class == ATA_DEV_ATA)
-				class = ATA_DEV_ATAPI;
-			else
-				class = ATA_DEV_ATA;
-			goto retry;
+				if (class == ATA_DEV_ATA)
+					class = ATA_DEV_ATAPI;
+				else
+					class = ATA_DEV_ATA;
+				goto retry;
+			}
+
+			/* Control reaches here iff the device aborted
+			 * both flavors of IDENTIFYs which happens
+			 * sometimes with phantom devices.
+			 */
+			ata_dev_printk(dev, KERN_DEBUG,
+				       "both IDENTIFYs aborted, assuming NODEV\n");
+			return -ENOENT;
 		}
 
 		rc = -EIO;
#38 lore raw

VLAN: Dont copy ALLMULTI/PROMISC flags from underlying device

In reply to Chris Wright

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

From: Patrick McHardy <[email protected]>

Upstream commit: 0ed21b321a13421e2dfeaa70a6c324e05e3e91e6

Changing these flags requires to use dev_set_allmulti/dev_set_promiscuity or dev_change_flags. Setting it directly causes two unwanted effects:

- the next dev_change_flags call will notice a difference between dev->gflags and the actual flags, enable promisc/allmulti mode and incorrectly update dev->gflags

- this keeps the underlying device in promisc/allmulti mode until the VLAN device is deleted

[ Ported back to 2.6.24 VLAN code. -DaveM ]

---
 net/8021q/vlan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/8021q/vlan.c +1 -1
@@ -326,7 +326,7 @@ static int vlan_dev_init(struct net_devi
 	int subclass = 0;
 
 	/* IFF_BROADCAST|IFF_MULTICAST; ??? */
-	dev->flags  = real_dev->flags & ~IFF_UP;
+	dev->flags  = real_dev->flags & ~(IFF_UP | IFF_PROMISC | IFF_ALLMULTI);
 	dev->iflink = real_dev->ifindex;
 	dev->state  = (real_dev->state & ((1<<__LINK_STATE_NOCARRIER) |
 					  (1<<__LINK_STATE_DORMANT))) |
#39 lore raw

DVB: tda10086: make the 22kHz tone for DISEQC a config option

In reply to Chris Wright

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

From: Hartmut Hackmann <[email protected]>

(backported from commit ea75baf4b0f117564bd50827a49c4b14d61d24e9)

Some cards need the diseqc signal modulated, while some just need the envelope to control the LNB supply.

This fixes Bug 9887

---
 drivers/media/dvb/dvb-usb/ttusb2.c        |    1 +
 drivers/media/dvb/frontends/tda10086.c    |   28 ++++++++++++++++++++++------
 drivers/media/dvb/frontends/tda10086.h    |    3 +++
 drivers/media/dvb/ttpci/budget.c          |    1 +
 drivers/media/video/saa7134/saa7134-dvb.c |    1 +
 5 files changed, 28 insertions(+), 6 deletions(-)
drivers/media/dvb/dvb-usb/ttusb2.c +1 -0
@@ -144,6 +144,7 @@ static int ttusb2_power_ctrl(struct dvb_
 static struct tda10086_config tda10086_config = {
 	.demod_address = 0x0e,
 	.invert = 0,
+	.diseqc_tone = 1,
 };
 
 static int ttusb2_frontend_attach(struct dvb_usb_adapter *adap)
drivers/media/dvb/frontends/tda10086.c +22 -6
@@ -106,9 +106,12 @@ static int tda10086_write_mask(struct td
 static int tda10086_init(struct dvb_frontend* fe)
 {
 	struct tda10086_state* state = fe->demodulator_priv;
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
 	// reset
 	tda10086_write_byte(state, 0x00, 0x00);
 	msleep(10);
@@ -158,7 +161,7 @@ static int tda10086_init(struct dvb_fron
 	tda10086_write_byte(state, 0x3d, 0x80);
 
 	// setup SEC
-	tda10086_write_byte(state, 0x36, 0x80); // all SEC off, no 22k tone
+	tda10086_write_byte(state, 0x36, t22k_off); // all SEC off, 22k tone
 	tda10086_write_byte(state, 0x34, (((1<<19) * (22000/1000)) / (SACLK/1000)));      // } tone frequency
 	tda10086_write_byte(state, 0x35, (((1<<19) * (22000/1000)) / (SACLK/1000)) >> 8); // }
 
@@ -180,16 +183,20 @@ static void tda10086_diseqc_wait(struct 
 static int tda10086_set_tone (struct dvb_frontend* fe, fe_sec_tone_mode_t tone)
 {
 	struct tda10086_state* state = fe->demodulator_priv;
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
+
 	switch (tone) {
 	case SEC_TONE_OFF:
-		tda10086_write_byte(state, 0x36, 0x80);
+		tda10086_write_byte(state, 0x36, t22k_off);
 		break;
 
 	case SEC_TONE_ON:
-		tda10086_write_byte(state, 0x36, 0x81);
+		tda10086_write_byte(state, 0x36, 0x01 + t22k_off);
 		break;
 	}
 
@@ -202,9 +209,13 @@ static int tda10086_send_master_cmd (str
 	struct tda10086_state* state = fe->demodulator_priv;
 	int i;
 	u8 oldval;
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
+
 	if (cmd->msg_len > 6)
 		return -EINVAL;
 	oldval = tda10086_read_byte(state, 0x36);
@@ -212,7 +223,8 @@ static int tda10086_send_master_cmd (str
 	for(i=0; i< cmd->msg_len; i++) {
 		tda10086_write_byte(state, 0x48+i, cmd->msg[i]);
 	}
-	tda10086_write_byte(state, 0x36, 0x88 | ((cmd->msg_len - 1) << 4));
+	tda10086_write_byte(state, 0x36, (0x08 + t22k_off)
+					| ((cmd->msg_len - 1) << 4));
 
 	tda10086_diseqc_wait(state);
 
@@ -225,16 +237,20 @@ static int tda10086_send_burst (struct d
 {
 	struct tda10086_state* state = fe->demodulator_priv;
 	u8 oldval = tda10086_read_byte(state, 0x36);
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
+
 	switch(minicmd) {
 	case SEC_MINI_A:
-		tda10086_write_byte(state, 0x36, 0x84);
+		tda10086_write_byte(state, 0x36, 0x04 + t22k_off);
 		break;
 
 	case SEC_MINI_B:
-		tda10086_write_byte(state, 0x36, 0x86);
+		tda10086_write_byte(state, 0x36, 0x06 + t22k_off);
 		break;
 	}
 
drivers/media/dvb/frontends/tda10086.h +3 -0
@@ -33,6 +33,9 @@ struct tda10086_config
 
 	/* does the "inversion" need inverted? */
 	u8 invert;
+
+	/* do we need the diseqc signal with carrier? */
+	u8 diseqc_tone;
 };
 
 #if defined(CONFIG_DVB_TDA10086) || (defined(CONFIG_DVB_TDA10086_MODULE) && defined(MODULE))
drivers/media/dvb/ttpci/budget.c +1 -0
@@ -351,6 +351,7 @@ static struct s5h1420_config s5h1420_con
 static struct tda10086_config tda10086_config = {
 	.demod_address = 0x0e,
 	.invert = 0,
+	.diseqc_tone = 1,
 };
 
 static u8 read_pwm(struct budget* budget)
drivers/media/video/saa7134/saa7134-dvb.c +1 -0
@@ -826,6 +826,7 @@ static struct tda1004x_config ads_tech_d
 static struct tda10086_config flydvbs = {
 	.demod_address = 0x0e,
 	.invert = 0,
+	.diseqc_tone = 0,
 };
 
 /* ==================================================================
#40 lore raw

SPARC64: Fix __get_cpu_var in preemption-enabled area.

In reply to Chris Wright

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

From: David S. Miller <[email protected]>

Upstream commit: 69072f6e8e4bd4799d2a54e4ff8771d0657512c1

Reported by Mariusz Kozlowski.

---
 arch/sparc64/mm/tlb.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/sparc64/mm/tlb.c +2 -1
@@ -23,10 +23,11 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_ga
 
 void flush_tlb_pending(void)
 {
-	struct mmu_gather *mp = &__get_cpu_var(mmu_gathers);
+	struct mmu_gather *mp;
 
 	preempt_disable();
 
+	mp = &__get_cpu_var(mmu_gathers);
 	if (mp->tlb_nr) {
 		flush_tsb_user(mp);
 
#41 lore raw

SPARC64: flush_ptrace_access() needs preemption disable.

In reply to Chris Wright

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

From: David S. Miller <[email protected]>

Upstream commit: f6a843d939ade435e060d580f5c56d958464f8a5

Based upon a report by Mariusz Kozlowski.

---
 arch/sparc64/kernel/ptrace.c |    4 ++++
 1 file changed, 4 insertions(+)
arch/sparc64/kernel/ptrace.c +4 -0
@@ -127,6 +127,8 @@ void flush_ptrace_access(struct vm_area_
 	if (tlb_type == hypervisor)
 		return;
 
+	preempt_disable();
+
 #ifdef DCACHE_ALIASING_POSSIBLE
 	/* If bit 13 of the kernel address we used to access the
 	 * user page is the same as the virtual address that page
@@ -165,6 +167,8 @@ void flush_ptrace_access(struct vm_area_
 		for (; start < end; start += icache_line_size)
 			flushi(start);
 	}
+
+	preempt_enable();
 }
 
 asmlinkage void do_ptrace(struct pt_regs *regs)
#42 lore raw

NET: include <linux/types.h> into linux/ethtool.h for __u* typedef

In reply to Chris Wright

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

From: Kirill A. Shutemov <[email protected]>

Upstream commit: e621e69137b24fdbbe7ad28214e8d81e614c25b7

---
 include/linux/ethtool.h |    1 +
 1 file changed, 1 insertion(+)
include/linux/ethtool.h +1 -0
@@ -12,6 +12,7 @@
 #ifndef _LINUX_ETHTOOL_H
 #define _LINUX_ETHTOOL_H
 
+#include <linux/types.h>
 
 /* This should work for both 32 and 64 bit userland. */
 struct ethtool_cmd {
#43 lore raw

INET: inet_frag_evictor() must run with BH disabled

In reply to Chris Wright

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

From: David S. Miller <[email protected]>

Part of upstream commit: e8e16b706e8406f1ab3bccab16932ebc513896d8

Based upon a lockdep trace from Dave Jones.

---
 net/ipv6/netfilter/nf_conntrack_reasm.c |    2 ++
 1 file changed, 2 insertions(+)
net/ipv6/netfilter/nf_conntrack_reasm.c +2 -0
@@ -147,7 +147,9 @@ static __inline__ void fq_kill(struct nf
 
 static void nf_ct_frag6_evictor(void)
 {
+	local_bh_disable();
 	inet_frag_evictor(&nf_frags);
+	local_bh_enable();
 }
 
 static void nf_ct_frag6_expire(unsigned long data)
#44 lore raw

PPPOL2TP: Make locking calls softirq-safe

In reply to Chris Wright

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

From: James Chapman <[email protected]>

Upstream commit: cf3752e2d203bbbfc88d29e362e6938cef4339b3

Fix locking issues in the pppol2tp driver which can cause a kernel crash on SMP boxes. There were two problems:-

1. The driver was violating read_lock() and write_lock() scheduling rules because it wasn't using softirq-safe locks in softirq contexts. So we now consistently use the _bh variants of the lock functions.

2. The driver was calling sk_dst_get() in pppol2tp_xmit() which was taking sk_dst_lock in softirq context. We now call __sk_dst_get().

---
 drivers/net/pppol2tp.c |   58 ++++++++++++++++++++++++------------------------
 1 files changed, 29 insertions(+), 29 deletions(-)
drivers/net/pppol2tp.c +29 -29
index a7556cd..ff4a94b 100644
@@ -302,14 +302,14 @@ pppol2tp_session_find(struct pppol2tp_tunnel *tunnel, u16 session_id)
 	struct pppol2tp_session *session;
 	struct hlist_node *walk;
 
-	read_lock(&tunnel->hlist_lock);
+	read_lock_bh(&tunnel->hlist_lock);
 	hlist_for_each_entry(session, walk, session_list, hlist) {
 		if (session->tunnel_addr.s_session == session_id) {
-			read_unlock(&tunnel->hlist_lock);
+			read_unlock_bh(&tunnel->hlist_lock);
 			return session;
 		}
 	}
-	read_unlock(&tunnel->hlist_lock);
+	read_unlock_bh(&tunnel->hlist_lock);
 
 	return NULL;
 }
@@ -320,14 +320,14 @@ static struct pppol2tp_tunnel *pppol2tp_tunnel_find(u16 tunnel_id)
 {
 	struct pppol2tp_tunnel *tunnel = NULL;
 
-	read_lock(&pppol2tp_tunnel_list_lock);
+	read_lock_bh(&pppol2tp_tunnel_list_lock);
 	list_for_each_entry(tunnel, &pppol2tp_tunnel_list, list) {
 		if (tunnel->stats.tunnel_id == tunnel_id) {
-			read_unlock(&pppol2tp_tunnel_list_lock);
+			read_unlock_bh(&pppol2tp_tunnel_list_lock);
 			return tunnel;
 		}
 	}
-	read_unlock(&pppol2tp_tunnel_list_lock);
+	read_unlock_bh(&pppol2tp_tunnel_list_lock);
 
 	return NULL;
 }
@@ -344,7 +344,7 @@ static void pppol2tp_recv_queue_skb(struct pppol2tp_session *session, struct sk_
 	struct sk_buff *skbp;
 	u16 ns = PPPOL2TP_SKB_CB(skb)->ns;
 
-	spin_lock(&session->reorder_q.lock);
+	spin_lock_bh(&session->reorder_q.lock);
 	skb_queue_walk(&session->reorder_q, skbp) {
 		if (PPPOL2TP_SKB_CB(skbp)->ns > ns) {
 			__skb_insert(skb, skbp->prev, skbp, &session->reorder_q);
@@ -360,7 +360,7 @@ static void pppol2tp_recv_queue_skb(struct pppol2tp_session *session, struct sk_
 	__skb_queue_tail(&session->reorder_q, skb);
 
 out:
-	spin_unlock(&session->reorder_q.lock);
+	spin_unlock_bh(&session->reorder_q.lock);
 }
 
 /* Dequeue a single skb.
@@ -442,7 +442,7 @@ static void pppol2tp_recv_dequeue(struct pppol2tp_session *session)
 	 * expect to send up next, dequeue it and any other
 	 * in-sequence packets behind it.
 	 */
-	spin_lock(&session->reorder_q.lock);
+	spin_lock_bh(&session->reorder_q.lock);
 	skb_queue_walk_safe(&session->reorder_q, skb, tmp) {
 		if (time_after(jiffies, PPPOL2TP_SKB_CB(skb)->expires)) {
 			session->stats.rx_seq_discards++;
@@ -469,13 +469,13 @@ static void pppol2tp_recv_dequeue(struct pppol2tp_session *session)
 				goto out;
 			}
 		}
-		spin_unlock(&session->reorder_q.lock);
+		spin_unlock_bh(&session->reorder_q.lock);
 		pppol2tp_recv_dequeue_skb(session, skb);
-		spin_lock(&session->reorder_q.lock);
+		spin_lock_bh(&session->reorder_q.lock);
 	}
 
 out:
-	spin_unlock(&session->reorder_q.lock);
+	spin_unlock_bh(&session->reorder_q.lock);
 }
 
 /* Internal receive frame. Do the real work of receiving an L2TP data frame
@@ -1058,7 +1058,7 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
 
 	/* Get routing info from the tunnel socket */
 	dst_release(skb->dst);
-	skb->dst = sk_dst_get(sk_tun);
+	skb->dst = dst_clone(__sk_dst_get(sk_tun));
 	skb_orphan(skb);
 	skb->sk = sk_tun;
 
@@ -1106,7 +1106,7 @@ static void pppol2tp_tunnel_closeall(struct pppol2tp_tunnel *tunnel)
 	PRINTK(tunnel->debug, PPPOL2TP_MSG_CONTROL, KERN_INFO,
 	       "%s: closing all sessions...\n", tunnel->name);
 
-	write_lock(&tunnel->hlist_lock);
+	write_lock_bh(&tunnel->hlist_lock);
 	for (hash = 0; hash < PPPOL2TP_HASH_SIZE; hash++) {
 again:
 		hlist_for_each_safe(walk, tmp, &tunnel->session_hlist[hash]) {
@@ -1126,7 +1126,7 @@ again:
 			 * disappear as we're jumping between locks.
 			 */
 			sock_hold(sk);
-			write_unlock(&tunnel->hlist_lock);
+			write_unlock_bh(&tunnel->hlist_lock);
 			lock_sock(sk);
 
 			if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
@@ -1148,11 +1148,11 @@ again:
 			 * list so we are guaranteed to make forward
 			 * progress.
 			 */
-			write_lock(&tunnel->hlist_lock);
+			write_lock_bh(&tunnel->hlist_lock);
 			goto again;
 		}
 	}
-	write_unlock(&tunnel->hlist_lock);
+	write_unlock_bh(&tunnel->hlist_lock);
 }
 
 /* Really kill the tunnel.
@@ -1161,9 +1161,9 @@ again:
 static void pppol2tp_tunnel_free(struct pppol2tp_tunnel *tunnel)
 {
 	/* Remove from socket list */
-	write_lock(&pppol2tp_tunnel_list_lock);
+	write_lock_bh(&pppol2tp_tunnel_list_lock);
 	list_del_init(&tunnel->list);
-	write_unlock(&pppol2tp_tunnel_list_lock);
+	write_unlock_bh(&pppol2tp_tunnel_list_lock);
 
 	atomic_dec(&pppol2tp_tunnel_count);
 	kfree(tunnel);
@@ -1239,9 +1239,9 @@ static void pppol2tp_session_destruct(struct sock *sk)
 				/* Delete the session socket from the
 				 * hash
 				 */
-				write_lock(&tunnel->hlist_lock);
+				write_lock_bh(&tunnel->hlist_lock);
 				hlist_del_init(&session->hlist);
-				write_unlock(&tunnel->hlist_lock);
+				write_unlock_bh(&tunnel->hlist_lock);
 
 				atomic_dec(&pppol2tp_session_count);
 			}
@@ -1386,9 +1386,9 @@ static struct sock *pppol2tp_prepare_tunnel_socket(int fd, u16 tunnel_id,
 
 	/* Add tunnel to our list */
 	INIT_LIST_HEAD(&tunnel->list);
-	write_lock(&pppol2tp_tunnel_list_lock);
+	write_lock_bh(&pppol2tp_tunnel_list_lock);
 	list_add(&tunnel->list, &pppol2tp_tunnel_list);
-	write_unlock(&pppol2tp_tunnel_list_lock);
+	write_unlock_bh(&pppol2tp_tunnel_list_lock);
 	atomic_inc(&pppol2tp_tunnel_count);
 
 	/* Bump the reference count. The tunnel context is deleted
@@ -1593,11 +1593,11 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr,
 	sk->sk_user_data = session;
 
 	/* Add session to the tunnel's hash list */
-	write_lock(&tunnel->hlist_lock);
+	write_lock_bh(&tunnel->hlist_lock);
 	hlist_add_head(&session->hlist,
 		       pppol2tp_session_id_hash(tunnel,
 						session->tunnel_addr.s_session));
-	write_unlock(&tunnel->hlist_lock);
+	write_unlock_bh(&tunnel->hlist_lock);
 
 	atomic_inc(&pppol2tp_session_count);
 
@@ -2199,7 +2199,7 @@ static struct pppol2tp_session *next_session(struct pppol2tp_tunnel *tunnel, str
 	int next = 0;
 	int i;
 
-	read_lock(&tunnel->hlist_lock);
+	read_lock_bh(&tunnel->hlist_lock);
 	for (i = 0; i < PPPOL2TP_HASH_SIZE; i++) {
 		hlist_for_each_entry(session, walk, &tunnel->session_hlist[i], hlist) {
 			if (curr == NULL) {
@@ -2217,7 +2217,7 @@ static struct pppol2tp_session *next_session(struct pppol2tp_tunnel *tunnel, str
 		}
 	}
 out:
-	read_unlock(&tunnel->hlist_lock);
+	read_unlock_bh(&tunnel->hlist_lock);
 	if (!found)
 		session = NULL;
 
@@ -2228,13 +2228,13 @@ static struct pppol2tp_tunnel *next_tunnel(struct pppol2tp_tunnel *curr)
 {
 	struct pppol2tp_tunnel *tunnel = NULL;
 
-	read_lock(&pppol2tp_tunnel_list_lock);
+	read_lock_bh(&pppol2tp_tunnel_list_lock);
 	if (list_is_last(&curr->list, &pppol2tp_tunnel_list)) {
 		goto out;
 	}
 	tunnel = list_entry(curr->list.next, struct pppol2tp_tunnel, list);
 out:
-	read_unlock(&pppol2tp_tunnel_list_lock);
+	read_unlock_bh(&pppol2tp_tunnel_list_lock);
 
 	return tunnel;
 }
#45 lore raw

PERCPU : __percpu_alloc_mask() can dynamically size percpu_data storage

In reply to Chris Wright

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

From: Eric Dumazet <[email protected]>

upstream commit: b3242151906372f30f57feaa43b4cac96a23edb1

Instead of allocating a fix sized array of NR_CPUS pointers for percpu_data, we can use nr_cpu_ids, which is generally < NR_CPUS.

---
 include/linux/percpu.h |    2 +-
 mm/allocpercpu.c       |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

This is appropriate for 2.6.24.y

include/linux/percpu.h +1 -1
@@ -34,7 +34,7 @@
 #ifdef CONFIG_SMP
 
 struct percpu_data {
-	void *ptrs[NR_CPUS];
+	void *ptrs[1];
 };
 
 #define __percpu_disguise(pdata) (struct percpu_data *)~(unsigned long)(pdata)
mm/allocpercpu.c +1 -1
@@ -98,7 +98,7 @@ EXPORT_SYMBOL_GPL(__percpu_populate_mask
  */
 void *__percpu_alloc_mask(size_t size, gfp_t gfp, cpumask_t *mask)
 {
-	void *pdata = kzalloc(sizeof(struct percpu_data), gfp);
+	void *pdata = kzalloc(nr_cpu_ids * sizeof(void *), gfp);
 	void *__pdata = __percpu_disguise(pdata);
 
 	if (unlikely(!pdata))
#46 lore raw

bluetooth: hci_core: defer hci_unregister_sysfs()

In reply to Chris Wright

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

From: Dave Young <[email protected]>

upstream commit: 147e2d59833e994cc99341806a88b9e59be41391

Alon Bar-Lev reports:

 Feb 16 23:41:33 alon1 usb 3-1: configuration #1 chosen from 1 choice
Feb 16 23:41:33 alon1 BUG: unable to handle kernel NULL pointer
dereference at virtual address 00000008
Feb 16 23:41:33 alon1 printing eip: c01b2db6 *pde = 00000000
Feb 16 23:41:33 alon1 Oops: 0000 [#1] PREEMPT
Feb 16 23:41:33 alon1 Modules linked in: ppp_deflate zlib_deflate

zlib_inflate bsd_comp ppp_async rfcomm l2cap hci_usb vmnet(P) vmmon(P) tun radeon drm autofs4 ipv6 aes_generic crypto_algapi ieee80211_crypt_ccmp nf_nat_irc nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT xt_tcpudp ipt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device bluetooth ppp_generic slhc ioatdma dca cfq_iosched cpufreq_powersave cpufreq_ondemand cpufreq_conservative acpi_cpufreq freq_table uinput fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm nsc_ircc snd_timer ipw2200 thinkpad_acpi irda snd ehci_hcd yenta_socket uhci_hcd psmouse ieee80211 soundcore intel_agp hwmon rsrc_nonstatic pcspkr e1000 crc_ccitt snd_page_alloc i2c_i801 ieee80211_crypt pcmcia_core agpgart thermal bat!
tery nvram rtc sr_mod ac sg firmware_class button processor cdrom unix usbcore evdev ext3 jbd ext2 mbcache loop ata_piix libata sd_mod scsi_mod

Feb 16 23:41:33 alon1
Feb 16 23:41:33 alon1 Pid: 4, comm: events/0 Tainted: P
(2.6.24-gentoo-r2 #1)
Feb 16 23:41:33 alon1 EIP: 0060:[<c01b2db6>] EFLAGS: 00010282 CPU: 0
Feb 16 23:41:33 alon1 EIP is at sysfs_get_dentry+0x26/0x80
Feb 16 23:41:33 alon1 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX:
f48a2210
Feb 16 23:41:33 alon1 ESI: f72eb900 EDI: f4803ae0 EBP: f4803ae0 ESP:
f7c49efc
Feb 16 23:41:33 alon1 hcid[7004]: HCI dev 0 registered
Feb 16 23:41:33 alon1 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Feb 16 23:41:33 alon1 Process events/0 (pid: 4, ti=f7c48000
task=f7c3efc0 task.ti=f7c48000)
Feb 16 23:41:33 alon1 Stack: f7cb6140 f4822668 f7e71e10 c01b304d
ffffffff ffffffff fffffffe c030ba9c
Feb 16 23:41:33 alon1 f7cb6140 f4822668 f6da6720 f7cb6140 f4822668
f6da6720 c030ba8e c01ce20b
Feb 16 23:41:33 alon1 f6e9dd00 c030ba8e f6da6720 f6e9dd00 f6e9dd00
00000000 f4822600 00000000
Feb 16 23:41:33 alon1 Call Trace:
Feb 16 23:41:33 alon1 [<c01b304d>] sysfs_move_dir+0x3d/0x1f0
Feb 16 23:41:33 alon1 [<c01ce20b>] kobject_move+0x9b/0x120
Feb 16 23:41:33 alon1 [<c0241711>] device_move+0x51/0x110
Feb 16 23:41:33 alon1 [<f9aaed80>] del_conn+0x0/0x70 [bluetooth]
Feb 16 23:41:33 alon1 [<f9aaed99>] del_conn+0x19/0x70 [bluetooth]
Feb 16 23:41:33 alon1 [<c012c1a1>] run_workqueue+0x81/0x140
Feb 16 23:41:33 alon1 [<c02c0c88>] schedule+0x168/0x2e0
Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50
Feb 16 23:41:33 alon1 [<c012c9cb>] worker_thread+0x9b/0xf0
Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50
Feb 16 23:41:33 alon1 [<c012c930>] worker_thread+0x0/0xf0
Feb 16 23:41:33 alon1 [<c012f962>] kthread+0x42/0x70
Feb 16 23:41:33 alon1 [<c012f920>] kthread+0x0/0x70
Feb 16 23:41:33 alon1 [<c0104c2f>] kernel_thread_helper+0x7/0x18
Feb 16 23:41:33 alon1 =======================
Feb 16 23:41:33 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0
56 53 8b 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74
47 89 fb eb 02 89 c3 <8b> 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98
e7 10 00 8b 43 10
Feb 16 23:41:33 alon1 EIP: [<c01b2db6>] sysfs_get_dentry+0x26/0x80
SS:ESP 0068:f7c49efc
Feb 16 23:41:33 alon1 ---[ end trace aae864e9592acc1d ]---

Defer hci_unregister_sysfs because hci device could be destructed while hci conn devices still there.

[email protected] notes:

This patch fixes http://bugs.gentoo.org/211179

---
 net/bluetooth/hci_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/bluetooth/hci_core.c +2 -2
@@ -901,8 +901,6 @@ int hci_unregister_dev(struct hci_dev *h
 
 	BT_DBG("%p name %s type %d", hdev, hdev->name, hdev->type);
 
-	hci_unregister_sysfs(hdev);
-
 	write_lock_bh(&hci_dev_list_lock);
 	list_del(&hdev->list);
 	write_unlock_bh(&hci_dev_list_lock);
@@ -914,6 +912,8 @@ int hci_unregister_dev(struct hci_dev *h
 
 	hci_notify(hdev, HCI_DEV_UNREG);
 
+	hci_unregister_sysfs(hdev);
+
 	__hci_dev_put(hdev);
 
 	return 0;
#47 lore raw

sch_htb: fix "too many events" situation

In reply to Chris Wright

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

From: Martin Devera <[email protected]>

Upstream commit: 8f3ea33a5078a09eba12bfe57424507809367756

HTB is event driven algorithm and part of its work is to apply scheduled events at proper times. It tried to defend itself from livelock by processing only limited number of events per dequeue. Because of faster computers some users already hit this hardcoded limit.

This patch limits processing up to 2 jiffies (why not 1 jiffie ? because it might stop prematurely when only fraction of jiffie remains).

---
 net/sched/sch_htb.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)
net/sched/sch_htb.c +7 -6
@@ -708,9 +708,11 @@ static void htb_charge_class(struct htb_
  */
 static psched_time_t htb_do_events(struct htb_sched *q, int level)
 {
-	int i;
-
-	for (i = 0; i < 500; i++) {
+	/* don't run for longer than 2 jiffies; 2 is used instead of
+	   1 to simplify things when jiffy is going to be incremented
+	   too soon */
+	unsigned long stop_at = jiffies + 2;
+	while (time_before(jiffies, stop_at)) {
 		struct htb_class *cl;
 		long diff;
 		struct rb_node *p = rb_first(&q->wait_pq[level]);
@@ -728,9 +730,8 @@ static psched_time_t htb_do_events(struc
 		if (cl->cmode != HTB_CAN_SEND)
 			htb_add_to_wait_tree(q, cl, diff);
 	}
-	if (net_ratelimit())
-		printk(KERN_WARNING "htb: too many events !\n");
-	return q->now + PSCHED_TICKS_PER_SEC / 10;
+	/* too much load - let's continue on next jiffie */
+	return q->now + PSCHED_TICKS_PER_SEC / HZ;
 }
 
 /* Returns class->node+prio from id-tree where classe's id is >= id. NULL
#48 lore raw

vmcoreinfo: add the symbol "phys_base"

In reply to Chris Wright

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

From: Ken'ichi Ohmichi <[email protected]>

upstream commit: 629c8b4cdb354518308663aff2f719e02f69ffbe

Fix the problem that makedumpfile sometimes fails on x86_64 machine.

This patch adds the symbol "phys_base" to a vmcoreinfo data. The vmcoreinfo data has the minimum debugging information only for dump filtering. makedumpfile (dump filtering command) gets it to distinguish unnecessary pages, and makedumpfile creates a small dumpfile.

On x86_64 kernel which compiled with CONFIG_PHYSICAL_START=0x0 and CONFIG_RELOCATABLE=y, makedumpfile fails like the following:

 # makedumpfile -d31 /proc/vmcore dumpfile
 The kernel version is not supported.
 The created dumpfile may be incomplete.
 _exclude_free_page: Can't get next online node.

makedumpfile Failed.
#

The cause is the lack of the symbol "phys_base" in a vmcoreinfo data. If the symbol "phys_base" does not exist, makedumpfile considers an x86_64 kernel as non relocatable. As the result, makedumpfile misunderstands the physical address where the kernel is loaded, and it cannot translate a kernel virtual address to physical address correctly.

To fix this problem, this patch adds the symbol "phys_base" to a vmcoreinfo data.

---
 arch/x86/kernel/machine_kexec_64.c |    1 +
 1 file changed, 1 insertion(+)
arch/x86/kernel/machine_kexec_64.c +1 -0
@@ -233,6 +233,7 @@ NORET_TYPE void machine_kexec(struct kim
 
 void arch_crash_save_vmcoreinfo(void)
 {
+	VMCOREINFO_SYMBOL(phys_base);
 	VMCOREINFO_SYMBOL(init_level4_pgt);
 
 #ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
#49 lore raw

Re: vmcoreinfo: add the symbol "phys_base"

Quoted 2 lines · Chris Wright

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

This patch seems quite reasonable. However as I read it, it is a feature enhancement, that allows a user space tool to function better. Do we backport trivial features into stable now?

Eric

#50 lore raw

Re: vmcoreinfo: add the symbol "phys_base"

Quoted 8 lines · * Eric W. Biederman ([email protected]) wrote:
Quoted 2 lines · Chris Wright

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

This patch seems quite reasonable. However as I read it, it is a feature enhancement, that allows a user space tool to function better. Do we backport trivial features into stable now?

Function better, meaning work reliably? Sounds like a fix not a feature.

thanks,
-chris

#51 lore raw

Re: vmcoreinfo: add the symbol "phys_base"

Quoted 6 lines · Chris Wright
Quoted 5 lines · * Eric W. Biederman ([email protected]) wrote:
Quoted 2 lines · Chris Wright

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

Quoted 7 lines
Quoted 3 lines

This patch seems quite reasonable. However as I read it, it is a feature enhancement, that allows a user space tool to function better. Do we backport trivial features into stable now?

Function better, meaning work reliably? Sounds like a fix not a feature.

I think in theory, makedumpfile should be able to guess phys_base by looking at the vmcore ELF headers (Look for program headers which are mapping kernel text and data and look at respective virtual address and physical addresses.).

I think this patch just makes it explicit instead putting extra logic for guessing the things.

To make sure makedumpfile is not broken with older kernels (in specific configurations where phys_base is not zero), I think one can also modify makedumpfile but I don't see any harm in putting this small change in stable kernel.

Keni'chi, can you please throw some light here if makedumpfile is broken with stable kernel or not (with phys_base not being zero).

Thanks
Vivek

#52 lore raw

Re: vmcoreinfo: add the symbol "phys_base"

Hi,

Quoted 21 lines · Vivek Goyal
Quoted 11 lines · Chris Wright
Quoted 7 lines · * Eric W. Biederman ([email protected]) wrote:
Quoted 2 lines · Chris Wright

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

This patch seems quite reasonable. However as I read it, it is a feature enhancement, that allows a user space tool to function better. Do we backport trivial features into stable now?

Function better, meaning work reliably? Sounds like a fix not a feature.

I think in theory, makedumpfile should be able to guess phys_base by looking at the vmcore ELF headers (Look for program headers which are mapping kernel text and data and look at respective virtual address and physical addresses.).

I think this patch just makes it explicit instead putting extra logic for guessing the things.

Quoted 7 lines

To make sure makedumpfile is not broken with older kernels (in specific configurations where phys_base is not zero), I think one can also modify makedumpfile but I don't see any harm in putting this small change in stable kernel.

Keni'chi, can you please throw some light here if makedumpfile is broken with stable kernel or not (with phys_base not being zero).

I'm glad if this patch is merged into stable kernel, because this patch solves the problem of a current makedumpfile. This patch is very simple, and it doesn't have any bad influence for the kernel building, the kernel operating or the other.

I will release the next makedumpfile which can run on also linux without this patch. If both linux and makedumpfile have been fixed, the condition that the problem occurs can be decreased.

Thanks
Ken'ichi Ohmichi

#53 lore raw

Re: vmcoreinfo: add the symbol "phys_base"

In reply to Chris Wright
Quoted 6 lines · Chris Wright
Quoted 5 lines · * Eric W. Biederman ([email protected]) wrote:
Quoted 2 lines · Chris Wright

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

Quoted 6 lines
Quoted 3 lines

This patch seems quite reasonable. However as I read it, it is a feature enhancement, that allows a user space tool to function better. Do we backport trivial features into stable now?

Function better, meaning work reliably? Sounds like a fix not a feature.

After you also upgrade user space, so it can use the additional information allowing us to get better bug reports on kernels built in an interesting fashion.

Essentially this patch widens our user space ABI very slightly.

I'm just being pedantic, and I don't oppose it.

Eric

#54 lore raw

PARISC fix signal trampoline cache flushing

In reply to Chris Wright

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

From: Kyle McMartin <[email protected]>

upstream commit: cf39cc3b56bc4a562db6242d3069f65034ec7549

The signal trampolines were accidently flushing the kernel I$ instead of the users. Fix that up, and also add a missing user D$ flush while we're at it.

---
 arch/parisc/kernel/signal.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/parisc/kernel/signal.c +2 -1
@@ -534,7 +534,8 @@ insert_restart_trampoline(struct pt_regs
 		 * Flushing one cacheline is cheap.
 		 * "sync" on bigger (> 4 way) boxes is not.
 		 */
-		flush_icache_range(regs->gr[30], regs->gr[30] + 4);
+		flush_user_dcache_range(regs->gr[30], regs->gr[30] + 4);
+		flush_user_icache_range(regs->gr[30], regs->gr[30] + 4);
 
 		regs->gr[31] = regs->gr[30] + 8;
 		/* Preserve original r28. */
#55 lore raw

xen: mask out SEP from CPUID

In reply to Chris Wright

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

From: Jeremy Fitzhardinge <[email protected]>

upstream commit: d40e705903397445c6861a0a56c23e5b2e8f9b9a

Fix 32-on-64 pvops kernel:

we don't want userspace using syscall/sysenter, even if the hypervisor supports it, so mask it out from CPUID.

---
 arch/x86/xen/enlighten.c |    1 +
 1 file changed, 1 insertion(+)
arch/x86/xen/enlighten.c +1 -0
@@ -153,6 +153,7 @@ static void xen_cpuid(unsigned int *eax,
 	if (*eax == 1)
 		maskedx = ~((1 << X86_FEATURE_APIC) |  /* disable APIC */
 			    (1 << X86_FEATURE_ACPI) |  /* disable ACPI */
+			    (1 << X86_FEATURE_SEP)  |  /* disable SEP */
 			    (1 << X86_FEATURE_ACC));   /* thermal monitoring */
 
 	asm(XEN_EMULATE_PREFIX "cpuid"
#56 lore raw

mtd: memory corruption in block2mtd.c

In reply to Chris Wright

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

From: Ingo van Lil <[email protected]>

upstream commit: 2875fb65f8e40401c4b781ebc5002df10485f635

The block2mtd driver (drivers/mtd/devices/block2mtd.c) will kfree an on-stack pointer when handling an invalid argument line (e.g. block2mtd=/dev/loop0,xxx).

The kfree was added some time ago when "name" was dynamically allocated.

---
 drivers/mtd/devices/block2mtd.c |    1 -
 1 file changed, 1 deletion(-)
drivers/mtd/devices/block2mtd.c +0 -1
@@ -408,7 +408,6 @@ static int block2mtd_setup2(const char *
 	if (token[1]) {
 		ret = parse_num(&erase_size, token[1]);
 		if (ret) {
-			kfree(name);
 			parse_err("illegal erase size");
 		}
 	}
#57 lore raw

USB: serial: ti_usb_3410_5052: Correct TUSB3410 endpoint requirements.

In reply to Chris Wright

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

From: Robert Spanton <[email protected]>

upstream commit: 1bfd6693cd66f1e79abce62d3e8c3647e1f59a55

The changes introduced in commit 063a2da8f01806906f7d7b1a1424b9afddebc443 changed the semantics of the num_interrupt_in, num_interrupt_out, num_bulk_in and num_bulk_out entries of the usb_serial_driver struct to be the number of endpoints the device has when probed.

This patch changes the ti_1port_device usb_serial_driver struct to reflect this change. The single port devices only have 1 bulk_out endpoint in their initial configuration, and so this patch changes the number of other types to NUM_DONT_CARE.

The same change probably needs doing to the ti_2port_device struct, but I don't have a two port device at hand.

---
 drivers/usb/serial/ti_usb_3410_5052.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/serial/ti_usb_3410_5052.c +2 -2
@@ -264,8 +264,8 @@ static struct usb_serial_driver ti_1port
 	.description		= "TI USB 3410 1 port adapter",
 	.usb_driver		= &ti_usb_driver,
 	.id_table		= ti_id_table_3410,
-	.num_interrupt_in	= 1,
-	.num_bulk_in		= 1,
+	.num_interrupt_in	= NUM_DONT_CARE,
+	.num_bulk_in		= NUM_DONT_CARE,
 	.num_bulk_out		= 1,
 	.num_ports		= 1,
 	.attach			= ti_startup,
#58 lore raw

Re: USB: serial: ti_usb_3410_5052: Correct TUSB3410 endpoint requirements.

Am Donnerstag, 17. April 2008 03:01:46 schrieb Chris Wright:

Quoted 5 lines

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

From: Robert Spanton <[email protected]>

Quoted 7 lines

upstream commit: 1bfd6693cd66f1e79abce62d3e8c3647e1f59a55

The changes introduced in commit 063a2da8f01806906f7d7b1a1424b9afddebc443 changed the semantics of the num_interrupt_in, num_interrupt_out, num_bulk_in and num_bulk_out entries of the usb_serial_driver struct to be the number of endpoints the device has when probed.

Greg, your last patch to 2.6.25-rc9 should have obsoleted this patch. Should your patch be included instead of this patch and
"USB: serial: fix regression in Visor/Palm OS module for kernels >= 2.6.24" ?

Regards
Oliver

#59 lore raw

Re: USB: serial: ti_usb_3410_5052: Correct TUSB3410 endpoint requirements.

Quoted 8 lines · Oliver Neukum

Am Donnerstag, 17. April 2008 03:01:46 schrieb Chris Wright:

Quoted 7 lines

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

From: Robert Spanton <[email protected]>

upstream commit: 1bfd6693cd66f1e79abce62d3e8c3647e1f59a55

Quoted 7 lines
Quoted 5 lines

The changes introduced in commit 063a2da8f01806906f7d7b1a1424b9afddebc443 changed the semantics of the num_interrupt_in, num_interrupt_out, num_bulk_in and num_bulk_out entries of the usb_serial_driver struct to be the number of endpoints the device has when probed.

Greg, your last patch to 2.6.25-rc9 should have obsoleted this patch.

Yes, but it came in too late :(

Quoted 2 lines

Should your patch be included instead of this patch and
"USB: serial: fix regression in Visor/Palm OS module for kernels >= 2.6.24" ?

This one is safe enough for now, the other patch has already been sent to stable@ so it will go into the next 2.6.24 kernel release.

thanks,

greg k-h

#60 lore raw

mtd: fix broken state in CFI driver caused by FL_SHUTDOWN

In reply to Chris Wright

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

From: Alexey Korolev <[email protected]>

upstream commit: fb6d080c6f75dfd7e23d5a3575334785aa8738eb

THe CFI driver in 2.6.24 kernel is broken. Not so intensive read/write operations cause incomplete writes which lead to kernel panics in JFFS2.

We investigated the issue - it is caused by bug in FL_SHUTDOWN parsing code. Sometimes chip returns -EIO as if it is in FL_SHUTDOWN state when it should wait in FL_PONT (error in order of conditions).

The following patch fixes the bug in state parsing code of CFI. Also I've added comments to notify developers if they want to add new case in future.

---
 drivers/mtd/chips/cfi_cmdset_0001.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/mtd/chips/cfi_cmdset_0001.c +5 -5
@@ -669,7 +669,7 @@ static int chip_ready (struct map_info *
 			/* Someone else might have been playing with it. */
 			return -EAGAIN;
 		}
-
+		/* Fall through */
 	case FL_READY:
 	case FL_CFI_QUERY:
 	case FL_JEDEC_QUERY:
@@ -729,14 +729,14 @@ static int chip_ready (struct map_info *
 		chip->state = FL_READY;
 		return 0;
 
+	case FL_SHUTDOWN:
+		/* The machine is rebooting now,so no one can get chip anymore */
+		return -EIO;
 	case FL_POINT:
 		/* Only if there's no operation suspended... */
 		if (mode == FL_READY && chip->oldstate == FL_READY)
 			return 0;
-
-	case FL_SHUTDOWN:
-		/* The machine is rebooting now,so no one can get chip anymore */
-		return -EIO;
+		/* Fall through */
 	default:
 	sleep:
 		set_current_state(TASK_UNINTERRUPTIBLE);
#61 lore raw

sis190: read the mac address from the eeprom first

In reply to Chris Wright

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

From: Francois Romieu <[email protected]>

upstream commit: 563e0ae06ff18f0b280f11cf706ba0172255ce52

Reading a serie of zero from the cmos sram area do not work well with is_valid_ether_addr(). Let's read the mac address from the eeprom first as it seems more reliable.

Fix for http://bugzilla.kernel.org/show_bug.cgi?id=9831

[email protected] notes:
This patch fixes http://bugs.gentoo.org/207706

---
 drivers/net/sis190.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/net/sis190.c +10 -5
@@ -1632,13 +1632,18 @@ static inline void sis190_init_rxfilter(
 
 static int sis190_get_mac_addr(struct pci_dev *pdev, struct net_device *dev)
 {
-	u8 from;
+	int rc;
+
+	rc = sis190_get_mac_addr_from_eeprom(pdev, dev);
+	if (rc < 0) {
+		u8 reg;
 
-	pci_read_config_byte(pdev, 0x73, &from);
+		pci_read_config_byte(pdev, 0x73, &reg);
 
-	return (from & 0x00000001) ?
-		sis190_get_mac_addr_from_apc(pdev, dev) :
-		sis190_get_mac_addr_from_eeprom(pdev, dev);
+		if (reg & 0x00000001)
+			rc = sis190_get_mac_addr_from_apc(pdev, dev);
+	}
+	return rc;
 }
 
 static void sis190_set_speed_auto(struct net_device *dev)
#62 lore raw

USB: serial: fix regression in Visor/Palm OS module for kernels >= 2.6.24

In reply to Chris Wright

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

From: Brad Sawatzky <[email protected]>

upstream commit: d04863e9e65767feff7807c8f693ac2719dd1944

Fixes a bug/inconsistency revealed by the additional sanity checking in
commit 063a2da8f01806906f7d7b1a1424b9afddebc443
introduced in the original 2.6.24 branch.

The Handspring Visor / PalmOS 4 device structure defines .num_bulk_out=2 but the usb-serial probe returns num_bulk_out=3, triggering the check in the above commit and forcing a bail out when the device (a Garmin iQue in my case) attempts to connect. The patch bumps the expected number of endpoints to 3.

FWIW, this patch will probably solve the following kernel bug report for Treo users (identical symptoms, different model PalmOS units):
<http://bugzilla.kernel.org/show_bug.cgi?id=10118>

---
 drivers/usb/serial/visor.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/serial/visor.c +1 -1
@@ -191,7 +191,7 @@ static struct usb_serial_driver handspri
 	.id_table =		id_table,
 	.num_interrupt_in =	NUM_DONT_CARE,
 	.num_bulk_in =		2,
-	.num_bulk_out =		2,
+	.num_bulk_out =		NUM_DONT_CARE,
 	.num_ports =		2,
 	.open =			visor_open,
 	.close =		visor_close,
#63 lore raw

signalfd: fix for incorrect SI_QUEUE user data reporting

In reply to Chris Wright

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

From: Davide Libenzi <[email protected]>

upstream commit: 0859ab59a8a48d2a96b9d2b7100889bcb6bb5818

Michael Kerrisk found out that signalfd was not reporting back user data pushed using sigqueue:

http://groups.google.com/group/linux.kernel/msg/9397cab8551e3123

The following patch makes signalfd report back the ssi_ptr and ssi_int members of the signalfd_siginfo structure.

---
 fs/signalfd.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
fs/signalfd.c +6 -1
@@ -110,9 +110,14 @@ static int signalfd_copyinfo(struct sign
 		err |= __put_user(kinfo->si_uid, &uinfo->ssi_uid);
 		err |= __put_user((long) kinfo->si_ptr, &uinfo->ssi_ptr);
 		break;
-	default: /* this is just in case for now ... */
+	default:
+		/*
+		 * This case catches also the signals queued by sigqueue().
+		 */
 		err |= __put_user(kinfo->si_pid, &uinfo->ssi_pid);
 		err |= __put_user(kinfo->si_uid, &uinfo->ssi_uid);
+		err |= __put_user((long) kinfo->si_ptr, &uinfo->ssi_ptr);
+		err |= __put_user(kinfo->si_int, &uinfo->ssi_int);
 		break;
 	}
 
#64 lore raw

SPARC64: Fix FPU saving in 64-bit signal handling.

In reply to Chris Wright

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

From: David S. Miller <[email protected]>

Upstream commit: 7c3cce978e4f933ac13758ec5d2554fc8d0927d2

The calculation of the FPU reg save area pointer
was wrong.

Based upon an OOPS report from Tom Callaway.

---
 arch/sparc64/kernel/signal.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/sparc64/kernel/signal.c +1 -1
@@ -354,7 +354,7 @@ static int invalid_frame_pointer(void __
 static inline int
 save_fpu_state(struct pt_regs *regs, __siginfo_fpu_t __user *fpu)
 {
-	unsigned long *fpregs = (unsigned long *)(regs+1);
+	unsigned long *fpregs = current_thread_info()->fpregs;
 	unsigned long fprs;
 	int err = 0;
 	
#65 lore raw

acpi: fix "buggy BIOS check" when CPUs are hot removed

In reply to Chris Wright

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

From: Alok Kataria <[email protected]>

upstream commit: ba62b077871a5255e271f4fdae57167651839277

Fixes a BUG in ACPI hotplugging.

processor_device_array[pr->id] needs to be set to NULL when removing a CPU. Else the "buggy BIOS check" in acpi_processor_start mistakenly fires when a CPU is removed from the system and then later re-added.

---
 drivers/acpi/processor_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/processor_core.c +1 -1
@@ -792,7 +792,7 @@ static int acpi_processor_remove(struct 
 	acpi_processor_remove_fs(device);
 
 	processors[pr->id] = NULL;
-
+	processor_device_array[pr->id] = NULL;
 	kfree(pr);
 
 	return 0;
#66 lore raw

xen: fix RMW when unmasking events

In reply to Chris Wright

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

From: Jeremy Fitzhardinge <[email protected]>

upstream commit: 04c44a080d2f699a3042d4e743f7ad2ffae9d538

xen_irq_enable_direct and xen_sysexit were using "andw $0x00ff, XEN_vcpu_info_pending(vcpu)" to unmask events and test for pending ones in one instuction.

Unfortunately, the pending flag must be modified with a locked operation since it can be set by another CPU, and the unlocked form of this operation was causing the pending flag to get lost, allowing the processor to return to usermode with pending events and ultimately deadlock.

The simple fix would be to make it a locked operation, but that's rather costly and unnecessary. The fix here is to split the mask-clearing and pending-testing into two instructions; the interrupt window between them is of no concern because either way pending or new events will be processed.

This should fix lingering bugs in using direct vcpu structure access too.

---
 arch/x86/xen/enlighten.c |    2 +-
 arch/x86/xen/xen-asm.S   |    9 +++++++--
 2 files changed, 8 insertions(+), 3 deletions(-)
arch/x86/xen/enlighten.c +1 -1
@@ -95,7 +95,7 @@ struct shared_info *HYPERVISOR_shared_in
  *
  * 0: not available, 1: available
  */
-static int have_vcpu_info_placement = 0;
+static int have_vcpu_info_placement = 1;
 
 static void __init xen_vcpu_setup(int cpu)
 {
arch/x86/xen/xen-asm.S +7 -2
@@ -33,12 +33,17 @@
 	events, then enter the hypervisor to get them handled.
  */
 ENTRY(xen_irq_enable_direct)
-	/* Clear mask and test pending */
-	andw $0x00ff, PER_CPU_VAR(xen_vcpu_info)+XEN_vcpu_info_pending
+	/* Unmask events */
+	movb $0, PER_CPU_VAR(xen_vcpu_info)+XEN_vcpu_info_mask
+
 	/* Preempt here doesn't matter because that will deal with
 	   any pending interrupts.  The pending check may end up being
 	   run on the wrong CPU, but that doesn't hurt. */
+
+	/* Test for pending */
+	testb $0xff, PER_CPU_VAR(xen_vcpu_info)+XEN_vcpu_info_pending
 	jz 1f
+
 2:	call check_events
 1:
 ENDPATCH(xen_irq_enable_direct)
#67 lore raw

HFS+: fix unlink of links

In reply to Chris Wright

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

From: Roman Zippel <[email protected]>

upstream commit: 76b0c26af2736b7e5b87e6ed7ab63901483d5736

Some time ago while attempting to handle invalid link counts, I botched the unlink of links itself, so this patch fixes this now correctly, so that only the link count of nodes that don't point to links is ignored. Thanks to Vlado Plaga <[email protected]> to notify me of this problem.

---
 fs/hfsplus/dir.c |   23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)
fs/hfsplus/dir.c +15 -8
@@ -340,16 +340,23 @@ static int hfsplus_unlink(struct inode *
 
 	if (inode->i_nlink > 0)
 		drop_nlink(inode);
-	hfsplus_delete_inode(inode);
-	if (inode->i_ino != cnid && !inode->i_nlink) {
-		if (!atomic_read(&HFSPLUS_I(inode).opencnt)) {
-			res = hfsplus_delete_cat(inode->i_ino, HFSPLUS_SB(sb).hidden_dir, NULL);
-			if (!res)
-				hfsplus_delete_inode(inode);
+	if (inode->i_ino == cnid)
+		clear_nlink(inode);
+	if (!inode->i_nlink) {
+		if (inode->i_ino != cnid) {
+			HFSPLUS_SB(sb).file_count--;
+			if (!atomic_read(&HFSPLUS_I(inode).opencnt)) {
+				res = hfsplus_delete_cat(inode->i_ino,
+							 HFSPLUS_SB(sb).hidden_dir,
+							 NULL);
+				if (!res)
+					hfsplus_delete_inode(inode);
+			} else
+				inode->i_flags |= S_DEAD;
 		} else
-			inode->i_flags |= S_DEAD;
+			hfsplus_delete_inode(inode);
 	} else
-		clear_nlink(inode);
+		HFSPLUS_SB(sb).file_count--;
 	inode->i_ctime = CURRENT_TIME_SEC;
 	mark_inode_dirty(inode);
 
#68 lore raw

plip: replace spin_lock_irq with spin_lock_irqsave in irq context

In reply to Chris Wright

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

From: Mikulas Patocka <[email protected]>

upstream commit: cabce28ec0a0ae3d0ddfa4461f0e8be94ade9e46

Plip uses spin_lock_irq/spin_unlock_irq in its IRQ handler (called from parport IRQ handler), the latter enables interrupts without parport subsystem IRQ handler expecting it.

The bug can be seen if you compile kernel with lock dependency checking and use plip --- it produces a warning.

This patch changes it to spin_lock_irqsave/spin_lock_irqrestore, so that it doesn't enable interrupts when already disabled.

---
 drivers/net/plip.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/plip.c +4 -3
@@ -903,17 +903,18 @@ plip_interrupt(void *dev_id)
 	struct net_local *nl;
 	struct plip_local *rcv;
 	unsigned char c0;
+	unsigned long flags;
 
 	nl = netdev_priv(dev);
 	rcv = &nl->rcv_data;
 
-	spin_lock_irq (&nl->lock);
+	spin_lock_irqsave (&nl->lock, flags);
 
 	c0 = read_status(dev);
 	if ((c0 & 0xf8) != 0xc0) {
 		if ((dev->irq != -1) && (net_debug > 1))
 			printk(KERN_DEBUG "%s: spurious interrupt\n", dev->name);
-		spin_unlock_irq (&nl->lock);
+		spin_unlock_irqrestore (&nl->lock, flags);
 		return;
 	}
 
@@ -942,7 +943,7 @@ plip_interrupt(void *dev_id)
 		break;
 	}
 
-	spin_unlock_irq(&nl->lock);
+	spin_unlock_irqrestore(&nl->lock, flags);
 }
 
 static int
#69 lore raw

md: close a livelock window in handle_parity_checks5

In reply to Chris Wright

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

From: Dan Williams <[email protected]>

upstream commit: bd2ab67030e9116f1e4aae1289220255412b37fd

If a failure is detected after a parity check operation has been initiated, but before it completes handle_parity_checks5 will never quiesce operations on the stripe.

Explicitly handle this case by "canceling" the parity check, i.e. clear the STRIPE_OP_CHECK flags and queue the stripe on the handle list again to refresh any non-uptodate blocks.

Kernel versions >= 2.6.23 are susceptible.

---
 drivers/md/raid5.c |   53 ++++++++++++++++++++++++++++++-----------------------
 1 file changed, 30 insertions(+), 23 deletions(-)
drivers/md/raid5.c +30 -23
@@ -2348,25 +2348,15 @@ static void handle_issuing_new_write_req
 static void handle_parity_checks5(raid5_conf_t *conf, struct stripe_head *sh,
 				struct stripe_head_state *s, int disks)
 {
+	int canceled_check = 0;
+
 	set_bit(STRIPE_HANDLE, &sh->state);
-	/* Take one of the following actions:
-	 * 1/ start a check parity operation if (uptodate == disks)
-	 * 2/ finish a check parity operation and act on the result
-	 * 3/ skip to the writeback section if we previously
-	 *    initiated a recovery operation
-	 */
-	if (s->failed == 0 &&
-	    !test_bit(STRIPE_OP_MOD_REPAIR_PD, &sh->ops.pending)) {
-		if (!test_and_set_bit(STRIPE_OP_CHECK, &sh->ops.pending)) {
-			BUG_ON(s->uptodate != disks);
-			clear_bit(R5_UPTODATE, &sh->dev[sh->pd_idx].flags);
-			sh->ops.count++;
-			s->uptodate--;
-		} else if (
-		       test_and_clear_bit(STRIPE_OP_CHECK, &sh->ops.complete)) {
-			clear_bit(STRIPE_OP_CHECK, &sh->ops.ack);
-			clear_bit(STRIPE_OP_CHECK, &sh->ops.pending);
 
+	/* complete a check operation */
+	if (test_and_clear_bit(STRIPE_OP_CHECK, &sh->ops.complete)) {
+	    clear_bit(STRIPE_OP_CHECK, &sh->ops.ack);
+	    clear_bit(STRIPE_OP_CHECK, &sh->ops.pending);
+		if (s->failed == 0) {
 			if (sh->ops.zero_sum_result == 0)
 				/* parity is correct (on disc,
 				 * not in buffer any more)
@@ -2391,7 +2381,8 @@ static void handle_parity_checks5(raid5_
 					s->uptodate++;
 				}
 			}
-		}
+		} else
+			canceled_check = 1; /* STRIPE_INSYNC is not set */
 	}
 
 	/* check if we can clear a parity disk reconstruct */
@@ -2404,12 +2395,28 @@ static void handle_parity_checks5(raid5_
 		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.pending);
 	}
 
-	/* Wait for check parity and compute block operations to complete
-	 * before write-back
+	/* start a new check operation if there are no failures, the stripe is
+	 * not insync, and a repair is not in flight
 	 */
-	if (!test_bit(STRIPE_INSYNC, &sh->state) &&
-		!test_bit(STRIPE_OP_CHECK, &sh->ops.pending) &&
-		!test_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.pending)) {
+	if (s->failed == 0 &&
+	    !test_bit(STRIPE_INSYNC, &sh->state) &&
+	    !test_bit(STRIPE_OP_MOD_REPAIR_PD, &sh->ops.pending)) {
+		if (!test_and_set_bit(STRIPE_OP_CHECK, &sh->ops.pending)) {
+			BUG_ON(s->uptodate != disks);
+			clear_bit(R5_UPTODATE, &sh->dev[sh->pd_idx].flags);
+			sh->ops.count++;
+			s->uptodate--;
+		}
+	}
+
+	/* Wait for check parity and compute block operations to complete
+	 * before write-back.  If a failure occurred while the check operation
+	 * was in flight we need to cycle this stripe through handle_stripe
+	 * since the parity block may not be uptodate
+	 */
+	if (!canceled_check && !test_bit(STRIPE_INSYNC, &sh->state) &&
+	    !test_bit(STRIPE_OP_CHECK, &sh->ops.pending) &&
+	    !test_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.pending)) {
 		struct r5dev *dev;
 		/* either failed parity check, or recovery is happening */
 		if (s->failed == 0)
#70 lore raw

SUNRPC: Fix a memory leak in rpc_create()

In reply to Chris Wright

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

From: Chuck Lever <[email protected]>

upstream commit: ed13c27e546667fb0967ae30f5070cd7f6455f90

Commit 510deb0d was supposed to move the xprt_create_transport() call in rpc_create(), but neglected to remove the old call site. This resulted in a transport leak after every rpc_create() call.

This leak is present in 2.6.24 and 2.6.25.

---

 net/sunrpc/clnt.c |    4 ----
 1 file changed, 4 deletions(-)
net/sunrpc/clnt.c +0 -4
@@ -249,10 +249,6 @@ struct rpc_clnt *rpc_create(struct rpc_c
 	};
 	char servername[20];
 
-	xprt = xprt_create_transport(&xprtargs);
-	if (IS_ERR(xprt))
-		return (struct rpc_clnt *)xprt;
-
 	/*
 	 * If the caller chooses not to specify a hostname, whip
 	 * up a string representation of the passed-in address.
#71 lore raw

Re: SUNRPC: Fix a memory leak in rpc_create()

Hi

Quoted 25 lines · you

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

From: Chuck Lever <[email protected]>

upstream commit: ed13c27e546667fb0967ae30f5070cd7f6455f90

Commit 510deb0d was supposed to move the xprt_create_transport() call in rpc_create(), but neglected to remove the old call site. This resulted in a transport leak after every rpc_create() call.

This leak is present in 2.6.24 and 2.6.25.

---

 net/sunrpc/clnt.c |    4 ----
 1 file changed, 4 deletions(-)

net/sunrpc/clnt.c struct rpc_clnt *rpc_create(struct rpc_c · line 254

Quoted 10 lines
net/sunrpc/clnt.c +0 -4
@@ -249,10 +249,6 @@ struct rpc_clnt *rpc_create(struct rpc_c
 	};
 	char servername[20];
 
-	xprt = xprt_create_transport(&xprtargs);
-	if (IS_ERR(xprt))
-		return (struct rpc_clnt *)xprt;
-
 	/*
 	 * If the caller chooses not to specify a hostname, whip
 	 * up a string representation of the passed-in address.

This patch might introduce a regression:

kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
NET: Registered protocol family 17
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Bridge firewalling registered
br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature. device eth0 entered promiscuous mode audit(1208454819.533:2): dev=eth0 prom=256 old_prom=0 auid=4294967295
br0: port 1(eth0) entering learning state
br0: no IPv6 routers present
eth0: no IPv6 routers present
br0: topology change detected, propagating
br0: port 1(eth0) entering forwarding state
lp0: using parport0 (interrupt-driven).
lp0: console ready
ppdev: user-space parallel port driver
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Installing knfsd (copyright (C) 1996 [email protected]).

BUG: unable to handle kernel NULL pointer dereference at virtual address 000001c2
printing eip: f9043e90 *pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ppdev lp ac battery bridge ipv6 af_packet nls_iso8859_1 nls_cp437 vfat fat fuse dm_crypt vboxdrv powernow_k8 freq_table snd_ens1371 gameport snd_hda_intel snd_ac97_codec ac97_bus snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore button i2c_nforce2 snd_page_alloc parport_pc parport k8temp i2c_core psmouse evdev serio_raw pcspkr ext3 jbd dm_mirror dm_snapshot dm_mod sd_mod usb_storage sg sr_mod cdrom usbhid ff_memless sata_nv pata_acpi libusual ata_generic ohci1394 pata_amd forcedeth ieee1394 libata ehci_hcd ohci_hcd usbcore ssb pcmcia pcmcia_core thermal processor fan

Pid: 2874, comm: rpc.nfsd Not tainted (2.6.24-2.6.24.4.slh.6-sidux-686 #1)
EIP: 0060:[<f9043e90>] EFLAGS: 00010282 CPU: 1
EIP is at rpc_create+0x20/0x400 [sunrpc]
EAX: f90575bf EBX: 0000000a ECX: f90575bf EDX: 00000002
ESI: f76d1e20 EDI: f76d1d40 EBP: f76d1d18 ESP: f76d1cb0
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process rpc.nfsd (pid: 2874, ti=f76d0000 task=df8b3080 task.ti=f76d0000)

Stack: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
       00000202 bae43b63 c0265a43 f76d1d3c f76d1d40 f76d1d44 f76d1d48 f76d1d4c
       7d7aeed1 c39f2ca7 00000014 0000000a f76d1e20 f76d1d40 f76d1d18 f9050dda
Call Trace:
 [<c0265a43>] __add_entropy_words+0x63/0x1f0
 [<f9050dda>] rpcb_create+0xaa/0xb0 [sunrpc]
 [<f905113d>] rpcb_register+0xfd/0x1d0 [sunrpc]
 [<f904b290>] svc_register+0xa0/0x170 [sunrpc]
 [<f904bb89>] __svc_create+0x179/0x1d0 [sunrpc]
 [<f90ad3e0>] write_ports+0x0/0x190 [nfsd]
 [<f904bc2f>] svc_create_pooled+0x4f/0x170 [sunrpc]
 [<f90ac6f0>] nfsd_last_thread+0x0/0x80 [nfsd]
 [<f90ac6f0>] nfsd_last_thread+0x0/0x80 [nfsd]
 [<f90ad3e0>] write_ports+0x0/0x190 [nfsd]
 [<f90ac543>] nfsd_create_serv+0x63/0xd0 [nfsd]
 [<f90ac770>] nfsd+0x0/0x2c0 [nfsd]
 [<f90ad3e0>] write_ports+0x0/0x190 [nfsd]
 [<f90ad472>] write_ports+0x92/0x190 [nfsd]
 [<f90ad3e0>] write_ports+0x0/0x190 [nfsd]
 [<f90acf65>] nfsctl_transaction_write+0x55/0x80 [nfsd]
 [<f90acf10>] nfsctl_transaction_write+0x0/0x80 [nfsd]
 [<c01888e5>] vfs_write+0xb5/0x140
 [<c0188f81>] sys_write+0x41/0x70
 [<c010445a>] syscall_call+0x7/0xb
 =======================
Code: 00 00 00 00 8d bc 27 00 00 00 00 83 ec 5c 89 6c 24 58 89 c5 89 5c 24 4c 89 74 24 50 89 7c 24 54 8b 40 14 85 c0 0f 84 37 03 00 00 <0f> b6 83 b8 01 00 00 83 c8 02 88 83 b8 01 00 00 f6 45 24 08 74
EIP: [<f9043e90>] rpc_create+0x20/0x400 [sunrpc] SS:ESP 0068:f76d1cb0
---[ end trace 602ea69c0564d8ad ]---

The kernel has been compiled with gcc 4.2.3 (current debian/ unstable) and eth0 is part of a bridge using tun/ tap for virtualbox-ose. Neither 2.6.24.4, nor 2.6.24.5-rc1 with this patch reverted trigger this Oops.

Responses might be a little delayed, as I am relaying this report for a user (and cannot confirm it myself), I'll ask him to test 2.6.25 tomorrow.

Regards
Stefan Lippers-Hollmann

#72 lore raw

Re: SUNRPC: Fix a memory leak in rpc_create()

Quoted 10 lines · Stefan Lippers-Hollmann

Hi

Quoted 7 lines · you

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

From: Chuck Lever <[email protected]>

upstream commit: ed13c27e546667fb0967ae30f5070cd7f6455f90

Quoted 8 lines
Quoted 5 lines

Commit 510deb0d was supposed to move the xprt_create_transport() call in rpc_create(), but neglected to remove the old call site. This resulted in a transport leak after every rpc_create() call.

This leak is present in 2.6.24 and 2.6.25.

This patch might introduce a regression:

Gah. You're quite right. The commit that introduced the leak was merged well after 2.6.24 was released despite what the changelog entry says above:

$ git describe 510deb0d
v2.6.24-3933-g510deb0

I should have double-checked before posting this to [email protected]. I'm very sorry...

Trond

Signature · 6 lines
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
www.netapp.com
#73 lore raw

Re: SUNRPC: Fix a memory leak in rpc_create()

Quoted 9 lines · * Trond Myklebust ([email protected]) wrote:

Gah. You're quite right. The commit that introduced the leak was merged well after 2.6.24 was released despite what the changelog entry says above:

$ git describe 510deb0d
v2.6.24-3933-g510deb0

I should have double-checked before posting this to [email protected]. I'm very sorry...

Thanks, I dropped it.
-chris

#74 lore raw

Re: SUNRPC: Fix a memory leak in rpc_create()

In reply to Trond Myklebust
Quoted 25 lines · Trond Myklebust
Quoted 11 lines · Stefan Lippers-Hollmann

Hi

Quoted 8 lines · you

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

From: Chuck Lever <[email protected]>

upstream commit: ed13c27e546667fb0967ae30f5070cd7f6455f90

Quoted 8 lines
Quoted 5 lines

Commit 510deb0d was supposed to move the xprt_create_transport() call in rpc_create(), but neglected to remove the old call site. This resulted in a transport leak after every rpc_create() call.

This leak is present in 2.6.24 and 2.6.25.

This patch might introduce a regression:

Gah. You're quite right. The commit that introduced the leak was merged well after 2.6.24 was released despite what the changelog entry says above:

Quoted 5 lines
$ git describe 510deb0d
v2.6.24-3933-g510deb0

I should have double-checked before posting this to [email protected]. I'm very sorry...

I guessed it was required for 2.6.24 based on the patch dates (and a fuzzy recollection of which release the "bad" commit went in). The date on the "bad" commit was before the release of 2.6.24, so I assumed the fix should be applied in 2.6.24 as well.

Mea culpa.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

#75 lore raw

macb: Call phy_disconnect on removing

In reply to Chris Wright

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

From: Atsushi Nemoto <[email protected]>

upstream commit: 84b7901f8d5a17536ef2df7fd628ab865df8fe3a

Call phy_disconnect() on remove routine. Otherwise the phy timer causes a kernel crash when unloading.

---
 drivers/net/macb.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/net/macb.c +2 -0
@@ -1257,6 +1257,8 @@ static int __devexit macb_remove(struct 
 
 	if (dev) {
 		bp = netdev_priv(dev);
+		if (bp->phy_dev)
+			phy_disconnect(bp->phy_dev);
 		mdiobus_unregister(&bp->mii_bus);
 		kfree(bp->mii_bus.irq);
 		unregister_netdev(dev);
#76 lore raw

locks: fix possible infinite loop in fcntl(F_SETLKW) over nfs

In reply to Chris Wright

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

From: J. Bruce Fields <[email protected]>

upstream commit: 19e729a928172103e101ffd0829fd13e68c13f78

Miklos Szeredi found the bug:

"Basically what happens is that on the server nlm_fopen() calls nfsd_open() which returns -EACCES, to which nlm_fopen() returns NLM_LCK_DENIED.

"On the client this will turn into a -EAGAIN (nlm_stat_to_errno()), which in will cause fcntl_setlk() to retry forever."

So, for example, opening a file on an nfs filesystem, changing permissions to forbid further access, then trying to lock the file, could result in an infinite loop.

And Trond Myklebust identified the culprit, from Marc Eshel and I:

	7723ec9777d9832849b76475b1a21a2872a40d20 "locks: factor out
	generic/filesystem switch from setlock code"

That commit claimed to just be reshuffling code, but actually introduced a behavioral change by calling the lock method repeatedly as long as it returned -EAGAIN.

We assumed this would be safe, since we assumed a lock of type SETLKW would only return with either success or an error other than -EAGAIN. However, nfs does can in fact return -EAGAIN in this situation, and independently of whether that behavior is correct or not, we don't actually need this change, and it seems far safer not to depend on such assumptions about the filesystem's ->lock method.

Therefore, revert the problematic part of the original commit. This leaves vfs_lock_file() and its other callers unchanged, while returning fcntl_setlk and fcntl_setlk64 to their former behavior.

---
 fs/locks.c |   48 ++++++++++++++++++++++++++++--------------------
 1 file changed, 28 insertions(+), 20 deletions(-)
fs/locks.c +28 -20
@@ -1805,17 +1805,21 @@ again:
 	if (error)
 		goto out;
 
-	for (;;) {
-		error = vfs_lock_file(filp, cmd, file_lock, NULL);
-		if (error != -EAGAIN || cmd == F_SETLK)
-			break;
-		error = wait_event_interruptible(file_lock->fl_wait,
-				!file_lock->fl_next);
-		if (!error)
-			continue;
+	if (filp->f_op && filp->f_op->lock != NULL)
+		error = filp->f_op->lock(filp, cmd, file_lock);
+	else {
+		for (;;) {
+			error = posix_lock_file(filp, file_lock, NULL);
+			if (error != -EAGAIN || cmd == F_SETLK)
+				break;
+			error = wait_event_interruptible(file_lock->fl_wait,
+					!file_lock->fl_next);
+			if (!error)
+				continue;
 
-		locks_delete_block(file_lock);
-		break;
+			locks_delete_block(file_lock);
+			break;
+		}
 	}
 
 	/*
@@ -1929,17 +1933,21 @@ again:
 	if (error)
 		goto out;
 
-	for (;;) {
-		error = vfs_lock_file(filp, cmd, file_lock, NULL);
-		if (error != -EAGAIN || cmd == F_SETLK64)
-			break;
-		error = wait_event_interruptible(file_lock->fl_wait,
-				!file_lock->fl_next);
-		if (!error)
-			continue;
+	if (filp->f_op && filp->f_op->lock != NULL)
+		error = filp->f_op->lock(filp, cmd, file_lock);
+	else {
+		for (;;) {
+			error = posix_lock_file(filp, file_lock, NULL);
+			if (error != -EAGAIN || cmd == F_SETLK64)
+				break;
+			error = wait_event_interruptible(file_lock->fl_wait,
+					!file_lock->fl_next);
+			if (!error)
+				continue;
 
-		locks_delete_block(file_lock);
-		break;
+			locks_delete_block(file_lock);
+			break;
+		}
 	}
 
 	/*
#77 lore raw

inotify: remove debug code

In reply to Chris Wright

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

From: Nick Piggin <[email protected]>

upstream commit: 0d71bd5993b630a989d15adc2562a9ffe41cd26d

The inotify debugging code is supposed to verify that the DCACHE_INOTIFY_PARENT_WATCHED scalability optimisation does not result in notifications getting lost nor extra needless locking generated.

Unfortunately there are also some races in the debugging code. And it isn't very good at finding problems anyway. So remove it for now.

---
 fs/dcache.c  |    3 ---
 fs/inotify.c |   17 +++++------------
 2 files changed, 5 insertions(+), 15 deletions(-)
fs/dcache.c +0 -3
@@ -1408,9 +1408,6 @@ void d_delete(struct dentry * dentry)
 	if (atomic_read(&dentry->d_count) == 1) {
 		dentry_iput(dentry);
 		fsnotify_nameremove(dentry, isdir);
-
-		/* remove this and other inotify debug checks after 2.6.18 */
-		dentry->d_flags &= ~DCACHE_INOTIFY_PARENT_WATCHED;
 		return;
 	}
 
fs/inotify.c +5 -12
@@ -168,20 +168,14 @@ static void set_dentry_child_flags(struc
 		struct dentry *child;
 
 		list_for_each_entry(child, &alias->d_subdirs, d_u.d_child) {
-			if (!child->d_inode) {
-				WARN_ON(child->d_flags & DCACHE_INOTIFY_PARENT_WATCHED);
+			if (!child->d_inode)
 				continue;
-			}
+
 			spin_lock(&child->d_lock);
-			if (watched) {
-				WARN_ON(child->d_flags &
-						DCACHE_INOTIFY_PARENT_WATCHED);
+			if (watched)
 				child->d_flags |= DCACHE_INOTIFY_PARENT_WATCHED;
-			} else {
-				WARN_ON(!(child->d_flags &
-					DCACHE_INOTIFY_PARENT_WATCHED));
-				child->d_flags&=~DCACHE_INOTIFY_PARENT_WATCHED;
-			}
+			else
+				child->d_flags &=~DCACHE_INOTIFY_PARENT_WATCHED;
 			spin_unlock(&child->d_lock);
 		}
 	}
@@ -253,7 +247,6 @@ void inotify_d_instantiate(struct dentry
 	if (!inode)
 		return;
 
-	WARN_ON(entry->d_flags & DCACHE_INOTIFY_PARENT_WATCHED);
 	spin_lock(&entry->d_lock);
 	parent = entry->d_parent;
 	if (parent->d_inode && inotify_inode_watched(parent->d_inode))
#78 lore raw

file capabilities: remove cap_task_kill()

In reply to Chris Wright

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

From: Serge Hallyn <[email protected]>

upstream commit: aedb60a67c10a0861af179725d060765262ba0fb

The original justification for cap_task_kill() was as follows:

check_kill_permission() does appropriate uid equivalence checks. However with file capabilities it becomes possible for an unprivileged user to execute a file with file capabilities resulting in a more privileged task with the same uid.

However now that cap_task_kill() always returns 0 (permission granted) when p->uid==current->uid, the whole hook is worthless, and only likely to create more subtle problems in the corner cases where it might still be called but return -EPERM. Those cases are basically when uids are different but euid/suid is equivalent as per the check in check_kill_permission().

One example of a still-broken application is 'at' for non-root users.

This patch removes cap_task_kill().

---
 include/linux/security.h |    3 +--
 security/capability.c    |    1 -
 security/commoncap.c     |   39 ---------------------------------------
 3 files changed, 1 insertion(+), 42 deletions(-)
include/linux/security.h +1 -2
@@ -62,7 +62,6 @@ extern int cap_inode_need_killpriv(struc
 extern int cap_inode_killpriv(struct dentry *dentry);
 extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, int flags);
 extern void cap_task_reparent_to_init (struct task_struct *p);
-extern int cap_task_kill(struct task_struct *p, struct siginfo *info, int sig, u32 secid);
 extern int cap_task_setscheduler (struct task_struct *p, int policy, struct sched_param *lp);
 extern int cap_task_setioprio (struct task_struct *p, int ioprio);
 extern int cap_task_setnice (struct task_struct *p, int nice);
@@ -2112,7 +2111,7 @@ static inline int security_task_kill (st
 				      struct siginfo *info, int sig,
 				      u32 secid)
 {
-	return cap_task_kill(p, info, sig, secid);
+	return 0;
 }
 
 static inline int security_task_wait (struct task_struct *p)
security/capability.c +0 -1
@@ -40,7 +40,6 @@ static struct security_operations capabi
 	.inode_need_killpriv =		cap_inode_need_killpriv,
 	.inode_killpriv =		cap_inode_killpriv,
 
-	.task_kill =			cap_task_kill,
 	.task_setscheduler =		cap_task_setscheduler,
 	.task_setioprio =		cap_task_setioprio,
 	.task_setnice =			cap_task_setnice,
security/commoncap.c +0 -39
@@ -527,40 +527,6 @@ int cap_task_setnice (struct task_struct
 	return cap_safe_nice(p);
 }
 
-int cap_task_kill(struct task_struct *p, struct siginfo *info,
-				int sig, u32 secid)
-{
-	if (info != SEND_SIG_NOINFO && (is_si_special(info) || SI_FROMKERNEL(info)))
-		return 0;
-
-	/*
-	 * Running a setuid root program raises your capabilities.
-	 * Killing your own setuid root processes was previously
-	 * allowed.
-	 * We must preserve legacy signal behavior in this case.
-	 */
-	if (p->uid == current->uid)
-		return 0;
-
-	/* sigcont is permitted within same session */
-	if (sig == SIGCONT && (task_session_nr(current) == task_session_nr(p)))
-		return 0;
-
-	if (secid)
-		/*
-		 * Signal sent as a particular user.
-		 * Capabilities are ignored.  May be wrong, but it's the
-		 * only thing we can do at the moment.
-		 * Used only by usb drivers?
-		 */
-		return 0;
-	if (cap_issubset(p->cap_permitted, current->cap_permitted))
-		return 0;
-	if (capable(CAP_KILL))
-		return 0;
-
-	return -EPERM;
-}
 #else
 int cap_task_setscheduler (struct task_struct *p, int policy,
 			   struct sched_param *lp)
@@ -575,11 +541,6 @@ int cap_task_setnice (struct task_struct
 {
 	return 0;
 }
-int cap_task_kill(struct task_struct *p, struct siginfo *info,
-				int sig, u32 secid)
-{
-	return 0;
-}
 #endif
 
 void cap_task_reparent_to_init (struct task_struct *p)
#79 lore raw

ipmi: change device node ordering to reflect probe order

In reply to Chris Wright

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

From: Carol Hebert <[email protected]>

upstream commit: abd24df828f1a72971db29d1b74fefae104ea9e2

In 2.6.14 a patch was merged which switching the order of the ipmi device naming from in-order-of-discovery over to reverse-order-of-discovery.

So on systems with multiple BMC interfaces, the ipmi device names are being created in reverse order relative to how they are discovered on the system (e.g. on an IBM x3950 multinode server with N nodes, the device name for the BMC in the first node is /dev/ipmiN-1 and the device name for the BMC in the last node is /dev/ipmi0, etc.).

The problem is caused by the list handling routines chosen in dmi_scan.c. Using list_add() causes the multiple ipmi devices to be added to the device list using a stack-paradigm and so the ipmi driver subsequently pulls them off during initialization in LIFO order. This patch changes the dmi_save_ipmi_device() list handling paradigm to a queue, thereby allowing the ipmi driver to build the ipmi device names in the order in which they are found on the system.

---
 drivers/firmware/dmi_scan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/dmi_scan.c +1 -1
@@ -219,7 +219,7 @@ static void __init dmi_save_ipmi_device(
 	dev->name = "IPMI controller";
 	dev->device_data = data;
 
-	list_add(&dev->list, &dmi_devices);
+	list_add_tail(&dev->list, &dmi_devices);
 }
 
 /*
#80 lore raw

CRYPTO xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

In reply to Chris Wright

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

From: Joy Latten <[email protected]>

upstream commit: 1edcf2e1ee2babb011cfca80ad9d202e9c491669

The kernel crashes when ipsec passes a udp packet of about 14XX bytes of data to aes-xcbc-mac.

It seems the first xxxx bytes of the data are in first sg entry, and remaining xx bytes are in next sg entry. But we don't check next sg entry to see if we need to go look the page up.

I noticed in hmac.c, we do a scatterwalk_sg_next(), to do this check and possible lookup, thus xcbc.c needs to use this routine too.

A 15-hour run of an ipsec stress test sending streams of tcp and udp packets of various sizes, using this patch and aes-xcbc-mac completed successfully, so hopefully this fixes the problem.

---
 crypto/xcbc.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
crypto/xcbc.c +9 -8
@@ -116,13 +116,11 @@ static int crypto_xcbc_digest_update2(st
 	struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
 	struct crypto_cipher *tfm = ctx->child;
 	int bs = crypto_hash_blocksize(parent);
-	unsigned int i = 0;
 
-	do {
-
-		struct page *pg = sg_page(&sg[i]);
-		unsigned int offset = sg[i].offset;
-		unsigned int slen = sg[i].length;
+	for (;;) {
+		struct page *pg = sg_page(sg);
+		unsigned int offset = sg->offset;
+		unsigned int slen = sg->length;
 
 		if (unlikely(slen > nbytes))
 			slen = nbytes;
@@ -182,8 +180,11 @@ static int crypto_xcbc_digest_update2(st
 			offset = 0;
 			pg++;
 		}
-		i++;
-	} while (nbytes>0);
+
+		if (!nbytes)
+			break;
+		sg = scatterwalk_sg_next(sg);
+	}
 
 	return 0;
 }
#81 lore raw

Re: CRYPTO xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

Hi;

17 Nis 2008 Per tarihinde, Chris Wright şunları yazmıştı:

Quoted 54 lines

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

From: Joy Latten <[email protected]>

upstream commit: 1edcf2e1ee2babb011cfca80ad9d202e9c491669

The kernel crashes when ipsec passes a udp packet of about 14XX bytes of data to aes-xcbc-mac.

It seems the first xxxx bytes of the data are in first sg entry, and remaining xx bytes are in next sg entry. But we don't check next sg entry to see if we need to go look the page up.

I noticed in hmac.c, we do a scatterwalk_sg_next(), to do this check and possible lookup, thus xcbc.c needs to use this routine too.

A 15-hour run of an ipsec stress test sending streams of tcp and udp packets of various sizes, using this patch and aes-xcbc-mac completed successfully, so hopefully this fixes the problem.

---
 crypto/xcbc.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
crypto/xcbc.c +4 -6
@@ -116,13 +116,11 @@ static int crypto_xcbc_digest_update2(st
 	struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
 	struct crypto_cipher *tfm = ctx->child;
 	int bs = crypto_hash_blocksize(parent);
-	unsigned int i = 0;
 
-	do {
-
-		struct page *pg = sg_page(&sg[i]);
-		unsigned int offset = sg[i].offset;
-		unsigned int slen = sg[i].length;
+	for (;;) {
+		struct page *pg = sg_page(sg);
+		unsigned int offset = sg->offset;
+		unsigned int slen = sg->length;
 
 		if (unlikely(slen > nbytes))
 			slen = nbytes;
@@ -182,8 +180,11 @@ static int crypto_xcbc_digest_update2(st
 			offset = 0;
 			pg++;
 		}

crypto/xcbc.c static int crypto_xcbc_digest_update2(st · line 190

Quoted 10 lines
crypto/xcbc.c +5 -2
-		i++;
-	} while (nbytes>0);
+
+		if (!nbytes)
+			break;
+		sg = scatterwalk_sg_next(sg);
+	}
 
 	return 0;
 }

zangetsu linux-2.6.24 # make

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  LD      crypto/built-in.o
  CC [M]  crypto/xcbc.o

crypto/xcbc.c: In function `crypto_xcbc_digest_update2':
crypto/xcbc.c:186: error: implicit declaration of function `scatterwalk_sg_next' crypto/xcbc.c:186: warning: assignment makes pointer from integer without a cast make[1]: *** [crypto/xcbc.o] Hata 1
make: *** [crypto] Hata 2

Cheeers

Signature · 4 lines
S.Çağlar Onur <[email protected]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
maintainer
#82 lore raw

Re: CRYPTO xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

Quoted 7 lines · S.Çağlar Onur

CC [M] crypto/xcbc.o
crypto/xcbc.c: In function `crypto_xcbc_digest_update2':
crypto/xcbc.c:186: error: implicit declaration of function `scatterwalk_sg_next' crypto/xcbc.c:186: warning: assignment makes pointer from integer without a cast make[1]: *** [crypto/xcbc.o] Hata 1
make: *** [crypto] Hata 2

Sorry, my fault. That should've been sg_next for 2.6.24.

Thanks for catching this!

Signature · 28 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
From: Joy Latten <[email protected]>

[CRYPTO] xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

[ Upstream commit: 1edcf2e1ee2babb011cfca80ad9d202e9c491669 ]

The kernel crashes when ipsec passes a udp packet of about 14XX bytes
of data to aes-xcbc-mac.

It seems the first xxxx bytes of the data are in first sg entry,
and remaining xx bytes are in next sg entry. But we don't
check next sg entry to see if we need to go look the page up.

I noticed in hmac.c, we do a scatterwalk_sg_next(), to do this check
and possible lookup, thus xcbc.c needs to use this routine too.

A 15-hour run of an ipsec stress test sending streams of tcp and
udp packets of various sizes,  using this patch and
aes-xcbc-mac completed successfully, so hopefully this fixes the
problem.

Signed-off-by: Joy Latten <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
crypto/xcbc.c +9 -8
index 2feb0f2..b63b633 100644
@@ -116,13 +116,11 @@ static int crypto_xcbc_digest_update2(struct hash_desc *pdesc,
 	struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
 	struct crypto_cipher *tfm = ctx->child;
 	int bs = crypto_hash_blocksize(parent);
-	unsigned int i = 0;
 
-	do {
-
-		struct page *pg = sg_page(&sg[i]);
-		unsigned int offset = sg[i].offset;
-		unsigned int slen = sg[i].length;
+	for (;;) {
+		struct page *pg = sg_page(sg);
+		unsigned int offset = sg->offset;
+		unsigned int slen = sg->length;
 
 		if (unlikely(slen > nbytes))
 			slen = nbytes;
@@ -182,8 +180,11 @@ static int crypto_xcbc_digest_update2(struct hash_desc *pdesc,
 			offset = 0;
 			pg++;
 		}
-		i++;
-	} while (nbytes>0);
+
+		if (!nbytes)
+			break;
+		sg = sg_next(sg);
+	}
 
 	return 0;
 }
#83 lore raw

Re: CRYPTO xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

Quoted 1 line · * Herbert Xu ([email protected]) wrote:

Sorry, my fault. That should've been sg_next for 2.6.24.

Thanks, fixed it up.
-chris

#84 lore raw

kbuild: soften modpost checks when doing cross builds

In reply to Chris Wright

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

From: Sam Ravnborg <[email protected]>

upstream commit: 4ce6efed48d736e3384c39ff87bda723e1f8e041

The module alias support in the kernel have a consistency check where it is checked that the size of a structure in the kernel and on the build host are the same.
For cross builds this check does not make sense so detect when we do cross builds and silently skip the check in these situations.
This fixes a build bug for a wireless driver when cross building for arm.

---
 Makefile                 |    2 +-
 scripts/Makefile.modpost |    6 +++++-
 scripts/mod/file2alias.c |    4 ++++
 scripts/mod/modpost.c    |    5 ++++-
 scripts/mod/modpost.h    |    1 +
 5 files changed, 15 insertions(+), 3 deletions(-)
Makefile +1 -1
@@ -189,7 +189,7 @@ SUBARCH := $(shell uname -m | sed -e s/i
 # Alternatively CROSS_COMPILE can be set in the environment.
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
-
+export KBUILD_BUILDHOST := $(SUBARCH)
 ARCH		?= $(SUBARCH)
 CROSS_COMPILE	?=
 
scripts/Makefile.modpost +5 -1
@@ -53,6 +53,9 @@ modules   := $(patsubst %.o,%.ko, $(wild
 # Stop after building .o files if NOFINAL is set. Makes compile tests quicker
 _modpost: $(if $(KBUILD_MODPOST_NOFINAL), $(modules:.ko:.o),$(modules))
 
+ifneq ($(KBUILD_BUILDHOST),$(ARCH))
+        cross_build := 1
+endif
 
 # Step 2), invoke modpost
 #  Includes step 3,4
@@ -62,7 +65,8 @@ modpost = scripts/mod/modpost           
  $(if $(KBUILD_EXTMOD),-i,-o) $(kernelsymfile)   \
  $(if $(KBUILD_EXTMOD),-I $(modulesymfile))      \
  $(if $(KBUILD_EXTMOD),-o $(modulesymfile))      \
- $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
+ $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w) \
+ $(if $(cross_build),-c)
 
 quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
       cmd_modpost = $(modpost) -s
scripts/mod/file2alias.c +4 -0
@@ -51,11 +51,13 @@ do {                                    
                 sprintf(str + strlen(str), "*");                \
 } while(0)
 
+unsigned int cross_build = 0;
 /**
  * Check that sizeof(device_id type) are consistent with size of section
  * in .o file. If in-consistent then userspace and kernel does not agree
  * on actual size which is a bug.
  * Also verify that the final entry in the table is all zeros.
+ * Ignore both checks if build host differ from target host and size differs.
  **/
 static void device_id_check(const char *modname, const char *device_id,
 			    unsigned long size, unsigned long id_size,
@@ -64,6 +66,8 @@ static void device_id_check(const char *
 	int i;
 
 	if (size % id_size || size < id_size) {
+		if (cross_build != 0)
+			return;
 		fatal("%s: sizeof(struct %s_device_id)=%lu is not a modulo "
 		      "of the size of section __mod_%s_device_table=%lu.\n"
 		      "Fix definition of struct %s_device_id "
scripts/mod/modpost.c +4 -1
@@ -1659,7 +1659,7 @@ int main(int argc, char **argv)
 	int opt;
 	int err;
 
-	while ((opt = getopt(argc, argv, "i:I:mso:aw")) != -1) {
+	while ((opt = getopt(argc, argv, "i:I:cmso:aw")) != -1) {
 		switch(opt) {
 			case 'i':
 				kernel_read = optarg;
@@ -1668,6 +1668,9 @@ int main(int argc, char **argv)
 				module_read = optarg;
 				external_module = 1;
 				break;
+		case 'c':
+			cross_build = 1;
+			break;
 			case 'm':
 				modversions = 1;
 				break;
scripts/mod/modpost.h +1 -0
@@ -130,6 +130,7 @@ struct elf_info {
 };
 
 /* file2alias.c */
+extern unsigned int cross_build;
 void handle_moddevtable(struct module *mod, struct elf_info *info,
 			Elf_Sym *sym, const char *symname);
 void add_moddevtable(struct buffer *buf, struct module *mod);
#85 lore raw
In reply to Chris Wright
Quoted 2 lines · * Chris Wright ([email protected]) wrote:

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.24.5-rc1.gz

updated roll-up at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.24.5-rc2.gz