Skip to contentSkip to conversation

2.6.32.58-longterm review

PATCH In review Greg KH 5 participants 42 messages Mar 1, 2012 – Mar 7, 2012

Subsystems (28)
lore
Share & tools
lore

Greg KH

author maintainer
#0 lore raw

cover 2.6.32.58-longterm review

NOTE:
I have NOT tested this rc release. I now no longer own any machines that can run the 2.6.32 kernel. Because of this, this will be the last 2.6.32-longterm kernel that I will release. I will be passing on the .32 kernel to someone else after this release. Please, if you care about the .32 kernel, test this release, I have _only_ build tested it, and have no idea if I got something wrong or not.

This is the start of the longterm review cycle for the 2.6.32.58 release. There are 34 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 me know.

Responses should be made by Sat Mar 3 21:39:21 UTC 2012. 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.58-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

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

 Makefile                                |    2 +-
 arch/arm/include/asm/assembler.h        |    5 ++
 arch/arm/mm/cache-v7.S                  |    6 ++
 arch/s390/include/asm/compat.h          |    7 --
 arch/s390/kernel/process.c              |    1 -
 arch/s390/kernel/ptrace.c               |    2 +-
 arch/s390/kernel/setup.c                |    2 +-
 arch/s390/mm/mmap.c                     |    2 +-
 crypto/sha512_generic.c                 |   83 +++++++++++--------------
 drivers/base/firmware_class.c           |   12 +++-
 drivers/cdrom/cdrom.c                   |    8 +--
 drivers/gpu/drm/i915/intel_lvds.c       |    8 +++
 drivers/gpu/drm/radeon/r100.c           |    4 +-
 drivers/gpu/drm/radeon/rs600.c          |    4 +-
 drivers/hwmon/f75375s.c                 |    4 +-
 drivers/media/video/hdpvr/hdpvr-video.c |    3 +-
 drivers/s390/block/dasd_eckd.c          |    1 +
 drivers/s390/block/dasd_ioctl.c         |    1 +
 drivers/s390/char/fs3270.c              |    1 +
 drivers/s390/char/vmcp.c                |    1 +
 drivers/s390/cio/chsc_sch.c             |    1 +
 drivers/s390/scsi/zfcp_cfdc.c           |    1 +
 drivers/scsi/3w-9xxx.c                  |   11 ++-
 drivers/usb/host/pci-quirks.c           |   11 +++
 drivers/usb/host/xhci-mem.c             |   32 +++++++---
 drivers/usb/serial/cp210x.c             |    2 +
 fs/autofs4/autofs_i.h                   |    1 +
 fs/autofs4/dev-ioctl.c                  |    1 +
 fs/autofs4/inode.c                      |    2 +
 fs/autofs4/waitq.c                      |   22 ++++++-
 fs/ecryptfs/file.c                      |    2 +-
 fs/ecryptfs/inode.c                     |  103 +++++++++++++++++++++----------
 fs/ecryptfs/main.c                      |   38 ++++++++++--
 include/linux/bitops.h                  |   20 ++++++
 include/linux/compat.h                  |    4 +
 include/linux/kernel.h                  |   15 ++---
 include/linux/kmod.h                    |    9 +++
 include/linux/proportions.h             |    4 +
 kernel/kmod.c                           |   33 ++++++++++-
 kernel/relay.c                          |   10 +++-
 net/mac80211/rx.c                       |    2 +-
 41 files changed, 338 insertions(+), 143 deletions(-)
author maintainer
#1 lore raw

PATCH 1/34 drm/i915: no lvds quirk for AOpen MP45

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

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

From: Daniel Vetter <[email protected]>

commit e57b6886f555ab57f40a01713304e2053efe51ec upstream.

According to a bug report, it doesn't have one.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263

---
 drivers/gpu/drm/i915/intel_lvds.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +8 -0
@@ -892,6 +892,14 @@ static const struct dmi_system_id intel_
 	},
 	{
 		.callback = intel_no_lvds_dmi_callback,
+                .ident = "AOpen i45GMx-I",
+                .matches = {
+                        DMI_MATCH(DMI_BOARD_VENDOR, "AOpen"),
+                        DMI_MATCH(DMI_BOARD_NAME, "i45GMx-I"),
+                },
+        },
+	{
+		.callback = intel_no_lvds_dmi_callback,
 		.ident = "Aopen i945GTt-VFA",
 		.matches = {
 			DMI_MATCH(DMI_PRODUCT_VERSION, "AO00001JW"),
author maintainer
#2 lore raw

PATCH 2/34 hwmon: (f75375s) Fix bit shifting in f75375_write16

In reply to Greg KH

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

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

From: Nikolaus Schulz <[email protected]>

commit eb2f255b2d360df3f500042a2258dcf2fcbe89a2 upstream.

In order to extract the high byte of the 16-bit word, shift the word to the right, not to the left.

---
 drivers/hwmon/f75375s.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/f75375s.c +1 -1
@@ -159,7 +159,7 @@ static inline void f75375_write8(struct
 static inline void f75375_write16(struct i2c_client *client, u8 reg,
 		u16 value)
 {
-	int err = i2c_smbus_write_byte_data(client, reg, (value << 8));
+	int err = i2c_smbus_write_byte_data(client, reg, (value >> 8));
 	if (err)
 		return;
 	i2c_smbus_write_byte_data(client, reg + 1, (value & 0xFF));
author maintainer
#3 lore raw

PATCH 3/34 lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

In reply to Greg KH

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

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

From: Wu Fengguang <[email protected]>

commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit():

	bdi_dirty *= numerator;
	do_div(bdi_dirty, denominator);

1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty

---
 include/linux/proportions.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/proportions.h +4 -0
@@ -81,7 +81,11 @@ void prop_inc_percpu(struct prop_descrip
  * Limit the time part in order to ensure there are some bits left for the
  * cycle counter and fraction multiply.
  */
+#if BITS_PER_LONG == 32
 #define PROP_MAX_SHIFT (3*BITS_PER_LONG/4)
+#else
+#define PROP_MAX_SHIFT (BITS_PER_LONG/2)
+#endif
 
 #define PROP_FRAC_SHIFT		(BITS_PER_LONG - PROP_MAX_SHIFT - 1)
 #define PROP_FRAC_BASE		(1UL << PROP_FRAC_SHIFT)
reviewer
#4 lore raw

Re: [ 03/34] lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

Quoted 1 line · Greg KH

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

Not that I'd see anything wrong with this patch for 2.6.32. But it is
also unnecessary since the code which was triggering the overflow does not exist in 2.6.32. So maybe just on the grounds of not applying unneeded patchs I'd skip this one.

Honza

Quoted 50 lines

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

From: Wu Fengguang <[email protected]>

commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit():

	bdi_dirty *= numerator;
	do_div(bdi_dirty, denominator);

1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty

---
 include/linux/proportions.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/proportions.h +4 -1
@@ -81,7 +81,11 @@ void prop_inc_percpu(struct prop_descrip
  * Limit the time part in order to ensure there are some bits left for the
  * cycle counter and fraction multiply.
  */
+#if BITS_PER_LONG == 32
 #define PROP_MAX_SHIFT (3*BITS_PER_LONG/4)
+#else
+#define PROP_MAX_SHIFT (BITS_PER_LONG/2)
+#endif
 
 #define PROP_FRAC_SHIFT		(BITS_PER_LONG - PROP_MAX_SHIFT - 1)
 #define PROP_FRAC_BASE		(1UL << PROP_FRAC_SHIFT)
 
 
--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR
#5 lore raw

Re: [ 03/34] lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

Quoted 6 lines · Jan Kara
Quoted 1 line · Greg KH

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

Not that I'd see anything wrong with this patch for 2.6.32. But it is
also unnecessary since the code which was triggering the overflow does not exist in 2.6.32. So maybe just on the grounds of not applying unneeded patchs I'd skip this one.

FYI I never see this divide error for pre-3.2 kernels. However I've run into problem (2) before 3.2 which makes bdi dirty threshold go wild. So it seems safer to go with this patch.

To be frank the boxes that run into bugs (1) or (2) do not have Terabytes of memory to create the big shift value in calc_period_shift() which is the sufficient condition for triggering the bugs as described in the below changelog. However the bugs do magically go away with the patch applied. Perhaps this patch breaks one necessary condition for triggering the bugs in a small memory box.

Thanks,
Fengguang

Quoted 52 lines
Quoted 49 lines

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

From: Wu Fengguang <[email protected]>

commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit():

	bdi_dirty *= numerator;
	do_div(bdi_dirty, denominator);

1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty

---
 include/linux/proportions.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/proportions.h +4 -1
@@ -81,7 +81,11 @@ void prop_inc_percpu(struct prop_descrip
  * Limit the time part in order to ensure there are some bits left for the
  * cycle counter and fraction multiply.
  */
+#if BITS_PER_LONG == 32
 #define PROP_MAX_SHIFT (3*BITS_PER_LONG/4)
+#else
+#define PROP_MAX_SHIFT (BITS_PER_LONG/2)
+#endif
 
 #define PROP_FRAC_SHIFT		(BITS_PER_LONG - PROP_MAX_SHIFT - 1)
 #define PROP_FRAC_BASE		(1UL << PROP_FRAC_SHIFT)
 
 
--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR
reviewer
#6 lore raw

Re: [ 03/34] lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

Quoted 12 lines · Wu Fengguang
Quoted 6 lines · Jan Kara
Quoted 1 line · Greg KH

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

Not that I'd see anything wrong with this patch for 2.6.32. But it is
also unnecessary since the code which was triggering the overflow does not exist in 2.6.32. So maybe just on the grounds of not applying unneeded patchs I'd skip this one.

FYI I never see this divide error for pre-3.2 kernels. However I've run into problem (2) before 3.2 which makes bdi dirty threshold go wild. So it seems safer to go with this patch.

Quoted 6 lines

To be frank the boxes that run into bugs (1) or (2) do not have Terabytes of memory to create the big shift value in calc_period_shift() which is the sufficient condition for triggering the bugs as described in the below changelog. However the bugs do magically go away with the patch applied. Perhaps this patch breaks one necessary condition for triggering the bugs in a small memory box.

The patch went in -stable kernel so this is mostly an academic discussion
but Documentation/stable_kernel_rules.txt says among other things:
- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.

This patch simply didn't pass these two conditions for me for 2.6.32 and
your arguments didn't convince me it's a critical thing either...

Honza

Quoted 57 lines
Quoted 44 lines
Quoted 44 lines

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

From: Wu Fengguang <[email protected]>

commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit():

	bdi_dirty *= numerator;
	do_div(bdi_dirty, denominator);

1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty

---
 include/linux/proportions.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/proportions.h +4 -0
@@ -81,7 +81,11 @@ void prop_inc_percpu(struct prop_descrip
  * Limit the time part in order to ensure there are some bits left for the
  * cycle counter and fraction multiply.
  */
+#if BITS_PER_LONG == 32
 #define PROP_MAX_SHIFT (3*BITS_PER_LONG/4)
+#else
+#define PROP_MAX_SHIFT (BITS_PER_LONG/2)
+#endif
 
 #define PROP_FRAC_SHIFT		(BITS_PER_LONG - PROP_MAX_SHIFT - 1)
 #define PROP_FRAC_BASE		(1UL << PROP_FRAC_SHIFT)
Quoted 8 lines
Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR
#7 lore raw

Re: [ 03/34] lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

Quoted 28 lines · Jan Kara
Quoted 12 lines · Wu Fengguang
Quoted 6 lines · Jan Kara
Quoted 1 line · Greg KH

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

Not that I'd see anything wrong with this patch for 2.6.32. But it is
also unnecessary since the code which was triggering the overflow does not exist in 2.6.32. So maybe just on the grounds of not applying unneeded patchs I'd skip this one.

FYI I never see this divide error for pre-3.2 kernels. However I've run into problem (2) before 3.2 which makes bdi dirty threshold go wild. So it seems safer to go with this patch.

Quoted 6 lines

To be frank the boxes that run into bugs (1) or (2) do not have Terabytes of memory to create the big shift value in calc_period_shift() which is the sufficient condition for triggering the bugs as described in the below changelog. However the bugs do magically go away with the patch applied. Perhaps this patch breaks one necessary condition for triggering the bugs in a small memory box.

The patch went in -stable kernel so this is mostly an academic discussion
but Documentation/stable_kernel_rules.txt says among other things:
- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.

Quoted 2 lines

This patch simply didn't pass these two conditions for me for 2.6.32 and
your arguments didn't convince me it's a critical thing either...

I see the point. We need *demonstrated* critical bugs for pushing the fix to -stable.

By this criterion, I agree that there are no strong reasons for including this patch in -stable.

Thanks,
Fengguang

Quoted 62 lines

Honza

Quoted 57 lines
Quoted 44 lines
Quoted 44 lines

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

From: Wu Fengguang <[email protected]>

commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit():

	bdi_dirty *= numerator;
	do_div(bdi_dirty, denominator);

1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty

---
 include/linux/proportions.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/proportions.h +4 -0
@@ -81,7 +81,11 @@ void prop_inc_percpu(struct prop_descrip
  * Limit the time part in order to ensure there are some bits left for the
  * cycle counter and fraction multiply.
  */
+#if BITS_PER_LONG == 32
 #define PROP_MAX_SHIFT (3*BITS_PER_LONG/4)
+#else
+#define PROP_MAX_SHIFT (BITS_PER_LONG/2)
+#endif
 
 #define PROP_FRAC_SHIFT		(BITS_PER_LONG - PROP_MAX_SHIFT - 1)
 #define PROP_FRAC_BASE		(1UL << PROP_FRAC_SHIFT)
Quoted 8 lines
Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR
author maintainer
#8 lore raw

PATCH 4/34 relay: prevent integer overflow in relay_open()

In reply to Greg KH

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

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

From: Dan Carpenter <[email protected]>

commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream.

"subbuf_size" and "n_subbufs" come from the user and they need to be capped to prevent an integer overflow.

---
 kernel/relay.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
kernel/relay.c +8 -2
@@ -171,10 +171,14 @@ depopulate:
  */
 static struct rchan_buf *relay_create_buf(struct rchan *chan)
 {
-	struct rchan_buf *buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);
-	if (!buf)
+	struct rchan_buf *buf;
+
+	if (chan->n_subbufs > UINT_MAX / sizeof(size_t *))
 		return NULL;
 
+	buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);
+	if (!buf)
+		return NULL;
 	buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t *), GFP_KERNEL);
 	if (!buf->padding)
 		goto free_buf;
@@ -581,6 +585,8 @@ struct rchan *relay_open(const char *bas
 
 	if (!(subbuf_size && n_subbufs))
 		return NULL;
+	if (subbuf_size > UINT_MAX / n_subbufs)
+		return NULL;
 
 	chan = kzalloc(sizeof(struct rchan), GFP_KERNEL);
 	if (!chan)
author maintainer
#9 lore raw

PATCH 5/34 mac80211: timeout a single frame in the rx reorder buffer

In reply to Greg KH

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

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

From: Eliad Peller <[email protected]>

commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.

The current code checks for stored_mpdu_num > 1, causing the reorder_timer to be triggered indefinitely, but the frame is never timed-out (until the next packet is received)

---
 net/mac80211/rx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/rx.c +1 -1
@@ -2363,7 +2363,7 @@ static u8 ieee80211_sta_manage_reorder_b
 	index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn)
 						% tid_agg_rx->buf_size;
 	if (!tid_agg_rx->reorder_buf[index] &&
-	    tid_agg_rx->stored_mpdu_num > 1) {
+	    tid_agg_rx->stored_mpdu_num) {
 		/*
 		 * No buffers ready to be released, but check whether any
 		 * frames in the reorder buffer have timed out.
author maintainer
#10 lore raw

PATCH 6/34 kernel.h: fix wrong usage of __ratelimit()

In reply to Greg KH

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

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

From: Yong Zhang <[email protected]>

commit bb1dc0bacb8ddd7ba6a5906c678a5a5a110cf695 upstream.

When __ratelimit() returns 1 this means that we can go ahead.

---
 include/linux/kernel.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/kernel.h +1 -1
@@ -417,7 +417,7 @@ static inline char *pack_hex_byte(char *
 		.burst = DEFAULT_RATELIMIT_BURST,       \
 	};                                              \
 							\
-	if (!__ratelimit(&_rs))                         \
+	if (__ratelimit(&_rs))                          \
 		printk(fmt, ##__VA_ARGS__);		\
 })
 #else
author maintainer
#11 lore raw

PATCH 7/34 printk_ratelimited(): fix uninitialized spinlock

In reply to Greg KH

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

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

From: OGAWA Hirofumi <[email protected]>

commit d8521fcc5e0ad3e79bbc4231bb20a6cdc2b50164 upstream.

ratelimit_state initialization of printk_ratelimited() seems broken. This fixes it by using DEFINE_RATELIMIT_STATE() to initialize spinlock properly.

---
 include/linux/kernel.h |   15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)
include/linux/kernel.h +7 -8
@@ -411,14 +411,13 @@ static inline char *pack_hex_byte(char *
  * no local ratelimit_state used in the !PRINTK case
  */
 #ifdef CONFIG_PRINTK
-#define printk_ratelimited(fmt, ...)  ({		\
-	static struct ratelimit_state _rs = {		\
-		.interval = DEFAULT_RATELIMIT_INTERVAL, \
-		.burst = DEFAULT_RATELIMIT_BURST,       \
-	};                                              \
-							\
-	if (__ratelimit(&_rs))                          \
-		printk(fmt, ##__VA_ARGS__);		\
+#define printk_ratelimited(fmt, ...)  ({				\
+	static DEFINE_RATELIMIT_STATE(_rs,				\
+				      DEFAULT_RATELIMIT_INTERVAL,	\
+				      DEFAULT_RATELIMIT_BURST);		\
+									\
+	if (__ratelimit(&_rs))						\
+		printk(fmt, ##__VA_ARGS__);				\
 })
 #else
 /* No effect, but we still get type checking even in the !PRINTK case: */
author maintainer
#12 lore raw

PATCH 8/34 hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375

In reply to Greg KH

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

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

From: Nikolaus Schulz <[email protected]>

commit 09e87e5c4f9af656af2a8a3afc03487c5d9287c3 upstream.

In order to enable temperature mode aka automatic mode for the F75373 and F75375 chips, the two FANx_MODE bits in the fan configuration register need be set to 01, not 10.

---
 drivers/hwmon/f75375s.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/f75375s.c +1 -1
@@ -311,7 +311,7 @@ static int set_pwm_enable_direct(struct
 		fanmode  |= (3 << FAN_CTRL_MODE(nr));
 		break;
 	case 2: /* AUTOMATIC*/
-		fanmode  |= (2 << FAN_CTRL_MODE(nr));
+		fanmode  |= (1 << FAN_CTRL_MODE(nr));
 		break;
 	case 3: /* fan speed */
 		break;
author maintainer
#13 lore raw

PATCH 9/34 crypto: sha512 - Use binary and instead of modulus

In reply to Greg KH

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

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

From: Herbert Xu <[email protected]>

commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd upstream.

The previous patch used the modulus operator over a power of 2 unnecessarily which may produce suboptimal binary code. This patch changes changes them to binary ands instead.

---
 crypto/sha512_generic.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
crypto/sha512_generic.c +2 -2
@@ -78,7 +78,7 @@ static inline void LOAD_OP(int I, u64 *W
 
 static inline void BLEND_OP(int I, u64 *W)
 {
-	W[I % 16] += s1(W[(I-2) % 16]) + W[(I-7) % 16] + s0(W[(I-15) % 16]);
+	W[I & 15] += s1(W[(I-2) & 15]) + W[(I-7) & 15] + s0(W[(I-15) & 15]);
 }
 
 static void
@@ -105,7 +105,7 @@ sha512_transform(u64 *state, const u8 *i
 
 #define SHA512_16_79(i, a, b, c, d, e, f, g, h)			\
 	BLEND_OP(i, W);						\
-	t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[(i)%16];	\
+	t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[(i)&15];	\
 	t2 = e0(a) + Maj(a, b, c);				\
 	d += t1;						\
 	h = t1 + t2
author maintainer
#14 lore raw

PATCH 10/34 crypto: sha512 - Avoid stack bloat on i386

In reply to Greg KH

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

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

From: Herbert Xu <[email protected]>

commit 3a92d687c8015860a19213e3c102cad6b722f83c upstream.

Unfortunately in reducing W from 80 to 16 we ended up unrolling the loop twice. As gcc has issues dealing with 64-bit ops on i386 this means that we end up using even more stack space (>1K).

This patch solves the W reduction by moving LOAD_OP/BLEND_OP into the loop itself, thus avoiding the need to duplicate it.

While the stack space still isn't great (>0.5K) it is at least in the same ball park as the amount of stack used for our C sha1 implementation.

Note that this patch basically reverts to the original code so the diff looks bigger than it really is.

---
 crypto/sha512_generic.c |   68 ++++++++++++++++++++++--------------------------
 1 file changed, 32 insertions(+), 36 deletions(-)
crypto/sha512_generic.c +32 -36
@@ -89,46 +89,42 @@ sha512_transform(u64 *state, const u8 *i
 	int i;
 	u64 W[16];
 
-	/* load the input */
-        for (i = 0; i < 16; i++)
-                LOAD_OP(i, W, input);
-
 	/* load the state into our registers */
 	a=state[0];   b=state[1];   c=state[2];   d=state[3];
 	e=state[4];   f=state[5];   g=state[6];   h=state[7];
 
-#define SHA512_0_15(i, a, b, c, d, e, f, g, h)			\
-	t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i];	\
-	t2 = e0(a) + Maj(a, b, c);				\
-	d += t1;						\
-	h = t1 + t2
-
-#define SHA512_16_79(i, a, b, c, d, e, f, g, h)			\
-	BLEND_OP(i, W);						\
-	t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[(i)&15];	\
-	t2 = e0(a) + Maj(a, b, c);				\
-	d += t1;						\
-	h = t1 + t2
-
-	for (i = 0; i < 16; i += 8) {
-		SHA512_0_15(i, a, b, c, d, e, f, g, h);
-		SHA512_0_15(i + 1, h, a, b, c, d, e, f, g);
-		SHA512_0_15(i + 2, g, h, a, b, c, d, e, f);
-		SHA512_0_15(i + 3, f, g, h, a, b, c, d, e);
-		SHA512_0_15(i + 4, e, f, g, h, a, b, c, d);
-		SHA512_0_15(i + 5, d, e, f, g, h, a, b, c);
-		SHA512_0_15(i + 6, c, d, e, f, g, h, a, b);
-		SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
-	}
-	for (i = 16; i < 80; i += 8) {
-		SHA512_16_79(i, a, b, c, d, e, f, g, h);
-		SHA512_16_79(i + 1, h, a, b, c, d, e, f, g);
-		SHA512_16_79(i + 2, g, h, a, b, c, d, e, f);
-		SHA512_16_79(i + 3, f, g, h, a, b, c, d, e);
-		SHA512_16_79(i + 4, e, f, g, h, a, b, c, d);
-		SHA512_16_79(i + 5, d, e, f, g, h, a, b, c);
-		SHA512_16_79(i + 6, c, d, e, f, g, h, a, b);
-		SHA512_16_79(i + 7, b, c, d, e, f, g, h, a);
+	/* now iterate */
+	for (i=0; i<80; i+=8) {
+		if (!(i & 8)) {
+			int j;
+
+			if (i < 16) {
+				/* load the input */
+				for (j = 0; j < 16; j++)
+					LOAD_OP(i + j, W, input);
+			} else {
+				for (j = 0; j < 16; j++) {
+					BLEND_OP(i + j, W);
+				}
+			}
+		}
+
+		t1 = h + e1(e) + Ch(e,f,g) + sha512_K[i  ] + W[(i & 15)];
+		t2 = e0(a) + Maj(a,b,c);    d+=t1;    h=t1+t2;
+		t1 = g + e1(d) + Ch(d,e,f) + sha512_K[i+1] + W[(i & 15) + 1];
+		t2 = e0(h) + Maj(h,a,b);    c+=t1;    g=t1+t2;
+		t1 = f + e1(c) + Ch(c,d,e) + sha512_K[i+2] + W[(i & 15) + 2];
+		t2 = e0(g) + Maj(g,h,a);    b+=t1;    f=t1+t2;
+		t1 = e + e1(b) + Ch(b,c,d) + sha512_K[i+3] + W[(i & 15) + 3];
+		t2 = e0(f) + Maj(f,g,h);    a+=t1;    e=t1+t2;
+		t1 = d + e1(a) + Ch(a,b,c) + sha512_K[i+4] + W[(i & 15) + 4];
+		t2 = e0(e) + Maj(e,f,g);    h+=t1;    d=t1+t2;
+		t1 = c + e1(h) + Ch(h,a,b) + sha512_K[i+5] + W[(i & 15) + 5];
+		t2 = e0(d) + Maj(d,e,f);    g+=t1;    c=t1+t2;
+		t1 = b + e1(g) + Ch(g,h,a) + sha512_K[i+6] + W[(i & 15) + 6];
+		t2 = e0(c) + Maj(c,d,e);    f+=t1;    b=t1+t2;
+		t1 = a + e1(f) + Ch(f,g,h) + sha512_K[i+7] + W[(i & 15) + 7];
+		t2 = e0(b) + Maj(b,c,d);    e+=t1;    a=t1+t2;
 	}
 
 	state[0] += a; state[1] += b; state[2] += c; state[3] += d;
author maintainer
#15 lore raw

PATCH 11/34 eCryptfs: Remove mmap from directory operations

In reply to Greg KH

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

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

From: Tyler Hicks <[email protected]>

backported from 38e3eaeedcac75360af8a92e7b66956ec4f334e5

Adrian reported that mkfontscale didn't work inside of eCryptfs mounts. Strace revealed the following:

open("./", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) open("./fonts.scale", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 getdents(3, /* 80 entries */, 32768) = 2304
open("./.", O_RDONLY) = 5
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
fstat64(5, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0 mmap2(NULL, 16384, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7fcf000 close(5) = 0
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++

The mmap2() on a directory was successful, resulting in a SIGBUS signal later. This patch removes mmap() from the list of possible ecryptfs_dir_fops so that mmap() isn't possible on eCryptfs directory files.

http://bugs.launchpad.net/bugs/400443

---
 fs/ecryptfs/file.c |    1 -
 1 file changed, 1 deletion(-)
fs/ecryptfs/file.c +0 -1
@@ -327,7 +327,6 @@ const struct file_operations ecryptfs_di
 #ifdef CONFIG_COMPAT
 	.compat_ioctl = ecryptfs_compat_ioctl,
 #endif
-	.mmap = generic_file_mmap,
 	.open = ecryptfs_open,
 	.flush = ecryptfs_flush,
 	.release = ecryptfs_release,
author maintainer
#16 lore raw

PATCH 12/34 Ban ecryptfs over ecryptfs

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

(cherry picked from commit 4403158ba295c8e36f6736b1bb12d0f7e1923dac)

This is a seriously simplified patch from Eric Sandeen; copy of rationale follows:
===
mounting stacked ecryptfs on ecryptfs has been shown to lead to bugs in testing. For crypto info in xattr, there is no mechanism for handling this at all, and for normal file headers, we run into other trouble:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffffa015b0b3>] ecryptfs_d_revalidate+0x43/0xa0 [ecryptfs]
  ...

There doesn't seem to be any good usecase for this, so I'd suggest just disallowing the configuration.

Based on a patch originally, I believe, from Mike Halcrow.
===

---
 fs/ecryptfs/main.c |    8 ++++++++
 1 file changed, 8 insertions(+)
fs/ecryptfs/main.c +8 -0
@@ -487,6 +487,7 @@ out:
 }
 
 struct kmem_cache *ecryptfs_sb_info_cache;
+static struct file_system_type ecryptfs_fs_type;
 
 /**
  * ecryptfs_fill_super
@@ -561,6 +562,13 @@ static int ecryptfs_read_super(struct su
 		ecryptfs_printk(KERN_WARNING, "path_lookup() failed\n");
 		goto out;
 	}
+	if (path.dentry->d_sb->s_type == &ecryptfs_fs_type) {
+		rc = -EINVAL;
+		printk(KERN_ERR "Mount on filesystem of type "
+			"eCryptfs explicitly disallowed due to "
+			"known incompatibilities\n");
+		goto out_free;
+	}
 	ecryptfs_set_superblock_lower(sb, path.dentry->d_sb);
 	sb->s_maxbytes = path.dentry->d_sb->s_maxbytes;
 	sb->s_blocksize = path.dentry->d_sb->s_blocksize;
author maintainer
#17 lore raw

PATCH 13/34 Add mount option to check uid of device being mounted = expect uid, CVE-2011-1833

In reply to Greg KH

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

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

From: John Johansen <[email protected]>

(backported from commit 764355487ea220fdc2faf128d577d7f679b91f97)

Close a TOCTOU race for mounts done via ecryptfs-mount-private. The mount source (device) can be raced when the ownership test is done in userspace. Provide Ecryptfs a means to force the uid check at mount time.

---
 fs/ecryptfs/main.c |   30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)
fs/ecryptfs/main.c +25 -5
@@ -212,7 +212,8 @@ enum { ecryptfs_opt_sig, ecryptfs_opt_ec
        ecryptfs_opt_passthrough, ecryptfs_opt_xattr_metadata,
        ecryptfs_opt_encrypted_view, ecryptfs_opt_fnek_sig,
        ecryptfs_opt_fn_cipher, ecryptfs_opt_fn_cipher_key_bytes,
-       ecryptfs_opt_unlink_sigs, ecryptfs_opt_err };
+       ecryptfs_opt_unlink_sigs, ecryptfs_opt_check_dev_ruid,
+       ecryptfs_opt_err };
 
 static const match_table_t tokens = {
 	{ecryptfs_opt_sig, "sig=%s"},
@@ -227,6 +228,7 @@ static const match_table_t tokens = {
 	{ecryptfs_opt_fn_cipher, "ecryptfs_fn_cipher=%s"},
 	{ecryptfs_opt_fn_cipher_key_bytes, "ecryptfs_fn_key_bytes=%u"},
 	{ecryptfs_opt_unlink_sigs, "ecryptfs_unlink_sigs"},
+	{ecryptfs_opt_check_dev_ruid, "ecryptfs_check_dev_ruid"},
 	{ecryptfs_opt_err, NULL}
 };
 
@@ -270,6 +272,7 @@ static void ecryptfs_init_mount_crypt_st
  * ecryptfs_parse_options
  * @sb: The ecryptfs super block
  * @options: The options pased to the kernel
+ * @check_ruid: set to 1 if device uid should be checked against the ruid
  *
  * Parse mount options:
  * debug=N 	   - ecryptfs_verbosity level for debug output
@@ -285,7 +288,8 @@ static void ecryptfs_init_mount_crypt_st
  *
  * Returns zero on success; non-zero on error
  */
-static int ecryptfs_parse_options(struct super_block *sb, char *options)
+static int ecryptfs_parse_options(struct super_block *sb, char *options,
+					uid_t *check_ruid)
 {
 	char *p;
 	int rc = 0;
@@ -310,6 +314,8 @@ static int ecryptfs_parse_options(struct
 	char *cipher_key_bytes_src;
 	char *fn_cipher_key_bytes_src;
 
+	*check_ruid = 0;
+
 	if (!options) {
 		rc = -EINVAL;
 		goto out;
@@ -410,6 +416,9 @@ static int ecryptfs_parse_options(struct
 		case ecryptfs_opt_unlink_sigs:
 			mount_crypt_stat->flags |= ECRYPTFS_UNLINK_SIGS;
 			break;
+		case ecryptfs_opt_check_dev_ruid:
+			*check_ruid = 1;
+			break;
 		case ecryptfs_opt_err:
 		default:
 			printk(KERN_WARNING
@@ -552,7 +561,8 @@ out:
  * ecryptfs_interpose to create our initial inode and super block
  * struct.
  */
-static int ecryptfs_read_super(struct super_block *sb, const char *dev_name)
+static int ecryptfs_read_super(struct super_block *sb, const char *dev_name,
+				uid_t check_ruid)
 {
 	struct path path;
 	int rc;
@@ -569,6 +579,15 @@ static int ecryptfs_read_super(struct su
 			"known incompatibilities\n");
 		goto out_free;
 	}
+
+	if (check_ruid && path.dentry->d_inode->i_uid != current_uid()) {
+		rc = -EPERM;
+		printk(KERN_ERR "Mount of device (uid: %d) not owned by "
+		       "requested user (uid: %d)\n",
+		       path.dentry->d_inode->i_uid, current_uid());
+		goto out_free;
+	}
+
 	ecryptfs_set_superblock_lower(sb, path.dentry->d_sb);
 	sb->s_maxbytes = path.dentry->d_sb->s_maxbytes;
 	sb->s_blocksize = path.dentry->d_sb->s_blocksize;
@@ -607,6 +626,7 @@ static int ecryptfs_get_sb(struct file_s
 {
 	int rc;
 	struct super_block *sb;
+	uid_t check_ruid;
 
 	rc = get_sb_nodev(fs_type, flags, raw_data, ecryptfs_fill_super, mnt);
 	if (rc < 0) {
@@ -614,12 +634,12 @@ static int ecryptfs_get_sb(struct file_s
 		goto out;
 	}
 	sb = mnt->mnt_sb;
-	rc = ecryptfs_parse_options(sb, raw_data);
+	rc = ecryptfs_parse_options(sb, raw_data, &check_ruid);
 	if (rc) {
 		printk(KERN_ERR "Error parsing options; rc = [%d]\n", rc);
 		goto out_abort;
 	}
-	rc = ecryptfs_read_super(sb, dev_name);
+	rc = ecryptfs_read_super(sb, dev_name, check_ruid);
 	if (rc) {
 		printk(KERN_ERR "Reading sb failed; rc = [%d]\n", rc);
 		goto out_abort;
author maintainer
#18 lore raw

PATCH 14/34 crypto: sha512 - use standard ror64()

In reply to Greg KH

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

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

From: Alexey Dobriyan <[email protected]>

commit f2ea0f5f04c97b48c88edccba52b0682fbe45087 upstream.

Use standard ror64() instead of hand-written.
There is no standard ror64, so create it.

The difference is shift value being "unsigned int" instead of uint64_t (for which there is no reason). gcc starts to emit native ROR instructions which it doesn't do for some reason currently. This should make the code faster.

Patch survives in-tree crypto test and ping flood with hmac(sha512) on.

---
 crypto/sha512_generic.c |   13 ++++---------
 include/linux/bitops.h  |   20 ++++++++++++++++++++
 2 files changed, 24 insertions(+), 9 deletions(-)
crypto/sha512_generic.c +4 -9
@@ -31,11 +31,6 @@ static inline u64 Maj(u64 x, u64 y, u64
         return (x & y) | (z & (x | y));
 }
 
-static inline u64 RORu64(u64 x, u64 y)
-{
-        return (x >> y) | (x << (64 - y));
-}
-
 static const u64 sha512_K[80] = {
         0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL, 0xb5c0fbcfec4d3b2fULL,
         0xe9b5dba58189dbbcULL, 0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
@@ -66,10 +61,10 @@ static const u64 sha512_K[80] = {
         0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
 };
 
-#define e0(x)       (RORu64(x,28) ^ RORu64(x,34) ^ RORu64(x,39))
-#define e1(x)       (RORu64(x,14) ^ RORu64(x,18) ^ RORu64(x,41))
-#define s0(x)       (RORu64(x, 1) ^ RORu64(x, 8) ^ (x >> 7))
-#define s1(x)       (RORu64(x,19) ^ RORu64(x,61) ^ (x >> 6))
+#define e0(x)       (ror64(x,28) ^ ror64(x,34) ^ ror64(x,39))
+#define e1(x)       (ror64(x,14) ^ ror64(x,18) ^ ror64(x,41))
+#define s0(x)       (ror64(x, 1) ^ ror64(x, 8) ^ (x >> 7))
+#define s1(x)       (ror64(x,19) ^ ror64(x,61) ^ (x >> 6))
 
 static inline void LOAD_OP(int I, u64 *W, const u8 *input)
 {
include/linux/bitops.h +20 -0
@@ -46,6 +46,26 @@ static inline unsigned long hweight_long
 }
 
 /**
+ * rol64 - rotate a 64-bit value left
+ * @word: value to rotate
+ * @shift: bits to roll
+ */
+static inline __u64 rol64(__u64 word, unsigned int shift)
+{
+	return (word << shift) | (word >> (64 - shift));
+}
+
+/**
+ * ror64 - rotate a 64-bit value right
+ * @word: value to rotate
+ * @shift: bits to roll
+ */
+static inline __u64 ror64(__u64 word, unsigned int shift)
+{
+	return (word >> shift) | (word << (64 - shift));
+}
+
+/**
  * rol32 - rotate a 32-bit value left
  * @word: value to rotate
  * @shift: bits to roll
author maintainer
#19 lore raw

PATCH 15/34 drm/radeon/kms: fix MSI re-arm on rv370+

In reply to Greg KH

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

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

From: Alex Deucher <[email protected]>

commit b7f5b7dec3d539a84734f2bcb7e53fbb1532a40b upstream.

MSI_REARM_EN register is a write only trigger register. There is no need RMW when re-arming.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=41668

---
 drivers/gpu/drm/radeon/r100.c  |    4 +---
 drivers/gpu/drm/radeon/rs600.c |    4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)
drivers/gpu/drm/radeon/r100.c +1 -3
@@ -218,9 +218,7 @@ int r100_irq_process(struct radeon_devic
 			WREG32(RADEON_AIC_CNTL, msi_rearm | RS400_MSI_REARM);
 			break;
 		default:
-			msi_rearm = RREG32(RADEON_MSI_REARM_EN) & ~RV370_MSI_REARM_EN;
-			WREG32(RADEON_MSI_REARM_EN, msi_rearm);
-			WREG32(RADEON_MSI_REARM_EN, msi_rearm | RV370_MSI_REARM_EN);
+			WREG32(RADEON_MSI_REARM_EN, RV370_MSI_REARM_EN);
 			break;
 		}
 	}
drivers/gpu/drm/radeon/rs600.c +1 -3
@@ -270,9 +270,7 @@ int rs600_irq_process(struct radeon_devi
 			WREG32(RADEON_BUS_CNTL, msi_rearm | RS600_MSI_REARM);
 			break;
 		default:
-			msi_rearm = RREG32(RADEON_MSI_REARM_EN) & ~RV370_MSI_REARM_EN;
-			WREG32(RADEON_MSI_REARM_EN, msi_rearm);
-			WREG32(RADEON_MSI_REARM_EN, msi_rearm | RV370_MSI_REARM_EN);
+			WREG32(RADEON_MSI_REARM_EN, RV370_MSI_REARM_EN);
 			break;
 		}
 	}
author maintainer
#20 lore raw

PATCH 16/34 ecryptfs: read on a directory should return EISDIR if not supported

In reply to Greg KH

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

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

From: Andy Whitcroft <[email protected]>

commit 323ef68faf1bbd9b1e66aea268fd09d358d7e8ab upstream.

read() calls against a file descriptor connected to a directory are incorrectly returning EINVAL rather than EISDIR:

[EISDIR]
[XSI] [Option Start] The fildes argument refers to a directory and the implementation does not allow the directory to be read using read() or pread(). The readdir() function should be used instead. [Option End]

This occurs because we do not have a .read operation defined for ecryptfs directories. Connect this up to generic_read_dir().

---
 fs/ecryptfs/file.c |    1 +
 1 file changed, 1 insertion(+)
fs/ecryptfs/file.c +1 -0
@@ -323,6 +323,7 @@ ecryptfs_compat_ioctl(struct file *file,
 
 const struct file_operations ecryptfs_dir_fops = {
 	.readdir = ecryptfs_readdir,
+	.read = generic_read_dir,
 	.unlocked_ioctl = ecryptfs_unlocked_ioctl,
 #ifdef CONFIG_COMPAT
 	.compat_ioctl = ecryptfs_compat_ioctl,
author maintainer
#21 lore raw

PATCH 17/34 SCSI: 3w-9xxx fix bug in sgl loading

In reply to Greg KH

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

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

From: adam radford <[email protected]>

commit 53ca353594a254e6bd45ccf2d405aa31bcbb7091 upstream.

This small patch fixes a bug in the 3w-9xxx driver where it would load an invalid sgl address in the ioctl path even if request length was zero.

---
 drivers/scsi/3w-9xxx.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/scsi/3w-9xxx.c +7 -4
@@ -76,6 +76,7 @@
                  Fix bug in twa_get_param() on 4GB+.
                  Use pci_resource_len() for ioremap().
    2.26.02.012 - Add power management support.
+   2.26.02.013 - Fix bug in twa_load_sgl().
 */
 
 #include <linux/module.h>
@@ -100,7 +101,7 @@
 #include "3w-9xxx.h"
 
 /* Globals */
-#define TW_DRIVER_VERSION "2.26.02.012"
+#define TW_DRIVER_VERSION "2.26.02.013"
 static TW_Device_Extension *twa_device_extension_list[TW_MAX_SLOT];
 static unsigned int twa_device_extension_count;
 static int twa_major = -1;
@@ -1378,10 +1379,12 @@ static void twa_load_sgl(TW_Device_Exten
 		newcommand = &full_command_packet->command.newcommand;
 		newcommand->request_id__lunl =
 			cpu_to_le16(TW_REQ_LUN_IN(TW_LUN_OUT(newcommand->request_id__lunl), request_id));
-		newcommand->sg_list[0].address = TW_CPU_TO_SGL(dma_handle + sizeof(TW_Ioctl_Buf_Apache) - 1);
-		newcommand->sg_list[0].length = cpu_to_le32(length);
+		if (length) {
+			newcommand->sg_list[0].address = TW_CPU_TO_SGL(dma_handle + sizeof(TW_Ioctl_Buf_Apache) - 1);
+			newcommand->sg_list[0].length = cpu_to_le32(length);
+		}
 		newcommand->sgl_entries__lunh =
-			cpu_to_le16(TW_REQ_LUN_IN(TW_LUN_OUT(newcommand->sgl_entries__lunh), 1));
+			cpu_to_le16(TW_REQ_LUN_IN(TW_LUN_OUT(newcommand->sgl_entries__lunh), length ? 1 : 0));
 	} else {
 		oldcommand = &full_command_packet->command.oldcommand;
 		oldcommand->request_id = request_id;
author maintainer
#22 lore raw

PATCH 18/34 ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR

In reply to Greg KH

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

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

From: Stephen Boyd <[email protected]>

commit b46c0f74657d1fe1c1b0c1452631cc38a9e6987f upstream.

armv7's flush_cache_all() flushes caches via set/way. To determine the cache attributes (line size, number of sets, etc.) the assembly first writes the CSSELR register to select a cache level and then reads the CCSIDR register. The CSSELR register is banked per-cpu and is used to determine which cache level CCSIDR reads. If the task is migrated between when the CSSELR is written and the CCSIDR is read the CCSIDR value may be for an unexpected cache level (for example L1 instead of L2) and incorrect cache flushing could occur.

Disable interrupts across the write and read so that the correct cache attributes are read and used for the cache flushing routine. We disable interrupts instead of disabling preemption because the critical section is only 3 instructions and we want to call v7_dcache_flush_all from __v7_setup which doesn't have a full kernel stack with a struct thread_info.

This fixes a problem we see in scm_call() when flush_cache_all() is called from preemptible context and sometimes the L2 cache is not properly flushed out.

---
 arch/arm/mm/cache-v7.S |    6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/mm/cache-v7.S +6 -0
@@ -39,9 +39,15 @@ loop1:
 	and	r1, r1, #7			@ mask of the bits for current cache only
 	cmp	r1, #2				@ see what cache we have at this level
 	blt	skip				@ skip if no cache, or just i-cache
+#ifdef CONFIG_PREEMPT
+	save_and_disable_irqs r9		@ make cssr&csidr read atomic
+#endif
 	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
 	isb					@ isb to sych the new cssr&csidr
 	mrc	p15, 1, r1, c0, c0, 0		@ read the new csidr
+#ifdef CONFIG_PREEMPT
+	restore_irqs_notrace r9
+#endif
 	and	r2, r1, #7			@ extract the length of the cache lines
 	add	r2, r2, #4			@ add 4 (line length offset)
 	ldr	r4, =0x3ff
author maintainer
#23 lore raw

PATCH 19/34 ARM: 7325/1: fix v7 boot with lockdep enabled

In reply to Greg KH

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

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

From: Rabin Vincent <[email protected]>

commit 8e43a905dd574f54c5715d978318290ceafbe275 upstream.

Bootup with lockdep enabled has been broken on v7 since b46c0f74657d ("ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR").

This is because v7_setup (which is called very early during boot) calls v7_flush_dcache_all, and the save_and_disable_irqs added by that patch ends up attempting to call into lockdep C code (trace_hardirqs_off()) when we are in no position to execute it (no stack, MMU off).

Fix this by using a notrace variant of save_and_disable_irqs. The code already uses the notrace variant of restore_irqs.

---
 arch/arm/include/asm/assembler.h |    5 +++++
 arch/arm/mm/cache-v7.S           |    2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)
arch/arm/include/asm/assembler.h +5 -0
@@ -133,6 +133,11 @@
 	disable_irq
 	.endm
 
+	.macro	save_and_disable_irqs_notrace, oldcpsr
+	mrs	\oldcpsr, cpsr
+	disable_irq_notrace
+	.endm
+
 /*
  * Restore interrupt state previously stored in a register.  We don't
  * guarantee that this will preserve the flags.
arch/arm/mm/cache-v7.S +1 -1
@@ -40,7 +40,7 @@ loop1:
 	cmp	r1, #2				@ see what cache we have at this level
 	blt	skip				@ skip if no cache, or just i-cache
 #ifdef CONFIG_PREEMPT
-	save_and_disable_irqs r9		@ make cssr&csidr read atomic
+	save_and_disable_irqs_notrace r9	@ make cssr&csidr read atomic
 #endif
 	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
 	isb					@ isb to sych the new cssr&csidr
author maintainer
#24 lore raw

PATCH 20/34 USB: Added Kamstrup VID/PIDs to cp210x serial driver.

In reply to Greg KH

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

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

From: Bruno Thomsen <[email protected]>

commit c6c1e4491dc8d1ed2509fa6aacffa7f34614fc38 upstream.

---
 drivers/usb/serial/cp210x.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/serial/cp210x.c +2 -0
@@ -136,6 +136,8 @@ static struct usb_device_id id_table []
 	{ USB_DEVICE(0x16DC, 0x0011) }, /* W-IE-NE-R Plein & Baus GmbH RCM Remote Control for MARATON Power Supply */
 	{ USB_DEVICE(0x16DC, 0x0012) }, /* W-IE-NE-R Plein & Baus GmbH MPOD Multi Channel Power Supply */
 	{ USB_DEVICE(0x16DC, 0x0015) }, /* W-IE-NE-R Plein & Baus GmbH CML Control, Monitoring and Data Logger */
+	{ USB_DEVICE(0x17A8, 0x0001) }, /* Kamstrup Optical Eye/3-wire */
+	{ USB_DEVICE(0x17A8, 0x0005) }, /* Kamstrup M-Bus Master MultiPort 250D */
 	{ USB_DEVICE(0x17F4, 0xAAAA) }, /* Wavesense Jazz blood glucose meter */
 	{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
 	{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
author maintainer
#25 lore raw

PATCH 21/34 USB: Fix handoff when BIOS disables host PCI device.

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit cab928ee1f221c9cc48d6615070fefe2e444384a upstream.

On some systems with an Intel Panther Point xHCI host controller, the BIOS disables the xHCI PCI device during boot, and switches the xHCI ports over to EHCI. This allows the BIOS to access USB devices without having xHCI support.

The downside is that the xHCI BIOS handoff mechanism will fail because memory mapped I/O is not enabled for the disabled PCI device. Jesse Barnes says this is expected behavior. The PCI core will enable BARs before quirks run, but it will leave it in an undefined state, and it may not have memory mapped I/O enabled.

Make the generic USB quirk handler call pci_enable_device() to re-enable MMIO, and call pci_disable_device() once the host-specific BIOS handoff is finished. This will balance the ref counts in the PCI core. When the PCI probe function is called, usb_hcd_pci_probe() will call pci_enable_device() again.

This should be back ported to kernels as old as 2.6.31. That was the first kernel with xHCI support, and no one has complained about BIOS handoffs failing due to memory mapped I/O being disabled on other hosts (EHCI, UHCI, or OHCI).

---
 drivers/usb/host/pci-quirks.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
drivers/usb/host/pci-quirks.c +11 -0
@@ -503,7 +503,17 @@ static void __devinit quirk_usb_early_ha
 	 */
 	if (pdev->vendor == 0x184e)	/* vendor Netlogic */
 		return;
+	if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
+			pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
+			pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
+			pdev->class != PCI_CLASS_SERIAL_USB_XHCI)
+		return;
 
+	if (pci_enable_device(pdev) < 0) {
+		dev_warn(&pdev->dev, "Can't enable PCI device, "
+				"BIOS handoff failed.\n");
+		return;
+	}
 	if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
 		quirk_usb_handoff_uhci(pdev);
 	else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
@@ -512,5 +522,6 @@ static void __devinit quirk_usb_early_ha
 		quirk_usb_disable_ehci(pdev);
 	else if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
 		quirk_usb_handoff_xhci(pdev);
+	pci_disable_device(pdev);
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
author maintainer
#26 lore raw

PATCH 22/34 xhci: Fix encoding for HS bulk/control NAK rate.

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2 upstream.

The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must be encoded as an exponent of two number of microframes. The endpoint descriptor has the NAK rate encoded in number of microframes. We were just copying the value from the endpoint descriptor into the endpoint context interval field, which was not correct. This lead to the VIA host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass storage device.

The fix is to use the correct encoding. Refactor the code to convert number of frames to an exponential number of microframes, and make sure we convert the number of microframes in HS bulk and control endpoints to an exponent.

This should be back ported to kernels as old as 2.6.31, that contain the commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval"

---
 drivers/usb/host/xhci-mem.c |   32 ++++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/usb/host/xhci-mem.c +24 -8
@@ -472,26 +472,42 @@ static unsigned int xhci_parse_exponent_
 }
 
 /*
- * Convert bInterval expressed in frames (in 1-255 range) to exponent of
+ * Convert bInterval expressed in microframes (in 1-255 range) to exponent of
  * microframes, rounded down to nearest power of 2.
  */
-static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
-		struct usb_host_endpoint *ep)
+static unsigned int xhci_microframes_to_exponent(struct usb_device *udev,
+		struct usb_host_endpoint *ep, unsigned int desc_interval,
+		unsigned int min_exponent, unsigned int max_exponent)
 {
 	unsigned int interval;
 
-	interval = fls(8 * ep->desc.bInterval) - 1;
-	interval = clamp_val(interval, 3, 10);
-	if ((1 << interval) != 8 * ep->desc.bInterval)
+	interval = fls(desc_interval) - 1;
+	interval = clamp_val(interval, min_exponent, max_exponent);
+	if ((1 << interval) != desc_interval)
 		dev_warn(&udev->dev,
 			 "ep %#x - rounding interval to %d microframes, ep desc says %d microframes\n",
 			 ep->desc.bEndpointAddress,
 			 1 << interval,
-			 8 * ep->desc.bInterval);
+			 desc_interval);
 
 	return interval;
 }
 
+static unsigned int xhci_parse_microframe_interval(struct usb_device *udev,
+		struct usb_host_endpoint *ep)
+{
+	return xhci_microframes_to_exponent(udev, ep,
+			ep->desc.bInterval, 0, 15);
+}
+
+
+static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
+		struct usb_host_endpoint *ep)
+{
+	return xhci_microframes_to_exponent(udev, ep,
+			ep->desc.bInterval * 8, 3, 10);
+}
+
 /* Return the polling or NAK interval.
  *
  * The polling interval is expressed in "microframes".  If xHCI's Interval field
@@ -510,7 +526,7 @@ static inline unsigned int xhci_get_endp
 		/* Max NAK rate */
 		if (usb_endpoint_xfer_control(&ep->desc) ||
 		    usb_endpoint_xfer_bulk(&ep->desc)) {
-			interval = ep->desc.bInterval;
+			interval = xhci_parse_microframe_interval(udev, ep);
 			break;
 		}
 		/* Fall through - SS and HS isoc/int have same decoding */
author maintainer
#27 lore raw

PATCH 23/34 hdpvr: fix race conditon during start of streaming

In reply to Greg KH

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

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

From: Janne Grunau <[email protected]>

commit afa159538af61f1a65d48927f4e949fe514fb4fc upstream.

status has to be set to STREAMING before the streaming worker is queued. hdpvr_transmit_buffers() will exit immediately otherwise.

---
 drivers/media/video/hdpvr/hdpvr-video.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/video/hdpvr/hdpvr-video.c +2 -1
@@ -279,12 +279,13 @@ static int hdpvr_start_streaming(struct
 
 		hdpvr_config_call(dev, CTRL_START_STREAMING_VALUE, 0x00);
 
+		dev->status = STATUS_STREAMING;
+
 		INIT_WORK(&dev->worker, hdpvr_transmit_buffers);
 		queue_work(dev->workqueue, &dev->worker);
 
 		v4l2_dbg(MSG_BUFFER, hdpvr_debug, &dev->v4l2_dev,
 			 "streaming started\n");
-		dev->status = STATUS_STREAMING;
 
 		return 0;
 	}
author maintainer
#28 lore raw

PATCH 24/34 eCryptfs: Use notify_change for truncating lower inodes

In reply to Greg KH

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

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

From: Tyler Hicks <[email protected]>

commit 5f3ef64f4da1c587cdcfaaac72311225b7df094c upstream.

When truncating inodes in the lower filesystem, eCryptfs directly invoked vmtruncate(). As Christoph Hellwig pointed out, vmtruncate() is a filesystem helper function, but filesystems may need to do more than just a call to vmtruncate().

This patch moves the lower inode truncation out of ecryptfs_truncate() and renames the function to truncate_upper(). truncate_upper() updates an iattr for the lower inode to indicate if the lower inode needs to be truncated upon return. ecryptfs_setattr() then calls notify_change(), using the updated iattr for the lower inode, to complete the truncation.

For eCryptfs functions needing to truncate, ecryptfs_truncate() is reintroduced as a simple way to truncate the upper inode to a specified size and then truncate the lower inode accordingly.

https://bugs.launchpad.net/bugs/451368

---
 fs/ecryptfs/inode.c |   99 +++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 67 insertions(+), 32 deletions(-)
fs/ecryptfs/inode.c +67 -32
@@ -758,18 +758,23 @@ upper_size_to_lower_size(struct ecryptfs
 }
 
 /**
- * ecryptfs_truncate
+ * truncate_upper
  * @dentry: The ecryptfs layer dentry
- * @new_length: The length to expand the file to
+ * @ia: Address of the ecryptfs inode's attributes
+ * @lower_ia: Address of the lower inode's attributes
  *
  * Function to handle truncations modifying the size of the file. Note
  * that the file sizes are interpolated. When expanding, we are simply
- * writing strings of 0's out. When truncating, we need to modify the
- * underlying file size according to the page index interpolations.
+ * writing strings of 0's out. When truncating, we truncate the upper
+ * inode and update the lower_ia according to the page index
+ * interpolations. If ATTR_SIZE is set in lower_ia->ia_valid upon return,
+ * the caller must use lower_ia in a call to notify_change() to perform
+ * the truncation of the lower inode.
  *
  * Returns zero on success; non-zero otherwise
  */
-int ecryptfs_truncate(struct dentry *dentry, loff_t new_length)
+static int truncate_upper(struct dentry *dentry, struct iattr *ia,
+			  struct iattr *lower_ia)
 {
 	int rc = 0;
 	struct inode *inode = dentry->d_inode;
@@ -780,8 +785,10 @@ int ecryptfs_truncate(struct dentry *den
 	loff_t lower_size_before_truncate;
 	loff_t lower_size_after_truncate;
 
-	if (unlikely((new_length == i_size)))
+	if (unlikely((ia->ia_size == i_size))) {
+		lower_ia->ia_valid &= ~ATTR_SIZE;
 		goto out;
+	}
 	crypt_stat = &ecryptfs_inode_to_private(dentry->d_inode)->crypt_stat;
 	/* Set up a fake ecryptfs file, this is used to interface with
 	 * the file in the underlying filesystem so that the
@@ -801,28 +808,30 @@ int ecryptfs_truncate(struct dentry *den
 		&fake_ecryptfs_file,
 		ecryptfs_inode_to_private(dentry->d_inode)->lower_file);
 	/* Switch on growing or shrinking file */
-	if (new_length > i_size) {
+	if (ia->ia_size > i_size) {
 		char zero[] = { 0x00 };
 
+		lower_ia->ia_valid &= ~ATTR_SIZE;
 		/* Write a single 0 at the last position of the file;
 		 * this triggers code that will fill in 0's throughout
 		 * the intermediate portion of the previous end of the
 		 * file and the new and of the file */
 		rc = ecryptfs_write(&fake_ecryptfs_file, zero,
-				    (new_length - 1), 1);
-	} else { /* new_length < i_size_read(inode) */
-		/* We're chopping off all the pages down do the page
-		 * in which new_length is located. Fill in the end of
-		 * that page from (new_length & ~PAGE_CACHE_MASK) to
+				    (ia->ia_size - 1), 1);
+	} else { /* ia->ia_size < i_size_read(inode) */
+		/* We're chopping off all the pages down to the page
+		 * in which ia->ia_size is located. Fill in the end of
+		 * that page from (ia->ia_size & ~PAGE_CACHE_MASK) to
 		 * PAGE_CACHE_SIZE with zeros. */
 		size_t num_zeros = (PAGE_CACHE_SIZE
-				    - (new_length & ~PAGE_CACHE_MASK));
+				    - (ia->ia_size & ~PAGE_CACHE_MASK));
 
 		if (!(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
-			rc = vmtruncate(inode, new_length);
+			rc = vmtruncate(inode, ia->ia_size);
 			if (rc)
 				goto out_free;
-			rc = vmtruncate(lower_dentry->d_inode, new_length);
+			lower_ia->ia_size = ia->ia_size;
+			lower_ia->ia_valid |= ATTR_SIZE;
 			goto out_free;
 		}
 		if (num_zeros) {
@@ -834,7 +843,7 @@ int ecryptfs_truncate(struct dentry *den
 				goto out_free;
 			}
 			rc = ecryptfs_write(&fake_ecryptfs_file, zeros_virt,
-					    new_length, num_zeros);
+					    ia->ia_size, num_zeros);
 			kfree(zeros_virt);
 			if (rc) {
 				printk(KERN_ERR "Error attempting to zero out "
@@ -843,7 +852,7 @@ int ecryptfs_truncate(struct dentry *den
 				goto out_free;
 			}
 		}
-		vmtruncate(inode, new_length);
+		vmtruncate(inode, ia->ia_size);
 		rc = ecryptfs_write_inode_size_to_metadata(inode);
 		if (rc) {
 			printk(KERN_ERR	"Problem with "
@@ -856,10 +865,12 @@ int ecryptfs_truncate(struct dentry *den
 		lower_size_before_truncate =
 		    upper_size_to_lower_size(crypt_stat, i_size);
 		lower_size_after_truncate =
-		    upper_size_to_lower_size(crypt_stat, new_length);
-		if (lower_size_after_truncate < lower_size_before_truncate)
-			vmtruncate(lower_dentry->d_inode,
-				   lower_size_after_truncate);
+		    upper_size_to_lower_size(crypt_stat, ia->ia_size);
+		if (lower_size_after_truncate < lower_size_before_truncate) {
+			lower_ia->ia_size = lower_size_after_truncate;
+			lower_ia->ia_valid |= ATTR_SIZE;
+		} else
+			lower_ia->ia_valid &= ~ATTR_SIZE;
 	}
 out_free:
 	if (ecryptfs_file_to_private(&fake_ecryptfs_file))
@@ -869,6 +880,33 @@ out:
 	return rc;
 }
 
+/**
+ * ecryptfs_truncate
+ * @dentry: The ecryptfs layer dentry
+ * @new_length: The length to expand the file to
+ *
+ * Simple function that handles the truncation of an eCryptfs inode and
+ * its corresponding lower inode.
+ *
+ * Returns zero on success; non-zero otherwise
+ */
+int ecryptfs_truncate(struct dentry *dentry, loff_t new_length)
+{
+	struct iattr ia = { .ia_valid = ATTR_SIZE, .ia_size = new_length };
+	struct iattr lower_ia = { .ia_valid = 0 };
+	int rc;
+
+	rc = truncate_upper(dentry, &ia, &lower_ia);
+	if (!rc && lower_ia.ia_valid & ATTR_SIZE) {
+		struct dentry *lower_dentry = ecryptfs_dentry_to_lower(dentry);
+
+		mutex_lock(&lower_dentry->d_inode->i_mutex);
+		rc = notify_change(lower_dentry, &lower_ia);
+		mutex_unlock(&lower_dentry->d_inode->i_mutex);
+	}
+	return rc;
+}
+
 static int
 ecryptfs_permission(struct inode *inode, int mask)
 {
@@ -891,6 +929,7 @@ static int ecryptfs_setattr(struct dentr
 {
 	int rc = 0;
 	struct dentry *lower_dentry;
+	struct iattr lower_ia;
 	struct inode *inode;
 	struct inode *lower_inode;
 	struct ecryptfs_crypt_stat *crypt_stat;
@@ -929,15 +968,11 @@ static int ecryptfs_setattr(struct dentr
 		}
 	}
 	mutex_unlock(&crypt_stat->cs_mutex);
+	memcpy(&lower_ia, ia, sizeof(lower_ia));
+	if (ia->ia_valid & ATTR_FILE)
+		lower_ia.ia_file = ecryptfs_file_to_lower(ia->ia_file);
 	if (ia->ia_valid & ATTR_SIZE) {
-		ecryptfs_printk(KERN_DEBUG,
-				"ia->ia_valid = [0x%x] ATTR_SIZE" " = [0x%x]\n",
-				ia->ia_valid, ATTR_SIZE);
-		rc = ecryptfs_truncate(dentry, ia->ia_size);
-		/* ecryptfs_truncate handles resizing of the lower file */
-		ia->ia_valid &= ~ATTR_SIZE;
-		ecryptfs_printk(KERN_DEBUG, "ia->ia_valid = [%x]\n",
-				ia->ia_valid);
+		rc = truncate_upper(dentry, ia, &lower_ia);
 		if (rc < 0)
 			goto out;
 	}
@@ -946,11 +981,11 @@ static int ecryptfs_setattr(struct dentr
 	 * mode change is for clearing setuid/setgid bits. Allow lower fs
 	 * to interpret this in its own way.
 	 */
-	if (ia->ia_valid & (ATTR_KILL_SUID | ATTR_KILL_SGID))
-		ia->ia_valid &= ~ATTR_MODE;
+	if (lower_ia.ia_valid & (ATTR_KILL_SUID | ATTR_KILL_SGID))
+		lower_ia.ia_valid &= ~ATTR_MODE;
 
 	mutex_lock(&lower_dentry->d_inode->i_mutex);
-	rc = notify_change(lower_dentry, ia);
+	rc = notify_change(lower_dentry, &lower_ia);
 	mutex_unlock(&lower_dentry->d_inode->i_mutex);
 out:
 	fsstack_copy_attr_all(inode, lower_inode, NULL);
author maintainer
#29 lore raw

PATCH 25/34 eCryptfs: Remove extra d_delete in ecryptfs_rmdir

In reply to Greg KH

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

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

From: Tyler Hicks <[email protected]>

commit 35ffa948b2f7bdf79e488cd496232935d095087a upstream.

vfs_rmdir() already calls d_delete() on the lower dentry. That was being duplicated in ecryptfs_rmdir() and caused a NULL pointer dereference when NFSv3 was the lower filesystem.

---
 fs/ecryptfs/inode.c |    2 --
 1 file changed, 2 deletions(-)
fs/ecryptfs/inode.c +0 -2
@@ -575,8 +575,6 @@ static int ecryptfs_rmdir(struct inode *
 	dget(lower_dentry);
 	rc = vfs_rmdir(lower_dir_dentry->d_inode, lower_dentry);
 	dput(lower_dentry);
-	if (!rc)
-		d_delete(lower_dentry);
 	fsstack_copy_attr_times(dir, lower_dir_dentry->d_inode);
 	dir->i_nlink = lower_dir_dentry->d_inode->i_nlink;
 	unlock_dir(lower_dir_dentry);
author maintainer
#30 lore raw

PATCH 26/34 eCryptfs: Clear i_nlink in rmdir

In reply to Greg KH

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

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

From: Tyler Hicks <[email protected]>

commit 07850552b92b3637fa56767b5e460b4238014447 upstream.

eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful vfs_rmdir() on the lower directory. This resulted in the inode evict and destroy paths to be missed.

https://bugs.launchpad.net/ecryptfs/+bug/723518

---
 fs/ecryptfs/inode.c |    2 ++
 1 file changed, 2 insertions(+)
fs/ecryptfs/inode.c +2 -0
@@ -575,6 +575,8 @@ static int ecryptfs_rmdir(struct inode *
 	dget(lower_dentry);
 	rc = vfs_rmdir(lower_dir_dentry->d_inode, lower_dentry);
 	dput(lower_dentry);
+	if (!rc && dentry->d_inode)
+		clear_nlink(dentry->d_inode);
 	fsstack_copy_attr_times(dir, lower_dir_dentry->d_inode);
 	dir->i_nlink = lower_dir_dentry->d_inode->i_nlink;
 	unlock_dir(lower_dir_dentry);
author maintainer
#31 lore raw

PATCH 27/34 cdrom: use copy_to_user() without the underscores

In reply to Greg KH

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

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

From: Dan Carpenter <[email protected]>

commit 822bfa51ce44f2c63c300fdb76dc99c4d5a5ca9f upstream.

"nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap on 32 bit systems. That would have been ok if we used the same wrapped value for the copy, but we use a shifted value. We should just use the checked version of copy_to_user() because it's not going to make a difference to the speed.

---
 drivers/cdrom/cdrom.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)
drivers/cdrom/cdrom.c +1 -7
@@ -2057,11 +2057,6 @@ static int cdrom_read_cdda_old(struct cd
 	if (!nr)
 		return -ENOMEM;
 
-	if (!access_ok(VERIFY_WRITE, ubuf, nframes * CD_FRAMESIZE_RAW)) {
-		ret = -EFAULT;
-		goto out;
-	}
-
 	cgc.data_direction = CGC_DATA_READ;
 	while (nframes > 0) {
 		if (nr > nframes)
@@ -2070,7 +2065,7 @@ static int cdrom_read_cdda_old(struct cd
 		ret = cdrom_read_block(cdi, &cgc, lba, nr, 1, CD_FRAMESIZE_RAW);
 		if (ret)
 			break;
-		if (__copy_to_user(ubuf, cgc.buffer, CD_FRAMESIZE_RAW * nr)) {
+		if (copy_to_user(ubuf, cgc.buffer, CD_FRAMESIZE_RAW * nr)) {
 			ret = -EFAULT;
 			break;
 		}
@@ -2078,7 +2073,6 @@ static int cdrom_read_cdda_old(struct cd
 		nframes -= nr;
 		lba += nr;
 	}
-out:
 	kfree(cgc.buffer);
 	return ret;
 }
author maintainer
#32 lore raw

PATCH 28/34 autofs: work around unhappy compat problem on x86-64

In reply to Greg KH

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

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

From: Ian Kent <[email protected]>

commit a32744d4abae24572eff7269bc17895c41bd0085 upstream.

When the autofs protocol version 5 packet type was added in commit 5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), it obvously tried quite hard to be word-size agnostic, and uses explicitly sized fields that are all correctly aligned.

However, with the final "char name[NAME_MAX+1]" array at the end, the actual size of the structure ends up being not very well defined:
because the struct isn't marked 'packed', doing a "sizeof()" on it will align the size of the struct up to the biggest alignment of the members it has.

And despite all the members being the same, the alignment of them is
different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round number (256), the name[] array starts out a 4-byte aligned.

End result: the "packed" size of the structure is 300 bytes: 4-byte, but not 8-byte aligned.

As a result, despite all the fields being in the same place on all architectures, sizeof() will round up that size to 304 bytes on architectures that have 8-byte alignment for u64.

Note that this is *not* a problem for 32-bit compat mode on POWER, since there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit and 64-bit alignment is different for 64-bit entities, and as a result the structure that has exactly the same layout has different sizes.

So on x86-64, but no other architecture, we will just subtract 4 from the size of the structure when running in a compat task. That way we will write the properly sized packet that user mode expects.

Not pretty. Sadly, this very subtle, and unnecessary, size difference has been encoded in user space that wants to read packets of *exactly* the right size, and will refuse to touch anything else.

---
 fs/autofs4/autofs_i.h  |    1 +
 fs/autofs4/dev-ioctl.c |    1 +
 fs/autofs4/inode.c     |    2 ++
 fs/autofs4/waitq.c     |   22 +++++++++++++++++++---
 4 files changed, 23 insertions(+), 3 deletions(-)
fs/autofs4/autofs_i.h +1 -0
@@ -125,6 +125,7 @@ struct autofs_sb_info {
 	int sub_version;
 	int min_proto;
 	int max_proto;
+	int compat_daemon;
 	unsigned long exp_timeout;
 	unsigned int type;
 	int reghost_enabled;
fs/autofs4/dev-ioctl.c +1 -0
@@ -389,6 +389,7 @@ static int autofs_dev_ioctl_setpipefd(st
 		sbi->pipefd = pipefd;
 		sbi->pipe = pipe;
 		sbi->catatonic = 0;
+		sbi->compat_daemon = is_compat_task();
 	}
 out:
 	mutex_unlock(&sbi->wq_mutex);
fs/autofs4/inode.c +2 -0
@@ -19,6 +19,7 @@
 #include <linux/parser.h>
 #include <linux/bitops.h>
 #include <linux/magic.h>
+#include <linux/compat.h>
 #include "autofs_i.h"
 #include <linux/module.h>
 
@@ -341,6 +342,7 @@ int autofs4_fill_super(struct super_bloc
 	set_autofs_type_indirect(&sbi->type);
 	sbi->min_proto = 0;
 	sbi->max_proto = 0;
+	sbi->compat_daemon = is_compat_task();
 	mutex_init(&sbi->wq_mutex);
 	spin_lock_init(&sbi->fs_lock);
 	sbi->queues = NULL;
fs/autofs4/waitq.c +19 -3
@@ -90,7 +90,24 @@ static int autofs4_write(struct file *fi
 
 	return (bytes > 0);
 }
-	
+
+/*
+ * The autofs_v5 packet was misdesigned.
+ *
+ * The packets are identical on x86-32 and x86-64, but have different
+ * alignment. Which means that 'sizeof()' will give different results.
+ * Fix it up for the case of running 32-bit user mode on a 64-bit kernel.
+ */
+static noinline size_t autofs_v5_packet_size(struct autofs_sb_info *sbi)
+{
+	size_t pktsz = sizeof(struct autofs_v5_packet);
+#if defined(CONFIG_X86_64) && defined(CONFIG_COMPAT)
+	if (sbi->compat_daemon > 0)
+		pktsz -= 4;
+#endif
+	return pktsz;
+}
+
 static void autofs4_notify_daemon(struct autofs_sb_info *sbi,
 				 struct autofs_wait_queue *wq,
 				 int type)
@@ -147,8 +164,7 @@ static void autofs4_notify_daemon(struct
 	{
 		struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet;
 
-		pktsz = sizeof(*packet);
-
+		pktsz = autofs_v5_packet_size(sbi);
 		packet->wait_queue_token = wq->wait_queue_token;
 		packet->len = wq->name.len;
 		memcpy(packet->name, wq->name.name, wq->name.len);
author maintainer
#33 lore raw

PATCH 29/34 Fix autofs compile without CONFIG_COMPAT

In reply to Greg KH

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

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

From: Linus Torvalds <[email protected]>

commit 3c761ea05a8900a907f32b628611873f6bef24b2 upstream.

The autofs compat handling fix caused a compile failure when CONFIG_COMPAT isn't defined.

Instead of adding random #ifdef'fery in autofs, let's just make the compat helpers earlier to use: without CONFIG_COMPAT, is_compat_task() just hardcodes to zero.

We could probably do something similar for a number of other cases where we have #ifdef's in code, but this is the low-hanging fruit.

---
 include/linux/compat.h |    4 ++++
 1 file changed, 4 insertions(+)
include/linux/compat.h +4 -0
@@ -311,5 +311,9 @@ asmlinkage long compat_sys_openat(unsign
 
 extern void __user *compat_alloc_user_space(unsigned long len);
 
+#else
+
+#define is_compat_task() (0)
+
 #endif /* CONFIG_COMPAT */
 #endif /* _LINUX_COMPAT_H */
author maintainer
#34 lore raw

PATCH 30/34 compat: fix compile breakage on s390

In reply to Greg KH

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

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

From: Heiko Carstens <[email protected]>

commit 048cd4e51d24ebf7f3552226d03c769d6ad91658 upstream.

The new is_compat_task() define for the !COMPAT case in include/linux/compat.h conflicts with a similar define in arch/s390/include/asm/compat.h.

This is the minimal patch which fixes the build issues.

---
 arch/s390/include/asm/compat.h  |    7 -------
 arch/s390/kernel/process.c      |    1 -
 arch/s390/kernel/ptrace.c       |    2 +-
 arch/s390/kernel/setup.c        |    2 +-
 arch/s390/mm/mmap.c             |    2 +-
 drivers/s390/block/dasd_eckd.c  |    1 +
 drivers/s390/block/dasd_ioctl.c |    1 +
 drivers/s390/char/fs3270.c      |    1 +
 drivers/s390/char/vmcp.c        |    1 +
 drivers/s390/cio/chsc_sch.c     |    1 +
 drivers/s390/scsi/zfcp_cfdc.c   |    1 +
 11 files changed, 9 insertions(+), 11 deletions(-)
arch/s390/include/asm/compat.h +0 -7
@@ -171,13 +171,6 @@ static inline int is_compat_task(void)
 	return test_thread_flag(TIF_31BIT);
 }
 
-#else
-
-static inline int is_compat_task(void)
-{
-	return 0;
-}
-
 #endif
 
 static inline void __user *arch_compat_alloc_user_space(long len)
arch/s390/kernel/process.c +0 -1
@@ -32,7 +32,6 @@
 #include <linux/kernel_stat.h>
 #include <linux/syscalls.h>
 #include <linux/compat.h>
-#include <asm/compat.h>
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
 #include <asm/system.h>
arch/s390/kernel/ptrace.c +1 -1
@@ -36,8 +36,8 @@
 #include <linux/regset.h>
 #include <linux/tracehook.h>
 #include <linux/seccomp.h>
+#include <linux/compat.h>
 #include <trace/syscall.h>
-#include <asm/compat.h>
 #include <asm/segment.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
arch/s390/kernel/setup.c +1 -1
@@ -43,6 +43,7 @@
 #include <linux/reboot.h>
 #include <linux/topology.h>
 #include <linux/ftrace.h>
+#include <linux/compat.h>
 
 #include <asm/ipl.h>
 #include <asm/uaccess.h>
@@ -56,7 +57,6 @@
 #include <asm/ptrace.h>
 #include <asm/sections.h>
 #include <asm/ebcdic.h>
-#include <asm/compat.h>
 #include <asm/kvm_virtio.h>
 
 long psw_kernel_bits	= (PSW_BASE_BITS | PSW_MASK_DAT | PSW_ASC_PRIMARY |
arch/s390/mm/mmap.c +1 -1
@@ -27,8 +27,8 @@
 #include <linux/personality.h>
 #include <linux/mm.h>
 #include <linux/module.h>
+#include <linux/compat.h>
 #include <asm/pgalloc.h>
-#include <asm/compat.h>
 
 /*
  * Top of mmap area (just below the process stack).
drivers/s390/block/dasd_eckd.c +1 -0
@@ -19,6 +19,7 @@
 #include <linux/bio.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/compat.h>
 
 #include <asm/debug.h>
 #include <asm/idals.h>
drivers/s390/block/dasd_ioctl.c +1 -0
@@ -13,6 +13,7 @@
 #define KMSG_COMPONENT "dasd"
 
 #include <linux/interrupt.h>
+#include <linux/compat.h>
 #include <linux/major.h>
 #include <linux/fs.h>
 #include <linux/blkpg.h>
drivers/s390/char/fs3270.c +1 -0
@@ -14,6 +14,7 @@
 #include <linux/list.h>
 #include <linux/types.h>
 #include <linux/smp_lock.h>
+#include <linux/compat.h>
 
 #include <asm/ccwdev.h>
 #include <asm/cio.h>
drivers/s390/char/vmcp.c +1 -0
@@ -16,6 +16,7 @@
 
 #include <linux/fs.h>
 #include <linux/init.h>
+#include <linux/compat.h>
 #include <linux/kernel.h>
 #include <linux/miscdevice.h>
 #include <linux/module.h>
drivers/s390/cio/chsc_sch.c +1 -0
@@ -11,6 +11,7 @@
 #include <linux/module.h>
 #include <linux/uaccess.h>
 #include <linux/miscdevice.h>
+#include <linux/compat.h>
 
 #include <asm/cio.h>
 #include <asm/chsc.h>
drivers/s390/scsi/zfcp_cfdc.c +1 -0
@@ -12,6 +12,7 @@
 
 #include <linux/types.h>
 #include <linux/miscdevice.h>
+#include <linux/compat.h>
 #include <asm/ccwdev.h>
 #include "zfcp_def.h"
 #include "zfcp_ext.h"
author maintainer
#35 lore raw

PATCH 31/34 PM: Print a warning if firmware is requested when tasks are frozen

In reply to Greg KH

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

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

From: Rafael J. Wysocki <[email protected]>

[ Upstream commit a144c6a6c924aa1da04dd77fb84b89927354fdff ]

Some drivers erroneously use request_firmware() from their ->resume() (or ->thaw(), or ->restore()) callbacks, which is not going to work unless the firmware has been built in. This causes system resume to stall until the firmware-loading timeout expires, which makes users think that the resume has failed and reboot their machines unnecessarily. For this reason, make _request_firmware() print a warning and return immediately with error code if it has been called when tasks are frozen and it's impossible to start any new usermode helpers.

---

 drivers/base/firmware_class.c |    5 +++++
 include/linux/kmod.h          |    5 +++++
 kernel/kmod.c                 |    9 +++++++++
 3 files changed, 19 insertions(+)
drivers/base/firmware_class.c +5 -0
@@ -489,6 +489,11 @@ _request_firmware(const struct firmware
 	if (!firmware_p)
 		return -EINVAL;
 
+	if (WARN_ON(usermodehelper_is_disabled())) {
+		dev_err(device, "firmware: %s will not be loaded\n", name);
+		return -EBUSY;
+	}
+
 	*firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_KERNEL);
 	if (!firmware) {
 		dev_err(device, "%s: kmalloc(struct firmware) failed\n",
include/linux/kmod.h +5 -0
@@ -104,7 +104,12 @@ struct file;
 extern int call_usermodehelper_pipe(char *path, char *argv[], char *envp[],
 				    struct file **filp);
 
+#ifdef CONFIG_PM_SLEEP
 extern int usermodehelper_disable(void);
 extern void usermodehelper_enable(void);
+extern bool usermodehelper_is_disabled(void);
+#else
+static inline bool usermodehelper_is_disabled(void) { return false; }
+#endif
 
 #endif /* __LINUX_KMOD_H__ */
kernel/kmod.c +9 -0
@@ -337,6 +337,15 @@ void usermodehelper_enable(void)
 	usermodehelper_disabled = 0;
 }
 
+/**
+ * usermodehelper_is_disabled - check if new helpers are allowed to be started
+ */
+bool usermodehelper_is_disabled(void)
+{
+	return usermodehelper_disabled;
+}
+EXPORT_SYMBOL_GPL(usermodehelper_is_disabled);
+
 static void helper_lock(void)
 {
 	atomic_inc(&running_helpers);
author maintainer
#36 lore raw

PATCH 32/34 firmware loader: allow builtin firmware load even if usermodehelper is disabled

In reply to Greg KH

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

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

From: Linus Torvalds <[email protected]>

[ Upstream commit caca9510ff4e5d842c0589110243d60927836222 ]

In commit a144c6a6c924 ("PM: Print a warning if firmware is requested when tasks are frozen") we not only printed a warning if somebody tried to load the firmware when tasks are frozen - we also failed the load.

But that check was done before the check for built-in firmware, and then when we disallowed usermode helpers during bootup (commit 288d5abec831:
"Boot up with usermodehelper disabled"), that actually means that built-in modules can no longer load their firmware even if the firmware is built in too. Which used to work, and some people depended on it for the R100 driver.

So move the test for usermodehelper_is_disabled() down, to after checking the built-in firmware.

This should fix:

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

---

 drivers/base/firmware_class.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/base/firmware_class.c +6 -5
@@ -489,11 +489,6 @@ _request_firmware(const struct firmware
 	if (!firmware_p)
 		return -EINVAL;
 
-	if (WARN_ON(usermodehelper_is_disabled())) {
-		dev_err(device, "firmware: %s will not be loaded\n", name);
-		return -EBUSY;
-	}
-
 	*firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_KERNEL);
 	if (!firmware) {
 		dev_err(device, "%s: kmalloc(struct firmware) failed\n",
@@ -513,6 +508,12 @@ _request_firmware(const struct firmware
 		return 0;
 	}
 
+	if (WARN_ON(usermodehelper_is_disabled())) {
+		dev_err(device, "firmware: %s will not be loaded\n", name);
+		retval = -EBUSY;
+		goto out;
+	}
+
 	if (uevent)
 		dev_info(device, "firmware: requesting %s\n", name);
 
author maintainer
#37 lore raw

PATCH 33/34 PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()

In reply to Greg KH

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

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

From: Srivatsa S. Bhat <[email protected]>

[ Upstream commit b298d289c79211508f11cb50749b0d1d54eb244a ]

Commit a144c6a (PM: Print a warning if firmware is requested when tasks are frozen) introduced usermodehelper_is_disabled() to warn and exit immediately if firmware is requested when usermodehelpers are disabled.

However, it is racy. Consider the following scenario, currently used in drivers/base/firmware_class.c:

...
if (usermodehelper_is_disabled())

        goto out;

/* Do actual work */
...

out:

        return err;

Nothing prevents someone from disabling usermodehelpers just after the check in the 'if' condition, which means that it is quite possible to try doing the "actual work" with usermodehelpers disabled, leading to undesirable consequences.

In particular, this race condition in _request_firmware() causes task freezing failures whenever suspend/hibernation is in progress because, it wrongly waits to get the firmware/microcode image from userspace when actually the usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race are those that depend on userspace via request_firmware(), such as x86 microcode module initialization and microcode image reload.

Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591

This patch adds proper synchronization to fix this issue.

It is to be noted that this patchset fixes the freezing failures but doesn't remove the warnings. IOW, it does not attempt to add explicit synchronization to x86 microcode driver to avoid requesting microcode image at inopportune moments. Because, the warnings were introduced to highlight such cases, in the first place. And we need not silence the warnings, since we take care of the *real* problem (freezing failure) and hence, after that, the warnings are pretty harmless anyway.

---

 drivers/base/firmware_class.c |    3 +++
 include/linux/kmod.h          |    4 ++++
 kernel/kmod.c                 |   24 +++++++++++++++++++++++-
 3 files changed, 30 insertions(+), 1 deletion(-)
drivers/base/firmware_class.c +3 -0
@@ -508,6 +508,8 @@ _request_firmware(const struct firmware
 		return 0;
 	}
 
+	read_lock_usermodehelper();
+
 	if (WARN_ON(usermodehelper_is_disabled())) {
 		dev_err(device, "firmware: %s will not be loaded\n", name);
 		retval = -EBUSY;
@@ -551,6 +553,7 @@ error_kfree_fw:
 	kfree(firmware);
 	*firmware_p = NULL;
 out:
+	read_unlock_usermodehelper();
 	return retval;
 }
 
include/linux/kmod.h +4 -0
@@ -108,8 +108,12 @@ extern int call_usermodehelper_pipe(char
 extern int usermodehelper_disable(void);
 extern void usermodehelper_enable(void);
 extern bool usermodehelper_is_disabled(void);
+extern void read_lock_usermodehelper(void);
+extern void read_unlock_usermodehelper(void);
 #else
 static inline bool usermodehelper_is_disabled(void) { return false; }
+static inline void read_lock_usermodehelper(void) {}
+static inline void read_unlock_usermodehelper(void) {}
 #endif
 
 #endif /* __LINUX_KMOD_H__ */
kernel/kmod.c +23 -1
@@ -35,6 +35,7 @@
 #include <linux/resource.h>
 #include <linux/notifier.h>
 #include <linux/suspend.h>
+#include <linux/rwsem.h>
 #include <asm/uaccess.h>
 
 #include <trace/events/module.h>
@@ -43,6 +44,8 @@ extern int max_threads;
 
 static struct workqueue_struct *khelper_wq;
 
+static DECLARE_RWSEM(umhelper_sem);
+
 #ifdef CONFIG_MODULES
 
 /*
@@ -286,6 +289,7 @@ static void __call_usermodehelper(struct
  * If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
  * (used for preventing user land processes from being created after the user
  * land has been frozen during a system-wide hibernation or suspend operation).
+ * Should always be manipulated under umhelper_sem acquired for write.
  */
 static int usermodehelper_disabled;
 
@@ -304,6 +308,18 @@ static DECLARE_WAIT_QUEUE_HEAD(running_h
  */
 #define RUNNING_HELPERS_TIMEOUT	(5 * HZ)
 
+void read_lock_usermodehelper(void)
+{
+	down_read(&umhelper_sem);
+}
+EXPORT_SYMBOL_GPL(read_lock_usermodehelper);
+
+void read_unlock_usermodehelper(void)
+{
+	up_read(&umhelper_sem);
+}
+EXPORT_SYMBOL_GPL(read_unlock_usermodehelper);
+
 /**
  * usermodehelper_disable - prevent new helpers from being started
  */
@@ -311,8 +327,10 @@ int usermodehelper_disable(void)
 {
 	long retval;
 
+	down_write(&umhelper_sem);
 	usermodehelper_disabled = 1;
-	smp_mb();
+	up_write(&umhelper_sem);
+
 	/*
 	 * From now on call_usermodehelper_exec() won't start any new
 	 * helpers, so it is sufficient if running_helpers turns out to
@@ -325,7 +343,9 @@ int usermodehelper_disable(void)
 	if (retval)
 		return 0;
 
+	down_write(&umhelper_sem);
 	usermodehelper_disabled = 0;
+	up_write(&umhelper_sem);
 	return -EAGAIN;
 }
 
@@ -334,7 +354,9 @@ int usermodehelper_disable(void)
  */
 void usermodehelper_enable(void)
 {
+	down_write(&umhelper_sem);
 	usermodehelper_disabled = 0;
+	up_write(&umhelper_sem);
 }
 
 /**
author maintainer
#38 lore raw

PATCH 34/34 PM / Sleep: Fix read_unlock_usermodehelper() call.

In reply to Greg KH

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

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

From: Tetsuo Handa <[email protected]>

[ Upstream commit e4c89a508f4385a0cd8681c2749a2cd2fa476e40 ]

Commit b298d289
"PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()"
added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called without read_lock_usermodehelper() when kmalloc() failed.

---

 drivers/base/firmware_class.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/base/firmware_class.c +1 -2
@@ -493,8 +493,7 @@ _request_firmware(const struct firmware
 	if (!firmware) {
 		dev_err(device, "%s: kmalloc(struct firmware) failed\n",
 			__func__);
-		retval = -ENOMEM;
-		goto out;
+		return -ENOMEM;
 	}
 
 	for (builtin = __start_builtin_fw; builtin != __end_builtin_fw;
#39 lore raw
In reply to Greg KH

Hi Greg,

Quoted 8 lines · Greg KH

NOTE:
I have NOT tested this rc release. I now no longer own any machines that can run the 2.6.32 kernel. Because of this, this will be the last 2.6.32-longterm kernel that I will release. I will be passing on the .32 kernel to someone else after this release. Please, if you care about the .32 kernel, test this release, I have _only_ build tested it, and have no idea if I got something wrong or not.

OK, tested here on an atom-based netbook (x86-32+i915 graphics). WiFi (incl firmware loading), bluetooth (over USB), NFS, suspend/resume, ACPI were tested with success. So I think that once again you did the job right till your last release :-)

Cheers,
Willy

#40 lore raw
Quoted 12 lines · Willy Tarreau

Hi Greg,

Quoted 8 lines · Greg KH

NOTE:
I have NOT tested this rc release. I now no longer own any machines that can run the 2.6.32 kernel. Because of this, this will be the last 2.6.32-longterm kernel that I will release. I will be passing on the .32 kernel to someone else after this release. Please, if you care about the .32 kernel, test this release, I have _only_ build tested it, and have no idea if I got something wrong or not.

Quoted 8 lines

OK, tested here on an atom-based netbook (x86-32+i915 graphics). WiFi (incl firmware loading), bluetooth (over USB), NFS, suspend/resume, ACPI were tested with success. So I think that once again you did the job right till your last release :-)

Cheers,
Willy

FWIW, tested too on a AMD Turion based laptop (x86_64+ATI X1200 graphics).
Ok, not exactly that but the 2.6.32.58+drm33. But that one also did not show obvious problems.

-Stefan

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author maintainer
#41 lore raw
In reply to Willy Tarreau
Quoted 12 lines · Willy Tarreau

Hi Greg,

Quoted 8 lines · Greg KH

NOTE:
I have NOT tested this rc release. I now no longer own any machines that can run the 2.6.32 kernel. Because of this, this will be the last 2.6.32-longterm kernel that I will release. I will be passing on the .32 kernel to someone else after this release. Please, if you care about the .32 kernel, test this release, I have _only_ build tested it, and have no idea if I got something wrong or not.

Quoted 4 lines

OK, tested here on an atom-based netbook (x86-32+i915 graphics). WiFi (incl firmware loading), bluetooth (over USB), NFS, suspend/resume, ACPI were tested with success. So I think that once again you did the job right till your last release :-)

Great, thanks for testing and letting me know.

greg k-h