Skip to contentSkip to conversation

2.6.32.46-longterm review

PATCH In review Greg KH 4 participants 25 messages Aug 26, 2011 – Aug 28, 2011

Subsystems (21)
lore
Share & tools
lore

Greg KH

author
#0 lore raw

cover 2.6.32.46-longterm review

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

Responses should be made by Monday, August 29, 2011, 12:00:00 UTC. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.46-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

 Makefile                           |    2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c |    1 -
 arch/x86/vdso/vdso32/sysenter.S    |    2 +-
 drivers/gpu/drm/ttm/ttm_bo.c       |    4 ++-
 drivers/hwmon/ibmaem.c             |   15 ++++++---
 drivers/net/igb/e1000_82575.c      |    1 +
 drivers/usb/class/usbtmc.c         |    2 +-
 drivers/usb/host/pci-quirks.c      |    2 +-
 drivers/usb/serial/qcserial.c      |    1 +
 drivers/usb/storage/unusual_devs.h |   10 ++++++
 fs/befs/linuxvfs.c                 |   23 +++++++++------
 fs/fuse/dev.c                      |    4 ++
 fs/partitions/efi.c                |    9 ++++++
 kernel/futex.c                     |   54 ++++++++++++++++++++++++++++--------
 mm/vmalloc.c                       |    7 ++--
 net/atm/br2684.c                   |    2 -
 sound/pci/ac97/ac97_patch.c        |    1 +
 sound/usb/caiaq/audio.c            |   37 ++++++++++++++++++++----
 sound/usb/caiaq/device.h           |    1 +
 tools/perf/util/config.c           |    7 ----
 20 files changed, 135 insertions(+), 50 deletions(-)
author
#1 lore raw

PATCH 1/19 USB: xhci: fix OS want to own HC

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

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

From: JiSheng Zhang <[email protected]>

commit 6768458b17f9bf48a4c3a34e49b20344091b5f7e upstream.

Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC.

This patch should be backported to kernels as far back as 2.6.31.

---
 drivers/usb/host/pci-quirks.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/pci-quirks.c +1 -1
@@ -444,7 +444,7 @@ static void __devinit quirk_usb_handoff_
 
 	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
 	if (val & XHCI_HC_BIOS_OWNED) {
-		writel(val & XHCI_HC_OS_OWNED, base + ext_cap_offset);
+		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
 
 		/* Wait for 5 seconds with 10 microsecond polling interval */
 		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
author
#2 lore raw

PATCH 2/19 USB: assign instead of equal in usbtmc.c

In reply to Greg KH

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

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

From: Maxim Nikulin <[email protected]>

commit 4f1a7a3e78037721496283ea3e87cfefc64d99c7 upstream.

Assign operator instead of equality test in the usbtmc_ioctl_abort_bulk_in() function.

---
 drivers/usb/class/usbtmc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/class/usbtmc.c +1 -1
@@ -267,7 +267,7 @@ usbtmc_abort_bulk_in_status:
 				dev_err(dev, "usb_bulk_msg returned %d\n", rv);
 				goto exit;
 			}
-		} while ((actual = max_size) &&
+		} while ((actual == max_size) &&
 			 (n < USBTMC_MAX_READS_TO_CLEAR_BULK_IN));
 
 	if (actual == max_size) {
author
#3 lore raw

PATCH 3/19 USB: usb-storage: unusual_devs entry for ARM V2M motherboard.

In reply to Greg KH

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

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

From: Nick Bowler <[email protected]>

commit a871e4f5519d8c52430052e1d340dd5710eb5ad6 upstream.

Connecting the V2M to a Linux host results in a constant stream of errors spammed to the console, all of the form

sd 1:0:0:0: ioctl_internal_command return code = 8070000

     : Sense Key : 0x4 [current]
     : ASC=0x0 ASCQ=0x0

The errors appear to be otherwise harmless. Add an unusual_devs entry which eliminates all of the error messages.

---
 drivers/usb/storage/unusual_devs.h |   10 ++++++++++
 1 file changed, 10 insertions(+)
drivers/usb/storage/unusual_devs.h +10 -0
@@ -1977,6 +1977,16 @@ UNUSUAL_DEV(  0x4146, 0xba01, 0x0100, 0x
 		"Micro Mini 1GB",
 		US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_NOT_LOCKABLE ),
 
+/*
+ * Nick Bowler <[email protected]>
+ * SCSI stack spams (otherwise harmless) error messages.
+ */
+UNUSUAL_DEV(  0xc251, 0x4003, 0x0100, 0x0100,
+		"Keil Software, Inc.",
+		"V2M MotherBoard",
+		US_SC_DEVICE, US_PR_DEVICE, NULL,
+		US_FL_NOT_LOCKABLE),
+
 /* Reported by Andrew Simmons <[email protected]> */
 UNUSUAL_DEV(  0xed06, 0x4500, 0x0001, 0x0001,
 		"DataStor",
author
#4 lore raw

PATCH 4/19 USB: Serial: Added device ID for Qualcomm Modem in Sagemcom's HiLo3G

In reply to Greg KH

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

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

From: Vijay Chavan <[email protected]>

commit e468561739fffb972d486b98f66c723936335136 upstream.

A new device ID pair is added for Qualcomm Modem present in Sagemcom's HiLo3G module.

---
 drivers/usb/serial/qcserial.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/serial/qcserial.c +1 -0
@@ -43,6 +43,7 @@ static struct usb_device_id id_table[] =
 	{USB_DEVICE(0x05c6, 0x9203)},	/* Generic Gobi Modem device */
 	{USB_DEVICE(0x05c6, 0x9222)},	/* Generic Gobi Modem device */
 	{USB_DEVICE(0x05c6, 0x9008)},	/* Generic Gobi QDL device */
+	{USB_DEVICE(0x05c6, 0x9009)},	/* Generic Gobi Modem device */
 	{USB_DEVICE(0x05c6, 0x9201)},	/* Generic Gobi QDL device */
 	{USB_DEVICE(0x05c6, 0x9221)},	/* Generic Gobi QDL device */
 	{USB_DEVICE(0x05c6, 0x9231)},	/* Generic Gobi QDL device */
author
#5 lore raw

PATCH 5/19 atm: br2864: sent packets truncated in VC routed mode

In reply to Greg KH

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

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

From: Chas Williams <[email protected]>

commit a08af810cdc29d2ca930e8a869d3d01744c392d8 upstream.

---
 net/atm/br2684.c |    2 --
 1 file changed, 2 deletions(-)
net/atm/br2684.c +0 -2
@@ -208,8 +208,6 @@ static int br2684_xmit_vcc(struct sk_buf
 		if (brdev->payload == p_bridged) {
 			skb_push(skb, 2);
 			memset(skb->data, 0, 2);
-		} else { /* p_routed */
-			skb_pull(skb, ETH_HLEN);
 		}
 	}
 	skb_debug(skb);
author
#6 lore raw

PATCH 6/19 hwmon: (ibmaem) add missing kfree

In reply to Greg KH

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

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

From: Julia Lawall <[email protected]>

commit 66a89b2164e2d30661edbd1953eacf0594d8203a upstream.

rs_resp is dynamically allocated in aem_read_sensor(), so it should be freed before exiting in every case. This collects the kfree and the return at the end of the function.

---
 drivers/hwmon/ibmaem.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/hwmon/ibmaem.c +10 -5
@@ -429,13 +429,15 @@ static int aem_read_sensor(struct aem_da
 	aem_send_message(ipmi);
 
 	res = wait_for_completion_timeout(&ipmi->read_complete, IPMI_TIMEOUT);
-	if (!res)
-		return -ETIMEDOUT;
+	if (!res) {
+		res = -ETIMEDOUT;
+		goto out;
+	}
 
 	if (ipmi->rx_result || ipmi->rx_msg_len != rs_size ||
 	    memcmp(&rs_resp->id, &system_x_id, sizeof(system_x_id))) {
-		kfree(rs_resp);
-		return -ENOENT;
+		res = -ENOENT;
+		goto out;
 	}
 
 	switch (size) {
@@ -460,8 +462,11 @@ static int aem_read_sensor(struct aem_da
 		break;
 	}
 	}
+	res = 0;
 
-	return 0;
+out:
+	kfree(rs_resp);
+	return res;
 }
 
 /* Update AEM energy registers */
author
#7 lore raw

PATCH 7/19 ALSA: snd-usb-caiaq: Correct offset fields of outbound iso_frame_desc

In reply to Greg KH

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

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

From: Daniel Mack <[email protected]>

commit 15439bde3af7ff88459ea2b5520b77312e958df2 upstream.

This fixes faulty outbount packets in case the inbound packets received from the hardware are fragmented and contain bogus input iso frames. The bug has been there for ages, but for some strange reasons, it was only triggered by newer machines in 64bit mode.

---
 sound/usb/caiaq/audio.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
sound/usb/caiaq/audio.c +4 -2
@@ -468,6 +468,7 @@ static void read_completed(struct urb *u
 	struct snd_usb_caiaqdev *dev;
 	struct urb *out;
 	int frame, len, send_it = 0, outframe = 0;
+	size_t offset = 0;
 
 	if (urb->status || !info)
 		return;
@@ -488,7 +489,8 @@ static void read_completed(struct urb *u
 		len = urb->iso_frame_desc[outframe].actual_length;
 		out->iso_frame_desc[outframe].length = len;
 		out->iso_frame_desc[outframe].actual_length = 0;
-		out->iso_frame_desc[outframe].offset = BYTES_PER_FRAME * frame;
+		out->iso_frame_desc[outframe].offset = offset;
+		offset += len;
 
 		if (len > 0) {
 			spin_lock(&dev->spinlock);
@@ -504,7 +506,7 @@ static void read_completed(struct urb *u
 	}
 
 	if (send_it) {
-		out->number_of_packets = FRAMES_PER_URB;
+		out->number_of_packets = outframe;
 		out->transfer_flags = URB_ISO_ASAP;
 		usb_submit_urb(out, GFP_ATOMIC);
 	}
author
#8 lore raw

PATCH 8/19 mm: fix wrong vmap address calculations with odd NR_CPUS values

In reply to Greg KH

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

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

From: Clemens Ladisch <[email protected]>

commit f982f91516fa4cfd9d20518833cd04ad714585be upstream.

Commit db64fe02258f ("mm: rewrite vmap layer") introduced code that does address calculations under the assumption that VMAP_BLOCK_SIZE is a power of two. However, this might not be true if CONFIG_NR_CPUS is not set to a power of two.

Wrong vmap_block index/offset values could lead to memory corruption. However, this has never been observed in practice (or never been diagnosed correctly); what caught this was the BUG_ON in vb_alloc() that checks for inconsistent vmap_block indices.

To fix this, ensure that VMAP_BLOCK_SIZE always is a power of two.

---
 mm/vmalloc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
mm/vmalloc.c +4 -3
@@ -671,9 +671,10 @@ static void free_unmap_vmap_area_addr(un
 #define VMAP_BBMAP_BITS_MIN	(VMAP_MAX_ALLOC*2)
 #define VMAP_MIN(x, y)		((x) < (y) ? (x) : (y)) /* can't use min() */
 #define VMAP_MAX(x, y)		((x) > (y) ? (x) : (y)) /* can't use max() */
-#define VMAP_BBMAP_BITS		VMAP_MIN(VMAP_BBMAP_BITS_MAX,		\
-					VMAP_MAX(VMAP_BBMAP_BITS_MIN,	\
-						VMALLOC_PAGES / NR_CPUS / 16))
+#define VMAP_BBMAP_BITS		\
+		VMAP_MIN(VMAP_BBMAP_BITS_MAX,	\
+		VMAP_MAX(VMAP_BBMAP_BITS_MIN,	\
+			VMALLOC_PAGES / roundup_pow_of_two(NR_CPUS) / 16))
 
 #define VMAP_BLOCK_SIZE		(VMAP_BBMAP_BITS * PAGE_SIZE)
 
author
#9 lore raw

PATCH 9/19 perf tools: do not look at ./config for configuration

In reply to Greg KH

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

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

From: Jonathan Nieder <[email protected]>

commit aba8d056078e47350d85b06a9cabd5afcc4b72ea upstream.

In addition to /etc/perfconfig and $HOME/.perfconfig, perf looks for configuration in the file ./config, imitating git which looks at $GIT_DIR/config. If ./config is not a perf configuration file, it fails, or worse, treats it as a configuration file and changes behavior in some unexpected way.

"config" is not an unusual name for a file to be lying around and perf does not have a private directory dedicated for its own use, so let's just stop looking for configuration in the cwd. Callers needing context-sensitive configuration can use the PERF_CONFIG environment variable.

---
 tools/perf/util/config.c |    7 -------
 1 file changed, 7 deletions(-)
tools/perf/util/config.c +0 -7
@@ -416,7 +416,6 @@ int perf_config_global(void)
 int perf_config(config_fn_t fn, void *data)
 {
 	int ret = 0, found = 0;
-	char *repo_config = NULL;
 	const char *home = NULL;
 
 	/* Setting $PERF_CONFIG makes perf read _only_ the given config file. */
@@ -438,12 +437,6 @@ int perf_config(config_fn_t fn, void *da
 		free(user_config);
 	}
 
-	repo_config = perf_pathdup("config");
-	if (!access(repo_config, R_OK)) {
-		ret += perf_config_from_file(fn, repo_config, data);
-		found += 1;
-	}
-	free(repo_config);
 	if (found == 0)
 		return -1;
 	return ret;
author
#10 lore raw

PATCH 10/19 fs/partitions/efi.c: corrupted GUID partition tables can cause kernel oops

In reply to Greg KH

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

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

From: Timo Warns <[email protected]>

commit 3eb8e74ec72736b9b9d728bad30484ec89c91dde upstream.

The kernel automatically evaluates partition tables of storage devices. The code for evaluating GUID partitions (in fs/partitions/efi.c) contains a bug that causes a kernel oops on certain corrupted GUID partition tables.

This bug has security impacts, because it allows, for example, to prepare a storage device that crashes a kernel subsystem upon connecting the device (e.g., a "USB Stick of (Partial) Death").

	crc = efi_crc32((const unsigned char *) (*gpt), le32_to_cpu((*gpt)->header_size));

computes a CRC32 checksum over gpt covering (*gpt)->header_size bytes. There is no validation of (*gpt)->header_size before the efi_crc32 call.

A corrupted partition table may have large values for (*gpt)->header_size.
In this case, the CRC32 computation access memory beyond the memory
allocated for gpt, which may cause a kernel heap overflow.

Validate value of GUID partition table header size.

[[email protected]: fix layout and indenting]
Cc Matt Domsch <[email protected]>
Cc Eugene Teo <[email protected]>
Cc Dave Jones <[email protected]>
[dannf: backported to Debian's 2.6.32]
---
 fs/partitions/efi.c |    9 +++++++++
 1 file changed, 9 insertions(+)
fs/partitions/efi.c +9 -0
@@ -311,6 +311,15 @@ is_gpt_valid(struct block_device *bdev,
 		goto fail;
 	}
 
+	/* Check the GUID Partition Table header size */
+	if (le32_to_cpu((*gpt)->header_size) >
+			bdev_logical_block_size(bdev)) {
+		pr_debug("GUID Partition Table Header size is wrong: %u > %u\n",
+			le32_to_cpu((*gpt)->header_size),
+			bdev_logical_block_size(bdev));
+		goto fail;
+	}
+
 	/* Check the GUID Partition Table CRC */
 	origcrc = le32_to_cpu((*gpt)->header_crc32);
 	(*gpt)->header_crc32 = 0;
author
#11 lore raw

PATCH 11/19 befs: Validate length of long symbolic links.

In reply to Greg KH

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

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

From: Timo Warns <[email protected]>

commit 338d0f0a6fbc82407864606f5b64b75aeb3c70f2 upstream.

---
 fs/befs/linuxvfs.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
fs/befs/linuxvfs.c +14 -9
@@ -469,17 +469,22 @@ befs_follow_link(struct dentry *dentry,
 		befs_data_stream *data = &befs_ino->i_data.ds;
 		befs_off_t len = data->size;
 
-		befs_debug(sb, "Follow long symlink");
-
-		link = kmalloc(len, GFP_NOFS);
-		if (!link) {
-			link = ERR_PTR(-ENOMEM);
-		} else if (befs_read_lsymlink(sb, data, link, len) != len) {
-			kfree(link);
-			befs_error(sb, "Failed to read entire long symlink");
+		if (len == 0) {
+			befs_error(sb, "Long symlink with illegal length");
 			link = ERR_PTR(-EIO);
 		} else {
-			link[len - 1] = '\0';
+			befs_debug(sb, "Follow long symlink");
+
+			link = kmalloc(len, GFP_NOFS);
+			if (!link) {
+				link = ERR_PTR(-ENOMEM);
+			} else if (befs_read_lsymlink(sb, data, link, len) != len) {
+				kfree(link);
+				befs_error(sb, "Failed to read entire long symlink");
+				link = ERR_PTR(-EIO);
+			} else {
+				link[len - 1] = '\0';
+			}
 		}
 	} else {
 		link = befs_ino->i_data.symlink;
author
#12 lore raw

PATCH 12/19 ALSA: snd_usb_caiaq: track submitted output urbs

In reply to Greg KH

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

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

From: Daniel Mack <[email protected]>

commit da6094ea7d3c2295473d8f5134279307255d6ebf upstream.

The snd_usb_caiaq driver currently assumes that output urbs are serviced in time and doesn't track when and whether they are given back by the USB core. That usually works fine, but due to temporary limitations of the XHCI stack, we faced that urbs were submitted more than once with this approach.

As it's no good practice to fire and forget urbs anyway, this patch introduces a proper bit mask to track which requests have been submitted and given back.

That alone however doesn't make the driver work in case the host controller is broken and doesn't give back urbs at all, and the output stream will stop once all pre-allocated output urbs are consumed. But it does prevent crashes of the controller stack in such cases.

See http://bugzilla.kernel.org/show_bug.cgi?id=40702 for more details.

---
 sound/usb/caiaq/audio.c  |   31 +++++++++++++++++++++++++++----
 sound/usb/caiaq/device.h |    1 +
 2 files changed, 28 insertions(+), 4 deletions(-)
sound/usb/caiaq/audio.c +27 -4
@@ -138,8 +138,12 @@ static void stream_stop(struct snd_usb_c
 
 	for (i = 0; i < N_URBS; i++) {
 		usb_kill_urb(dev->data_urbs_in[i]);
-		usb_kill_urb(dev->data_urbs_out[i]);
+
+		if (test_bit(i, &dev->outurb_active_mask))
+			usb_kill_urb(dev->data_urbs_out[i]);
 	}
+
+	dev->outurb_active_mask = 0;
 }
 
 static int snd_usb_caiaq_substream_open(struct snd_pcm_substream *substream)
@@ -466,8 +470,8 @@ static void read_completed(struct urb *u
 {
 	struct snd_usb_caiaq_cb_info *info = urb->context;
 	struct snd_usb_caiaqdev *dev;
-	struct urb *out;
-	int frame, len, send_it = 0, outframe = 0;
+	struct urb *out = NULL;
+	int i, frame, len, send_it = 0, outframe = 0;
 	size_t offset = 0;
 
 	if (urb->status || !info)
@@ -478,7 +482,17 @@ static void read_completed(struct urb *u
 	if (!dev->streaming)
 		return;
 
-	out = dev->data_urbs_out[info->index];
+	/* find an unused output urb that is unused */
+	for (i = 0; i < N_URBS; i++)
+		if (test_and_set_bit(i, &dev->outurb_active_mask) == 0) {
+			out = dev->data_urbs_out[i];
+			break;
+		}
+
+	if (!out) {
+		log("Unable to find an output urb to use\n");
+		goto requeue;
+	}
 
 	/* read the recently received packet and send back one which has
 	 * the same layout */
@@ -509,8 +523,12 @@ static void read_completed(struct urb *u
 		out->number_of_packets = outframe;
 		out->transfer_flags = URB_ISO_ASAP;
 		usb_submit_urb(out, GFP_ATOMIC);
+	} else {
+		struct snd_usb_caiaq_cb_info *oinfo = out->context;
+		clear_bit(oinfo->index, &dev->outurb_active_mask);
 	}
 
+requeue:
 	/* re-submit inbound urb */
 	for (frame = 0; frame < FRAMES_PER_URB; frame++) {
 		urb->iso_frame_desc[frame].offset = BYTES_PER_FRAME * frame;
@@ -532,6 +550,8 @@ static void write_completed(struct urb *
 		dev->output_running = 1;
 		wake_up(&dev->prepare_wait_queue);
 	}
+
+	clear_bit(info->index, &dev->outurb_active_mask);
 }
 
 static struct urb **alloc_urbs(struct snd_usb_caiaqdev *dev, int dir, int *ret)
@@ -682,6 +702,9 @@ int snd_usb_caiaq_audio_init(struct snd_
 	if (!dev->data_cb_info)
 		return -ENOMEM;
 
+	dev->outurb_active_mask = 0;
+	BUILD_BUG_ON(N_URBS > (sizeof(dev->outurb_active_mask) * 8));
+
 	for (i = 0; i < N_URBS; i++) {
 		dev->data_cb_info[i].dev = dev;
 		dev->data_cb_info[i].index = i;
sound/usb/caiaq/device.h +1 -0
@@ -92,6 +92,7 @@ struct snd_usb_caiaqdev {
 	int input_panic, output_panic, warned;
 	char *audio_in_buf, *audio_out_buf;
 	unsigned int samplerates, bpp;
+	unsigned long outurb_active_mask;
 
 	struct snd_pcm_substream *sub_playback[MAX_STREAMS];
 	struct snd_pcm_substream *sub_capture[MAX_STREAMS];
author
#13 lore raw

PATCH 13/19 ALSA: ac97: Add HP Compaq dc5100 SFF(PT003AW) to Headphone Jack Sense whitelist

In reply to Greg KH

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

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

From: Daniel T Chen <[email protected]>

commit eade7b281c9fc18401b989c77d5e5e660b25a3b7 upstream.

The original reporter needs 'Headphone Jack Sense' enabled to have audible audio, so add his PCI SSID to the whitelist.

Reported-and-tested-by Muhammad Khurram Khan
---
 sound/pci/ac97/ac97_patch.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/ac97/ac97_patch.c +1 -0
@@ -1915,6 +1915,7 @@ static unsigned int ad1981_jacks_whiteli
 	0x103c0944, /* HP nc6220 */
 	0x103c0934, /* HP nc8220 */
 	0x103c006d, /* HP nx9105 */
+	0x103c300d, /* HP Compaq dc5100 SFF(PT003AW) */
 	0x17340088, /* FSC Scenic-W */
 	0 /* end */
 };
author
#14 lore raw

PATCH 14/19 futex: Fix regression with read only mappings

In reply to Greg KH

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

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

From: Shawn Bohrer <[email protected]>

commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae upstream.

commit 7485d0d3758e8e6491a5c9468114e74dc050785d (futexes: Remove rw parameter from get_futex_key()) in 2.6.33 fixed two problems: First, It prevented a loop when encountering a ZERO_PAGE. Second, it fixed RW MAP_PRIVATE futex operations by forcing the COW to occur by unconditionally performing a write access get_user_pages_fast() to get the page. The commit also introduced a user-mode regression in that it broke futex operations on read-only memory maps. For example, this breaks workloads that have one or more reader processes doing a FUTEX_WAIT on a futex within a read only shared file mapping, and a writer processes that has a writable mapping issuing the FUTEX_WAKE.

This fixes the regression for valid futex operations on RO mappings by trying a RO get_user_pages_fast() when the RW get_user_pages_fast() fails. This change makes it necessary to also check for invalid use cases, such as anonymous RO mappings (which can never change) and the ZERO_PAGE which the commit referenced above was written to address.

This patch does restore the original behavior with RO MAP_PRIVATE mappings, which have inherent user-mode usage problems and don't really make sense. With this patch performing a FUTEX_WAIT within a RO MAP_PRIVATE mapping will be successfully woken provided another process updates the region of the underlying mapped file. However, the mmap() man page states that for a MAP_PRIVATE mapping:

It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.

So user-mode users attempting to use futex operations on RO MAP_PRIVATE mappings are depending on unspecified behavior. Additionally a RO MAP_PRIVATE mapping could fail to wake up in the following case.

Thread-A: call futex(FUTEX_WAIT, memory-region-A).
get_futex_key() return inode based key.
sleep on the key
Thread-B: call mprotect(PROT_READ|PROT_WRITE, memory-region-A)
Thread-B: write memory-region-A.
COW happen. This process's memory-region-A become related to new COWed private (ie PageAnon=1) page.
Thread-B: call futex(FUETX_WAKE, memory-region-A).
get_futex_key() return mm based key.
IOW, we fail to wake up Thread-A.

Once again doing something like this is just silly and users who do something like this get what they deserve.

While RO MAP_PRIVATE mappings are nonsensical, checking for a private mapping requires walking the vmas and was deemed too costly to avoid a userspace hang.

This Patch is based on Peter Zijlstra's initial patch with modifications to only allow RO mappings for futex operations that need VERIFY_READ access.

---
 kernel/futex.c |   54 ++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 42 insertions(+), 12 deletions(-)
kernel/futex.c +42 -12
@@ -203,6 +203,8 @@ static void drop_futex_key_refs(union fu
  * @uaddr:	virtual address of the futex
  * @fshared:	0 for a PROCESS_PRIVATE futex, 1 for PROCESS_SHARED
  * @key:	address where result is stored.
+ * @rw:		mapping needs to be read/write (values: VERIFY_READ,
+ *              VERIFY_WRITE)
  *
  * Returns a negative error code or 0
  * The key words are stored in *key on success.
@@ -214,12 +216,12 @@ static void drop_futex_key_refs(union fu
  * lock_page() might sleep, the caller should not hold a spinlock.
  */
 static int
-get_futex_key(u32 __user *uaddr, int fshared, union futex_key *key)
+get_futex_key(u32 __user *uaddr, int fshared, union futex_key *key, int rw)
 {
 	unsigned long address = (unsigned long)uaddr;
 	struct mm_struct *mm = current->mm;
 	struct page *page;
-	int err;
+	int err, ro = 0;
 
 	/*
 	 * The futex address must be "naturally" aligned.
@@ -247,14 +249,31 @@ get_futex_key(u32 __user *uaddr, int fsh
 
 again:
 	err = get_user_pages_fast(address, 1, 1, &page);
+	/*
+	 * If write access is not required (eg. FUTEX_WAIT), try
+	 * and get read-only access.
+	 */
+	if (err == -EFAULT && rw == VERIFY_READ) {
+		err = get_user_pages_fast(address, 1, 0, &page);
+		ro = 1;
+	}
 	if (err < 0)
 		return err;
+	else
+		err = 0;
 
 	page = compound_head(page);
 	lock_page(page);
 	if (!page->mapping) {
 		unlock_page(page);
 		put_page(page);
+		/*
+		* ZERO_PAGE pages don't have a mapping. Avoid a busy loop
+		* trying to find one. RW mapping would have COW'd (and thus
+		* have a mapping) so this page is RO and won't ever change.
+		*/
+		if ((page == ZERO_PAGE(address)))
+			return -EFAULT;
 		goto again;
 	}
 
@@ -266,6 +285,15 @@ again:
 	 * the object not the particular process.
 	 */
 	if (PageAnon(page)) {
+		/*
+		 * A RO anonymous page will never change and thus doesn't make
+		 * sense for futex operations.
+		 */
+		if (ro) {
+			err = -EFAULT;
+			goto out;
+		}
+
 		key->both.offset |= FUT_OFF_MMSHARED; /* ref taken on mm */
 		key->private.mm = mm;
 		key->private.address = address;
@@ -277,9 +305,10 @@ again:
 
 	get_futex_key_refs(key);
 
+out:
 	unlock_page(page);
 	put_page(page);
-	return 0;
+	return err;
 }
 
 static inline
@@ -880,7 +909,7 @@ static int futex_wake(u32 __user *uaddr,
 	if (!bitset)
 		return -EINVAL;
 
-	ret = get_futex_key(uaddr, fshared, &key);
+	ret = get_futex_key(uaddr, fshared, &key, VERIFY_READ);
 	if (unlikely(ret != 0))
 		goto out;
 
@@ -926,10 +955,10 @@ futex_wake_op(u32 __user *uaddr1, int fs
 	int ret, op_ret;
 
 retry:
-	ret = get_futex_key(uaddr1, fshared, &key1);
+	ret = get_futex_key(uaddr1, fshared, &key1, VERIFY_READ);
 	if (unlikely(ret != 0))
 		goto out;
-	ret = get_futex_key(uaddr2, fshared, &key2);
+	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_WRITE);
 	if (unlikely(ret != 0))
 		goto out_put_key1;
 
@@ -1188,10 +1217,11 @@ retry:
 		pi_state = NULL;
 	}
 
-	ret = get_futex_key(uaddr1, fshared, &key1);
+	ret = get_futex_key(uaddr1, fshared, &key1, VERIFY_READ);
 	if (unlikely(ret != 0))
 		goto out;
-	ret = get_futex_key(uaddr2, fshared, &key2);
+	ret = get_futex_key(uaddr2, fshared, &key2,
+			    requeue_pi ? VERIFY_WRITE : VERIFY_READ);
 	if (unlikely(ret != 0))
 		goto out_put_key1;
 
@@ -1746,7 +1776,7 @@ static int futex_wait_setup(u32 __user *
 	 */
 retry:
 	q->key = FUTEX_KEY_INIT;
-	ret = get_futex_key(uaddr, fshared, &q->key);
+	ret = get_futex_key(uaddr, fshared, &q->key, VERIFY_READ);
 	if (unlikely(ret != 0))
 		return ret;
 
@@ -1912,7 +1942,7 @@ static int futex_lock_pi(u32 __user *uad
 	q.requeue_pi_key = NULL;
 retry:
 	q.key = FUTEX_KEY_INIT;
-	ret = get_futex_key(uaddr, fshared, &q.key);
+	ret = get_futex_key(uaddr, fshared, &q.key, VERIFY_WRITE);
 	if (unlikely(ret != 0))
 		goto out;
 
@@ -2031,7 +2061,7 @@ retry:
 	if ((uval & FUTEX_TID_MASK) != task_pid_vnr(current))
 		return -EPERM;
 
-	ret = get_futex_key(uaddr, fshared, &key);
+	ret = get_futex_key(uaddr, fshared, &key, VERIFY_WRITE);
 	if (unlikely(ret != 0))
 		goto out;
 
@@ -2223,7 +2253,7 @@ static int futex_wait_requeue_pi(u32 __u
 	rt_waiter.task = NULL;
 
 	key2 = FUTEX_KEY_INIT;
-	ret = get_futex_key(uaddr2, fshared, &key2);
+	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_WRITE);
 	if (unlikely(ret != 0))
 		goto out;
 
author
#15 lore raw

PATCH 15/19 x86-32, vdso: On system call restart after SYSENTER, use int $0x80

In reply to Greg KH

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

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

From: "H. Peter Anvin" <[email protected]>

commit 7ca0758cdb7c241cb4e0490a8d95f0eb5b861daf upstream.

When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle the arguments to match the int $0x80 calling convention. This was probably a design mistake, but it's what it is now. This causes errors if the system call as to be restarted.

For SYSENTER, we have to invoke the instruction from the vdso as the return address is hardcoded. Accordingly, we can simply replace the jump in the vdso with an int $0x80 instruction and use the slower entry point for a post-restart.

---
 arch/x86/vdso/vdso32/sysenter.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/vdso/vdso32/sysenter.S +1 -1
@@ -43,7 +43,7 @@ __kernel_vsyscall:
 	.space 7,0x90
 
 	/* 14: System call restart point is here! (SYSENTER_RETURN-2) */
-	jmp .Lenter_kernel
+	int $0x80
 	/* 16: System call normal return point is here! */
 VDSO32_SYSENTER_RETURN:	/* Symbol used by sysenter.c via vdso32-syms.h */
 	pop %ebp
author
#16 lore raw

PATCH 16/19 x86, UV: Remove UV delay in starting slave cpus

In reply to Greg KH

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

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

From: Jack Steiner <[email protected]>

commit 05e33fc20ea5e493a2a1e7f1d04f43cdf89f83ed upstream.

Delete the 10 msec delay between the INIT and SIPI when starting slave cpus. I can find no requirement for this delay. BIOS also has similar code sequences without the delay.

Removing the delay reduces boot time by 40 sec. Every bit helps.

---
 arch/x86/kernel/apic/x2apic_uv_x.c |    1 -
 1 file changed, 1 deletion(-)
arch/x86/kernel/apic/x2apic_uv_x.c +0 -1
@@ -117,7 +117,6 @@ static int __cpuinit uv_wakeup_secondary
 	    ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
 	    APIC_DM_INIT;
 	uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
-	mdelay(10);
 
 	val = (1UL << UVH_IPI_INT_SEND_SHFT) |
 	    (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
author
#17 lore raw

PATCH 17/19 drm/ttm: fix ttm_bo_add_ttm(user) failure path

In reply to Greg KH

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

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

From: Marcin Slusarz <[email protected]>

commit 7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream.

ttm_tt_destroy kfrees passed object, so we need to nullify a reference to it.

---
 drivers/gpu/drm/ttm/ttm_bo.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/ttm/ttm_bo.c +3 -1
@@ -281,8 +281,10 @@ static int ttm_bo_add_ttm(struct ttm_buf
 
 		ret = ttm_tt_set_user(bo->ttm, current,
 				      bo->buffer_start, bo->num_pages);
-		if (unlikely(ret != 0))
+		if (unlikely(ret != 0)) {
 			ttm_tt_destroy(bo->ttm);
+			bo->ttm = NULL;
+		}
 		break;
 	default:
 		printk(KERN_ERR TTM_PFX "Illegal buffer object type\n");
author
#18 lore raw

PATCH 18/19 fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message

In reply to Greg KH

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

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

From: Miklos Szeredi <[email protected]>

commit c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream.

FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the message processing could overrun and result in a "kernel BUG at fs/fuse/dev.c:629!"

---
 fs/fuse/dev.c |    4 ++++
 1 file changed, 4 insertions(+)
fs/fuse/dev.c +4 -0
@@ -899,6 +899,10 @@ static int fuse_notify_inval_entry(struc
 	if (outarg.namelen > FUSE_NAME_MAX)
 		goto err;
 
+	err = -EINVAL;
+	if (size != sizeof(outarg) + outarg.namelen + 1)
+		goto err;
+
 	name.name = buf;
 	name.len = outarg.namelen;
 	err = fuse_copy_one(cs, buf, outarg.namelen + 1);
author
#19 lore raw

PATCH 19/19 igb: Fix lack of flush after register write and before delay

In reply to Greg KH

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

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

From: Carolyn Wyborny <[email protected]>

commit 064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream.

Register writes followed by a delay are required to have a flush before the delay in order to commit the values to the register. Without the flush, the code following the delay may not function correctly.

---
 drivers/net/igb/e1000_82575.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/igb/e1000_82575.c +1 -0
@@ -941,6 +941,7 @@ static s32 igb_setup_copper_link_82575(s
 	ctrl |= E1000_CTRL_SLU;
 	ctrl &= ~(E1000_CTRL_FRCSPD | E1000_CTRL_FRCDPX);
 	wr32(E1000_CTRL, ctrl);
+	wrfl();
 
 	ret_val = igb_setup_serdes_link_82575(hw);
 	if (ret_val)
#20 lore raw
In reply to Greg KH

Greg KH wrote...

Quoted 3 lines

This is the start of the longterm review cycle for the 2.6.32.46 release. There are 19 patches in this series, all will be posted as a response to this one.

Seems like they didn't get though to LKML, same for 3.0.4. Can you please provide them, or at least the applicable commit hashes from master?

Thanks,

Christoph

author
#21 lore raw
Quoted 9 lines · Christoph Biedl

Greg KH wrote...

Quoted 3 lines

This is the start of the longterm review cycle for the 2.6.32.46 release. There are 19 patches in this series, all will be posted as a response to this one.

Seems like they didn't get though to LKML, same for 3.0.4. Can you please provide them, or at least the applicable commit hashes from master?

I see them there now, don't you?

#22 lore raw

Greg KH wrote...

Quoted 1 line

I see them there now, don't you?

They've arrived now, thanks.

Christoph

#23 lore raw
In reply to Greg KH
Quoted 9 lines · Greg KH

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

Responses should be made by Monday, August 29, 2011, 12:00:00 UTC. Anything received after that time might be too late.

Quoted 7 lines

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

	kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.46-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

Hi,

upstream commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978 ("tunnels: fix netns vs proto registration ordering") , which was included in 2.6.32.44-longterm, was not backported correctly, and results in a NULL pointer dereference in ip6_tunnel.c for longterm kernels 2.6.32.44 and 2.6.32.45.

The bug has been reported at the Gentoo [1] and Debian [2] bugzillas, and fixed in the latest grsec-patches [3], but I haven't found a report for this at the lkml (or at the kernel's bugzilla).

The fix is trivial, and I think it can be included in 2.6.32.46, if possible.
If you want, I can submit it with a new email to [email protected].

net/ipv6/ip6_tunnel.c +1 -1
index 7fb3e02..53e0d51 100644
@@ -1466,7 +1466,7 @@ static int __init ip6_tunnel_init(void)
 {
        int  err;
 
-       err = register_pernet_device(&ip6_tnl_net_ops);
+       err = register_pernet_gen_device(&ip6_tnl_net_id, &ip6_tnl_net_ops);
        if (err < 0)
                goto out_pernet;
 

Btw, this has been fixed in grsec-patches, and an identical patch has also been posted at the Debian bugzilla, so I'm not sure about the Signed-off-by and Reported-by tags.

[1] https://bugs.gentoo.org/show_bug.cgi?id=380609
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633738
[3] http://grsecurity.net/changelog-stable.txt

Signature · 2 lines
Stratos Psomadakis
<[email protected]>
#24 lore raw
Quoted 25 lines · Stratos Psomadakis
Quoted 9 lines · Greg KH

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

Responses should be made by Monday, August 29, 2011, 12:00:00 UTC. Anything received after that time might be too late.

Quoted 7 lines

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

	kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.46-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

Hi,

upstream commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978 ("tunnels: fix netns vs proto registration ordering") , which was included in 2.6.32.44-longterm, was not backported correctly, and results in a NULL pointer dereference in ip6_tunnel.c for longterm kernels 2.6.32.44 and 2.6.32.45.

Quoted 7 lines

The bug has been reported at the Gentoo [1] and Debian [2] bugzillas, and fixed in the latest grsec-patches [3], but I haven't found a report for this at the lkml (or at the kernel's bugzilla).

The fix is trivial, and I think it can be included in 2.6.32.46, if possible.
If you want, I can submit it with a new email to [email protected].

Yes, please do so I can properly add it.

thanks,

greg k-h