All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/23] 2.6.27.58-longterm review
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review

This is the start of the longterm review cycle for the 2.6.27.58 release.
This version is up to date with what was merged in 2.6.32.28.

I know it was sensibly delayed, but nothing was critical so I preferred to
ensure that I did not repeat the hackish review process I used to work with
on 2.6.20. Next reviews should take less time. Special thanks to thank Greg
for sharing scripts, ideas and methods to help me catch up with a process I
left a few years ago.

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.

The full quilt queue can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/longterm/longterm-queue-2.6.27.git

Responses should be made within 72 hours. 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.27.58-rc1.gz
and the diffstat can be found below.

 arch/x86/vdso/Makefile               |    4 +-
 drivers/char/hvc_console.c           |   25 +++++---
 drivers/dma/mv_xor.c                 |    2 +-
 drivers/hid/hidraw.c                 |   11 +++-
 drivers/hwmon/adm1026.c              |   20 +++---
 drivers/infiniband/core/uverbs_cmd.c |  101 +++++++++++++++++++---------------
 drivers/md/md.c                      |    7 ++-
 drivers/usb/misc/uss720.c            |    4 +-
 drivers/usb/storage/unusual_devs.h   |    7 ++
 fs/exec.c                            |    5 ++
 fs/nfs/file.c                        |    2 +
 fs/nfsd/nfs3xdr.c                    |    6 +-
 include/linux/nfsd/xdr4.h            |    4 +-
 include/net/sctp/sm.h                |    1 +
 include/net/sctp/structs.h           |    3 +
 kernel/exit.c                        |    8 +++
 kernel/power/user.c                  |    2 +-
 kernel/trace/trace.c                 |   12 +++-
 mm/mmap.c                            |   16 ++++-
 net/sctp/input.c                     |   22 ++++++-
 net/sctp/sm_sideeffect.c             |   35 ++++++++++++
 net/sctp/transport.c                 |    2 +
 net/sunrpc/svc_xprt.c                |    9 +++-
 sound/oss/soundcard.c                |    4 +-
 sound/pci/hda/hda_intel.c            |    2 +
 sound/pci/hda/patch_realtek.c        |    1 +
 26 files changed, 225 insertions(+), 90 deletions(-)



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 01/23] ALSA: hda: Use model=lg quirk for LG P1 Express to enable playback and capture
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Daniel T Chen, Takashi Iwai, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Daniel T Chen <crimsun@ubuntu.com>

commit 77c4d5cdb81d25a45fbdfb84dd3348121219a072 upstream.

BugLink: https://launchpad.net/bugs/595482

The original reporter states that audible playback from the internal
speaker is inaudible despite the hardware being properly detected.  To
work around this symptom, he uses the model=lg quirk to properly enable
both playback, capture, and jack sense.  Another user corroborates this
workaround on separate hardware.  Add this PCI SSID to the quirk table
to enable it for further LG P1 Expresses.

Reported-and-tested-by: Philip Peitsch <philip.peitsch@gmail.com>
Tested-by: nikhov
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)

Index: longterm-2.6.27/sound/pci/hda/patch_realtek.c
===================================================================
--- longterm-2.6.27.orig/sound/pci/hda/patch_realtek.c	2011-01-29 11:19:14.761063991 +0100
+++ longterm-2.6.27/sound/pci/hda/patch_realtek.c	2011-01-29 11:26:53.367191052 +0100
@@ -3154,6 +3154,7 @@
 	SND_PCI_QUIRK(0x1734, 0x10b0, "Fujitsu", ALC880_FUJITSU),
 	SND_PCI_QUIRK(0x1854, 0x0018, "LG LW20", ALC880_LG_LW),
 	SND_PCI_QUIRK(0x1854, 0x003b, "LG", ALC880_LG),
+	SND_PCI_QUIRK(0x1854, 0x005f, "LG P1 Express", ALC880_LG),
 	SND_PCI_QUIRK(0x1854, 0x0068, "LG w1", ALC880_LG),
 	SND_PCI_QUIRK(0x1854, 0x0077, "LG LW25", ALC880_LG_LW),
 	SND_PCI_QUIRK(0x19db, 0x4188, "TCL S700", ALC880_TCL_S700),



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 02/23] ALSA: hda: Use LPIB for Dell Latitude 131L
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Daniel T Chen, Takashi Iwai, Willy Tarreau

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

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

From: Daniel T Chen <crimsun@ubuntu.com>

commit 9919c7619c52d01e89103bca405cc3d4a2b1ac31 upstream.

BugLink: https://launchpad.net/bugs/530346

The OR has verified that position_fix=1 is necessary to work around
errors on his machine.

Reported-by: Tom Louwrier
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 sound/pci/hda/hda_intel.c |    1 +
 1 file changed, 1 insertion(+)

Index: longterm-2.6.27/sound/pci/hda/hda_intel.c
===================================================================
--- longterm-2.6.27.orig/sound/pci/hda/hda_intel.c	2011-01-23 10:52:41.000000000 +0100
+++ longterm-2.6.27/sound/pci/hda/hda_intel.c	2011-01-29 15:57:30.536067735 +0100
@@ -1966,6 +1966,7 @@
 static struct snd_pci_quirk position_fix_list[] __devinitdata = {
 	SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB),
+	SND_PCI_QUIRK(0x1028, 0x01f6, "Dell Latitude 131L", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
 	{}
 };



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 03/23] ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Daniel T Chen, Takashi Iwai, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Daniel T Chen <crimsun@ubuntu.com>

commit e03fa055bc126e536c7f65862e08a9b143138ea9 upstream.

Sjoerd Simons reports that, without using position_fix=1, recording
experiences overruns. Work around that by applying the LPIB quirk
for his hardware.

Reported-and-tested-by: Sjoerd Simons <sjoerd@debian.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 sound/pci/hda/hda_intel.c |    1 +
 1 file changed, 1 insertion(+)

Index: longterm-2.6.27/sound/pci/hda/hda_intel.c
===================================================================
--- longterm-2.6.27.orig/sound/pci/hda/hda_intel.c	2011-01-29 15:57:30.000000000 +0100
+++ longterm-2.6.27/sound/pci/hda/hda_intel.c	2011-01-29 15:58:13.711064993 +0100
@@ -1967,6 +1967,7 @@
 	SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1028, 0x01f6, "Dell Latitude 131L", POS_FIX_LPIB),
+	SND_PCI_QUIRK(0x1028, 0x0470, "Dell Inspiron 1120", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
 	{}
 };



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 04/23] USB: usb-storage: unusual_devs entry for the Samsung YP-CP3
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Vitaly Kuznetsov, Alan Stern, Matthew Dharm, Greg Kroah-Hartman,
	Willy Tarreau

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

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

From: Vitaly Kuznetsov <vitty@altlinux.ru>

commit d73a9b3001f29271c2e9f2a806b05a431c5d9591 upstream.

Add an unusual_devs entry for the Samsung YP-CP3 MP4 player.

User was getting the following errors in dmesg:
 usb 2-6: reset high speed USB device using ehci_hcd and address 2
 usb 2-6: reset high speed USB device using ehci_hcd and address 2
 usb 2-6: reset high speed USB device using ehci_hcd and address 2
 usb 2-6: USB disconnect, address 2
 sd 3:0:0:0: [sdb] Assuming drive cache: write through
 sdb:<2>ldm_validate_partition_table(): Disk read failed.
 Dev sdb: unable to read RDB block 0
  unable to read partition table

Signed-off-by: Vitaly Kuznetsov <vitty@altlinux.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

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

Index: longterm-2.6.27/drivers/usb/storage/unusual_devs.h
===================================================================
--- longterm-2.6.27.orig/drivers/usb/storage/unusual_devs.h	2011-01-29 11:19:14.704065119 +0100
+++ longterm-2.6.27/drivers/usb/storage/unusual_devs.h	2011-01-29 11:27:24.078067832 +0100
@@ -608,6 +608,13 @@
 		US_SC_DEVICE, US_PR_DEVICE, NULL,
 		US_FL_MAX_SECTORS_64),
 
+/* Reported by Vitaly Kuznetsov <vitty@altlinux.ru> */
+UNUSUAL_DEV(  0x04e8, 0x5122, 0x0000, 0x9999,
+		"Samsung",
+		"YP-CP3",
+		US_SC_DEVICE, US_PR_DEVICE, NULL,
+		US_FL_MAX_SECTORS_64 | US_FL_BULK_IGNORE_TAG),
+
 /* Entry and supporting patch by Theodore Kilgore <kilgota@auburn.edu>.
  * Device uses standards-violating 32-byte Bulk Command Block Wrappers and
  * reports itself as "Proprietary SCSI Bulk." Cf. device entry 0x084d:0x0011.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 05/23] USB: misc: uss720.c: add another vendor/product ID
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Thomas Sailer, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Thomas Sailer <t.sailer@alumni.ethz.ch>

commit ecc1624a2fff45780959efbcb73ace18fdb3c58d upstream.

Fabio Battaglia report that he has another cable that works with this
driver, so this patch adds its vendor/product ID.

Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/usb/misc/uss720.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: longterm-2.6.27/drivers/usb/misc/uss720.c
===================================================================
--- longterm-2.6.27.orig/drivers/usb/misc/uss720.c	2011-01-29 11:19:14.700064522 +0100
+++ longterm-2.6.27/drivers/usb/misc/uss720.c	2011-01-29 11:27:23.196065599 +0100
@@ -3,7 +3,7 @@
 /*
  *	uss720.c  --  USS720 USB Parport Cable.
  *
- *	Copyright (C) 1999, 2005
+ *	Copyright (C) 1999, 2005, 2010
  *	    Thomas Sailer (t.sailer@alumni.ethz.ch)
  *
  *	This program is free software; you can redistribute it and/or modify
@@ -774,6 +774,8 @@
 	{ USB_DEVICE(0x0557, 0x2001) },
 	{ USB_DEVICE(0x0729, 0x1284) },
 	{ USB_DEVICE(0x1293, 0x0002) },
+	{ USB_DEVICE(0x1293, 0x0002) },
+	{ USB_DEVICE(0x050d, 0x0002) },
 	{ }						/* Terminating entry */
 };
 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 06/23] HID: hidraw: fix window in hidraw_release
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Jiri Slaby, Jiri Kosina, Antonio Ospite, Greg Kroah-Hartman,
	Willy Tarreau

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

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

From: Jiri Slaby <jslaby@suse.cz>

commit cb174681a9ececa6702f114b85bdf82144b6a5af upstream.

[ Backport to .32.y by Antonio Ospite <ospite@studenti.unina.it> ]

There is a window between hidraw_table check and its dereference.
In that window, the device may be unplugged and removed form the
system and we will then dereference NULL.

Lock that place properly so that either we get NULL and jump out or we
can work with real pointer.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/hid/hidraw.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/hid/hidraw.c
===================================================================
--- longterm-2.6.27.orig/drivers/hid/hidraw.c	2011-01-29 11:19:14.681064282 +0100
+++ longterm-2.6.27/drivers/hid/hidraw.c	2011-01-29 11:27:11.371063762 +0100
@@ -196,11 +196,14 @@
 	unsigned int minor = iminor(inode);
 	struct hidraw *dev;
 	struct hidraw_list *list = file->private_data;
+	int ret;
 
+	mutex_lock(&minors_lock);
 	if (!hidraw_table[minor]) {
 		printk(KERN_EMERG "hidraw device with minor %d doesn't exist\n",
 				minor);
-		return -ENODEV;
+		ret = -ENODEV;
+		goto unlock;
 	}
 
 	list_del(&list->node);
@@ -211,10 +214,12 @@
 		else
 			kfree(list->hidraw);
 	}
-
 	kfree(list);
+	ret = 0;
+unlock:
+	mutex_unlock(&minors_lock);
 
-	return 0;
+	return ret;
 }
 
 static long hidraw_ioctl(struct file *file, unsigned int cmd,



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 07/23] hwmon: (adm1026) Allow 1 as a valid divider value
@ 2011-02-06 23:22 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:22 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Gabriele Gorla, Jean Delvare, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Gabriele Gorla <gorlik@penguintown.net>

commit 8b0f1840a46449e1946fc88860ef3ec8d6b1c2c7 upstream.

Allow 1 as a valid div value as specified in the ADM1026 datasheet.

Signed-off-by: Gabriele Gorla <gorlik@penguintown.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/hwmon/adm1026.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Index: longterm-2.6.27/drivers/hwmon/adm1026.c
===================================================================
--- longterm-2.6.27.orig/drivers/hwmon/adm1026.c	2011-01-29 11:19:14.685064867 +0100
+++ longterm-2.6.27/drivers/hwmon/adm1026.c	2011-01-29 11:27:12.646064622 +0100
@@ -926,9 +926,7 @@
 
 	val = simple_strtol(buf, NULL, 10);
 	new_div = DIV_TO_REG(val);
-	if (new_div == 0) {
-		return -EINVAL;
-	}
+
 	mutex_lock(&data->update_lock);
 	orig_div = data->fan_div[nr];
 	data->fan_div[nr] = DIV_FROM_REG(new_div);



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 08/23] hwmon: (adm1026) Fix setting fan_div
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Gabriele Gorla, Jean Delvare, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Gabriele Gorla <gorlik@penguintown.net>

commit 52bc9802ce849d0d287cc5fe76d06b0daa3986ca upstream.

Prevent setting fan_div from stomping on other fans that share the
same I2C register.

Signed-off-by: Gabriele Gorla <gorlik@penguintown.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/hwmon/adm1026.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

Index: longterm-2.6.27/drivers/hwmon/adm1026.c
===================================================================
--- longterm-2.6.27.orig/drivers/hwmon/adm1026.c	2011-01-29 11:27:12.646064622 +0100
+++ longterm-2.6.27/drivers/hwmon/adm1026.c	2011-01-29 11:27:13.410065115 +0100
@@ -922,7 +922,7 @@
 	int nr = sensor_attr->index;
 	struct i2c_client *client = to_i2c_client(dev);
 	struct adm1026_data *data = i2c_get_clientdata(client);
-	int val, orig_div, new_div, shift;
+	int val, orig_div, new_div;
 
 	val = simple_strtol(buf, NULL, 10);
 	new_div = DIV_TO_REG(val);
@@ -932,15 +932,17 @@
 	data->fan_div[nr] = DIV_FROM_REG(new_div);
 
 	if (nr < 4) { /* 0 <= nr < 4 */
-		shift = 2 * nr;
 		adm1026_write_value(client, ADM1026_REG_FAN_DIV_0_3,
-			((DIV_TO_REG(orig_div) & (~(0x03 << shift))) |
-			(new_div << shift)));
+				    (DIV_TO_REG(data->fan_div[0]) << 0) |
+				    (DIV_TO_REG(data->fan_div[1]) << 2) |
+				    (DIV_TO_REG(data->fan_div[2]) << 4) |
+				    (DIV_TO_REG(data->fan_div[3]) << 6));
 	} else { /* 3 < nr < 8 */
-		shift = 2 * (nr - 4);
 		adm1026_write_value(client, ADM1026_REG_FAN_DIV_4_7,
-			((DIV_TO_REG(orig_div) & (~(0x03 << (2 * shift)))) |
-			(new_div << shift)));
+				    (DIV_TO_REG(data->fan_div[4]) << 0) |
+				    (DIV_TO_REG(data->fan_div[5]) << 2) |
+				    (DIV_TO_REG(data->fan_div[6]) << 4) |
+				    (DIV_TO_REG(data->fan_div[7]) << 6));
 	}
 
 	if (data->fan_div[nr] != orig_div) {



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 09/23] IB/uverbs: Handle large number of entries in poll CQ
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Dan Carpenter, Roland Dreier, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Dan Carpenter <error27@gmail.com>

commit 7182afea8d1afd432a17c18162cc3fd441d0da93 upstream.

In ib_uverbs_poll_cq() code there is a potential integer overflow if
userspace passes in a large cmd.ne.  The calls to kmalloc() would
allocate smaller buffers than intended, leading to memory corruption.
There iss also an information leak if resp wasn't all used.
Unprivileged userspace may call this function, although only if an
RDMA device that uses this function is present.

Fix this by copying CQ entries one at a time, which avoids the
allocation entirely, and also by moving this copying into a function
that makes sure to initialize all memory copied to userspace.

Special thanks to Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
for his help and advice.

Signed-off-by: Dan Carpenter <error27@gmail.com>

[ Monkey around with things a bit to avoid bad code generation by gcc
  when designated initializers are used.  - Roland ]

Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/infiniband/core/uverbs_cmd.c |  101 +++++++++++++++++++----------------
 1 file changed, 57 insertions(+), 44 deletions(-)

Index: longterm-2.6.27/drivers/infiniband/core/uverbs_cmd.c
===================================================================
--- longterm-2.6.27.orig/drivers/infiniband/core/uverbs_cmd.c	2011-01-29 11:19:14.689065716 +0100
+++ longterm-2.6.27/drivers/infiniband/core/uverbs_cmd.c	2011-01-29 11:27:14.060064011 +0100
@@ -875,68 +875,81 @@
 	return ret ? ret : in_len;
 }
 
+static int copy_wc_to_user(void __user *dest, struct ib_wc *wc)
+{
+	struct ib_uverbs_wc tmp;
+
+	tmp.wr_id		= wc->wr_id;
+	tmp.status		= wc->status;
+	tmp.opcode		= wc->opcode;
+	tmp.vendor_err		= wc->vendor_err;
+	tmp.byte_len		= wc->byte_len;
+	tmp.ex.imm_data		= (__u32 __force) wc->ex.imm_data;
+	tmp.qp_num		= wc->qp->qp_num;
+	tmp.src_qp		= wc->src_qp;
+	tmp.wc_flags		= wc->wc_flags;
+	tmp.pkey_index		= wc->pkey_index;
+	tmp.slid		= wc->slid;
+	tmp.sl			= wc->sl;
+	tmp.dlid_path_bits	= wc->dlid_path_bits;
+	tmp.port_num		= wc->port_num;
+	tmp.reserved		= 0;
+
+	if (copy_to_user(dest, &tmp, sizeof tmp))
+		return -EFAULT;
+
+	return 0;
+}
+
 ssize_t ib_uverbs_poll_cq(struct ib_uverbs_file *file,
 			  const char __user *buf, int in_len,
 			  int out_len)
 {
 	struct ib_uverbs_poll_cq       cmd;
-	struct ib_uverbs_poll_cq_resp *resp;
+	struct ib_uverbs_poll_cq_resp  resp;
+	u8 __user                     *header_ptr;
+	u8 __user                     *data_ptr;
 	struct ib_cq                  *cq;
-	struct ib_wc                  *wc;
-	int                            ret = 0;
-	int                            i;
-	int                            rsize;
+	struct ib_wc                   wc;
+	int                            ret;
 
 	if (copy_from_user(&cmd, buf, sizeof cmd))
 		return -EFAULT;
 
-	wc = kmalloc(cmd.ne * sizeof *wc, GFP_KERNEL);
-	if (!wc)
-		return -ENOMEM;
-
-	rsize = sizeof *resp + cmd.ne * sizeof(struct ib_uverbs_wc);
-	resp = kmalloc(rsize, GFP_KERNEL);
-	if (!resp) {
-		ret = -ENOMEM;
-		goto out_wc;
-	}
-
 	cq = idr_read_cq(cmd.cq_handle, file->ucontext, 0);
-	if (!cq) {
-		ret = -EINVAL;
-		goto out;
-	}
+	if (!cq)
+		return -EINVAL;
 
-	resp->count = ib_poll_cq(cq, cmd.ne, wc);
+	/* we copy a struct ib_uverbs_poll_cq_resp to user space */
+	header_ptr = (void __user *)(unsigned long) cmd.response;
+	data_ptr = header_ptr + sizeof resp;
 
-	put_cq_read(cq);
+	memset(&resp, 0, sizeof resp);
+	while (resp.count < cmd.ne) {
+		ret = ib_poll_cq(cq, 1, &wc);
+		if (ret < 0)
+			goto out_put;
+		if (!ret)
+			break;
+
+		ret = copy_wc_to_user(data_ptr, &wc);
+		if (ret)
+			goto out_put;
 
-	for (i = 0; i < resp->count; i++) {
-		resp->wc[i].wr_id 	   = wc[i].wr_id;
-		resp->wc[i].status 	   = wc[i].status;
-		resp->wc[i].opcode 	   = wc[i].opcode;
-		resp->wc[i].vendor_err 	   = wc[i].vendor_err;
-		resp->wc[i].byte_len 	   = wc[i].byte_len;
-		resp->wc[i].ex.imm_data    = (__u32 __force) wc[i].ex.imm_data;
-		resp->wc[i].qp_num 	   = wc[i].qp->qp_num;
-		resp->wc[i].src_qp 	   = wc[i].src_qp;
-		resp->wc[i].wc_flags 	   = wc[i].wc_flags;
-		resp->wc[i].pkey_index 	   = wc[i].pkey_index;
-		resp->wc[i].slid 	   = wc[i].slid;
-		resp->wc[i].sl 		   = wc[i].sl;
-		resp->wc[i].dlid_path_bits = wc[i].dlid_path_bits;
-		resp->wc[i].port_num 	   = wc[i].port_num;
+		data_ptr += sizeof(struct ib_uverbs_wc);
+		++resp.count;
 	}
 
-	if (copy_to_user((void __user *) (unsigned long) cmd.response, resp, rsize))
+	if (copy_to_user(header_ptr, &resp, sizeof resp)) {
 		ret = -EFAULT;
+		goto out_put;
+	}
 
-out:
-	kfree(resp);
+	ret = in_len;
 
-out_wc:
-	kfree(wc);
-	return ret ? ret : in_len;
+out_put:
+	put_cq_read(cq);
+	return ret;
 }
 
 ssize_t ib_uverbs_req_notify_cq(struct ib_uverbs_file *file,



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 10/23] mv_xor: fix race in tasklet function
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Saeed Bishara, Dan Williams, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Saeed Bishara <saeed@marvell.com>

commit 8333f65ef094e47020cd01452b4637e7daf5a77f upstream.

use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
aquires the spin lock that needed to protect the drivers data.

Signed-off-by: Saeed Bishara <saeed@marvell.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

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

Index: longterm-2.6.27/drivers/dma/mv_xor.c
===================================================================
--- longterm-2.6.27.orig/drivers/dma/mv_xor.c	2011-01-29 11:22:46.657065036 +0100
+++ longterm-2.6.27/drivers/dma/mv_xor.c	2011-01-29 11:27:15.509064355 +0100
@@ -449,7 +449,7 @@
 static void mv_xor_tasklet(unsigned long data)
 {
 	struct mv_xor_chan *chan = (struct mv_xor_chan *) data;
-	__mv_xor_slot_cleanup(chan);
+	mv_xor_slot_cleanup(chan);
 }
 
 static struct mv_xor_desc_slot *



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 11/23] md: fix bug with re-adding of partially recovered device.
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: NeilBrown, Greg Kroah-Hartman, Willy Tarreau

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

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

From: NeilBrown <neilb@suse.de>

commit 1a855a0606653d2d82506281e2c686bacb4b2f45 upstream.

With v0.90 metadata, a hot-spare does not become a full member of the
array until recovery is complete.  So if we re-add such a device to
the array, we know that all of it is as up-to-date as the event count
would suggest, and so it a bitmap-based recovery is possible.

However with v1.x metadata, the hot-spare immediately becomes a full
member of the array, but it record how much of the device has been
recovered.  If the array is stopped and re-assembled recovery starts
from this point.

When such a device is hot-added to an array we currently lose the 'how
much is recovered' information and incorrectly included it as a full
in-sync member (after bitmap-based fixup).
This is wrong and unsafe and could corrupt data.

So be more careful about setting saved_raid_disk - which is what
guides the re-adding of devices back into an array.
The new code matches the code in slot_store which does a similar
thing, which is encouraging.

This is suitable for any -stable kernel.

Reported-by: "Dailey, Nate" <Nate.Dailey@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/md/md.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/drivers/md/md.c
===================================================================
--- longterm-2.6.27.orig/drivers/md/md.c	2011-01-29 11:19:14.697066081 +0100
+++ longterm-2.6.27/drivers/md/md.c	2011-01-29 11:27:14.692063986 +0100
@@ -4300,7 +4300,7 @@
 				PTR_ERR(rdev));
 			return PTR_ERR(rdev);
 		}
-		/* set save_raid_disk if appropriate */
+		/* set saved_raid_disk if appropriate */
 		if (!mddev->persistent) {
 			if (info->state & (1<<MD_DISK_SYNC)  &&
 			    info->raid_disk < mddev->raid_disks)
@@ -4310,7 +4310,10 @@
 		} else
 			super_types[mddev->major_version].
 				validate_super(mddev, rdev);
-		rdev->saved_raid_disk = rdev->raid_disk;
+		if (test_bit(In_sync, &rdev->flags))
+			rdev->saved_raid_disk = rdev->raid_disk;
+		else
+			rdev->saved_raid_disk = -1;
 
 		clear_bit(In_sync, &rdev->flags); /* just to be sure */
 		if (info->state & (1<<MD_DISK_WRITEMOSTLY))



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 12/23] NFS: Fix fcntl F_GETLK not reporting some conflicts
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Sergey Vlasov, Trond Myklebust, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Sergey Vlasov <vsu@altlinux.ru>

commit 21ac19d484a8ffb66f64487846c8d53afef04d2b upstream.

The commit 129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK
regression (failure to find conflicts)) fixed the posix_test_lock()
function by itself, however, its usage in NFS changed by the commit
9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock
same interface as ->lock) remained broken - subsequent NFS-specific
locking code received F_UNLCK instead of the user-specified lock type.
To fix the problem, fl->fl_type needs to be saved before the
posix_test_lock() call and restored if no local conflicts were reported.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892
Tested-by: Alexander Morozov <amorozov@etersoft.ru>
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 fs/nfs/file.c |    2 ++
 1 file changed, 2 insertions(+)

Index: longterm-2.6.27/fs/nfs/file.c
===================================================================
--- longterm-2.6.27.orig/fs/nfs/file.c	2011-01-29 11:19:14.707063734 +0100
+++ longterm-2.6.27/fs/nfs/file.c	2011-01-29 11:27:16.154063024 +0100
@@ -552,6 +552,7 @@
 {
 	struct inode *inode = filp->f_mapping->host;
 	int status = 0;
+	unsigned int saved_type = fl->fl_type;
 
 	lock_kernel();
 	/* Try local locking first */
@@ -560,6 +561,7 @@
 		/* found a conflict */
 		goto out;
 	}
+	fl->fl_type = saved_type;
 
 	if (nfs_have_delegation(inode, FMODE_READ))
 		goto out_noconflict;



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 13/23] nfsd: Fix possible BUG_ON firing in set_change_info
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: NeilBrown, J. Bruce Fields, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Neil Brown <neilb@suse.de>

commit c1ac3ffcd0bc7e9617f62be8c7043d53ab84deac upstream.

If vfs_getattr in fill_post_wcc returns an error, we don't
set fh_post_change.
For NFSv4, this can result in set_change_info triggering a BUG_ON.
i.e. fh_post_saved being zero isn't really a bug.

So:
 - instead of BUGging when fh_post_saved is zero, just clear ->atomic.
 - if vfs_getattr fails in fill_post_wcc, take a copy of i_ctime anyway.
   This will be used i seg_change_info, but not overly trusted.
 - While we are there, remove the pointless 'if' statements in set_change_info.
   There is no harm setting all the values.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 fs/nfsd/nfs3xdr.c         |    6 ++++--
 include/linux/nfsd/xdr4.h |   21 ++++++++++-----------
 2 files changed, 14 insertions(+), 13 deletions(-)

Index: longterm-2.6.27/fs/nfsd/nfs3xdr.c
===================================================================
--- longterm-2.6.27.orig/fs/nfsd/nfs3xdr.c	2011-01-23 10:52:29.000000000 +0100
+++ longterm-2.6.27/fs/nfsd/nfs3xdr.c	2011-01-29 11:59:54.144063900 +0100
@@ -272,9 +272,11 @@
 
 	err = vfs_getattr(fhp->fh_export->ex_path.mnt, fhp->fh_dentry,
 			&fhp->fh_post_attr);
-	if (err)
+	if (err) {
 		fhp->fh_post_saved = 0;
-	else
+		/* Grab the ctime anyway - set_change_info might use it */
+		fhp->fh_post_attr.ctime = fhp->fh_dentry->d_inode->i_ctime;
+	} else
 		fhp->fh_post_saved = 1;
 }
 
Index: longterm-2.6.27/include/linux/nfsd/xdr4.h
===================================================================
--- longterm-2.6.27.orig/include/linux/nfsd/xdr4.h	2011-01-23 10:52:35.000000000 +0100
+++ longterm-2.6.27/include/linux/nfsd/xdr4.h	2011-01-29 11:58:59.816063878 +0100
@@ -424,8 +424,8 @@
 static inline void
 set_change_info(struct nfsd4_change_info *cinfo, struct svc_fh *fhp)
 {
-	BUG_ON(!fhp->fh_pre_saved || !fhp->fh_post_saved);
-	cinfo->atomic = 1;
+	BUG_ON(!fhp->fh_pre_saved);
+	cinfo->atomic = fhp->fh_post_saved;
 	cinfo->before_ctime_sec = fhp->fh_pre_ctime.tv_sec;
 	cinfo->before_ctime_nsec = fhp->fh_pre_ctime.tv_nsec;
 	cinfo->after_ctime_sec = fhp->fh_post_attr.ctime.tv_sec;



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 14/23] PM / Hibernate: Fix PM_POST_* notification with user-space suspend
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Takashi Iwai, Rafael J. Wysocki, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream.

The user-space hibernation sends a wrong notification after the image
restoration because of thinko for the file flag check.  RDONLY
corresponds to hibernation and WRONLY to restoration, confusingly.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 kernel/power/user.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: longterm-2.6.27/kernel/power/user.c
===================================================================
--- longterm-2.6.27.orig/kernel/power/user.c	2011-01-29 11:19:14.719063850 +0100
+++ longterm-2.6.27/kernel/power/user.c	2011-01-29 11:27:16.799064365 +0100
@@ -129,7 +129,7 @@
 	free_all_swap_pages(data->swap);
 	if (data->frozen)
 		thaw_processes();
-	pm_notifier_call_chain(data->mode == O_WRONLY ?
+	pm_notifier_call_chain(data->mode == O_RDONLY ?
 			PM_POST_HIBERNATION : PM_POST_RESTORE);
 	atomic_inc(&snapshot_device_available);
 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 15/23] posix-cpu-timers: workaround to suppress the problems with mt exec
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Oleg Nesterov, Linus Torvalds, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Oleg Nesterov <oleg@redhat.com>

commit e0a70217107e6f9844628120412cb27bb4cea194 upstream.

posix-cpu-timers.c correctly assumes that the dying process does
posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD
timers from signal->cpu_timers list.

But, it also assumes that timer->it.cpu.task is always the group
leader, and thus the dead ->task means the dead thread group.

This is obviously not true after de_thread() changes the leader.
After that almost every posix_cpu_timer_ method has problems.

It is not simple to fix this bug correctly. First of all, I think
that timer->it.cpu should use struct pid instead of task_struct.
Also, the locking should be reworked completely. In particular,
tasklist_lock should not be used at all. This all needs a lot of
nontrivial and hard-to-test changes.

Change __exit_signal() to do posix_cpu_timers_exit_group() when
the old leader dies during exec. This is not the fix, just the
temporary hack to hide the problem for 2.6.37 and stable. IOW,
this is obviously wrong but this is what we currently have anyway:
cpu timers do not work after mt exec.

In theory this change adds another race. The exiting leader can
detach the timers which were attached to the new leader. However,
the window between de_thread() and release_task() is small, we
can pretend that sys_timer_create() was called before de_thread().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 kernel/exit.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: longterm-2.6.27/kernel/exit.c
===================================================================
--- longterm-2.6.27.orig/kernel/exit.c	2011-01-29 11:22:46.765065209 +0100
+++ longterm-2.6.27/kernel/exit.c	2011-01-29 11:27:17.594064616 +0100
@@ -94,6 +94,14 @@
 		posix_cpu_timers_exit_group(tsk);
 	else {
 		/*
+		 * This can only happen if the caller is de_thread().
+		 * FIXME: this is the temporary hack, we should teach
+		 * posix-cpu-timers to handle this case correctly.
+		 */
+		if (unlikely(has_group_leader_pid(tsk)))
+			posix_cpu_timers_exit_group(tsk);
+
+		/*
 		 * If there is any task waiting for the group exit
 		 * then notify it:
 		 */



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 16/23] sctp: Fix a race between ICMP protocol unreachable and connect()
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Vlad Yasevich, David S. Miller, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Vlad Yasevich <vladislav.yasevich@hp.com>

commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819 upstream.

ICMP protocol unreachable handling completely disregarded
the fact that the user may have locked the socket.  It proceeded
to destroy the association, even though the user may have
held the lock and had a ref on the association.  This resulted
in the following:

Attempt to release alive inet socket f6afcc00

=========================
[ BUG: held lock freed! ]
-------------------------
somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
there!
 (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
1 lock held by somenu/2672:
 #0:  (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c

stack backtrace:
Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
Call Trace:
 [<c1232266>] ? printk+0xf/0x11
 [<c1038553>] debug_check_no_locks_freed+0xce/0xff
 [<c10620b4>] kmem_cache_free+0x21/0x66
 [<c1185f25>] __sk_free+0x9d/0xab
 [<c1185f9c>] sk_free+0x1c/0x1e
 [<c1216e38>] sctp_association_put+0x32/0x89
 [<c1220865>] __sctp_connect+0x36d/0x3f4
 [<c122098a>] ? sctp_connect+0x13/0x4c
 [<c102d073>] ? autoremove_wake_function+0x0/0x33
 [<c12209a8>] sctp_connect+0x31/0x4c
 [<c11d1e80>] inet_dgram_connect+0x4b/0x55
 [<c11834fa>] sys_connect+0x54/0x71
 [<c103a3a2>] ? lock_release_non_nested+0x88/0x239
 [<c1054026>] ? might_fault+0x42/0x7c
 [<c1054026>] ? might_fault+0x42/0x7c
 [<c11847ab>] sys_socketcall+0x6d/0x178
 [<c10da994>] ? trace_hardirqs_on_thunk+0xc/0x10
 [<c1002959>] syscall_call+0x7/0xb

This was because the sctp_wait_for_connect() would aqcure the socket
lock and then proceed to release the last reference count on the
association, thus cause the fully destruction path to finish freeing
the socket.

The simplest solution is to start a very short timer in case the socket
is owned by user.  When the timer expires, we can do some verification
and be able to do the release properly.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 include/net/sctp/sm.h      |    1 +
 include/net/sctp/structs.h |    3 +++
 net/sctp/input.c           |   22 ++++++++++++++++++----
 net/sctp/sm_sideeffect.c   |   35 +++++++++++++++++++++++++++++++++++
 net/sctp/transport.c       |    2 ++
 5 files changed, 59 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/include/net/sctp/sm.h
===================================================================
--- longterm-2.6.27.orig/include/net/sctp/sm.h	2011-01-29 11:19:14.709063960 +0100
+++ longterm-2.6.27/include/net/sctp/sm.h	2011-01-29 11:27:18.740064435 +0100
@@ -277,6 +277,7 @@
 /* 2nd level prototypes */
 void sctp_generate_t3_rtx_event(unsigned long peer);
 void sctp_generate_heartbeat_event(unsigned long peer);
+void sctp_generate_proto_unreach_event(unsigned long peer);
 
 void sctp_ootb_pkt_free(struct sctp_packet *);
 
Index: longterm-2.6.27/include/net/sctp/structs.h
===================================================================
--- longterm-2.6.27.orig/include/net/sctp/structs.h	2011-01-29 11:19:14.713065031 +0100
+++ longterm-2.6.27/include/net/sctp/structs.h	2011-01-29 11:27:18.745065220 +0100
@@ -998,6 +998,9 @@
 	/* Heartbeat timer is per destination. */
 	struct timer_list hb_timer;
 
+	/* Timer to handle ICMP proto unreachable envets */
+	struct timer_list proto_unreach_timer;
+
 	/* Since we're using per-destination retransmission timers
 	 * (see above), we're also using per-destination "transmitted"
 	 * queues.  This probably ought to be a private struct
Index: longterm-2.6.27/net/sctp/input.c
===================================================================
--- longterm-2.6.27.orig/net/sctp/input.c	2011-01-29 11:19:14.722065417 +0100
+++ longterm-2.6.27/net/sctp/input.c	2011-01-29 11:27:18.751064926 +0100
@@ -425,11 +425,25 @@
 {
 	SCTP_DEBUG_PRINTK("%s\n",  __func__);
 
-	sctp_do_sm(SCTP_EVENT_T_OTHER,
-		   SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
-		   asoc->state, asoc->ep, asoc, t,
-		   GFP_ATOMIC);
+	if (sock_owned_by_user(sk)) {
+		if (timer_pending(&t->proto_unreach_timer))
+			return;
+		else {
+			if (!mod_timer(&t->proto_unreach_timer,
+						jiffies + (HZ/20)))
+				sctp_association_hold(asoc);
+		}
 
+	} else {
+		if (timer_pending(&t->proto_unreach_timer) &&
+		    del_timer(&t->proto_unreach_timer))
+			sctp_association_put(asoc);
+
+		sctp_do_sm(SCTP_EVENT_T_OTHER,
+			   SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
+			   asoc->state, asoc->ep, asoc, t,
+			   GFP_ATOMIC);
+	}
 }
 
 /* Common lookup code for icmp/icmpv6 error handler. */
Index: longterm-2.6.27/net/sctp/sm_sideeffect.c
===================================================================
--- longterm-2.6.27.orig/net/sctp/sm_sideeffect.c	2011-01-29 11:19:14.726064976 +0100
+++ longterm-2.6.27/net/sctp/sm_sideeffect.c	2011-01-29 11:27:18.754064379 +0100
@@ -397,6 +397,41 @@
 	sctp_transport_put(transport);
 }
 
+/* Handle the timeout of the ICMP protocol unreachable timer.  Trigger
+ * the correct state machine transition that will close the association.
+ */
+void sctp_generate_proto_unreach_event(unsigned long data)
+{
+	struct sctp_transport *transport = (struct sctp_transport *) data;
+	struct sctp_association *asoc = transport->asoc;
+
+	sctp_bh_lock_sock(asoc->base.sk);
+	if (sock_owned_by_user(asoc->base.sk)) {
+		SCTP_DEBUG_PRINTK("%s:Sock is busy.\n", __func__);
+
+		/* Try again later.  */
+		if (!mod_timer(&transport->proto_unreach_timer,
+				jiffies + (HZ/20)))
+			sctp_association_hold(asoc);
+		goto out_unlock;
+	}
+
+	/* Is this structure just waiting around for us to actually
+	 * get destroyed?
+	 */
+	if (asoc->base.dead)
+		goto out_unlock;
+
+	sctp_do_sm(SCTP_EVENT_T_OTHER,
+		   SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
+		   asoc->state, asoc->ep, asoc, transport, GFP_ATOMIC);
+
+out_unlock:
+	sctp_bh_unlock_sock(asoc->base.sk);
+	sctp_association_put(asoc);
+}
+
+
 /* Inject a SACK Timeout event into the state machine.  */
 static void sctp_generate_sack_event(unsigned long data)
 {
Index: longterm-2.6.27/net/sctp/transport.c
===================================================================
--- longterm-2.6.27.orig/net/sctp/transport.c	2011-01-29 11:19:14.728063852 +0100
+++ longterm-2.6.27/net/sctp/transport.c	2011-01-29 11:27:18.758064715 +0100
@@ -107,6 +107,8 @@
 			(unsigned long)peer);
 	setup_timer(&peer->hb_timer, sctp_generate_heartbeat_event,
 			(unsigned long)peer);
+	setup_timer(&peer->proto_unreach_timer,
+		    sctp_generate_proto_unreach_event, (unsigned long)peer);
 
 	/* Initialize the 64-bit random nonce sent with heartbeat. */
 	get_random_bytes(&peer->hb_nonce, sizeof(peer->hb_nonce));



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 17/23] sound: Prevent buffer overflow in OSS load_mixer_volumes
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Dan Rosenberg, Takashi Iwai, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Dan Rosenberg <drosenberg@vsecurity.com>

commit d81a12bc29ae4038770e05dce4ab7f26fd5880fb upstream.

The load_mixer_volumes() function, which can be triggered by
unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to
a buffer overflow.  Because the provided "name" argument isn't
guaranteed to be NULL terminated at the expected 32 bytes, it's possible
to overflow past the end of the last element in the mixer_vols array.
Further exploitation can result in an arbitrary kernel write (via
subsequent calls to load_mixer_volumes()) leading to privilege
escalation, or arbitrary kernel reads via get_mixer_levels().  In
addition, the strcmp() may leak bytes beyond the mixer_vols array.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 sound/oss/soundcard.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: longterm-2.6.27/sound/oss/soundcard.c
===================================================================
--- longterm-2.6.27.orig/sound/oss/soundcard.c	2011-01-29 11:19:14.734064117 +0100
+++ longterm-2.6.27/sound/oss/soundcard.c	2011-01-29 11:27:20.586064152 +0100
@@ -87,7 +87,7 @@
 	int             i, n;
 
 	for (i = 0; i < num_mixer_volumes; i++) {
-		if (strcmp(name, mixer_vols[i].name) == 0) {
+		if (strncmp(name, mixer_vols[i].name, 32) == 0) {
 			if (present)
 				mixer_vols[i].num = i;
 			return mixer_vols[i].levels;
@@ -99,7 +99,7 @@
 	}
 	n = num_mixer_volumes++;
 
-	strcpy(mixer_vols[n].name, name);
+	strncpy(mixer_vols[n].name, name, 32);
 
 	if (present)
 		mixer_vols[n].num = n;



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 18/23] sunrpc: prevent use-after-free on clearing XPT_BUSY
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: NeilBrown, J. Bruce Fields, Greg Kroah-Hartman, Willy Tarreau

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

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

From: NeilBrown <neilb@suse.de>

commit ed2849d3ecfa339435818eeff28f6c3424300cec upstream.

When an xprt is created, it has a refcount of 1, and XPT_BUSY is set.
The refcount is *not* owned by the thread that created the xprt
(as is clear from the fact that creators never put the reference).
Rather, it is owned by the absence of XPT_DEAD.  Once XPT_DEAD is set,
(And XPT_BUSY is clear) that initial reference is dropped and the xprt
can be freed.

So when a creator clears XPT_BUSY it is dropping its only reference and
so must not touch the xprt again.

However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY
reference on a new xprt), calls svc_xprt_recieved.  This clears
XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference.
This is dangerous and has been seen to leave svc_xprt_enqueue working
with an xprt containing garbage.

So we need to hold an extra counted reference over that call to
svc_xprt_received.

For safety, any time we clear XPT_BUSY and then use the xprt again, we
first get a reference, and the put it again afterwards.

Note that svc_close_all does not need this extra protection as there are
no threads running, and the final free can only be called asynchronously
from such a thread.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 net/sunrpc/svc_xprt.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Index: longterm-2.6.27/net/sunrpc/svc_xprt.c
===================================================================
--- longterm-2.6.27.orig/net/sunrpc/svc_xprt.c	2011-01-29 11:19:14.731064813 +0100
+++ longterm-2.6.27/net/sunrpc/svc_xprt.c	2011-01-29 11:27:22.220064064 +0100
@@ -172,6 +172,7 @@
 	spin_lock(&svc_xprt_class_lock);
 	list_for_each_entry(xcl, &svc_xprt_class_list, xcl_list) {
 		struct svc_xprt *newxprt;
+		unsigned short newport;
 
 		if (strcmp(xprt_name, xcl->xcl_name))
 			continue;
@@ -192,8 +193,9 @@
 		spin_lock_bh(&serv->sv_lock);
 		list_add(&newxprt->xpt_list, &serv->sv_permsocks);
 		spin_unlock_bh(&serv->sv_lock);
+		newport = svc_xprt_local_port(newxprt);
 		clear_bit(XPT_BUSY, &newxprt->xpt_flags);
-		return svc_xprt_local_port(newxprt);
+		return newport;
 	}
  err:
 	spin_unlock(&svc_xprt_class_lock);
@@ -386,8 +388,13 @@
 {
 	BUG_ON(!test_bit(XPT_BUSY, &xprt->xpt_flags));
 	xprt->xpt_pool = NULL;
+	/* As soon as we clear busy, the xprt could be closed and
+	 * 'put', so we need a reference to call svc_xprt_enqueue with:
+	 */
+	svc_xprt_get(xprt);
 	clear_bit(XPT_BUSY, &xprt->xpt_flags);
 	svc_xprt_enqueue(xprt);
+	svc_xprt_put(xprt);
 }
 EXPORT_SYMBOL_GPL(svc_xprt_received);
 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 19/23] x86, gcc-4.6: Use gcc -m options when building vdso
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review; +Cc: H. Peter Anvin, Greg Kroah-Hartman

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

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

From: H. Peter Anvin <hpa@linux.intel.com>

commit de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream.

The vdso Makefile passes linker-style -m options not to the linker but
to gcc.  This happens to work with earlier gcc, but fails with gcc
4.6.  Pass gcc-style -m options, instead.

Note: all currently supported versions of gcc supports -m32, so there
is no reason to conditionalize it any more.

Reported-by: H. J. Lu <hjl.tools@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
LKML-Reference: <tip-*@git.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Index: longterm-2.6.27/arch/x86/vdso/Makefile
===================================================================
--- longterm-2.6.27.orig/arch/x86/vdso/Makefile	2011-01-29 11:19:14.676064283 +0100
+++ longterm-2.6.27/arch/x86/vdso/Makefile	2011-01-29 11:27:24.890063749 +0100
@@ -25,7 +25,7 @@
 
 export CPPFLAGS_vdso.lds += -P -C
 
-VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -Wl,-soname=linux-vdso.so.1 \
+VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
 		      	-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
 
 $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
@@ -69,7 +69,7 @@
 vdso32-images			= $(vdso32.so-y:%=vdso32-%.so)
 
 CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
-VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -Wl,-soname=linux-gate.so.1
+VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1
 
 # This makes sure the $(obj) subdirectory exists even though vdso32/
 # is not a kbuild sub-make subdirectory.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing
@ 2011-02-06 23:23 ` Willy Tarreau
  2011-02-14 23:14   ` [Stable-review] " Ben Hutchings
  0 siblings, 1 reply; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Slava Pestov, Steven Rostedt, Greg Kroah-Hartman, Willy Tarreau

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

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

From: Slava Pestov <slavapestov@google.com>

commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.

The file_ops struct for the "trace" special file defined llseek as seq_lseek().
However, if the file was opened for writing only, seq_open() was not called,
and the seek would dereference a null pointer, file->private_data.

This patch introduces a new wrapper for seq_lseek() which checks if the file
descriptor is opened for reading first. If not, it does nothing.

Signed-off-by: Slava Pestov <slavapestov@google.com>
LKML-Reference: <1290640396-24179-1-git-send-email-slavapestov@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[wt: applied to tracing_lt_fops too /wt]
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 kernel/trace/trace.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Index: longterm-2.6.27/kernel/trace/trace.c
===================================================================
--- longterm-2.6.27.orig/kernel/trace/trace.c	2011-01-23 10:52:37.000000000 +0100
+++ longterm-2.6.27/kernel/trace/trace.c	2011-01-29 11:42:07.287067215 +0100
@@ -2041,17 +2041,25 @@
 	return ret;
 }
 
+static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
+{
+	if (file->f_mode & FMODE_READ)
+		return seq_lseek(file, offset, origin);
+	else
+		return 0;
+}
+
 static struct file_operations tracing_fops = {
 	.open		= tracing_open,
 	.read		= seq_read,
-	.llseek		= seq_lseek,
+	.llseek		= tracing_lseek,
 	.release	= tracing_release,
 };
 
 static struct file_operations tracing_lt_fops = {
 	.open		= tracing_lt_open,
 	.read		= seq_read,
-	.llseek		= seq_lseek,
+	.llseek		= tracing_lseek,
 	.release	= tracing_release,
 };
 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove
@ 2011-02-06 23:23   ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Amit Shah, Alan Cox, linuxppc-dev, Rusty Russell,
	Greg Kroah-Hartman, Willy Tarreau

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

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

From: Amit Shah <amit.shah@redhat.com>

commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.

Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().

Alan describes it thus:

The hvc_console assumes that a close and remove call can't occur at the
same time.

In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....

So this can happen

        hvc_close                               hvc_remove
        hung up ? - no
                                                lock
                                                tty = hp->tty
                                                unlock
        lock
        hp->tty = NULL
        unlock
        notify del
        kref_put the hvc struct
        close completes
        tty is destroyed
                                                tty_hangup dead tty
                                                tty->ops will be NULL
                                                NULL->...

This patch adds some tty krefs and also converts to using tty_vhangup().

Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/char/hvc_console.c |   31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

Index: longterm-2.6.27/drivers/char/hvc_console.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/hvc_console.c	2011-01-23 10:52:15.000000000 +0100
+++ longterm-2.6.27/drivers/char/hvc_console.c	2011-01-29 15:33:05.169065818 +0100
@@ -312,6 +312,7 @@
 	spin_lock_irqsave(&hp->lock, flags);
 	/* Check and then increment for fast path open. */
 	if (hp->count++ > 0) {
+		tty_kref_get(tty);
 		spin_unlock_irqrestore(&hp->lock, flags);
 		hvc_kick();
 		return 0;
@@ -320,7 +321,7 @@
 	tty->driver_data = hp;
 	tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
 
-	hp->tty = tty;
+	hp->tty = tty_kref_get(tty);
 
 	spin_unlock_irqrestore(&hp->lock, flags);
 
@@ -337,6 +338,7 @@
 		spin_lock_irqsave(&hp->lock, flags);
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
+		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		kref_put(&hp->kref, destroy_hvc_struct);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -364,13 +366,18 @@
 		return;
 
 	hp = tty->driver_data;
+
 	spin_lock_irqsave(&hp->lock, flags);
+	tty_kref_get(tty);
 
 	if (--hp->count == 0) {
 		/* We are done with the tty pointer now. */
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
 
+		/* Put the ref obtained in hvc_open() */
+		tty_kref_put(tty);
+
 		if (hp->ops->notifier_del)
 			hp->ops->notifier_del(hp, hp->data);
 
@@ -387,6 +394,7 @@
 		spin_unlock_irqrestore(&hp->lock, flags);
 	}
 
+	tty_kref_put(tty);
 	kref_put(&hp->kref, destroy_hvc_struct);
 }
 
@@ -423,6 +431,7 @@
 
 	while(temp_open_count) {
 		--temp_open_count;
+		tty_kref_put(tty);
 		kref_put(&hp->kref, destroy_hvc_struct);
 	}
 }
@@ -550,7 +559,7 @@
 		poll_mask |= HVC_POLL_WRITE;
 
 	/* No tty attached, just skip */
-	tty = hp->tty;
+	tty = tty_kref_get(hp->tty);
 	if (tty == NULL)
 		goto bail;
 
@@ -627,6 +636,8 @@
 
 		tty_flip_buffer_push(tty);
 	}
+	if (tty)
+		tty_kref_put(tty);
 
 	return poll_mask;
 }
@@ -749,7 +760,7 @@
 	struct tty_struct *tty;
 
 	spin_lock_irqsave(&hp->lock, flags);
-	tty = hp->tty;
+	tty = tty_kref_get(hp->tty);
 
 	if (hp->index < MAX_NR_HVC_CONSOLES)
 		vtermnos[hp->index] = -1;
@@ -761,18 +772,18 @@
 	/*
 	 * We 'put' the instance that was grabbed when the kref instance
 	 * was initialized using kref_init().  Let the last holder of this
-	 * kref cause it to be removed, which will probably be the tty_hangup
+	 * kref cause it to be removed, which will probably be the tty_vhangup
 	 * below.
 	 */
 	kref_put(&hp->kref, destroy_hvc_struct);
 
 	/*
-	 * This function call will auto chain call hvc_hangup.  The tty should
-	 * always be valid at this time unless a simultaneous tty close already
-	 * cleaned up the hvc_struct.
+	 * This function call will auto chain call hvc_hangup.
 	 */
-	if (tty)
-		tty_hangup(tty);
+	if (tty) {
+		tty_vhangup(tty);
+		tty_kref_put(tty);
+	}
 	return 0;
 }
 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove
@ 2011-02-06 23:23   ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Greg Kroah-Hartman, Rusty Russell, linuxppc-dev, Amit Shah,
	Willy Tarreau, Alan Cox

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

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

From: Amit Shah <amit.shah@redhat.com>

commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.

Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().

Alan describes it thus:

The hvc_console assumes that a close and remove call can't occur at the
same time.

In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....

So this can happen

        hvc_close                               hvc_remove
        hung up ? - no
                                                lock
                                                tty = hp->tty
                                                unlock
        lock
        hp->tty = NULL
        unlock
        notify del
        kref_put the hvc struct
        close completes
        tty is destroyed
                                                tty_hangup dead tty
                                                tty->ops will be NULL
                                                NULL->...

This patch adds some tty krefs and also converts to using tty_vhangup().

Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/char/hvc_console.c |   31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

Index: longterm-2.6.27/drivers/char/hvc_console.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/hvc_console.c	2011-01-23 10:52:15.000000000 +0100
+++ longterm-2.6.27/drivers/char/hvc_console.c	2011-01-29 15:33:05.169065818 +0100
@@ -312,6 +312,7 @@
 	spin_lock_irqsave(&hp->lock, flags);
 	/* Check and then increment for fast path open. */
 	if (hp->count++ > 0) {
+		tty_kref_get(tty);
 		spin_unlock_irqrestore(&hp->lock, flags);
 		hvc_kick();
 		return 0;
@@ -320,7 +321,7 @@
 	tty->driver_data = hp;
 	tty->low_latency = 1; /* Makes flushes to ldisc synchronous. */
 
-	hp->tty = tty;
+	hp->tty = tty_kref_get(tty);
 
 	spin_unlock_irqrestore(&hp->lock, flags);
 
@@ -337,6 +338,7 @@
 		spin_lock_irqsave(&hp->lock, flags);
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
+		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		kref_put(&hp->kref, destroy_hvc_struct);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -364,13 +366,18 @@
 		return;
 
 	hp = tty->driver_data;
+
 	spin_lock_irqsave(&hp->lock, flags);
+	tty_kref_get(tty);
 
 	if (--hp->count == 0) {
 		/* We are done with the tty pointer now. */
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
 
+		/* Put the ref obtained in hvc_open() */
+		tty_kref_put(tty);
+
 		if (hp->ops->notifier_del)
 			hp->ops->notifier_del(hp, hp->data);
 
@@ -387,6 +394,7 @@
 		spin_unlock_irqrestore(&hp->lock, flags);
 	}
 
+	tty_kref_put(tty);
 	kref_put(&hp->kref, destroy_hvc_struct);
 }
 
@@ -423,6 +431,7 @@
 
 	while(temp_open_count) {
 		--temp_open_count;
+		tty_kref_put(tty);
 		kref_put(&hp->kref, destroy_hvc_struct);
 	}
 }
@@ -550,7 +559,7 @@
 		poll_mask |= HVC_POLL_WRITE;
 
 	/* No tty attached, just skip */
-	tty = hp->tty;
+	tty = tty_kref_get(hp->tty);
 	if (tty == NULL)
 		goto bail;
 
@@ -627,6 +636,8 @@
 
 		tty_flip_buffer_push(tty);
 	}
+	if (tty)
+		tty_kref_put(tty);
 
 	return poll_mask;
 }
@@ -749,7 +760,7 @@
 	struct tty_struct *tty;
 
 	spin_lock_irqsave(&hp->lock, flags);
-	tty = hp->tty;
+	tty = tty_kref_get(hp->tty);
 
 	if (hp->index < MAX_NR_HVC_CONSOLES)
 		vtermnos[hp->index] = -1;
@@ -761,18 +772,18 @@
 	/*
 	 * We 'put' the instance that was grabbed when the kref instance
 	 * was initialized using kref_init().  Let the last holder of this
-	 * kref cause it to be removed, which will probably be the tty_hangup
+	 * kref cause it to be removed, which will probably be the tty_vhangup
 	 * below.
 	 */
 	kref_put(&hp->kref, destroy_hvc_struct);
 
 	/*
-	 * This function call will auto chain call hvc_hangup.  The tty should
-	 * always be valid at this time unless a simultaneous tty close already
-	 * cleaned up the hvc_struct.
+	 * This function call will auto chain call hvc_hangup.
 	 */
-	if (tty)
-		tty_hangup(tty);
+	if (tty) {
+		tty_vhangup(tty);
+		tty_kref_put(tty);
+	}
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 22/23] hvc_console: Fix race between hvc_close and hvc_remove, again
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Anton Blanchard, Amit Shah, Rusty Russell, Greg Kroah-Hartman,
	Willy Tarreau

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

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

From: Anton Blanchard <anton@samba.org>

commit 320718ee074acce5ffced6506cb51af1388942aa upstream.

I don't claim to understand the tty layer, but it seems like hvc_open and
hvc_close should be balanced in their kref reference counting.

Right now we get a kref every call to hvc_open:

        if (hp->count++ > 0) {
                tty_kref_get(tty); <----- here
                spin_unlock_irqrestore(&hp->lock, flags);
                hvc_kick();
                return 0;
        } /* else count == 0 */

        tty->driver_data = hp;

        hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0

But hvc_close has:

        tty_kref_get(tty);

        if (--hp->count == 0) {
...
                /* Put the ref obtained in hvc_open() */
                tty_kref_put(tty);
...
        }

        tty_kref_put(tty);

Since the outside kref get/put balance we only do a single kref_put when
count reaches 0.

The patch below changes things to call tty_kref_put once for every
hvc_close call, and with that my machine boots fine.

Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 drivers/char/hvc_console.c |    4 ----
 1 file changed, 4 deletions(-)

Index: longterm-2.6.27/drivers/char/hvc_console.c
===================================================================
--- longterm-2.6.27.orig/drivers/char/hvc_console.c	2011-01-29 15:33:05.169065818 +0100
+++ longterm-2.6.27/drivers/char/hvc_console.c	2011-01-29 15:33:55.140065271 +0100
@@ -368,16 +368,12 @@
 	hp = tty->driver_data;
 
 	spin_lock_irqsave(&hp->lock, flags);
-	tty_kref_get(tty);
 
 	if (--hp->count == 0) {
 		/* We are done with the tty pointer now. */
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
 
-		/* Put the ref obtained in hvc_open() */
-		tty_kref_put(tty);
-
 		if (hp->ops->notifier_del)
 			hp->ops->notifier_del(hp, hp->data);
 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 23/23] install_special_mapping skips security_file_mmap check.
@ 2011-02-06 23:23 ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-06 23:23 UTC (permalink / raw)
  To: linux-kernel, stable, stable-review
  Cc: Tavis Ormandy, Kees Cook, Robert Swiecki, Linus Torvalds,
	Greg Kroah-Hartman, Willy Tarreau

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

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

From: Tavis Ormandy <taviso@cmpxchg8b.com>

commit 462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream.

The install_special_mapping routine (used, for example, to setup the
vdso) skips the security check before insert_vm_struct, allowing a local
attacker to bypass the mmap_min_addr security restriction by limiting
the available pages for special mappings.

bprm_mm_init() also skips the check, and although I don't think this can
be used to bypass any restrictions, I don't see any reason not to have
the security check.

  $ uname -m
  x86_64
  $ cat /proc/sys/vm/mmap_min_addr
  65536
  $ cat install_special_mapping.s
  section .bss
      resb BSS_SIZE
  section .text
      global _start
      _start:
          mov     eax, __NR_pause
          int     0x80
  $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
  $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
  $ ./install_special_mapping &
  [1] 14303
  $ cat /proc/14303/maps
  0000f000-00010000 r-xp 00000000 00:00 0                                  [vdso]
  00010000-00011000 r-xp 00001000 00:19 2453665                            /home/taviso/install_special_mapping
  00011000-ffffe000 rwxp 00000000 00:00 0                                  [stack]

It's worth noting that Red Hat are shipping with mmap_min_addr set to
4096.

Signed-off-by: Tavis Ormandy <taviso@google.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Robert Swiecki <swiecki@google.com>
[ Changed to not drop the error code - akpm ]
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>

---
 fs/exec.c |    5 +++++
 mm/mmap.c |   16 ++++++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

Index: longterm-2.6.27/fs/exec.c
===================================================================
--- longterm-2.6.27.orig/fs/exec.c	2011-01-29 11:22:46.000000000 +0100
+++ longterm-2.6.27/fs/exec.c	2011-01-29 15:36:13.479064083 +0100
@@ -257,6 +257,11 @@
 
 	vma->vm_flags = VM_STACK_FLAGS;
 	vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+
+	err = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1);
+	if (err)
+		goto err;
+
 	err = insert_vm_struct(mm, vma);
 	if (err) {
 		up_write(&mm->mmap_sem);
Index: longterm-2.6.27/mm/mmap.c
===================================================================
--- longterm-2.6.27.orig/mm/mmap.c	2011-01-29 11:22:46.000000000 +0100
+++ longterm-2.6.27/mm/mmap.c	2011-01-29 15:38:47.368066702 +0100
@@ -2253,6 +2253,7 @@
 			    unsigned long addr, unsigned long len,
 			    unsigned long vm_flags, struct page **pages)
 {
+	int ret;
 	struct vm_area_struct *vma;
 
 	vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
@@ -2269,14 +2270,21 @@
 	vma->vm_ops = &special_mapping_vmops;
 	vma->vm_private_data = pages;
 
-	if (unlikely(insert_vm_struct(mm, vma))) {
-		kmem_cache_free(vm_area_cachep, vma);
-		return -ENOMEM;
-	}
+	ret = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1);
+	if (ret)
+		goto out;
+
+	ret = insert_vm_struct(mm, vma);
+	if (ret)
+		goto out;
 
 	mm->total_vm += len >> PAGE_SHIFT;
 
 	return 0;
+
+out:
+	kmem_cache_free(vm_area_cachep, vma);
+	return ret;
 }
 
 static DEFINE_MUTEX(mm_all_locks_mutex);



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove
  2011-02-06 23:23   ` Willy Tarreau
@ 2011-02-07 21:16     ` Anton Blanchard
  -1 siblings, 0 replies; 34+ messages in thread
From: Anton Blanchard @ 2011-02-07 21:16 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: linux-kernel, stable, stable-review, Greg Kroah-Hartman,
	Rusty Russell, linuxppc-dev, Amit Shah, Alan Cox


Hi,

> From: Amit Shah <amit.shah@redhat.com>
> 
> commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
> 
> Alan pointed out a race in the code where hvc_remove is invoked. The
> recent virtio_console work is the first user of hvc_remove().

I faintly remember this bug caused boot issues and the following patch
must be applied to fix it.

Anton
--

commit 320718ee074acce5ffced6506cb51af1388942aa
Author: Anton Blanchard <anton@samba.org>
Date:   Tue Apr 6 21:42:38 2010 +1000

    hvc_console: Fix race between hvc_close and hvc_remove
    
    I don't claim to understand the tty layer, but it seems like hvc_open and
    hvc_close should be balanced in their kref reference counting.
    
    Right now we get a kref every call to hvc_open:
    
            if (hp->count++ > 0) {
                    tty_kref_get(tty); <----- here
                    spin_unlock_irqrestore(&hp->lock, flags);
                    hvc_kick();
                    return 0;
            } /* else count == 0 */
    
            tty->driver_data = hp;
    
            hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0
    
    But hvc_close has:
    
            tty_kref_get(tty);
    
            if (--hp->count == 0) {
    ...
                    /* Put the ref obtained in hvc_open() */
                    tty_kref_put(tty);
    ...
            }
    
            tty_kref_put(tty);
    
    Since the outside kref get/put balance we only do a single kref_put when
    count reaches 0.
    
    The patch below changes things to call tty_kref_put once for every
    hvc_close call, and with that my machine boots fine.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d3890e8..35cca4c 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -368,16 +368,12 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 	hp = tty->driver_data;
 
 	spin_lock_irqsave(&hp->lock, flags);
-	tty_kref_get(tty);
 
 	if (--hp->count == 0) {
 		/* We are done with the tty pointer now. */
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
 
-		/* Put the ref obtained in hvc_open() */
-		tty_kref_put(tty);
-
 		if (hp->ops->notifier_del)
 			hp->ops->notifier_del(hp, hp->data);
 

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove
@ 2011-02-07 21:16     ` Anton Blanchard
  0 siblings, 0 replies; 34+ messages in thread
From: Anton Blanchard @ 2011-02-07 21:16 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Rusty Russell, Greg Kroah-Hartman, linux-kernel, stable,
	linuxppc-dev, Amit Shah, stable-review, Alan Cox


Hi,

> From: Amit Shah <amit.shah@redhat.com>
> 
> commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
> 
> Alan pointed out a race in the code where hvc_remove is invoked. The
> recent virtio_console work is the first user of hvc_remove().

I faintly remember this bug caused boot issues and the following patch
must be applied to fix it.

Anton
--

commit 320718ee074acce5ffced6506cb51af1388942aa
Author: Anton Blanchard <anton@samba.org>
Date:   Tue Apr 6 21:42:38 2010 +1000

    hvc_console: Fix race between hvc_close and hvc_remove
    
    I don't claim to understand the tty layer, but it seems like hvc_open and
    hvc_close should be balanced in their kref reference counting.
    
    Right now we get a kref every call to hvc_open:
    
            if (hp->count++ > 0) {
                    tty_kref_get(tty); <----- here
                    spin_unlock_irqrestore(&hp->lock, flags);
                    hvc_kick();
                    return 0;
            } /* else count == 0 */
    
            tty->driver_data = hp;
    
            hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0
    
    But hvc_close has:
    
            tty_kref_get(tty);
    
            if (--hp->count == 0) {
    ...
                    /* Put the ref obtained in hvc_open() */
                    tty_kref_put(tty);
    ...
            }
    
            tty_kref_put(tty);
    
    Since the outside kref get/put balance we only do a single kref_put when
    count reaches 0.
    
    The patch below changes things to call tty_kref_put once for every
    hvc_close call, and with that my machine boots fine.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d3890e8..35cca4c 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -368,16 +368,12 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 	hp = tty->driver_data;
 
 	spin_lock_irqsave(&hp->lock, flags);
-	tty_kref_get(tty);
 
 	if (--hp->count == 0) {
 		/* We are done with the tty pointer now. */
 		hp->tty = NULL;
 		spin_unlock_irqrestore(&hp->lock, flags);
 
-		/* Put the ref obtained in hvc_open() */
-		tty_kref_put(tty);
-
 		if (hp->ops->notifier_del)
 			hp->ops->notifier_del(hp, hp->data);
 

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove
  2011-02-07 21:16     ` Anton Blanchard
@ 2011-02-07 22:11       ` Willy Tarreau
  -1 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-07 22:11 UTC (permalink / raw)
  To: Anton Blanchard
  Cc: linux-kernel, stable, stable-review, Greg Kroah-Hartman,
	Rusty Russell, linuxppc-dev, Amit Shah, Alan Cox

Hi Anton,

On Tue, Feb 08, 2011 at 08:16:00AM +1100, Anton Blanchard wrote:
> 
> Hi,
> 
> > From: Amit Shah <amit.shah@redhat.com>
> > 
> > commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
> > 
> > Alan pointed out a race in the code where hvc_remove is invoked. The
> > recent virtio_console work is the first user of hvc_remove().
> 
> I faintly remember this bug caused boot issues and the following patch
> must be applied to fix it.

The patch you pointed was indeed merged just after this one so we should
be OK. Thanks very much for the double check !

Willy


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove
@ 2011-02-07 22:11       ` Willy Tarreau
  0 siblings, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-07 22:11 UTC (permalink / raw)
  To: Anton Blanchard
  Cc: Rusty Russell, Greg Kroah-Hartman, linux-kernel, stable,
	linuxppc-dev, Amit Shah, stable-review, Alan Cox

Hi Anton,

On Tue, Feb 08, 2011 at 08:16:00AM +1100, Anton Blanchard wrote:
> 
> Hi,
> 
> > From: Amit Shah <amit.shah@redhat.com>
> > 
> > commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
> > 
> > Alan pointed out a race in the code where hvc_remove is invoked. The
> > recent virtio_console work is the first user of hvc_remove().
> 
> I faintly remember this bug caused boot issues and the following patch
> must be applied to fix it.

The patch you pointed was indeed merged just after this one so we should
be OK. Thanks very much for the double check !

Willy

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Stable-review] [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing
  2011-02-06 23:23 ` [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing Willy Tarreau
@ 2011-02-14 23:14   ` Ben Hutchings
  2011-02-15  1:33     ` Steven Rostedt
  2011-02-15  5:39     ` Willy Tarreau
  0 siblings, 2 replies; 34+ messages in thread
From: Ben Hutchings @ 2011-02-14 23:14 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: linux-kernel, stable, stable-review, Slava Pestov,
	Greg Kroah-Hartman, Steven Rostedt

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On Mon, 2011-02-07 at 00:23 +0100, Willy Tarreau wrote:
> 2.6.27.58-stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Slava Pestov <slavapestov@google.com>
> 
> commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
> 
> The file_ops struct for the "trace" special file defined llseek as seq_lseek().
> However, if the file was opened for writing only, seq_open() was not called,
> and the seek would dereference a null pointer, file->private_data.
> 
> This patch introduces a new wrapper for seq_lseek() which checks if the file
> descriptor is opened for reading first. If not, it does nothing.
[...]
> --- longterm-2.6.27.orig/kernel/trace/trace.c	2011-01-23 10:52:37.000000000 +0100
> +++ longterm-2.6.27/kernel/trace/trace.c	2011-01-29 11:42:07.287067215 +0100
> @@ -2041,17 +2041,25 @@
>  	return ret;
>  }
>  
> +static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
[...]
> +	.llseek		= tracing_lseek,
[...]
> +	.llseek		= tracing_lseek,
[...]

These names don't agree!

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Stable-review] [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing
  2011-02-14 23:14   ` [Stable-review] " Ben Hutchings
@ 2011-02-15  1:33     ` Steven Rostedt
  2011-02-15  1:38       ` Ben Hutchings
  2011-02-15  5:39     ` Willy Tarreau
  1 sibling, 1 reply; 34+ messages in thread
From: Steven Rostedt @ 2011-02-15  1:33 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: Willy Tarreau, linux-kernel, stable, stable-review, Slava Pestov,
	Greg Kroah-Hartman

On Mon, 2011-02-14 at 23:14 +0000, Ben Hutchings wrote:
> On Mon, 2011-02-07 at 00:23 +0100, Willy Tarreau wrote:
> > 2.6.27.58-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Slava Pestov <slavapestov@google.com>
> > 
> > commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
> > 
> > The file_ops struct for the "trace" special file defined llseek as seq_lseek().
> > However, if the file was opened for writing only, seq_open() was not called,
> > and the seek would dereference a null pointer, file->private_data.
> > 
> > This patch introduces a new wrapper for seq_lseek() which checks if the file
> > descriptor is opened for reading first. If not, it does nothing.
> [...]
> > --- longterm-2.6.27.orig/kernel/trace/trace.c	2011-01-23 10:52:37.000000000 +0100
> > +++ longterm-2.6.27/kernel/trace/trace.c	2011-01-29 11:42:07.287067215 +0100
> > @@ -2041,17 +2041,25 @@
> >  	return ret;
> >  }
> >  
> > +static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
> [...]
> > +	.llseek		= tracing_lseek,
> [...]
> > +	.llseek		= tracing_lseek,
> [...]
> 
> These names don't agree!

What don't they agree on?

-- Steve



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Stable-review] [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing
  2011-02-15  1:33     ` Steven Rostedt
@ 2011-02-15  1:38       ` Ben Hutchings
  2011-02-15  2:01         ` Steven Rostedt
  0 siblings, 1 reply; 34+ messages in thread
From: Ben Hutchings @ 2011-02-15  1:38 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Willy Tarreau, linux-kernel, stable, stable-review, Slava Pestov,
	Greg Kroah-Hartman

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

On Mon, 2011-02-14 at 20:33 -0500, Steven Rostedt wrote:
> On Mon, 2011-02-14 at 23:14 +0000, Ben Hutchings wrote:
> > On Mon, 2011-02-07 at 00:23 +0100, Willy Tarreau wrote:
> > > 2.6.27.58-stable review patch.  If anyone has any objections, please let us know.
> > > 
> > > ------------------
> > > 
> > > From: Slava Pestov <slavapestov@google.com>
> > > 
> > > commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
> > > 
> > > The file_ops struct for the "trace" special file defined llseek as seq_lseek().
> > > However, if the file was opened for writing only, seq_open() was not called,
> > > and the seek would dereference a null pointer, file->private_data.
> > > 
> > > This patch introduces a new wrapper for seq_lseek() which checks if the file
> > > descriptor is opened for reading first. If not, it does nothing.
> > [...]
> > > --- longterm-2.6.27.orig/kernel/trace/trace.c	2011-01-23 10:52:37.000000000 +0100
> > > +++ longterm-2.6.27/kernel/trace/trace.c	2011-01-29 11:42:07.287067215 +0100
> > > @@ -2041,17 +2041,25 @@
> > >  	return ret;
> > >  }
> > >  
> > > +static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
> > [...]
> > > +	.llseek		= tracing_lseek,
> > [...]
> > > +	.llseek		= tracing_lseek,
> > [...]
> > 
> > These names don't agree!
> 
> What don't they agree on?

Whether seek is spelt with an 'l'...

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Stable-review] [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing
  2011-02-15  1:38       ` Ben Hutchings
@ 2011-02-15  2:01         ` Steven Rostedt
  0 siblings, 0 replies; 34+ messages in thread
From: Steven Rostedt @ 2011-02-15  2:01 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: Willy Tarreau, linux-kernel, stable, stable-review, Slava Pestov,
	Greg Kroah-Hartman

On Tue, 2011-02-15 at 01:38 +0000, Ben Hutchings wrote:
> On Mon, 2011-02-14 at 20:33 -0500, Steven Rostedt wrote:
> > On Mon, 2011-02-14 at 23:14 +0000, Ben Hutchings wrote:
> > > On Mon, 2011-02-07 at 00:23 +0100, Willy Tarreau wrote:
> > > > 2.6.27.58-stable review patch.  If anyone has any objections, please let us know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Slava Pestov <slavapestov@google.com>
> > > > 
> > > > commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
> > > > 
> > > > The file_ops struct for the "trace" special file defined llseek as seq_lseek().
> > > > However, if the file was opened for writing only, seq_open() was not called,
> > > > and the seek would dereference a null pointer, file->private_data.
> > > > 
> > > > This patch introduces a new wrapper for seq_lseek() which checks if the file
> > > > descriptor is opened for reading first. If not, it does nothing.
> > > [...]
> > > > --- longterm-2.6.27.orig/kernel/trace/trace.c	2011-01-23 10:52:37.000000000 +0100
> > > > +++ longterm-2.6.27/kernel/trace/trace.c	2011-01-29 11:42:07.287067215 +0100
> > > > @@ -2041,17 +2041,25 @@
> > > >  	return ret;
> > > >  }
> > > >  
> > > > +static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
> > > [...]
> > > > +	.llseek		= tracing_lseek,
> > > [...]
> > > > +	.llseek		= tracing_lseek,
> > > [...]
> > > 
> > > These names don't agree!
> > 
> > What don't they agree on?
> 
> Whether seek is spelt with an 'l'...

Ah, I was looking at the two .llseek lines ;)

Yeah, in mainline it's just tracing_seek.

-- Steve



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Stable-review] [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing
  2011-02-14 23:14   ` [Stable-review] " Ben Hutchings
  2011-02-15  1:33     ` Steven Rostedt
@ 2011-02-15  5:39     ` Willy Tarreau
  1 sibling, 0 replies; 34+ messages in thread
From: Willy Tarreau @ 2011-02-15  5:39 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: linux-kernel, stable, stable-review, Slava Pestov,
	Greg Kroah-Hartman, Steven Rostedt

Hi Ben,

On Mon, Feb 14, 2011 at 11:14:27PM +0000, Ben Hutchings wrote:
> On Mon, 2011-02-07 at 00:23 +0100, Willy Tarreau wrote:
> > 2.6.27.58-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Slava Pestov <slavapestov@google.com>
> > 
> > commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
> > 
> > The file_ops struct for the "trace" special file defined llseek as seq_lseek().
> > However, if the file was opened for writing only, seq_open() was not called,
> > and the seek would dereference a null pointer, file->private_data.
> > 
> > This patch introduces a new wrapper for seq_lseek() which checks if the file
> > descriptor is opened for reading first. If not, it does nothing.
> [...]
> > --- longterm-2.6.27.orig/kernel/trace/trace.c	2011-01-23 10:52:37.000000000 +0100
> > +++ longterm-2.6.27/kernel/trace/trace.c	2011-01-29 11:42:07.287067215 +0100
> > @@ -2041,17 +2041,25 @@
> >  	return ret;
> >  }
> >  
> > +static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
> [...]
> > +	.llseek		= tracing_lseek,
> [...]
> > +	.llseek		= tracing_lseek,
> [...]
> 
> These names don't agree!

Indeed, it's been fixed before releasing.
Thanks for the review anyway !

Willy


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2011-02-15  5:39 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-06 23:22 [PATCH 00/23] 2.6.27.58-longterm review Willy Tarreau
2011-02-06 23:22 ` Willy Tarreau
2011-02-06 23:22 ` [PATCH 01/23] ALSA: hda: Use model=lg quirk for LG P1 Express to enable playback and capture Willy Tarreau
2011-02-06 23:22 ` [PATCH 02/23] ALSA: hda: Use LPIB for Dell Latitude 131L Willy Tarreau
2011-02-06 23:22 ` [PATCH 03/23] ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120 Willy Tarreau
2011-02-06 23:22 ` [PATCH 04/23] USB: usb-storage: unusual_devs entry for the Samsung YP-CP3 Willy Tarreau
2011-02-06 23:22 ` [PATCH 05/23] USB: misc: uss720.c: add another vendor/product ID Willy Tarreau
2011-02-06 23:22 ` [PATCH 06/23] HID: hidraw: fix window in hidraw_release Willy Tarreau
2011-02-06 23:22 ` [PATCH 07/23] hwmon: (adm1026) Allow 1 as a valid divider value Willy Tarreau
2011-02-06 23:23 ` [PATCH 08/23] hwmon: (adm1026) Fix setting fan_div Willy Tarreau
2011-02-06 23:23 ` [PATCH 09/23] IB/uverbs: Handle large number of entries in poll CQ Willy Tarreau
2011-02-06 23:23 ` [PATCH 10/23] mv_xor: fix race in tasklet function Willy Tarreau
2011-02-06 23:23 ` [PATCH 11/23] md: fix bug with re-adding of partially recovered device Willy Tarreau
2011-02-06 23:23 ` [PATCH 12/23] NFS: Fix fcntl F_GETLK not reporting some conflicts Willy Tarreau
2011-02-06 23:23 ` [PATCH 13/23] nfsd: Fix possible BUG_ON firing in set_change_info Willy Tarreau
2011-02-06 23:23 ` [PATCH 14/23] PM / Hibernate: Fix PM_POST_* notification with user-space suspend Willy Tarreau
2011-02-06 23:23 ` [PATCH 15/23] posix-cpu-timers: workaround to suppress the problems with mt exec Willy Tarreau
2011-02-06 23:23 ` [PATCH 16/23] sctp: Fix a race between ICMP protocol unreachable and connect() Willy Tarreau
2011-02-06 23:23 ` [PATCH 17/23] sound: Prevent buffer overflow in OSS load_mixer_volumes Willy Tarreau
2011-02-06 23:23 ` [PATCH 18/23] sunrpc: prevent use-after-free on clearing XPT_BUSY Willy Tarreau
2011-02-06 23:23 ` [PATCH 19/23] x86, gcc-4.6: Use gcc -m options when building vdso Willy Tarreau
2011-02-06 23:23 ` [PATCH 20/23] tracing: Fix panic when lseek() called on "trace" opened for writing Willy Tarreau
2011-02-14 23:14   ` [Stable-review] " Ben Hutchings
2011-02-15  1:33     ` Steven Rostedt
2011-02-15  1:38       ` Ben Hutchings
2011-02-15  2:01         ` Steven Rostedt
2011-02-15  5:39     ` Willy Tarreau
2011-02-06 23:23 ` [PATCH 21/23] hvc_console: Fix race between hvc_close and hvc_remove Willy Tarreau
2011-02-06 23:23   ` Willy Tarreau
2011-02-07 21:16   ` Anton Blanchard
2011-02-07 21:16     ` Anton Blanchard
2011-02-07 22:11     ` Willy Tarreau
2011-02-07 22:11       ` Willy Tarreau
2011-02-06 23:23 ` [PATCH 22/23] hvc_console: Fix race between hvc_close and hvc_remove, again Willy Tarreau
2011-02-06 23:23 ` [PATCH 23/23] install_special_mapping skips security_file_mmap check Willy Tarreau

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.