[PATCH 00/91] 2.6.27.60-longterm review

[PATCH 00/91] 2.6.27.60-longterm review

[Willy Tarreau]

This is the start of the longterm review cycle for the 2.6.27.60 release.
All patches will be posted as a response to this one.  If anyone has any
issues with these being applied, please let me 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 have been picked out of 647 patches that were merged between
2.6.32.39 and 2.6.32.56. A number of driver-specific patches which cannot be
tested without proper hardware have *not* been merged to keep the list low.
If you're having an issue with a specific driver with the 2.6.27 series and
you know the 2.6.32 series is OK, please report it to me, a fix might exist.

Responses should be made within 72 hours. Anything received after that
time might be too late.

Please note that the whole -rc patch is not provided anymore, only individual
patches are provided so that their authors and subsystem maintainers can spot
issues. The new release process does not make it as easy as before to upload
pre-release patches, and experience shows that release candidates are almost
never built for old kernels, users only build the final patch, so that's not
worth the pain. If this is a problem for you, please manifest yourself so that
we find a solution.

The diffstat is appened below.

 Documentation/kbuild/makefiles.txt         |   12 ++++++
 MAINTAINERS                                |    2 +-
 Makefile                                   |    5 ++-
 arch/alpha/kernel/osf_sys.c                |   11 +++--
 arch/arm/kernel/sys_oabi-compat.c          |    2 +-
 arch/parisc/mm/init.c                      |    4 +-
 arch/powerpc/kernel/crash.c                |    6 +--
 arch/powerpc/kernel/prom_init.c            |    6 +-
 arch/powerpc/oprofile/op_model_power4.c    |   24 +++++++++++-
 arch/powerpc/platforms/pseries/hvconsole.c |    2 +-
 arch/powerpc/platforms/pseries/lpar.c      |    2 +-
 arch/s390/kvm/kvm-s390.c                   |   14 +++++--
 arch/um/drivers/ubd_kern.c                 |   31 +++++++++++++++-
 arch/x86/kernel/amd_iommu_init.c           |    8 ++--
 arch/x86/kernel/reboot.c                   |    8 ++++
 arch/x86/lib/copy_user_64.S                |    4 +-
 arch/x86/mm/gup.c                          |   56 ++++++++++++++++++++++++++++
 arch/x86/mm/mmap.c                         |    4 +-
 arch/x86/oprofile/backtrace.c              |   46 +++++++++++++++++++++--
 arch/x86/oprofile/init.c                   |    7 ++-
 arch/x86/xen/smp.c                         |   10 +++++
 block/cfq-iosched.c                        |    8 +++-
 block/elevator.c                           |    3 +-
 block/scsi_ioctl.c                         |   40 ++++++++++++++++++++
 drivers/ata/libata-scsi.c                  |   24 +++++++++---
 drivers/ata/sata_via.c                     |   15 +++++++
 drivers/block/ub.c                         |    4 ++
 drivers/block/virtio_blk.c                 |    6 +++
 drivers/char/agp/generic.c                 |   19 +++++++--
 drivers/char/i8k.c                         |   11 +++--
 drivers/char/tpm/tpm.c                     |    9 ++++-
 drivers/ide/ide-floppy.c                   |    9 +++-
 drivers/md/dm-linear.c                     |   10 ++++-
 drivers/md/dm-mpath.c                      |    6 +++
 drivers/md/md.c                            |    2 +-
 drivers/media/video/uvc/uvc_queue.c        |    2 +
 drivers/mmc/host/sdhci-pci.c               |    1 +
 drivers/mmc/host/sdhci.c                   |    9 ++++-
 drivers/mtd/ubi/cdev.c                     |    3 +
 drivers/net/bonding/bond_3ad.c             |    7 +++
 drivers/net/bonding/bond_alb.c             |    7 +++
 drivers/net/bonding/bond_main.c            |    4 ++
 drivers/net/rionet.c                       |    4 +-
 drivers/net/wireless/libertas/cmd.c        |    6 ++-
 drivers/scsi/aacraid/commsup.c             |    2 +
 drivers/scsi/device_handler/scsi_dh.c      |    7 +++-
 drivers/scsi/hosts.c                       |    9 +++-
 drivers/scsi/libsas/sas_expander.c         |   13 ++++--
 drivers/scsi/scsi_lib.c                    |   15 ++++++-
 drivers/scsi/scsi_sysfs.c                  |   16 ++++----
 drivers/scsi/sd.c                          |   11 ++++-
 drivers/scsi/sym53c8xx_2/sym_glue.c        |    4 ++
 drivers/usb/musb/musb_core.c               |    1 +
 drivers/usb/serial/ftdi_sio.c              |   14 +++++-
 drivers/usb/storage/usb.c                  |    1 +
 drivers/video/carminefb.c                  |    6 +-
 drivers/video/offb.c                       |   52 ++++++++++++--------------
 fs/cifs/cifssmb.c                          |    3 +-
 fs/ext3/namei.c                            |   13 +++++-
 fs/ext3/xattr.c                            |   12 +++++-
 fs/ext4/extents.c                          |    1 +
 fs/ext4/inode.c                            |    2 +-
 fs/hfs/btree.c                             |   15 +++++++
 fs/hfs/trans.c                             |    2 +
 fs/jbd/journal.c                           |    8 ++++
 fs/jbd2/journal.c                          |    8 ++++
 fs/lockd/clntproc.c                        |    8 +++-
 fs/nfsd/export.c                           |    2 +-
 fs/nfsd/vfs.c                              |    9 ++++-
 fs/partitions/efi.c                        |    6 +++
 fs/partitions/ldm.c                        |   21 ++++++++--
 fs/partitions/osf.c                        |   12 +++++-
 fs/ubifs/recovery.c                        |   26 +++++++++++++
 include/asm-x86/uaccess.h                  |    2 +-
 include/linux/blkdev.h                     |    1 +
 include/linux/if_packet.h                  |    2 +
 include/linux/mm.h                         |    6 +++
 include/linux/seqlock.h                    |    4 +-
 include/linux/sunrpc/sched.h               |    4 +-
 init/Kconfig                               |    1 +
 kernel/taskstats.c                         |    1 +
 kernel/time/timekeeping.c                  |   11 ++++-
 mm/util.c                                  |   13 ++++++
 net/bluetooth/l2cap.c                      |    2 +-
 net/ipv4/af_inet.c                         |    3 +
 net/packet/af_packet.c                     |    2 +
 net/sched/sch_api.c                        |   14 +++---
 net/sunrpc/clnt.c                          |    3 +
 net/sunrpc/rpcb_clnt.c                     |    2 +-
 net/sunrpc/sched.c                         |    1 +
 net/sunrpc/svc.c                           |    3 +
 net/sunrpc/svc_xprt.c                      |   11 +++--
 net/sunrpc/xprtsock.c                      |   28 +++++++++++---
 net/unix/af_unix.c                         |   16 +++++++-
 scripts/Kbuild.include                     |    5 ++
 sound/core/timer.c                         |    2 +
 sound/pci/ice1712/amp.c                    |    7 ++-
 97 files changed, 751 insertions(+), 165 deletions(-)

[PATCH 01/91] UBIFS: fix master node recovery

[Willy Tarreau]

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

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

commit 6e0d9fd38b750d678bf9fd07db23582f52fafa55 upstream.

This patch fixes the following symptoms:
1. Unmount UBIFS cleanly.
2. Start mounting UBIFS R/W and have a power cut immediately
3. Start mounting UBIFS R/O, this succeeds
4. Try to re-mount UBIFS R/W - this fails immediately or later on,
   because UBIFS will write the master node to the flash area
   which has been written before.

The analysis of the problem:

1. UBIFS is unmounted cleanly, both copies of the master node are clean.
2. UBIFS is being mounter R/W, starts changing master node copy 1, and
   a power cut happens. The copy N1 becomes corrupted.
3. UBIFS is being mounted R/O. It notices the copy N1 is corrupted and
   reads copy N2. Copy N2 is clean.
4. Because of R/O mode, UBIFS cannot recover copy 1.
5. The mount code (ubifs_mount()) sees that the master node is clean,
   so it decides that no recovery is needed.
6. We are re-mounting R/W. UBIFS believes no recovery is needed and
   starts updating the master node, but copy N1 is still corrupted
   and was not recovered!

Fix this problem by marking the master node as dirty every time we
recover it and we are in R/O mode. This forces further recovery and
the UBIFS cleans-up the corruptions and recovers the copy N1 when
re-mounting R/W later.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/ubifs/recovery.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/fs/ubifs/recovery.c
===================================================================
--- longterm-2.6.27.orig/fs/ubifs/recovery.c	2012-02-05 22:34:35.037914818 +0100
+++ longterm-2.6.27/fs/ubifs/recovery.c	2012-02-05 22:34:35.088916370 +0100
@@ -280,6 +280,32 @@
 			goto out_free;
 		}
 		memcpy(c->rcvrd_mst_node, c->mst_node, UBIFS_MST_NODE_SZ);
+
+		/*
+		 * We had to recover the master node, which means there was an
+		 * unclean reboot. However, it is possible that the master node
+		 * is clean at this point, i.e., %UBIFS_MST_DIRTY is not set.
+		 * E.g., consider the following chain of events:
+		 *
+		 * 1. UBIFS was cleanly unmounted, so the master node is clean
+		 * 2. UBIFS is being mounted R/W and starts changing the master
+		 *    node in the first (%UBIFS_MST_LNUM). A power cut happens,
+		 *    so this LEB ends up with some amount of garbage at the
+		 *    end.
+		 * 3. UBIFS is being mounted R/O. We reach this place and
+		 *    recover the master node from the second LEB
+		 *    (%UBIFS_MST_LNUM + 1). But we cannot update the media
+		 *    because we are being mounted R/O. We have to defer the
+		 *    operation.
+		 * 4. However, this master node (@c->mst_node) is marked as
+		 *    clean (since the step 1). And if we just return, the
+		 *    mount code will be confused and won't recover the master
+		 *    node when it is re-mounter R/W later.
+		 *
+		 *    Thus, to force the recovery by marking the master node as
+		 *    dirty.
+		 */
+		c->mst_node->flags |= cpu_to_le32(UBIFS_MST_DIRTY);
 	} else {
 		/* Write the recovered master node */
 		c->max_sqnum = le64_to_cpu(mst->ch.sqnum) - 1;

[PATCH 02/91] slub: fix panic with DISCONTIGMEM

[Willy Tarreau]

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

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

commit 4a5fa3590f09999f6db41bc386bce40848fa9f63 upstream.

Slub makes assumptions about page_to_nid() which are violated by
DISCONTIGMEM and !NUMA.  This violation results in a panic because
page_to_nid() can be non-zero for pages in the discontiguous ranges and
this leads to a null return by get_node().  The assertion by the
maintainer is that DISCONTIGMEM should only be allowed when NUMA is also
defined.  However, at least six architectures: alpha, ia64, m32r, m68k,
mips, parisc violate this.  The panic is a regression against slab, so
just mark slub broken in the problem configuration to prevent users
reporting these panics.

Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 init/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/init/Kconfig
===================================================================
--- longterm-2.6.27.orig/init/Kconfig	2012-02-05 22:34:35.012915163 +0100
+++ longterm-2.6.27/init/Kconfig	2012-02-05 22:34:35.225915821 +0100
@@ -747,6 +747,7 @@
 	  a slab allocator.
 
 config SLUB
+	depends on BROKEN || NUMA || !DISCONTIGMEM
 	bool "SLUB (Unqueued Allocator)"
 	help
 	   SLUB is a slab allocator that minimizes cache line usage

[PATCH 03/91] set memory ranges in N_NORMAL_MEMORY when onlined

[Willy Tarreau]

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

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

commit d9b41e0b54fd7e164daf1e9c539c1070398aa02e upstream.

When a DISCONTIGMEM memory range is brought online as a NUMA node, it
also needs to have its bet set in N_NORMAL_MEMORY.  This is necessary for
generic kernel code that utilizes N_NORMAL_MEMORY as a subset of N_ONLINE
for memory savings.

These types of hacks can hopefully be removed once DISCONTIGMEM is either
removed or abstracted away from CONFIG_NUMA.

Fixes a panic in the slub code which only initializes structures for
N_NORMAL_MEMORY to save memory:

	Backtrace:
	 [<000000004021c938>] add_partial+0x28/0x98
	 [<000000004021faa0>] __slab_free+0x1d0/0x1d8
	 [<000000004021fd04>] kmem_cache_free+0xc4/0x128
	 [<000000004033bf9c>] ida_get_new_above+0x21c/0x2c0
	 [<00000000402a8980>] sysfs_new_dirent+0xd0/0x238
	 [<00000000402a974c>] create_dir+0x5c/0x168
	 [<00000000402a9ab0>] sysfs_create_dir+0x98/0x128
	 [<000000004033d6c4>] kobject_add_internal+0x114/0x258
	 [<000000004033d9ac>] kobject_add_varg+0x7c/0xa0
	 [<000000004033df20>] kobject_add+0x50/0x90
	 [<000000004033dfb4>] kobject_create_and_add+0x54/0xc8
	 [<00000000407862a0>] cgroup_init+0x138/0x1f0
	 [<000000004077ce50>] start_kernel+0x5a0/0x840
	 [<000000004011fa3c>] start_parisc+0xa4/0xb8
	 [<00000000404bb034>] packet_ioctl+0x16c/0x208
	 [<000000004049ac30>] ip_mroute_setsockopt+0x260/0xf20

Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/parisc/mm/init.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/arch/parisc/mm/init.c
===================================================================
--- longterm-2.6.27.orig/arch/parisc/mm/init.c	2012-02-05 22:34:34.989914901 +0100
+++ longterm-2.6.27/arch/parisc/mm/init.c	2012-02-05 22:34:35.362915231 +0100
@@ -265,8 +265,10 @@
 	}
 	memset(pfnnid_map, 0xff, sizeof(pfnnid_map));
 
-	for (i = 0; i < npmem_ranges; i++)
+	for (i = 0; i < npmem_ranges; i++) {
+		node_set_state(i, N_NORMAL_MEMORY);
 		node_set_online(i);
+	}
 #endif
 
 	/*

[PATCH 04/91] agp: fix arbitrary kernel memory writes

[Willy Tarreau]

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

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

commit 194b3da873fd334ef183806db751473512af29ce upstream.

pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
cmds of agp_ioctl() and passed to agpioc_bind_wrap().  As said in the
comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
and it is not checked at all in case of AGPIOC_UNBIND.  As a result, user
with sufficient privileges (usually "video" group) may generate either
local DoS or privilege escalation.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/agp/generic.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/char/agp/generic.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/agp/generic.c	2012-02-05 22:34:34.961915038 +0100
+++ longterm-2.6.27/drivers/char/agp/generic.c	2012-02-05 22:34:35.500916106 +0100
@@ -1099,8 +1099,8 @@
 		return -EINVAL;
 	}
 
-	/* AK: could wrap */
-	if ((pg_start + mem->page_count) > num_entries)
+	if (((pg_start + mem->page_count) > num_entries) ||
+	    ((pg_start + mem->page_count) < pg_start))
 		return -EINVAL;
 
 	j = pg_start;
@@ -1132,7 +1132,7 @@
 {
 	size_t i;
 	struct agp_bridge_data *bridge;
-	int mask_type;
+	int mask_type, num_entries;
 
 	bridge = mem->bridge;
 	if (!bridge)
@@ -1144,6 +1144,11 @@
 	if (type != mem->type)
 		return -EINVAL;
 
+	num_entries = agp_num_entries();
+	if (((pg_start + mem->page_count) > num_entries) ||
+	    ((pg_start + mem->page_count) < pg_start))
+		return -EINVAL;
+
 	mask_type = bridge->driver->agp_type_to_mask_type(bridge, type);
 	if (mask_type != 0) {
 		/* The generic routines know nothing of memory types */

[PATCH 05/91] agp: fix OOM and buffer overflow

[Willy Tarreau]

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

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

commit b522f02184b413955f3bc952e3776ce41edc6355 upstream.

page_count is copied from userspace.  agp_allocate_memory() tries to
check whether this number is too big, but doesn't take into account the
wrap case.  Also agp_create_user_memory() doesn't check whether
alloc_size is calculated from num_agp_pages variable without overflow.
This may lead to allocation of too small buffer with following buffer
overflow.

Another problem in agp code is not addressed in the patch - kernel memory
exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls).  It is not checked
whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()).
Each allocation is limited to 16KB, though, there is no per-process limit.
This might lead to OOM situation, which is not even solved in case of the
caller death by OOM killer - the memory is allocated for another (faked) process.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/agp/generic.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/char/agp/generic.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/agp/generic.c	2012-02-05 22:34:35.500916106 +0100
+++ longterm-2.6.27/drivers/char/agp/generic.c	2012-02-05 22:34:35.639914999 +0100
@@ -123,6 +123,9 @@
 	struct agp_memory *new;
 	unsigned long alloc_size = num_agp_pages*sizeof(struct page *);
 
+	if (INT_MAX/sizeof(struct page *) < num_agp_pages)
+		return NULL;
+
 	new = kzalloc(sizeof(struct agp_memory), GFP_KERNEL);
 	if (new == NULL)
 		return NULL;
@@ -236,11 +239,14 @@
 	int scratch_pages;
 	struct agp_memory *new;
 	size_t i;
+	int cur_memory;
 
 	if (!bridge)
 		return NULL;
 
-	if ((atomic_read(&bridge->current_memory_agp) + page_count) > bridge->max_memory_agp)
+	cur_memory = atomic_read(&bridge->current_memory_agp);
+	if ((cur_memory + page_count > bridge->max_memory_agp) ||
+	    (cur_memory + page_count < page_count))
 		return NULL;
 
 	if (type >= AGP_USER_TYPES) {

[PATCH 06/91] put stricter guards on queue dead checks

[Willy Tarreau]

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

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

commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream.

SCSI uses request_queue->queuedata == NULL as a signal that the queue
is dying.  We set this state in the sdev release function.  However,
this allows a small window where we release the last reference but
haven't quite got to this stage yet and so something will try to take
a reference in scsi_request_fn and oops.  It's very rare, but we had a
report here, so we're pushing this as a bug fix

The actual fix is to set request_queue->queuedata to NULL in
scsi_remove_device() before we drop the reference.  This causes
correct automatic rejects from scsi_request_fn as people who hold
additional references try to submit work and prevents anything from
getting a new reference to the sdev that way.

Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/scsi_sysfs.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

Index: longterm-2.6.27/drivers/scsi/scsi_sysfs.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/scsi_sysfs.c	2012-02-05 22:34:34.876915660 +0100
+++ longterm-2.6.27/drivers/scsi/scsi_sysfs.c	2012-02-05 22:34:35.776914691 +0100
@@ -317,14 +317,8 @@
 		kfree(evt);
 	}
 
-	if (sdev->request_queue) {
-		sdev->request_queue->queuedata = NULL;
-		/* user context needed to free queue */
-		scsi_free_queue(sdev->request_queue);
-		/* temporary expedient, try to catch use of queue lock
-		 * after free of sdev */
-		sdev->request_queue = NULL;
-	}
+	/* NULL queue means the device can't be used */
+	sdev->request_queue = NULL;
 
 	scsi_target_reap(scsi_target(sdev));
 
@@ -950,6 +944,12 @@
 	if (sdev->host->hostt->slave_destroy)
 		sdev->host->hostt->slave_destroy(sdev);
 	transport_destroy_device(dev);
+
+	/* cause the request function to reject all I/O requests */
+	sdev->request_queue->queuedata = NULL;
+
+	/* Freeing the queue signals to block that we're done */
+	scsi_free_queue(sdev->request_queue);
 	put_device(dev);
 }
 

[PATCH 07/91] mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()

[Willy Tarreau]

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

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

commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream.

If pci_ioremap_bar() fails during probe, we "goto release;" and free the
host, but then we return 0 -- which tells sdhci_pci_probe() that the probe
succeeded.  Since we think the probe succeeded, when we unload sdhci we'll
go to sdhci_pci_remove_slot() and it will try to dereference slot->host,
which is now NULL because we freed it in the error path earlier.

The patch simply sets ret appropriately, so that sdhci_pci_probe() will
detect the failure immediately and bail out.

Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/mmc/host/sdhci-pci.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/mmc/host/sdhci-pci.c
===================================================================
--- longterm-2.6.27.orig/drivers/mmc/host/sdhci-pci.c	2012-02-05 22:34:34.824917273 +0100
+++ longterm-2.6.27/drivers/mmc/host/sdhci-pci.c	2012-02-05 22:34:35.914915549 +0100
@@ -547,6 +547,7 @@
 	host->ioaddr = ioremap_nocache(addr, pci_resource_len(pdev, bar));
 	if (!host->ioaddr) {
 		dev_err(&pdev->dev, "failed to remap registers\n");
+		ret = -ENOMEM;
 		goto release;
 	}
 

[PATCH 08/91] mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish

[Willy Tarreau]

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

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

commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream.

It seems that under certain circumstances that the sdhci_tasklet_finish()
call can be entered with mrq->cmd set to NULL, causing the system to crash
with a NULL pointer de-reference.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
PC is at sdhci_tasklet_finish+0x34/0xe8
LR is at sdhci_tasklet_finish+0x24/0xe8

Seen on S3C6410 system.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/mmc/host/sdhci.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/mmc/host/sdhci.c
===================================================================
--- longterm-2.6.27.orig/drivers/mmc/host/sdhci.c	2012-02-05 22:34:34.798915250 +0100
+++ longterm-2.6.27/drivers/mmc/host/sdhci.c	2012-02-05 22:34:36.053916156 +0100
@@ -1176,7 +1176,7 @@
 	 * upon error conditions.
 	 */
 	if (!(host->flags & SDHCI_DEVICE_DEAD) &&
-		(mrq->cmd->error ||
+	    ((mrq->cmd && mrq->cmd->error) ||
 		 (mrq->data && (mrq->data->error ||
 		  (mrq->data->stop && mrq->data->stop->error))) ||
 		   (host->quirks & SDHCI_QUIRK_RESET_AFTER_REQUEST))) {

[PATCH 09/91] mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish

[Willy Tarreau]

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

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

commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream.

It seems that under certain circumstances the sdhci_tasklet_finish()
call can be entered with mrq set to NULL, causing the system to crash
with a NULL pointer de-reference.

Seen on S3C6410 system.  Based on a patch by Dimitris Papastamos.

Reported-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/mmc/host/sdhci.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/mmc/host/sdhci.c
===================================================================
--- longterm-2.6.27.orig/drivers/mmc/host/sdhci.c	2012-02-05 22:34:36.053916156 +0100
+++ longterm-2.6.27/drivers/mmc/host/sdhci.c	2012-02-05 22:34:36.192916064 +0100
@@ -1165,6 +1165,13 @@
 
 	host = (struct sdhci_host*)param;
 
+        /*
+         * If this tasklet gets rescheduled while running, it will
+         * be run again afterwards but without any active request.
+         */
+	if (!host->mrq)
+		return;
+
 	spin_lock_irqsave(&host->lock, flags);
 
 	del_timer(&host->timer);

[PATCH 10/91] af_unix: Only allow recv on connected seqpacket sockets.

[Willy Tarreau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

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

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

commit a05d2ad1c1f391c7f514a1d1e09b5417968a7d07 upstream.

This fixes the following oops discovered by Dan Aloni:
> Anyway, the following is the output of the Oops that I got on the
> Ubuntu kernel on which I first detected the problem
> (2.6.37-12-generic). The Oops that followed will be more useful, I
> guess.

>[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference
> at           (null)
> [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420
> [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0
> [ 5594.693720] Oops: 0002 [#1] SMP
> [ 5594.699888] last sysfs file:

The bug was that unix domain sockets use a pseduo packet for
connecting and accept uses that psudo packet to get the socket.
In the buggy seqpacket case we were allowing unconnected
sockets to call recvmsg and try to receive the pseudo packet.

That is always wrong and as of commit 7361c36c5 the pseudo
packet had become enough different from a normal packet
that the kernel started oopsing.

Do for seqpacket_recv what was done for seqpacket_send in 2.5
and only allow it on connected seqpacket sockets.

Tested-by: Dan Aloni <dan@aloni.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/unix/af_unix.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/net/unix/af_unix.c
===================================================================
--- longterm-2.6.27.orig/net/unix/af_unix.c	2012-02-05 22:34:34.711914871 +0100
+++ longterm-2.6.27/net/unix/af_unix.c	2012-02-05 22:34:36.344916818 +0100
@@ -501,6 +501,8 @@
 			      int, int);
 static int unix_seqpacket_sendmsg(struct kiocb *, struct socket *,
 				  struct msghdr *, size_t);
+static int unix_seqpacket_recvmsg(struct kiocb *, struct socket *,
+				  struct msghdr *, size_t, int);
 
 static const struct proto_ops unix_stream_ops = {
 	.family =	PF_UNIX,
@@ -560,7 +562,7 @@
 	.setsockopt =	sock_no_setsockopt,
 	.getsockopt =	sock_no_getsockopt,
 	.sendmsg =	unix_seqpacket_sendmsg,
-	.recvmsg =	unix_dgram_recvmsg,
+	.recvmsg =	unix_seqpacket_recvmsg,
 	.mmap =		sock_no_mmap,
 	.sendpage =	sock_no_sendpage,
 };
@@ -1617,6 +1619,18 @@
 	return unix_dgram_sendmsg(kiocb, sock, msg, len);
 }
 
+static int unix_seqpacket_recvmsg(struct kiocb *iocb, struct socket *sock,
+			      struct msghdr *msg, size_t size,
+			      int flags)
+{
+	struct sock *sk = sock->sk;
+
+	if (sk->sk_state != TCP_ESTABLISHED)
+		return -ENOTCONN;
+
+	return unix_dgram_recvmsg(iocb, sock, msg, size, flags);
+}
+
 static void unix_copy_addr(struct msghdr *msg, struct sock *sk)
 {
 	struct unix_sock *u = unix_sk(sk);

[PATCH 11/91] ARM: 6891/1: prevent heap corruption in OABI semtimedop

[Willy Tarreau]

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

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

commit 0f22072ab50cac7983f9660d33974b45184da4f9 upstream.

When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not
bound the nsops argument.  A sufficiently large value will cause an
integer overflow in allocation size, followed by copying too much data
into the allocated buffer.  Fix this by restricting nsops to SEMOPM.
Untested.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/arm/kernel/sys_oabi-compat.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/arch/arm/kernel/sys_oabi-compat.c
===================================================================
--- longterm-2.6.27.orig/arch/arm/kernel/sys_oabi-compat.c	2012-02-05 22:34:34.686915228 +0100
+++ longterm-2.6.27/arch/arm/kernel/sys_oabi-compat.c	2012-02-05 22:34:36.482915240 +0100
@@ -319,7 +319,7 @@
 	long err;
 	int i;
 
-	if (nsops < 1)
+	if (nsops < 1 || nsops > SEMOPM)
 		return -EINVAL;
 	sops = kmalloc(sizeof(*sops) * nsops, GFP_KERNEL);
 	if (!sops)

[PATCH 12/91] Open with O_CREAT flag set fails to open existing files on non writable directories

[Willy Tarreau]

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

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

commit 1574dff8996ab1ed92c09012f8038b5566fce313 upstream.

An open on a NFS4 share using the O_CREAT flag on an existing file for
which we have permissions to open but contained in a directory with no
write permissions will fail with EACCES.

A tcpdump shows that the client had set the open mode to UNCHECKED which
indicates that the file should be created if it doesn't exist and
encountering an existing flag is not an error. Since in this case the
file exists and can be opened by the user, the NFS server is wrong in
attempting to check create permissions on the parent directory.

The patch adds a conditional statement to check for create permissions
only if the file doesn't exist.

Signed-off-by: Sachin S. Prabhu <sprabhu@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/nfsd/vfs.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/fs/nfsd/vfs.c
===================================================================
--- longterm-2.6.27.orig/fs/nfsd/vfs.c	2012-02-05 22:34:34.659915205 +0100
+++ longterm-2.6.27/fs/nfsd/vfs.c	2012-02-05 22:34:36.622917202 +0100
@@ -1334,7 +1334,7 @@
 		goto out;
 	if (!(iap->ia_valid & ATTR_MODE))
 		iap->ia_mode = 0;
-	err = fh_verify(rqstp, fhp, S_IFDIR, NFSD_MAY_CREATE);
+	err = fh_verify(rqstp, fhp, S_IFDIR, NFSD_MAY_EXEC);
 	if (err)
 		goto out;
 
@@ -1356,6 +1356,13 @@
 	if (IS_ERR(dchild))
 		goto out_nfserr;
 
+	/* If file doesn't exist, check for permissions to create one */
+	if (!dchild->d_inode) {
+		err = fh_verify(rqstp, fhp, S_IFDIR, NFSD_MAY_CREATE);
+		if (err)
+			goto out;
+	}
+
 	err = fh_compose(resfhp, fhp->fh_export, dchild, fhp);
 	if (err)
 		goto out;

[PATCH 13/91] fs/partitions/ldm.c: fix oops caused by corrupted partition table

[Willy Tarreau]

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

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

commit c340b1d640001c8c9ecff74f68fd90422ae2448a upstream.

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains
a bug that causes a kernel oops on certain corrupted LDM partitions.
A kernel subsystem seems to crash, because, after the oops, the kernel no
longer recognizes newly connected storage devices.

The patch validates the value of vblk_size.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Richard Russon <rich@flatcap.org>
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>
---
 fs/partitions/ldm.c |   16 ++++++++++++----
 1 files changed, 12 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/fs/partitions/ldm.c
===================================================================
--- longterm-2.6.27.orig/fs/partitions/ldm.c	2012-02-05 22:34:34.635914935 +0100
+++ longterm-2.6.27/fs/partitions/ldm.c	2012-02-05 22:34:36.759915873 +0100
@@ -1299,6 +1299,11 @@
 
 	BUG_ON (!data || !frags);
 
+	if (size < 2 * VBLK_SIZE_HEAD) {
+		ldm_error("Value of size is to small.");
+		return false;
+	}
+
 	group = get_unaligned_be32(data + 0x08);
 	rec   = get_unaligned_be16(data + 0x0C);
 	num   = get_unaligned_be16(data + 0x0E);
@@ -1306,6 +1311,10 @@
 		ldm_error ("A VBLK claims to have %d parts.", num);
 		return false;
 	}
+	if (rec >= num) {
+		ldm_error("REC value (%d) exceeds NUM value (%d)", rec, num);
+		return false;
+	}
 
 	list_for_each (item, frags) {
 		f = list_entry (item, struct frag, list);
@@ -1334,10 +1343,9 @@
 
 	f->map |= (1 << rec);
 
-	if (num > 0) {
-		data += VBLK_SIZE_HEAD;
-		size -= VBLK_SIZE_HEAD;
-	}
+	data += VBLK_SIZE_HEAD;
+	size -= VBLK_SIZE_HEAD;
+
 	memcpy (f->data+rec*(size-VBLK_SIZE_HEAD)+VBLK_SIZE_HEAD, data, size);
 
 	return true;

[PATCH 14/91] SUNRPC: fix NFS client over TCP hangs due to packet loss (Bug 16494)

[Willy Tarreau]

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

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

commit 669502ff31d7dba1849aec7ee2450a3c61f57d39 upstream.

When reusing a TCP connection, ensure that it's aborted if a previous
shutdown attempt has been made on that connection so that the RPC over
TCP recovery mechanism succeeds.

Signed-off-by: Andy Chittenden <andyc.bluearc@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/sunrpc/xprtsock.c |   28 ++++++++++++++++++++++------
 1 files changed, 22 insertions(+), 6 deletions(-)

Index: longterm-2.6.27/net/sunrpc/xprtsock.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/xprtsock.c	2012-02-05 22:34:34.580914949 +0100
+++ longterm-2.6.27/net/sunrpc/xprtsock.c	2012-02-05 22:34:36.898916728 +0100
@@ -1126,10 +1126,11 @@
 	if (!(xprt = xprt_from_sock(sk)))
 		goto out;
 	dprintk("RPC:       xs_tcp_state_change client %p...\n", xprt);
-	dprintk("RPC:       state %x conn %d dead %d zapped %d\n",
+	dprintk("RPC:       state %x conn %d dead %d zapped %d sk_shutdown %d\n",
 			sk->sk_state, xprt_connected(xprt),
 			sock_flag(sk, SOCK_DEAD),
-			sock_flag(sk, SOCK_ZAPPED));
+			sock_flag(sk, SOCK_ZAPPED),
+			sk->sk_shutdown);
 
 	switch (sk->sk_state) {
 	case TCP_ESTABLISHED:
@@ -1594,10 +1595,25 @@
 {
 	unsigned int state = transport->inet->sk_state;
 
-	if (state == TCP_CLOSE && transport->sock->state == SS_UNCONNECTED)
-		return;
-	if ((1 << state) & (TCPF_ESTABLISHED|TCPF_SYN_SENT))
-		return;
+	if (state == TCP_CLOSE && transport->sock->state == SS_UNCONNECTED) {
+		/* we don't need to abort the connection if the socket
+		 * hasn't undergone a shutdown
+		 */
+		if (transport->inet->sk_shutdown == 0)
+			return;
+		dprintk("RPC:       %s: TCP_CLOSEd and sk_shutdown set to %d\n",
+				__func__, transport->inet->sk_shutdown);
+	}
+	if ((1 << state) & (TCPF_ESTABLISHED|TCPF_SYN_SENT)) {
+		/* we don't need to abort the connection if the socket
+		 * hasn't undergone a shutdown
+		 */
+		if (transport->inet->sk_shutdown == 0)
+			return;
+		dprintk("RPC:       %s: ESTABLISHED/SYN_SENT "
+				"sk_shutdown set to %d\n",
+				__func__, transport->inet->sk_shutdown);
+	}
 	xs_abort_connection(xprt, transport);
 }
 

[PATCH 15/91] Fix corrupted OSF partition table parsing

[Willy Tarreau]

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

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

commit 1eafbfeb7bdf59cfe173304c76188f3fd5f1fd05 upstream.

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating OSF partitions contains a bug that leaks data
from kernel heap memory to userspace for certain corrupted OSF
partitions.

In more detail:

  for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) {

iterates from 0 to d_npartitions - 1, where d_npartitions is read from
the partition table without validation and partition is a pointer to an
array of at most 8 d_partitions.

Add the proper and obvious validation.

Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: stable@kernel.org
[ Changed the patch trivially to not repeat the whole le16_to_cpu()
  thing, and to use an explicit constant for the magic value '8' ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/partitions/osf.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/fs/partitions/osf.c
===================================================================
--- longterm-2.6.27.orig/fs/partitions/osf.c	2012-02-05 22:34:34.555915472 +0100
+++ longterm-2.6.27/fs/partitions/osf.c	2012-02-05 22:34:37.034915210 +0100
@@ -10,10 +10,13 @@
 #include "check.h"
 #include "osf.h"
 
+#define MAX_OSF_PARTITIONS 8
+
 int osf_partition(struct parsed_partitions *state, struct block_device *bdev)
 {
 	int i;
 	int slot = 1;
+	unsigned int npartitions;
 	Sector sect;
 	unsigned char *data;
 	struct disklabel {
@@ -45,7 +48,7 @@
 			u8  p_fstype;
 			u8  p_frag;
 			__le16 p_cpg;
-		} d_partitions[8];
+		} d_partitions[MAX_OSF_PARTITIONS];
 	} * label;
 	struct d_partition * partition;
 
@@ -63,7 +66,12 @@
 		put_dev_sector(sect);
 		return 0;
 	}
-	for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) {
+	npartitions = le16_to_cpu(label->d_npartitions);
+	if (npartitions > MAX_OSF_PARTITIONS) {
+		put_dev_sector(sect);
+		return 0;
+	}
+	for (i = 0 ; i < npartitions; i++, partition++) {
 		if (slot == state->limit)
 		        break;
 		if (le32_to_cpu(partition->p_size))

[PATCH 16/91] sata_via: Delay on vt6420 when starting ATAPI DMA write

[Willy Tarreau]

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

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

commit a55ab496ea9c820b7192c15ef1fbf3291edfe638 upstream.

When writing a disc on certain lite-on dvd-writers (also rebadged
as optiarc/LG/...) connected to a vt6420, the ATAPI CDB ends
up in the datastream and on the disc, causing silent corruption.
Delaying between sending the CDB and starting DMA seems to
prevent this.

I do not know if there are burners that do not suffer from
this, but the patch should be safe for those as well.

There are many reports of this issue, but AFAICT no solution was
found before. For example:
http://lkml.indiana.edu/hypermail/linux/kernel/0802.3/0561.html

Signed-off-by: Bart Hartgers <bart.hartgers@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
[bwh: Remove version bump for 2.6.32]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/ata/sata_via.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/ata/sata_via.c
===================================================================
--- longterm-2.6.27.orig/drivers/ata/sata_via.c	2012-02-05 22:34:34.531916020 +0100
+++ longterm-2.6.27/drivers/ata/sata_via.c	2012-02-05 22:34:37.173915226 +0100
@@ -40,6 +40,8 @@
 #include <linux/blkdev.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_host.h>
 #include <linux/libata.h>
 
@@ -72,6 +74,7 @@
 static int svia_scr_write(struct ata_port *ap, unsigned int sc_reg, u32 val);
 static void svia_noop_freeze(struct ata_port *ap);
 static int vt6420_prereset(struct ata_link *link, unsigned long deadline);
+static void vt6420_bmdma_start(struct ata_queued_cmd *qc);
 static int vt6421_pata_cable_detect(struct ata_port *ap);
 static void vt6421_set_pio_mode(struct ata_port *ap, struct ata_device *adev);
 static void vt6421_set_dma_mode(struct ata_port *ap, struct ata_device *adev);
@@ -107,6 +110,7 @@
 	.inherits		= &ata_bmdma_port_ops,
 	.freeze			= svia_noop_freeze,
 	.prereset		= vt6420_prereset,
+	.bmdma_start		= vt6420_bmdma_start,
 };
 
 static struct ata_port_operations vt6421_pata_ops = {
@@ -247,6 +251,17 @@
 	return 0;
 }
 
+static void vt6420_bmdma_start(struct ata_queued_cmd *qc)
+{
+	struct ata_port *ap = qc->ap;
+	if ((qc->tf.command == ATA_CMD_PACKET) &&
+	    (qc->scsicmd->sc_data_direction == DMA_TO_DEVICE)) {
+		/* Prevents corruption on some ATAPI burners */
+		ata_sff_pause(ap);
+	}
+	ata_bmdma_start(qc);
+}
+
 static int vt6421_pata_cable_detect(struct ata_port *ap)
 {
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);

[PATCH 17/91] libata: set queue DMA alignment to sector size for ATAPI too

[Willy Tarreau]

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

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

commit 729a6a300e628a48cf12bac93a964a535e83cd1d upstream.

ata_pio_sectors() expects buffer for each sector to be contained in a
single page; otherwise, it ends up overrunning the first page.  This
is achieved by setting queue DMA alignment.  If sector_size is smaller
than PAGE_SIZE and all buffers are sector_size aligned, buffer for
each sector is always contained in a single page.

This wasn't applied to ATAPI devices but IDENTIFY_PACKET is executed
as ATA_PROT_PIO and thus uses ata_pio_sectors().  Newer versions of
udev issue IDENTIFY_PACKET with unaligned buffer triggering the
problem and causing oops.

This patch fixes the problem by setting sdev->sector_size to
ATA_SECT_SIZE on ATATPI devices and always setting DMA alignment to
sector_size.  While at it, add a warning for the unlikely but still
possible scenario where sector_size is larger than PAGE_SIZE, in which
case the alignment wouldn't be enough.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: John Stanley <jpsinthemix@verizon.net>
Tested-by: John Stanley <jpsinthemix@verizon.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/ata/libata-scsi.c |   24 ++++++++++++++++++------
 1 files changed, 18 insertions(+), 6 deletions(-)

Index: longterm-2.6.27/drivers/ata/libata-scsi.c
===================================================================
--- longterm-2.6.27.orig/drivers/ata/libata-scsi.c	2012-02-05 22:34:34.505914937 +0100
+++ longterm-2.6.27/drivers/ata/libata-scsi.c	2012-02-05 22:34:37.312916183 +0100
@@ -957,13 +957,13 @@
 	/* configure max sectors */
 	blk_queue_max_sectors(sdev->request_queue, dev->max_sectors);
 
+	sdev->sector_size = ATA_SECT_SIZE;
+
 	if (dev->class == ATA_DEV_ATAPI) {
 		struct request_queue *q = sdev->request_queue;
 		void *buf;
 
-		/* set the min alignment and padding */
-		blk_queue_update_dma_alignment(sdev->request_queue,
-					       ATA_DMA_PAD_SZ - 1);
+		/* set DMA padding */
 		blk_queue_update_dma_pad(sdev->request_queue,
 					 ATA_DMA_PAD_SZ - 1);
 
@@ -977,12 +977,24 @@
 
 		blk_queue_dma_drain(q, atapi_drain_needed, buf, ATAPI_MAX_DRAIN);
 	} else {
-		/* ATA devices must be sector aligned */
-		blk_queue_update_dma_alignment(sdev->request_queue,
-					       ATA_SECT_SIZE - 1);
 		sdev->manage_start_stop = 1;
 	}
 
+	/*
+	 * ata_pio_sectors() expects buffer for each sector to not cross
+	 * page boundary.  Enforce it by requiring buffers to be sector
+	 * aligned, which works iff sector_size is not larger than
+	 * PAGE_SIZE.  ATAPI devices also need the alignment as
+	 * IDENTIFY_PACKET is executed as ATA_PROT_PIO.
+	 */
+	if (sdev->sector_size > PAGE_SIZE)
+		ata_dev_printk(dev, KERN_WARNING,
+			"sector_size=%u > PAGE_SIZE, PIO may malfunction\n",
+			sdev->sector_size);
+
+	blk_queue_update_dma_alignment(sdev->request_queue,
+				       sdev->sector_size - 1);
+
 	if (dev->flags & ATA_DFLAG_AN)
 		set_bit(SDEV_EVT_MEDIA_CHANGE, sdev->supported_events);
 

[PATCH 18/91] usb: musb: core: set has_tt flag

[Willy Tarreau]

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

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

commit ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 upstream.

MUSB is a non-standard host implementation which
can handle all speeds with the same core. We need
to set has_tt flag after commit
d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent
buggy hubs from crashing the USB stack) in order for
MUSB HCD to continue working.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Michael Jones <michael.jones@matrix-vision.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/usb/musb/musb_core.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/usb/musb/musb_core.c
===================================================================
--- longterm-2.6.27.orig/drivers/usb/musb/musb_core.c	2012-02-05 22:34:34.480915184 +0100
+++ longterm-2.6.27/drivers/usb/musb/musb_core.c	2012-02-05 22:34:37.452915834 +0100
@@ -1792,6 +1792,7 @@
 	INIT_LIST_HEAD(&musb->out_bulk);
 
 	hcd->uses_new_polling = 1;
+	hcd->has_tt = 1;
 
 	musb->vbuserr_retry = VBUSERR_RETRY_COUNT;
 #else

[PATCH 19/91] Validate size of EFI GUID partition entries.

[Willy Tarreau]

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

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

commit fa039d5f6b126fbd65eefa05db2f67e44df8f121 upstream.

Otherwise corrupted EFI partition tables can cause total confusion.

Signed-off-by: Timo Warns <warns@pre-sense.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/partitions/efi.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/fs/partitions/efi.c
===================================================================
--- longterm-2.6.27.orig/fs/partitions/efi.c	2012-02-05 22:34:34.453915054 +0100
+++ longterm-2.6.27/fs/partitions/efi.c	2012-02-05 22:34:37.590915121 +0100
@@ -343,6 +343,12 @@
 		goto fail;
 	}
 
+	/* Check that sizeof_partition_entry has the correct value */
+	if (le32_to_cpu((*gpt)->sizeof_partition_entry) != sizeof(gpt_entry)) {
+		pr_debug("GUID Partitition Entry Size check failed.\n");
+		goto fail;
+	}
+
 	if (!(*ptes = alloc_read_gpt_entries(bdev, *gpt)))
 		goto fail;
 

[PATCH 20/91] libertas: fix cmdpendingq locking

[Willy Tarreau]

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

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

commit 2ae1b8b35faba31a59b153cbad07f9c15de99740 upstream.

We occasionally see list corruption using libertas.

While we haven't been able to diagnose this precisely, we have spotted
a possible cause: cmdpendingq is generally modified with driver_lock
held. However, there are a couple of points where this is not the case.

Fix up those operations to execute under the lock, it seems like
the correct thing to do and will hopefully improve the situation.

Signed-off-by: Paul Fox <pgf@laptop.org>
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/wireless/libertas/cmd.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/drivers/net/wireless/libertas/cmd.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/wireless/libertas/cmd.c	2012-02-05 22:34:34.401915241 +0100
+++ longterm-2.6.27/drivers/net/wireless/libertas/cmd.c	2012-02-05 22:34:37.731916421 +0100
@@ -1751,8 +1751,8 @@
 				    cpu_to_le16(CMD_SUBCMD_EXIT_PS)) {
 					lbs_deb_host(
 					       "EXEC_NEXT_CMD: ignore ENTER_PS cmd\n");
-					list_del(&cmdnode->list);
 					spin_lock_irqsave(&priv->driver_lock, flags);
+					list_del(&cmdnode->list);
 					lbs_complete_command(priv, cmdnode, 0);
 					spin_unlock_irqrestore(&priv->driver_lock, flags);
 
@@ -1764,8 +1764,8 @@
 				    (priv->psstate == PS_STATE_PRE_SLEEP)) {
 					lbs_deb_host(
 					       "EXEC_NEXT_CMD: ignore EXIT_PS cmd in sleep\n");
-					list_del(&cmdnode->list);
 					spin_lock_irqsave(&priv->driver_lock, flags);
+					list_del(&cmdnode->list);
 					lbs_complete_command(priv, cmdnode, 0);
 					spin_unlock_irqrestore(&priv->driver_lock, flags);
 					priv->needtowakeup = 1;
@@ -1778,7 +1778,9 @@
 				       "EXEC_NEXT_CMD: sending EXIT_PS\n");
 			}
 		}
+		spin_lock_irqsave(&priv->driver_lock, flags);
 		list_del(&cmdnode->list);
+		spin_unlock_irqrestore(&priv->driver_lock, flags);
 		lbs_deb_host("EXEC_NEXT_CMD: sending command 0x%04x\n",
 			    le16_to_cpu(cmd->command));
 		lbs_submit_command(priv, cmdnode);

[PATCH 21/91] powerpc/oprofile: Handle events that raise an exception without overflowing

[Willy Tarreau]

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

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

commit ad5d5292f16c6c1d7d3e257c4c7407594286b97e upstream.

Commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 fixes a situation on POWER7
where events can roll back if a specualtive event doesn't actually complete.
This can raise a performance monitor exception.  We need to catch this to ensure
that we reset the PMC.  In all cases the PMC will be less than 256 cycles from
overflow.

This patch lifts Anton's fix for the problem in perf and applies it to oprofile
as well.

Signed-off-by: Eric B Munson <emunson@mgebm.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/powerpc/oprofile/op_model_power4.c |   24 +++++++++++++++++++++++-
 1 files changed, 23 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/arch/powerpc/oprofile/op_model_power4.c
===================================================================
--- longterm-2.6.27.orig/arch/powerpc/oprofile/op_model_power4.c	2012-02-05 22:34:34.372915404 +0100
+++ longterm-2.6.27/arch/powerpc/oprofile/op_model_power4.c	2012-02-05 22:34:37.870914576 +0100
@@ -254,6 +254,28 @@
 	return is_kernel;
 }
 
+static bool pmc_overflow(unsigned long val)
+{
+	if ((int)val < 0)
+		return true;
+
+	/*
+	 * Events on POWER7 can roll back if a speculative event doesn't
+	 * eventually complete. Unfortunately in some rare cases they will
+	 * raise a performance monitor exception. We need to catch this to
+	 * ensure we reset the PMC. In all cases the PMC will be 256 or less
+	 * cycles from overflow.
+	 *
+	 * We only do this if the first pass fails to find any overflowing
+	 * PMCs because a user might set a period of less than 256 and we
+	 * don't want to mistakenly reset them.
+	 */
+	if (__is_processor(PV_POWER7) && ((0x80000000 - val) <= 256))
+		return true;
+
+	return false;
+}
+
 static void power4_handle_interrupt(struct pt_regs *regs,
 				    struct op_counter_config *ctr)
 {
@@ -274,7 +296,7 @@
 
 	for (i = 0; i < cur_cpu_spec->num_pmcs; ++i) {
 		val = classic_ctr_read(i);
-		if (val < 0) {
+		if (pmc_overflow(val)) {
 			if (oprofile_running && ctr[i].enabled) {
 				oprofile_add_ext_sample(pc, regs, i, is_kernel);
 				classic_ctr_write(i, reset_value[i]);

[PATCH 22/91] ext3: Fix fs corruption when make_indexed_dir() fails

[Willy Tarreau]

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

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

commit 86c4f6d85595cd7da635dc6985d27bfa43b1ae10 upstream.

When make_indexed_dir() fails (e.g. because of ENOSPC) after it has allocated
block for index tree root, we did not properly mark all changed buffers dirty.
This lead to only some of these buffers being written out and thus effectively
corrupting the directory.

Fix the issue by marking all changed data dirty even in the error failure case.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/ext3/namei.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/fs/ext3/namei.c
===================================================================
--- longterm-2.6.27.orig/fs/ext3/namei.c	2012-02-05 22:34:34.345914859 +0100
+++ longterm-2.6.27/fs/ext3/namei.c	2012-02-05 22:34:38.012917109 +0100
@@ -1430,10 +1430,19 @@
 	frame->at = entries;
 	frame->bh = bh;
 	bh = bh2;
+	/*
+	 * Mark buffers dirty here so that if do_split() fails we write a
+	 * consistent set of buffers to disk.
+	 */
+	ext3_journal_dirty_metadata(handle, frame->bh);
+	ext3_journal_dirty_metadata(handle, bh);
 	de = do_split(handle,dir, &bh, frame, &hinfo, &retval);
-	dx_release (frames);
-	if (!(de))
+	if (!de) {
+		ext3_mark_inode_dirty(handle, dir);
+		dx_release(frames);
 		return retval;
+	}
+	dx_release(frames);
 
 	return add_dirent_to_buf(handle, dentry, inode, de, bh);
 }

[PATCH 23/91] Fix for buffer overflow in ldm_frag_add not sufficient

[Willy Tarreau]

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

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

commit cae13fe4cc3f24820ffb990c09110626837e85d4 upstream.

As Ben Hutchings discovered [1], the patch for CVE-2011-1017 (buffer
overflow in ldm_frag_add) is not sufficient.  The original patch in
commit c340b1d64000 ("fs/partitions/ldm.c: fix oops caused by corrupted
partition table") does not consider that, for subsequent fragments,
previously allocated memory is used.

[1] http://lkml.org/lkml/2011/5/6/407

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Timo Warns <warns@pre-sense.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/partitions/ldm.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/fs/partitions/ldm.c
===================================================================
--- longterm-2.6.27.orig/fs/partitions/ldm.c	2012-02-05 22:34:36.759915873 +0100
+++ longterm-2.6.27/fs/partitions/ldm.c	2012-02-05 22:34:38.150914572 +0100
@@ -1335,6 +1335,11 @@
 
 	list_add_tail (&f->list, frags);
 found:
+	if (rec >= f->num) {
+		ldm_error("REC value (%d) exceeds NUM value (%d)", rec, f->num);
+		return false;
+	}
+
 	if (f->map & (1 << rec)) {
 		ldm_error ("Duplicate VBLK, part %d.", rec);
 		f->map &= 0x7F;			/* Mark the group as broken */

[PATCH 24/91] seqlock: Dont smp_rmb in seqlock reader spin loop

[Willy Tarreau]

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

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

commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.

Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.

A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active.  Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.

Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.

A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.

At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock.  I defer that the future.

While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.

Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 include/linux/seqlock.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/include/linux/seqlock.h
===================================================================
--- longterm-2.6.27.orig/include/linux/seqlock.h	2012-02-05 22:34:34.295914918 +0100
+++ longterm-2.6.27/include/linux/seqlock.h	2012-02-05 22:34:38.288914818 +0100
@@ -88,12 +88,12 @@
 	unsigned ret;
 
 repeat:
-	ret = sl->sequence;
-	smp_rmb();
+	ret = ACCESS_ONCE(sl->sequence);
 	if (unlikely(ret & 1)) {
 		cpu_relax();
 		goto repeat;
 	}
+	smp_rmb();
 
 	return ret;
 }

[PATCH 25/91] x86/amd-iommu: Fix 3 possible endless loops

[Willy Tarreau]

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

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

commit 0de66d5b35ee148455e268b2782873204ffdef4b upstream.

The driver contains several loops counting on an u16 value
where the exit-condition is checked against variables that
can have values up to 0xffff. In this case the loops will
never exit. This patch fixed 3 such loops.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/kernel/amd_iommu_init.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/arch/x86/kernel/amd_iommu_init.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/kernel/amd_iommu_init.c	2012-02-05 22:34:34.270914795 +0100
+++ longterm-2.6.27/arch/x86/kernel/amd_iommu_init.c	2012-02-05 22:34:38.426915208 +0100
@@ -538,8 +538,8 @@
 {
 	u8 *p = (u8 *)h;
 	u8 *end = p, flags = 0;
-	u16 dev_i, devid = 0, devid_start = 0, devid_to = 0;
-	u32 ext_flags = 0;
+	u16 devid = 0, devid_start = 0, devid_to = 0;
+	u32 dev_i, ext_flags = 0;
 	bool alias = false;
 	struct ivhd_entry *e;
 
@@ -638,7 +638,7 @@
 /* Initializes the device->iommu mapping for the driver */
 static int __init init_iommu_devices(struct amd_iommu *iommu)
 {
-	u16 i;
+	u32 i;
 
 	for (i = iommu->first_device; i <= iommu->last_device; ++i)
 		set_iommu_for_device(iommu, i);
@@ -833,7 +833,7 @@
  */
 static void init_device_table(void)
 {
-	u16 devid;
+	u32 devid;
 
 	for (devid = 0; devid <= amd_iommu_last_bdf; ++devid) {
 		set_dev_entry_bit(devid, DEV_ENTRY_VALID);

[PATCH 26/91] md: check ->hot_remove_disk when removing disk

[Willy Tarreau]

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

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

commit 01393f3d5836b7d62e925e6f4658a7eb22b83a11 upstream.

Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store()
during disk removal. The linear personality only has ->hot_add_disk and
no ->hot_remove_disk, so that removing disk in the array resulted to
following kernel bug:

$ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3]
$ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot
 BUG: unable to handle kernel NULL pointer dereference at           (null)
 IP: [<          (null)>]           (null)
 PGD c9f5d067 PUD 8575a067 PMD 0
 Oops: 0010 [#1] SMP
 CPU 2
 Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sg

 Pid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO
 RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
 RSP: 0018:ffff880085757df0  EFLAGS: 00010282
 RAX: ffffffffa00168e0 RBX: ffff8800d1431800 RCX: 000000000000006e
 RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff88008543c000
 RBP: ffff880085757e48 R08: 0000000000000002 R09: 000000000000000a
 R10: 0000000000000000 R11: ffff88008543c2e0 R12: 00000000ffffffff
 R13: ffff8800b4641000 R14: 0000000000000005 R15: 0000000000000000
 FS:  00007fe8c9e05700(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000000 CR3: 00000000b4502000 CR4: 00000000000406e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process tee (pid: 10450, threadinfo ffff880085756000, task ffff8800c9f08000)
 Stack:
  ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000
  ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90
  ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98
 Call Trace:
  [<ffffffff8138496a>] ? slot_store+0xaa/0x265
  [<ffffffff81384bae>] rdev_attr_store+0x89/0xa8
  [<ffffffff8115a96a>] sysfs_write_file+0x108/0x144
  [<ffffffff81106b87>] vfs_write+0xb1/0x10d
  [<ffffffff8106e6c0>] ? trace_hardirqs_on_caller+0x111/0x135
  [<ffffffff81106cac>] sys_write+0x4d/0x77
  [<ffffffff814fe702>] system_call_fastpath+0x16/0x1b
 Code:  Bad RIP value.
 RIP  [<          (null)>]           (null)
  RSP <ffff880085757df0>
 CR2: 0000000000000000
 ---[ end trace ba5fc64319a826fb ]---

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/md/md.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/md/md.c
===================================================================
--- longterm-2.6.27.orig/drivers/md/md.c	2012-02-05 22:34:34.241915006 +0100
+++ longterm-2.6.27/drivers/md/md.c	2012-02-05 22:34:38.571917468 +0100
@@ -2002,7 +2002,7 @@
 		if (rdev->raid_disk == -1)
 			return -EEXIST;
 		/* personality does all needed checks */
-		if (rdev->mddev->pers->hot_add_disk == NULL)
+		if (rdev->mddev->pers->hot_remove_disk == NULL)
 			return -EINVAL;
 		err = rdev->mddev->pers->
 			hot_remove_disk(rdev->mddev, rdev->raid_disk);

[PATCH 27/91] uvcvideo: Remove buffers from the queues when freeing

[Willy Tarreau]

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

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

commit 8ca2c80b170c47eeb55f0c2a0f2b8edf85f35d49 upstream.

When freeing memory for the video buffers also remove them from the
irq & main queues.

This fixes an oops when doing the following:

open ("/dev/video", ..)
VIDIOC_REQBUFS
VIDIOC_QBUF
VIDIOC_REQBUFS
close ()

As the second VIDIOC_REQBUFS will cause the list entries of the buffers
to be cleared while they still hang around on the main and irc queues

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/media/video/uvc/uvc_queue.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/media/video/uvc/uvc_queue.c
===================================================================
--- longterm-2.6.27.orig/drivers/media/video/uvc/uvc_queue.c	2012-02-05 22:34:34.215915503 +0100
+++ longterm-2.6.27/drivers/media/video/uvc/uvc_queue.c	2012-02-05 22:34:38.711914474 +0100
@@ -165,6 +165,8 @@
 	}
 
 	if (queue->count) {
+		uvc_queue_cancel(queue, 0);
+		INIT_LIST_HEAD(&queue->mainqueue);
 		vfree(queue->mem);
 		queue->count = 0;
 	}

[PATCH 28/91] cfq-iosched: fix locking around ioc->ioc_data assignment

[Willy Tarreau]

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

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

commit ab4bd22d3cce6977dc039664cc2d052e3147d662 upstream.

Since we are modifying this RCU pointer, we need to hold
the lock protecting it around it.

This fixes a potential reuse and double free of a cfq
io_context structure. The bug has been in CFQ for a long
time, it hit very few people but those it did hit seemed
to see it a lot.

Tracked in RH bugzilla here:

https://bugzilla.redhat.com/show_bug.cgi?id=577968

Credit goes to Paul Bolle for figuring out that the issue
was around the one-hit ioc->ioc_data cache. Thanks to his
hard work the issue is now fixed.

Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 block/cfq-iosched.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/block/cfq-iosched.c
===================================================================
--- longterm-2.6.27.orig/block/cfq-iosched.c	2012-02-05 22:34:34.185915429 +0100
+++ longterm-2.6.27/block/cfq-iosched.c	2012-02-05 22:34:38.850917663 +0100
@@ -1286,8 +1286,11 @@
 	cic->dead_key = (unsigned long) cic->key;
 	cic->key = NULL;
 
-	if (ioc->ioc_data == cic)
+	if (rcu_dereference(ioc->ioc_data) == cic) {
+		spin_lock(&ioc->lock);
 		rcu_assign_pointer(ioc->ioc_data, NULL);
+		spin_unlock(&ioc->lock);
+	}
 
 	if (cic->cfqq[ASYNC]) {
 		cfq_exit_cfqq(cfqd, cic->cfqq[ASYNC]);

[PATCH 29/91] cfq-iosched: fix a rcu warning

[Willy Tarreau]

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

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

commit 3181faa85bda3dc3f5e630a1846526c9caaa38e3 upstream.

I got a rcu warnning at boot. the ioc->ioc_data is rcu_deferenced, but
doesn't hold rcu_read_lock.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 block/cfq-iosched.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/block/cfq-iosched.c
===================================================================
--- longterm-2.6.27.orig/block/cfq-iosched.c	2012-02-05 22:34:38.850917663 +0100
+++ longterm-2.6.27/block/cfq-iosched.c	2012-02-05 22:34:38.987917155 +0100
@@ -1286,11 +1286,14 @@
 	cic->dead_key = (unsigned long) cic->key;
 	cic->key = NULL;
 
+	rcu_read_lock();
 	if (rcu_dereference(ioc->ioc_data) == cic) {
+		rcu_read_unlock();
 		spin_lock(&ioc->lock);
 		rcu_assign_pointer(ioc->ioc_data, NULL);
 		spin_unlock(&ioc->lock);
-	}
+	} else
+		rcu_read_unlock();
 
 	if (cic->cfqq[ASYNC]) {
 		cfq_exit_cfqq(cfqd, cic->cfqq[ASYNC]);

[PATCH 30/91] SUNRPC: Fix use of static variable in rpcb_getport_async

[Willy Tarreau]

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

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

commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 upstream.

Because struct rpcbind_args *map was declared static, if two
threads entered this method at the same time, the values
assigned to map could be sent two two differen tasks.
This could cause all sorts of problems, include use-after-free
and double-free of memory.

Fix this by removing the static declaration so that the map
pointer is on the stack.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/sunrpc/rpcb_clnt.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/net/sunrpc/rpcb_clnt.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/rpcb_clnt.c	2012-02-05 22:34:34.111915926 +0100
+++ longterm-2.6.27/net/sunrpc/rpcb_clnt.c	2012-02-05 22:34:39.126915071 +0100
@@ -505,7 +505,7 @@
 	u32 bind_version;
 	struct rpc_xprt *xprt;
 	struct rpc_clnt	*rpcb_clnt;
-	static struct rpcbind_args *map;
+	struct rpcbind_args *map;
 	struct rpc_task	*child;
 	struct sockaddr_storage addr;
 	struct sockaddr *sap = (struct sockaddr *)&addr;

[PATCH 31/91] x86: Make Dell Latitude E5420 use reboot=pci

[Willy Tarreau]

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

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

commit b7798d28ec15d20fd34b70fa57eb13f0cf6d1ecd upstream.

Rebooting on the Dell E5420 often hangs with the keyboard or ACPI
methods, but is reliable via the PCI method.

[ hpa: this was deferred because we believed for a long time that the
  recent reshuffling of the boot priorities in commit
  660e34cebf0a11d54f2d5dd8838607452355f321 fixed this platform.
  Unfortunately that turned out to be incorrect. ]

Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/kernel/reboot.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/arch/x86/kernel/reboot.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/kernel/reboot.c	2012-02-05 22:34:34.087914934 +0100
+++ longterm-2.6.27/arch/x86/kernel/reboot.c	2012-02-05 22:34:39.265915394 +0100
@@ -227,6 +227,14 @@
 			DMI_MATCH(DMI_BOARD_NAME, "P4S800"),
 		},
 	},
+	{	/* Handle problems with rebooting on the Latitude E5420. */
+		.callback = set_pci_reboot,
+		.ident = "Dell Latitude E5420",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"),
+		},
+	},
 	{ }
 };
 

[PATCH 32/91] libsas: remove expander from dev list on error

[Willy Tarreau]

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

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

commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.

If expander discovery fails (sas_discover_expander()), remove the
expander from the port device list (sas_ex_discover_expander()),
before freeing it. Else the list is corrupted and, e.g., when we
attempt to send SMP commands to other devices, the kernel oopses.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Reviewed-by: Jack Wang <jack_wang@usish.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/libsas/sas_expander.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/scsi/libsas/sas_expander.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/libsas/sas_expander.c	2012-02-05 22:34:34.059914940 +0100
+++ longterm-2.6.27/drivers/scsi/libsas/sas_expander.c	2012-02-05 22:34:39.404915902 +0100
@@ -839,6 +839,9 @@
 
 	res = sas_discover_expander(child);
 	if (res) {
+		spin_lock_irq(&parent->port->dev_list_lock);
+		list_del(&child->dev_list_node);
+		spin_unlock_irq(&parent->port->dev_list_lock);
 		kfree(child);
 		return NULL;
 	}

[PATCH 33/91] powerpc/kdump: Fix timeout in crash_kexec_wait_realmode

[Willy Tarreau]

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

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

commit 63f21a56f1cc0b800a4c00349c59448f82473d19 upstream.

The existing code it pretty ugly.  How about we clean it up even more
like this?

From: Anton Blanchard <anton@samba.org>

We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/powerpc/kernel/crash.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

Index: longterm-2.6.27/arch/powerpc/kernel/crash.c
===================================================================
--- longterm-2.6.27.orig/arch/powerpc/kernel/crash.c	2012-02-05 22:34:33.998915277 +0100
+++ longterm-2.6.27/arch/powerpc/kernel/crash.c	2012-02-05 22:34:39.544914550 +0100
@@ -176,12 +176,8 @@
 
 		while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
 			barrier();
-			if (!cpu_possible(i)) {
+			if (!cpu_possible(i) || !cpu_online(i) || (msecs <= 0))
 				break;
-			}
-			if (!cpu_online(i)) {
-				break;
-			}
 			msecs--;
 			mdelay(1);
 		}

[PATCH 34/91] ext3: Fix oops in ext3_try_to_allocate_with_rsv()

[Willy Tarreau]

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

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

commit ad95c5e9bc8b5885f94dce720137cac8fa8da4c9 upstream.

Block allocation is called from two places: ext3_get_blocks_handle() and
ext3_xattr_block_set(). These two callers are not necessarily synchronized
because xattr code holds only xattr_sem and i_mutex, and
ext3_get_blocks_handle() may hold only truncate_mutex when called from
writepage() path. Block reservation code does not expect two concurrent
allocations to happen to the same inode and thus assertions can be triggered
or reservation structure corruption can occur.

Fix the problem by taking truncate_mutex in xattr code to serialize
allocations.

CC: Sage Weil <sage@newdream.net>
Reported-by: Fyodor Ustinov <ufm@ufm.su>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/ext3/xattr.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/fs/ext3/xattr.c
===================================================================
--- longterm-2.6.27.orig/fs/ext3/xattr.c	2012-02-05 22:34:33.971915261 +0100
+++ longterm-2.6.27/fs/ext3/xattr.c	2012-02-05 22:34:39.684915780 +0100
@@ -801,8 +801,16 @@
 			/* We need to allocate a new block */
 			ext3_fsblk_t goal = ext3_group_first_block_no(sb,
 						EXT3_I(inode)->i_block_group);
-			ext3_fsblk_t block = ext3_new_block(handle, inode,
-							goal, &error);
+			ext3_fsblk_t block;
+
+			/*
+			 * Protect us agaist concurrent allocations to the
+			 * same inode from ext3_..._writepage(). Reservation
+			 * code does not expect racing allocations.
+			 */
+			mutex_lock(&EXT3_I(inode)->truncate_mutex);
+			block = ext3_new_block(handle, inode, goal, &error);
+			mutex_unlock(&EXT3_I(inode)->truncate_mutex);
 			if (error)
 				goto cleanup;
 			ea_idebug(inode, "creating block %d", block);

[PATCH 35/91] svcrpc: fix list-corrupting race on nfsd shutdown

[Willy Tarreau]

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

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

commit ebc63e531cc6a457595dd110b07ac530eae788c3 upstream.

After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
longer removed its xpt_ready (then sk_ready) field from whatever list it
was on, noting that there was no point since the whole list was about to
be destroyed anyway.

That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
still be hanging around playing with the about-to-be-destroyed list, and
could get themselves into trouble writing to freed memory if we left
this xprt on the list after freeing it.

(This is actually functionally identical to a patch made first by Ben
Greear, but with more comments.)

Cc: gnb@fmeh.org
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/sunrpc/svc_xprt.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

Index: longterm-2.6.27/net/sunrpc/svc_xprt.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/svc_xprt.c	2012-02-05 22:34:33.947915241 +0100
+++ longterm-2.6.27/net/sunrpc/svc_xprt.c	2012-02-05 22:34:39.823917910 +0100
@@ -830,12 +830,13 @@
 	if (!test_and_set_bit(XPT_DETACHED, &xprt->xpt_flags))
 		list_del_init(&xprt->xpt_list);
 	/*
-	 * We used to delete the transport from whichever list
-	 * it's sk_xprt.xpt_ready node was on, but we don't actually
-	 * need to.  This is because the only time we're called
-	 * while still attached to a queue, the queue itself
-	 * is about to be destroyed (in svc_destroy).
+	 * The only time we're called while xpt_ready is still on a list
+	 * is while the list itself is about to be destroyed (in
+	 * svc_destroy).  BUT svc_xprt_enqueue could still be attempting
+	 * to add new entries to the sp_sockets list, so we can't leave
+	 * a freed xprt on it.
 	 */
+	list_del_init(&xprt->xpt_ready);
 	if (test_bit(XPT_TEMP, &xprt->xpt_flags))
 		serv->sv_tmpcnt--;
 

[PATCH 36/91] powerpc/pseries/hvconsole: Fix dropped console output

[Willy Tarreau]

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

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

commit 51d33021425e1f905beb4208823146f2fb6517da upstream.

Return -EAGAIN when we get H_BUSY back from the hypervisor. This
makes the hvc console driver retry, avoiding dropped printks.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/powerpc/platforms/pseries/hvconsole.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- longterm-2.6.27.orig/arch/powerpc/platforms/pseries/hvconsole.c	2012-02-05 22:34:33.922915442 +0100
+++ longterm-2.6.27/arch/powerpc/platforms/pseries/hvconsole.c	2012-02-05 22:34:39.962914708 +0100
@@ -73,7 +73,7 @@
 	if (ret == H_SUCCESS)
 		return count;
 	if (ret == H_BUSY)
-		return 0;
+		return -EAGAIN;
 	return -EIO;
 }
 

[PATCH 37/91] alpha: fix several security issues

[Willy Tarreau]

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

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

commit 21c5977a836e399fc710ff2c5367845ed5c2527f upstream.

Fix several security issues in Alpha-specific syscalls.  Untested, but
mostly trivial.

1. Signedness issue in osf_getdomainname allows copying out-of-bounds
kernel memory to userland.

2. Signedness issue in osf_sysinfo allows copying large amounts of
kernel memory to userland.

3. Typo (?) in osf_getsysinfo bounds minimum instead of maximum copy
size, allowing copying large amounts of kernel memory to userland.

4. Usage of user pointer in osf_wait4 while under KERNEL_DS allows
privilege escalation via writing return value of sys_wait4 to kernel
memory.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.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>
---
 arch/alpha/kernel/osf_sys.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/arch/alpha/kernel/osf_sys.c
===================================================================
--- longterm-2.6.27.orig/arch/alpha/kernel/osf_sys.c	2012-02-05 22:34:33.893915202 +0100
+++ longterm-2.6.27/arch/alpha/kernel/osf_sys.c	2012-02-05 22:34:40.104915063 +0100
@@ -451,7 +451,7 @@
 		return -EFAULT;
 
 	len = namelen;
-	if (namelen > 32)
+	if (len > 32)
 		len = 32;
 
 	down_read(&uts_sem);
@@ -639,7 +639,7 @@
 	down_read(&uts_sem);
 	res = sysinfo_table[offset];
 	len = strlen(res)+1;
-	if (len > count)
+	if ((unsigned long)len > (unsigned long)count)
 		len = count;
 	if (copy_to_user(buf, res, len))
 		err = -EFAULT;
@@ -695,7 +695,7 @@
 		return 1;
 
 	case GSI_GET_HWRPB:
-		if (nbytes < sizeof(*hwrpb))
+		if (nbytes > sizeof(*hwrpb))
 			return -EINVAL;
 		if (copy_to_user(buffer, hwrpb, nbytes) != 0)
 			return -EFAULT;
@@ -1061,6 +1061,7 @@
 {
 	struct rusage r;
 	long ret, err;
+	unsigned int status = 0;
 	mm_segment_t old_fs;
 
 	if (!ur)
@@ -1069,13 +1070,15 @@
 	old_fs = get_fs();
 		
 	set_fs (KERNEL_DS);
-	ret = sys_wait4(pid, ustatus, options, (struct rusage __user *) &r);
+	ret = sys_wait4(pid, (unsigned int __user *) &status, options,
+			(struct rusage __user *) &r);
 	set_fs (old_fs);
 
 	if (!access_ok(VERIFY_WRITE, ur, sizeof(*ur)))
 		return -EFAULT;
 
 	err = 0;
+	err |= put_user(status, ustatus);
 	err |= __put_user(r.ru_utime.tv_sec, &ur->ru_utime.tv_sec);
 	err |= __put_user(r.ru_utime.tv_usec, &ur->ru_utime.tv_usec);
 	err |= __put_user(r.ru_stime.tv_sec, &ur->ru_stime.tv_sec);

[PATCH 38/91] ALSA: timer - Fix Oops at closing slave timer

[Willy Tarreau]

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

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

commit 0584ffa548b6e59aceb027112f23a55f0133400e upstream.

A slave-timer instance has no timer reference, and this results in
NULL-dereference at stopping the timer, typically called at closing
the device.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40682

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 sound/core/timer.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/sound/core/timer.c
===================================================================
--- longterm-2.6.27.orig/sound/core/timer.c	2012-02-05 22:34:33.866915229 +0100
+++ longterm-2.6.27/sound/core/timer.c	2012-02-05 22:34:40.244919877 +0100
@@ -527,6 +527,8 @@
 	if (err < 0)
 		return err;
 	timer = timeri->timer;
+	if (!timer)
+		return -EINVAL;
 	spin_lock_irqsave(&timer->lock, flags);
 	timeri->cticks = timeri->ticks;
 	timeri->pticks = 0;

[PATCH 39/91] powerpc: Fix device tree claim code

[Willy Tarreau]

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

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

commit 966728dd88b4026ec58fee169ccceaeaf56ef120 upstream.

I have a box that fails in OF during boot with:

DEFAULT CATCH!, exception-handler=fff00400
at   %SRR0: 49424d2c4c6f6768   %SRR1: 800000004000b002

ie "IBM,Logh". OF got corrupted with a device tree string.

Looking at make_room and alloc_up, we claim the first chunk (1 MB)
but we never claim any more. mem_end is always set to alloc_top
which is the top of our available address space, guaranteeing we will
never call alloc_up and claim more memory.

Also alloc_up wasn't setting alloc_bottom to the bottom of the
available address space.

This doesn't help the box to boot, but we at least fail with
an obvious error. We could relocate the device tree in a future
patch.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/powerpc/kernel/prom_init.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/arch/powerpc/kernel/prom_init.c
===================================================================
--- longterm-2.6.27.orig/arch/powerpc/kernel/prom_init.c	2012-02-05 22:34:33.840914904 +0100
+++ longterm-2.6.27/arch/powerpc/kernel/prom_init.c	2012-02-05 22:34:40.385916495 +0100
@@ -880,7 +880,7 @@
 	}
 	if (addr == 0)
 		return 0;
-	RELOC(alloc_bottom) = addr;
+	RELOC(alloc_bottom) = addr + size;
 
 	prom_debug(" -> %x\n", addr);
 	prom_debug("  alloc_bottom : %x\n", RELOC(alloc_bottom));
@@ -1680,7 +1680,7 @@
 		chunk = alloc_up(room, 0);
 		if (chunk == 0)
 			prom_panic("No memory for flatten_device_tree (claim failed)");
-		*mem_end = RELOC(alloc_top);
+		*mem_end = chunk + room;
 	}
 
 	ret = (void *)*mem_start;
@@ -1899,7 +1899,7 @@
 	mem_start = (unsigned long)alloc_up(room, PAGE_SIZE);
 	if (mem_start == 0)
 		prom_panic("Can't allocate initial device-tree chunk\n");
-	mem_end = RELOC(alloc_top);
+	mem_end = mem_start + room;
 
 	/* Get root of tree */
 	root = call_prom("peer", 1, 1, (phandle)0);

[PATCH 40/91] powerpc: pseries: Fix kexec on machines with more than 4TB of RAM

[Willy Tarreau]

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

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

commit bed9a31527af8ff3dfbad62a1a42815cef4baab7 upstream.

On a box with 8TB of RAM the MMU hashtable is 64GB in size. That
means we have 4G PTEs. pSeries_lpar_hptab_clear was using a signed
int to store the index which will overflow at 2G.

Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/powerpc/platforms/pseries/lpar.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- longterm-2.6.27.orig/arch/powerpc/platforms/pseries/lpar.c	2012-02-05 22:34:33.813915314 +0100
+++ longterm-2.6.27/arch/powerpc/platforms/pseries/lpar.c	2012-02-05 22:34:40.526914898 +0100
@@ -371,7 +371,7 @@
 		unsigned long ptel;
 	} ptes[4];
 	long lpar_rc;
-	int i, j;
+	unsigned long i, j;
 
 	/* Read in batches of 4,
 	 * invalidate only valid entries not in the VRMA

[PATCH 41/91] xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead.

[Willy Tarreau]

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

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

commit ed467e69f16e6b480e2face7bc5963834d025f91 upstream.

We have hit a couple of customer bugs where they would like to
use those parameters to run an UP kernel - but both of those
options turn of important sources of interrupt information so
we end up not being able to boot. The correct way is to
pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and
the kernel will patch itself to be a UP kernel.

Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308

Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/xen/smp.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/arch/x86/xen/smp.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/xen/smp.c	2012-02-05 22:34:33.783914838 +0100
+++ longterm-2.6.27/arch/x86/xen/smp.c	2012-02-05 22:34:40.668915455 +0100
@@ -33,6 +33,7 @@
 #include <xen/page.h>
 #include <xen/events.h>
 
+#include <xen/hvc-console.h>
 #include "xen-ops.h"
 #include "mmu.h"
 
@@ -182,6 +183,15 @@
 {
 	unsigned cpu;
 
+	if (skip_ioapic_setup) {
+		char *m = (max_cpus == 0) ?
+			"The nosmp parameter is incompatible with Xen; " \
+			"use Xen dom0_max_vcpus=1 parameter" :
+			"The noapic parameter is incompatible with Xen";
+
+		xen_raw_printk(m);
+		panic(m);
+	}
 	xen_init_lock_cpu(0);
 
 	smp_store_cpu_info(0);

[PATCH 42/91] cifs: fix possible memory corruption in CIFSFindNext

[Willy Tarreau]

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

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

commit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream.

The name_len variable in CIFSFindNext is a signed int that gets set to
the resume_name_len in the cifs_search_info. The resume_name_len however
is unsigned and for some infolevels is populated directly from a 32 bit
value sent by the server.

If the server sends a very large value for this, then that value could
look negative when converted to a signed int. That would make that
value pass the PATH_MAX check later in CIFSFindNext. The name_len would
then be used as a length value for a memcpy. It would then be treated
as unsigned again, and the memcpy scribbles over a ton of memory.

Fix this by making the name_len an unsigned value in CIFSFindNext.

Reported-by: Darren Lavender <dcl@hppine99.gbr.hp.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/cifs/cifssmb.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/fs/cifs/cifssmb.c
===================================================================
--- longterm-2.6.27.orig/fs/cifs/cifssmb.c	2012-02-05 22:34:33.755917316 +0100
+++ longterm-2.6.27/fs/cifs/cifssmb.c	2012-02-05 22:34:40.813915010 +0100
@@ -3649,7 +3649,8 @@
 	T2_FNEXT_RSP_PARMS *parms;
 	char *response_data;
 	int rc = 0;
-	int bytes_returned, name_len;
+	int bytes_returned;
+	unsigned int name_len;
 	__u16 params, byte_count;
 
 	cFYI(1, ("In FindNext"));

[PATCH 43/91] TPM: Call tpm_transmit with correct size

[Willy Tarreau]

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

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

commit 6b07d30aca7e52f2881b8c8c20c8a2cd28e8b3d3 upstream.

This patch changes the call of tpm_transmit by supplying the size of the
userspace buffer instead of TPM_BUFSIZE.

This got assigned CVE-2011-1161.

[The first hunk didn't make sense given one could expect
 way less data than TPM_BUFSIZE, so added tpm_transmit boundary
 check over bufsiz instead
 The last parameter of tpm_transmit() reflects the amount
 of data expected from the device, and not the buffer size
 being supplied to it. It isn't ideal to parse it directly,
 so we just set it to the maximum the input buffer can handle
 and let the userspace API to do such job.]

Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/tpm/tpm.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/char/tpm/tpm.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/tpm/tpm.c	2012-02-05 22:34:33.730914904 +0100
+++ longterm-2.6.27/drivers/char/tpm/tpm.c	2012-02-05 22:34:40.951915689 +0100
@@ -375,6 +375,9 @@
 	u32 count, ordinal;
 	unsigned long stop;
 
+	if (bufsiz > TPM_BUFSIZE)
+		bufsiz = TPM_BUFSIZE;
+
 	count = be32_to_cpu(*((__be32 *) (buf + 2)));
 	ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
 	if (count == 0)

[PATCH 44/91] TPM: Zero buffer after copying to userspace

[Willy Tarreau]

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

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

commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 upstream.

Since the buffer might contain security related data it might be a good idea to
zero the buffer after we have copied it to userspace.

This got assigned CVE-2011-1162.

Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/tpm/tpm.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/char/tpm/tpm.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/tpm/tpm.c	2012-02-05 22:34:40.951915689 +0100
+++ longterm-2.6.27/drivers/char/tpm/tpm.c	2012-02-05 22:34:41.090914667 +0100
@@ -1069,6 +1069,7 @@
 {
 	struct tpm_chip *chip = file->private_data;
 	ssize_t ret_size;
+	int rc;
 
 	del_singleshot_timer_sync(&chip->user_read_timer);
 	flush_scheduled_work();
@@ -1079,8 +1080,11 @@
 			ret_size = size;
 
 		mutex_lock(&chip->buffer_mutex);
-		if (copy_to_user(buf, chip->data_buffer, ret_size))
+		rc = copy_to_user(buf, chip->data_buffer, ret_size);
+		memset(chip->data_buffer, 0, ret_size);
+		if (rc)
 			ret_size = -EFAULT;
+
 		mutex_unlock(&chip->buffer_mutex);
 	}
 

[PATCH 45/91] aacraid: reset should disable MSI interrupt

[Willy Tarreau]

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

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

commit d0efab26f89506387a1bde898556660e06d7eb15 upstream.

scsi reset on hardware with enabled MSI interrupts generates WARNING message

[11027.798722] aacraid: Host adapter abort request (0,0,0,0)
[11027.798814] aacraid: Host adapter reset request. SCSI hang ?
[11087.762237] aacraid: SCSI bus appears hung
[11135.082543] ------------[ cut here ]------------
[11135.082646] WARNING: at drivers/pci/msi.c:658 pci_enable_msi_block+0x251/0x290()

Signed-off-by: Vasily Averin <vvs@sw.ru>
Acked-by: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/aacraid/commsup.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/scsi/aacraid/commsup.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/aacraid/commsup.c	2012-02-05 22:34:33.642915831 +0100
+++ longterm-2.6.27/drivers/scsi/aacraid/commsup.c	2012-02-05 22:34:41.243915381 +0100
@@ -1202,6 +1202,8 @@
 	kfree(aac->queues);
 	aac->queues = NULL;
 	free_irq(aac->pdev->irq, aac);
+	if (aac->msi)
+		pci_disable_msi(aac->pdev);
 	kfree(aac->fsa_dev);
 	aac->fsa_dev = NULL;
 	quirks = aac_get_driver_ident(index)->quirks;

[PATCH 46/91] libsas: fix panic when single phy is disabled on a wide port

[Willy Tarreau]

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

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

commit a73914c35b05d80f8ce78288e10056c91090b666 upstream.

When a wide port is being utilized to a target, if one disables only one
of the
phys, we get an OS crash:

BUG: unable to handle kernel NULL pointer dereference at
0000000000000238
IP: [<ffffffff814ca9b1>] mutex_lock+0x21/0x50
PGD 4103f5067 PUD 41dba9067 PMD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/bus/pci/slots/5/address
CPU 0
Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]

Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
Pid: 5146, comm: scsi_wq_5 Not tainted
2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server
RIP: 0010:[<ffffffff814ca9b1>]  [<ffffffff814ca9b1>]
mutex_lock+0x21/0x50
RSP: 0018:ffff8803e4e33d30  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238
RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0
FS:  0000000000000000(0000) GS:ffff880028200000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task
ffff8803e4e294a0)
Stack:
 ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e
<0> ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00
<0> ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200
Call Trace:
 [<ffffffffa001f06e>] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas]
 [<ffffffffa0032b6c>] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas]
 [<ffffffffa0034914>] sas_ex_revalidate_domain+0x204/0x330 [libsas]
 [<ffffffffa00307f0>] ? sas_revalidate_domain+0x0/0x90 [libsas]
 [<ffffffffa0030855>] sas_revalidate_domain+0x65/0x90 [libsas]
 [<ffffffff8108c7d0>] worker_thread+0x170/0x2a0
 [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8108c660>] ? worker_thread+0x0/0x2a0
 [<ffffffff81091b36>] kthread+0x96/0xa0
 [<ffffffff810141ca>] child_rip+0xa/0x20
 [<ffffffff81091aa0>] ? kthread+0x0/0xa0
 [<ffffffff810141c0>] ? child_rip+0x0/0x20
Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24
4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df <f0> ff
0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d
RIP  [<ffffffff814ca9b1>] mutex_lock+0x21/0x50
 RSP <ffff8803e4e33d30>
CR2: 0000000000000238

The following patch is admittedly a band-aid, and does not solve the
root cause, but it still is a good candidate for hardening as a pointer
check before reference.

Signed-off-by: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
Tested-by: Jack Wang <jack_wang@usish.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/libsas/sas_expander.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/drivers/scsi/libsas/sas_expander.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/libsas/sas_expander.c	2012-02-05 22:34:39.404915902 +0100
+++ longterm-2.6.27/drivers/scsi/libsas/sas_expander.c	2012-02-05 22:34:41.383915412 +0100
@@ -1722,10 +1722,12 @@
 	}
 	sas_disable_routing(parent, phy->attached_sas_addr);
 	memset(phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
-	sas_port_delete_phy(phy->port, phy->phy);
-	if (phy->port->num_phys == 0)
-		sas_port_delete(phy->port);
-	phy->port = NULL;
+	if (phy->port) {
+		sas_port_delete_phy(phy->port, phy->phy);
+		if (phy->port->num_phys == 0)
+			sas_port_delete(phy->port);
+		phy->port = NULL;
+	}
 }
 
 static int sas_discover_bfs_by_root_level(struct domain_device *root,

[PATCH 47/91] KVM: s390: check cpu_id prior to using it

[Willy Tarreau]

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

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

commit 4d47555a80495657161a7e71ec3014ff2021e450 upstream.

We use the cpu id provided by userspace as array index here. Thus we
clearly need to check it first. Ooops.

Signed-off-by: Carsten Otte <cotte@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/s390/kvm/kvm-s390.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/arch/s390/kvm/kvm-s390.c
===================================================================
--- longterm-2.6.27.orig/arch/s390/kvm/kvm-s390.c	2012-02-05 22:34:33.588915140 +0100
+++ longterm-2.6.27/arch/s390/kvm/kvm-s390.c	2012-02-05 22:34:41.524915249 +0100
@@ -274,11 +274,17 @@
 struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
 				      unsigned int id)
 {
-	struct kvm_vcpu *vcpu = kzalloc(sizeof(struct kvm_vcpu), GFP_KERNEL);
-	int rc = -ENOMEM;
+	struct kvm_vcpu *vcpu;
+	int rc = -EINVAL;
 
+	if (id >= KVM_MAX_VCPUS)
+		goto out;
+
+	rc = -ENOMEM;
+
+	vcpu = kzalloc(sizeof(struct kvm_vcpu), GFP_KERNEL);
 	if (!vcpu)
-		goto out_nomem;
+		goto out;
 
 	vcpu->arch.sie_block = (struct kvm_s390_sie_block *)
 					get_zeroed_page(GFP_KERNEL);
@@ -313,7 +319,7 @@
 	return vcpu;
 out_free_cpu:
 	kfree(vcpu);
-out_nomem:
+out:
 	return ERR_PTR(rc);
 }
 

[PATCH 48/91] carminefb: Fix module parameters permissions

[Willy Tarreau]

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

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

commit c84c14224bbca6ec60d5851fcc87be0e34df2f44 upstream.

The third parameter of module_param is supposed to be an octal value.
The missing leading "0" causes the following:

$ ls -l /sys/module/carminefb/parameters/
total 0
-rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_displays
-rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_mode
-rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_mode_str

After fixing the perm parameter, we get the expected:

$ ls -l /sys/module/carminefb/parameters/
total 0
-r--r--r-- 1 root root 4096 Jul  8 08:56 fb_displays
-r--r--r-- 1 root root 4096 Jul  8 08:56 fb_mode
-r--r--r-- 1 root root 4096 Jul  8 08:56 fb_mode_str

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/video/carminefb.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/video/carminefb.c
===================================================================
--- longterm-2.6.27.orig/drivers/video/carminefb.c	2012-02-05 22:34:33.561914997 +0100
+++ longterm-2.6.27/drivers/video/carminefb.c	2012-02-05 22:34:41.662915038 +0100
@@ -31,11 +31,11 @@
 #define CARMINEFB_DEFAULT_VIDEO_MODE	1
 
 static unsigned int fb_mode = CARMINEFB_DEFAULT_VIDEO_MODE;
-module_param(fb_mode, uint, 444);
+module_param(fb_mode, uint, 0444);
 MODULE_PARM_DESC(fb_mode, "Initial video mode as integer.");
 
 static char *fb_mode_str;
-module_param(fb_mode_str, charp, 444);
+module_param(fb_mode_str, charp, 0444);
 MODULE_PARM_DESC(fb_mode_str, "Initial video mode in characters.");
 
 /*
@@ -45,7 +45,7 @@
  * 0b010 Display 1
  */
 static int fb_displays = CARMINE_USE_DISPLAY0 | CARMINE_USE_DISPLAY1;
-module_param(fb_displays, int, 444);
+module_param(fb_displays, int, 0444);
 MODULE_PARM_DESC(fb_displays, "Bit mode, which displays are used");
 
 struct carmine_hw {

[PATCH 49/91] um: fix ubd cow size

[Willy Tarreau]

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

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

commit 8535639810e578960233ad39def3ac2157b0c3ec upstream.

ubd_file_size() cannot use ubd_dev->cow.file because at this time
ubd_dev->cow.file is not initialized.
Therefore, ubd_file_size() will always report a wrong disk size when
COW files are used.
Reading from /dev/ubd* would crash the kernel.

We have to read the correct disk size from the COW file's backing
file.

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/um/drivers/ubd_kern.c |   31 ++++++++++++++++++++++++++++++-
 1 files changed, 30 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/arch/um/drivers/ubd_kern.c
===================================================================
--- longterm-2.6.27.orig/arch/um/drivers/ubd_kern.c	2012-02-05 22:34:33.536914634 +0100
+++ longterm-2.6.27/arch/um/drivers/ubd_kern.c	2012-02-05 22:34:41.803915498 +0100
@@ -529,8 +529,37 @@
 static inline int ubd_file_size(struct ubd *ubd_dev, __u64 *size_out)
 {
 	char *file;
+	int fd;
+	int err;
 
-	file = ubd_dev->cow.file ? ubd_dev->cow.file : ubd_dev->file;
+	__u32 version;
+	__u32 align;
+	char *backing_file;
+	time_t mtime;
+	unsigned long long size;
+	int sector_size;
+	int bitmap_offset;
+
+	if (ubd_dev->file && ubd_dev->cow.file) {
+		file = ubd_dev->cow.file;
+
+		goto out;
+	}
+
+	fd = os_open_file(ubd_dev->file, global_openflags, 0);
+	if (fd < 0)
+		return fd;
+
+	err = read_cow_header(file_reader, &fd, &version, &backing_file, \
+		&mtime, &size, &sector_size, &align, &bitmap_offset);
+	os_close_file(fd);
+
+	if(err == -EINVAL)
+		file = ubd_dev->file;
+	else
+		file = backing_file;
+
+out:
 	return os_file_size(file, size_out);
 }
 

[PATCH 50/91] NLM: Dont hang forever on NLM unlock requests

[Willy Tarreau]

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

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

commit 0b760113a3a155269a3fba93a409c640031dd68f upstream.

If the NLM daemon is killed on the NFS server, we can currently end up
hanging forever on an 'unlock' request, instead of aborting. Basically,
if the rpcbind request fails, or the server keeps returning garbage, we
really want to quit instead of retrying.

Tested-by: Vasily Averin <vvs@sw.ru>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/lockd/clntproc.c          |    8 +++++++-
 include/linux/sunrpc/sched.h |    4 ++--
 net/sunrpc/clnt.c            |    3 +++
 net/sunrpc/sched.c           |    1 +
 4 files changed, 13 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/fs/lockd/clntproc.c
===================================================================
--- longterm-2.6.27.orig/fs/lockd/clntproc.c	2012-02-05 22:34:33.509914670 +0100
+++ longterm-2.6.27/fs/lockd/clntproc.c	2012-02-05 22:34:41.942915002 +0100
@@ -709,7 +709,13 @@
 
 	if (task->tk_status < 0) {
 		dprintk("lockd: unlock failed (err = %d)\n", -task->tk_status);
-		goto retry_rebind;
+		switch (task->tk_status) {
+		case -EACCES:
+		case -EIO:
+			goto die;
+		default:
+			goto retry_rebind;
+		}
 	}
 	if (status == NLM_LCK_DENIED_GRACE_PERIOD) {
 		rpc_delay(task, NLMCLNT_GRACE_WAIT);
Index: longterm-2.6.27/include/linux/sunrpc/sched.h
===================================================================
--- longterm-2.6.27.orig/include/linux/sunrpc/sched.h	2012-02-05 22:34:33.497915064 +0100
+++ longterm-2.6.27/include/linux/sunrpc/sched.h	2012-02-05 22:34:41.949914805 +0100
@@ -84,8 +84,8 @@
 	long			tk_rtt;		/* round-trip time (jiffies) */
 
 	pid_t			tk_owner;	/* Process id for batching tasks */
-	unsigned char		tk_priority : 2;/* Task priority */
-
+	unsigned char		tk_priority : 2,/* Task priority */
+				tk_rebind_retry : 2;
 #ifdef RPC_DEBUG
 	unsigned short		tk_pid;		/* debugging aid */
 #endif
Index: longterm-2.6.27/net/sunrpc/clnt.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/clnt.c	2012-02-05 22:34:33.501914879 +0100
+++ longterm-2.6.27/net/sunrpc/clnt.c	2012-02-05 22:34:41.957914825 +0100
@@ -955,6 +955,9 @@
 			status = -EOPNOTSUPP;
 			break;
 		}
+		if (task->tk_rebind_retry == 0)
+			break;
+		task->tk_rebind_retry--;
 		rpc_delay(task, 3*HZ);
 		goto retry_timeout;
 	case -ETIMEDOUT:
Index: longterm-2.6.27/net/sunrpc/sched.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/sched.c	2012-02-05 22:34:33.505915115 +0100
+++ longterm-2.6.27/net/sunrpc/sched.c	2012-02-05 22:34:41.963916236 +0100
@@ -786,6 +786,7 @@
 	/* Initialize retry counters */
 	task->tk_garb_retry = 2;
 	task->tk_cred_retry = 2;
+	task->tk_rebind_retry = 2;
 
 	task->tk_priority = task_setup_data->priority - RPC_PRIORITY_LOW;
 	task->tk_owner = current->tgid;

[PATCH 51/91] Bluetooth: Prevent buffer overflow in l2cap config request

[Willy Tarreau]

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

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

commit 7ac28817536797fd40e9646452183606f9e17f71 upstream.

A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header.  This results in copying a very large amount of data via
memcpy() and destroying the kernel heap.  Check for underflow.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/bluetooth/l2cap.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/net/bluetooth/l2cap.c
===================================================================
--- longterm-2.6.27.orig/net/bluetooth/l2cap.c	2012-02-05 22:34:33.464915011 +0100
+++ longterm-2.6.27/net/bluetooth/l2cap.c	2012-02-05 22:34:42.135914462 +0100
@@ -1737,7 +1737,7 @@
 
 	/* Reject if config buffer is too small. */
 	len = cmd_len - sizeof(*req);
-	if (l2cap_pi(sk)->conf_len + len > sizeof(l2cap_pi(sk)->conf_req)) {
+	if (len < 0 || l2cap_pi(sk)->conf_len + len > sizeof(l2cap_pi(sk)->conf_req)) {
 		l2cap_send_cmd(conn, cmd->ident, L2CAP_CONF_RSP,
 				l2cap_build_conf_rsp(sk, rsp,
 					L2CAP_CONF_REJECT, flags), rsp);

[PATCH 52/91] net_sched: Fix qdisc_notify()

[Willy Tarreau]

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

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

commit 53b0f08042f04813cd1a7473dacd3edfacb28eb3 upstream.

Ben Pfaff reported a kernel oops and provided a test program to
reproduce it.

https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805

tc_fill_qdisc() should not be called for builtin qdisc, or it
dereference a NULL pointer to get device ifindex.

Fix is to always use tc_qdisc_dump_ignore() before calling
tc_fill_qdisc().

Reported-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/sched/sch_api.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

Index: longterm-2.6.27/net/sched/sch_api.c
===================================================================
--- longterm-2.6.27.orig/net/sched/sch_api.c	2012-02-05 22:34:33.439915080 +0100
+++ longterm-2.6.27/net/sched/sch_api.c	2012-02-05 22:34:42.275915891 +0100
@@ -1193,6 +1193,11 @@
 	return -1;
 }
 
+static bool tc_qdisc_dump_ignore(struct Qdisc *q)
+{
+	return (q->flags & TCQ_F_BUILTIN) ? true : false;
+}
+
 static int qdisc_notify(struct sk_buff *oskb, struct nlmsghdr *n,
 			u32 clid, struct Qdisc *old, struct Qdisc *new)
 {
@@ -1203,11 +1208,11 @@
 	if (!skb)
 		return -ENOBUFS;
 
-	if (old && old->handle) {
+	if (old && !tc_qdisc_dump_ignore(old)) {
 		if (tc_fill_qdisc(skb, old, clid, pid, n->nlmsg_seq, 0, RTM_DELQDISC) < 0)
 			goto err_out;
 	}
-	if (new) {
+	if (new && !tc_qdisc_dump_ignore(new)) {
 		if (tc_fill_qdisc(skb, new, clid, pid, n->nlmsg_seq, old ? NLM_F_REPLACE : 0, RTM_NEWQDISC) < 0)
 			goto err_out;
 	}
@@ -1220,11 +1225,6 @@
 	return -EINVAL;
 }
 
-static bool tc_qdisc_dump_ignore(struct Qdisc *q)
-{
-	return (q->flags & TCQ_F_BUILTIN) ? true : false;
-}
-
 static int tc_dump_qdisc_root(struct Qdisc *root, struct sk_buff *skb,
 			      struct netlink_callback *cb,
 			      int *q_idx_p, int s_q_idx)

[PATCH 53/91] ext4: fix BUG_ON() in ext4_ext_insert_extent()

[Willy Tarreau]

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

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

Does not corrispond with a direct commit in Linus's tree as it was fixed
differently in the 3.0 release.


We will meet with a BUG_ON() if following script is run.

mkfs.ext4 -b 4096 /dev/sdb1 1000000
mount -t ext4 /dev/sdb1 /mnt/sdb1
fallocate -l 100M /mnt/sdb1/test
sync
for((i=0;i<170;i++))
do
        dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1
seek=`expr $i \* 2`
done
umount /mnt/sdb1
mount -t ext4 /dev/sdb1 /mnt/sdb1
dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=341
umount /mnt/sdb1
mount /dev/sdb1 /mnt/sdb1
dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=340
sync

The reason is that it forgot to mark dirty when splitting two extents in
ext4_ext_convert_to_initialized(). Althrough ex has been updated in
memory, it is not dirtied both in ext4_ext_convert_to_initialized() and
ext4_ext_insert_extent(). The disk layout is corrupted. Then it will
meet with a BUG_ON() when writting at the start of that extent again.

Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Xiaoyun Mao <xiaoyun.maoxy@aliyun-inc.com>
Cc: Yingbin Wang <yingbin.wangyb@aliyun-inc.com>
Cc: Jia Wan <jia.wanj@aliyun-inc.com>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/ext4/extents.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/fs/ext4/extents.c
===================================================================
--- longterm-2.6.27.orig/fs/ext4/extents.c	2012-02-05 22:34:33.413914999 +0100
+++ longterm-2.6.27/fs/ext4/extents.c	2012-02-05 22:34:42.416916530 +0100
@@ -2327,6 +2327,7 @@
 		ex1 = ex;
 		ex1->ee_len = cpu_to_le16(iblock - ee_block);
 		ext4_ext_mark_uninitialized(ex1);
+		ext4_ext_dirty(handle, inode, path + depth);
 		ex2 = &newex;
 	}
 	/*

[PATCH 54/91] drivers/net/rionet.c: fix ethernet address macros for LE platforms

[Willy Tarreau]

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

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

commit e0c87bd95e8dad455c23bc56513af8dcb1737e55 upstream.

Modify Ethernet addess macros to be compatible with BE/LE platforms

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Chul Kim <chul.kim@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.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>
---
 drivers/net/rionet.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/drivers/net/rionet.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/rionet.c	2012-02-05 22:34:33.389915485 +0100
+++ longterm-2.6.27/drivers/net/rionet.c	2012-02-05 22:34:42.555916186 +0100
@@ -87,8 +87,8 @@
 #define dev_rionet_capable(dev) \
 	is_rionet_capable(dev->pef, dev->src_ops, dev->dst_ops)
 
-#define RIONET_MAC_MATCH(x)	(*(u32 *)x == 0x00010001)
-#define RIONET_GET_DESTID(x)	(*(u16 *)(x + 4))
+#define RIONET_MAC_MATCH(x)	(!memcmp((x), "\00\01\00\01", 4))
+#define RIONET_GET_DESTID(x)	((*((u8 *)x + 4) << 8) | *((u8 *)x + 5))
 
 static int rionet_rx_clean(struct net_device *ndev)
 {

[PATCH 55/91] Make scsi_free_queue() kill pending SCSI commands

[Willy Tarreau]

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

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

commit 3308511c93e6ad0d3c58984ecd6e5e57f96b12c8 upstream.

Make sure that SCSI device removal via scsi_remove_host() does finish
all pending SCSI commands. Currently that's not the case and hence
removal of a SCSI host during I/O can cause a deadlock. See also
"blkdev_issue_discard() hangs forever if underlying storage device is
removed" (http://bugzilla.kernel.org/show_bug.cgi?id=40472). See also
http://lkml.org/lkml/2011/8/27/6.

Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/hosts.c    |    9 ++++++---
 drivers/scsi/scsi_lib.c |    9 +++++++++
 2 files changed, 15 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/scsi/hosts.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/hosts.c	2012-02-05 22:34:33.360914737 +0100
+++ longterm-2.6.27/drivers/scsi/hosts.c	2012-02-05 22:34:42.692915134 +0100
@@ -269,14 +269,17 @@
 {
 	struct Scsi_Host *shost = dev_to_shost(dev);
 	struct device *parent = dev->parent;
+	struct request_queue *q;
 
 	if (shost->ehandler)
 		kthread_stop(shost->ehandler);
 	if (shost->work_q)
 		destroy_workqueue(shost->work_q);
-	if (shost->uspace_req_q) {
-		kfree(shost->uspace_req_q->queuedata);
-		scsi_free_queue(shost->uspace_req_q);
+	q = shost->uspace_req_q;
+	if (q) {
+		kfree(q->queuedata);
+		q->queuedata = NULL;
+		scsi_free_queue(q);
 	}
 
 	scsi_destroy_command_freelist(shost);
Index: longterm-2.6.27/drivers/scsi/scsi_lib.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/scsi_lib.c	2012-02-05 22:34:33.364914767 +0100
+++ longterm-2.6.27/drivers/scsi/scsi_lib.c	2012-02-05 22:34:42.697916475 +0100
@@ -1680,6 +1680,15 @@
 
 void scsi_free_queue(struct request_queue *q)
 {
+	unsigned long flags;
+
+	WARN_ON(q->queuedata);
+
+	/* cause scsi_request_fn() to kill all non-finished requests */
+	spin_lock_irqsave(q->queue_lock, flags);
+	q->request_fn(q);
+	spin_unlock_irqrestore(q->queue_lock, flags);
+
 	blk_cleanup_queue(q);
 }
 

[PATCH 56/91] hfs: add sanity check for file name length

[Willy Tarreau]

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

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

commit bc5b8a9003132ae44559edd63a1623b7b99dfb68 upstream.

On a corrupted file system the ->len field could be wrong leading to
a buffer overflow.

Reported-and-acked-by: Clement LECIGNE <clement.lecigne@netasq.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/hfs/trans.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/fs/hfs/trans.c
===================================================================
--- longterm-2.6.27.orig/fs/hfs/trans.c	2012-02-05 22:34:33.296915074 +0100
+++ longterm-2.6.27/fs/hfs/trans.c	2012-02-05 22:34:42.844914477 +0100
@@ -40,6 +40,8 @@
 
 	src = in->name;
 	srclen = in->len;
+	if (srclen > HFS_NAMELEN)
+		srclen = HFS_NAMELEN;
 	dst = out;
 	dstlen = HFS_MAX_NAMELEN;
 	if (nls_io) {

[PATCH 57/91] USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c

[Willy Tarreau]

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

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

commit b1ffb4c851f185e9051ba837c16d9b84ef688d26 upstream.

Fix for ftdi_set_termios() glitching output

ftdi_set_termios() is constantly setting the baud rate, data bits and parity
unnecessarily on every call, . When called while characters are being
transmitted can cause the FTDI chip to corrupt the serial port bit stream
output by stalling the output half a bit during the output of a character.
Simple fix by skipping this setting if the baud rate/data bits/parity are
unchanged.

Signed-off-by: Andrew Worsley <amworsley@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/usb/serial/ftdi_sio.c |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/usb/serial/ftdi_sio.c
===================================================================
--- longterm-2.6.27.orig/drivers/usb/serial/ftdi_sio.c	2012-02-05 22:34:33.270914634 +0100
+++ longterm-2.6.27/drivers/usb/serial/ftdi_sio.c	2012-02-05 22:34:42.983916543 +0100
@@ -2109,13 +2109,19 @@
 
 	cflag = termios->c_cflag;
 
-	/* FIXME -For this cut I don't care if the line is really changing or
-	   not  - so just do the change regardless  - should be able to
-	   compare old_termios and tty->termios */
+	if (old_termios->c_cflag == termios->c_cflag
+	    && old_termios->c_ispeed == termios->c_ispeed
+	    && old_termios->c_ospeed == termios->c_ospeed)
+		goto no_c_cflag_changes;
+
 	/* NOTE These routines can get interrupted by
 	   ftdi_sio_read_bulk_callback  - need to examine what this means -
 	   don't see any problems yet */
 
+	if ((old_termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) ==
+	    (termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)))
+		goto no_data_parity_stop_changes;
+
 	/* Set number of data bits, parity, stop bits */
 
 	termios->c_cflag &= ~CMSPAR;
@@ -2151,6 +2157,7 @@
 	}
 
 	/* Now do the baudrate */
+no_data_parity_stop_changes:
 	if ((cflag & CBAUD) == B0) {
 		/* Disable flow control */
 		if (usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
@@ -2173,6 +2180,7 @@
 
 	/* Set flow control */
 	/* Note device also supports DTR/CD (ugh) and Xon/Xoff in hardware */
+no_c_cflag_changes:
 	if (cflag & CRTSCTS) {
 		dbg("%s Setting to CRTSCTS flow control", __func__);
 		if (usb_control_msg(dev,

[PATCH 58/91] oprofile, x86: Fix crash when unloading module (nmi timer mode)

[Willy Tarreau]

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

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

commit 97f7f8189fe54e3cfe324ef9ad35064f3d2d3bff upstream.

If oprofile uses the nmi timer interrupt there is a crash while
unloading the module. The bug can be triggered with oprofile build as
module and kernel parameter nolapic set. This patch fixes this.

oprofile: using NMI timer interrupt.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58
PGD 42dbca067 PUD 41da6a067 PMD 0
Oops: 0002 [#1] PREEMPT SMP
CPU 5
Modules linked in: oprofile(-) [last unloaded: oprofile]

Pid: 2518, comm: modprobe Not tainted 3.1.0-rc7-00019-gb2fb49d #19 Advanced Micro Device Anaheim/Anaheim
RIP: 0010:[<ffffffff8123c226>]  [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58
RSP: 0018:ffff88041ef71e98  EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffffffa0017100 RCX: dead000000200200
RDX: 0000000000000000 RSI: dead000000100100 RDI: ffffffff8178c620
RBP: ffff88041ef71ea8 R08: 0000000000000001 R09: 0000000000000082
R10: 0000000000000000 R11: ffff88041ef71de8 R12: 0000000000000080
R13: fffffffffffffff5 R14: 0000000000000001 R15: 0000000000610210
FS:  00007fc902f20700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 000000041cdb6000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 2518, threadinfo ffff88041ef70000, task ffff88041d348040)
Stack:
 ffff88041ef71eb8 ffffffffa0017790 ffff88041ef71eb8 ffffffffa0013532
 ffff88041ef71ec8 ffffffffa00132d6 ffff88041ef71ed8 ffffffffa00159b2
 ffff88041ef71f78 ffffffff81073115 656c69666f72706f 0000000000610200
Call Trace:
 [<ffffffffa0013532>] op_nmi_exit+0x15/0x17 [oprofile]
 [<ffffffffa00132d6>] oprofile_arch_exit+0xe/0x10 [oprofile]
 [<ffffffffa00159b2>] oprofile_exit+0x1e/0x20 [oprofile]
 [<ffffffff81073115>] sys_delete_module+0x1c3/0x22f
 [<ffffffff811bf09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff8148070b>] system_call_fastpath+0x16/0x1b
Code: 20 c6 78 81 e8 c5 cc 23 00 48 8b 13 48 8b 43 08 48 be 00 01 10 00 00 00 ad de 48 b9 00 02 20 00 00 00 ad de 48 c7 c7 20 c6 78 81
 89 42 08 48 89 10 48 89 33 48 89 4b 08 e8 a6 c0 23 00 5a 5b
RIP  [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58
 RSP <ffff88041ef71e98>
CR2: 0000000000000008
---[ end trace 43a541a52956b7b0 ]---

Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/oprofile/init.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/arch/x86/oprofile/init.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/oprofile/init.c	2012-02-05 22:34:33.209915247 +0100
+++ longterm-2.6.27/arch/x86/oprofile/init.c	2012-02-05 22:34:43.123914870 +0100
@@ -21,6 +21,7 @@
 extern void op_nmi_exit(void);
 extern void x86_backtrace(struct pt_regs * const regs, unsigned int depth);
 
+static int nmi_timer;
 
 int __init oprofile_arch_init(struct oprofile_operations *ops)
 {
@@ -31,8 +32,9 @@
 #ifdef CONFIG_X86_LOCAL_APIC
 	ret = op_nmi_init(ops);
 #endif
+	nmi_timer = (ret != 0);
 #ifdef CONFIG_X86_IO_APIC
-	if (ret < 0)
+	if (nmi_timer)
 		ret = op_nmi_timer_init(ops);
 #endif
 	ops->backtrace = x86_backtrace;
@@ -44,6 +46,7 @@
 void oprofile_arch_exit(void)
 {
 #ifdef CONFIG_X86_LOCAL_APIC
-	op_nmi_exit();
+	if (!nmi_timer)
+		op_nmi_exit();
 #endif
 }

[PATCH 59/91] jbd/jbd2: validate sb->s_first in journal_get_superblock()

[Willy Tarreau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]

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

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

commit 8762202dd0d6e46854f786bdb6fb3780a1625efe upstream.

I hit a J_ASSERT(blocknr != 0) failure in cleanup_journal_tail() when
mounting a fsfuzzed ext3 image. It turns out that the corrupted ext3
image has s_first = 0 in journal superblock, and the 0 is passed to
journal->j_head in journal_reset(), then to blocknr in
cleanup_journal_tail(), in the end the J_ASSERT failed.

So validate s_first after reading journal superblock from disk in
journal_get_superblock() to ensure s_first is valid.

The following script could reproduce it:

fstype=ext3
blocksize=1024
img=$fstype.img
offset=0
found=0
magic="c0 3b 39 98"

dd if=/dev/zero of=$img bs=1M count=8
mkfs -t $fstype -b $blocksize -F $img
filesize=`stat -c %s $img`
while [ $offset -lt $filesize ]
do
        if od -j $offset -N 4 -t x1 $img | grep -i "$magic";then
                echo "Found journal: $offset"
                found=1
                break
        fi
        offset=`echo "$offset+$blocksize" | bc`
done

if [ $found -ne 1 ];then
        echo "Magic \"$magic\" not found"
        exit 1
fi

dd if=/dev/zero of=$img seek=$(($offset+23)) conv=notrunc bs=1 count=1

mkdir -p ./mnt
mount -o loop $img ./mnt

Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Moritz Mühlenhoff <jmm@inutil.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/jbd/journal.c  |    8 ++++++++
 fs/jbd2/journal.c |    8 ++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/fs/jbd/journal.c
===================================================================
--- longterm-2.6.27.orig/fs/jbd/journal.c	2012-02-05 22:34:33.178914769 +0100
+++ longterm-2.6.27/fs/jbd/journal.c	2012-02-05 22:34:43.263916090 +0100
@@ -1030,6 +1030,14 @@
 		goto out;
 	}
 
+	if (be32_to_cpu(sb->s_first) == 0 ||
+	    be32_to_cpu(sb->s_first) >= journal->j_maxlen) {
+		printk(KERN_WARNING
+			"JBD: Invalid start block of journal: %u\n",
+			be32_to_cpu(sb->s_first));
+		goto out;
+	}
+
 	return 0;
 
 out:
Index: longterm-2.6.27/fs/jbd2/journal.c
===================================================================
--- longterm-2.6.27.orig/fs/jbd2/journal.c	2012-02-05 22:34:33.183914664 +0100
+++ longterm-2.6.27/fs/jbd2/journal.c	2012-02-05 22:34:43.272916600 +0100
@@ -1369,6 +1369,14 @@
 		goto out;
 	}
 
+	if (be32_to_cpu(sb->s_first) == 0 ||
+	    be32_to_cpu(sb->s_first) >= journal->j_maxlen) {
+		printk(KERN_WARNING
+			"JBD2: Invalid start block of journal: %u\n",
+			be32_to_cpu(sb->s_first));
+		goto out;
+	}
+
 	return 0;
 
 out:

[PATCH 60/91] Make TASKSTATS require root access

[Willy Tarreau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

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

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

commit 1a51410abe7d0ee4b1d112780f46df87d3621043 upstream.

Ok, this isn't optimal, since it means that 'iotop' needs admin
capabilities, and we may have to work on this some more.  But at the
same time it is very much not acceptable to let anybody just read
anybody elses IO statistics quite at this level.

Use of the GENL_ADMIN_PERM suggested by Johannes Berg as an alternative
to checking the capabilities by hand.

Reported-by: Vasiliy Kulikov <segoon@openwall.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Moritz Mühlenhoff <jmm@inutil.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 kernel/taskstats.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/kernel/taskstats.c
===================================================================
--- longterm-2.6.27.orig/kernel/taskstats.c	2012-02-05 22:34:33.153915196 +0100
+++ longterm-2.6.27/kernel/taskstats.c	2012-02-05 22:34:43.419915481 +0100
@@ -574,6 +574,7 @@
 	.cmd		= TASKSTATS_CMD_GET,
 	.doit		= taskstats_user_cmd,
 	.policy		= taskstats_cmd_get_policy,
+	.flags		= GENL_ADMIN_PERM,
 };
 
 static struct genl_ops cgroupstats_ops = {

[PATCH 61/91] hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops

[Willy Tarreau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

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

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

commit 434a964daa14b9db083ce20404a4a2add54d037a upstream.

Clement Lecigne reports a filesystem which causes a kernel oops in
hfs_find_init() trying to dereference sb->ext_tree which is NULL.

This proves to be because the filesystem has a corrupted MDB extent
record, where the extents file does not fit into the first three extents
in the file record (the first blocks).

In hfs_get_block() when looking up the blocks for the extent file
(HFS_EXT_CNID), it fails the first blocks special case, and falls
through to the extent code (which ultimately calls hfs_find_init())
which is in the process of being initialised.

Hfs avoids this scenario by always having the extents b-tree fitting
into the first blocks (the extents B-tree can't have overflow extents).

The fix is to check at mount time that the B-tree fits into first
blocks, i.e.  fail if HFS_I(inode)->alloc_blocks >=
HFS_I(inode)->first_blocks

Note, the existing commit 47f365eb57573 ("hfs: fix oops on mount with
corrupted btree extent records") becomes subsumed into this as a special
case, but only for the extents B-tree (HFS_EXT_CNID), it is perfectly
acceptable for the catalog B-Tree file to grow beyond three extents,
with the remaining extent descriptors in the extents overfow.

[WT: patch edited - 47f365eb57573 was missing from 2.6.27.x]

This fixes CVE-2011-2203

Reported-by: Clement LECIGNE <clement.lecigne@netasq.com>
Signed-off-by: Phillip Lougher <plougher@redhat.com>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Moritz Mühlenhoff <jmm@inutil.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/hfs/btree.c |   20 +++++++++++++++-----
 1 files changed, 15 insertions(+), 5 deletions(-)

Index: longterm-2.6.27/fs/hfs/btree.c
===================================================================
--- longterm-2.6.27.orig/fs/hfs/btree.c	2012-02-05 22:34:33.129915287 +0100
+++ longterm-2.6.27/fs/hfs/btree.c	2012-02-05 22:34:43.555914905 +0100
@@ -45,11 +45,26 @@
 	case HFS_EXT_CNID:
 		hfs_inode_read_fork(tree->inode, mdb->drXTExtRec, mdb->drXTFlSize,
 				    mdb->drXTFlSize, be32_to_cpu(mdb->drXTClpSiz));
+		if (HFS_I(tree->inode)->alloc_blocks >
+					HFS_I(tree->inode)->first_blocks) {
+			printk(KERN_ERR "hfs: invalid btree extent records\n");
+			unlock_new_inode(tree->inode);
+			goto free_inode;
+		}
+
 		tree->inode->i_mapping->a_ops = &hfs_btree_aops;
 		break;
 	case HFS_CAT_CNID:
 		hfs_inode_read_fork(tree->inode, mdb->drCTExtRec, mdb->drCTFlSize,
 				    mdb->drCTFlSize, be32_to_cpu(mdb->drCTClpSiz));
+
+		if (!HFS_I(tree->inode)->first_blocks) {
+			printk(KERN_ERR "hfs: invalid btree extent records "
+								"(0 size).\n");
+			unlock_new_inode(tree->inode);
+			goto free_inode;
+		}
+
 		tree->inode->i_mapping->a_ops = &hfs_btree_aops;
 		break;
 	default:

[PATCH 62/91] [PATCH] x86, mm: Add __get_user_pages_fast()

[Willy Tarreau]

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

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

Introduce a gup_fast() variant which is usable from IRQ/NMI context.

[ WT: this one is only needed for next patch ]

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Nick Piggin <npiggin@suse.de>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/mm/gup.c  |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mm.h |    6 +++++
 2 files changed, 62 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/arch/x86/mm/gup.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/mm/gup.c	2012-02-05 22:34:33.105915236 +0100
+++ longterm-2.6.27/arch/x86/mm/gup.c	2012-02-05 22:34:43.693914996 +0100
@@ -219,6 +219,62 @@
 	return 1;
 }
 
+/*
+ * Like get_user_pages_fast() except its IRQ-safe in that it won't fall
+ * back to the regular GUP.
+ */
+int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
+			  struct page **pages)
+{
+	struct mm_struct *mm = current->mm;
+	unsigned long addr, len, end;
+	unsigned long next;
+	unsigned long flags;
+	pgd_t *pgdp;
+	int nr = 0;
+
+	start &= PAGE_MASK;
+	addr = start;
+	len = (unsigned long) nr_pages << PAGE_SHIFT;
+	end = start + len;
+	if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
+					(void __user *)start, len)))
+		return 0;
+
+	/*
+	 * XXX: batch / limit 'nr', to avoid large irq off latency
+	 * needs some instrumenting to determine the common sizes used by
+	 * important workloads (eg. DB2), and whether limiting the batch size
+	 * will decrease performance.
+	 *
+	 * It seems like we're in the clear for the moment. Direct-IO is
+	 * the main guy that batches up lots of get_user_pages, and even
+	 * they are limited to 64-at-a-time which is not so many.
+	 */
+	/*
+	 * This doesn't prevent pagetable teardown, but does prevent
+	 * the pagetables and pages from being freed on x86.
+	 *
+	 * So long as we atomically load page table pointers versus teardown
+	 * (which we do on x86, with the above PAE exception), we can follow the
+	 * address down to the the page and take a ref on it.
+	 */
+	local_irq_save(flags);
+	pgdp = pgd_offset(mm, addr);
+	do {
+		pgd_t pgd = *pgdp;
+
+		next = pgd_addr_end(addr, end);
+		if (pgd_none(pgd))
+			break;
+		if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
+			break;
+	} while (pgdp++, addr = next, addr != end);
+	local_irq_restore(flags);
+
+	return nr;
+}
+
 int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			struct page **pages)
 {
Index: longterm-2.6.27/include/linux/mm.h
===================================================================
--- longterm-2.6.27.orig/include/linux/mm.h	2012-02-05 22:34:33.099915218 +0100
+++ longterm-2.6.27/include/linux/mm.h	2012-02-05 22:34:43.701916289 +0100
@@ -850,6 +850,12 @@
 			struct page **pages);
 
 /*
+ * doesn't attempt to fault and will return short.
+ */
+int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
+			  struct page **pages);
+
+/*
  * A callback you can register to apply pressure to ageable caches.
  *
  * 'shrink' is passed a count 'nr_to_scan' and a 'gfpmask'.  It should

[PATCH 63/91] export __get_user_pages_fast() function

[Willy Tarreau]

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

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

commit 45888a0c6edc305495b6bd72a30e66bc40b324c6 upstream.

Backport for stable kernel v2.6.32.y to v2.6.36.y.

Needed for next patch:

 oprofile, x86: Fix nmi-unsafe callgraph support

This function is used by KVM to pin process's page in the atomic context.

Define the 'weak' function to avoid other architecture not support it

Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 mm/util.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/mm/util.c
===================================================================
--- longterm-2.6.27.orig/mm/util.c	2012-02-05 22:34:33.070915063 +0100
+++ longterm-2.6.27/mm/util.c	2012-02-05 22:34:43.848914804 +0100
@@ -101,6 +101,19 @@
 }
 EXPORT_SYMBOL(__krealloc);
 
+/*
+ * Like get_user_pages_fast() except its IRQ-safe in that it won't fall
+ * back to the regular GUP.
+ * If the architecture not support this fucntion, simply return with no
+ * page pinned
+ */
+int __attribute__((weak)) __get_user_pages_fast(unsigned long start,
+				 int nr_pages, int write, struct page **pages)
+{
+	return 0;
+}
+EXPORT_SYMBOL_GPL(__get_user_pages_fast);
+
 /**
  * krealloc - reallocate memory. The contents will remain unchanged.
  * @p: object to reallocate memory for.

[PATCH 64/91] oprofile, x86: Fix nmi-unsafe callgraph support

[Willy Tarreau]

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

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

commit a0e3e70243f5b270bc3eca718f0a9fa5e6b8262e upstream.

Backport for stable kernel v2.6.32.y to v2.6.36.y.

Current oprofile's x86 callgraph support may trigger page faults
throwing the BUG_ON(in_nmi()) message below. This patch fixes this by
using the same nmi-safe copy-from-user code as in perf.

------------[ cut here ]------------
kernel BUG at .../arch/x86/kernel/traps.c:436!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:0a.0/0000:07:00.0/0000:08:04.0/net/eth0/broadcast
CPU 5
Modules linked in:

Pid: 8611, comm: opcontrol Not tainted 2.6.39-00007-gfe47ae7 #1 Advanced Micro Device Anaheim/Anaheim
RIP: 0010:[<ffffffff813e8e35>]  [<ffffffff813e8e35>] do_nmi+0x22/0x1ee
RSP: 0000:ffff88042fd47f28  EFLAGS: 00010002
RAX: ffff88042c0a7fd8 RBX: 0000000000000001 RCX: 00000000c0000101
RDX: 00000000ffff8804 RSI: ffffffffffffffff RDI: ffff88042fd47f58
RBP: ffff88042fd47f48 R08: 0000000000000004 R09: 0000000000001484
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88042fd47f58
R13: 0000000000000000 R14: ffff88042fd47d98 R15: 0000000000000020
FS:  00007fca25e56700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000074 CR3: 000000042d28b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process opcontrol (pid: 8611, threadinfo ffff88042c0a6000, task ffff88042c532310)
Stack:
 0000000000000000 0000000000000001 ffff88042c0a7fd8 0000000000000000
 ffff88042fd47de8 ffffffff813e897a 0000000000000020 ffff88042fd47d98
 0000000000000000 ffff88042c0a7fd8 ffff88042fd47de8 0000000000000074
Call Trace:
 <NMI>
 [<ffffffff813e897a>] nmi+0x1a/0x20
 [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771
 <<EOE>>
Code: ff 59 5b 41 5c 41 5d c9 c3 55 65 48 8b 04 25 88 b5 00 00 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 f6 80 47 e0 ff ff 04 74 04 <0f> 0b eb fe 81 80 44 e0 ff ff 00 00 01 04 65 ff 04 25 c4 0f 01
RIP  [<ffffffff813e8e35>] do_nmi+0x22/0x1ee
 RSP <ffff88042fd47f28>
---[ end trace ed6752185092104b ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 8611, comm: opcontrol Tainted: G      D     2.6.39-00007-gfe47ae7 #1
Call Trace:
 <NMI>  [<ffffffff813e5e0a>] panic+0x8c/0x188
 [<ffffffff813e915c>] oops_end+0x81/0x8e
 [<ffffffff8100403d>] die+0x55/0x5e
 [<ffffffff813e8c45>] do_trap+0x11c/0x12b
 [<ffffffff810023c8>] do_invalid_op+0x91/0x9a
 [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee
 [<ffffffff8131e6fa>] ? oprofile_add_sample+0x83/0x95
 [<ffffffff81321670>] ? op_amd_check_ctrs+0x4f/0x2cf
 [<ffffffff813ee4d5>] invalid_op+0x15/0x20
 [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee
 [<ffffffff813e8e7a>] ? do_nmi+0x67/0x1ee
 [<ffffffff813e897a>] nmi+0x1a/0x20
 [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771
 <<EOE>>

Cc: John Lumby <johnlumby@hotmail.com>
Cc: Maynard Johnson <maynardj@us.ibm.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/oprofile/backtrace.c |   46 +++++++++++++++++++++++++++++++++++++---
 1 files changed, 42 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/arch/x86/oprofile/backtrace.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/oprofile/backtrace.c	2012-02-05 22:34:33.047915246 +0100
+++ longterm-2.6.27/arch/x86/oprofile/backtrace.c	2012-02-05 22:34:43.985914946 +0100
@@ -11,6 +11,8 @@
 #include <linux/oprofile.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
+#include <linux/highmem.h>
+
 #include <asm/ptrace.h>
 #include <asm/uaccess.h>
 #include <asm/stacktrace.h>
@@ -47,6 +49,42 @@
 	.address = backtrace_address,
 };
 
+/* from arch/x86/kernel/cpu/perf_event.c: */
+
+/*
+ * best effort, GUP based copy_from_user() that assumes IRQ or NMI context
+ */
+static unsigned long
+copy_from_user_nmi(void *to, const void __user *from, unsigned long n)
+{
+	unsigned long offset, addr = (unsigned long)from;
+	unsigned long size, len = 0;
+	struct page *page;
+	void *map;
+	int ret;
+
+	do {
+		ret = __get_user_pages_fast(addr, 1, 0, &page);
+		if (!ret)
+			break;
+
+		offset = addr & (PAGE_SIZE - 1);
+		size = min(PAGE_SIZE - offset, n - len);
+
+		map = kmap_atomic(page, KM_USER0);
+		memcpy(to, map+offset, size);
+		kunmap_atomic(map, KM_USER0);
+		put_page(page);
+
+		len  += size;
+		to   += size;
+		addr += size;
+
+	} while (len < n);
+
+	return len;
+}
+
 struct frame_head {
 	struct frame_head *bp;
 	unsigned long ret;
@@ -55,12 +93,12 @@
 static struct frame_head *
 dump_user_backtrace(struct frame_head * head)
 {
+	/* Also check accessibility of one struct frame_head beyond: */
 	struct frame_head bufhead[2];
+	unsigned long bytes;
 
-	/* Also check accessibility of one struct frame_head beyond */
-	if (!access_ok(VERIFY_READ, head, sizeof(bufhead)))
-		return NULL;
-	if (__copy_from_user_inatomic(bufhead, head, sizeof(bufhead)))
+	bytes = copy_from_user_nmi(bufhead, head, sizeof(bufhead));
+	if (bytes != sizeof(bufhead))
 		return NULL;
 
 	oprofile_add_trace(bufhead[0].ret);

[PATCH 65/91] ext4: avoid hangs in ext4_da_should_update_i_disksize()

[Willy Tarreau]

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

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

commit ea51d132dbf9b00063169c1159bee253d9649224 upstream.

If the pte mapping in generic_perform_write() is unmapped between
iov_iter_fault_in_readable() and iov_iter_copy_from_user_atomic(), the
"copied" parameter to ->end_write can be zero. ext4 couldn't cope with
it with delayed allocations enabled. This skips the i_disksize
enlargement logic if copied is zero and no new data was appeneded to
the inode.

 gdb> bt
 #0  0xffffffff811afe80 in ext4_da_should_update_i_disksize (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x1\
 08000, len=0x1000, copied=0x0, page=0xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2467
 #1  ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\
 xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512
 #2  0xffffffff810d97f1 in generic_perform_write (iocb=<value optimized out>, iov=<value optimized out>, nr_segs=<value o\
 ptimized out>, pos=0x108000, ppos=0xffff88001e26be40, count=<value optimized out>, written=0x0) at mm/filemap.c:2440
 #3  generic_file_buffered_write (iocb=<value optimized out>, iov=<value optimized out>, nr_segs=<value optimized out>, p\
 os=0x108000, ppos=0xffff88001e26be40, count=<value optimized out>, written=0x0) at mm/filemap.c:2482
 #4  0xffffffff810db5d1 in __generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, ppos=0\
 xffff88001e26be40) at mm/filemap.c:2600
 #5  0xffffffff810db853 in generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=<value optimi\
 zed out>, pos=<value optimized out>) at mm/filemap.c:2632
 #6  0xffffffff811a71aa in ext4_file_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, pos=0x108000) a\
 t fs/ext4/file.c:136
 #7  0xffffffff811375aa in do_sync_write (filp=0xffff88003f606a80, buf=<value optimized out>, len=<value optimized out>, \
 ppos=0xffff88001e26bf48) at fs/read_write.c:406
 #8  0xffffffff81137e56 in vfs_write (file=0xffff88003f606a80, buf=0x1ec2960 <Address 0x1ec2960 out of bounds>, count=0x4\
 000, pos=0xffff88001e26bf48) at fs/read_write.c:435
 #9  0xffffffff8113816c in sys_write (fd=<value optimized out>, buf=0x1ec2960 <Address 0x1ec2960 out of bounds>, count=0x\
 4000) at fs/read_write.c:487
 #10 <signal handler called>
 #11 0x00007f120077a390 in __brk_reservation_fn_dmi_alloc__ ()
 #12 0x0000000000000000 in ?? ()
 gdb> print offset
 $22 = 0xffffffffffffffff
 gdb> print idx
 $23 = 0xffffffff
 gdb> print inode->i_blkbits
 $24 = 0xc
 gdb> up
 #1  ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\
 xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512
 2512                    if (ext4_da_should_update_i_disksize(page, end)) {
 gdb> print start
 $25 = 0x0
 gdb> print end
 $26 = 0xffffffffffffffff
 gdb> print pos
 $27 = 0x108000
 gdb> print new_i_size
 $28 = 0x108000
 gdb> print ((struct ext4_inode_info *)((char *)inode-((int)(&((struct ext4_inode_info *)0)->vfs_inode))))->i_disksize
 $29 = 0xd9000
 gdb> down
 2467            for (i = 0; i < idx; i++)
 gdb> print i
 $30 = 0xd44acbee

This is 100% reproducible with some autonuma development code tuned in
a very aggressive manner (not normal way even for knumad) which does
"exotic" changes to the ptes. It wouldn't normally trigger but I don't
see why it can't happen normally if the page is added to swap cache in
between the two faults leading to "copied" being zero (which then
hangs in ext4). So it should be fixed. Especially possible with lumpy
reclaim (albeit disabled if compaction is enabled) as that would
ignore the young bits in the ptes.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/ext4/inode.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/fs/ext4/inode.c
===================================================================
--- longterm-2.6.27.orig/fs/ext4/inode.c	2012-02-05 22:34:33.021914803 +0100
+++ longterm-2.6.27/fs/ext4/inode.c	2012-02-05 22:34:44.128916205 +0100
@@ -2816,7 +2816,7 @@
 	 */
 
 	new_i_size = pos + copied;
-	if (new_i_size > EXT4_I(inode)->i_disksize) {
+	if (copied && new_i_size > EXT4_I(inode)->i_disksize) {
 		if (ext4_da_should_update_i_disksize(page, end)) {
 			down_write(&EXT4_I(inode)->i_data_sem);
 			if (new_i_size > EXT4_I(inode)->i_disksize) {

[PATCH 66/91] offb: Fix setting of the pseudo-palette for >8bpp

[Willy Tarreau]

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

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

commit 1bb0b7d21584b3f878e2bc880db62351ddee5185 upstream.

When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
and doesn't touch the color map even if it has a corresponding access method
for the real hardware.

Thus it needs to set the pseudo-palette with all 3 components of the color,
like other truecolor framebuffers, not with copies of the color index like
a directcolor framebuffer would do.

This went unnoticed for a long time because it's pretty hard to get offb
to kick in with anything but 8bpp (old BootX under MacOS will do that and
qemu does it).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/video/offb.c |   50 +++++++++++++++++++++++---------------------------
 1 files changed, 23 insertions(+), 27 deletions(-)

Index: longterm-2.6.27/drivers/video/offb.c
===================================================================
--- longterm-2.6.27.orig/drivers/video/offb.c	2012-02-05 22:34:32.996915260 +0100
+++ longterm-2.6.27/drivers/video/offb.c	2012-02-05 22:34:44.268915456 +0100
@@ -100,36 +100,32 @@
 			  u_int transp, struct fb_info *info)
 {
 	struct offb_par *par = (struct offb_par *) info->par;
-	int i, depth;
-	u32 *pal = info->pseudo_palette;
 
-	depth = info->var.bits_per_pixel;
-	if (depth == 16)
-		depth = (info->var.green.length == 5) ? 15 : 16;
-
-	if (regno > 255 ||
-	    (depth == 16 && regno > 63) ||
-	    (depth == 15 && regno > 31))
-		return 1;
-
-	if (regno < 16) {
-		switch (depth) {
-		case 15:
-			pal[regno] = (regno << 10) | (regno << 5) | regno;
-			break;
-		case 16:
-			pal[regno] = (regno << 11) | (regno << 5) | regno;
-			break;
-		case 24:
-			pal[regno] = (regno << 16) | (regno << 8) | regno;
-			break;
-		case 32:
-			i = (regno << 8) | regno;
-			pal[regno] = (i << 16) | i;
-			break;
+	if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+		u32 *pal = info->pseudo_palette;
+		u32 cr = red >> (16 - info->var.red.length);
+		u32 cg = green >> (16 - info->var.green.length);
+		u32 cb = blue >> (16 - info->var.blue.length);
+		u32 value;
+
+		if (regno >= 16)
+			return -EINVAL;
+
+		value = (cr << info->var.red.offset) |
+			(cg << info->var.green.offset) |
+			(cb << info->var.blue.offset);
+		if (info->var.transp.length > 0) {
+			u32 mask = (1 << info->var.transp.length) - 1;
+			mask <<= info->var.transp.offset;
+			value |= mask;
 		}
+		pal[regno] = value;
+		return 0;
 	}
 
+	if (regno > 255)
+		return -EINVAL;
+
 	red >>= 8;
 	green >>= 8;
 	blue >>= 8;

[PATCH 67/91] offb: Fix bug in calculating requested vram size

[Willy Tarreau]

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

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

commit c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 upstream.

We used to try to request 8 times more vram than needed, which would
fail if the card has a too small BAR (observed with qemu & kvm).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/video/offb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/video/offb.c
===================================================================
--- longterm-2.6.27.orig/drivers/video/offb.c	2012-02-05 22:34:44.268915456 +0100
+++ longterm-2.6.27/drivers/video/offb.c	2012-02-05 22:34:44.406915262 +0100
@@ -368,7 +368,7 @@
 				int pitch, unsigned long address,
 				int foreign_endian, struct device_node *dp)
 {
-	unsigned long res_size = pitch * height * (depth + 7) / 8;
+	unsigned long res_size = pitch * height;
 	struct offb_par *par = &default_par;
 	unsigned long res_start = address;
 	struct fb_fix_screeninfo *fix;

[PATCH 68/91] usb: usb-storage doesnt support dynamic id currently, the patch disables the feature to fix an oops

[Willy Tarreau]

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

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

commit 1a3a026ba1b6bbfe0b7f79ab38cf991d691e7c9a upstream.

Echo vendor and product number of a non usb-storage device to
usb-storage driver's new_id, then plug in the device to host and you
will find following oops msg, the root cause is usb_stor_probe1()
refers invalid id entry if giving a dynamic id, so just disable the
feature.

[ 3105.018012] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 3105.018062] CPU 0
[ 3105.018075] Modules linked in: usb_storage usb_libusual bluetooth
dm_crypt binfmt_misc snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep hp_wmi ppdev sparse_keymap snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse snd
serio_raw tpm_infineon soundcore i915 snd_page_alloc tpm_tis
parport_pc tpm tpm_bios drm_kms_helper drm i2c_algo_bit video lp
parport usbhid hid sg sr_mod sd_mod ehci_hcd uhci_hcd usbcore e1000e
usb_common floppy
[ 3105.018408]
[ 3105.018419] Pid: 189, comm: khubd Tainted: G          I  3.2.0-rc7+
#29 Hewlett-Packard HP Compaq dc7800p Convertible Minitower/0AACh
[ 3105.018481] RIP: 0010:[<ffffffffa045830d>]  [<ffffffffa045830d>]
usb_stor_probe1+0x2fd/0xc20 [usb_storage]
[ 3105.018536] RSP: 0018:ffff880056a3d830  EFLAGS: 00010286
[ 3105.018562] RAX: ffff880065f4e648 RBX: ffff88006bb28000 RCX: 0000000000000000
[ 3105.018597] RDX: ffff88006f23c7b0 RSI: 0000000000000001 RDI: 0000000000000206
[ 3105.018632] RBP: ffff880056a3d900 R08: 0000000000000000 R09: ffff880067365000
[ 3105.018665] R10: 00000000000002ac R11: 0000000000000010 R12: ffff6000b41a7340
[ 3105.018698] R13: ffff880065f4ef60 R14: ffff88006bb28b88 R15: ffff88006f23d270
[ 3105.018733] FS:  0000000000000000(0000) GS:ffff88007a200000(0000)
knlGS:0000000000000000
[ 3105.018773] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3105.018801] CR2: 00007fc99c8c4650 CR3: 0000000001e05000 CR4: 00000000000006f0
[ 3105.018835] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3105.018870] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 3105.018906] Process khubd (pid: 189, threadinfo ffff880056a3c000,
task ffff88005677a400)
[ 3105.018945] Stack:
[ 3105.018959]  0000000000000000 0000000000000000 ffff880056a3d8d0
0000000000000002
[ 3105.019011]  0000000000000000 ffff880056a3d918 ffff880000000000
0000000000000002
[ 3105.019058]  ffff880056a3d8d0 0000000000000012 ffff880056a3d8d0
0000000000000006
[ 3105.019105] Call Trace:
[ 3105.019128]  [<ffffffffa0458cd4>] storage_probe+0xa4/0xe0 [usb_storage]
[ 3105.019173]  [<ffffffffa0097822>] usb_probe_interface+0x172/0x330 [usbcore]
[ 3105.019211]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019243]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019272]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019303]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019334]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019364]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.019396]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.019434]  [<ffffffffa0094e42>] usb_set_configuration+0x822/0x9e0 [usbcore]
[ 3105.019479]  [<ffffffffa00a3492>] generic_probe+0x62/0xf0 [usbcore]
[ 3105.019518]  [<ffffffffa0097a46>] usb_probe_device+0x66/0xb0 [usbcore]
[ 3105.019555]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019589]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019617]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019648]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019680]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019709]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.021040] usb usb6: usb auto-resume
[ 3105.021045] usb usb6: wakeup_rh
[ 3105.024849]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.025086]  [<ffffffffa0088987>] usb_new_device+0x1e7/0x2b0 [usbcore]
[ 3105.025086]  [<ffffffffa008a4d7>] hub_thread+0xb27/0x1ec0 [usbcore]
[ 3105.025086]  [<ffffffff810d5200>] ? wake_up_bit+0x50/0x50
[ 3105.025086]  [<ffffffffa00899b0>] ? usb_remote_wakeup+0xa0/0xa0 [usbcore]
[ 3105.025086]  [<ffffffff810d49b8>] kthread+0xd8/0xf0
[ 3105.025086]  [<ffffffff81939884>] kernel_thread_helper+0x4/0x10
[ 3105.025086]  [<ffffffff8192a8c0>] ? _raw_spin_unlock_irq+0x50/0x80
[ 3105.025086]  [<ffffffff8192b1b4>] ? retint_restore_args+0x13/0x13
[ 3105.025086]  [<ffffffff810d48e0>] ? __init_kthread_worker+0x80/0x80
[ 3105.025086]  [<ffffffff81939880>] ? gs_change+0x13/0x13
[ 3105.025086] Code: 00 48 83 05 cd ad 00 00 01 48 83 05 cd ad 00 00
01 4c 8b ab 30 0c 00 00 48 8b 50 08 48 83 c0 30 48 89 45 a0 4c 89 a3
40 0c 00 00 <41> 0f b6 44 24 10 48 89 55 a8 3c ff 0f 84 b8 04 00 00 48
83 05
[ 3105.025086] RIP  [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20
[usb_storage]
[ 3105.025086]  RSP <ffff880056a3d830>
[ 3105.060037] hub 6-0:1.0: hub_resume
[ 3105.062616] usb usb5: usb auto-resume
[ 3105.064317] ehci_hcd 0000:00:1d.7: resume root hub
[ 3105.094809] ---[ end trace a7919e7f17c0a727 ]---
[ 3105.130069] hub 5-0:1.0: hub_resume
[ 3105.132131] usb usb4: usb auto-resume
[ 3105.132136] usb usb4: wakeup_rh
[ 3105.180059] hub 4-0:1.0: hub_resume
[ 3106.290052] usb usb6: suspend_rh (auto-stop)
[ 3106.290077] usb usb4: suspend_rh (auto-stop)

Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/usb/storage/usb.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/usb/storage/usb.c
===================================================================
--- longterm-2.6.27.orig/drivers/usb/storage/usb.c	2012-02-05 22:34:32.917914806 +0100
+++ longterm-2.6.27/drivers/usb/storage/usb.c	2012-02-05 22:34:44.546914890 +0100
@@ -1065,6 +1065,7 @@
 	.post_reset =	storage_post_reset,
 	.id_table =	storage_usb_ids,
 	.soft_unbind =	1,
+	.no_dynamic_id = 1,
 };
 
 static int __init usb_stor_init(void)

[PATCH 69/91] SCSI: scsi_dh: check queuedata pointer before proceeding further

[Willy Tarreau]

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

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

commit a18a920c70d48a8e4a2b750d8a183b3c1a4be514 upstream.

This patch validates sdev pointer in scsi_dh_activate before proceeding further.

Without this check we might see the panic as below. I have seen this
panic multiple times..

Call trace:

 #0 [ffff88007d647b50] machine_kexec at ffffffff81020902
 #1 [ffff88007d647ba0] crash_kexec at ffffffff810875b0
 #2 [ffff88007d647c70] oops_end at ffffffff8139c650
 #3 [ffff88007d647c90] __bad_area_nosemaphore at ffffffff8102dd15
 #4 [ffff88007d647d50] page_fault at ffffffff8139b8cf
    [exception RIP: scsi_dh_activate+0x82]
    RIP: ffffffffa0041922  RSP: ffff88007d647e00  RFLAGS: 00010046
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 00000000000093c5
    RDX: 00000000000093c5  RSI: ffffffffa02e6640  RDI: ffff88007cc88988
    RBP: 000000000000000f   R8: ffff88007d646000   R9: 0000000000000000
    R10: ffff880082293790  R11: 00000000ffffffff  R12: ffff88007cc88988
    R13: 0000000000000000  R14: 0000000000000286  R15: ffff880037b845e0
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0000
 #5 [ffff88007d647e38] run_workqueue at ffffffff81060268
 #6 [ffff88007d647e78] worker_thread at ffffffff81060386
 #7 [ffff88007d647ee8] kthread at ffffffff81064436
 #8 [ffff88007d647f48] kernel_thread at ffffffff81003fba

Signed-off-by: Babu Moger <babu.moger@netapp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/device_handler/scsi_dh.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/scsi/device_handler/scsi_dh.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/device_handler/scsi_dh.c	2012-02-05 22:34:32.891915048 +0100
+++ longterm-2.6.27/drivers/scsi/device_handler/scsi_dh.c	2012-02-05 22:34:44.687914590 +0100
@@ -423,7 +423,12 @@
 
 	spin_lock_irqsave(q->queue_lock, flags);
 	sdev = q->queuedata;
-	if (sdev && sdev->scsi_dh_data)
+	if (!sdev) {
+		spin_unlock_irqrestore(q->queue_lock, flags);
+		return SCSI_DH_NOSYS;
+	}
+
+	if (sdev->scsi_dh_data)
 		scsi_dh = sdev->scsi_dh_data->scsi_dh;
 	if (!scsi_dh || !get_device(&sdev->sdev_gendev))
 		err = SCSI_DH_NOSYS;

[PATCH 70/91] ALSA: ice1724 - Check for ac97 to avoid kernel oops

[Willy Tarreau]

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

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

commit e7848163aa2a649d9065f230fadff80dc3519775 upstream.

Cards with identical PCI ids but no AC97 config in EEPROM do not have
the ac97 field initialized. We must check for this case to avoid kernel oops.

Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 sound/pci/ice1712/amp.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/sound/pci/ice1712/amp.c
===================================================================
--- longterm-2.6.27.orig/sound/pci/ice1712/amp.c	2012-02-05 22:34:32.865918049 +0100
+++ longterm-2.6.27/sound/pci/ice1712/amp.c	2012-02-05 22:34:44.825915033 +0100
@@ -67,8 +67,11 @@
 
 static int __devinit snd_vt1724_amp_add_controls(struct snd_ice1712 *ice)
 {
-	/* we use pins 39 and 41 of the VT1616 for left and right read outputs */
-	snd_ac97_write_cache(ice->ac97, 0x5a, snd_ac97_read(ice->ac97, 0x5a) & ~0x8000);
+	if (ice->ac97)
+		/* we use pins 39 and 41 of the VT1616 for left and right
+		read outputs */
+		snd_ac97_write_cache(ice->ac97, 0x5a,
+			snd_ac97_read(ice->ac97, 0x5a) & ~0x8000);
 	return 0;
 }
 

[PATCH 71/91] UBI: fix nameless volumes handling

[Willy Tarreau]

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

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

commit 4a59c797a18917a5cf3ff7ade296b46134d91e6a upstream.

Currently it's possible to create a volume without a name. E.g:
ubimkvol -n 32 -s 2MiB -t static /dev/ubi0 -N ""

After that vtbl_check() will always fail because it does not permit
empty strings.

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/mtd/ubi/cdev.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/mtd/ubi/cdev.c
===================================================================
--- longterm-2.6.27.orig/drivers/mtd/ubi/cdev.c	2012-02-05 22:34:32.837915400 +0100
+++ longterm-2.6.27/drivers/mtd/ubi/cdev.c	2012-02-05 22:34:44.966914934 +0100
@@ -569,6 +569,9 @@
 	if (req->alignment != 1 && n)
 		goto bad;
 
+	if (!req->name[0] || !req->name_len)
+		goto bad;
+
 	if (req->name_len > UBI_VOL_NAME_MAX) {
 		err = -ENAMETOOLONG;
 		goto bad;

[PATCH 72/91] svcrpc: fix double-free on shutdown of nfsd after changing pool mode

[Willy Tarreau]

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

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

commit 61c8504c428edcebf23b97775a129c5b393a302b upstream.

The pool_to and to_pool fields of the global svc_pool_map are freed on
shutdown, but are initialized in nfsd startup only in the
SVC_POOL_PERCPU and SVC_POOL_PERNODE cases.

They *are* initialized to zero on kernel startup.  So as long as you use
only SVC_POOL_GLOBAL (the default), this will never be a problem.

You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE.

However, the following sequence events leads to a double-free:

	1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE
	2. start nfsd: both fields are initialized.
	3. shutdown nfsd: both fields are freed.
	4. set SVC_POOL_GLOBAL
	5. start nfsd: the fields are left untouched.
	6. shutdown nfsd: now we try to free them again.

Step 4 is actually unnecessary, since (for some bizarre reason), nfsd
automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/sunrpc/svc.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/net/sunrpc/svc.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/svc.c	2012-02-05 22:34:32.810915144 +0100
+++ longterm-2.6.27/net/sunrpc/svc.c	2012-02-05 22:34:45.104915090 +0100
@@ -163,6 +163,7 @@
 
 fail_free:
 	kfree(m->to_pool);
+	m->to_pool = NULL;
 fail:
 	return -ENOMEM;
 }
@@ -283,7 +284,9 @@
 	if (!--m->count) {
 		m->mode = SVC_POOL_DEFAULT;
 		kfree(m->to_pool);
+		m->to_pool = NULL;
 		kfree(m->pool_to);
+		m->pool_to = NULL;
 		m->npools = 0;
 	}
 

[PATCH 73/91] nfsd: Fix oops when parsing a 0 length export

[Willy Tarreau]

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

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

commit b2ea70afade7080360ac55c4e64ff7a5fafdb67b upstream.

expkey_parse() oopses when handling a 0 length export. This is easily
triggerable from usermode by writing 0 bytes into
'/proc/[proc id]/net/rpc/nfsd.fh/channel'.

Below is the log:

[ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff
[ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
[ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160
[ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1402.287632] CPU 1
[ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6
[ 1402.287632] RIP: 0010:[<ffffffff812b4b99>]  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
[ 1402.287632] RSP: 0018:ffff880077f0fd68  EFLAGS: 00010292
[ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400
[ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0
[ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000
[ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000
[ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0
[ 1402.287632] FS:  00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
[ 1402.287632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0
[ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0)
[ 1402.287632] Stack:
[ 1402.287632]  ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e
[ 1402.287632]  ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0
[ 1402.287632]  0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63
[ 1402.287632] Call Trace:
[ 1402.287632]  [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc
[ 1402.287632]  [<ffffffff81111f63>] ? might_fault+0x97/0x9e
[ 1402.287632]  [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e
[ 1402.287632]  [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f
[ 1402.287632]  [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130
[ 1402.287632]  [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a
[ 1402.287632]  [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b
[ 1402.287632]  [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad
[ 1402.287632]  [<ffffffff8113fe81>] vfs_write+0xaa/0xfd
[ 1402.287632]  [<ffffffff8114142d>] ? fget_light+0x35/0x9e
[ 1402.287632]  [<ffffffff8113ff8b>] sys_write+0x48/0x6f
[ 1402.287632]  [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b
[ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff
[ 1402.287632]  38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85
[ 1402.287632] RIP  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
[ 1402.287632]  RSP <ffff880077f0fd68>
[ 1402.287632] CR2: ffff880077c49fff
[ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]---

Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/nfsd/export.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/fs/nfsd/export.c
===================================================================
--- longterm-2.6.27.orig/fs/nfsd/export.c	2012-02-05 22:34:32.786915116 +0100
+++ longterm-2.6.27/fs/nfsd/export.c	2012-02-05 22:34:45.243916126 +0100
@@ -101,7 +101,7 @@
 	struct svc_expkey key;
 	struct svc_expkey *ek;
 
-	if (mesg[mlen-1] != '\n')
+	if (mlen < 1 || mesg[mlen-1] != '\n')
 		return -EINVAL;
 	mesg[mlen-1] = 0;
 

[PATCH 74/91] sym53c8xx: Fix NULL pointer dereference in slave_destroy

[Willy Tarreau]

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

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

commit cced5041ed5a2d1352186510944b0ddfbdbe4c0b upstream.

sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has
succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference
(exposed by commit 4e6c82b).

Signed-off-by: Stratos Psomadakis <psomas@gentoo.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/sym53c8xx_2/sym_glue.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/sym53c8xx_2/sym_glue.c	2012-02-05 22:34:32.760914610 +0100
+++ longterm-2.6.27/drivers/scsi/sym53c8xx_2/sym_glue.c	2012-02-05 22:34:45.383915058 +0100
@@ -821,6 +821,10 @@
 	struct sym_hcb *np = sym_get_hcb(sdev->host);
 	struct sym_lcb *lp = sym_lp(&np->target[sdev->id], sdev->lun);
 
+	/* if slave_alloc returned before allocating a sym_lcb, return */
+	if (!lp)
+		return;
+
 	if (lp->itlq_tbl)
 		sym_mfree_dma(lp->itlq_tbl, SYM_CONF_MAX_TASK * 4, "ITLQ_TBL");
 	kfree(lp->cb_tags);

[PATCH 75/91] [PATCH] bonding: correctly process non-linear skbs

[Willy Tarreau]

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

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

commit ab12811c89e88f2e66746790b1fe4469ccb7bdd9 upstream.

It was recently brought to my attention that 802.3ad mode bonds would no
longer form when using some network hardware after a driver update.
After snooping around I realized that the particular hardware was using
page-based skbs and found that skb->data did not contain a valid LACPDU
as it was not stored there.  That explained the inability to form an
802.3ad-based bond.  For balance-alb mode bonds this was also an issue
as ARPs would not be properly processed.

This patch fixes the issue in my tests and should be applied to 2.6.36
and as far back as anyone cares to add it to stable.

Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/bonding/bond_3ad.c |    3 +++
 drivers/net/bonding/bond_alb.c |    3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/net/bonding/bond_3ad.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/bonding/bond_3ad.c	2012-02-05 22:34:32.729915391 +0100
+++ longterm-2.6.27/drivers/net/bonding/bond_3ad.c	2012-02-05 22:34:45.523916489 +0100
@@ -2436,6 +2436,9 @@
 	if (!(dev->flags & IFF_MASTER))
 		goto out;
 
+	if (!pskb_may_pull(skb, sizeof(struct lacpdu)))
+		goto out;
+
 	read_lock(&bond->lock);
 	slave = bond_get_slave_by_dev((struct bonding *)dev->priv, orig_dev);
 	if (!slave)
Index: longterm-2.6.27/drivers/net/bonding/bond_alb.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/bonding/bond_alb.c	2012-02-05 22:34:32.733915045 +0100
+++ longterm-2.6.27/drivers/net/bonding/bond_alb.c	2012-02-05 22:34:45.528915452 +0100
@@ -359,6 +359,9 @@
 		goto out;
 	}
 
+	if (!pskb_may_pull(skb, arp_hdr_len(bond_dev)))
+		goto out;
+
 	if (skb->len < sizeof(struct arp_pkt)) {
 		dprintk("Packet is too small to be an ARP\n");
 		goto out;

[PATCH 76/91] bonding: Ensure that we unshare skbs prior to calling pskb_may_pull

[Willy Tarreau]

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

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

commit b30532515f0a62bfe17207ab00883dd262497006 upstream.

Recently reported oops:

kernel BUG at net/core/skbuff.c:813!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/bond0/broadcast
CPU 8
Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
scsi_transport_sas dm_mod [last unloaded: microcode]

Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
scsi_transport_sas dm_mod [last unloaded: microcode]
Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22
-[7870AC1]-
RIP: 0010:[<ffffffff81405b16>]  [<ffffffff81405b16>]
pskb_expand_head+0x36/0x1e0
RSP: 0018:ffff880028303b70  EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80
RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64
R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000
R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0)
Stack:
 ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000
<0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00
<0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a
Call Trace:
<IRQ>
 [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90
 [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360
 [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding]
 [<ffffffff814a0857>] ? packet_rcv+0x377/0x440
 [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670
 [<ffffffff8140f788>] napi_skb_finish+0x58/0x70
 [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50
 [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe]
 [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe]
 [<ffffffff8140fe53>] net_rx_action+0x103/0x210
 [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0
 [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170
 [<ffffffff810142cc>] call_softirq+0x1c/0x30
 [<ffffffff81015f35>] do_softirq+0x65/0xa0
 [<ffffffff810739d5>] irq_exit+0x85/0x90
 [<ffffffff814cf915>] do_IRQ+0x75/0xf0
 [<ffffffff81013ad3>] ret_from_intr+0x0/0x11
 <EOI>
 [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0
 [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20
 [<ffffffff81011e96>] cpu_idle+0xb6/0x110
 [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f

Resulted from bonding driver registering packet handlers via dev_add_pack and
then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET
sockets) gets called first, the delivered skb will have a user count > 1, which
causes pskb_may_pull to BUG halt when it does its skb_shared check.  Fix this by
calling skb_share_check prior to the may_pull call sites in the bonding driver
to clone the skb when needed.  Tested by myself and the reported successfully.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/bonding/bond_3ad.c  |    4 ++++
 drivers/net/bonding/bond_alb.c  |    4 ++++
 drivers/net/bonding/bond_main.c |    4 ++++
 3 files changed, 12 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/drivers/net/bonding/bond_3ad.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/bonding/bond_3ad.c	2012-02-05 22:34:45.523916489 +0100
+++ longterm-2.6.27/drivers/net/bonding/bond_3ad.c	2012-02-05 22:34:45.677916635 +0100
@@ -2436,6 +2436,10 @@
 	if (!(dev->flags & IFF_MASTER))
 		goto out;
 
+	skb = skb_share_check(skb, GFP_ATOMIC);
+	if (!skb)
+		goto out;
+
 	if (!pskb_may_pull(skb, sizeof(struct lacpdu)))
 		goto out;
 
Index: longterm-2.6.27/drivers/net/bonding/bond_alb.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/bonding/bond_alb.c	2012-02-05 22:34:45.528915452 +0100
+++ longterm-2.6.27/drivers/net/bonding/bond_alb.c	2012-02-05 22:34:45.682915651 +0100
@@ -359,6 +359,10 @@
 		goto out;
 	}
 
+	skb = skb_share_check(skb, GFP_ATOMIC);
+	if (!skb)
+		goto out;
+
 	if (!pskb_may_pull(skb, arp_hdr_len(bond_dev)))
 		goto out;
 
Index: longterm-2.6.27/drivers/net/bonding/bond_main.c
===================================================================
--- longterm-2.6.27.orig/drivers/net/bonding/bond_main.c	2012-02-05 22:34:32.651914903 +0100
+++ longterm-2.6.27/drivers/net/bonding/bond_main.c	2012-02-05 22:34:45.691916958 +0100
@@ -2699,6 +2699,10 @@
 	if (!slave || !slave_do_arp_validate(bond, slave))
 		goto out_unlock;
 
+	skb = skb_share_check(skb, GFP_ATOMIC);
+	if (!skb)
+		goto out_unlock;
+
 	if (!pskb_may_pull(skb, arp_hdr_len(dev)))
 		goto out_unlock;
 

[PATCH 77/91] block: add proper state guards to __elv_next_request

[Willy Tarreau]

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

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

commit 0a58e077eb600d1efd7e54ad9926a75a39d7f8ae upstream.

blk_cleanup_queue() calls elevator_exit() and after this, we can't
touch the elevator without oopsing.  __elv_next_request() must check
for this state because in the refcounted queue model, we can still
call it after blk_cleanup_queue() has been called.

This was reported as causing an oops attributable to scsi.

[WT: in 2.6.27, __elv_next_request() is in elevator.c]

Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 block/clk.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/block/elevator.c
===================================================================
--- longterm-2.6.27.orig/block/elevator.c	2012-02-05 22:34:32.624915301 +0100
+++ longterm-2.6.27/block/elevator.c	2012-02-05 22:34:45.849915230 +0100
@@ -729,7 +729,8 @@
 				return rq;
 		}
 
-		if (!q->elevator->ops->elevator_dispatch_fn(q, 0))
+		if (test_bit(QUEUE_FLAG_DEAD, &q->queue_flags) ||
+		    !q->elevator->ops->elevator_dispatch_fn(q, 0))
 			return NULL;
 	}
 }

[PATCH 78/91] x86, 64-bit: Fix copy_[to/from]_user() checks for the userspace address limit

[Willy Tarreau]

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

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

commit 26afb7c661080ae3f1f13ddf7f0c58c4f931c22b upstream.

As reported in BZ #30352:

  https://bugzilla.kernel.org/show_bug.cgi?id=30352

there's a kernel bug related to reading the last allowed page on x86_64.

The _copy_to_user() and _copy_from_user() functions use the following
check for address limit:

  if (buf + size >= limit)
	fail();

while it should be more permissive:

  if (buf + size > limit)
	fail();

That's because the size represents the number of bytes being
read/write from/to buf address AND including the buf address.
So the copy function will actually never touch the limit
address even if "buf + size == limit".

Following program fails to use the last page as buffer
due to the wrong limit check:

 #include <sys/mman.h>
 #include <sys/socket.h>
 #include <assert.h>

 #define PAGE_SIZE       (4096)
 #define LAST_PAGE       ((void*)(0x7fffffffe000))

 int main()
 {
        int fds[2], err;
        void * ptr = mmap(LAST_PAGE, PAGE_SIZE, PROT_READ | PROT_WRITE,
                          MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0);
        assert(ptr == LAST_PAGE);
        err = socketpair(AF_LOCAL, SOCK_STREAM, 0, fds);
        assert(err == 0);
        err = send(fds[0], ptr, PAGE_SIZE, 0);
        perror("send");
        assert(err == PAGE_SIZE);
        err = recv(fds[1], ptr, PAGE_SIZE, MSG_WAITALL);
        perror("recv");
        assert(err == PAGE_SIZE);
        return 0;
 }

The other place checking the addr limit is the access_ok() function,
which is working properly. There's just a misleading comment
for the __range_not_ok() macro - which this patch fixes as well.

The last page of the user-space address range is a guard page and
Brian Gerst observed that the guard page itself due to an erratum on K8 cpus
(#121 Sequential Execution Across Non-Canonical Boundary Causes Processor
Hang).

However, the test code is using the last valid page before the guard page.
The bug is that the last byte before the guard page can't be read
because of the off-by-one error. The guard page is left in place.

This bug would normally not show up because the last page is
part of the process stack and never accessed via syscalls.

[WT: in 2.6.27 use include/asm-x86/uaccess.h]

Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Brian Gerst <brgerst@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1305210630-7136-1-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/include/asm/uaccess.h |    2 +-
 arch/x86/lib/copy_user_64.S    |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/include/asm-x86/uaccess.h
===================================================================
--- longterm-2.6.27.orig/include/asm-x86/uaccess.h	2012-02-05 22:34:32.595915339 +0100
+++ longterm-2.6.27/include/asm-x86/uaccess.h	2012-02-05 22:34:45.985914777 +0100
@@ -42,7 +42,7 @@
  * Returns 0 if the range is valid, nonzero otherwise.
  *
  * This is equivalent to the following test:
- * (u33)addr + (u33)size >= (u33)current->addr_limit.seg (u65 for x86_64)
+ * (u33)addr + (u33)size > (u33)current->addr_limit.seg (u65 for x86_64)
  *
  * This needs 33-bit (65-bit for x86_64) arithmetic. We have a carry...
  */
Index: longterm-2.6.27/arch/x86/lib/copy_user_64.S
===================================================================
--- longterm-2.6.27.orig/arch/x86/lib/copy_user_64.S	2012-02-05 22:34:32.601914938 +0100
+++ longterm-2.6.27/arch/x86/lib/copy_user_64.S	2012-02-05 22:34:45.992914590 +0100
@@ -72,7 +72,7 @@
 	addq %rdx,%rcx
 	jc bad_to_user
 	cmpq TI_addr_limit(%rax),%rcx
-	jae bad_to_user
+	ja bad_to_user
 	ALTERNATIVE_JUMP X86_FEATURE_REP_GOOD,copy_user_generic_unrolled,copy_user_generic_string
 	CFI_ENDPROC
 
@@ -84,7 +84,7 @@
 	addq %rdx,%rcx
 	jc bad_from_user
 	cmpq TI_addr_limit(%rax),%rcx
-	jae bad_from_user
+	ja bad_from_user
 	ALTERNATIVE_JUMP X86_FEATURE_REP_GOOD,copy_user_generic_unrolled,copy_user_generic_string
 	CFI_ENDPROC
 ENDPROC(copy_from_user)

[PATCH 79/91] SCSI: scsi_lib: fix potential NULL dereference

[Willy Tarreau]

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

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

commit 03b147083a2f9a2a3fbbd2505fa88ffa3c6ab194 upstream.

Stanse found a potential NULL dereference in scsi_kill_request.

Instead of triggering BUG() in 'if (unlikely(cmd == NULL))' branch,
the kernel will Oops earlier on cmd dereference.

Move the dereferences after the if.

[ WT: starget is not set in 2.6.27 ]

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/scsi/scsi_lib.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/scsi/scsi_lib.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/scsi_lib.c	2012-02-05 22:34:42.697916475 +0100
+++ longterm-2.6.27/drivers/scsi/scsi_lib.c	2012-02-05 22:34:46.142917247 +0100
@@ -1389,8 +1389,8 @@
 static void scsi_kill_request(struct request *req, struct request_queue *q)
 {
 	struct scsi_cmnd *cmd = req->special;
-	struct scsi_device *sdev = cmd->device;
-	struct Scsi_Host *shost = sdev->host;
+	struct scsi_device *sdev;
+	struct Scsi_Host *shost;
 
 	blkdev_dequeue_request(req);
 
@@ -1400,6 +1400,8 @@
 		BUG();
 	}
 
+	sdev = cmd->device;
+	shost = sdev->host;
 	scsi_init_cmd_errh(cmd);
 	cmd->result = DID_NO_CONNECT << 16;
 	atomic_inc(&cmd->device->iorequest_cnt);

[PATCH 80/91] MAINTAINERS: stable: Update address

[Willy Tarreau]

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

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

commit bc7a2f3abc636d7cab84258a48e77b08fb5fd3d6 upstream.

The old address hasn't worked since the great intrusion of August 2011.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 MAINTAINERS |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/MAINTAINERS
===================================================================
--- longterm-2.6.27.orig/MAINTAINERS	2012-02-05 22:34:32.541914736 +0100
+++ longterm-2.6.27/MAINTAINERS	2012-02-05 22:34:46.294916794 +0100
@@ -3857,7 +3857,7 @@
 STABLE BRANCH:
 P:	Greg Kroah-Hartman
 M:	greg@kroah.com
-L:	stable@kernel.org
+L:	stable@vger.kernel.org
 S:	Maintained
 
 SHARP LH SUPPORT (LH7952X & LH7A40X)

[PATCH 81/91] af_packet: prevent information leak

[Willy Tarreau]

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

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

[ Upstream commit 13fcb7bd322164c67926ffe272846d4860196dc6 ]

In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
added a small information leak.

Add padding field and make sure its zeroed before copy to user.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 include/linux/if_packet.h |    2 ++
 net/packet/af_packet.c    |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/include/linux/if_packet.h
===================================================================
--- longterm-2.6.27.orig/include/linux/if_packet.h	2012-02-05 22:34:32.515915059 +0100
+++ longterm-2.6.27/include/linux/if_packet.h	2012-02-05 22:34:46.429914864 +0100
@@ -61,6 +61,7 @@
 	__u16		tp_mac;
 	__u16		tp_net;
 	__u16		tp_vlan_tci;
+	__u16		tp_padding;
 };
 
 struct tpacket_hdr
@@ -93,6 +94,7 @@
 	__u32		tp_sec;
 	__u32		tp_nsec;
 	__u16		tp_vlan_tci;
+	__u16		tp_padding;
 };
 
 #define TPACKET2_HDRLEN		(TPACKET_ALIGN(sizeof(struct tpacket2_hdr)) + sizeof(struct sockaddr_ll))
Index: longterm-2.6.27/net/packet/af_packet.c
===================================================================
--- longterm-2.6.27.orig/net/packet/af_packet.c	2012-02-05 22:34:32.520914890 +0100
+++ longterm-2.6.27/net/packet/af_packet.c	2012-02-05 22:34:46.438916430 +0100
@@ -708,6 +708,7 @@
 		h.h2->tp_sec = ts.tv_sec;
 		h.h2->tp_nsec = ts.tv_nsec;
 		h.h2->tp_vlan_tci = skb->vlan_tci;
+		h.h2->tp_padding = 0;
 		hdrlen = sizeof(*h.h2);
 		break;
 	default:
@@ -1181,6 +1182,7 @@
 		aux.tp_net = skb_network_offset(skb);
 		aux.tp_vlan_tci = skb->vlan_tci;
 
+		aux.tp_padding = 0;
 		put_cmsg(msg, SOL_PACKET, PACKET_AUXDATA, sizeof(aux), &aux);
 	}
 

[PATCH 82/91] Fix time() inconsistencies caused by intermediate xtime_cache values being read

[Willy Tarreau]

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

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

Currently with 2.6.32-longterm, its possible for time() to occasionally
return values one second earlier then the previous time() call.

This happens because update_xtime_cache() does:
	xtime_cache = xtime;
	timespec_add_ns(&xtime_cache, nsec);

Its possible that xtime is 1sec,999msecs, and nsecs is 1ms, resulting in
a xtime_cache that is 2sec,0ms.

get_seconds() (which is used by sys_time()) does not take the
xtime_lock, which is ok as the xtime.tv_sec value is a long and can be
atomically read safely.

The problem occurs the next call to update_xtime_cache() if xtime has
not increased:
	/* This sets xtime_cache back to 1sec, 999msec */
	xtime_cache = xtime;
	/* get_seconds, calls here, and sees a 1second inconsistency */
	timespec_add_ns(&xtime_cache, nsec);


In order to resolve this, we could add locking to get_seconds(), but it
needs to be lock free, as it is called from the machine check handler,
opening a possible deadlock.

So instead, this patch introduces an intermediate value for the
calculations, so that we only assign xtime_cache once with the correct
time, using ACCESS_ONCE to make sure the compiler doesn't optimize out
any intermediate values.

The xtime_cache manipulations were removed with 2.6.35, so that kernel
and later do not need this change.

In 2.6.33 and 2.6.34 the logarithmic accumulation should make it so
xtime is updated each tick, so it is unlikely that two updates to
xtime_cache could occur while the difference between xtime and
xtime_cache crosses the second boundary. However, the paranoid might
want to pull this into 2.6.33/34-longterm just to be sure.

Thanks to Stephen for helping finally narrow down the root cause and
many hours of help with testing and validation. Also thanks to Max,
Andi, Eric and Paul for review of earlier attempts and helping clarify
what is possible with regard to out of order execution.

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 kernel/time/timekeeping.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/kernel/time/timekeeping.c
===================================================================
--- longterm-2.6.27.orig/kernel/time/timekeeping.c	2012-02-05 22:34:32.487915124 +0100
+++ longterm-2.6.27/kernel/time/timekeeping.c	2012-02-05 22:34:46.587915458 +0100
@@ -52,8 +52,15 @@
 static struct timespec xtime_cache __attribute__ ((aligned (16)));
 void update_xtime_cache(u64 nsec)
 {
-	xtime_cache = xtime;
-	timespec_add_ns(&xtime_cache, nsec);
+	/*
+	 * Use temporary variable so get_seconds() cannot catch
+	 * an intermediate xtime_cache.tv_sec value.
+	 * The ACCESS_ONCE() keeps the compiler from optimizing
+	 * out the intermediate value.
+	 */
+	struct timespec ts = xtime;
+	timespec_add_ns(&ts, nsec);
+	ACCESS_ONCE(xtime_cache) = ts;
 }
 
 struct clocksource *clock;

[PATCH 83/91] net/ipv4: Check for mistakenly passed in non-IPv4 address

[Willy Tarreau]

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

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

[ Upstream commit d0733d2e29b652b2e7b1438ececa732e4eed98eb ]

Check against mistakenly passing in IPv6 addresses (which would result
in an INADDR_ANY bind) or similar incompatible sockaddrs.

Signed-off-by: Marcus Meissner <meissner@suse.de>
Cc: Reinhard Max <max@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ipv4/af_inet.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/net/ipv4/af_inet.c
===================================================================
--- longterm-2.6.27.orig/net/ipv4/af_inet.c	2012-02-05 22:34:32.462915223 +0100
+++ longterm-2.6.27/net/ipv4/af_inet.c	2012-02-05 22:34:46.727915859 +0100
@@ -458,6 +458,9 @@
 	if (addr_len < sizeof(struct sockaddr_in))
 		goto out;
 
+	if (addr->sin_family != AF_INET)
+		goto out;
+
 	chk_addr_ret = inet_addr_type(sock_net(sk), addr->sin_addr.s_addr);
 
 	/* Not specified by any standard per-se, however it breaks too

[PATCH 84/91] x86: Fix mmap random address range

[Willy Tarreau]

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

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

commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.

On x86_32 casting the unsigned int result of get_random_int() to
long may result in a negative value.  On x86_32 the range of
mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
used 0 to 255 as intended.

The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
in January 2008.

Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: harvey.harrison@gmail.com
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/mm/mmap.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/arch/x86/mm/mmap.c
===================================================================
--- longterm-2.6.27.orig/arch/x86/mm/mmap.c	2012-02-05 22:34:32.437915058 +0100
+++ longterm-2.6.27/arch/x86/mm/mmap.c	2012-02-05 22:34:46.864914382 +0100
@@ -87,9 +87,9 @@
 	*/
 	if (current->flags & PF_RANDOMIZE) {
 		if (mmap_is_ia32())
-			rnd = (long)get_random_int() % (1<<8);
+			rnd = get_random_int() % (1<<8);
 		else
-			rnd = (long)(get_random_int() % (1<<28));
+			rnd = get_random_int() % (1<<28);
 	}
 	return rnd << PAGE_SHIFT;
 }

[PATCH 85/91] i8k: Tell gcc that *regs gets clobbered

[Willy Tarreau]

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

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

commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 upstream.

More recent GCC caused the i8k driver to stop working, on Slackware
compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't
work anymore, meaning the driver didn't load or gave total nonsensical
output.

As it turned out the asm(..) statement forgot to mention it modifies the
*regs variable.

Credits to Andi Kleen and Andreas Schwab for providing the fix.

Signed-off-by: Jim Bos <jim876@xs4all.nl>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/i8k.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/drivers/char/i8k.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/i8k.c	2012-02-05 22:34:32.409914870 +0100
+++ longterm-2.6.27/drivers/char/i8k.c	2012-02-05 22:34:47.002916726 +0100
@@ -141,7 +141,7 @@
 		"lahf\n\t"
 		"shrl $8,%%eax\n\t"
 		"andl $1,%%eax\n"
-		:"=a"(rc)
+		:"=a"(rc), "+m" (*regs)
 		:    "a"(regs)
 		:    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #else
@@ -166,7 +166,8 @@
 	    "movl %%edx,0(%%eax)\n\t"
 	    "lahf\n\t"
 	    "shrl $8,%%eax\n\t"
-	    "andl $1,%%eax\n":"=a"(rc)
+	    "andl $1,%%eax\n"
+	    :"=a"(rc), "+m" (*regs)
 	    :    "a"(regs)
 	    :    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #endif

[PATCH 86/91] Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)

[Willy Tarreau]

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

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

commit 22d3243de86bc92d874abb7c5b185d5c47aba323 upstream.

The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets
clobbered") to work around the gcc miscompiling i8k.c to add "+m
(*regs)" caused register pressure problems and a build failure.

Changing the 'asm' statement to 'asm volatile' instead should prevent
that and works around the gcc bug as well, so we can remove the "+m".

[ Background on the gcc bug: a memory clobber fails to mark the function
  the asm resides in as non-pure (aka "__attribute__((const))"), so if
  the function does nothing else that triggers the non-pure logic, gcc
  will think that that function has no side effects at all. As a result,
  callers will be mis-compiled.

  Adding the "+m" made gcc see that it's not a pure function, and so
  does "asm volatile". The problem was never really the need to mark
  "*regs" as changed, since the memory clobber did that part - the
  problem was just a bug in the gcc "pure" function analysis  - Linus ]

Signed-off-by: Jim Bos <jim876@xs4all.nl>
Acked-by: Jakub Jelinek <jakub@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/i8k.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/drivers/char/i8k.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/i8k.c	2012-02-05 22:34:47.002916726 +0100
+++ longterm-2.6.27/drivers/char/i8k.c	2012-02-05 22:34:47.136914619 +0100
@@ -119,7 +119,7 @@
 	int eax = regs->eax;
 
 #if defined(CONFIG_X86_64)
-	asm("pushq %%rax\n\t"
+	asm volatile("pushq %%rax\n\t"
 		"movl 0(%%rax),%%edx\n\t"
 		"pushq %%rdx\n\t"
 		"movl 4(%%rax),%%ebx\n\t"
@@ -141,11 +141,11 @@
 		"lahf\n\t"
 		"shrl $8,%%eax\n\t"
 		"andl $1,%%eax\n"
-		:"=a"(rc), "+m" (*regs)
+		:"=a"(rc)
 		:    "a"(regs)
 		:    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #else
-	asm("pushl %%eax\n\t"
+	asm volatile("pushl %%eax\n\t"
 	    "movl 0(%%eax),%%edx\n\t"
 	    "push %%edx\n\t"
 	    "movl 4(%%eax),%%ebx\n\t"
@@ -167,7 +167,7 @@
 	    "lahf\n\t"
 	    "shrl $8,%%eax\n\t"
 	    "andl $1,%%eax\n"
-	    :"=a"(rc), "+m" (*regs)
+	    :"=a"(rc)
 	    :    "a"(regs)
 	    :    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #endif

[PATCH 87/91] kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0

[Willy Tarreau]

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

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

commit af0e5d565d2fffcd97d1e2d89669d627cc04e8b8 upstream.

Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0
It produces more false positives than useful warnings.

This can still be enabled using W=1
[gregkh - No it can not for 2.6.32, but we don't care]

Signed-off-by: Dave Jones <davej@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 Makefile |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Index: longterm-2.6.27/Makefile
===================================================================
--- longterm-2.6.27.orig/Makefile	2012-02-05 22:34:32.306915729 +0100
+++ longterm-2.6.27/Makefile	2012-02-05 22:34:47.271916824 +0100
@@ -530,6 +530,9 @@
 # Arch Makefiles may override this setting
 KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
 
+# This warning generated too much noise in a regular build.
+KBUILD_CFLAGS += $(call cc-option, -Wno-unused-but-set-variable)
+
 ifdef CONFIG_FRAME_POINTER
 KBUILD_CFLAGS	+= -fno-omit-frame-pointer -fno-optimize-sibling-calls
 else

[PATCH 88/91] kbuild: Fix passing -Wno-* options to gcc 4.4+

[Willy Tarreau]

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

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

commit 8417da6f2128008c431c7d130af6cd3d9079922e upstream.

Starting with 4.4, gcc will happily accept -Wno-<anything> in the
cc-option test and complain later when compiling a file that has some
other warning. This rather unexpected behavior is intentional as per
http://gcc.gnu.org/PR28322, so work around it by testing for support of
the opposite option (without the no-). Introduce a new Makefile function
cc-disable-warning that does this and update two uses of cc-option in
the toplevel Makefile.

Reported-and-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 Documentation/kbuild/makefiles.txt |   12 ++++++++++++
 Makefile                           |    4 ++--
 scripts/Kbuild.include             |    5 +++++
 3 files changed, 19 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/Documentation/kbuild/makefiles.txt
===================================================================
--- longterm-2.6.27.orig/Documentation/kbuild/makefiles.txt	2012-02-05 22:34:32.253915069 +0100
+++ longterm-2.6.27/Documentation/kbuild/makefiles.txt	2012-02-05 22:34:47.409917106 +0100
@@ -471,6 +471,18 @@
 	gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
 	Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options
 
+    cc-disable-warning
+	cc-disable-warning checks if gcc supports a given warning and returns
+	the commandline switch to disable it. This special function is needed,
+	because gcc 4.4 and later accept any unknown -Wno-* option and only
+	warn about it if there is another warning in the source file.
+
+	Example:
+		KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+
+	In the above example, -Wno-unused-but-set-variable will be added to
+	KBUILD_CFLAGS only if gcc really accepts it.
+
     cc-version
 	cc-version returns a numerical version of the $(CC) compiler version.
 	The format is <major><minor> where both are two digits. So for example
Index: longterm-2.6.27/Makefile
===================================================================
--- longterm-2.6.27.orig/Makefile	2012-02-05 22:34:47.271916824 +0100
+++ longterm-2.6.27/Makefile	2012-02-05 22:34:47.412915249 +0100
@@ -531,7 +531,7 @@
 KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
 
 # This warning generated too much noise in a regular build.
-KBUILD_CFLAGS += $(call cc-option, -Wno-unused-but-set-variable)
+KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
 
 ifdef CONFIG_FRAME_POINTER
 KBUILD_CFLAGS	+= -fno-omit-frame-pointer -fno-optimize-sibling-calls
@@ -561,7 +561,7 @@
 KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
 
 # disable pointer signed / unsigned warnings in gcc 4.0
-KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
+KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign)
 
 # disable invalid "can't wrap" optimzations for signed / pointers
 KBUILD_CFLAGS	+= $(call cc-option,-fno-strict-overflow)
Index: longterm-2.6.27/scripts/Kbuild.include
===================================================================
--- longterm-2.6.27.orig/scripts/Kbuild.include	2012-02-05 22:34:32.256915061 +0100
+++ longterm-2.6.27/scripts/Kbuild.include	2012-02-05 22:34:47.418914568 +0100
@@ -117,6 +117,11 @@
 cc-option-align = $(subst -functions=0,,\
 	$(call cc-option,-falign-functions=0,-malign-functions=0))
 
+# cc-disable-warning
+# Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable)
+cc-disable-warning = $(call try-run,\
+	$(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -xc /dev/null -o "$$TMP",-Wno-$(strip $(1)))
+
 # cc-version
 # Usage gcc-ver := $(call cc-version)
 cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))

[PATCH 89/91] i8k: Avoid lahf in 64-bit code

[Willy Tarreau]

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

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

commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream.

i8k uses lahf to read the flag register in 64-bit code; early x86-64
CPUs, however, lack this instruction and we get an invalid opcode
exception at runtime.
Use pushf to load the flag register into the stack instead.

Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Reported-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Harry G McGavran Jr <w5pny@arrl.net>
Cc: Massimo Dal Zotto <dz@debian.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/i8k.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/drivers/char/i8k.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/i8k.c	2012-02-05 22:34:47.136914619 +0100
+++ longterm-2.6.27/drivers/char/i8k.c	2012-02-05 22:34:47.574914836 +0100
@@ -138,8 +138,8 @@
 		"movl %%edi,20(%%rax)\n\t"
 		"popq %%rdx\n\t"
 		"movl %%edx,0(%%rax)\n\t"
-		"lahf\n\t"
-		"shrl $8,%%eax\n\t"
+		"pushfq\n\t"
+		"popq %%rax\n\t"
 		"andl $1,%%eax\n"
 		:"=a"(rc)
 		:    "a"(regs)

[PATCH 90/91] block: fail SCSI passthrough ioctls on partition devices

[Willy Tarreau]

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

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

commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
  and -ENOIOCTLCMD from sd_compat_ioctl. ]

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
 ENOTTY, so we must return ENOTTY directly]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[wt: no scsi_cmd_blk_ioctl in 2.6.27, change callers instead. cciss is OK,
 ub,virtio_blk,ide-floppy,sd need fixing, cdrom&st can be ignored ]

---
 block/scsi_ioctl.c     |   45 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/scsi/sd.c      |   11 +++++++++--
 include/linux/blkdev.h |    1 +
 3 files changed, 55 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/block/scsi_ioctl.c
===================================================================
--- longterm-2.6.27.orig/block/scsi_ioctl.c	2012-02-05 22:34:32.181915026 +0100
+++ longterm-2.6.27/block/scsi_ioctl.c	2012-02-05 22:39:32.090915159 +0100
@@ -653,3 +653,43 @@
 }
 
 EXPORT_SYMBOL(scsi_cmd_ioctl);
+
+int scsi_verify_blk_ioctl(struct block_device *bd, unsigned int cmd)
+{
+	if (bd && bd == bd->bd_contains)
+		return 0;
+
+	/* Actually none of these is particularly useful on a partition,
+	 * but they are safe.
+	 */
+	switch (cmd) {
+	case SCSI_IOCTL_GET_IDLUN:
+	case SCSI_IOCTL_GET_BUS_NUMBER:
+	case SCSI_IOCTL_GET_PCI:
+	case SCSI_IOCTL_PROBE_HOST:
+	case SG_GET_VERSION_NUM:
+	case SG_SET_TIMEOUT:
+	case SG_GET_TIMEOUT:
+	case SG_GET_RESERVED_SIZE:
+	case SG_SET_RESERVED_SIZE:
+	case SG_EMULATED_HOST:
+		return 0;
+	case CDROM_GET_CAPABILITY:
+		/* Keep this until we remove the printk below.  udev sends it
+		 * and we do not want to spam dmesg about it.   CD-ROMs do
+		 * not have partitions, so we get here only for disks.
+		 */
+		return -ENOTTY;
+	default:
+		break;
+	}
+
+	/* In particular, rule out all resets and host-specific ioctls.  */
+	if (printk_ratelimit())
+		printk(KERN_WARNING
+			   "%s: sending ioctl %x to a partition!\n", current->comm, cmd);
+
+	return capable(CAP_SYS_RAWIO) ? 0 : -ENOTTY;
+}
+EXPORT_SYMBOL(scsi_verify_blk_ioctl);
+
Index: longterm-2.6.27/drivers/scsi/sd.c
===================================================================
--- longterm-2.6.27.orig/drivers/scsi/sd.c	2012-02-05 22:34:32.191915216 +0100
+++ longterm-2.6.27/drivers/scsi/sd.c	2012-02-05 22:34:47.717916292 +0100
@@ -749,6 +749,10 @@
 	SCSI_LOG_IOCTL(1, printk("sd_ioctl: disk=%s, cmd=0x%x\n",
 						disk->disk_name, cmd));
 
+	error = scsi_verify_blk_ioctl(bdev, cmd);
+	if (error < 0)
+		return error;
+
 	/*
 	 * If we are in the middle of error recovery, don't let anyone
 	 * else try and use this device.  Also, if error recovery fails, it
@@ -927,6 +931,11 @@
 	struct block_device *bdev = file->f_path.dentry->d_inode->i_bdev;
 	struct gendisk *disk = bdev->bd_disk;
 	struct scsi_device *sdev = scsi_disk(disk)->device;
+	int ret;
+
+	ret = scsi_verify_blk_ioctl(bdev, cmd);
+	if (ret < 0)
+		return -ENOIOCTLCMD;
 
 	/*
 	 * If we are in the middle of error recovery, don't let anyone
@@ -938,8 +947,6 @@
 		return -ENODEV;
 	       
 	if (sdev->host->hostt->compat_ioctl) {
-		int ret;
-
 		ret = sdev->host->hostt->compat_ioctl(sdev, cmd, (void __user *)arg);
 
 		return ret;
Index: longterm-2.6.27/include/linux/blkdev.h
===================================================================
--- longterm-2.6.27.orig/include/linux/blkdev.h	2012-02-05 22:34:32.200915634 +0100
+++ longterm-2.6.27/include/linux/blkdev.h	2012-02-05 22:34:47.724916417 +0100
@@ -669,6 +669,7 @@
 extern void blk_plug_device_unlocked(struct request_queue *);
 extern int blk_remove_plug(struct request_queue *);
 extern void blk_recount_segments(struct request_queue *, struct bio *);
+extern int scsi_verify_blk_ioctl(struct block_device *, unsigned int);
 extern int scsi_cmd_ioctl(struct file *, struct request_queue *,
 			  struct gendisk *, unsigned int, void __user *);
 extern int sg_scsi_ioctl(struct file *, struct request_queue *,
Index: longterm-2.6.27/drivers/block/ub.c
===================================================================
--- longterm-2.6.27.orig/drivers/block/ub.c	2012-02-05 22:34:32.188915006 +0100
+++ longterm-2.6.27/drivers/block/ub.c	2012-02-05 22:34:47.731916501 +0100
@@ -1731,7 +1731,11 @@
 {
 	struct gendisk *disk = inode->i_bdev->bd_disk;
 	void __user *usermem = (void __user *) arg;
+	int ret;
 
+	ret = scsi_verify_blk_ioctl(inode->i_bdev, cmd);
+	if (ret < 0)
+		return ret;
 	return scsi_cmd_ioctl(filp, disk->queue, disk, cmd, usermem);
 }
 
Index: longterm-2.6.27/drivers/block/virtio_blk.c
===================================================================
--- longterm-2.6.27.orig/drivers/block/virtio_blk.c	2012-02-05 22:34:32.185914704 +0100
+++ longterm-2.6.27/drivers/block/virtio_blk.c	2012-02-05 22:34:47.735917527 +0100
@@ -149,6 +149,12 @@
 static int virtblk_ioctl(struct inode *inode, struct file *filp,
 			 unsigned cmd, unsigned long data)
 {
+	int ret;
+
+	ret = scsi_verify_blk_ioctl(inode->i_bdev, cmd);
+	if (ret < 0)
+		return ret;
+
 	return scsi_cmd_ioctl(filp, inode->i_bdev->bd_disk->queue,
 			      inode->i_bdev->bd_disk, cmd,
 			      (void __user *)data);
Index: longterm-2.6.27/drivers/ide/ide-floppy.c
===================================================================
--- longterm-2.6.27.orig/drivers/ide/ide-floppy.c	2012-02-05 22:34:32.195915402 +0100
+++ longterm-2.6.27/drivers/ide/ide-floppy.c	2012-02-05 22:34:47.741917013 +0100
@@ -1336,9 +1336,12 @@
 	 * skip SCSI_IOCTL_SEND_COMMAND (deprecated)
 	 * and CDROM_SEND_PACKET (legacy) ioctls
 	 */
-	if (cmd != CDROM_SEND_PACKET && cmd != SCSI_IOCTL_SEND_COMMAND)
-		err = scsi_cmd_ioctl(file, bdev->bd_disk->queue,
-					bdev->bd_disk, cmd, argp);
+	if (cmd != CDROM_SEND_PACKET && cmd != SCSI_IOCTL_SEND_COMMAND) {
+		err = scsi_verify_blk_ioctl(bdev, cmd);
+		if (err == 0)
+			err = scsi_cmd_ioctl(file, bdev->bd_disk->queue,
+			                     bdev->bd_disk, cmd, argp);
+	}
 	else
 		err = -ENOTTY;
 

[PATCH 91/91] dm: do not forward ioctls from logical volumes to the underlying device

[Willy Tarreau]

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

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

commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.

Based on a patch from Alasdair G Kergon.

Cc: Alasdair G Kergon <agk@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backport to 2.6.32 - drop change to drivers/md/dm-flakey.c]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/md/dm-linear.c |   12 +++++++++++-
 drivers/md/dm-mpath.c  |    6 ++++++
 2 files changed, 17 insertions(+), 1 deletions(-)

Index: longterm-2.6.27/drivers/md/dm-linear.c
===================================================================
--- longterm-2.6.27.orig/drivers/md/dm-linear.c	2012-02-05 22:34:32.148917626 +0100
+++ longterm-2.6.27/drivers/md/dm-linear.c	2012-02-05 22:34:47.932914720 +0100
@@ -118,12 +118,20 @@
 	struct block_device *bdev = lc->dev->bdev;
 	struct file fake_file = {};
 	struct dentry fake_dentry = {};
+	int r = 0;
 
 	fake_file.f_mode = lc->dev->mode;
 	fake_file.f_path.dentry = &fake_dentry;
 	fake_dentry.d_inode = bdev->bd_inode;
 
-	return blkdev_driver_ioctl(bdev->bd_inode, &fake_file, bdev->bd_disk, cmd, arg);
+	/*
+	 * Only pass ioctls through if the device sizes match exactly.
+	 */
+	if (lc->start ||
+	    ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT)
+		r = scsi_verify_blk_ioctl(NULL, cmd);
+
+	return r ? : blkdev_driver_ioctl(bdev->bd_inode, &fake_file, bdev->bd_disk, cmd, arg);
 }
 
 static int linear_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
Index: longterm-2.6.27/drivers/md/dm-mpath.c
===================================================================
--- longterm-2.6.27.orig/drivers/md/dm-mpath.c	2012-02-05 22:34:32.145914857 +0100
+++ longterm-2.6.27/drivers/md/dm-mpath.c	2012-02-05 22:34:47.937916536 +0100
@@ -1421,6 +1421,12 @@
 
 	spin_unlock_irqrestore(&m->lock, flags);
 
+	/*
+	 * Only pass ioctls through if the device sizes match exactly.
+	 */
+	if (!r && ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT)
+		r = scsi_verify_blk_ioctl(NULL, cmd);
+
 	return r ? : blkdev_driver_ioctl(bdev->bd_inode, &fake_file,
 					 bdev->bd_disk, cmd, arg);
 }

Re: [PATCH 90/91] block: fail SCSI passthrough ioctls on partition devices

[Paolo Bonzini]

On 02/05/2012 11:11 PM, Willy Tarreau wrote:
> Signed-off-by: Ben Hutchings<ben@decadent.org.uk>
> Signed-off-by: Greg Kroah-Hartman<gregkh@linuxfoundation.org>
> [wt: no scsi_cmd_blk_ioctl in 2.6.27, change callers instead. cciss is OK,
>   ub,virtio_blk,ide-floppy,sd need fixing, cdrom&st can be ignored ]

NACK, you aren't fixing virtio-blk to call scsi_verify_blk_ioctl, are you?

You need to backport the patch that introduced scsi_cmd_blk_ioctl, 
which, in fact was in the same patch series as this one.

Paolo

Re: [PATCH 90/91] block: fail SCSI passthrough ioctls on partition devices

[Willy Tarreau]

Hi Paolo,

On Sun, Feb 05, 2012 at 11:44:57PM +0100, Paolo Bonzini wrote:
> On 02/05/2012 11:11 PM, Willy Tarreau wrote:
> >Signed-off-by: Ben Hutchings<ben@decadent.org.uk>
> >Signed-off-by: Greg Kroah-Hartman<gregkh@linuxfoundation.org>
> >[wt: no scsi_cmd_blk_ioctl in 2.6.27, change callers instead. cciss is OK,
> >  ub,virtio_blk,ide-floppy,sd need fixing, cdrom&st can be ignored ]
> 
> NACK, you aren't fixing virtio-blk to call scsi_verify_blk_ioctl, are you?
> 
> You need to backport the patch that introduced scsi_cmd_blk_ioctl, 
> which, in fact was in the same patch series as this one.

Thanks for this report, I missed this patch. I thought the reason for the lack
of scsi_cmd_blk_ioctl() it was one of the differences between 2.6.27 and 2.6.32,
so I have adapted the callers I identified to perform the same test as what's
in scsi_cmd_blk_ioctl(). I *think* I did it correctly, but it would be safer
to apply the original patch, of course. Now I see the patch (618 in my queue).
 I'll merge it and it will simplify the backport.

Thank you,
Willy

Re: [PATCH 32/91] libsas: remove expander from dev list on error

[Luben Tuikov]

Isn't this my patch? Are you submitting it as your own?

        Luben


On Feb 5, 2012, at 14:10, Willy Tarreau <w@1wt.eu> wrote:

> 2.6.27-longterm review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.
> 
> If expander discovery fails (sas_discover_expander()), remove the
> expander from the port device list (sas_ex_discover_expander()),
> before freeing it. Else the list is corrupted and, e.g., when we
> attempt to send SMP commands to other devices, the kernel oopses.
> 
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> Reviewed-by: Jack Wang <jack_wang@usish.com>
> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> ---
> drivers/scsi/libsas/sas_expander.c |    3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
> 
> Index: longterm-2.6.27/drivers/scsi/libsas/sas_expander.c
> ===================================================================
> --- longterm-2.6.27.orig/drivers/scsi/libsas/sas_expander.c    2012-02-05 22:34:34.059914940 +0100
> +++ longterm-2.6.27/drivers/scsi/libsas/sas_expander.c    2012-02-05 22:34:39.404915902 +0100
> @@ -839,6 +839,9 @@
> 
>    res = sas_discover_expander(child);
>    if (res) {
> +        spin_lock_irq(&parent->port->dev_list_lock);
> +        list_del(&child->dev_list_node);
> +        spin_unlock_irq(&parent->port->dev_list_lock);
>        kfree(child);
>        return NULL;
>    }
> 
> 

Re: [PATCH 32/91] libsas: remove expander from dev list on error

[Wanlong Gao]

On 02/06/2012 07:48 AM, Luben Tuikov wrote:

> Isn't this my patch? Are you submitting it as your own?


No, he just wanna backport to the stable.

> 
>         Luben
> 
> 
> On Feb 5, 2012, at 14:10, Willy Tarreau <w@1wt.eu> wrote:
> 
>> 2.6.27-longterm review patch.  If anyone has any objections, please let us know.
>>
>> ------------------
>>
>> commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.
>>
>> If expander discovery fails (sas_discover_expander()), remove the
>> expander from the port device list (sas_ex_discover_expander()),
>> before freeing it. Else the list is corrupted and, e.g., when we
>> attempt to send SMP commands to other devices, the kernel oopses.
>>
>> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
>> Reviewed-by: Jack Wang <jack_wang@usish.com>
>> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>> ---
>> drivers/scsi/libsas/sas_expander.c |    3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> Index: longterm-2.6.27/drivers/scsi/libsas/sas_expander.c
>> ===================================================================
>> --- longterm-2.6.27.orig/drivers/scsi/libsas/sas_expander.c    2012-02-05 22:34:34.059914940 +0100
>> +++ longterm-2.6.27/drivers/scsi/libsas/sas_expander.c    2012-02-05 22:34:39.404915902 +0100
>> @@ -839,6 +839,9 @@
>>
>>    res = sas_discover_expander(child);
>>    if (res) {
>> +        spin_lock_irq(&parent->port->dev_list_lock);
>> +        list_del(&child->dev_list_node);
>> +        spin_unlock_irq(&parent->port->dev_list_lock);
>>        kfree(child);
>>        return NULL;
>>    }
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH 32/91] libsas: remove expander from dev list on error

[Luben Tuikov]

Where is the "From:" tag that would appear in "git log"?

        Luben


On Feb 5, 2012, at 16:52, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:

> On 02/06/2012 07:48 AM, Luben Tuikov wrote:
> 
>> Isn't this my patch? Are you submitting it as your own?
> 
> 
> No, he just wanna backport to the stable.
> 
>> 
>>        Luben
>> 
>> 
>> On Feb 5, 2012, at 14:10, Willy Tarreau <w@1wt.eu> wrote:
>> 
>>> 2.6.27-longterm review patch.  If anyone has any objections, please let us know.
>>> 
>>> ------------------
>>> 
>>> commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.
>>> 
>>> If expander discovery fails (sas_discover_expander()), remove the
>>> expander from the port device list (sas_ex_discover_expander()),
>>> before freeing it. Else the list is corrupted and, e.g., when we
>>> attempt to send SMP commands to other devices, the kernel oopses.
>>> 
>>> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
>>> Reviewed-by: Jack Wang <jack_wang@usish.com>
>>> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>> ---
>>> drivers/scsi/libsas/sas_expander.c |    3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>> 
>>> Index: longterm-2.6.27/drivers/scsi/libsas/sas_expander.c
>>> ===================================================================
>>> --- longterm-2.6.27.orig/drivers/scsi/libsas/sas_expander.c    2012-02-05 22:34:34.059914940 +0100
>>> +++ longterm-2.6.27/drivers/scsi/libsas/sas_expander.c    2012-02-05 22:34:39.404915902 +0100
>>> @@ -839,6 +839,9 @@
>>> 
>>>   res = sas_discover_expander(child);
>>>   if (res) {
>>> +        spin_lock_irq(&parent->port->dev_list_lock);
>>> +        list_del(&child->dev_list_node);
>>> +        spin_unlock_irq(&parent->port->dev_list_lock);
>>>       kfree(child);
>>>       return NULL;
>>>   }
>>> 
>>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>> 
> 
> 

Re: [PATCH 32/91] libsas: remove expander from dev list on error

[Willy Tarreau]

On Sun, Feb 05, 2012 at 05:14:26PM -0800, Luben Tuikov wrote:
> Where is the "From:" tag that would appear in "git log"?

Here's the complete patch scheduled for merging :

	From da229078845ada4d7b0b49a020c8eaf49420cec9 Mon Sep 17 00:00:00 2001
	From: Luben Tuikov <ltuikov@yahoo.com>
	Date: Tue, 26 Jul 2011 23:10:48 -0700
	Subject: libsas: remove expander from dev list on error

	commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.

	If expander discovery fails (sas_discover_expander()), remove the
	expander from the port device list (sas_ex_discover_expander()),
	before freeing it. Else the list is corrupted and, e.g., when we
	attempt to send SMP commands to other devices, the kernel oopses.

	Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
	Reviewed-by: Jack Wang <jack_wang@usish.com>
	Signed-off-by: James Bottomley <JBottomley@Parallels.com>
	Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
	---
	 drivers/scsi/libsas/sas_expander.c |    3 +++
	 1 files changed, 3 insertions(+), 0 deletions(-)

	Index: longterm-2.6.27/drivers/scsi/libsas/sas_expander.c
	===================================================================
	--- longterm-2.6.27.orig/drivers/scsi/libsas/sas_expander.c     2012-02-05 22:34:34.059914940 +0100
	+++ longterm-2.6.27/drivers/scsi/libsas/sas_expander.c  2012-02-05 22:34:39.404915902 +0100
	@@ -839,6 +839,9 @@
	 
		res = sas_discover_expander(child);
		if (res) {
	+               spin_lock_irq(&parent->port->dev_list_lock);
	+               list_del(&child->dev_list_node);
	+               spin_unlock_irq(&parent->port->dev_list_lock);
			kfree(child);
			return NULL;
		}

You're clearly the one who's credited for the patch, both by the From: and
Signed-off-by tags. I am always very careful about credit attributions, and
that's even what scares me when I have to force to apply patches by hand.
I think you were surprized not to see you in the From just because of the
way the review scripts assembles the patches in mails.  I'm using quilt this
way to build the mails :

   quilt mail \
     -m "$(sed -e "s/XX\.YY/$SUBLEVEL.$REV/g" .quilt/header;git diff --stat)" \
     --from "$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>" \
     --subject "$VERSION.$PATCHLEVEL.$SUBLEVEL.$REV-longterm review" \
     --prefix "PATCH" \
     --to "linux-kernel@vger.kernel.org, stable@vger.kernel.org" \
     --mbox mbox

I don't think there's anything wrong with this. I you have suggestions to
improve the output readability, feel free to suggest so.

Best regards,
Willy

Re: [PATCH 55/91] Make scsi_free_queue() kill pending SCSI commands

[Bart Van Assche]

On Sun, Feb 5, 2012 at 11:10 PM, Willy Tarreau <w@1wt.eu> wrote:
>
> 2.6.27-longterm review patch.  If anyone has any objections, please let us know.
>
> ------------------
>
> commit 3308511c93e6ad0d3c58984ecd6e5e57f96b12c8 upstream.
>
> Make sure that SCSI device removal via scsi_remove_host() does finish
> all pending SCSI commands. Currently that's not the case and hence
> removal of a SCSI host during I/O can cause a deadlock. See also
> "blkdev_issue_discard() hangs forever if underlying storage device is
> removed" (http://bugzilla.kernel.org/show_bug.cgi?id=40472). See also
> http://lkml.org/lkml/2011/8/27/6.

If you backport that commit, you should backport commit
745718132c3c7cac98a622b610e239dcd5217f71 too. See e.g.
http://lkml.org/lkml/2011/11/8/22.

Bart.

Re: [PATCH 55/91] Make scsi_free_queue() kill pending SCSI commands

[Willy Tarreau]

On Mon, Feb 06, 2012 at 08:28:48AM +0100, Bart Van Assche wrote:
> On Sun, Feb 5, 2012 at 11:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > 2.6.27-longterm review patch.  If anyone has any objections, please let us know.
> >
> > ------------------
> >
> > commit 3308511c93e6ad0d3c58984ecd6e5e57f96b12c8 upstream.
> >
> > Make sure that SCSI device removal via scsi_remove_host() does finish
> > all pending SCSI commands. Currently that's not the case and hence
> > removal of a SCSI host during I/O can cause a deadlock. See also
> > "blkdev_issue_discard() hangs forever if underlying storage device is
> > removed" (http://bugzilla.kernel.org/show_bug.cgi?id=40472). See also
> > http://lkml.org/lkml/2011/8/27/6.
> 
> If you backport that commit, you should backport commit
> 745718132c3c7cac98a622b610e239dcd5217f71 too. See e.g.
> http://lkml.org/lkml/2011/11/8/22.

Thank you Bart, I thought it was just cosmetic. Queued now.

Cheers,
Willy

Re: [PATCH 41/91] xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead.

[Konrad Rzeszutek Wilk]

On Sun, Feb 05, 2012 at 11:10:30PM +0100, Willy Tarreau wrote:
> 2.6.27-longterm review patch.  If anyone has any objections, please let us know.

Please drop this patch. The 2.6.27 did not have dom0 functionality so it
will never hit this error path.

> 
> ------------------
> 
> commit ed467e69f16e6b480e2face7bc5963834d025f91 upstream.
> 
> We have hit a couple of customer bugs where they would like to
> use those parameters to run an UP kernel - but both of those
> options turn of important sources of interrupt information so
> we end up not being able to boot. The correct way is to
> pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and
> the kernel will patch itself to be a UP kernel.
> 
> Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308
> 
> Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> ---
>  arch/x86/xen/smp.c |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> Index: longterm-2.6.27/arch/x86/xen/smp.c
> ===================================================================
> --- longterm-2.6.27.orig/arch/x86/xen/smp.c	2012-02-05 22:34:33.783914838 +0100
> +++ longterm-2.6.27/arch/x86/xen/smp.c	2012-02-05 22:34:40.668915455 +0100
> @@ -33,6 +33,7 @@
>  #include <xen/page.h>
>  #include <xen/events.h>
>  
> +#include <xen/hvc-console.h>
>  #include "xen-ops.h"
>  #include "mmu.h"
>  
> @@ -182,6 +183,15 @@
>  {
>  	unsigned cpu;
>  
> +	if (skip_ioapic_setup) {
> +		char *m = (max_cpus == 0) ?
> +			"The nosmp parameter is incompatible with Xen; " \
> +			"use Xen dom0_max_vcpus=1 parameter" :
> +			"The noapic parameter is incompatible with Xen";
> +
> +		xen_raw_printk(m);
> +		panic(m);
> +	}
>  	xen_init_lock_cpu(0);
>  
>  	smp_store_cpu_info(0);
> 

Re: [PATCH 41/91] xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead.

[Willy Tarreau]

On Mon, Feb 06, 2012 at 11:50:40AM -0500, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 05, 2012 at 11:10:30PM +0100, Willy Tarreau wrote:
> > 2.6.27-longterm review patch.  If anyone has any objections, please let us know.
> 
> Please drop this patch. The 2.6.27 did not have dom0 functionality so it
> will never hit this error path.

Fine, thank you Konrad.

Best regards,
Willy

Re: [PATCH 02/91] slub: fix panic with DISCONTIGMEM

[David Rientjes]

On Sun, 5 Feb 2012, Willy Tarreau wrote:

> commit 4a5fa3590f09999f6db41bc386bce40848fa9f63 upstream.
> 
> Slub makes assumptions about page_to_nid() which are violated by
> DISCONTIGMEM and !NUMA.  This violation results in a panic because
> page_to_nid() can be non-zero for pages in the discontiguous ranges and
> this leads to a null return by get_node().  The assertion by the
> maintainer is that DISCONTIGMEM should only be allowed when NUMA is also
> defined.  However, at least six architectures: alpha, ia64, m32r, m68k,
> mips, parisc violate this.  The panic is a regression against slab, so
> just mark slub broken in the problem configuration to prevent users
> reporting these panics.
> 
> Acked-by: David Rientjes <rientjes@google.com>
> Acked-by: Pekka Enberg <penberg@kernel.org>
> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The problem that this patch initially addressed is fixed by the next patch 
in your series, "set memory ranges in N_NORMAL_MEMORY when onlined", so I 
don't think this one should be merged.

Re: [PATCH 02/91] slub: fix panic with DISCONTIGMEM

[Willy Tarreau]

On Mon, Feb 06, 2012 at 01:58:56PM -0800, David Rientjes wrote:
> On Sun, 5 Feb 2012, Willy Tarreau wrote:
> 
> > commit 4a5fa3590f09999f6db41bc386bce40848fa9f63 upstream.
> > 
> > Slub makes assumptions about page_to_nid() which are violated by
> > DISCONTIGMEM and !NUMA.  This violation results in a panic because
> > page_to_nid() can be non-zero for pages in the discontiguous ranges and
> > this leads to a null return by get_node().  The assertion by the
> > maintainer is that DISCONTIGMEM should only be allowed when NUMA is also
> > defined.  However, at least six architectures: alpha, ia64, m32r, m68k,
> > mips, parisc violate this.  The panic is a regression against slab, so
> > just mark slub broken in the problem configuration to prevent users
> > reporting these panics.
> > 
> > Acked-by: David Rientjes <rientjes@google.com>
> > Acked-by: Pekka Enberg <penberg@kernel.org>
> > Signed-off-by: James Bottomley <James.Bottomley@suse.de>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> The problem that this patch initially addressed is fixed by the next patch 
> in your series, "set memory ranges in N_NORMAL_MEMORY when onlined", so I 
> don't think this one should be merged.

Perfect, I'm dropping it then.

Thank you David,
Willy

Re: [PATCH 90/91] block: fail SCSI passthrough ioctls on partition devices

[Paolo Bonzini]

On 02/05/2012 11:53 PM, Willy Tarreau wrote:
> Thanks for this report, I missed this patch. I thought the reason for the lack
> of scsi_cmd_blk_ioctl() it was one of the differences between 2.6.27 and 2.6.32,
> so I have adapted the callers I identified to perform the same test as what's
> in scsi_cmd_blk_ioctl().

There were other callers in patch 1/3, most notably virtio-blk, that are 
not in your patch.

  I*think*  I did it correctly, but it would be safer
> to apply the original patch, of course. Now I see the patch (618 in my queue).
> I'll merge it and it will simplify the backport.

Sounds like a plan, thanks!

Paolo

Re: [PATCH 90/91] block: fail SCSI passthrough ioctls on partition devices

[Willy Tarreau]

Hi Paolo,

On Tue, Feb 07, 2012 at 11:03:03AM +0100, Paolo Bonzini wrote:
> On 02/05/2012 11:53 PM, Willy Tarreau wrote:
> >Thanks for this report, I missed this patch. I thought the reason for the 
> >lack
> >of scsi_cmd_blk_ioctl() it was one of the differences between 2.6.27 and 
> >2.6.32,
> >so I have adapted the callers I identified to perform the same test as 
> >what's
> >in scsi_cmd_blk_ioctl().
> 
> There were other callers in patch 1/3, most notably virtio-blk, that are 
> not in your patch.

Yes it was, just like ub, sd and ide-floppy. In fact backport this whole patch
was the trickiest task as I had to review each caller one after the other, and
I'm quite confident the result is fine. But I prefer to redo it from scratch
with your original patch that I missed, as it will wipe any doubts and make
further maintenance easier.

Thanks,
Willy