[patch 00/50] 2.6.25.6 -stable review

[patch 00/50] 2.6.25.6 -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.25.6 release.
There are 50 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let us know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

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

Responses should be made by Mon, Jun 9 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.25.6-rc1.gz
and the diffstat can be found below.

thanks,

the -stable release team
-- 

 Makefile                                       |    2 +-
 arch/powerpc/kernel/smp.c                      |    2 +
 arch/powerpc/mm/slb.c                          |   21 +++--
 arch/x86/kernel/apic_64.c                      |    2 +-
 arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c     |   10 ++
 arch/x86/kernel/irq_32.c                       |    2 +-
 arch/x86/kernel/process_32.c                   |    5 +-
 arch/x86/kernel/process_64.c                   |    5 +-
 arch/x86/kernel/ptrace.c                       |    7 +-
 arch/x86/kernel/tsc_32.c                       |   38 ++++----
 arch/x86/kernel/tsc_64.c                       |    5 +-
 arch/x86/pci/common.c                          |   17 ----
 block/genhd.c                                  |    9 ++-
 drivers/ata/libata-core.c                      |   12 +++
 drivers/block/brd.c                            |    1 +
 drivers/cpufreq/cpufreq.c                      |    4 +-
 drivers/hid/hid-input.c                        |    5 +-
 drivers/hid/usbhid/hid-quirks.c                |   38 ++++----
 drivers/i2c/busses/i2c-nforce2.c               |   28 +++++-
 drivers/i2c/chips/max6875.c                    |    3 -
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |    6 ++
 drivers/md/md.c                                |    2 +-
 drivers/md/raid5.c                             |   10 ++-
 drivers/net/atl1/atl1_main.c                   |    1 +
 drivers/net/ps3_gelic_wireless.c               |    2 +
 drivers/usb/class/cdc-acm.c                    |    3 +
 drivers/usb/host/ohci-omap.c                   |    3 +-
 drivers/usb/host/ohci-sm501.c                  |    3 +-
 drivers/usb/misc/ldusb.c                       |    4 -
 drivers/usb/serial/ftdi_sio.c                  |    1 +
 drivers/usb/serial/ftdi_sio.h                  |    6 ++
 drivers/usb/serial/option.c                    |    9 ++-
 drivers/usb/serial/pl2303.c                    |    1 -
 drivers/usb/serial/pl2303.h                    |    1 -
 drivers/usb/storage/unusual_devs.h             |   10 ++
 fs/cifs/inode.c                                |   15 +++-
 fs/ecryptfs/ecryptfs_kernel.h                  |    2 -
 fs/ecryptfs/read_write.c                       |   22 -----
 fs/ext3/xattr.c                                |    5 +
 fs/ext4/xattr.c                                |    5 +
 fs/proc/array.c                                |    2 +-
 fs/proc/base.c                                 |   33 ++++++--
 fs/proc/task_mmu.c                             |   28 ++----
 fs/xfs/linux-2.6/xfs_buf.c                     |   24 ++++-
 fs/xfs/linux-2.6/xfs_buf.h                     |   19 ++++
 include/asm-x86/tlbflush.h                     |   13 +++-
 include/linux/capability.h                     |   29 +++++--
 include/linux/genhd.h                          |    4 +-
 include/linux/hid.h                            |    1 +
 include/linux/types.h                          |    4 +-
 init/do_mounts.c                               |   27 ++++++-
 kernel/capability.c                            |  111 ++++++++++++++++--------
 kernel/cgroup.c                                |    2 +-
 mm/memory_hotplug.c                            |   78 ++++++++--------
 mm/mmap.c                                      |    8 ++-
 mm/page_alloc.c                                |    3 +-
 net/ipv6/netfilter/nf_conntrack_reasm.c        |    8 +-
 net/netfilter/nf_conntrack_expect.c            |    4 +-
 net/netfilter/xt_connlimit.c                   |    3 +-
 net/netfilter/xt_iprange.c                     |    2 +
 security/smack/smack_lsm.c                     |   12 +++
 61 files changed, 483 insertions(+), 259 deletions(-)

[patch 01/50] block: do_mounts - accept root=<non-existant partition>

[Chris Wright]

[-- Attachment #1: block-do_mounts-accept-root-non-existant-partition.patch --]
[-- Type: text/plain, Size: 3488 bytes --]

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

From: Kay Sievers <kay.sievers@vrfy.org>

commit 30f2f0eb4bd2c43d10a8b0d872c6e5ad8f31c9a0 upstream

Some devices, like md, may create partitions only at first access,
so allow root= to be set to a valid non-existant partition of an
existing disk. This applies only to non-initramfs root mounting.

This fixes a regression from 2.6.24 which did allow this to happen and
broke some users machines :(

Acked-by: Neil Brown <neilb@suse.de>
Tested-by: Joao Luis Meloni Assirati <assirati@nonada.if.usp.br>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 block/genhd.c         |    9 ++++++---
 include/linux/genhd.h |    4 ++--
 init/do_mounts.c      |   27 ++++++++++++++++++++++++++-
 3 files changed, 34 insertions(+), 6 deletions(-)

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -645,7 +645,7 @@ void genhd_media_change_notify(struct ge
 EXPORT_SYMBOL_GPL(genhd_media_change_notify);
 #endif  /*  0  */
 
-dev_t blk_lookup_devt(const char *name)
+dev_t blk_lookup_devt(const char *name, int part)
 {
 	struct device *dev;
 	dev_t devt = MKDEV(0, 0);
@@ -653,7 +653,11 @@ dev_t blk_lookup_devt(const char *name)
 	mutex_lock(&block_class_lock);
 	list_for_each_entry(dev, &block_class.devices, node) {
 		if (strcmp(dev->bus_id, name) == 0) {
-			devt = dev->devt;
+			struct gendisk *disk = dev_to_disk(dev);
+
+			if (part < disk->minors)
+				devt = MKDEV(MAJOR(dev->devt),
+					     MINOR(dev->devt) + part);
 			break;
 		}
 	}
@@ -661,7 +665,6 @@ dev_t blk_lookup_devt(const char *name)
 
 	return devt;
 }
-
 EXPORT_SYMBOL(blk_lookup_devt);
 
 struct gendisk *alloc_disk(int minors)
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -524,7 +524,7 @@ struct unixware_disklabel {
 #define ADDPART_FLAG_RAID	1
 #define ADDPART_FLAG_WHOLEDISK	2
 
-extern dev_t blk_lookup_devt(const char *name);
+extern dev_t blk_lookup_devt(const char *name, int part);
 extern char *disk_name (struct gendisk *hd, int part, char *buf);
 
 extern int rescan_partitions(struct gendisk *disk, struct block_device *bdev);
@@ -552,7 +552,7 @@ static inline struct block_device *bdget
 
 static inline void printk_all_partitions(void) { }
 
-static inline dev_t blk_lookup_devt(const char *name)
+static inline dev_t blk_lookup_devt(const char *name, int part)
 {
 	dev_t devt = MKDEV(0, 0);
 	return devt;
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -76,6 +76,7 @@ dev_t name_to_dev_t(char *name)
 	char s[32];
 	char *p;
 	dev_t res = 0;
+	int part;
 
 	if (strncmp(name, "/dev/", 5) != 0) {
 		unsigned maj, min;
@@ -106,7 +107,31 @@ dev_t name_to_dev_t(char *name)
 	for (p = s; *p; p++)
 		if (*p == '/')
 			*p = '!';
-	res = blk_lookup_devt(s);
+	res = blk_lookup_devt(s, 0);
+	if (res)
+		goto done;
+
+	/*
+	 * try non-existant, but valid partition, which may only exist
+	 * after revalidating the disk, like partitioned md devices
+	 */
+	while (p > s && isdigit(p[-1]))
+		p--;
+	if (p == s || !*p || *p == '0')
+		goto fail;
+
+	/* try disk name without <part number> */
+	part = simple_strtoul(p, NULL, 10);
+	*p = '\0';
+	res = blk_lookup_devt(s, part);
+	if (res)
+		goto done;
+
+	/* try disk name without p<part number> */
+	if (p < s + 2 || !isdigit(p[-2]) || p[-1] != 'p')
+		goto fail;
+	p[-1] = '\0';
+	res = blk_lookup_devt(s, part);
 	if (res)
 		goto done;
 

-- 

Re: [patch 01/50] block: do_mounts - accept root=<non-existant partition>

[Adrian Bunk]

We have reports from two different people running into problems that 
are exposed by this patch.

Although it's unclear what's actually going wrong this patch is IMHO 
not -stable fodder until that's sorted out.

cu
Adrian

-- 

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

Re: [patch 01/50] block: do_mounts - accept root=<non-existant partition>

[Chris Wright]

* Adrian Bunk (bunk@kernel.org) wrote:
> We have reports from two different people running into problems that 
> are exposed by this patch.

Thanks, pulled.  We can add back (plus Linus' fix) once everything
is settled.

thanks,
-chris

[patch 02/50] POWERPC Bolt in SLB entry for kernel stack on secondary cpus

[Chris Wright]

[-- Attachment #1: powerpc-bolt-in-slb-entry-for-kernel-stack-on-secondary-cpus.patch --]
[-- Type: text/plain, Size: 4381 bytes --]

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

From: Paul Mackerras <paulus@samba.org>

This is upstream as commit 3b5750644b2ffa2a76fdfe7b4e00e4af2ecf3539.

This fixes a regression reported by Kamalesh Bulabel where a POWER4
machine would crash because of an SLB miss at a point where the SLB
miss exception was unrecoverable.  This regression is tracked at:

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

SLB misses at such points shouldn't happen because the kernel stack is
the only memory accessed other than things in the first segment of the
linear mapping (which is mapped at all times by entry 0 of the SLB).
The context switch code ensures that SLB entry 2 covers the kernel
stack, if it is not already covered by entry 0.  None of entries 0
to 2 are ever replaced by the SLB miss handler.

Where this went wrong is that the context switch code assumes it
doesn't have to write to SLB entry 2 if the new kernel stack is in the
same segment as the old kernel stack, since entry 2 should already be
correct.  However, when we start up a secondary cpu, it calls
slb_initialize, which doesn't set up entry 2.  This is correct for
the boot cpu, where we will be using a stack in the kernel BSS at this
point (i.e. init_thread_union), but not necessarily for secondary
cpus, whose initial stack can be allocated anywhere.  This doesn't
cause any immediate problem since the SLB miss handler will just
create an SLB entry somewhere else to cover the initial stack.

In fact it's possible for the cpu to go quite a long time without SLB
entry 2 being valid.  Eventually, though, the entry created by the SLB
miss handler will get overwritten by some other entry, and if the next
access to the stack is at an unrecoverable point, we get the crash.

This fixes the problem by making slb_initialize create a suitable
entry for the kernel stack, if we are on a secondary cpu and the stack
isn't covered by SLB entry 0.  This requires initializing the
get_paca()->kstack field earlier, so I do that in smp_create_idle
where the current field is initialized.  This also abstracts a bit of
the computation that mk_esid_data in slb.c does so that it can be used
in slb_initialize.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 arch/powerpc/kernel/smp.c |    2 ++
 arch/powerpc/mm/slb.c     |   21 +++++++++++++--------
 2 files changed, 15 insertions(+), 8 deletions(-)

--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -386,6 +386,8 @@ static void __init smp_create_idle(unsig
 		panic("failed fork for CPU %u: %li", cpu, PTR_ERR(p));
 #ifdef CONFIG_PPC64
 	paca[cpu].__current = p;
+	paca[cpu].kstack = (unsigned long) task_thread_info(p)
+		+ THREAD_SIZE - STACK_FRAME_OVERHEAD;
 #endif
 	current_set[cpu] = task_thread_info(p);
 	task_thread_info(p)->cpu = cpu;
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -44,13 +44,13 @@ static void slb_allocate(unsigned long e
 	slb_allocate_realmode(ea);
 }
 
+#define slb_esid_mask(ssize)	\
+	(((ssize) == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T)
+
 static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
 					 unsigned long slot)
 {
-	unsigned long mask;
-
-	mask = (ssize == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T;
-	return (ea & mask) | SLB_ESID_V | slot;
+	return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
 }
 
 #define slb_vsid_shift(ssize)	\
@@ -301,11 +301,16 @@ void slb_initialize(void)
 
 	create_shadowed_slbe(VMALLOC_START, mmu_kernel_ssize, vflags, 1);
 
+	/* For the boot cpu, we're running on the stack in init_thread_union,
+	 * which is in the first segment of the linear mapping, and also
+	 * get_paca()->kstack hasn't been initialized yet.
+	 * For secondary cpus, we need to bolt the kernel stack entry now.
+	 */
 	slb_shadow_clear(2);
+	if (raw_smp_processor_id() != boot_cpuid &&
+	    (get_paca()->kstack & slb_esid_mask(mmu_kernel_ssize)) > PAGE_OFFSET)
+		create_shadowed_slbe(get_paca()->kstack,
+				     mmu_kernel_ssize, lflags, 2);
 
-	/* We don't bolt the stack for the time being - we're in boot,
-	 * so the stack is in the bolted segment.  By the time it goes
-	 * elsewhere, we'll call _switch() which will bolt in the new
-	 * one. */
 	asm volatile("isync":::"memory");
 }

-- 

[patch 03/50] USB: remove PICDEM FS USB demo (04d8:000c) device from ldusb

[Chris Wright]

[-- Attachment #1: usb-remove-picdem-fs-usb-demo-device-from-ldusb.patch --]
[-- Type: text/plain, Size: 1698 bytes --]

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

From: Xiaofan Chen <xiaofanc@gmail.com>

commit 5fc89390f74ac42165db477793fb30f6a200e79c upstream
Date: Tue, 13 May 2008 21:52:00 +0800
Subject: [patch 03/50] USB: remove PICDEM FS USB demo (04d8:000c) device from ldusb

Microchip has changed the PICDEM FS USB demo device (0x04d8:000c)
to use bulk transfer and not interrupt transfer. So I've updated the libusb
based program here (Post #31).
	http://forum.microchip.com/tm.aspx?m=106426&mpage=2

So I believe that the in-kernel ldusb driver will no longer work with the
demo firmware.  It should be removed.


Signed-off-by: Xiaofan Chen <xiaofanc@gmail.com>
Cc: Michael Hund <MHund@LD-Didactic.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/misc/ldusb.c |    4 ----
 1 file changed, 4 deletions(-)

--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -63,9 +63,6 @@
 #define USB_DEVICE_ID_VERNIER_CYCLOPS	0x0004
 #define USB_DEVICE_ID_VERNIER_LCSPEC	0x0006
 
-#define USB_VENDOR_ID_MICROCHIP		0x04d8
-#define USB_DEVICE_ID_PICDEM		0x000c
-
 #ifdef CONFIG_USB_DYNAMIC_MINORS
 #define USB_LD_MINOR_BASE	0
 #else
@@ -92,7 +89,6 @@ static struct usb_device_id ld_usb_table
 	{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_GOTEMP) },
 	{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_SKIP) },
 	{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_CYCLOPS) },
-	{ USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICDEM) },
 	{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LCSPEC) },
 	{ }					/* Terminating entry */
 };

-- 

[patch 04/50] USB: unusual_devs: Add support for GI 0401 SD-Card interface

[Chris Wright]

[-- Attachment #1: usb-unusual_devs-add-support-for-gi-0401-sd-card-interface.patch --]
[-- Type: text/plain, Size: 3886 bytes --]

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

From: Filip Aben <f.aben@option.com>

commit e7c6f80fd733218aa1e79efa5d9ece9f76966160 upstream

Enables the SD-Card interface on the GI 0401 HSUPA card from Option.

The unusual_devs.h entry is necessary because the device descriptor is
vendor-specific. That prevents usb-storage from binding to it as an
interface driver.

This revised patch adds a small comment explaining why and reduces the
rev range.

T:  Bus=02 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=0af0 ProdID=7401 Rev= 0.00
S:  Manufacturer=Option N.V.
S:  Product=Globetrotter HSUPA Modem
C:* #Ifs=10 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 0 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 2 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 4 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 5 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 5 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 6 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 6 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 7 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 7 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 9 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Filip Aben <f.aben@option.com>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/storage/unusual_devs.h |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1285,6 +1285,16 @@ UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0
 		US_SC_DEVICE, US_PR_DEVICE, NULL,
 		US_FL_IGNORE_DEVICE ),
 
+/* Reported by F. Aben <f.aben@option.com>
+ * This device (wrongly) has a vendor-specific device descriptor.
+ * The entry is needed so usb-storage can bind to it's mass-storage
+ * interface as an interface driver */
+UNUSUAL_DEV( 0x0af0, 0x7401, 0x0000, 0x0000,
+		"Option",
+		"GI 0401 SD-Card",
+		US_SC_DEVICE, US_PR_DEVICE, NULL,
+		0 ),
+
 #ifdef CONFIG_USB_STORAGE_ISD200
 UNUSUAL_DEV(  0x0bf6, 0xa001, 0x0100, 0x0110,
 		"ATI",

-- 

[patch 05/50] USB: option: add new Dell 5520 HSDPA variant

[Chris Wright]

[-- Attachment #1: usb-option-add-new-dell-5520-hsdpa-variant.patch --]
[-- Type: text/plain, Size: 1168 bytes --]

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

From: Dan Williams <dcbw@redhat.com>

commit 96cb15cf977356d9d3117dd88f3fe187d6024f4b upstream

New variant of the 5520 found by Luke Sheldrick.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/serial/option.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -293,6 +293,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(DELL_VENDOR_ID, 0x8133) }, /* Dell Wireless 5720 == Novatel EV620 CDMA/EV-DO */
 	{ USB_DEVICE(DELL_VENDOR_ID, 0x8136) },	/* Dell Wireless HSDPA 5520 == Novatel Expedite EU860D */
 	{ USB_DEVICE(DELL_VENDOR_ID, 0x8137) },	/* Dell Wireless HSDPA 5520 */
+	{ USB_DEVICE(DELL_VENDOR_ID, 0x8138) },	/* Dell Wireless 5520 Voda I Mobile Broadband (3G HSDPA) Minicard */
 	{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) },
 	{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
 	{ USB_DEVICE(AXESSTEL_VENDOR_ID, AXESSTEL_PRODUCT_MV110H) },

-- 

[patch 06/50] USB: add Zoom Telephonics Model 3095F V.92 USB Mini External modem to cdc-acm

[Chris Wright]

[-- Attachment #1: usb-add-zoom-telephonics-model-3095f-v.92-usb-mini-external-modem-to-cdc-acm.patch --]
[-- Type: text/plain, Size: 1479 bytes --]

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

From: Iain McFarlane <iain@imcfarla.homelinux.net>

commit 6149ed5e3a6207595bd7362af7724d64f44af216 upstream

The patch below is a necessary workaround to support the Zoom Telephonics Model 3095F V.92 USB Mini External modem, which fails to initialise properly during normal probing thus:

May  3 22:53:00 imcfarla kernel: drivers/usb/class/cdc-acm.c: Zero length descriptor references
May  3 22:53:00 imcfarla kernel: cdc_acm: probe of 5-2:1.0 failed with error -22

Adding the patch below causes the probing section to be skipped, and the modem
then initialises correctly.

Signed-off-by: Iain McFarlane <iain@imcfarla.homelinux.net>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/class/cdc-acm.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1242,6 +1242,9 @@ static struct usb_device_id acm_ids[] = 
 	{ USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */
 	.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
 	},
+	{ USB_DEVICE(0x0803, 0x3095), /* Zoom Telephonics Model 3095F USB MODEM */
+	.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+	},
 
 	/* control interfaces with various AT-command sets */
 	{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,

-- 

[patch 07/50] USB: do not handle device 1410:5010 in option driver

[Chris Wright]

[-- Attachment #1: usb-do-not-handle-device-1410-5010-in-option-driver.patch --]
[-- Type: text/plain, Size: 2289 bytes --]

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

From: Eugeniy Meshcheryakov <eugen@debian.org>

commit cdafc37a7b727b75ced65e31e47dafbd8b70f97f upstream

This device is not a serial port, but a virtual CD-ROM device. For
example with my Novatel MC950D:

lsusb -v -d 1410:5010 | grep InterfaceClass
      bInterfaceClass         8 Mass Storage

After some time (ca. 5min) or if virtual CD is ejected, device id
changes to 1410:4400:

% lsusb -v -d 1410:4400 | grep InterfaceClass
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceClass       255 Vendor Specific Class

Variable name says that 0x5010 is a Novatel U727, but searching in
internet shows, that this device also provides virtual CD that should be
ejected before use. Product id for serial port in this case is 0x4100.

Signed-off-by: Eugeniy Meshcheryakov <eugen@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/serial/option.c |    3 ---
 1 file changed, 3 deletions(-)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -154,8 +154,6 @@ static int  option_send_setup(struct usb
 #define NOVATELWIRELESS_PRODUCT_MC727		0x4100
 #define NOVATELWIRELESS_PRODUCT_MC950D		0x4400
 
-#define NOVATELWIRELESS_PRODUCT_U727		0x5010
-
 /* FUTURE NOVATEL PRODUCTS */
 #define NOVATELWIRELESS_PRODUCT_EVDO_1		0x6000
 #define NOVATELWIRELESS_PRODUCT_HSPA_1		0x7000
@@ -269,7 +267,6 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EU870D) }, /* Novatel EU850D/EU860D/EU870D */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC950D) }, /* Novatel MC930D/MC950D */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC727) }, /* Novatel MC727/U727/USB727 */
-	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_U727) }, /* Novatel U727 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EVDO_1) }, /* Novatel EVDO product */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_HSPA_1) }, /* Novatel HSPA product */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EMBEDDED_1) }, /* Novatel Embedded product */

-- 

[patch 08/50] USB: add Telstra NextG CDMA id to option driver

[Chris Wright]

[-- Attachment #1: usb-add-telstra-nextg-cdma-id-to-option-driver.patch --]
[-- Type: text/plain, Size: 952 bytes --]

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

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

commit 23cacd65f65956426bbca25964a68c174db83a31 upstream

As reported by Magnus Boman <captain.magnus@opensuse.org>

Cc: Magnus Boman <captain.magnus@opensuse.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/serial/option.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -299,6 +299,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC680) },
 	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
 	{ USB_DEVICE(MAXON_VENDOR_ID, 0x6280) }, /* BP3-USB & BP3-EXT HSDPA */
+	{ USB_DEVICE(0x19d2, 0x0001) }, 	/* Telstra NextG CDMA */
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

-- 

[patch 09/50] ext3/4: fix uninitialized bs in ext3/4_xattr_set_handle()

[Chris Wright]

[-- Attachment #1: ext3-4-fix-uninitialized-bs-in-ext3-4_xattr_set_handle.patch --]
[-- Type: text/plain, Size: 2107 bytes --]

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

From: Tiger Yang <tiger.yang@oracle.com>

commit 7e01c8e5420b6c7f9d85d34c15d8c7a15c9fc720 upstream

This fix the uninitialized bs when we try to replace a xattr entry in
ibody with the new value which require more than free space.

This situation only happens we format ext3/4 with inode size more than 128 and
we have put xattr entries both in ibody and block.  The consequences about
this bug is we will lost the xattr block which pointed by i_file_acl with all
xattr entires in it.  We will alloc a new xattr block and put that large value
entry in it.  The old xattr block will become orphan block.

Signed-off-by: Tiger Yang <tiger.yang@oracle.com>
Cc: <linux-ext4@vger.kernel.org>
Cc: Andreas Gruenbacher <agruen@suse.de>
Acked-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 fs/ext3/xattr.c |    5 +++++
 fs/ext4/xattr.c |    5 +++++
 2 files changed, 10 insertions(+)

--- a/fs/ext3/xattr.c
+++ b/fs/ext3/xattr.c
@@ -1000,6 +1000,11 @@ ext3_xattr_set_handle(handle_t *handle, 
 			i.value = NULL;
 			error = ext3_xattr_block_set(handle, inode, &i, &bs);
 		} else if (error == -ENOSPC) {
+			if (EXT3_I(inode)->i_file_acl && !bs.s.base) {
+				error = ext3_xattr_block_find(inode, &i, &bs);
+				if (error)
+					goto cleanup;
+			}
 			error = ext3_xattr_block_set(handle, inode, &i, &bs);
 			if (error)
 				goto cleanup;
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1011,6 +1011,11 @@ ext4_xattr_set_handle(handle_t *handle, 
 			i.value = NULL;
 			error = ext4_xattr_block_set(handle, inode, &i, &bs);
 		} else if (error == -ENOSPC) {
+			if (EXT4_I(inode)->i_file_acl && !bs.s.base) {
+				error = ext4_xattr_block_find(inode, &i, &bs);
+				if (error)
+					goto cleanup;
+			}
 			error = ext4_xattr_block_set(handle, inode, &i, &bs);
 			if (error)
 				goto cleanup;

-- 

[patch 10/50] libata: force hardreset if link is in powersave mode

[Chris Wright]

[-- Attachment #1: libata-force-hardreset-if-link-is-in-powersave-mode.patch --]
[-- Type: text/plain, Size: 1533 bytes --]

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

From: Tejun Heo <htejun@gmail.com>

Inhibiting link PM mode doesn't bring the link back online if it's
already in powersave mode.  If SRST is used in these cases, libata EH
thinks that the link is offline and fails detection.  Force hardreset
if link is in powersave mode.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/ata/libata-core.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3947,6 +3947,7 @@ int ata_std_prereset(struct ata_link *li
 	struct ata_port *ap = link->ap;
 	struct ata_eh_context *ehc = &link->eh_context;
 	const unsigned long *timing = sata_ehc_deb_timing(ehc);
+	u32 sstatus;
 	int rc;
 
 	/* handle link resume */
@@ -3960,6 +3961,17 @@ int ata_std_prereset(struct ata_link *li
 	if (ap->flags & ATA_FLAG_PMP)
 		ehc->i.action |= ATA_EH_HARDRESET;
 
+	/* if link powersave is on, force hardreset */
+	if (sata_scr_read(link, SCR_STATUS, &sstatus) == 0) {
+		u8 ipm = sstatus >> 8;
+
+		if (ipm == 2 || ipm == 6) {
+			ata_link_printk(link, KERN_INFO, "link in powersave "
+				"mode (ipm=%d), forcing hardreset\n", ipm);
+			ehc->i.action |= ATA_EH_HARDRESET;
+		}
+	}
+
 	/* if we're about to do hardreset, nothing more to do */
 	if (ehc->i.action & ATA_EH_HARDRESET)
 		return 0;

-- 

Re: [patch 10/50] libata: force hardreset if link is in powersave mode

[Linus Torvalds]

On Fri, 6 Jun 2008, Chris Wright wrote:
>
> -stable review patch.  If anyone has any objections, please let us know.
> ---------------------
> 
> From: Tejun Heo <htejun@gmail.com>
> 
> Inhibiting link PM mode doesn't bring the link back online if it's
> already in powersave mode.  If SRST is used in these cases, libata EH
> thinks that the link is offline and fails detection.  Force hardreset
> if link is in powersave mode.

This isn't upstream. Maybe there's some reason it's not needed upstream, 
but it would be nice to know.

		Linus

Re: [stable] [patch 10/50] libata: force hardreset if link is in powersave mode

[Greg KH]

On Fri, Jun 06, 2008 at 06:27:15PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 6 Jun 2008, Chris Wright wrote:
> >
> > -stable review patch.  If anyone has any objections, please let us know.
> > ---------------------
> > 
> > From: Tejun Heo <htejun@gmail.com>
> > 
> > Inhibiting link PM mode doesn't bring the link back online if it's
> > already in powersave mode.  If SRST is used in these cases, libata EH
> > thinks that the link is offline and fails detection.  Force hardreset
> > if link is in powersave mode.
> 
> This isn't upstream. Maybe there's some reason it's not needed upstream, 
> but it would be nice to know.

To quote Tejun when he sent this patch:
	---
	Patch for -stable only.  Devel branch now uses hardreset by
	default so this type of promotion logic isn't necessary anymore.


thanks,

greg k-h

Re: [stable] [patch 10/50] libata: force hardreset if link is in powersave mode

[Linus Torvalds]

On Fri, 6 Jun 2008, Greg KH wrote:
> > 
> > This isn't upstream. Maybe there's some reason it's not needed upstream, 
> > but it would be nice to know.
> 
> To quote Tejun when he sent this patch:
> 	---
> 	Patch for -stable only.  Devel branch now uses hardreset by
> 	default so this type of promotion logic isn't necessary anymore.

Ok, thanks,

		Linus

Re: [patch 10/50] libata: force hardreset if link is in powersave mode

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Fri, 6 Jun 2008, Chris Wright wrote:
>> -stable review patch.  If anyone has any objections, please let us know.
>> ---------------------
>>
>> From: Tejun Heo <htejun@gmail.com>
>>
>> Inhibiting link PM mode doesn't bring the link back online if it's
>> already in powersave mode.  If SRST is used in these cases, libata EH
>> thinks that the link is offline and fails detection.  Force hardreset
>> if link is in powersave mode.
> 
> This isn't upstream. Maybe there's some reason it's not needed upstream, 
> but it would be nice to know.

We do hard reset by default...

	Jeff

[patch 11/50] memory_hotplug: always initialize pageblock bitmap

[Chris Wright]

[-- Attachment #1: memory_hotplug-always-initialize-pageblock-bitmap.patch --]
[-- Type: text/plain, Size: 6025 bytes --]

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

From: Heiko Carstens <heiko.carstens@de.ibm.com>

commit 76cdd58e558669366adfaded436fda01b30cce3e upstream

Trying to online a new memory section that was added via memory hotplug
sometimes results in crashes when the new pages are added via __free_page.
 Reason for that is that the pageblock bitmap isn't initialized and hence
contains random stuff.  That means that get_pageblock_migratetype()
returns also random stuff and therefore

	list_add(&page->lru,
		&zone->free_area[order].free_list[migratetype]);

in __free_one_page() tries to do a list_add to something that isn't even
necessarily a list.

This happens since 86051ca5eaf5e560113ec7673462804c54284456 ("mm: fix
usemap initialization") which makes sure that the pageblock bitmap gets
only initialized for pages present in a zone.  Unfortunately for hot-added
memory the zones "grow" after the memmap and the pageblock memmap have
been initialized.  Which means that the new pages have an unitialized
bitmap.  To solve this the calls to grow_zone_span() and grow_pgdat_span()
are moved to __add_zone() just before the initialization happens.

The patch also moves the two functions since __add_zone() is the only
caller and I didn't want to add a forward declaration.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 mm/memory_hotplug.c |   78 ++++++++++++++++++++++++++--------------------------
 mm/page_alloc.c     |    3 --
 2 files changed, 40 insertions(+), 41 deletions(-)

--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -58,23 +58,59 @@ static void release_memory_resource(stru
 	return;
 }
 
-
 #ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+static void grow_zone_span(struct zone *zone, unsigned long start_pfn,
+			   unsigned long end_pfn)
+{
+	unsigned long old_zone_end_pfn;
+
+	zone_span_writelock(zone);
+
+	old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
+	if (start_pfn < zone->zone_start_pfn)
+		zone->zone_start_pfn = start_pfn;
+
+	zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -
+				zone->zone_start_pfn;
+
+	zone_span_writeunlock(zone);
+}
+
+static void grow_pgdat_span(struct pglist_data *pgdat, unsigned long start_pfn,
+			    unsigned long end_pfn)
+{
+	unsigned long old_pgdat_end_pfn =
+		pgdat->node_start_pfn + pgdat->node_spanned_pages;
+
+	if (start_pfn < pgdat->node_start_pfn)
+		pgdat->node_start_pfn = start_pfn;
+
+	pgdat->node_spanned_pages = max(old_pgdat_end_pfn, end_pfn) -
+					pgdat->node_start_pfn;
+}
+
 static int __add_zone(struct zone *zone, unsigned long phys_start_pfn)
 {
 	struct pglist_data *pgdat = zone->zone_pgdat;
 	int nr_pages = PAGES_PER_SECTION;
 	int nid = pgdat->node_id;
 	int zone_type;
+	unsigned long flags;
 
 	zone_type = zone - pgdat->node_zones;
 	if (!zone->wait_table) {
-		int ret = 0;
+		int ret;
+
 		ret = init_currently_empty_zone(zone, phys_start_pfn,
 						nr_pages, MEMMAP_HOTPLUG);
-		if (ret < 0)
+		if (ret)
 			return ret;
 	}
+	pgdat_resize_lock(zone->zone_pgdat, &flags);
+	grow_zone_span(zone, phys_start_pfn, phys_start_pfn + nr_pages);
+	grow_pgdat_span(zone->zone_pgdat, phys_start_pfn,
+			phys_start_pfn + nr_pages);
+	pgdat_resize_unlock(zone->zone_pgdat, &flags);
 	memmap_init_zone(nr_pages, nid, zone_type,
 			 phys_start_pfn, MEMMAP_HOTPLUG);
 	return 0;
@@ -134,36 +170,6 @@ int __add_pages(struct zone *zone, unsig
 }
 EXPORT_SYMBOL_GPL(__add_pages);
 
-static void grow_zone_span(struct zone *zone,
-		unsigned long start_pfn, unsigned long end_pfn)
-{
-	unsigned long old_zone_end_pfn;
-
-	zone_span_writelock(zone);
-
-	old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-	if (start_pfn < zone->zone_start_pfn)
-		zone->zone_start_pfn = start_pfn;
-
-	zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -
-				zone->zone_start_pfn;
-
-	zone_span_writeunlock(zone);
-}
-
-static void grow_pgdat_span(struct pglist_data *pgdat,
-		unsigned long start_pfn, unsigned long end_pfn)
-{
-	unsigned long old_pgdat_end_pfn =
-		pgdat->node_start_pfn + pgdat->node_spanned_pages;
-
-	if (start_pfn < pgdat->node_start_pfn)
-		pgdat->node_start_pfn = start_pfn;
-
-	pgdat->node_spanned_pages = max(old_pgdat_end_pfn, end_pfn) -
-					pgdat->node_start_pfn;
-}
-
 static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
 			void *arg)
 {
@@ -183,7 +189,6 @@ static int online_pages_range(unsigned l
 
 int online_pages(unsigned long pfn, unsigned long nr_pages)
 {
-	unsigned long flags;
 	unsigned long onlined_pages = 0;
 	struct zone *zone;
 	int need_zonelists_rebuild = 0;
@@ -211,11 +216,6 @@ int online_pages(unsigned long pfn, unsi
 	 * memory_block->state_sem.
 	 */
 	zone = page_zone(pfn_to_page(pfn));
-	pgdat_resize_lock(zone->zone_pgdat, &flags);
-	grow_zone_span(zone, pfn, pfn + nr_pages);
-	grow_pgdat_span(zone->zone_pgdat, pfn, pfn + nr_pages);
-	pgdat_resize_unlock(zone->zone_pgdat, &flags);
-
 	/*
 	 * If this zone is not populated, then it is not in zonelist.
 	 * This means the page allocator ignores this zone.
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2837,8 +2837,6 @@ __meminit int init_currently_empty_zone(
 
 	zone->zone_start_pfn = zone_start_pfn;
 
-	memmap_init(size, pgdat->node_id, zone_idx(zone), zone_start_pfn);
-
 	zone_init_free_lists(zone);
 
 	return 0;
@@ -3408,6 +3406,7 @@ static void __paginginit free_area_init_
 		ret = init_currently_empty_zone(zone, zone_start_pfn,
 						size, MEMMAP_EARLY);
 		BUG_ON(ret);
+		memmap_init(size, nid, j, zone_start_pfn);
 		zone_start_pfn += size;
 	}
 }

-- 

[patch 12/50] USB: fix build errors in ohci-omap.c and ohci-sm501.c

[Chris Wright]

[-- Attachment #1: usb-fix-build-errors-in-ohci-omap.c-and-ohci-sm501.c.patch --]
[-- Type: text/plain, Size: 1522 bytes --]

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

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

This fixes the build errors previously caused by
45fa78357eab3287b5c39f2d983b91150b3f4bd8

This makes the code mirror what went into Linus's tree previously.


Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/usb/host/ohci-omap.c  |    3 ++-
 drivers/usb/host/ohci-sm501.c |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -511,7 +511,8 @@ static int ohci_omap_suspend(struct plat
 
 static int ohci_omap_resume(struct platform_device *dev)
 {
-	struct ohci_hcd	*ohci = hcd_to_ohci(platform_get_drvdata(dev));
+	struct usb_hcd	*hcd = platform_get_drvdata(dev);
+	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -231,7 +231,8 @@ static int ohci_sm501_suspend(struct pla
 static int ohci_sm501_resume(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct ohci_hcd	*ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+	struct usb_hcd	*hcd = platform_get_drvdata(pdev);
+	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);

-- 

[patch 13/50] i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert

[Chris Wright]

[-- Attachment #1: i2c-nforce2-disable-the-second-smbus-channel-on-the-dfi-lanparty-nf4-expert.patch --]
[-- Type: text/plain, Size: 2439 bytes --]

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

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

commit 08851d6eb4eeb0894f4d095dfdf8ab61c435ad57 in upstream

There is a strange chip at 0x2e on the second SMBus channel of the
DFI Lanparty NF4 Expert motherboard. Accessing the chip reboots the
system. As there's nothing interesting on this SMBus channel, the
easiest and safest thing to do is to disable it on that board.

This is a better fix to bug #5889 than the it87 driver update that was
done originally:
http://bugzilla.kernel.org/show_bug.cgi?id=5889

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

---
 drivers/i2c/busses/i2c-nforce2.c |   28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

--- a/drivers/i2c/busses/i2c-nforce2.c
+++ b/drivers/i2c/busses/i2c-nforce2.c
@@ -50,6 +50,7 @@
 #include <linux/init.h>
 #include <linux/i2c.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <asm/io.h>
 
 MODULE_LICENSE("GPL");
@@ -109,6 +110,18 @@ struct nforce2_smbus {
 /* Misc definitions */
 #define MAX_TIMEOUT	100
 
+/* We disable the second SMBus channel on these boards */
+static struct dmi_system_id __devinitdata nforce2_dmi_blacklist2[] = {
+	{
+		.ident = "DFI Lanparty NF4 Expert",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "DFI Corp,LTD"),
+			DMI_MATCH(DMI_BOARD_NAME, "LP UT NF4 Expert"),
+		},
+	},
+	{ }
+};
+
 static struct pci_driver nforce2_driver;
 
 static void nforce2_abort(struct i2c_adapter *adap)
@@ -367,10 +380,17 @@ static int __devinit nforce2_probe(struc
 		smbuses[0].base = 0;	/* to have a check value */
 	}
 	/* SMBus adapter 2 */
-	res2 = nforce2_probe_smb(dev, 5, NFORCE_PCI_SMB2, &smbuses[1], "SMB2");
-	if (res2 < 0) {
-		dev_err(&dev->dev, "Error probing SMB2.\n");
-		smbuses[1].base = 0;	/* to have a check value */
+	if (dmi_check_system(nforce2_dmi_blacklist2)) {
+		dev_err(&dev->dev, "Disabling SMB2 for safety reasons.\n");
+		res2 = -EPERM;
+		smbuses[1].base = 0;
+	} else {
+		res2 = nforce2_probe_smb(dev, 5, NFORCE_PCI_SMB2, &smbuses[1],
+					 "SMB2");
+		if (res2 < 0) {
+			dev_err(&dev->dev, "Error probing SMB2.\n");
+			smbuses[1].base = 0;	/* to have a check value */
+		}
 	}
 	if ((res1 < 0) && (res2 < 0)) {
 		/* we did not find even one of the SMBuses, so we give up */

-- 

[patch 14/50] i2c/max6875: Really prevent 24RF08 corruption

[Chris Wright]

[-- Attachment #1: i2c-max6875-really-prevent-24rf08-corruption.patch --]
[-- Type: text/plain, Size: 1154 bytes --]

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

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

commit 70455e790391dac85d9b483a9e286a40df1ecc7f in upstream

i2c-core takes care of the possible corruption of 24RF08 chips for
quite some times, so device drivers no longer need to do it. And they
really should not, as applying the prevention twice voids it.

I thought that I had fixed all drivers long ago but apparently I had
missed that one.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Ben Gardner <bgardner@wabtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/i2c/chips/max6875.c |    3 ---
 1 file changed, 3 deletions(-)

--- a/drivers/i2c/chips/max6875.c
+++ b/drivers/i2c/chips/max6875.c
@@ -207,9 +207,6 @@ static int max6875_detect(struct i2c_ada
 	fake_client->flags = 0;
 	strlcpy(fake_client->name, "max6875 subclient", I2C_NAME_SIZE);
 
-	/* Prevent 24RF08 corruption (in case of user error) */
-	i2c_smbus_write_quick(real_client, 0);
-
 	if ((err = i2c_attach_client(real_client)) != 0)
 		goto exit_kfree2;
 

-- 

[patch 15/50] x86: user_regset_view table fix for ia32 on 64-bit

[Chris Wright]

[-- Attachment #1: x86-user_regset_view-table-fix-for-ia32-on-64-bit.patch --]
[-- Type: text/plain, Size: 1769 bytes --]

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

From: Roland McGrath <roland@redhat.com>

commit 1f465f4e475454b8bb590846c50a9d16e8046f3d upstream

The user_regset_view table for the 32-bit regsets on the 64-bit build had
the wrong sizes for the FP regsets.  This bug had no user-visible effect
(just on kernel modules using the user_regset interfaces and the like).
But the fix is trivial and risk-free.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 arch/x86/kernel/ptrace.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1382,6 +1382,9 @@ static const struct user_regset_view use
 #define genregs32_get		genregs_get
 #define genregs32_set		genregs_set
 
+#define user_i387_ia32_struct	user_i387_struct
+#define user32_fxsr_struct	user_fxsr_struct
+
 #endif	/* CONFIG_X86_64 */
 
 #if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
@@ -1394,13 +1397,13 @@ static const struct user_regset x86_32_r
 	},
 	[REGSET_FP] = {
 		.core_note_type = NT_PRFPREG,
-		.n = sizeof(struct user_i387_struct) / sizeof(u32),
+		.n = sizeof(struct user_i387_ia32_struct) / sizeof(u32),
 		.size = sizeof(u32), .align = sizeof(u32),
 		.active = fpregs_active, .get = fpregs_get, .set = fpregs_set
 	},
 	[REGSET_XFP] = {
 		.core_note_type = NT_PRXFPREG,
-		.n = sizeof(struct user_i387_struct) / sizeof(u32),
+		.n = sizeof(struct user32_fxsr_struct) / sizeof(u32),
 		.size = sizeof(u32), .align = sizeof(u32),
 		.active = xfpregs_active, .get = xfpregs_get, .set = xfpregs_set
 	},

-- 

[patch 16/50] i386: fix asm constraint in do_IRQ()

[Chris Wright]

[-- Attachment #1: i386-fix-asm-constraint-in-do_irq.patch --]
[-- Type: text/plain, Size: 893 bytes --]

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

From: Jan Beulich <jbeulich@novell.com>

upstream commit: 5065dbafc299507f16731434e95b91dadff03006

i386: fix asm constraint in do_IRQ()

Two prior changes resulted in the "ecx" clobber being lost.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/arch/x86/kernel/irq_32.c
+++ b/arch/x86/kernel/irq_32.c
@@ -134,7 +134,7 @@ unsigned int do_IRQ(struct pt_regs *regs
 			: "=a" (arg1), "=d" (arg2), "=b" (bx)
 			:  "0" (irq),   "1" (desc),  "2" (isp),
 			   "D" (desc->handle_irq)
-			: "memory", "cc"
+			: "memory", "cc", "ecx"
 		);
 	} else
 #endif

-- 

[patch 17/50] CIFS: Fix UNC path prefix on QueryUnixPathInfo to have correct slash

[Chris Wright]

[-- Attachment #1: cifs-fix-unc-path-prefix-on-queryunixpathinfo-to-have-correct-slash.patch --]
[-- Type: text/plain, Size: 2826 bytes --]

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

From: Steve French <sfrench@us.ibm.com>

upstream commit: 076d8423a98659a92837b07aa494cb74bfefe77c


When a share was in DFS and the server was Unix/Linux, we were sending paths of the form
    \\server\share/dir/file
rather than
    //server/share/dir/file

There was some discussion between me and jra over whether we should use
    /server/share/dir/file
as MS sometimes says - but the documentation for this claims it should be
doubleslash for this type of UNC-like path format and that works, so leaving
it as doubleslash but converting the \ to / in the the //server/share portion.

This gets Samba to now correctly return STATUS_PATH_NOT_COVERED when it is
supposed to (Windows already did since the direction of the slash was not an issue
for them).  Still need another minor change to fully enable DFS (need to finish
some chages to SMBGetDFSRefer

Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/cifs/inode.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -161,12 +161,14 @@ static void cifs_unix_info_to_inode(stru
 	spin_unlock(&inode->i_lock);
 }
 
-static const unsigned char *cifs_get_search_path(struct cifsTconInfo *pTcon,
-					const char *search_path)
+static const unsigned char *cifs_get_search_path(struct cifs_sb_info *cifs_sb,
+						const char *search_path)
 {
 	int tree_len;
 	int path_len;
+	int i;
 	char *tmp_path;
+	struct cifsTconInfo *pTcon = cifs_sb->tcon;
 
 	if (!(pTcon->Flags & SMB_SHARE_IS_IN_DFS))
 		return search_path;
@@ -180,6 +182,11 @@ static const unsigned char *cifs_get_sea
 		return search_path;
 
 	strncpy(tmp_path, pTcon->treeName, tree_len);
+	if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)
+		for (i = 0; i < tree_len; i++) {
+			if (tmp_path[i] == '\\')
+				tmp_path[i] = '/';
+		}
 	strncpy(tmp_path+tree_len, search_path, path_len);
 	tmp_path[tree_len+path_len] = 0;
 	return tmp_path;
@@ -199,7 +206,7 @@ int cifs_get_inode_info_unix(struct inod
 	pTcon = cifs_sb->tcon;
 	cFYI(1, ("Getting info on %s", search_path));
 
-	full_path = cifs_get_search_path(pTcon, search_path);
+	full_path = cifs_get_search_path(cifs_sb, search_path);
 
 try_again_CIFSSMBUnixQPathInfo:
 	/* could have done a find first instead but this returns more info */
@@ -402,7 +409,7 @@ int cifs_get_inode_info(struct inode **p
 			return -ENOMEM;
 		pfindData = (FILE_ALL_INFO *)buf;
 
-		full_path = cifs_get_search_path(pTcon, search_path);
+		full_path = cifs_get_search_path(cifs_sb, search_path);
 
 try_again_CIFSSMBQPathInfo:
 		/* could do find first instead but this returns more info */

-- 

[patch 18/50] USB: add TELIT HDSPA UC864-E modem to option driver

[Chris Wright]

[-- Attachment #1: usb-add-telit-hdspa-uc864-e-modem-to-option-driver.patch --]
[-- Type: text/plain, Size: 1523 bytes --]

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

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

upstream commit: ee53b0ca0153b4f944cb142b5e65c96a1860d765

This adds the Telit UC864-E HDSPA modem support to the option driver.
This lets their customers comply with the GPL instead of having to use a
binary driver from the manufacturer.

Cc: Simon Kissel <kissel@viprinet.com>
Cc: Nico Erfurth <ne@nicoerfurth.de>
Cc: Andrea Ghezzo <TS-EMEA@telit.com>
Cc: Dietmar Staps <Dietmar.Staps@telit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/usb/serial/option.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -193,6 +193,9 @@ static int  option_send_setup(struct usb
 
 #define MAXON_VENDOR_ID				0x16d8
 
+#define TELIT_VENDOR_ID				0x1bc7
+#define TELIT_PRODUCT_UC864E			0x1003
+
 static struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -300,6 +303,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
 	{ USB_DEVICE(MAXON_VENDOR_ID, 0x6280) }, /* BP3-USB & BP3-EXT HSDPA */
 	{ USB_DEVICE(0x19d2, 0x0001) }, 	/* Telstra NextG CDMA */
+	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UC864E) },
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

-- 

[patch 19/50] usb-serial: Use ftdi_sio driver for RATOC REX-USB60F

[Chris Wright]

[-- Attachment #1: usb-serial-use-ftdi_sio-driver-for-ratoc-rex-usb60f.patch --]
[-- Type: text/plain, Size: 2339 bytes --]

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

From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>

upstream commit: 26ab705396b65a469233a8327ecb51b8aebb6be0

This patch reverts 57833ea6b95a3995149f1f6d1a8d8862ab7a0ba2
("usb-serial: pl2303: add support for RATOC REX-USB60F") and adds
support for the device to ftdi_sio driver.

Cc: Akira Tsukamoto <akirat@rd.scei.sony.co.jp>
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/usb/serial/ftdi_sio.c |    1 +
 drivers/usb/serial/ftdi_sio.h |    6 ++++++
 drivers/usb/serial/pl2303.c   |    1 -
 drivers/usb/serial/pl2303.h   |    1 -
 4 files changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -366,6 +366,7 @@ static struct usb_device_id id_table_com
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
 	{ USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+	{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) },
 	{ },					/* Optional parameter entry */
 	{ }					/* Terminating entry */
 };
--- a/drivers/usb/serial/ftdi_sio.h
+++ b/drivers/usb/serial/ftdi_sio.h
@@ -581,6 +581,12 @@
 #define	FIC_NEO1973_DEBUG_PID	0x5118
 
 /*
+ * RATOC REX-USB60F
+ */
+#define RATOC_VENDOR_ID		0x0584
+#define RATOC_PRODUCT_ID_USB60F	0xb020
+
+/*
  *   BmRequestType:  1100 0000b
  *   bRequest:       FTDI_E2_READ
  *   wValue:         0
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -66,7 +66,6 @@ static struct usb_device_id id_table [] 
 	{ USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID_2080) },
 	{ USB_DEVICE(MA620_VENDOR_ID, MA620_PRODUCT_ID) },
 	{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID) },
-	{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) },
 	{ USB_DEVICE(TRIPP_VENDOR_ID, TRIPP_PRODUCT_ID) },
 	{ USB_DEVICE(RADIOSHACK_VENDOR_ID, RADIOSHACK_PRODUCT_ID) },
 	{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -36,7 +36,6 @@
 
 #define RATOC_VENDOR_ID		0x0584
 #define RATOC_PRODUCT_ID	0xb000
-#define RATOC_PRODUCT_ID_USB60F	0xb020
 
 #define TRIPP_VENDOR_ID		0x2478
 #define TRIPP_PRODUCT_ID	0x2008

-- 

[patch 20/50] cgroups: remove node_ prefix_from ns subsystem

[Chris Wright]

[-- Attachment #1: cgroups-remove-node_-prefix_from-ns-subsystem.patch --]
[-- Type: text/plain, Size: 2094 bytes --]

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

From: Cedric Le Goater <clg@fr.ibm.com>

upstream commit: 5c02b575780d0d785815a1e7b79a98edddee895a

This is a slight change in the namespace cgroup subsystem api.

The change is that previously when cgroup_clone() was called (currently
only from the unshare path in ns_proxy cgroup, you'd get a new group named
"node_$pid" whereas now you'll get a group named after just your pid.)

The only users who would notice it are those who are using the ns_proxy
cgroup subsystem to auto-create cgroups when namespaces are unshared -
something of an experimental feature, which I think really needs more
complete container/namespace support in order to be useful.  I suspect the
only users are Cedric and Serge, or maybe a few others on
containers@lists.linux-foundation.org.  And in fact it would only be
noticed by the users who make the assumption about how the name is
generated, rather than getting it from the /proc/<pid>/cgroups file for
the process in question.

Whether the change is actually needed or not I'm fairly agnostic on, but I
guess it is more elegant to just use the pid as the new group name rather
than adding a fairly arbitrary "node_" prefix on the front.

[menage@google.com: provided changelog]
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Cc: "Paul Menage" <menage@google.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 kernel/cgroup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2808,7 +2808,7 @@ int cgroup_clone(struct task_struct *tsk
 	cg = tsk->cgroups;
 	parent = task_cgroup(tsk, subsys->subsys_id);
 
-	snprintf(nodename, MAX_CGROUP_TYPE_NAMELEN, "node_%d", tsk->pid);
+	snprintf(nodename, MAX_CGROUP_TYPE_NAMELEN, "%d", tsk->pid);
 
 	/* Pin the hierarchy */
 	atomic_inc(&parent->root->sb->s_active);

-- 

[patch 21/50] brd: dont show ramdisks in /proc/partitions

[Chris Wright]

[-- Attachment #1: brd-don-t-show-ramdisks-in-proc-partitions.patch --]
[-- Type: text/plain, Size: 2258 bytes --]

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

From: Marcin Krol <hawk@pld-linux.org>

upstream commit: 53978d0a7a27eb036b9bf33c4caa06257a9dbed7

In 2.6.25, ramdisk devices show up in /proc/partitions, which is a
behaviour change from the old rd.c.  Add GENHD_FL_SUPPRESS_PARTITION_INFO,
which was present in rd.c.

All kernels prior to 2.6.25 weren't displaying ramdisks in
/proc/partitions.  Since there are many userspace tools using information
from /proc/partitions some of them may now behave incorrectly (I didn't
tested any though).  For example before 2.6.25 /proc/partitions was empty
if no block devices like hard disks and such were detected by kernel.  Now
all 16 ramdisks are always visible there.  Some software may rely on such
information (I mean, on empty /proc/partitions).

There was quite similar situation back in 2004, and ramdisks were excluded
back from displaying.  Thats why I called this a regression (maybe a bit
unfortunate).  See this patch for info:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch

I also think that someone somewhere (long time ago) excluded ramdisks from
/proc/partitions for good reasons.  It is possible that now such new
"feature" is harmless, but I think there are more chances that someone
will say "hey, /proc/partitions has changed, now my software doesn't work"
then "hey where did my new 2.6.25 feature go".  nbd devices are also
excluded, maybe for very same (unknown to me) reasons.

Signed-off-by: Marcin Krol <hawk@pld-linux.org>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/block/brd.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -442,6 +442,7 @@ static struct brd_device *brd_alloc(int 
 	disk->fops		= &brd_fops;
 	disk->private_data	= brd;
 	disk->queue		= brd->brd_queue;
+	disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
 	sprintf(disk->disk_name, "ram%d", i);
 	set_capacity(disk, rd_size * 2);
 

-- 

Re: [patch 21/50] brd: dont show ramdisks in /proc/partitions

[H. Peter Anvin]

Chris Wright wrote:
 > From: Marcin Krol <hawk@pld-linux.org>
 >
> I also think that someone somewhere (long time ago) excluded ramdisks from
> /proc/partitions for good reasons.  It is possible that now such new
> "feature" is harmless, but I think there are more chances that someone
> will say "hey, /proc/partitions has changed, now my software doesn't work"
> then "hey where did my new 2.6.25 feature go".  nbd devices are also
> excluded, maybe for very same (unknown to me) reasons.

This seems a bit like cargo cult programming to me.  If there isn't a 
known, good, reason to revert this behaviour change, I would consider it 
a bugfix, not a regression.

	-hpa

Re: [stable] [patch 21/50] brd: dont show ramdisks in /proc/partitions

[Chris Wright]

* H. Peter Anvin (hpa@kernel.org) wrote:
> This seems a bit like cargo cult programming to me.  If there isn't a 
> known, good, reason to revert this behaviour change, I would consider it 
> a bugfix, not a regression.

We have one /proc/partitions parser that got broken (never saw details
on how).  I don't care for this change either (esp. since nbd is still
left out...it's inconsistent).

This is now the upstream behaviour (obvious since it's a -stable
candidate), and the change was introduced in 2.6.25...I'd actually prefer
to drop this patch, but there's no good reason to deviate if upstream
keeps this one.  I can defer while upstream gets revisited, can you
revisit this upstream?

thanks,
-chris

Re: [stable] [patch 21/50] brd: dont show ramdisks in /proc/partitions

[Willy Tarreau]

On Mon, Jun 09, 2008 at 10:08:40AM -0700, Chris Wright wrote:
> * H. Peter Anvin (hpa@kernel.org) wrote:
> > This seems a bit like cargo cult programming to me.  If there isn't a 
> > known, good, reason to revert this behaviour change, I would consider it 
> > a bugfix, not a regression.
> 
> We have one /proc/partitions parser that got broken (never saw details
> on how).  I don't care for this change either (esp. since nbd is still
> left out...it's inconsistent).

I also had one of my old install scripts proposing me to choose between
16 ramdisks to install to. Quite bothering in fact. I'm not sure we
really can consider ramdisks as partitions. Also, all of them are listed,
whether they are initialized or not.

In fact, I was glad to see this "fixed" with this patch.

Regards,
willy

Re: [stable] [patch 21/50] brd: dont show ramdisks in /proc/partitions

[H. Peter Anvin]

Chris Wright wrote:
> * H. Peter Anvin (hpa@kernel.org) wrote:
>> This seems a bit like cargo cult programming to me.  If there isn't a 
>> known, good, reason to revert this behaviour change, I would consider it 
>> a bugfix, not a regression.
> 
> We have one /proc/partitions parser that got broken (never saw details
> on how).  I don't care for this change either (esp. since nbd is still
> left out...it's inconsistent).
> 
> This is now the upstream behaviour (obvious since it's a -stable
> candidate), and the change was introduced in 2.6.25...I'd actually prefer
> to drop this patch, but there's no good reason to deviate if upstream
> keeps this one.  I can defer while upstream gets revisited, can you
> revisit this upstream?

I had to ask Chris offline what he meant with this... basically, he and 
I both agree that absent hard evidence of malfunction, we should revert 
to 2.6.25 behaviour.

	-hpa

[patch 22/50] types.h: dont expose struct ustat to userspace

[Chris Wright]

[-- Attachment #1: types.h-don-t-expose-struct-ustat-to-userspace.patch --]
[-- Type: text/plain, Size: 1309 bytes --]

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

From: maximilian attems <max@stro.at>

upstream commit: 6c7c6afbb8c0e60d32a563cae7c6889211e9d9d8

<linux/types.h> can't be used together with <sys/ustat.h> because they
both define struct ustat:

    $ cat test.c
    #include <sys/ustat.h>
    #include <linux/types.h>
    $ gcc -c test.c
    In file included from test.c:2:
    /usr/include/linux/types.h:165: error: redefinition of 'struct ustat'

has been reported a while ago to debian, but seems to have been
lost in cat fighting: http://bugs.debian.org/429064

Signed-off-by: maximilian attems <max@stro.at>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 include/linux/types.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -197,8 +197,6 @@ typedef u64 resource_size_t;
 typedef u32 resource_size_t;
 #endif
 
-#endif	/* __KERNEL__ */
-
 struct ustat {
 	__kernel_daddr_t	f_tfree;
 	__kernel_ino_t		f_tinode;
@@ -206,4 +204,6 @@ struct ustat {
 	char			f_fpack[6];
 };
 
+#endif	/* __KERNEL__ */
+
 #endif /* _LINUX_TYPES_H */

-- 

[patch 23/50] x86: dont read maxlvt before checking if APIC is mapped

[Chris Wright]

[-- Attachment #1: x86-don-t-read-maxlvt-before-checking-if-apic-is-mapped.patch --]
[-- Type: text/plain, Size: 831 bytes --]

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

From: Chuck Ebbert <cebbert@redhat.com>

upstream commit: 2584a82deed7196f48066f1b1a7fad4ec5bea961

A check for unmapped apic was added before reading maxlvt but the early
read of maxlvt wasn't removed.

Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/apic_64.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -524,7 +524,7 @@ int setup_profiling_timer(unsigned int m
  */
 void clear_local_APIC(void)
 {
-	int maxlvt = lapic_get_maxlvt();
+	int maxlvt;
 	u32 v;
 
 	/* APIC hasn't been mapped yet */

-- 

[patch 24/50] IPoIB: Test for NULL broadcast object in ipiob_mcast_join_finish()

[Chris Wright]

[-- Attachment #1: ipoib-test-for-null-broadcast-object-in-ipiob_mcast_join_finish.patch --]
[-- Type: text/plain, Size: 1586 bytes --]

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

From: Jack Morgenstein <jackm@dev.mellanox.co.il>

upstream commit: e1d50dce5af77cb6d33555af70e2b8748dd84009

We saw a kernel oops in our regression testing when a multicast "join
finish" occurred just after the interface was -- this is
<https://bugs.openfabrics.org/show_bug.cgi?id=1040>.  The test
randomly causes the HCA physical port to go down then up.

The cause of this is that ipoib_mcast_join_finish() processing happen
just after ipoib_mcast_dev_flush() was invoked (in which case the
broadcast pointer is NULL).  This patch tests for and handles the case
where priv->broadcast is NULL.

Cc: <stable@kernel.org>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -194,7 +194,13 @@ static int ipoib_mcast_join_finish(struc
 	/* Set the cached Q_Key before we attach if it's the broadcast group */
 	if (!memcmp(mcast->mcmember.mgid.raw, priv->dev->broadcast + 4,
 		    sizeof (union ib_gid))) {
+		spin_lock_irq(&priv->lock);
+		if (!priv->broadcast) {
+			spin_unlock_irq(&priv->lock);
+			return -EAGAIN;
+		}
 		priv->qkey = be32_to_cpu(priv->broadcast->mcmember.qkey);
+		spin_unlock_irq(&priv->lock);
 		priv->tx_wr.wr.ud.remote_qkey = priv->qkey;
 	}
 

-- 

[patch 25/50] x86: fix setup of cyc2ns in tsc_64.c

[Chris Wright]

[-- Attachment #1: x86-fix-setup-of-cyc2ns-in-tsc_64.c.patch --]
[-- Type: text/plain, Size: 1576 bytes --]

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

From: Thomas Gleixner <tglx@linutronix.de>

upstream commit: b6db80ee1331e7beaeb91b4b3d946dd16c72e388

When the TSC is calibrated against the PIT due to the nonavailability
of PMTIMER/HPET or due to SMI interference then the setup of the per
CPU cyc2ns variables is skipped. This is unlikely to happen but it
would definitely render sched_clock() unusable.

This was introduced with commit 53d517cdbaac704352b3d0c10fecb99e0b54572e

    x86: scale cyc_2_nsec according to CPU frequency

Update the per CPU cyc2ns variables in all exit pathes of tsc_calibrate.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/tsc_64.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/tsc_64.c
+++ b/arch/x86/kernel/tsc_64.c
@@ -227,14 +227,14 @@ void __init tsc_calibrate(void)
 	/* hpet or pmtimer available ? */
 	if (!hpet && !pm1 && !pm2) {
 		printk(KERN_INFO "TSC calibrated against PIT\n");
-		return;
+		goto out;
 	}
 
 	/* Check, whether the sampling was disturbed by an SMI */
 	if (tsc1 == ULONG_MAX || tsc2 == ULONG_MAX) {
 		printk(KERN_WARNING "TSC calibration disturbed by SMI, "
 		       "using PIT calibration result\n");
-		return;
+		goto out;
 	}
 
 	tsc2 = (tsc2 - tsc1) * 1000000L;
@@ -255,6 +255,7 @@ void __init tsc_calibrate(void)
 
 	tsc_khz = tsc2 / tsc1;
 
+out:
 	for_each_possible_cpu(cpu)
 		set_cyc2ns_scale(tsc_khz, cpu);
 }

-- 

[patch 26/50] x86: if we cannot calibrate the TSC, we panic.

[Chris Wright]

[-- Attachment #1: x86-if-we-cannot-calibrate-the-tsc-we-panic.patch --]
[-- Type: text/plain, Size: 1634 bytes --]

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

From: Rusty Russell <rusty@rustcorp.com.au>

upstream commit: 3c2047cd32b1a8c782d7efab72707e7daa251625

The current tsc_init() clears the TSC feature bit if the TSC khz
cannot be calculated, causing us to panic in
arch/x86/kernel/cpu/bugs.c check_config().  We should simply mark it
unstable.

Frankly, someone should take an axe to this code.  mark_tsc_unstable()
not only marks it unstable, but sets tsc_enabled to 0, which seems
redundant but is actually important here because means it won't be
used by sched_clock() either.  Perhaps a tristate enum "UNUSABLE,
UNSTABLE, OK" would be clearer, and separate mark_tsc_unstable() and
mark_tsc_broken() functions?

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/tsc_32.c |   13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

--- a/arch/x86/kernel/tsc_32.c
+++ b/arch/x86/kernel/tsc_32.c
@@ -392,13 +392,15 @@ void __init tsc_init(void)
 	int cpu;
 
 	if (!cpu_has_tsc)
-		goto out_no_tsc;
+		return;
 
 	cpu_khz = calculate_cpu_khz();
 	tsc_khz = cpu_khz;
 
-	if (!cpu_khz)
-		goto out_no_tsc;
+	if (!cpu_khz) {
+		mark_tsc_unstable("could not calculate TSC khz");
+		return;
+	}
 
 	printk("Detected %lu.%03lu MHz processor.\n",
 				(unsigned long)cpu_khz / 1000,
@@ -431,9 +433,4 @@ void __init tsc_init(void)
 		tsc_enabled = 1;
 
 	clocksource_register(&clocksource_tsc);
-
-	return;
-
-out_no_tsc:
-	setup_clear_cpu_cap(X86_FEATURE_TSC);
 }

-- 

[patch 27/50] x86: distangle user disabled TSC from unstable

[Chris Wright]

[-- Attachment #1: x86-distangle-user-disabled-tsc-from-unstable.patch --]
[-- Type: text/plain, Size: 2659 bytes --]

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

From: Thomas Gleixner <tglx@linutronix.de>

upstream commit: 9ccc906c97e34fd91dc6aaf5b69b52d824386910

tsc_enabled is set to 0 from the command line switch "notsc" and from
the mark_tsc_unstable code. Seperate those functionalities and replace
tsc_enable with tsc_disable. This makes also the native_sched_clock()
decision when to use TSC understandable.

Preparatory patch to solve the sched_clock() issue on 32 bit.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/tsc_32.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

--- a/arch/x86/kernel/tsc_32.c
+++ b/arch/x86/kernel/tsc_32.c
@@ -14,7 +14,7 @@
 
 #include "mach_timer.h"
 
-static int tsc_enabled;
+static int tsc_disabled;
 
 /*
  * On some systems the TSC frequency does not
@@ -28,8 +28,8 @@ EXPORT_SYMBOL_GPL(tsc_khz);
 static int __init tsc_setup(char *str)
 {
 	printk(KERN_WARNING "notsc: Kernel compiled with CONFIG_X86_TSC, "
-				"cannot disable TSC completely.\n");
-	mark_tsc_unstable("user disabled TSC");
+	       "cannot disable TSC completely.\n");
+	tsc_disabled = 1;
 	return 1;
 }
 #else
@@ -121,7 +121,7 @@ unsigned long long native_sched_clock(vo
 	 *   very important for it to be as fast as the platform
 	 *   can achive it. )
 	 */
-	if (unlikely(!tsc_enabled && !tsc_unstable))
+	if (unlikely(tsc_disabled))
 		/* No locking but a rare wrong value is not a big deal: */
 		return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
 
@@ -310,7 +310,6 @@ void mark_tsc_unstable(char *reason)
 {
 	if (!tsc_unstable) {
 		tsc_unstable = 1;
-		tsc_enabled = 0;
 		printk("Marking TSC unstable due to: %s.\n", reason);
 		/* Can be called before registration */
 		if (clocksource_tsc.mult)
@@ -324,7 +323,7 @@ EXPORT_SYMBOL_GPL(mark_tsc_unstable);
 static int __init dmi_mark_tsc_unstable(const struct dmi_system_id *d)
 {
 	printk(KERN_NOTICE "%s detected: marking TSC unstable.\n",
-		       d->ident);
+	       d->ident);
 	tsc_unstable = 1;
 	return 0;
 }
@@ -391,8 +390,11 @@ void __init tsc_init(void)
 {
 	int cpu;
 
-	if (!cpu_has_tsc)
+	if (!cpu_has_tsc || tsc_disabled) {
+		/* Disable the TSC in case of !cpu_has_tsc */
+		tsc_disabled = 1;
 		return;
+	}
 
 	cpu_khz = calculate_cpu_khz();
 	tsc_khz = cpu_khz;
@@ -429,8 +431,6 @@ void __init tsc_init(void)
 	if (check_tsc_unstable()) {
 		clocksource_tsc.rating = 0;
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
-	} else
-		tsc_enabled = 1;
-
+	}
 	clocksource_register(&clocksource_tsc);
 }

-- 

[patch 28/50] x86: disable TSC for sched_clock() when calibration failed

[Chris Wright]

[-- Attachment #1: x86-disable-tsc-for-sched_clock-when-calibration-failed.patch --]
[-- Type: text/plain, Size: 851 bytes --]

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

From: Thomas Gleixner <tglx@linutronix.de>

upstream commit: 74dc51a3de06aa516e3b9fdc4017b2aeb38bf44b

When the TSC calibration fails then TSC is still used in
sched_clock(). Disable it completely in that case.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/tsc_32.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/arch/x86/kernel/tsc_32.c
+++ b/arch/x86/kernel/tsc_32.c
@@ -401,6 +401,11 @@ void __init tsc_init(void)
 
 	if (!cpu_khz) {
 		mark_tsc_unstable("could not calculate TSC khz");
+		/*
+		 * We need to disable the TSC completely in this case
+		 * to prevent sched_clock() from using it.
+		 */
+		tsc_disabled = 1;
 		return;
 	}
 

-- 

[patch 29/50] XFS: Fix memory corruption with small buffer reads

[Chris Wright]

[-- Attachment #1: xfs-fix-memory-corruption-with-small-buffer-reads.patch --]
[-- Type: text/plain, Size: 4301 bytes --]

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

From: Christoph Hellwig <hch@infradead.org>

upstream commit: 6ab455eeaff6893cd06da33843e840d888cdc04a

When we have multiple buffers in a single page for a blocksize == pagesize
filesystem we might overwrite the page contents if two callers hit it
shortly after each other. To prevent that we need to keep the page locked
until I/O is completed and the page marked uptodate.

Thanks to Eric Sandeen for triaging this bug and finding a reproducible
testcase and Dave Chinner for additional advice.

This should fix kernel.org bz #10421.

Tested-by: Eric Sandeen <sandeen@sandeen.net>

SGI-PV: 981813
SGI-Modid: xfs-linux-melb:xfs-kern:31173a

Signed-off-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/xfs/linux-2.6/xfs_buf.c |   24 ++++++++++++++++++++----
 fs/xfs/linux-2.6/xfs_buf.h |   19 +++++++++++++++++++
 2 files changed, 39 insertions(+), 4 deletions(-)

--- a/fs/xfs/linux-2.6/xfs_buf.c
+++ b/fs/xfs/linux-2.6/xfs_buf.c
@@ -387,6 +387,8 @@ _xfs_buf_lookup_pages(
 		if (unlikely(page == NULL)) {
 			if (flags & XBF_READ_AHEAD) {
 				bp->b_page_count = i;
+				for (i = 0; i < bp->b_page_count; i++)
+					unlock_page(bp->b_pages[i]);
 				return -ENOMEM;
 			}
 
@@ -416,17 +418,24 @@ _xfs_buf_lookup_pages(
 		ASSERT(!PagePrivate(page));
 		if (!PageUptodate(page)) {
 			page_count--;
-			if (blocksize < PAGE_CACHE_SIZE && !PagePrivate(page)) {
+			if (blocksize >= PAGE_CACHE_SIZE) {
+				if (flags & XBF_READ)
+					bp->b_flags |= _XBF_PAGE_LOCKED;
+			} else if (!PagePrivate(page)) {
 				if (test_page_region(page, offset, nbytes))
 					page_count++;
 			}
 		}
 
-		unlock_page(page);
 		bp->b_pages[i] = page;
 		offset = 0;
 	}
 
+	if (!(bp->b_flags & _XBF_PAGE_LOCKED)) {
+		for (i = 0; i < bp->b_page_count; i++)
+			unlock_page(bp->b_pages[i]);
+	}
+
 	if (page_count == bp->b_page_count)
 		bp->b_flags |= XBF_DONE;
 
@@ -746,6 +755,7 @@ xfs_buf_associate_memory(
 	bp->b_count_desired = len;
 	bp->b_buffer_length = buflen;
 	bp->b_flags |= XBF_MAPPED;
+	bp->b_flags &= ~_XBF_PAGE_LOCKED;
 
 	return 0;
 }
@@ -1093,8 +1103,10 @@ _xfs_buf_ioend(
 	xfs_buf_t		*bp,
 	int			schedule)
 {
-	if (atomic_dec_and_test(&bp->b_io_remaining) == 1)
+	if (atomic_dec_and_test(&bp->b_io_remaining) == 1) {
+		bp->b_flags &= ~_XBF_PAGE_LOCKED;
 		xfs_buf_ioend(bp, schedule);
+	}
 }
 
 STATIC void
@@ -1125,6 +1137,9 @@ xfs_buf_bio_end_io(
 
 		if (--bvec >= bio->bi_io_vec)
 			prefetchw(&bvec->bv_page->flags);
+
+		if (bp->b_flags & _XBF_PAGE_LOCKED)
+			unlock_page(page);
 	} while (bvec >= bio->bi_io_vec);
 
 	_xfs_buf_ioend(bp, 1);
@@ -1163,7 +1178,8 @@ _xfs_buf_ioapply(
 	 * filesystem block size is not smaller than the page size.
 	 */
 	if ((bp->b_buffer_length < PAGE_CACHE_SIZE) &&
-	    (bp->b_flags & XBF_READ) &&
+	    ((bp->b_flags & (XBF_READ|_XBF_PAGE_LOCKED)) ==
+	      (XBF_READ|_XBF_PAGE_LOCKED)) &&
 	    (blocksize >= PAGE_CACHE_SIZE)) {
 		bio = bio_alloc(GFP_NOIO, 1);
 
--- a/fs/xfs/linux-2.6/xfs_buf.h
+++ b/fs/xfs/linux-2.6/xfs_buf.h
@@ -66,6 +66,25 @@ typedef enum {
 	_XBF_PAGES = (1 << 18),	    /* backed by refcounted pages	   */
 	_XBF_RUN_QUEUES = (1 << 19),/* run block device task queue	   */
 	_XBF_DELWRI_Q = (1 << 21),   /* buffer on delwri queue		   */
+
+	/*
+	 * Special flag for supporting metadata blocks smaller than a FSB.
+	 *
+	 * In this case we can have multiple xfs_buf_t on a single page and
+	 * need to lock out concurrent xfs_buf_t readers as they only
+	 * serialise access to the buffer.
+	 *
+	 * If the FSB size >= PAGE_CACHE_SIZE case, we have no serialisation
+	 * between reads of the page. Hence we can have one thread read the
+	 * page and modify it, but then race with another thread that thinks
+	 * the page is not up-to-date and hence reads it again.
+	 *
+	 * The result is that the first modifcation to the page is lost.
+	 * This sort of AGF/AGI reading race can happen when unlinking inodes
+	 * that require truncation and results in the AGI unlinked list
+	 * modifications being lost.
+	 */
+	_XBF_PAGE_LOCKED = (1 << 22),
 } xfs_buf_flags_t;
 
 typedef enum {

-- 

[patch 30/50] x86: prevent PGE flush from interruption/preemption

[Chris Wright]

[-- Attachment #1: x86-prevent-pge-flush-from-interruption-preemption.patch --]
[-- Type: text/plain, Size: 1642 bytes --]

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

From: Ingo Molnar <mingo@elte.hu>

upstream commit: b1979a5fda7869a790f4fd83fb06c78498d26ba1

CR4 manipulation is not protected against interrupts and preemption,
but KVM uses smp_function_call to manipulate the X86_CR4_VMXE bit
either from the CPU hotplug code or from the kvm_init call.

We need to protect the CR4 manipulation from both interrupts and
preemption.

Original bug report: http://lkml.org/lkml/2008/5/7/48
Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=10642

This is not a regression from 2.6.25, it's a long standing and hard to
trigger bug.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 include/asm-x86/tlbflush.h |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

--- a/include/asm-x86/tlbflush.h
+++ b/include/asm-x86/tlbflush.h
@@ -22,12 +22,23 @@ static inline void __native_flush_tlb(vo
 
 static inline void __native_flush_tlb_global(void)
 {
-	unsigned long cr4 = read_cr4();
+	unsigned long flags;
+	unsigned long cr4;
 
+	/*
+	 * Read-modify-write to CR4 - protect it from preemption and
+	 * from interrupts. (Use the raw variant because this code can
+	 * be called from deep inside debugging code.)
+	 */
+	raw_local_irq_save(flags);
+
+	cr4 = read_cr4();
 	/* clear PGE */
 	write_cr4(cr4 & ~X86_CR4_PGE);
 	/* write old PGE again and flush TLBs */
 	write_cr4(cr4);
+
+	raw_local_irq_restore(flags);
 }
 
 static inline void __native_flush_tlb_single(unsigned long addr)

-- 

[patch 31/50] Revert "PCI: remove default PCI expansion ROM memory allocation"

[Chris Wright]

[-- Attachment #1: revert-pci-remove-default-pci-expansion-rom-memory-allocation.patch --]
[-- Type: text/plain, Size: 1892 bytes --]

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

From: Linus Torvalds <torvalds@linux-foundation.org>

upstream commit: 8d539108560ec121d59eee05160236488266221c

This reverts commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e, which was
reported to break X startup (xf86-video-ati-6.8.0). See

	http://bugs.freedesktop.org/show_bug.cgi?id=15523

for details.

Reported-by: Laurence Withers <l@lwithers.me.uk>
Cc: Gary Hade <garyhade@us.ibm.com>
Cc: Greg KH <greg@kroah.com>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[cebbert@redhat.com: backport, remove first hunk to make port easier]
[chrisw@sous-sol.org: add back first hunk]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/pci/common.c |   17 -----------------
 1 file changed, 17 deletions(-)

--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -130,19 +130,6 @@ static void __devinit pcibios_fixup_ghos
 	}
 }
 
-static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
-{
-	struct resource *rom_r = &dev->resource[PCI_ROM_RESOURCE];
-
-	if (rom_r->parent)
-		return;
-	if (rom_r->start)
-		/* we deal with BIOS assigned ROM later */
-		return;
-	if (!(pci_probe & PCI_ASSIGN_ROMS))
-		rom_r->start = rom_r->end = rom_r->flags = 0;
-}
-
 /*
  *  Called after each bus is probed, but before its children
  *  are examined.
@@ -150,12 +137,8 @@ static void __devinit pcibios_fixup_devi
 
 void __devinit  pcibios_fixup_bus(struct pci_bus *b)
 {
-	struct pci_dev *dev;
-
 	pcibios_fixup_ghosts(b);
 	pci_read_bridge_bases(b);
-	list_for_each_entry(dev, &b->devices, bus_list)
-		pcibios_fixup_device_resources(dev);
 }
 
 /*

-- 

[patch 32/50] PS3: gelic: fix memory leak

[Chris Wright]

[-- Attachment #1: ps3-gelic-fix-memory-leak.patch --]
[-- Type: text/plain, Size: 869 bytes --]

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

From: Masakazu Mokuno <mokuno@sm.sony.co.jp>

upstream commit: 6fc7431dc0775f21ad7a7a39c2ad0290291a56ea

This fixes the bug that the I/O buffer is not freed at the driver removal.

Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/net/ps3_gelic_wireless.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/net/ps3_gelic_wireless.c
+++ b/drivers/net/ps3_gelic_wireless.c
@@ -2474,6 +2474,8 @@ static void gelic_wl_free(struct gelic_w
 
 	pr_debug("%s: <-\n", __func__);
 
+	free_page((unsigned long)wl->buf);
+
 	pr_debug("%s: destroy queues\n", __func__);
 	destroy_workqueue(wl->eurus_cmd_queue);
 	destroy_workqueue(wl->event_queue);

-- 

[patch 33/50] netfilter: xt_iprange: module aliases for xt_iprange

[Chris Wright]

[-- Attachment #1: netfilter-xt_iprange-module-aliases-for-xt_iprange.patch --]
[-- Type: text/plain, Size: 1094 bytes --]

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

From: Phil Oester <kernel@linuxace.com>

upstream commit: 01b7a314291b2ef56ad718ee1374a1bac4768b29 

Using iptables 1.3.8 with kernel 2.6.25, rules which include '-m
iprange' don't automatically pull in xt_iprange module.  Below patch
adds module aliases to fix that.  Patch against latest -git, but seems
like a good candidate for -stable also.

Signed-off-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 net/netfilter/xt_iprange.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/net/netfilter/xt_iprange.c
+++ b/net/netfilter/xt_iprange.c
@@ -179,3 +179,5 @@ module_exit(iprange_mt_exit);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>, Jan Engelhardt <jengelh@computergmbh.de>");
 MODULE_DESCRIPTION("Xtables: arbitrary IPv4 range matching");
+MODULE_ALIAS("ipt_iprange");
+MODULE_ALIAS("ip6t_iprange");

-- 

[patch 34/50] HID: split Numlock emulation quirk from HID_QUIRK_APPLE_HAS_FN.

[Chris Wright]

[-- Attachment #1: hid-split-numlock-emulation-quirk-from-hid_quirk_apple_has_fn.patch --]
[-- Type: text/plain, Size: 7929 bytes --]

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

From: Diego 'Flameeyes' Petteno <flameeyes@gmail.com>

upstream commit: 6e7045990f35ef9250804b3fd85e855b8c2aaeb6.

[jkosina@suse.cz: Needed to fix apple aluminium keyboard regression]

Since 2.6.25 the HID_QUIRK_APPLE_HAS_FN quirk is enabled even for
non-laptop Apple keyboards of the Aluminium series. The USB version of
these don't need Numlock emulation, like the laptop (and Aluminium
Wireless) do, as they have a proper keypad.

This patch splits the Numlock emulation for Apple keyboards in a
different quirk flag, so that it can be enabled for all the keyboards
but the Aluminium USB ones.

If the Numlock emulation is enabled for Aluminium USB keyboards, the
JKL and UIO keys become the numeric pad, and the rest of the keyboard
is disabled, included the key used to disable Numlock.

Additionally, these keyboard should not have a Numlock at all, as the
Numlock key is instead replaced by the 'Clear' key as usual for Apple
USB keyboards.

Signed-off-by: Diego 'Flameeyes' Petteno <flameeyes@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/hid/hid-input.c         |    5 +++--
 drivers/hid/usbhid/hid-quirks.c |   38 +++++++++++++++++++-------------------
 include/linux/hid.h             |    1 +
 3 files changed, 23 insertions(+), 21 deletions(-)

--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -218,8 +218,9 @@ int hidinput_apple_event(struct hid_devi
 			}
 		}
 
-		if (test_bit(usage->code, hid->pb_pressed_numlock) ||
-				test_bit(LED_NUML, input->led)) {
+		if (hid->quirks & HID_QUIRK_APPLE_NUMLOCK_EMULATION && (
+				test_bit(usage->code, hid->pb_pressed_numlock) ||
+				test_bit(LED_NUML, input->led))) {
 			trans = find_translation(powerbook_numlock_keys, usage->code);
 
 			if (trans) {
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -613,28 +613,28 @@ static const struct hid_blacklist {
 
 	{ USB_VENDOR_ID_WISEGROUP_LTD, USB_DEVICE_ID_SMARTJOY_DUAL_PLUS, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD},
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD},
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD},
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD},
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD},
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD},
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
 	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI, HID_QUIRK_APPLE_HAS_FN },
 	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD },
 	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS, HID_QUIRK_APPLE_HAS_FN },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI, HID_QUIRK_APPLE_HAS_FN },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS, HID_QUIRK_APPLE_HAS_FN },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
 
 	{ USB_VENDOR_ID_DELL, USB_DEVICE_ID_DELL_W7658, HID_QUIRK_RESET_LEDS },
 	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KBD, HID_QUIRK_RESET_LEDS },
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -284,6 +284,7 @@ struct hid_item {
 #define HID_QUIRK_2WHEEL_MOUSE_HACK_B8		0x02000000
 #define HID_QUIRK_HWHEEL_WHEEL_INVERT		0x04000000
 #define HID_QUIRK_MICROSOFT_KEYS		0x08000000
+#define HID_QUIRK_APPLE_NUMLOCK_EMULATION	0x10000000
 
 /*
  * Separate quirks for runtime report descriptor fixup

-- 

[patch 35/50] CPUFREQ: Make acpi-cpufreq more robust against BIOS freq changes behind our back.

[Chris Wright]

[-- Attachment #1: make-acpi-cpufreq-more-robust-against-bios-freq-changes-behind-our-back.patch --]
[-- Type: text/plain, Size: 1483 bytes --]

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

From: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

upstream commit: e56a727b023d40d1adf660168883f30f2e6abe0a

We checked the hardware freq with OS cached freq value in get_cur_freqon_cpu().

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: "Anthony L. Awtrey" <tony@awtrey.com>
[chrisw: backport to 2.6.25.4]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -339,6 +339,7 @@ static unsigned int get_cur_freq_on_cpu(
 {
 	struct acpi_cpufreq_data *data = per_cpu(drv_data, cpu);
 	unsigned int freq;
+	unsigned int cached_freq;
 
 	dprintk("get_cur_freq_on_cpu (%d)\n", cpu);
 
@@ -347,7 +348,16 @@ static unsigned int get_cur_freq_on_cpu(
 		return 0;
 	}
 
+	cached_freq = data->freq_table[data->acpi_data->state].frequency;
 	freq = extract_freq(get_cur_val(cpumask_of_cpu(cpu)), data);
+	if (freq != cached_freq) {
+		/*
+		 * The dreaded BIOS frequency change behind our back.
+		 * Force set the frequency on next target call.
+		 */
+		data->resume = 1;
+	}
+
 	dprintk("cur freq = %u\n", freq);
 
 	return freq;

-- 

[patch 36/50] x86, fpu: fix CONFIG_PREEMPT=y corruption of applications FPU stack

[Chris Wright]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: x86-fpu-fix-config_preempt-y-corruption-of-application-s-fpu-stack.patch --]
[-- Type: text/plain, Size: 2844 bytes --]

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

From: Suresh Siddha <suresh.b.siddha@intel.com>

upstream commit: 870568b39064cab2dd971fe57969916036982862

Jürgen Mell reported an FPU state corruption bug under CONFIG_PREEMPT,
and bisected it to commit v2.6.19-1363-gacc2076, "i386: add sleazy FPU
optimization".

Add tsk_used_math() checks to prevent calling math_state_restore()
which can sleep in the case of !tsk_used_math(). This prevents
making a blocking call in __switch_to().

Apparently "fpu_counter > 5" check is not enough, as in some signal handling
and fork/exec scenarios, fpu_counter > 5 and !tsk_used_math() is possible.

It's a side effect though. This is the failing scenario:

process 'A' in save_i387_ia32() just after clear_used_math()

Got an interrupt and pre-empted out.

At the next context switch to process 'A' again, kernel tries to restore
the math state proactively and sees a fpu_counter > 0 and !tsk_used_math()

This results in init_fpu() during the __switch_to()'s math_state_restore()

And resulting in fpu corruption which will be saved/restored
(save_i387_fxsave and restore_i387_fxsave) during the remaining
part of the signal handling after the context switch.

Bisected-by: Jürgen Mell <j.mell@t-online.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Tested-by: Jürgen Mell <j.mell@t-online.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86/kernel/process_32.c |    5 ++++-
 arch/x86/kernel/process_64.c |    5 ++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -710,8 +710,11 @@ struct task_struct * __switch_to(struct 
 	/* If the task has used fpu the last 5 timeslices, just do a full
 	 * restore of the math state immediately to avoid the trap; the
 	 * chances of needing FPU soon are obviously high now
+	 *
+	 * tsk_used_math() checks prevent calling math_state_restore(),
+	 * which can sleep in the case of !tsk_used_math()
 	 */
-	if (next_p->fpu_counter > 5)
+	if (tsk_used_math(next_p) && next_p->fpu_counter > 5)
 		math_state_restore();
 
 	/*
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -696,8 +696,11 @@ __switch_to(struct task_struct *prev_p, 
 	/* If the task has used fpu the last 5 timeslices, just do a full
 	 * restore of the math state immediately to avoid the trap; the
 	 * chances of needing FPU soon are obviously high now
+	 *
+	 * tsk_used_math() checks prevent calling math_state_restore(),
+	 * which can sleep in the case of !tsk_used_math()
 	 */
-	if (next_p->fpu_counter>5)
+	if (tsk_used_math(next_p) && next_p->fpu_counter > 5)
 		math_state_restore();
 	return prev_p;
 }

-- 

[patch 37/50] netfilter: nf_conntrack_expect: fix error path unwind in nf_conntrack_expect_init()

[Chris Wright]

[-- Attachment #1: netfilter-nf_conntrack_expect-fix-error-path-unwind-in-nf_conntrack_expect_init.patch --]
[-- Type: text/plain, Size: 900 bytes --]

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

From: Patrick McHardy <kaber@trash.net>

upstream commit: 12293bf91126ad253a25e2840b307fdc7c2754c3

Signed-off-by: Alexey Dobriyan <adobriyan@parallels.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

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

--- a/net/netfilter/nf_conntrack_expect.c
+++ b/net/netfilter/nf_conntrack_expect.c
@@ -550,10 +550,10 @@ int __init nf_conntrack_expect_init(void
 	return 0;
 
 err3:
+	kmem_cache_destroy(nf_ct_expect_cachep);
+err2:
 	nf_ct_free_hashtable(nf_ct_expect_hash, nf_ct_expect_vmalloc,
 			     nf_ct_expect_hsize);
-err2:
-	kmem_cache_destroy(nf_ct_expect_cachep);
 err1:
 	return err;
 }

-- 

[patch 38/50] netfilter: xt_connlimit: fix accouning when receive RST packet in ESTABLISHED state

[Chris Wright]

[-- Attachment #1: netfilter-xt_connlimit-fix-accouning-when-receive-rst-packet-in-established-state.patch --]
[-- Type: text/plain, Size: 1313 bytes --]

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

From: Patrick McHardy <kaber@trash.net>

upstream commit: d2ee3f2c4b1db1320c1efb4dcaceeaf6c7e6c2d3

In xt_connlimit match module, the counter of an IP is decreased when
the TCP packet is go through the chain with ip_conntrack state TW.
Well, it's very natural that the server and client close the socket
with FIN packet. But when the client/server close the socket with RST
packet(using so_linger), the counter for this connection still exsit.
The following patch can fix it which is based on linux-2.6.25.4

Signed-off-by: Dong Wei <dwei.zh@gmail.com>
Acked-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

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

--- a/net/netfilter/xt_connlimit.c
+++ b/net/netfilter/xt_connlimit.c
@@ -75,7 +75,8 @@ static inline bool already_closed(const 
 	u_int16_t proto = conn->tuplehash[0].tuple.dst.protonum;
 
 	if (proto == IPPROTO_TCP)
-		return conn->proto.tcp.state == TCP_CONNTRACK_TIME_WAIT;
+		return conn->proto.tcp.state == TCP_CONNTRACK_TIME_WAIT ||
+		       conn->proto.tcp.state == TCP_CONNTRACK_CLOSE;
 	else
 		return 0;
 }

-- 

[patch 39/50] netfilter: nf_conntrack_ipv6: fix inconsistent lock state in nf_ct_frag6_gather()

[Chris Wright]

[-- Attachment #1: netfilter-nf_conntrack_ipv6-fix-inconsistent-lock-state-in-nf_ct_frag6_gather.patch --]
[-- Type: text/plain, Size: 2320 bytes --]

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

From: Patrick McHardy <kaber@trash.net>

upstream commit: b9c698964614f71b9c8afeca163a945b4c2e2d20

[   63.531438] =================================
[   63.531520] [ INFO: inconsistent lock state ]
[   63.531520] 2.6.26-rc4 #7
[   63.531520] ---------------------------------
[   63.531520] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
[   63.531520] tcpsic6/3864 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   63.531520]  (&q->lock#2){-+..}, at: [<c07175b0>] ipv6_frag_rcv+0xd0/0xbd0
[   63.531520] {softirq-on-W} state was registered at:
[   63.531520]   [<c0143bba>] __lock_acquire+0x3aa/0x1080
[   63.531520]   [<c0144906>] lock_acquire+0x76/0xa0
[   63.531520]   [<c07a8f0b>] _spin_lock+0x2b/0x40
[   63.531520]   [<c0727636>] nf_ct_frag6_gather+0x3f6/0x910
 ...

According to this and another similar lockdep report inet_fragment
locks are taken from nf_ct_frag6_gather() with softirqs enabled, but
these locks are mainly used in softirq context, so disabling BHs is
necessary.

Reported-and-tested-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 net/ipv6/netfilter/nf_conntrack_reasm.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -209,7 +209,9 @@ fq_find(__be32 id, struct in6_addr *src,
 	arg.dst = dst;
 	hash = ip6qhashfn(id, src, dst);
 
+	local_bh_disable();
 	q = inet_frag_find(&nf_init_frags, &nf_frags, &arg, hash);
+	local_bh_enable();
 	if (q == NULL)
 		goto oom;
 
@@ -638,10 +640,10 @@ struct sk_buff *nf_ct_frag6_gather(struc
 		goto ret_orig;
 	}
 
-	spin_lock(&fq->q.lock);
+	spin_lock_bh(&fq->q.lock);
 
 	if (nf_ct_frag6_queue(fq, clone, fhdr, nhoff) < 0) {
-		spin_unlock(&fq->q.lock);
+		spin_unlock_bh(&fq->q.lock);
 		pr_debug("Can't insert skb to queue\n");
 		fq_put(fq);
 		goto ret_orig;
@@ -652,7 +654,7 @@ struct sk_buff *nf_ct_frag6_gather(struc
 		if (ret_skb == NULL)
 			pr_debug("Can't reassemble fragmented packets\n");
 	}
-	spin_unlock(&fq->q.lock);
+	spin_unlock_bh(&fq->q.lock);
 
 	fq_put(fq);
 	return ret_skb;

-- 

[patch 40/50] atl1: fix 4G memory corruption bug

[Chris Wright]

[-- Attachment #1: atl1-fix-4g-memory-corruption-bug.patch --]
[-- Type: text/plain, Size: 1185 bytes --]

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

From: Alexey Dobriyan <adobriyan@gmail.com>

upstream commit: aefdbf1a3b832a580a50cf3d1dcbb717be7cbdbe

When using 4+ GB RAM and SWIOTLB is active, the driver corrupts
memory by writing an skb after the relevant DMA page has been
unmapped.  Although this doesn't happen when *not* using bounce
buffers, clearing the pointer to the DMA page after unmapping
it fixes the problem.

http://marc.info/?t=120861317000005&r=2&w=2

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
[jacliburn@bellsouth.net: backport to 2.6.25.4]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/net/atl1/atl1_main.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1334,6 +1334,7 @@ rrd_ok:
 		/* Good Receive */
 		pci_unmap_page(adapter->pdev, buffer_info->dma,
 			       buffer_info->length, PCI_DMA_FROMDEVICE);
+		buffer_info->dma = 0;
 		skb = buffer_info->skb;
 		length = le16_to_cpu(rrd->xsz.xsum_sz.pkt_size);
 

-- 

[patch 41/50] Smack: fuse mount hang fix

[Chris Wright]

[-- Attachment #1: smack-fuse-mount-hang-fix.patch --]
[-- Type: text/plain, Size: 1484 bytes --]

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

From: Casey Schaufler <casey@schaufler-ca.com>

upstream commit: e97dcb0eadbb821eccd549d4987b653cf61e2374

The d_instantiate hook for Smack can hang on the root inode of a
filesystem if the file system code has not really done all the set-up.
Fuse is known to encounter this problem.

This change detects an attempt to instantiate a root inode and addresses
it early in the processing, before any attempt is made to do something
that might hang.

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Tested-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 security/smack/smack_lsm.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1865,6 +1865,18 @@ static void smack_d_instantiate(struct d
 	final = sbsp->smk_default;
 
 	/*
+	 * If this is the root inode the superblock
+	 * may be in the process of initialization.
+	 * If that is the case use the root value out
+	 * of the superblock.
+	 */
+	if (opt_dentry->d_parent == opt_dentry) {
+		isp->smk_inode = sbsp->smk_root;
+		isp->smk_flags |= SMK_INODE_INSTANT;
+		goto unlockandout;
+	}
+
+	/*
 	 * This is pretty hackish.
 	 * Casey says that we shouldn't have to do
 	 * file system specific code, but it does help

-- 

[patch 42/50] proc: calculate the correct /proc/<pid> link count

[Chris Wright]

[-- Attachment #1: proc-calculate-the-correct-proc-pid-link-count.patch --]
[-- Type: text/plain, Size: 2683 bytes --]

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

From: Vegard Nossum <vegard.nossum@gmail.com>

upstream commit: aed5417593ad125283f35513573282139a8664b5

This patch:

  commit e9720acd728a46cb40daa52c99a979f7c4ff195c
  Author: Pavel Emelyanov <xemul@openvz.org>
  Date:   Fri Mar 7 11:08:40 2008 -0800

    [NET]: Make /proc/net a symlink on /proc/self/net (v3)

introduced a /proc/self/net directory without bumping the corresponding
link count for /proc/self.

This patch replaces the static link count initializations with a call that
counts the number of directory entries in the given pid_entry table
whenever it is instantiated, and thus relieves the burden of manually
keeping the two in sync.

[akpm@linux-foundation.org: cleanup]
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/proc/base.c |   33 +++++++++++++++++++++++++--------
 1 file changed, 25 insertions(+), 8 deletions(-)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -126,6 +126,25 @@ struct pid_entry {
 		NULL, &proc_single_file_operations,	\
 		{ .proc_show = &proc_##OTYPE } )
 
+/*
+ * Count the number of hardlinks for the pid_entry table, excluding the .
+ * and .. links.
+ */
+static unsigned int pid_entry_count_dirs(const struct pid_entry *entries,
+	unsigned int n)
+{
+	unsigned int i;
+	unsigned int count;
+
+	count = 0;
+	for (i = 0; i < n; ++i) {
+		if (S_ISDIR(entries[i].mode))
+			++count;
+	}
+
+	return count;
+}
+
 int maps_protect;
 EXPORT_SYMBOL(maps_protect);
 
@@ -2483,10 +2502,9 @@ static struct dentry *proc_pid_instantia
 	inode->i_op = &proc_tgid_base_inode_operations;
 	inode->i_fop = &proc_tgid_base_operations;
 	inode->i_flags|=S_IMMUTABLE;
-	inode->i_nlink = 5;
-#ifdef CONFIG_SECURITY
-	inode->i_nlink += 1;
-#endif
+
+	inode->i_nlink = 2 + pid_entry_count_dirs(tgid_base_stuff,
+		ARRAY_SIZE(tgid_base_stuff));
 
 	dentry->d_op = &pid_dentry_operations;
 
@@ -2713,10 +2731,9 @@ static struct dentry *proc_task_instanti
 	inode->i_op = &proc_tid_base_inode_operations;
 	inode->i_fop = &proc_tid_base_operations;
 	inode->i_flags|=S_IMMUTABLE;
-	inode->i_nlink = 4;
-#ifdef CONFIG_SECURITY
-	inode->i_nlink += 1;
-#endif
+
+	inode->i_nlink = 2 + pid_entry_count_dirs(tid_base_stuff,
+		ARRAY_SIZE(tid_base_stuff));
 
 	dentry->d_op = &pid_dentry_operations;
 

-- 

[patch 43/50] pagemap: fix bug in add_to_pagemap, require aligned-length reads of /proc/pid/pagemap

[Chris Wright]

[-- Attachment #1: pagemap-fix-bug-in-add_to_pagemap-require-aligned-length-reads-of-proc-pid-pagemap.patch --]
[-- Type: text/plain, Size: 2632 bytes --]

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

From: Thomas Tuttle <ttuttle@google.com>

upstream commit: aae8679b0ebcaa92f99c1c3cb0cd651594a43915

Fix a bug in add_to_pagemap.  Previously, since pm->out was a char *,
put_user was only copying 1 byte of every PFN, resulting in the top 7
bytes of each PFN not being copied.  By requiring that reads be a multiple
of 8 bytes, I can make pm->out and pm->end u64*s instead of char*s, which
makes put_user work properly, and also simplifies the logic in
add_to_pagemap a bit.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Thomas Tuttle <ttuttle@google.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/proc/task_mmu.c |   28 +++++++++-------------------
 1 file changed, 9 insertions(+), 19 deletions(-)

--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -524,7 +524,7 @@ const struct file_operations proc_clear_
 };
 
 struct pagemapread {
-	char __user *out, *end;
+	u64 __user *out, *end;
 };
 
 #define PM_ENTRY_BYTES      sizeof(u64)
@@ -547,21 +547,11 @@ struct pagemapread {
 static int add_to_pagemap(unsigned long addr, u64 pfn,
 			  struct pagemapread *pm)
 {
-	/*
-	 * Make sure there's room in the buffer for an
-	 * entire entry.  Otherwise, only copy part of
-	 * the pfn.
-	 */
-	if (pm->out + PM_ENTRY_BYTES >= pm->end) {
-		if (copy_to_user(pm->out, &pfn, pm->end - pm->out))
-			return -EFAULT;
-		pm->out = pm->end;
-		return PM_END_OF_BUFFER;
-	}
-
 	if (put_user(pfn, pm->out))
 		return -EFAULT;
-	pm->out += PM_ENTRY_BYTES;
+	pm->out++;
+	if (pm->out >= pm->end)
+		return PM_END_OF_BUFFER;
 	return 0;
 }
 
@@ -662,7 +652,7 @@ static ssize_t pagemap_read(struct file 
 
 	ret = -EINVAL;
 	/* file position must be aligned */
-	if (*ppos % PM_ENTRY_BYTES)
+	if ((*ppos % PM_ENTRY_BYTES) || (count % PM_ENTRY_BYTES))
 		goto out_task;
 
 	ret = 0;
@@ -692,8 +682,8 @@ static ssize_t pagemap_read(struct file 
 		goto out_pages;
 	}
 
-	pm.out = buf;
-	pm.end = buf + count;
+	pm.out = (u64 *)buf;
+	pm.end = (u64 *)(buf + count);
 
 	if (!ptrace_may_attach(task)) {
 		ret = -EIO;
@@ -718,9 +708,9 @@ static ssize_t pagemap_read(struct file 
 		if (ret == PM_END_OF_BUFFER)
 			ret = 0;
 		/* don't need mmap_sem for these, but this looks cleaner */
-		*ppos += pm.out - buf;
+		*ppos += (char *)pm.out - buf;
 		if (!ret)
-			ret = pm.out - buf;
+			ret = (char *)pm.out - buf;
 	}
 
 out_pages:

-- 

[patch 44/50] brk: make sys_brk() honor COMPAT_BRK when computing lower bound

[Chris Wright]

[-- Attachment #1: brk-make-sys_brk-honor-compat_brk-when-computing-lower-bound.patch --]
[-- Type: text/plain, Size: 1500 bytes --]

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

From: Jiri Kosina <jkosina@suse.cz>

upstream commit: a5b4592cf77b973c29e7c9695873a26052b58951

Fix a regression introduced by

commit 4cc6028d4040f95cdb590a87db478b42b8be0508
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Wed Feb 6 22:39:44 2008 +0100

    brk: check the lower bound properly

The check in sys_brk() on minimum value the brk might have must take
CONFIG_COMPAT_BRK setting into account.  When this option is turned on
(i.e.  we support ancient legacy binaries, e.g.  libc5-linked stuff), the
lower bound on brk value is mm->end_code, otherwise the brk start is
allowed to be arbitrarily shifted.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 mm/mmap.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -242,10 +242,16 @@ asmlinkage unsigned long sys_brk(unsigne
 	unsigned long rlim, retval;
 	unsigned long newbrk, oldbrk;
 	struct mm_struct *mm = current->mm;
+	unsigned long min_brk;
 
 	down_write(&mm->mmap_sem);
 
-	if (brk < mm->start_brk)
+#ifdef CONFIG_COMPAT_BRK
+	min_brk = mm->end_code;
+#else
+	min_brk = mm->start_brk;
+#endif
+	if (brk < min_brk)
 		goto out;
 
 	/*

-- 

[patch 45/50] eCryptfs: remove unnecessary page decrypt call

[Chris Wright]

[-- Attachment #1: ecryptfs-remove-unnecessary-page-decrypt-call.patch --]
[-- Type: text/plain, Size: 2958 bytes --]

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

From: Michael Halcrow <mhalcrow@us.ibm.com>

upstream commit: d3e49afbb66109613c3474f2273f5830ac2dcb09

The page decrypt calls in ecryptfs_write() are both pointless and buggy.
Pointless because ecryptfs_get_locked_page() has already brought the page
up to date, and buggy because prior mmap writes will just be blown away by
the decrypt call.

This patch also removes the declaration of a now-nonexistent function
ecryptfs_write_zeros().

Thanks to Eric Sandeen and David Kleikamp for helping to track this
down.

Eric said:

   fsx w/ mmap dies quickly ( < 100 ops) without this, and survives
   nicely (to millions of ops+) with it in place.

Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[chrisw: backport to 2.6.25.5]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/ecryptfs/ecryptfs_kernel.h |    2 --
 fs/ecryptfs/read_write.c      |   22 ----------------------
 2 files changed, 24 deletions(-)

--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -626,8 +626,6 @@ int ecryptfs_get_tfm_and_mutex_for_ciphe
 int ecryptfs_keyring_auth_tok_for_sig(struct key **auth_tok_key,
 				      struct ecryptfs_auth_tok **auth_tok,
 				      char *sig);
-int ecryptfs_write_zeros(struct file *file, pgoff_t index, int start,
-			 int num_zeros);
 int ecryptfs_write_lower(struct inode *ecryptfs_inode, char *data,
 			 loff_t offset, size_t size);
 int ecryptfs_write_lower_page_segment(struct inode *ecryptfs_inode,
--- a/fs/ecryptfs/read_write.c
+++ b/fs/ecryptfs/read_write.c
@@ -157,20 +157,6 @@ int ecryptfs_write(struct file *ecryptfs
 			       ecryptfs_page_idx, rc);
 			goto out;
 		}
-		if (start_offset_in_page) {
-			/* Read in the page from the lower
-			 * into the eCryptfs inode page cache,
-			 * decrypting */
-			rc = ecryptfs_decrypt_page(ecryptfs_page);
-			if (rc) {
-				printk(KERN_ERR "%s: Error decrypting "
-				       "page; rc = [%d]\n",
-				       __FUNCTION__, rc);
-				ClearPageUptodate(ecryptfs_page);
-				page_cache_release(ecryptfs_page);
-				goto out;
-			}
-		}
 		ecryptfs_page_virt = kmap_atomic(ecryptfs_page, KM_USER0);
 
 		/*
@@ -349,14 +335,6 @@ int ecryptfs_read(char *data, loff_t off
 			       ecryptfs_page_idx, rc);
 			goto out;
 		}
-		rc = ecryptfs_decrypt_page(ecryptfs_page);
-		if (rc) {
-			printk(KERN_ERR "%s: Error decrypting "
-			       "page; rc = [%d]\n", __FUNCTION__, rc);
-			ClearPageUptodate(ecryptfs_page);
-			page_cache_release(ecryptfs_page);
-			goto out;
-		}
 		ecryptfs_page_virt = kmap_atomic(ecryptfs_page, KM_USER0);
 		memcpy((data + data_offset),
 		       ((char *)ecryptfs_page_virt + start_offset_in_page),

-- 

[patch 46/50] md: do not compute parity unless it is on a failed drive

[Chris Wright]

[-- Attachment #1: md-do-not-compute-parity-unless-it-is-on-a-failed-drive.patch --]
[-- Type: text/plain, Size: 1848 bytes --]

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

From: Dan Williams <dan.j.williams@intel.com>

upstream commit: c337869d95011495fa181536786e74aa2d7ff031

If a block is computed (rather than read) then a check/repair operation
may be lead to believe that the data on disk is correct, when infact it
isn't.  So only compute blocks for failed devices.

This issue has been around since at least 2.6.12, but has become harder to
hit in recent kernels since most reads bypass the cache.

echo repair > /sys/block/mdN/md/sync_action will set the parity blocks to the
correct state.

Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/md/raid5.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1984,6 +1984,7 @@ static int __handle_issuing_new_read_req
 		 * have quiesced.
 		 */
 		if ((s->uptodate == disks - 1) &&
+		    (s->failed && disk_idx == s->failed_num) &&
 		    !test_bit(STRIPE_OP_CHECK, &sh->ops.pending)) {
 			set_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.pending);
 			set_bit(R5_Wantcompute, &dev->flags);
@@ -2069,7 +2070,9 @@ static void handle_issuing_new_read_requ
 			/* we would like to get this block, possibly
 			 * by computing it, but we might not be able to
 			 */
-			if (s->uptodate == disks-1) {
+			if ((s->uptodate == disks - 1) &&
+			    (s->failed && (i == r6s->failed_num[0] ||
+					   i == r6s->failed_num[1]))) {
 				pr_debug("Computing stripe %llu block %d\n",
 				       (unsigned long long)sh->sector, i);
 				compute_block_1(sh, i, 0);

-- 

[patch 47/50] md: fix uninitialized use of mddev->recovery_wait

[Chris Wright]

[-- Attachment #1: md-fix-uninitialized-use-of-mddev-recovery_wait.patch --]
[-- Type: text/plain, Size: 1273 bytes --]

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

From: Dan Williams <dan.j.williams@intel.com>

upstream commit: a6d8113a986c66aeb379a26b6e0062488b3e59e1

If an array was created with --assume-clean we will oops when trying to
set ->resync_max.

Fix this by initializing ->recovery_wait in mddev_find.

Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/md/md.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -274,6 +274,7 @@ static mddev_t * mddev_find(dev_t unit)
 	atomic_set(&new->active, 1);
 	spin_lock_init(&new->write_lock);
 	init_waitqueue_head(&new->sb_wait);
+	init_waitqueue_head(&new->recovery_wait);
 	new->reshape_position = MaxSector;
 	new->resync_max = MaxSector;
 
@@ -5559,7 +5560,6 @@ void md_do_sync(mddev_t *mddev)
 		window/2,(unsigned long long) max_sectors/2);
 
 	atomic_set(&mddev->recovery_active, 0);
-	init_waitqueue_head(&mddev->recovery_wait);
 	last_check = 0;
 
 	if (j>2) {

-- 

[patch 48/50] md: fix prexor vs sync_request race

[Chris Wright]

[-- Attachment #1: md-fix-prexor-vs-sync_request-race.patch --]
[-- Type: text/plain, Size: 2916 bytes --]

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

From: Dan Williams <dan.j.williams@intel.com>

upstream commit: e0a115e5aa554b93150a8dc1c3fe15467708abb2

During the initial array synchronization process there is a window between
when a prexor operation is scheduled to a specific stripe and when it
completes for a sync_request to be scheduled to the same stripe.  When
this happens the prexor completes and the stripe is unconditionally marked
"insync", effectively canceling the sync_request for the stripe.  Prior to
2.6.23 this was not a problem because the prexor operation was done under
sh->lock.  The effect in older kernels being that the prexor would still
erroneously mark the stripe "insync", but sync_request would be held off
and re-mark the stripe as "!in_sync".

Change the write completion logic to not mark the stripe "in_sync" if a
prexor was performed.  The effect of the change is to sometimes not set
STRIPE_INSYNC.  The worst this can do is cause the resync to stall waiting
for STRIPE_INSYNC to be set.  If this were happening, then STRIPE_SYNCING
would be set and handle_issuing_new_read_requests would cause all
available blocks to eventually be read, at which point prexor would never
be used on that stripe any more and STRIPE_INSYNC would eventually be set.

echo repair > /sys/block/mdN/md/sync_action will correct arrays that may
have lost this race.

Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[chrisw: backport to 2.6.25.5]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/md/raid5.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2621,6 +2621,7 @@ static void handle_stripe5(struct stripe
 	struct stripe_head_state s;
 	struct r5dev *dev;
 	unsigned long pending = 0;
+	int prexor;
 
 	memset(&s, 0, sizeof(s));
 	pr_debug("handling stripe %llu, state=%#lx cnt=%d, pd_idx=%d "
@@ -2740,9 +2741,11 @@ static void handle_stripe5(struct stripe
 	/* leave prexor set until postxor is done, allows us to distinguish
 	 * a rmw from a rcw during biodrain
 	 */
+	prexor = 0;
 	if (test_bit(STRIPE_OP_PREXOR, &sh->ops.complete) &&
 		test_bit(STRIPE_OP_POSTXOR, &sh->ops.complete)) {
 
+		prexor = 1;
 		clear_bit(STRIPE_OP_PREXOR, &sh->ops.complete);
 		clear_bit(STRIPE_OP_PREXOR, &sh->ops.ack);
 		clear_bit(STRIPE_OP_PREXOR, &sh->ops.pending);
@@ -2776,6 +2779,8 @@ static void handle_stripe5(struct stripe
 				if (!test_and_set_bit(
 				    STRIPE_OP_IO, &sh->ops.pending))
 					sh->ops.count++;
+				if (prexor)
+					continue;
 				if (!test_bit(R5_Insync, &dev->flags) ||
 				    (i == sh->pd_idx && s.failed == 0))
 					set_bit(STRIPE_INSYNC, &sh->state);

-- 

[patch 49/50] capabilities: remain source compatible with 32-bit raw legacy capability support.

[Chris Wright]

[-- Attachment #1: capabilities-remain-source-compatible-with-32-bit-raw-legacy-capability-support.patch --]
[-- Type: text/plain, Size: 9656 bytes --]

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

From: Andrew G. Morgan <morgan@kernel.org>

upstream commit: ca05a99a54db1db5bca72eccb5866d2a86f8517f

Source code out there hard-codes a notion of what the
_LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the
raw capability system calls capget() and capset().  Its unfortunate, but
true.

Since the confusing header file has been in a released kernel, there is
software that is erroneously using 64-bit capabilities with the semantics
of 32-bit compatibilities.  These recently compiled programs may suffer
corruption of their memory when sys_getcap() overwrites more memory than
they are coded to expect, and the raising of added capabilities when using
sys_capset().

As such, this patch does a number of things to clean up the situation
for all. It

  1. forces the _LINUX_CAPABILITY_VERSION define to always retain its
     legacy value.

  2. adopts a new #define strategy for the kernel's internal
     implementation of the preferred magic.

  3. deprecates v2 capability magic in favor of a new (v3) magic
     number. The functionality of v3 is entirely equivalent to v2,
     the only difference being that the v2 magic causes the kernel
     to log a "deprecated" warning so the admin can find applications
     that may be using v2 inappropriately.

[User space code continues to be encouraged to use the libcap API which
protects the application from details like this.  libcap-2.10 is the first
to support v3 capabilities.]

Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
Thanks to Bojan Smojver for the report.

[akpm@linux-foundation.org: s/depreciate/deprecate/g]
[akpm@linux-foundation.org: be robust about put_user size]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: Bojan Smojver <bojan@rexursive.com>
Cc: stable@kernel.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/proc/array.c            |    2 
 include/linux/capability.h |   29 ++++++++---
 kernel/capability.c        |  111 +++++++++++++++++++++++++++++----------------
 3 files changed, 95 insertions(+), 47 deletions(-)

--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -287,7 +287,7 @@ static void render_cap_t(struct seq_file
 	seq_printf(m, "%s", header);
 	CAP_FOR_EACH_U32(__capi) {
 		seq_printf(m, "%08x",
-			   a->cap[(_LINUX_CAPABILITY_U32S-1) - __capi]);
+			   a->cap[(_KERNEL_CAPABILITY_U32S-1) - __capi]);
 	}
 	seq_printf(m, "\n");
 }
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -31,11 +31,11 @@ struct task_struct;
 #define _LINUX_CAPABILITY_VERSION_1  0x19980330
 #define _LINUX_CAPABILITY_U32S_1     1
 
-#define _LINUX_CAPABILITY_VERSION_2  0x20071026
+#define _LINUX_CAPABILITY_VERSION_2  0x20071026  /* deprecated - use v3 */
 #define _LINUX_CAPABILITY_U32S_2     2
 
-#define _LINUX_CAPABILITY_VERSION    _LINUX_CAPABILITY_VERSION_2
-#define _LINUX_CAPABILITY_U32S       _LINUX_CAPABILITY_U32S_2
+#define _LINUX_CAPABILITY_VERSION_3  0x20080522
+#define _LINUX_CAPABILITY_U32S_3     2
 
 typedef struct __user_cap_header_struct {
 	__u32 version;
@@ -77,10 +77,23 @@ struct vfs_cap_data {
 	} data[VFS_CAP_U32];
 };
 
-#ifdef __KERNEL__
+#ifndef __KERNEL__
+
+/*
+ * Backwardly compatible definition for source code - trapped in a
+ * 32-bit world. If you find you need this, please consider using
+ * libcap to untrap yourself...
+ */
+#define _LINUX_CAPABILITY_VERSION  _LINUX_CAPABILITY_VERSION_1
+#define _LINUX_CAPABILITY_U32S     _LINUX_CAPABILITY_U32S_1
+
+#else
+
+#define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
+#define _KERNEL_CAPABILITY_U32S    _LINUX_CAPABILITY_U32S_3
 
 typedef struct kernel_cap_struct {
-	__u32 cap[_LINUX_CAPABILITY_U32S];
+	__u32 cap[_KERNEL_CAPABILITY_U32S];
 } kernel_cap_t;
 
 #define _USER_CAP_HEADER_SIZE  (sizeof(struct __user_cap_header_struct))
@@ -350,7 +363,7 @@ typedef struct kernel_cap_struct {
  */
 
 #define CAP_FOR_EACH_U32(__capi)  \
-	for (__capi = 0; __capi < _LINUX_CAPABILITY_U32S; ++__capi)
+	for (__capi = 0; __capi < _KERNEL_CAPABILITY_U32S; ++__capi)
 
 # define CAP_FS_MASK_B0     (CAP_TO_MASK(CAP_CHOWN)		\
 			    | CAP_TO_MASK(CAP_DAC_OVERRIDE)	\
@@ -360,7 +373,7 @@ typedef struct kernel_cap_struct {
 
 # define CAP_FS_MASK_B1     (CAP_TO_MASK(CAP_MAC_OVERRIDE))
 
-#if _LINUX_CAPABILITY_U32S != 2
+#if _KERNEL_CAPABILITY_U32S != 2
 # error Fix up hand-coded capability macro initializers
 #else /* HAND-CODED capability initializers */
 
@@ -371,7 +384,7 @@ typedef struct kernel_cap_struct {
 # define CAP_NFSD_SET     {{ CAP_FS_MASK_B0|CAP_TO_MASK(CAP_SYS_RESOURCE), \
 			     CAP_FS_MASK_B1 } }
 
-#endif /* _LINUX_CAPABILITY_U32S != 2 */
+#endif /* _KERNEL_CAPABILITY_U32S != 2 */
 
 #define CAP_INIT_INH_SET    CAP_EMPTY_SET
 
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -53,6 +53,69 @@ static void warn_legacy_capability_use(v
 }
 
 /*
+ * Version 2 capabilities worked fine, but the linux/capability.h file
+ * that accompanied their introduction encouraged their use without
+ * the necessary user-space source code changes. As such, we have
+ * created a version 3 with equivalent functionality to version 2, but
+ * with a header change to protect legacy source code from using
+ * version 2 when it wanted to use version 1. If your system has code
+ * that trips the following warning, it is using version 2 specific
+ * capabilities and may be doing so insecurely.
+ *
+ * The remedy is to either upgrade your version of libcap (to 2.10+,
+ * if the application is linked against it), or recompile your
+ * application with modern kernel headers and this warning will go
+ * away.
+ */
+
+static void warn_deprecated_v2(void)
+{
+	static int warned;
+
+	if (!warned) {
+		char name[sizeof(current->comm)];
+
+		printk(KERN_INFO "warning: `%s' uses deprecated v2"
+		       " capabilities in a way that may be insecure.\n",
+		       get_task_comm(name, current));
+		warned = 1;
+	}
+}
+
+/*
+ * Version check. Return the number of u32s in each capability flag
+ * array, or a negative value on error.
+ */
+static int cap_validate_magic(cap_user_header_t header, unsigned *tocopy)
+{
+	__u32 version;
+
+	if (get_user(version, &header->version))
+		return -EFAULT;
+
+	switch (version) {
+	case _LINUX_CAPABILITY_VERSION_1:
+		warn_legacy_capability_use();
+		*tocopy = _LINUX_CAPABILITY_U32S_1;
+		break;
+	case _LINUX_CAPABILITY_VERSION_2:
+		warn_deprecated_v2();
+		/*
+		 * fall through - v3 is otherwise equivalent to v2.
+		 */
+	case _LINUX_CAPABILITY_VERSION_3:
+		*tocopy = _LINUX_CAPABILITY_U32S_3;
+		break;
+	default:
+		if (put_user((u32)_KERNEL_CAPABILITY_VERSION, &header->version))
+			return -EFAULT;
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
  * For sys_getproccap() and sys_setproccap(), any of the three
  * capability set pointers may be NULL -- indicating that that set is
  * uninteresting and/or not to be changed.
@@ -71,27 +134,13 @@ asmlinkage long sys_capget(cap_user_head
 {
 	int ret = 0;
 	pid_t pid;
-	__u32 version;
 	struct task_struct *target;
 	unsigned tocopy;
 	kernel_cap_t pE, pI, pP;
 
-	if (get_user(version, &header->version))
-		return -EFAULT;
-
-	switch (version) {
-	case _LINUX_CAPABILITY_VERSION_1:
-		warn_legacy_capability_use();
-		tocopy = _LINUX_CAPABILITY_U32S_1;
-		break;
-	case _LINUX_CAPABILITY_VERSION_2:
-		tocopy = _LINUX_CAPABILITY_U32S_2;
-		break;
-	default:
-		if (put_user(_LINUX_CAPABILITY_VERSION, &header->version))
-			return -EFAULT;
-		return -EINVAL;
-	}
+	ret = cap_validate_magic(header, &tocopy);
+	if (ret != 0)
+		return ret;
 
 	if (get_user(pid, &header->pid))
 		return -EFAULT;
@@ -118,7 +167,7 @@ out:
 	spin_unlock(&task_capability_lock);
 
 	if (!ret) {
-		struct __user_cap_data_struct kdata[_LINUX_CAPABILITY_U32S];
+		struct __user_cap_data_struct kdata[_KERNEL_CAPABILITY_U32S];
 		unsigned i;
 
 		for (i = 0; i < tocopy; i++) {
@@ -128,7 +177,7 @@ out:
 		}
 
 		/*
-		 * Note, in the case, tocopy < _LINUX_CAPABILITY_U32S,
+		 * Note, in the case, tocopy < _KERNEL_CAPABILITY_U32S,
 		 * we silently drop the upper capabilities here. This
 		 * has the effect of making older libcap
 		 * implementations implicitly drop upper capability
@@ -240,30 +289,16 @@ static inline int cap_set_all(kernel_cap
  */
 asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t data)
 {
-	struct __user_cap_data_struct kdata[_LINUX_CAPABILITY_U32S];
+	struct __user_cap_data_struct kdata[_KERNEL_CAPABILITY_U32S];
 	unsigned i, tocopy;
 	kernel_cap_t inheritable, permitted, effective;
-	__u32 version;
 	struct task_struct *target;
 	int ret;
 	pid_t pid;
 
-	if (get_user(version, &header->version))
-		return -EFAULT;
-
-	switch (version) {
-	case _LINUX_CAPABILITY_VERSION_1:
-		warn_legacy_capability_use();
-		tocopy = _LINUX_CAPABILITY_U32S_1;
-		break;
-	case _LINUX_CAPABILITY_VERSION_2:
-		tocopy = _LINUX_CAPABILITY_U32S_2;
-		break;
-	default:
-		if (put_user(_LINUX_CAPABILITY_VERSION, &header->version))
-			return -EFAULT;
-		return -EINVAL;
-	}
+	ret = cap_validate_magic(header, &tocopy);
+	if (ret != 0)
+		return ret;
 
 	if (get_user(pid, &header->pid))
 		return -EFAULT;
@@ -281,7 +316,7 @@ asmlinkage long sys_capset(cap_user_head
 		permitted.cap[i] = kdata[i].permitted;
 		inheritable.cap[i] = kdata[i].inheritable;
 	}
-	while (i < _LINUX_CAPABILITY_U32S) {
+	while (i < _KERNEL_CAPABILITY_U32S) {
 		effective.cap[i] = 0;
 		permitted.cap[i] = 0;
 		inheritable.cap[i] = 0;

-- 

[patch 50/50] cpufreq: fix null object access on Transmeta CPU

[Chris Wright]

[-- Attachment #1: cpufreq-fix-null-object-access-on-transmeta-cpu.patch --]
[-- Type: text/plain, Size: 1909 bytes --]

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

From: CHIKAMA masaki <masaki.chikama@gmail.com>

upstream commit: 879000f94442860e72c934f9e568989bc7fb8ec4

If cpu specific cpufreq driver(i.e.  longrun) has "setpolicy" function,
governor object isn't set into cpufreq_policy object at "__cpufreq_set_policy"
function in driver/cpufreq/cpufreq.c .

This causes a null object access at "store_scaling_setspeed" and
"show_scaling_setspeed" function in driver/cpufreq/cpufreq.c when reading or
writing through /sys interface (ex.  cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed)

Addresses:
	http://bugzilla.kernel.org/show_bug.cgi?id=10654
	https://bugzilla.redhat.com/show_bug.cgi?id=443354

Signed-off-by: CHIKAMA Masaki <masaki.chikama@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Chuck Ebbert <cebbert@redhat.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/cpufreq/cpufreq.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -607,7 +607,7 @@ static ssize_t store_scaling_setspeed(st
 	unsigned int freq = 0;
 	unsigned int ret;
 
-	if (!policy->governor->store_setspeed)
+	if (!policy->governor || !policy->governor->store_setspeed)
 		return -EINVAL;
 
 	ret = sscanf(buf, "%u", &freq);
@@ -621,7 +621,7 @@ static ssize_t store_scaling_setspeed(st
 
 static ssize_t show_scaling_setspeed(struct cpufreq_policy *policy, char *buf)
 {
-	if (!policy->governor->show_setspeed)
+	if (!policy->governor || !policy->governor->show_setspeed)
 		return sprintf(buf, "<unsupported>\n");
 
 	return policy->governor->show_setspeed(policy, buf);

-- 

Re: [patch 00/50] 2.6.25.6 -stable review

[Hugh Dickins]

On Fri, 6 Jun 2008, Chris Wright wrote:
> This is the start of the stable review cycle for the 2.6.25.6 release.
> There are 50 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.

Please add 2.6.26-rc5's 2884f110d5409714f3a04eeb6d2ecd77da66b242
into 2.6.25.6: it's actually not a serious problem, but it does
look as if it's a serious problem, so we should stamp it out.

Thanks,
Hugh

x86: fix bad pmd ffff810000207xxx(9090909090909090)

OGAWA Hirofumi and Fede have reported rare pmd_ERROR messages:
mm/memory.c:127: bad pmd ffff810000207xxx(9090909090909090).

Initialization's cleanup_highmap was leaving alignment filler
behind in the pmd for MODULES_VADDR: when vmalloc's guard page
would occupy a new page table, it's not allocated, and then
module unload's vfree hits the bad 9090 pmd entry left over.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 32ba13b..998a06e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -206,7 +206,7 @@ void __init cleanup_highmap(void)
 	pmd_t *last_pmd = pmd + PTRS_PER_PMD;
 
 	for (; pmd < last_pmd; pmd++, vaddr += PMD_SIZE) {
-		if (!pmd_present(*pmd))
+		if (pmd_none(*pmd))
 			continue;
 		if (vaddr < (unsigned long) _text || vaddr > end)
 			set_pmd(pmd, __pmd(0));

Re: [stable] [patch 00/50] 2.6.25.6 -stable review

[Chris Wright]

* Hugh Dickins (hugh@veritas.com) wrote:
> Please add 2.6.26-rc5's 2884f110d5409714f3a04eeb6d2ecd77da66b242
> into 2.6.25.6: it's actually not a serious problem, but it does
> look as if it's a serious problem, so we should stamp it out.

Got it, thanks for the reminder.
-chris

Re: 2.6.25 crash: EIP: [<c02e2f14>] xfrm_output_resume+0x64/0x100 ss:esp 0068:c03a1e5c

[Marco Berizzi]

Marco Berizzi wrote:

> Marco Berizzi wrote:
>
> > Herbert Xu wrote:
> >
> > > On Mon, May 12, 2008 at 09:14:54AM +0200, Marco Berizzi wrote:
> > > >
> > > > PS: linux version shown by dmesg is 2.6.24 but it
> > > > is the results of 'git bisect good v2.6.24' and
> > > > 'git bisect bad v2.6.25'
> > >
> > > So what's the changeset hash for the source that produced this
> > > kernel?
> >
> > root@Calimero:/tmp/GIT/herbert# git bisect good v2.6.24
> > You need to start by "git bisect start"
> > Do you want me to do it for you [Y/n]? Y
> > root@Calimero:/tmp/GIT/herbert# git bisect bad v2.6.25
> > Bisecting: 6353 revisions left to test after this
> > [dd5f5fed6c9458a7aa81eeef3732cc3a9891cfdf] Merge branch 'audit.b46'
of
> > git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
> >
> > Then I have copied from 2.6.25 two files:
> >
> > net/ipv4/xfrm4_tunnel.c and ipcomp.c because
> > of these bugs:
> >
> >
>
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commit;h=11b47c8828d4cd1df21636719603784ec5e26067
> >
>
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commit;h=363c11d7e1c2b2cc30e33416a518cea5ef9e0cc8
> >
>
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commit;h=cefe34bea77e194fd6b6a7a062e1620af2eef69f
> >
> > and finally I have run 'make menuconfig' and
> > 'make bzImage modules modules_install'
>
> ok, I have git bisected again:
>
> root@Calimero:/tmp/GIT/herbert# git bisect bad
> Bisecting: 3176 revisions left to test after this
> [fde3571fd8613483f1203d11394ae316c6b79a03] iwlwifi: avoid firmware
> command sending if rfkill is enabled
>
> and then copied always the two files from 2.6.25
> xfrm4_tunnel.c and ipcomp.c
>
> now this kernel is up for 4 hours (at least it
> doesn't crash at startup)
> I will keep you updated.
> Thanks for the feedback Herbert.

NAK: it crashed after 4 hours and few minutes with
this message:

BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
printing eip: ca8931be *pde = 00000000
Oops: 0002 [#1]
Modules linked in: netconsole sch_sfq sch_htb cls_fw nf_nat_pptp
nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp
nf_conntrack_ftp 3c59x mii
Pid: 881, comm: squid Not tainted (2.6.24 #1)
EIP: 0060:[<ca8931be>] EFLAGS: 00010203 CPU: 0
EIP is at sfq_dequeue+0x6e/0x1f0 [sch_sfq]
EAX: 6b6b6b6b EBX: c91d0d14 ECX: c91d0d08 EDX: 000005e8
ESI: c91d0080 EDI: c559c540 EBP: c91d0000 ESP: c9149e9c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process squid (pid: 881, ti=c9148000 task=c9fbd020 task.ti=c9148000)
Stack: c559c540 7e0039c1 00000000 fffffffe c913ed20 00000000 ca89b146
c905b468
       c2468012 c9e3d840 00000282 c905b388 00000282 000005ea 00000000
c905b168
       c905b288 000006e0 c905b060 00000000 c905b0e0 00000007 5c9a608b
00000003
Call Trace:
 [<ca89b146>] htb_dequeue+0x226/0x860 [sch_htb]
 [<c028189b>] dev_hard_start_xmit+0x1cb/0x230
 [<c0290bf5>] __qdisc_run+0xd5/0x130
 [<c0283129>] net_tx_action+0x39/0xd0
 [<c0283129>] net_tx_action+0x39/0xd0
 [<c0283177>] net_tx_action+0x87/0xd0
 [<c0118ad2>] __do_softirq+0x42/0x90
 [<c0118b46>] do_softirq+0x26/0x30
 [<c0104a9a>] do_IRQ+0x4a/0x80
 [<c0154891>] sys_read+0x41/0x70
 [<c010303f>] common_interrupt+0x23/0x28
 =======================
Code: 8d 14 85 00 00 00 00 8d 8c 16 a0 06 00 00 8b 41 0c 8d 59 0c 39 d8
89 04 24 0f 84 72 01 00 00 8b 3c 24 8b 07 ff 8c 16 b4 06 00 00 <89> 58
04 89 41 0c c7 47 04 00 00 00 00 c7 07 00 00 00 00 0f b6
EIP: [<ca8931be>] sfq_dequeue+0x6e/0x1f0 [sch_sfq] SS:ESP 0068:c9149e9c
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 5 seconds..Linux version 2.6.24 (root@Calimero) (gcc
version 4.2.3) #1 Mon May 12 11:12:56 CEST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000a000000 (usable)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
160MB LOWMEM available.
Entering add_active_range(0, 0, 40960) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    40960
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    40960
On node 0 totalpages: 40960
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 288 pages used for memmap
  Normal zone: 36576 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
DMI 2.1 present.
ACPI: DMI detected: Hewlett-Packard
Allocating PCI resources starting at 10000000 (gap: 0a000000:f5ff0000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
40640
Kernel command line: auto BOOT_IMAGE=Linux ro root=301 slub_debug
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffb000 (01141000)
Enabling fast FPU save and restore... done.
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 267.281 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 158956k/163840k available (2010k kernel code, 4452k reserved,
606k data, 160k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb5000 - 0xfffff000   ( 296 kB)
    vmalloc : 0xca800000 - 0xfffb3000   ( 855 MB)
    lowmem  : 0xc0000000 - 0xca000000   ( 160 MB)
      .init : 0xc0392000 - 0xc03ba000   ( 160 kB)
      .data : 0xc02f687e - 0xc038e280   ( 606 kB)
      .text : 0xc0100000 - 0xc02f687e   (2010 kB)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 535.28 BogoMIPS
(lpj=1070570)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000
00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040 00000000
00000000 00000000 00000000
Compat vDSO mapped to ffffe000.
CPU: Intel Celeron (Covington) stepping 00
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 0k freed
ACPI: Core revision 20070126
ACPI Exception (tbxface-0629): AE_NO_ACPI_TABLES, While loading
namespace from ACPI tables [20070126]
ACPI: Unable to load the System Description Tables
net_namespace: 128 bytes
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfda61, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
PCI quirk: region 6100-613f claimed by PIIX4 ACPI
PCI quirk: region 5f00-5f0f claimed by PIIX4 SMB
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
  IO window: b000-bfff
  MEM window: efe00000-efefffff
  PREFETCH window: e5c00000-e7cfffff
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
SGI XFS with no debug enabled
io scheduler noop registered (default)
Limiting direct PCI/PCI transfers.
Boot video device is 0000:01:00.0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PIIX4: IDE controller (0x8086:0x7111 rev 0x01) at  PCI slot 0000:00:07.1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/33 mode selected
Probing IDE interface ide1...
hdc: CRD-8160B, ATAPI CD/DVD-ROM drive
hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdc: MWDMA2 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63
hda: cache flushes not supported
 hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 >
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
nf_conntrack version 0.5.0 (3072 buckets, 12288 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Using IPI Shortcut mode
input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
Filesystem "hda1": Disabling barriers, not supported by the underlying
device
XFS mounting filesystem hda1
Starting XFS recovery on filesystem: hda1 (logdev: internal)
Ending XFS recovery on filesystem: hda1 (logdev: internal)
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 160k freed
Adding 330584k swap on /dev/hda9.  Priority:-1 extents:1 across:330584k
Filesystem "hda1": Disabling barriers, not supported by the underlying
device
Filesystem "hda1": Disabling barriers, not supported by the underlying
device
PCI: setting IRQ 10 as level-triggered
PCI: Found IRQ 10 for device 0000:00:09.0
3c59x: Donald Becker and others.
0000:00:09.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001dc00.
PCI: setting IRQ 11 as level-triggered
PCI: Found IRQ 11 for device 0000:00:0a.0
0000:00:0a.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001da00.
PCI: setting IRQ 9 as level-triggered
PCI: Found IRQ 9 for device 0000:00:0b.0
PCI: Sharing IRQ 9 with 0000:00:07.2
0000:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001d800.
netconsole: local port 6665
netconsole: local IP 85.32.35.30
netconsole: interface eth0
netconsole: remote port 6666
netconsole: remote IP 80.204.235.230
netconsole: remote ethernet address 00:1b:d4:0a:43:d0
netconsole: device eth0 not up yet, forcing it
eth0:  setting full-duplex.
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
console [netcon0] enabled
netconsole: network logging started
Filesystem "hda5": Disabling barriers, not supported by the underlying
device
XFS mounting filesystem hda5
Starting XFS recovery on filesystem: hda5 (logdev: internal)
Ending XFS recovery on filesystem: hda5 (logdev: internal)
Filesystem "hda6": Disabling barriers, not supported by the underlying
device
XFS mounting filesystem hda6
Starting XFS recovery on filesystem: hda6 (logdev: internal)
Ending XFS recovery on filesystem: hda6 (logdev: internal)
Filesystem "hda7": Disabling barriers, not supported by the underlying
device
XFS mounting filesystem hda7
Ending clean XFS mount for filesystem: hda7
Filesystem "hda8": Disabling barriers, not supported by the underlying
device
XFS mounting filesystem hda8
Starting XFS recovery on filesystem: hda8 (logdev: internal)
Ending XFS recovery on filesystem: hda8 (logdev: internal)

Re: 2.6.25 crash: EIP: [<c02e2f14>] xfrm_output_resume+0x64/0x100 ss:esp 0068:c03a1e5c

[Marco Berizzi]

Marco Berizzi wrote:

> Marco Berizzi wrote:
>
> > Marco Berizzi wrote:
> >
> > > Herbert Xu wrote:
> > >
> > > > On Mon, May 12, 2008 at 09:14:54AM +0200, Marco Berizzi wrote:
> > > > >
> > > > > PS: linux version shown by dmesg is 2.6.24 but it
> > > > > is the results of 'git bisect good v2.6.24' and
> > > > > 'git bisect bad v2.6.25'
> > > >
> > > > So what's the changeset hash for the source that produced this
> > > > kernel?

This kernel (see below git bisect log) has not
been crashed after more than 17 hours. I want
to test it till this evening.
This is the git bisect log:

root@Calimero:/tmp/GIT/herbert# git bisect log
git-bisect start
# good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24
git-bisect good 49914084e797530d9baaf51df9eda77babc98fa8
# bad: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25
git-bisect bad 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
# bad: [dd5f5fed6c9458a7aa81eeef3732cc3a9891cfdf] Merge branch
'audit.b46' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
git-bisect bad dd5f5fed6c9458a7aa81eeef3732cc3a9891cfdf
# bad: [fde3571fd8613483f1203d11394ae316c6b79a03] iwlwifi: avoid
firmware command sending if rfkill is enabled
git-bisect bad fde3571fd8613483f1203d11394ae316c6b79a03
# good: [1c7c2cdec3a6b2873439096983794a550d7ff65b] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
git-bisect good 1c7c2cdec3a6b2873439096983794a550d7ff65b
# bad: [4c37799ccf6c722e0dad6a0677af22d1c23fb897] [NETFILTER]: Use
lowercase names for matches in Kconfig
git-bisect bad 4c37799ccf6c722e0dad6a0677af22d1c23fb897

I hope this helps.

PS: I always replace from 2.6.25 ipcomp.c and
xfrm4_tunnel.c

[IPSEC]: Use the correct ip_local_out function

[Herbert Xu]

On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> 
> I hope this helps.

OK found the problem, it was my fault after all :)

Dave, this patch needs to go into stable too.

[IPSEC]: Use the correct ip_local_out function

Because the IPsec output function xfrm_output_resume does its
own dst_output call it should always call __ip_local_output
instead of ip_local_output as the latter may invoke dst_output
directly.  Otherwise the return values from nf_hook and dst_output
may clash as they both use the value 1 but for different purposes.

When that clash occurs this can cause a packet to be used after
it has been freed which usually leads to a crash.  Because the
offending value is only returned from dst_output with qdiscs
such as HTB, this bug is normally not visible.

Thanks to Marco Berizzi for his perseverance in tracking this
down.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 92f90ae..df41026 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -160,7 +160,7 @@ static struct dst_ops ipv4_dst_ops = {
 	.negative_advice =	ipv4_negative_advice,
 	.link_failure =		ipv4_link_failure,
 	.update_pmtu =		ip_rt_update_pmtu,
-	.local_out =		ip_local_out,
+	.local_out =		__ip_local_out,
 	.entry_size =		sizeof(struct rtable),
 	.entries =		ATOMIC_INIT(0),
 };
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 12bba08..849b78a 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -109,7 +109,7 @@ static struct dst_ops ip6_dst_ops_template = {
 	.negative_advice	=	ip6_negative_advice,
 	.link_failure		=	ip6_link_failure,
 	.update_pmtu		=	ip6_rt_update_pmtu,
-	.local_out		=	ip6_local_out,
+	.local_out		=	__ip6_local_out,
 	.entry_size		=	sizeof(struct rt6_info),
 	.entries		=	ATOMIC_INIT(0),
 };

Re: [IPSEC]: Use the correct ip_local_out function

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 20 May 2008 17:25:11 +0800

> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> > 
> > I hope this helps.
> 
> OK found the problem, it was my fault after all :)
> 
> Dave, this patch needs to go into stable too.
> 
> [IPSEC]: Use the correct ip_local_out function
> 
> Because the IPsec output function xfrm_output_resume does its
> own dst_output call it should always call __ip_local_output
> instead of ip_local_output as the latter may invoke dst_output
> directly.  Otherwise the return values from nf_hook and dst_output
> may clash as they both use the value 1 but for different purposes.
> 
> When that clash occurs this can cause a packet to be used after
> it has been freed which usually leads to a crash.  Because the
> offending value is only returned from dst_output with qdiscs
> such as HTB, this bug is normally not visible.
> 
> Thanks to Marco Berizzi for his perseverance in tracking this
> down.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied and queued to -stable, thanks!

Re: [patch 00/50] 2.6.25.6 -stable review

[Marco Berizzi]

David Miller wrote:

> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 20 May 2008 17:25:11 +0800
> 
>> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
>> > 
>> > I hope this helps.
>> 
>> OK found the problem, it was my fault after all :)
>> 
>> Dave, this patch needs to go into stable too.
>> 
>> [IPSEC]: Use the correct ip_local_out function
>> 
>> Because the IPsec output function xfrm_output_resume does its
>> own dst_output call it should always call __ip_local_output
>> instead of ip_local_output as the latter may invoke dst_output
>> directly.  Otherwise the return values from nf_hook and dst_output
>> may clash as they both use the value 1 but for different purposes.
>> 
>> When that clash occurs this can cause a packet to be used after
>> it has been freed which usually leads to a crash.  Because the
>> offending value is only returned from dst_output with qdiscs
>> such as HTB, this bug is normally not visible.
>> 
>> Thanks to Marco Berizzi for his perseverance in tracking this
>> down.
>> 
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> Applied and queued to -stable, thanks!

Hi David,

I don't see this patch in Chris 2.6.25.6 -stable review message.

Re: [patch 00/50] 2.6.25.6 -stable review

[Willy Tarreau]

On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
> David Miller wrote:
> 
> > From: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Tue, 20 May 2008 17:25:11 +0800
> > 
> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >> > 
> >> > I hope this helps.
> >> 
> >> OK found the problem, it was my fault after all :)
> >> 
> >> Dave, this patch needs to go into stable too.
> >> 
> >> [IPSEC]: Use the correct ip_local_out function
> >> 
> >> Because the IPsec output function xfrm_output_resume does its
> >> own dst_output call it should always call __ip_local_output
> >> instead of ip_local_output as the latter may invoke dst_output
> >> directly.  Otherwise the return values from nf_hook and dst_output
> >> may clash as they both use the value 1 but for different purposes.
> >> 
> >> When that clash occurs this can cause a packet to be used after
> >> it has been freed which usually leads to a crash.  Because the
> >> offending value is only returned from dst_output with qdiscs
> >> such as HTB, this bug is normally not visible.
> >> 
> >> Thanks to Marco Berizzi for his perseverance in tracking this
> >> down.
> >> 
> >> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > 
> > Applied and queued to -stable, thanks!
> 
> Hi David,
> 
> I don't see this patch in Chris 2.6.25.6 -stable review message.

Is it already in mainline ? (stable should only contain already merged
patches). It generally helps the stable team if you indicate the commit
id, as it's easier to "git show" than to "git log|grep".

Regards,
Willy

Re: [patch 00/50] 2.6.25.6 -stable review

[Marco Berizzi]

Willy Tarreau wrote:

> On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
>> David Miller wrote:
>> 
>> > From: Herbert Xu <herbert@gondor.apana.org.au>
>> > Date: Tue, 20 May 2008 17:25:11 +0800
>> > 
>> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
>> >> > 
>> >> > I hope this helps.
>> >> 
>> >> OK found the problem, it was my fault after all :)
>> >> 
>> >> Dave, this patch needs to go into stable too.
>> >> 
>> >> [IPSEC]: Use the correct ip_local_out function
>> >> 
>> >> Because the IPsec output function xfrm_output_resume does its
>> >> own dst_output call it should always call __ip_local_output
>> >> instead of ip_local_output as the latter may invoke dst_output
>> >> directly.  Otherwise the return values from nf_hook and dst_output
>> >> may clash as they both use the value 1 but for different purposes.
>> >> 
>> >> When that clash occurs this can cause a packet to be used after
>> >> it has been freed which usually leads to a crash.  Because the
>> >> offending value is only returned from dst_output with qdiscs
>> >> such as HTB, this bug is normally not visible.
>> >> 
>> >> Thanks to Marco Berizzi for his perseverance in tracking this
>> >> down.
>> >> 
>> >> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>> > 
>> > Applied and queued to -stable, thanks!
>> 
>> Hi David,
>> 
>> I don't see this patch in Chris 2.6.25.6 -stable review message.
> 
> Is it already in mainline ?

yes, since 2008/05/20
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3

Re: [patch 00/50] 2.6.25.6 -stable review

[Willy Tarreau]

On Sun, Jun 08, 2008 at 01:56:01PM +0200, Marco Berizzi wrote:
> Willy Tarreau wrote:
> 
> > On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
> >> David Miller wrote:
> >> 
> >> > From: Herbert Xu <herbert@gondor.apana.org.au>
> >> > Date: Tue, 20 May 2008 17:25:11 +0800
> >> > 
> >> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >> >> > 
> >> >> > I hope this helps.
> >> >> 
> >> >> OK found the problem, it was my fault after all :)
> >> >> 
> >> >> Dave, this patch needs to go into stable too.
> >> >> 
> >> >> [IPSEC]: Use the correct ip_local_out function
> >> >> 
> >> >> Because the IPsec output function xfrm_output_resume does its
> >> >> own dst_output call it should always call __ip_local_output
> >> >> instead of ip_local_output as the latter may invoke dst_output
> >> >> directly.  Otherwise the return values from nf_hook and dst_output
> >> >> may clash as they both use the value 1 but for different purposes.
> >> >> 
> >> >> When that clash occurs this can cause a packet to be used after
> >> >> it has been freed which usually leads to a crash.  Because the
> >> >> offending value is only returned from dst_output with qdiscs
> >> >> such as HTB, this bug is normally not visible.
> >> >> 
> >> >> Thanks to Marco Berizzi for his perseverance in tracking this
> >> >> down.
> >> >> 
> >> >> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> >> > 
> >> > Applied and queued to -stable, thanks!
> >> 
> >> Hi David,
> >> 
> >> I don't see this patch in Chris 2.6.25.6 -stable review message.
> > 
> > Is it already in mainline ?
> 
> yes, since 2008/05/20
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3

Indeed. Most likely it was simply lost somewhere in the e-mail chain.
Then best thing to do is to retransmit it for next batch of patches.
Chris, here's the fix in question.

Thanks,
Willy
--

>From 1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3 Mon Sep 17 00:00:00 2001
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 20 May 2008 14:32:14 -0700
Subject: ipsec: Use the correct ip_local_out function

Because the IPsec output function xfrm_output_resume does its
own dst_output call it should always call __ip_local_output
instead of ip_local_output as the latter may invoke dst_output
directly.  Otherwise the return values from nf_hook and dst_output
may clash as they both use the value 1 but for different purposes.

When that clash occurs this can cause a packet to be used after
it has been freed which usually leads to a crash.  Because the
offending value is only returned from dst_output with qdiscs
such as HTB, this bug is normally not visible.

Thanks to Marco Berizzi for his perseverance in tracking this
down.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/route.c |    2 +-
 net/ipv6/route.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 92f90ae..df41026 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -160,7 +160,7 @@ static struct dst_ops ipv4_dst_ops = {
 	.negative_advice =	ipv4_negative_advice,
 	.link_failure =		ipv4_link_failure,
 	.update_pmtu =		ip_rt_update_pmtu,
-	.local_out =		ip_local_out,
+	.local_out =		__ip_local_out,
 	.entry_size =		sizeof(struct rtable),
 	.entries =		ATOMIC_INIT(0),
 };
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b7a4a87..48534c6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -109,7 +109,7 @@ static struct dst_ops ip6_dst_ops_template = {
 	.negative_advice	=	ip6_negative_advice,
 	.link_failure		=	ip6_link_failure,
 	.update_pmtu		=	ip6_rt_update_pmtu,
-	.local_out		=	ip6_local_out,
+	.local_out		=	__ip6_local_out,
 	.entry_size		=	sizeof(struct rt6_info),
 	.entries		=	ATOMIC_INIT(0),
 };
-- 
1.5.3.8

Re: [patch 00/50] 2.6.25.6 -stable review

[David Miller]

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 8 Jun 2008 14:36:01 +0200

> Indeed. Most likely it was simply lost somewhere in the e-mail chain.
> Then best thing to do is to retransmit it for next batch of patches.
> Chris, here's the fix in question.

It did not get lost at all, it's perfectly sitting in my
networking -stable queue waiting for me to have an
opportunity to submit it to the -stable folks after I do
some testing.

If you ask me in the future about the status of a -stable
patch from the networking, I'll let you know exactly what
is happening to that patch wrt. stable.  I rarely forget
to submit an appropriate patch, and when I do forget you
merely have to let me know (rather than submitting it
to -stable directly, please don't do that) so that I can
fit it in with what I plan to submit to -stable already.

Right now is an unusual situation where I am in a 3 week
period of near constant travel, otherwise all of this
stuff would have been submitted already.  As I stated in
another reply to you, that period is ending tomorrow so I
should be able to crank out all of these patches to -stable
some time this week.

Thanks.

Re: [patch 00/50] 2.6.25.6 -stable review

[Willy Tarreau]

On Sun, Jun 08, 2008 at 07:10:51AM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Sun, 8 Jun 2008 14:36:01 +0200
> 
> > Indeed. Most likely it was simply lost somewhere in the e-mail chain.
> > Then best thing to do is to retransmit it for next batch of patches.
> > Chris, here's the fix in question.
> 
> It did not get lost at all, it's perfectly sitting in my
> networking -stable queue waiting for me to have an
> opportunity to submit it to the -stable folks after I do
> some testing.
> 
> If you ask me in the future about the status of a -stable
> patch from the networking, I'll let you know exactly what
> is happening to that patch wrt. stable.  I rarely forget
> to submit an appropriate patch, and when I do forget you
> merely have to let me know (rather than submitting it
> to -stable directly, please don't do that) so that I can
> fit it in with what I plan to submit to -stable already.

OK

> Right now is an unusual situation where I am in a 3 week
> period of near constant travel, otherwise all of this
> stuff would have been submitted already.  As I stated in
> another reply to you, that period is ending tomorrow so I
> should be able to crank out all of these patches to -stable
> some time this week.

Perfect, thank you David.
Willy

Re: [patch 00/50] 2.6.25.6 -stable review

[Jay Cliburn]

On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:


> If you ask me in the future about the status of a -stable
> patch from the networking, I'll let you know exactly what
> is happening to that patch wrt. stable.  I rarely forget
> to submit an appropriate patch, and when I do forget you
> merely have to let me know (rather than submitting it
> to -stable directly, please don't do that) so that I can
> fit it in with what I plan to submit to -stable already.


As a netdev driver maintainer, I've been following this workflow for
patches that need to go to -stable:

1.  I submit a mainline patch to Jeff Garzik.
2.  Jeff submits to David.
3.  David submits to Linus.
4.  Linus merges patch into mainline.
5.  I extract mainline commit ID.
6.  I apply and test patch against appropriate 2.6.x.y git tree.
7.  I submit patch directly to -stable.

David's admonition tells me I'm doing it wrong, and that I should
submit the stable patch to Jeff as well.  Am I right?

Jay

Re: [patch 00/50] 2.6.25.6 -stable review

[Willy Tarreau]

On Sun, Jun 08, 2008 at 10:38:35AM -0500, Jay Cliburn wrote:
> On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> 
> > If you ask me in the future about the status of a -stable
> > patch from the networking, I'll let you know exactly what
> > is happening to that patch wrt. stable.  I rarely forget
> > to submit an appropriate patch, and when I do forget you
> > merely have to let me know (rather than submitting it
> > to -stable directly, please don't do that) so that I can
> > fit it in with what I plan to submit to -stable already.
> 
> 
> As a netdev driver maintainer, I've been following this workflow for
> patches that need to go to -stable:
> 
> 1.  I submit a mainline patch to Jeff Garzik.
> 2.  Jeff submits to David.
> 3.  David submits to Linus.
> 4.  Linus merges patch into mainline.
> 5.  I extract mainline commit ID.
> 6.  I apply and test patch against appropriate 2.6.x.y git tree.
> 7.  I submit patch directly to -stable.
> 
> David's admonition tells me I'm doing it wrong, and that I should
> submit the stable patch to Jeff as well.  Am I right?

The normal recommended method to get patches automatically sent to
stable is to add a "Cc: stable@kernel.org" line above your signed-off-by
line. That way it is automatically sent to stable when Linus merges it,
and David gets notified. This should *theorically* save him some of the
work consisting in checking his stable queue for unmerged patches, but
his workflow may be different. Also, this method is particularly suited
to ensure that patches don't get lost when the maintainer does not have
a specific stable queue, which is not the case here, according to David.

Regards,
Willy

Re: [patch 00/50] 2.6.25.6 -stable review

[Jeff Garzik]

Jay Cliburn wrote:
> On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> 
>> If you ask me in the future about the status of a -stable
>> patch from the networking, I'll let you know exactly what
>> is happening to that patch wrt. stable.  I rarely forget
>> to submit an appropriate patch, and when I do forget you
>> merely have to let me know (rather than submitting it
>> to -stable directly, please don't do that) so that I can
>> fit it in with what I plan to submit to -stable already.
> 
> 
> As a netdev driver maintainer, I've been following this workflow for
> patches that need to go to -stable:
> 
> 1.  I submit a mainline patch to Jeff Garzik.
> 2.  Jeff submits to David.
> 3.  David submits to Linus.
> 4.  Linus merges patch into mainline.
> 5.  I extract mainline commit ID.
> 6.  I apply and test patch against appropriate 2.6.x.y git tree.
> 7.  I submit patch directly to -stable.
> 
> David's admonition tells me I'm doing it wrong, and that I should
> submit the stable patch to Jeff as well.  Am I right?

I usually encourage a more-parallel process where you simply email 
stable@kernel.org with the upstream commit id of the change(s) in question.

	Jeff

Re: [patch 00/50] 2.6.25.6 -stable review

[David Miller]

From: Jeff Garzik <jeff@garzik.org>
Date: Sun, 08 Jun 2008 16:07:47 -0400

> Jay Cliburn wrote:
> > David's admonition tells me I'm doing it wrong, and that I should
> > submit the stable patch to Jeff as well.  Am I right?
> 
> I usually encourage a more-parallel process where you simply email 
> stable@kernel.org with the upstream commit id of the change(s) in question.

Right, and if Jeff wants to work things that way for the
networking drivers that's fine.

Personally, I like to make sure some time passes between when
a fix goes into Linus's tree and when I push it into -stable
because time is often what shakes out the last remaining problems
introduced by some change no matter how seeming obvious the
patch is.