[patch 00/16] Linux 2.6.25 -stable review

[patch 00/16] Linux 2.6.25 -stable review

[Greg KH]

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

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

Responses should be made by May 10, 17:00:00 UTC.  Anything received
after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.2-rc1.gz
and the diffstat can be found below.


thanks,

the -stable release team

---------------
 Makefile                         |    2 -
 arch/arm/kernel/kprobes-decode.c |    2 -
 arch/arm/kernel/kprobes.c        |    2 -
 arch/x86/pci/common.c            |    7 ++--
 arch/x86/pci/init.c              |    2 +
 arch/x86/pci/pci.h               |    2 +
 crypto/authenc.c                 |    5 +-
 crypto/cryptd.c                  |    4 +-
 crypto/eseqiv.c                  |    3 +
 drivers/acpi/processor_idle.c    |    4 ++
 drivers/md/md.c                  |    2 -
 drivers/net/wireless/b43/b43.h   |    4 ++
 drivers/net/wireless/b43/main.c  |   40 ++++++++++++++++++-----
 drivers/serial/mpc52xx_uart.c    |    2 -
 fs/reiserfs/ioctl.c              |    4 --
 fs/reiserfs/super.c              |   17 +++++++---
 fs/utimes.c                      |   17 ++++++++--
 include/crypto/scatterwalk.h     |    4 ++
 include/linux/reiserfs_fs.h      |    1 
 kernel/sched.c                   |   66 ++++++++++++++++++++++++++++++++++++++-
 mm/page_alloc.c                  |   14 +++++++-
 21 files changed, 171 insertions(+), 33 deletions(-)

[patch 01/16] 2.6.25 regression: powertop says 120K wakeups/sec

[Greg KH]

[-- Attachment #1: 2.6.25-regression-powertop-says-120k-wakeups-sec.patch --]
[-- Type: text/plain, Size: 1427 bytes --]

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

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

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

commit 0fda6b403f0eca66ad8a7c946b3996e359100443 upstream

Patch to fix huge number of wakeups reported due to recent changes in
processor_idle.c. The problem was that the entry_method determination was
broken due to one of the recent commits (bc71bec91f987) causing
C1 entry to not to go to halt.

http://lkml.org/lkml/2008/3/22/124

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/acpi/processor_idle.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -848,6 +848,7 @@ static int acpi_processor_get_power_info
 		/* all processors need to support C1 */
 		pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
 		pr->power.states[ACPI_STATE_C1].valid = 1;
+		pr->power.states[ACPI_STATE_C1].entry_method = ACPI_CSTATE_HALT;
 	}
 	/* the C0 state only exists as a filler in our array */
 	pr->power.states[ACPI_STATE_C0].valid = 1;
@@ -960,6 +961,9 @@ static int acpi_processor_get_power_info
 				 cx.address);
 		}
 
+		if (cx.type == ACPI_STATE_C1) {
+			cx.valid = 1;
+		}
 
 		obj = &(element->package.elements[2]);
 		if (obj->type != ACPI_TYPE_INTEGER)

-- 

[patch 02/16] mm: fix usemap initialization

[Greg KH]

[-- Attachment #1: mm-fix-usemap-initialization.patch --]
[-- Type: text/plain, Size: 2699 bytes --]


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

------------------
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

commit: 86051ca5eaf5e560113ec7673462804c54284456 upstream

usemap must be initialized only when pfn is within zone.  If not, it corrupts
memory.

And this patch also reduces the number of calls to set_pageblock_migratetype()
from
	(pfn & (pageblock_nr_pages -1)
to
	!(pfn & (pageblock_nr_pages-1)
it should be called once per pageblock.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Shi Weihua <shiwh@cn.fujitsu.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/page_alloc.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2518,7 +2518,9 @@ void __meminit memmap_init_zone(unsigned
 	struct page *page;
 	unsigned long end_pfn = start_pfn + size;
 	unsigned long pfn;
+	struct zone *z;
 
+	z = &NODE_DATA(nid)->node_zones[zone];
 	for (pfn = start_pfn; pfn < end_pfn; pfn++) {
 		/*
 		 * There can be holes in boot-time mem_map[]s
@@ -2536,7 +2538,6 @@ void __meminit memmap_init_zone(unsigned
 		init_page_count(page);
 		reset_page_mapcount(page);
 		SetPageReserved(page);
-
 		/*
 		 * Mark the block movable so that blocks are reserved for
 		 * movable at startup. This will force kernel allocations
@@ -2545,8 +2546,15 @@ void __meminit memmap_init_zone(unsigned
 		 * kernel allocations are made. Later some blocks near
 		 * the start are marked MIGRATE_RESERVE by
 		 * setup_zone_migrate_reserve()
+		 *
+		 * bitmap is created for zone's valid pfn range. but memmap
+		 * can be created for invalid pages (for alignment)
+		 * check here not to call set_pageblock_migratetype() against
+		 * pfn out of zone.
 		 */
-		if ((pfn & (pageblock_nr_pages-1)))
+		if ((z->zone_start_pfn <= pfn)
+		    && (pfn < z->zone_start_pfn + z->spanned_pages)
+		    && !(pfn & (pageblock_nr_pages - 1)))
 			set_pageblock_migratetype(page, MIGRATE_MOVABLE);
 
 		INIT_LIST_HEAD(&page->lru);
@@ -4460,6 +4468,8 @@ void set_pageblock_flags_group(struct pa
 	pfn = page_to_pfn(page);
 	bitmap = get_pageblock_bitmap(zone, pfn);
 	bitidx = pfn_to_bitidx(zone, pfn);
+	VM_BUG_ON(pfn < zone->zone_start_pfn);
+	VM_BUG_ON(pfn >= zone->zone_start_pfn + zone->spanned_pages);
 
 	for (; start_bitidx <= end_bitidx; start_bitidx++, value <<= 1)
 		if (flags & value)

-- 

[patch 03/16] md: fix use after free when removing rdev via sysfs

[Greg KH]

[-- Attachment #1: md-fix-use-after-free-when-removing-rdev-via-sysfs.patch --]
[-- Type: text/plain, Size: 906 bytes --]

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

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

commit: 6a51830e14529063cb2685921e1177d9af50e49a upstream

rdev->mddev is no longer valid upon return from entry->store() when the
'remove' command is given.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2096,7 +2096,7 @@ rdev_attr_store(struct kobject *kobj, st
 			rv = -EBUSY;
 		else
 			rv = entry->store(rdev, page, length);
-		mddev_unlock(rdev->mddev);
+		mddev_unlock(mddev);
 	}
 	return rv;
 }

-- 

[patch 04/16] vfs: fix permission checking in sys_utimensat

[Greg KH]

[-- Attachment #1: vfs-fix-permission-checking-in-sys_utimensat.patch --]
[-- Type: text/plain, Size: 2235 bytes --]

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

------------------
From: Miklos Szeredi <mszeredi@suse.cz>

commit: 02c6be615f1fcd37ac5ed93a3ad6692ad8991cd9 upstream

If utimensat() is called with both times set to UTIME_NOW or one of them to
UTIME_NOW and the other to UTIME_OMIT, then it will update the file time
without any permission checking.

I don't think this can be used for anything other than a local DoS, but could
be quite bewildering at that (e.g.  "Why was that large source tree rebuilt
when I didn't modify anything???")

This affects all kernels from 2.6.22, when the utimensat() syscall was
introduced.

Fix by doing the same permission checking as for the "times == NULL" case.

Thanks to Michael Kerrisk, whose utimensat-non-conformances-and-fixes.patch in
-mm also fixes this (and breaks other stuff), only he didn't realize the
security implications of this bug.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/utimes.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -39,9 +39,14 @@ asmlinkage long sys_utime(char __user *f
 
 #endif
 
+static bool nsec_special(long nsec)
+{
+	return nsec == UTIME_OMIT || nsec == UTIME_NOW;
+}
+
 static bool nsec_valid(long nsec)
 {
-	if (nsec == UTIME_OMIT || nsec == UTIME_NOW)
+	if (nsec_special(nsec))
 		return true;
 
 	return nsec >= 0 && nsec <= 999999999;
@@ -115,7 +120,15 @@ long do_utimes(int dfd, char __user *fil
 			newattrs.ia_mtime.tv_nsec = times[1].tv_nsec;
 			newattrs.ia_valid |= ATTR_MTIME_SET;
 		}
-	} else {
+	}
+
+	/*
+	 * If times is NULL or both times are either UTIME_OMIT or
+	 * UTIME_NOW, then need to check permissions, because
+	 * inode_change_ok() won't do it.
+	 */
+	if (!times || (nsec_special(times[0].tv_nsec) &&
+		       nsec_special(times[1].tv_nsec))) {
 		error = -EACCES;
                 if (IS_IMMUTABLE(inode))
                         goto dput_and_out;

-- 

[patch 05/16] sched: fix hrtick_start_fair and CPU-Hotplug

[Greg KH]

[-- Attachment #1: sched-fix-hrtick_start_fair-and-cpu-hotplug.patch --]
[-- Type: text/plain, Size: 3563 bytes --]

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

------------------
From: Peter Zijlstra <peterz@infradead.org>

commit: b328ca182f01c2a04b85e0ee8a410720b104fbcc upstream

Gautham R Shenoy reported:

 > While running the usual CPU-Hotplug stress tests on linux-2.6.25,
 > I noticed the following in the console logs.
 >
 > This is a wee bit difficult to reproduce. In the past 10 runs I hit this
 > only once.
 >
 > ------------[ cut here ]------------
 >
 > WARNING: at kernel/sched.c:962 hrtick+0x2e/0x65()
 >
 > Just wondering if we are doing a good job at handling the cancellation
 > of any per-cpu scheduler timers during CPU-Hotplug.

This looks like its indeed not cancelled at all and migrates the it to
another cpu. Fix it via a proper hotplug notifier mechanism.

Reported-by: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/sched.c |   66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 65 insertions(+), 1 deletion(-)

--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -876,6 +876,7 @@ static inline void resched_rq(struct rq 
 enum {
 	HRTICK_SET,		/* re-programm hrtick_timer */
 	HRTICK_RESET,		/* not a new slice */
+	HRTICK_BLOCK,		/* stop hrtick operations */
 };
 
 /*
@@ -887,6 +888,8 @@ static inline int hrtick_enabled(struct 
 {
 	if (!sched_feat(HRTICK))
 		return 0;
+	if (unlikely(test_bit(HRTICK_BLOCK, &rq->hrtick_flags)))
+		return 0;
 	return hrtimer_is_hres_active(&rq->hrtick_timer);
 }
 
@@ -969,7 +972,63 @@ static enum hrtimer_restart hrtick(struc
 	return HRTIMER_NORESTART;
 }
 
-static inline void init_rq_hrtick(struct rq *rq)
+static void hotplug_hrtick_disable(int cpu)
+{
+	struct rq *rq = cpu_rq(cpu);
+	unsigned long flags;
+
+	spin_lock_irqsave(&rq->lock, flags);
+	rq->hrtick_flags = 0;
+	__set_bit(HRTICK_BLOCK, &rq->hrtick_flags);
+	spin_unlock_irqrestore(&rq->lock, flags);
+
+	hrtick_clear(rq);
+}
+
+static void hotplug_hrtick_enable(int cpu)
+{
+	struct rq *rq = cpu_rq(cpu);
+	unsigned long flags;
+
+	spin_lock_irqsave(&rq->lock, flags);
+	__clear_bit(HRTICK_BLOCK, &rq->hrtick_flags);
+	spin_unlock_irqrestore(&rq->lock, flags);
+}
+
+static int
+hotplug_hrtick(struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+	int cpu = (int)(long)hcpu;
+
+	switch (action) {
+	case CPU_UP_CANCELED:
+	case CPU_UP_CANCELED_FROZEN:
+	case CPU_DOWN_PREPARE:
+	case CPU_DOWN_PREPARE_FROZEN:
+	case CPU_DEAD:
+	case CPU_DEAD_FROZEN:
+		hotplug_hrtick_disable(cpu);
+		return NOTIFY_OK;
+
+	case CPU_UP_PREPARE:
+	case CPU_UP_PREPARE_FROZEN:
+	case CPU_DOWN_FAILED:
+	case CPU_DOWN_FAILED_FROZEN:
+	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
+		hotplug_hrtick_enable(cpu);
+		return NOTIFY_OK;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static void init_hrtick(void)
+{
+	hotcpu_notifier(hotplug_hrtick, 0);
+}
+
+static void init_rq_hrtick(struct rq *rq)
 {
 	rq->hrtick_flags = 0;
 	hrtimer_init(&rq->hrtick_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
@@ -1006,6 +1065,10 @@ static inline void init_rq_hrtick(struct
 void hrtick_resched(void)
 {
 }
+
+static inline void init_hrtick(void)
+{
+}
 #endif
 
 /*
@@ -7094,6 +7157,7 @@ void __init sched_init_smp(void)
 	put_online_cpus();
 	/* XXX: Theoretical race here - CPU may be hotplugged now */
 	hotcpu_notifier(update_sched_domains, 0);
+	init_hrtick();
 
 	/* Move init over to a non-isolated CPU */
 	if (set_cpus_allowed(current, non_isolated_cpus) < 0)

-- 

[patch 06/16] reiserfs: Unpack tails on quota files

[Greg KH]

[-- Attachment #1: reiserfs-unpack-tails-on-quota-files.patch --]
[-- Type: text/plain, Size: 3351 bytes --]

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

------------------
From: Jan Kara <jack@suse.cz>

commit d5dee5c395062a55236318ac4eec1f4ebb9de6db upstream

Quota files cannot have tails because quota_write and quota_read functions do
not support them. So far when quota files did have tail, we just refused to
turn quotas on it. Sadly this check has been wrong and so there are now plenty
installations where quota files don't have NOTAIL flag set and so now after
fixing the check, they suddently fail to turn quotas on. Since it's easy to
unpack the tail from kernel, do this from reiserfs_quota_on() which solves the
problem and is generally nicer to users anyway.

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by: <urhausen@urifabi.net>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/reiserfs/ioctl.c         |    4 +---
 fs/reiserfs/super.c         |   17 ++++++++++++-----
 include/linux/reiserfs_fs.h |    1 +
 3 files changed, 14 insertions(+), 8 deletions(-)

--- a/fs/reiserfs/ioctl.c
+++ b/fs/reiserfs/ioctl.c
@@ -11,8 +11,6 @@
 #include <linux/smp_lock.h>
 #include <linux/compat.h>
 
-static int reiserfs_unpack(struct inode *inode, struct file *filp);
-
 /*
 ** reiserfs_ioctl - handler for ioctl for inode
 ** supported commands:
@@ -140,7 +138,7 @@ int reiserfs_prepare_write(struct file *
 ** Function try to convert tail from direct item into indirect.
 ** It set up nopack attribute in the REISERFS_I(inode)->nopack
 */
-static int reiserfs_unpack(struct inode *inode, struct file *filp)
+int reiserfs_unpack(struct inode *inode, struct file *filp)
 {
 	int retval = 0;
 	int index;
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -2019,6 +2019,7 @@ static int reiserfs_quota_on(struct supe
 {
 	int err;
 	struct nameidata nd;
+	struct inode *inode;
 
 	if (!(REISERFS_SB(sb)->s_mount_opt & (1 << REISERFS_QUOTA)))
 		return -EINVAL;
@@ -2030,12 +2031,18 @@ static int reiserfs_quota_on(struct supe
 		path_put(&nd.path);
 		return -EXDEV;
 	}
+	inode = nd.path.dentry->d_inode;
 	/* We must not pack tails for quota files on reiserfs for quota IO to work */
-	if (!(REISERFS_I(nd.path.dentry->d_inode)->i_flags & i_nopack_mask)) {
-		reiserfs_warning(sb,
-				 "reiserfs: Quota file must have tail packing disabled.");
-		path_put(&nd.path);
-		return -EINVAL;
+	if (!(REISERFS_I(inode)->i_flags & i_nopack_mask)) {
+		err = reiserfs_unpack(inode, NULL);
+		if (err) {
+			reiserfs_warning(sb,
+				"reiserfs: Unpacking tail of quota file failed"
+				" (%d). Cannot turn on quotas.", err);
+			path_put(&nd.path);
+			return -EINVAL;
+		}
+		mark_inode_dirty(inode);
 	}
 	/* Not journalling quota? No more tests needed... */
 	if (!REISERFS_SB(sb)->s_qf_names[USRQUOTA] &&
--- a/include/linux/reiserfs_fs.h
+++ b/include/linux/reiserfs_fs.h
@@ -2176,6 +2176,7 @@ int reiserfs_ioctl(struct inode *inode, 
 		   unsigned int cmd, unsigned long arg);
 long reiserfs_compat_ioctl(struct file *filp,
 		   unsigned int cmd, unsigned long arg);
+int reiserfs_unpack(struct inode *inode, struct file *filp);
 
 /* ioctl's command */
 #define REISERFS_IOC_UNPACK		_IOW(0xCD,1,long)

-- 

[patch 07/16] POWERPC: mpc5200: Fix unterminated of_device_id table

[Greg KH]

[-- Attachment #1: powerpc-mpc5200-fix-unterminated-of_device_id-table.patch --]
[-- Type: text/plain, Size: 837 bytes --]


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

------------------
From: Grant Likely <grant.likely@secretlab.ca>

commit bc775eac63c16dbcfabc4c6e949c0228edf3e11f upstream

If CONFIG_PPC_MPC5121 is not set, then the of_device_id table for the
mpc5200 serial driver will not get terminated with a NULL entry.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -1221,8 +1221,8 @@ static struct of_device_id mpc52xx_uart_
 #endif
 #ifdef CONFIG_PPC_MPC512x
 	{ .compatible = "fsl,mpc5121-psc-uart", .data = &mpc512x_psc_ops, },
-	{},
 #endif
+	{},
 };
 
 static int __devinit

-- 

[patch 08/16] b43: Fix dual-PHY devices

[Greg KH]

[-- Attachment #1: b43-fix-dual-phy-devices.patch --]
[-- Type: text/plain, Size: 1062 bytes --]

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

------------------
From: Michael Buesch <mb@bu3sch.de>

commit 2e35af143a1380173ba292e48e9b4913ef16b4ee upstream

This fixes operation of dual-PHY (A/B/G) devices.
Do not anounce the A-PHY to mac80211, as that's not supported, yet.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/b43/main.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -3912,6 +3912,14 @@ static int b43_wireless_core_attach(stru
 		err = -EOPNOTSUPP;
 		goto err_powerdown;
 	}
+	if (1 /* disable A-PHY */) {
+		/* FIXME: For now we disable the A-PHY on multi-PHY devices. */
+		if (dev->phy.type != B43_PHYTYPE_N) {
+			have_2ghz_phy = 1;
+			have_5ghz_phy = 0;
+		}
+	}
+
 	dev->phy.gmode = have_2ghz_phy;
 	tmp = dev->phy.gmode ? B43_TMSLOW_GMODE : 0;
 	b43_wireless_core_reset(dev, tmp);

-- 

Re: [patch 08/16] b43: Fix dual-PHY devices

[John W. Linville]

On Thu, May 08, 2008 at 10:42:14AM -0700, Greg KH wrote:
> 2.6.25-stable review patch.  If anyone has any objections, please let us
> know.
> 
> ------------------
> From: Michael Buesch <mb@bu3sch.de>
> 
> commit 2e35af143a1380173ba292e48e9b4913ef16b4ee upstream
> 
> This fixes operation of dual-PHY (A/B/G) devices.
> Do not anounce the A-PHY to mac80211, as that's not supported, yet.
> 
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

ACK

-- 
John W. Linville
linville@tuxdriver.com

[patch 09/16] kprobes/arm: fix cache flush address for instruction stub

[Greg KH]

[-- Attachment #1: kprobes-arm-fix-cache-flush-address-for-instruction-stub.patch --]
[-- Type: text/plain, Size: 962 bytes --]

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

------------------
From: Nicolas Pitre <nico@cam.org>

It is more useful to flush the cache with the actual buffer address
rather than the address containing a pointer to the buffer.

Mainline commit: 8f79ff0cb5330a92032c30ff586745d3016b34ca

Signed-off-by: Nicolas Pitre <nico@marvell.com>
Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/arch/arm/kernel/kprobes.c
+++ b/arch/arm/kernel/kprobes.c
@@ -66,7 +66,7 @@ int __kprobes arch_prepare_kprobe(struct
 			return -ENOMEM;
 		for (is = 0; is < MAX_INSN_SIZE; ++is)
 			p->ainsn.insn[is] = tmp_insn[is];
-		flush_insns(&p->ainsn.insn, MAX_INSN_SIZE);
+		flush_insns(p->ainsn.insn, MAX_INSN_SIZE);
 		break;
 
 	case INSN_GOOD_NO_SLOT:	/* instruction doesn't need insn slot */

-- 

[patch 10/16] kprobes/arm: fix decoding of arithmetic immediate instructions

[Greg KH]

[-- Attachment #1: kprobes-arm-fix-decoding-of-arithmetic-immediate-instructions.patch --]
[-- Type: text/plain, Size: 1127 bytes --]

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

------------------
From: Lennert Buytenhek <buytenh@wantstofly.org>

The ARM kprobes arithmetic immediate instruction decoder
(space_cccc_001x()) was accidentally zero'ing out not only the Rn and
Rd arguments, but the lower nibble of the immediate argument as well
-- this patch fixes this.

Mainline commit: a3fd133c24e16d430ba21f3d9f5c0b8faeeb37fe

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/arm/kernel/kprobes-decode.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/kernel/kprobes-decode.c
+++ b/arch/arm/kernel/kprobes-decode.c
@@ -1176,7 +1176,7 @@ space_cccc_001x(kprobe_opcode_t insn, st
 	 * *S (bit 20) updates condition codes
 	 * ADC/SBC/RSC reads the C flag
 	 */
-	insn &= 0xfff00ff0;	/* Rn = r0, Rd = r0 */
+	insn &= 0xfff00fff;	/* Rn = r0, Rd = r0 */
 	asi->insn[0] = insn;
 	asi->insn_handler = (insn & (1 << 20)) ?  /* S-bit */
 			emulate_alu_imm_rwflags : emulate_alu_imm_rflags;

-- 

[patch 11/16] b43: Fix some TX/RX locking issues

[Greg KH]

[-- Attachment #1: b43-fix-some-tx-rx-locking-issues.patch --]
[-- Type: text/plain, Size: 3596 bytes --]

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

------------------
From: Michael Buesch <mb@bu3sch.de>

commit 21a75d7788f4e29b6c6d28e08f9f0310c4de828d upstream.

This fixes some TX/RX related locking issues.
With this patch applied, some of the PHY transmission errors are fixed.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/b43/b43.h  |    4 ++++
 drivers/net/wireless/b43/main.c |   32 +++++++++++++++++++++++---------
 2 files changed, 27 insertions(+), 9 deletions(-)

--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -628,6 +628,10 @@ struct b43_wl {
 
 	struct mutex mutex;
 	spinlock_t irq_lock;
+	/* R/W lock for data transmission.
+	 * Transmissions on 2+ queues can run concurrently, but somebody else
+	 * might sync with TX by write_lock_irqsave()'ing. */
+	rwlock_t tx_lock;
 	/* Lock for LEDs access. */
 	spinlock_t leds_lock;
 	/* Lock for SHM access. */
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -622,6 +622,7 @@ static void b43_synchronize_irq(struct b
  */
 void b43_dummy_transmission(struct b43_wldev *dev)
 {
+	struct b43_wl *wl = dev->wl;
 	struct b43_phy *phy = &dev->phy;
 	unsigned int i, max_loop;
 	u16 value;
@@ -648,6 +649,9 @@ void b43_dummy_transmission(struct b43_w
 		return;
 	}
 
+	spin_lock_irq(&wl->irq_lock);
+	write_lock(&wl->tx_lock);
+
 	for (i = 0; i < 5; i++)
 		b43_ram_write(dev, i * 4, buffer[i]);
 
@@ -688,6 +692,9 @@ void b43_dummy_transmission(struct b43_w
 	}
 	if (phy->radio_ver == 0x2050 && phy->radio_rev <= 0x5)
 		b43_radio_write16(dev, 0x0051, 0x0037);
+
+	write_unlock(&wl->tx_lock);
+	spin_unlock_irq(&wl->irq_lock);
 }
 
 static void key_write(struct b43_wldev *dev,
@@ -2592,15 +2599,21 @@ static int b43_op_tx(struct ieee80211_hw
 {
 	struct b43_wl *wl = hw_to_b43_wl(hw);
 	struct b43_wldev *dev = wl->current_dev;
-	int err = -ENODEV;
+	unsigned long flags;
+	int err;
 
 	if (unlikely(!dev))
-		goto out;
-	if (unlikely(b43_status(dev) < B43_STAT_STARTED))
-		goto out;
-	/* DMA-TX is done without a global lock. */
-	err = b43_dma_tx(dev, skb, ctl);
-out:
+		return NETDEV_TX_BUSY;
+
+	/* Transmissions on seperate queues can run concurrently. */
+	read_lock_irqsave(&wl->tx_lock, flags);
+
+	err = -ENODEV;
+	if (likely(b43_status(dev) >= B43_STAT_STARTED))
+		err = b43_dma_tx(dev, skb, ctl);
+
+	read_unlock_irqrestore(&wl->tx_lock, flags);
+
 	if (unlikely(err))
 		return NETDEV_TX_BUSY;
 	return NETDEV_TX_OK;
@@ -3109,7 +3122,9 @@ static void b43_wireless_core_stop(struc
 	spin_unlock_irqrestore(&wl->irq_lock, flags);
 	b43_synchronize_irq(dev);
 
+	write_lock_irqsave(&wl->tx_lock, flags);
 	b43_set_status(dev, B43_STAT_INITIALIZED);
+	write_unlock_irqrestore(&wl->tx_lock, flags);
 
 	mutex_unlock(&wl->mutex);
 	/* Must unlock as it would otherwise deadlock. No races here.
@@ -3117,8 +3132,6 @@ static void b43_wireless_core_stop(struc
 	cancel_delayed_work_sync(&dev->periodic_work);
 	mutex_lock(&wl->mutex);
 
-	ieee80211_stop_queues(wl->hw);	//FIXME this could cause a deadlock, as mac80211 seems buggy.
-
 	b43_mac_suspend(dev);
 	free_irq(dev->dev->irq, dev);
 	b43dbg(wl, "Wireless interface stopped\n");
@@ -4084,6 +4097,7 @@ static int b43_wireless_init(struct ssb_
 	memset(wl, 0, sizeof(*wl));
 	wl->hw = hw;
 	spin_lock_init(&wl->irq_lock);
+	rwlock_init(&wl->tx_lock);
 	spin_lock_init(&wl->leds_lock);
 	spin_lock_init(&wl->shm_lock);
 	mutex_init(&wl->mutex);

-- 

Re: [patch 11/16] b43: Fix some TX/RX locking issues

[John W. Linville]

On Thu, May 08, 2008 at 10:42:21AM -0700, Greg KH wrote:
> 2.6.25-stable review patch.  If anyone has any objections, please let us
> know.
> 
> ------------------
> From: Michael Buesch <mb@bu3sch.de>
> 
> commit 21a75d7788f4e29b6c6d28e08f9f0310c4de828d upstream.
> 
> This fixes some TX/RX related locking issues.
> With this patch applied, some of the PHY transmission errors are fixed.

ACK

-- 
John W. Linville
linville@tuxdriver.com

[patch 12/16] x86 PCI: call dmi_check_pciprobe()

[Greg KH]

[-- Attachment #1: x86-pci-call-dmi_check_pciprobe.patch --]
[-- Type: text/plain, Size: 2738 bytes --]

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

------------------
From: Yinghai Lu <yhlu.kernel@gmail.com>

This is a backport of the noted commit which is in 2.6.26-rc1
now.  This is necessary to enable pci=bfsort automatically on a number
of Dell and HP servers, as well as pci=assign-busses for a few other
systems, which was broken between 2.6.22 and 2.6.23.

commit 0df18ff366853cdf31e5238764ec5c63e6b5a398 upstream

x86 PCI: call dmi_check_pciprobe()

this change:

| commit 08f1c192c3c32797068bfe97738babb3295bbf42
| Author: Muli Ben-Yehuda <muli@il.ibm.com>
| Date:   Sun Jul 22 00:23:39 2007 +0300
|
|    x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata
|
|    This patch introduces struct pci_sysdata to x86 and x86-64, and
|    converts the existing two users (NUMA, Calgary) to use it.
|
|    This lays the groundwork for having other users of sysdata, such as
|    the PCI domains work.
|
|    The Calgary bits are tested, the NUMA bits just look ok.

replaces pcibios_scan_root with pci_scan_bus_parented...

but in pcibios_scan_root we have a DMI check:

dmi_check_system(pciprobe_dmi_table);

when when have several peer root buses this could be called multiple
times (which is bad), so move that call to pci_access_init().

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 arch/x86/pci/common.c |    7 +++++--
 arch/x86/pci/init.c   |    2 ++
 arch/x86/pci/pci.h    |    2 ++
 3 files changed, 9 insertions(+), 2 deletions(-)

--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -372,13 +372,16 @@ static struct dmi_system_id __devinitdat
 	{}
 };
 
+void __init dmi_check_pciprobe(void)
+{
+	dmi_check_system(pciprobe_dmi_table);
+}
+
 struct pci_bus * __devinit pcibios_scan_root(int busnum)
 {
 	struct pci_bus *bus = NULL;
 	struct pci_sysdata *sd;
 
-	dmi_check_system(pciprobe_dmi_table);
-
 	while ((bus = pci_find_next_bus(bus)) != NULL) {
 		if (bus->number == busnum) {
 			/* Already scanned */
--- a/arch/x86/pci/init.c
+++ b/arch/x86/pci/init.c
@@ -32,6 +32,8 @@ static __init int pci_access_init(void)
 		printk(KERN_ERR
 		"PCI: Fatal: No config space access function found\n");
 
+ 	dmi_check_pciprobe();
+
 	return 0;
 }
 arch_initcall(pci_access_init);
--- a/arch/x86/pci/pci.h
+++ b/arch/x86/pci/pci.h
@@ -39,6 +39,8 @@ enum pci_bf_sort_state {
 	pci_dmi_bf,
 };
 
+extern void __init dmi_check_pciprobe(void);
+
 /* pci-i386.c */
 
 extern unsigned int pcibios_max_latency;

-- 

[patch 13/16] CRYPTO: api: Fix scatterwalk_sg_chain

[Greg KH]

[-- Attachment #1: crypto-api-fix-scatterwalk_sg_chain.patch --]
[-- Type: text/plain, Size: 1496 bytes --]

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

------------------
From: Herbert Xu <herbert@gondor.apana.org.au>

[CRYPTO] api: Fix scatterwalk_sg_chain

[ Upstream commit: 8ec970d8561abb5645d4602433b772e268c96d05 ]

When I backed out of using the generic sg chaining (as it isn't currently
portable) and introduced scatterwalk_sg_chain/scatterwalk_sg_next I left
out the sg_is_last check in the latter.  This causes it to potentially
dereference beyond the end of the sg array.

As most uses of scatterwalk_sg_next are bound by an overall length, this
only affected the chaining code in authenc and eseqiv. Thanks to Patrick
McHardy for identifying this problem.

This patch also clears the "last" bit on the head of the chained list as
it's no longer last.  This also went missing in scatterwalk_sg_chain and
is present in sg_chain.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 include/crypto/scatterwalk.h |    4 ++++
 1 file changed, 4 insertions(+)

--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -57,10 +57,14 @@ static inline void scatterwalk_sg_chain(
 					struct scatterlist *sg2)
 {
 	sg_set_page(&sg1[num - 1], (void *)sg2, 0, 0);
+	sg1[num - 1].page_link &= ~0x02;
 }
 
 static inline struct scatterlist *scatterwalk_sg_next(struct scatterlist *sg)
 {
+	if (sg_is_last(sg))
+		return NULL;
+
 	return (++sg)->length ? sg : (void *)sg_page(sg);
 }
 

-- 

[patch 14/16] CRYPTO: cryptd: Correct kzalloc error test

[Greg KH]

[-- Attachment #1: crypto-cryptd-correct-kzalloc-error-test.patch --]
[-- Type: text/plain, Size: 926 bytes --]

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

------------------
From: Julia Lawall <julia@diku.dk>

[CRYPTO] cryptd: Correct kzalloc error test

[ Upstream commit: b1145ce395f7785487c128fe8faf8624e6586d84 ]

Normally, kzalloc returns NULL or a valid pointer value, not a value to be
tested using IS_ERR.

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 crypto/cryptd.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -190,8 +190,10 @@ static struct crypto_instance *cryptd_al
 	int err;
 
 	inst = kzalloc(sizeof(*inst) + sizeof(*ctx), GFP_KERNEL);
-	if (IS_ERR(inst))
+	if (!inst) {
+		inst = ERR_PTR(-ENOMEM);
 		goto out;
+	}
 
 	err = -ENAMETOOLONG;
 	if (snprintf(inst->alg.cra_driver_name, CRYPTO_MAX_ALG_NAME,

-- 

[patch 15/16] CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()

[Greg KH]

[-- Attachment #1: crypto-authenc-fix-async-crypto-crash-in-crypto_authenc_genicv.patch --]
[-- Type: text/plain, Size: 2710 bytes --]

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

------------------
From: Patrick McHardy <kaber@trash.net>

[CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv()

[ Upstream commit: 161613293fd4b7d5ceb1faab788f47e688e07a67 ]

crypto_authenc_givencrypt_done uses req->data as struct aead_givcrypt_request,
while it really points to a struct aead_request, causing this crash:

BUG: unable to handle kernel paging request at 6b6b6b6b
IP: [<dc87517b>] :authenc:crypto_authenc_genicv+0x23/0x109
*pde = 00000000
Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
Modules linked in: hifn_795x authenc esp4 aead xfrm4_mode_tunnel sha1_generic hmac crypto_hash]

Pid: 3074, comm: ping Not tainted (2.6.25 #4)
EIP: 0060:[<dc87517b>] EFLAGS: 00010296 CPU: 0
EIP is at crypto_authenc_genicv+0x23/0x109 [authenc]
EAX: daa04690 EBX: daa046e0 ECX: dab0a100 EDX: daa046b0
ESI: 6b6b6b6b EDI: dc872054 EBP: c033ff60 ESP: c033ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process ping (pid: 3074, ti=c033f000 task=db883a80 task.ti=dab6c000)
Stack: 00000000 daa046b0 c0215a3e daa04690 dab0a100 00000000 ffffffff db9fd7f0
       dba208c0 dbbb1720 00000001 daa04720 00000001 c033ff54 c0119ca9 dc852a75
       c033ff60 c033ff60 daa046e0 00000000 00000001 c033ff6c dc87527b 00000001
Call Trace:
 [<c0215a3e>] ? dev_alloc_skb+0x14/0x29
 [<c0119ca9>] ? printk+0x15/0x17
 [<dc87527b>] ? crypto_authenc_givencrypt_done+0x1a/0x27 [authenc]
 [<dc850cca>] ? hifn_process_ready+0x34a/0x352 [hifn_795x]
 [<dc8353c7>] ? rhine_napipoll+0x3f2/0x3fd [via_rhine]
 [<dc851a56>] ? hifn_check_for_completion+0x4d/0xa6 [hifn_795x]
 [<dc851ab9>] ? hifn_tasklet_callback+0xa/0xc [hifn_795x]
 [<c011d046>] ? tasklet_action+0x3f/0x66
 [<c011d230>] ? __do_softirq+0x38/0x7a
 [<c0105a5f>] ? do_softirq+0x3e/0x71
 [<c011d17c>] ? irq_exit+0x2c/0x65
 [<c010e0c0>] ? smp_apic_timer_interrupt+0x5f/0x6a
 [<c01042e4>] ? apic_timer_interrupt+0x28/0x30
 [<dc851640>] ? hifn_handle_req+0x44a/0x50d [hifn_795x]
 ...

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 crypto/authenc.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -217,9 +217,10 @@ static void crypto_authenc_givencrypt_do
 					   int err)
 {
 	if (!err) {
-		struct aead_givcrypt_request *greq = req->data;
+		struct aead_request *areq = req->data;
+		struct skcipher_givcrypt_request *greq = aead_request_ctx(areq);
 
-		err = crypto_authenc_genicv(&greq->areq, greq->giv, 0);
+		err = crypto_authenc_genicv(areq, greq->giv, 0);
 	}
 
 	aead_request_complete(req->data, err);

-- 

[patch 16/16] CRYPTO: eseqiv: Fix off-by-one encryption

[Greg KH]

[-- Attachment #1: crypto-eseqiv-fix-off-by-one-encryption.patch --]
[-- Type: text/plain, Size: 1065 bytes --]

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

------------------
From: Herbert Xu <herbert@gondor.apana.org.au>

[CRYPTO] eseqiv: Fix off-by-one encryption

[ Upstream commit: 46f8153cc59384eb09a426d044668d4801f818ce ]

After attaching the IV to the head during encryption, eseqiv does not
increase the encryption length by that amount.  As such the last block
of the actual plain text will be left unencrypted.

Fortunately the only user of this code hifn currently crashes so this
shouldn't affect anyone :)

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 crypto/eseqiv.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/crypto/eseqiv.c
+++ b/crypto/eseqiv.c
@@ -136,7 +136,8 @@ static int eseqiv_givencrypt(struct skci
 	}
 
 	ablkcipher_request_set_crypt(subreq, reqctx->src, dst,
-				     req->creq.nbytes, req->creq.info);
+				     req->creq.nbytes + ivsize,
+				     req->creq.info);
 
 	memcpy(req->creq.info, ctx->salt, ivsize);
 

-- 

Re: [patch 00/16] Linux 2.6.25 -stable review

[Willy Tarreau]

On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.25.2 release.
(...)                                                  ^^^^^^^^
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.2-rc1.gz
                                                             ^^^^^^^^

warning Greg, you wrote 2.6.25.2 everywhere it seems. It should be .3.

Willy

Re: [patch 00/16] Linux 2.6.25 -stable review

[Greg KH]

On Thu, May 08, 2008 at 07:51:41PM +0200, Willy Tarreau wrote:
> On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.25.2 release.
> (...)                                                  ^^^^^^^^
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.2-rc1.gz
>                                                              ^^^^^^^^
> 
> warning Greg, you wrote 2.6.25.2 everywhere it seems. It should be .3.

Ugh, sorry, you are right.  I'll go move the patch file on kernel.org as
well.

Need more coffee...

greg k-h

Re: [patch 00/16] Linux 2.6.25 -stable review

[Greg KH]

On Thu, May 08, 2008 at 07:51:41PM +0200, Willy Tarreau wrote:
> On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.25.2 release.
> (...)                                                  ^^^^^^^^
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.2-rc1.gz
>                                                              ^^^^^^^^
> 
> warning Greg, you wrote 2.6.25.2 everywhere it seems. It should be .3.

Ok, the updated patch is at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.3-rc1.gz

Sorry for the confusion.

greg k-h

Re: [patch 00/16] Linux 2.6.25 -stable review

[Willy Tarreau]

On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.25.2 release.
> There are 16 patches in this series, all will be posted as a response to
> this one.  If anyone has any issues with these being applied, please let
> us know.  If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.

Greg, shouldn't we also queue this one (may be in a later version) ? It's
in mainline.

Regards,
Willy


>From a815ab8b5891f3d2515316655729272f68269e3b Mon Sep 17 00:00:00 2001
From: Li Zefan <lizf@cn.fujitsu.com>
Date: Fri, 18 Apr 2008 13:27:29 -0700
Subject: ACPI: check a return value correctly in acpi_power_get_context()

We should check *resource != NULL rather than resource != NULL, which will be
always true.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/power.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 76bf6d9..f2a76ac 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -121,7 +121,7 @@ acpi_power_get_context(acpi_handle handle,
 	}
 
 	*resource = acpi_driver_data(device);
-	if (!resource)
+	if (!*resource)
 		return -ENODEV;
 
 	return 0;
-- 
1.5.3.8

Re: [patch 00/16] Linux 2.6.25 -stable review

[Greg KH]

On Thu, May 08, 2008 at 08:13:42PM +0200, Willy Tarreau wrote:
> On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.25.2 release.
> > There are 16 patches in this series, all will be posted as a response to
> > this one.  If anyone has any issues with these being applied, please let
> > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > to add a Signed-off-by: line to the patch, please respond with it.
> 
> Greg, shouldn't we also queue this one (may be in a later version) ? It's
> in mainline.

What problem does it solve?

Does Len want it in -stable?

thanks,

greg k-h

> >From a815ab8b5891f3d2515316655729272f68269e3b Mon Sep 17 00:00:00 2001
> From: Li Zefan <lizf@cn.fujitsu.com>
> Date: Fri, 18 Apr 2008 13:27:29 -0700
> Subject: ACPI: check a return value correctly in acpi_power_get_context()
> 
> We should check *resource != NULL rather than resource != NULL, which will be
> always true.
> 
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> Acked-by: Zhao Yakui <yakui.zhao@intel.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/acpi/power.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index 76bf6d9..f2a76ac 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -121,7 +121,7 @@ acpi_power_get_context(acpi_handle handle,
>  	}
>  
>  	*resource = acpi_driver_data(device);
> -	if (!resource)
> +	if (!*resource)
>  		return -ENODEV;
>  
>  	return 0;
> -- 
> 1.5.3.8

Re: [patch 00/16] Linux 2.6.25 -stable review

[Willy Tarreau]

On Thu, May 08, 2008 at 11:22:33AM -0700, Greg KH wrote:
> On Thu, May 08, 2008 at 08:13:42PM +0200, Willy Tarreau wrote:
> > On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> > > This is the start of the stable review cycle for the 2.6.25.2 release.
> > > There are 16 patches in this series, all will be posted as a response to
> > > this one.  If anyone has any issues with these being applied, please let
> > > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > > to add a Signed-off-by: line to the patch, please respond with it.
> > 
> > Greg, shouldn't we also queue this one (may be in a later version) ? It's
> > in mainline.
> 
> What problem does it solve?

from what I see in the code, currently acpi_power_get_state() will return
0 when setting resource to NULL, and some callers (eg: acpi_power_on())
will happily dereference resource if acpi_power_get_state() returns 0. So
I guess there are circumstances where we can oops.

> Does Len want it in -stable?

I simply forgot to ask. I'm CCing him.

Willy

> thanks,
> 
> greg k-h
> 
> > >From a815ab8b5891f3d2515316655729272f68269e3b Mon Sep 17 00:00:00 2001
> > From: Li Zefan <lizf@cn.fujitsu.com>
> > Date: Fri, 18 Apr 2008 13:27:29 -0700
> > Subject: ACPI: check a return value correctly in acpi_power_get_context()
> > 
> > We should check *resource != NULL rather than resource != NULL, which will be
> > always true.
> > 
> > Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> > Acked-by: Zhao Yakui <yakui.zhao@intel.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Len Brown <len.brown@intel.com>
> > ---
> >  drivers/acpi/power.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > index 76bf6d9..f2a76ac 100644
> > --- a/drivers/acpi/power.c
> > +++ b/drivers/acpi/power.c
> > @@ -121,7 +121,7 @@ acpi_power_get_context(acpi_handle handle,
> >  	}
> >  
> >  	*resource = acpi_driver_data(device);
> > -	if (!resource)
> > +	if (!*resource)
> >  		return -ENODEV;
> >  
> >  	return 0;
> > -- 
> > 1.5.3.8
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/16] Linux 2.6.25 -stable review

[Len Brown]

On Thursday 08 May 2008, Willy Tarreau wrote:
> On Thu, May 08, 2008 at 11:22:33AM -0700, Greg KH wrote:
> > On Thu, May 08, 2008 at 08:13:42PM +0200, Willy Tarreau wrote:
> > > On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> > > > This is the start of the stable review cycle for the 2.6.25.2 release.
> > > > There are 16 patches in this series, all will be posted as a response to
> > > > this one.  If anyone has any issues with these being applied, please let
> > > > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > > > to add a Signed-off-by: line to the patch, please respond with it.
> > > 
> > > Greg, shouldn't we also queue this one (may be in a later version) ? It's
> > > in mainline.
> > 
> > What problem does it solve?
> 
> from what I see in the code, currently acpi_power_get_state() will return
> 0 when setting resource to NULL, and some callers (eg: acpi_power_on())
> will happily dereference resource if acpi_power_get_state() returns 0. So
> I guess there are circumstances where we can oops.
> 
> > Does Len want it in -stable?
> 
> I simply forgot to ask. I'm CCing him.

This patch is correct.

Go ahead and apply it -- it won't hurt anything.
I don't think it will help anything in real-life either, though.

While it is true if we had this failure, we'd oops in acpi_power_on() and acpi_power_off().
But I think this is effectively a check for a programming error that we
don't (currently) have.  ie. acpi_power_add() always does this:
acpi_driver_data(device) = resource; with a valid pointer.
So the fact that this error check was a errantly a NO-OP was hidden in practice.

-Len

> > 
> > > >From a815ab8b5891f3d2515316655729272f68269e3b Mon Sep 17 00:00:00 2001
> > > From: Li Zefan <lizf@cn.fujitsu.com>
> > > Date: Fri, 18 Apr 2008 13:27:29 -0700
> > > Subject: ACPI: check a return value correctly in acpi_power_get_context()
> > > 
> > > We should check *resource != NULL rather than resource != NULL, which will be
> > > always true.
> > > 
> > > Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> > > Acked-by: Zhao Yakui <yakui.zhao@intel.com>
> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > > Signed-off-by: Len Brown <len.brown@intel.com>
> > > ---
> > >  drivers/acpi/power.c |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > > index 76bf6d9..f2a76ac 100644
> > > --- a/drivers/acpi/power.c
> > > +++ b/drivers/acpi/power.c
> > > @@ -121,7 +121,7 @@ acpi_power_get_context(acpi_handle handle,
> > >  	}
> > >  
> > >  	*resource = acpi_driver_data(device);
> > > -	if (!resource)
> > > +	if (!*resource)
> > >  		return -ENODEV;
> > >  
> > >  	return 0;
> > > -- 
> > > 1.5.3.8
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [patch 00/16] Linux 2.6.25 -stable review

[Greg KH]

On Thu, May 08, 2008 at 03:16:28PM -0400, Len Brown wrote:
> On Thursday 08 May 2008, Willy Tarreau wrote:
> > On Thu, May 08, 2008 at 11:22:33AM -0700, Greg KH wrote:
> > > On Thu, May 08, 2008 at 08:13:42PM +0200, Willy Tarreau wrote:
> > > > On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
> > > > > This is the start of the stable review cycle for the 2.6.25.2 release.
> > > > > There are 16 patches in this series, all will be posted as a response to
> > > > > this one.  If anyone has any issues with these being applied, please let
> > > > > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > > > > to add a Signed-off-by: line to the patch, please respond with it.
> > > > 
> > > > Greg, shouldn't we also queue this one (may be in a later version) ? It's
> > > > in mainline.
> > > 
> > > What problem does it solve?
> > 
> > from what I see in the code, currently acpi_power_get_state() will return
> > 0 when setting resource to NULL, and some callers (eg: acpi_power_on())
> > will happily dereference resource if acpi_power_get_state() returns 0. So
> > I guess there are circumstances where we can oops.
> > 
> > > Does Len want it in -stable?
> > 
> > I simply forgot to ask. I'm CCing him.
> 
> This patch is correct.
> 
> Go ahead and apply it -- it won't hurt anything.
> I don't think it will help anything in real-life either, though.

Ok, because of that, I'll not apply it, we want patches that actually
fix reported problems.

thanks,

greg k-h

Re: [patch 00/16] Linux 2.6.25 -stable review

[Li Zefan]

Greg KH wrote:
> On Thu, May 08, 2008 at 03:16:28PM -0400, Len Brown wrote:
>> On Thursday 08 May 2008, Willy Tarreau wrote:
>>> On Thu, May 08, 2008 at 11:22:33AM -0700, Greg KH wrote:
>>>> On Thu, May 08, 2008 at 08:13:42PM +0200, Willy Tarreau wrote:
>>>>> On Thu, May 08, 2008 at 10:41:22AM -0700, Greg KH wrote:
>>>>>> This is the start of the stable review cycle for the 2.6.25.2 release.
>>>>>> There are 16 patches in this series, all will be posted as a response to
>>>>>> this one.  If anyone has any issues with these being applied, please let
>>>>>> us know.  If anyone is a maintainer of the proper subsystem, and wants
>>>>>> to add a Signed-off-by: line to the patch, please respond with it.
>>>>> Greg, shouldn't we also queue this one (may be in a later version) ? It's
>>>>> in mainline.
>>>> What problem does it solve?
>>> from what I see in the code, currently acpi_power_get_state() will return
>>> 0 when setting resource to NULL, and some callers (eg: acpi_power_on())
>>> will happily dereference resource if acpi_power_get_state() returns 0. So
>>> I guess there are circumstances where we can oops.
>>>
>>>> Does Len want it in -stable?
>>> I simply forgot to ask. I'm CCing him.
>> This patch is correct.
>>
>> Go ahead and apply it -- it won't hurt anything.
>> I don't think it will help anything in real-life either, though.
> 
> Ok, because of that, I'll not apply it, we want patches that actually
> fix reported problems.
> 

It's Ok for me. I found this when reading the code but not hitting a real-world
problem.

> thanks,
> 
> greg k-h