2012-05-18 21:27:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 00/54] 3.0.32-stable review

This is the start of the stable review cycle for the 3.0.32 release.
There are 54 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 Sun May 20 21:15:57 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/v3.0/stable-review/patch-3.0.32-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Documentation/networking/ip-sysctl.txt | 4 +-
Makefile | 4 +-
arch/arm/kernel/smp.c | 4 +-
arch/arm/kernel/sys_arm.c | 2 +-
arch/arm/mach-orion5x/mpp.h | 4 +-
arch/arm/mm/fault.c | 4 +-
arch/sparc/kernel/central.c | 2 +-
arch/sparc/mm/ultra.S | 6 +--
arch/tile/kernel/compat_signal.c | 12 ++---
arch/x86/kernel/setup_percpu.c | 14 +++++-
arch/x86/xen/enlighten.c | 7 ++-
arch/x86/xen/mmu.c | 7 ++-
drivers/acpi/sleep.c | 8 ++++
drivers/crypto/Kconfig | 1 +
drivers/gpio/Kconfig | 11 +++--
drivers/gpio/pch_gpio.c | 1 +
drivers/md/md.c | 2 +
drivers/media/rc/ene_ir.c | 32 ++++++-------
drivers/media/rc/fintek-cir.c | 20 ++++----
drivers/media/rc/ite-cir.c | 20 ++++----
drivers/media/rc/nuvoton-cir.c | 36 +++++++--------
drivers/media/rc/winbond-cir.c | 78 ++++++++++++++++----------------
drivers/net/Kconfig | 11 +++--
drivers/net/pch_gbe/pch_gbe_main.c | 50 +++++++++++++++-----
drivers/net/pch_gbe/pch_gbe_param.c | 15 +++---
drivers/net/sky2.c | 31 ++++++++-----
drivers/net/sky2.h | 1 -
drivers/net/sungem.c | 2 +-
drivers/net/tg3.c | 18 +++++++-
drivers/net/usb/asix.c | 4 +-
drivers/net/usb/cdc_ether.c | 30 +++++++++++-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/usb/usbnet.c | 54 +++++++++++++++-------
drivers/platform/x86/sony-laptop.c | 2 +-
drivers/regulator/max8997.c | 2 +-
drivers/scsi/hpsa.c | 4 +-
fs/ext3/ialloc.c | 8 +++-
fs/ext4/ialloc.c | 8 +++-
fs/ext4/xattr.c | 7 +--
fs/jffs2/gc.c | 2 +-
fs/nfs/nfs4proc.c | 1 +
fs/super.c | 2 +
include/asm-generic/statfs.h | 2 +-
include/linux/seqlock.h | 2 +-
include/linux/usb/usbnet.h | 3 +-
init/do_mounts.c | 2 +-
kernel/compat.c | 63 +++++++++++++++++++-------
kernel/fork.c | 3 ++
mm/hugetlb.c | 1 -
mm/memcontrol.c | 6 +++
mm/nobootmem.c | 3 +-
mm/percpu.c | 12 +++++
net/core/dev.c | 20 ++++++++
net/ipv4/tcp.c | 12 ++---
net/ipv4/tcp_input.c | 2 +-
net/l2tp/l2tp_ip.c | 3 +-
net/sched/sch_netem.c | 6 +--
sound/pci/echoaudio/echoaudio_dsp.c | 2 +-
sound/pci/hda/hda_intel.c | 6 ++-
59 files changed, 448 insertions(+), 233 deletions(-)


2012-05-18 23:02:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 01/54] smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Paolo Pisati <[email protected]>

commit 07d69d4238418746a7b85c5d05ec17c658a2a390 upstream.

Without this patch sysfs reports the cable as present

flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier
1

while it's not:

flag@flag-desktop:~$ sudo mii-tool eth0
eth0: no link

Tested on my Beagle XM.

v2: added mantainer to the list of recipient

Signed-off-by: Paolo Pisati <[email protected]>
Acked-by: Steve Glendinning <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1190,7 +1190,7 @@ static const struct driver_info smsc95xx
.rx_fixup = smsc95xx_rx_fixup,
.tx_fixup = smsc95xx_tx_fixup,
.status = smsc95xx_status,
- .flags = FLAG_ETHER | FLAG_SEND_ZLP,
+ .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_LINK_INTR,
};

static const struct usb_device_id products[] = {

2012-05-18 23:02:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 02/54] xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Konrad Rzeszutek Wilk <[email protected]>

commit b7e5ffe5d83fa40d702976d77452004abbe35791 upstream.

If I try to do "cat /sys/kernel/debug/kernel_page_tables"
I end up with:

BUG: unable to handle kernel paging request at ffffc7fffffff000
IP: [<ffffffff8106aa51>] ptdump_show+0x221/0x480
PGD 0
Oops: 0000 [#1] SMP
CPU 0
.. snip..
RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000
RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000

which is due to the fact we are trying to access a PFN that is not
accessible to us. The reason (at least in this case) was that
PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the
hypervisor) to point to a read-only linear map of the MFN->PFN array.
During our parsing we would get the MFN (a valid one), try to look
it up in the MFN->PFN tree and find it invalid and return ~0 as PFN.
Then pte_mfn_to_pfn would happilly feed that in, attach the flags
and return it back to the caller. 'ptdump_show' bitshifts it and
gets and invalid value that it tries to dereference.

Instead of doing all of that, we detect the ~0 case and just
return !_PAGE_PRESENT.

This bug has been in existence .. at least until 2.6.37 (yikes!)

Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/xen/mmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -320,8 +320,13 @@ static pteval_t pte_mfn_to_pfn(pteval_t
{
if (val & _PAGE_PRESENT) {
unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
+ unsigned long pfn = mfn_to_pfn(mfn);
+
pteval_t flags = val & PTE_FLAGS_MASK;
- val = ((pteval_t)mfn_to_pfn(mfn) << PAGE_SHIFT) | flags;
+ if (unlikely(pfn == ~0))
+ val = flags & ~_PAGE_PRESENT;
+ else
+ val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
}

return val;

2012-05-18 23:02:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 04/54] percpu, x86: dont use PMD_SIZE as embedded atom_size on 32bit

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Tejun Heo <[email protected]>

commit d5e28005a1d2e67833852f4c9ea8ec206ea3ff85 upstream.

With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE
or PMD_SIZE for atom_size. PMD_SIZE is used when CPU supports PSE so
that percpu areas are aligned to PMD mappings and possibly allow using
PMD mappings in vmalloc areas in the future. Using larger atom_size
doesn't waste actual memory; however, it does require larger vmalloc
space allocation later on for !first chunks.

With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem
but x86_32 at this point is anything but reasonable in terms of
address space and using larger atom_size reportedly leads to frequent
percpu allocation failures on certain setups.

As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space
is aplenty and most x86_64 configurations support PSE, fix the issue
by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32.

v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and
x86_32 PAGE_SIZE as suggested by hpa.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Yanmin Zhang <[email protected]>
Reported-by: ShuoX Liu <[email protected]>
Acked-by: H. Peter Anvin <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/setup_percpu.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/setup_percpu.c
+++ b/arch/x86/kernel/setup_percpu.c
@@ -185,10 +185,22 @@ void __init setup_per_cpu_areas(void)
#endif
rc = -EINVAL;
if (pcpu_chosen_fc != PCPU_FC_PAGE) {
- const size_t atom_size = cpu_has_pse ? PMD_SIZE : PAGE_SIZE;
const size_t dyn_size = PERCPU_MODULE_RESERVE +
PERCPU_DYNAMIC_RESERVE - PERCPU_FIRST_CHUNK_RESERVE;
+ size_t atom_size;

+ /*
+ * On 64bit, use PMD_SIZE for atom_size so that embedded
+ * percpu areas are aligned to PMD. This, in the future,
+ * can also allow using PMD mappings in vmalloc area. Use
+ * PAGE_SIZE on 32bit as vmalloc space is highly contended
+ * and large vmalloc area allocs can easily fail.
+ */
+#ifdef CONFIG_X86_64
+ atom_size = PMD_SIZE;
+#else
+ atom_size = PAGE_SIZE;
+#endif
rc = pcpu_embed_first_chunk(PERCPU_FIRST_CHUNK_RESERVE,
dyn_size, atom_size,
pcpu_cpu_distance,

2012-05-18 23:02:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 03/54] xen/pci: dont use PCI BIOS service for configuration space accesses

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: David Vrabel <[email protected]>

commit 76a8df7b49168509df02461f83fab117a4a86e08 upstream.

The accessing PCI configuration space with the PCI BIOS32 service does
not work in PV guests.

On systems without MMCONFIG or where the BIOS hasn't marked the
MMCONFIG region as reserved in the e820 map, the BIOS service is
probed (even though direct access is preferred) and this hangs.

Acked-by: Jan Beulich <[email protected]>
Signed-off-by: David Vrabel <[email protected]>
[v1: Fixed compile error when CONFIG_PCI is not set]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/xen/enlighten.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -62,6 +62,7 @@
#include <asm/reboot.h>
#include <asm/stackprotector.h>
#include <asm/hypervisor.h>
+#include <asm/pci_x86.h>

#include "xen-ops.h"
#include "mmu.h"
@@ -1259,8 +1260,10 @@ asmlinkage void __init xen_start_kernel(
/* Make sure ACS will be enabled */
pci_request_acs();
}
-
-
+#ifdef CONFIG_PCI
+ /* PCI BIOS service won't work from a PV guest. */
+ pci_probe &= ~PCI_PROBE_BIOS;
+#endif
xen_raw_console_write("about to get started...\n");

xen_setup_runstate_info(0);

2012-05-18 23:03:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 10/54] ARM: orion5x: Fix GPIO enable bits for MPP9

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Ben Hutchings <[email protected]>

commit 48d99f47a81a66bdd61a348c7fe8df5a7afdf5f3 upstream.

Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 ('ARM: orion5x: Refactor
mpp code to use common orion platform mpp.') seems to have accidentally
inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform
which uses MPP9 as a GPIO LED device, this results in the error:

[ 12.711476] leds-gpio: probe of leds-gpio failed with error -22

Reported-by: Henry von Tresckow <[email protected]>
References: http://bugs.debian.org/667446
Signed-off-by: Ben Hutchings <[email protected]>
Tested-by: Hans Henry von Tresckow <[email protected]>
Signed-off-by: Jason Cooper <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/mach-orion5x/mpp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/mach-orion5x/mpp.h
+++ b/arch/arm/mach-orion5x/mpp.h
@@ -65,8 +65,8 @@
#define MPP8_GIGE MPP(8, 0x1, 0, 0, 1, 1, 1)

#define MPP9_UNUSED MPP(9, 0x0, 0, 0, 1, 1, 1)
-#define MPP9_GPIO MPP(9, 0x0, 0, 0, 1, 1, 1)
-#define MPP9_GIGE MPP(9, 0x1, 1, 1, 1, 1, 1)
+#define MPP9_GPIO MPP(9, 0x0, 1, 1, 1, 1, 1)
+#define MPP9_GIGE MPP(9, 0x1, 0, 0, 1, 1, 1)

#define MPP10_UNUSED MPP(10, 0x0, 0, 0, 1, 1, 1)
#define MPP10_GPIO MPP(10, 0x0, 1, 1, 1, 1, 1)

2012-05-18 23:03:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 13/54] net: In unregister_netdevice_notifier unregister the netdevices.

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: "Eric W. Biederman" <[email protected]>

[ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ]

We already synthesize events in register_netdevice_notifier and synthesizing
events in unregister_netdevice_notifier allows to us remove the need for
special case cleanup code.

This change should be safe as it adds no new cases for existing callers
of unregiser_netdevice_notifier to handle.

Signed-off-by: Eric W. Biederman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/dev.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1406,14 +1406,34 @@ EXPORT_SYMBOL(register_netdevice_notifie
* register_netdevice_notifier(). The notifier is unlinked into the
* kernel structures and may then be reused. A negative errno code
* is returned on a failure.
+ *
+ * After unregistering unregister and down device events are synthesized
+ * for all devices on the device list to the removed notifier to remove
+ * the need for special case cleanup code.
*/

int unregister_netdevice_notifier(struct notifier_block *nb)
{
+ struct net_device *dev;
+ struct net *net;
int err;

rtnl_lock();
err = raw_notifier_chain_unregister(&netdev_chain, nb);
+ if (err)
+ goto unlock;
+
+ for_each_net(net) {
+ for_each_netdev(net, dev) {
+ if (dev->flags & IFF_UP) {
+ nb->notifier_call(nb, NETDEV_GOING_DOWN, dev);
+ nb->notifier_call(nb, NETDEV_DOWN, dev);
+ }
+ nb->notifier_call(nb, NETDEV_UNREGISTER, dev);
+ nb->notifier_call(nb, NETDEV_UNREGISTER_BATCH, dev);
+ }
+ }
+unlock:
rtnl_unlock();
return err;
}

2012-05-18 23:03:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 18/54] sungem: Fix WakeOnLan

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: Gerard Lledo <[email protected]>

[ Upstream commit 5a8887d39e1ba5ee2d4ccb94b14d6f2dce5ddfca ]

WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit
bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5).
gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting
gp->wake_on_lan to bool. Tested on an iBook G4.

Signed-off-by: Gerard Lledo <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/sungem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/sungem.c
+++ b/drivers/net/sungem.c
@@ -2363,7 +2363,7 @@ static int gem_suspend(struct pci_dev *p
netif_device_detach(dev);

/* Switch off MAC, remember WOL setting */
- gp->asleep_wol = gp->wake_on_lan;
+ gp->asleep_wol = !!gp->wake_on_lan;
gem_do_stop(dev, gp->asleep_wol);
} else
gp->asleep_wol = 0;

2012-05-18 23:03:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 25/54] sparc64: Do not clobber %g2 in xcall_fetch_glob_regs().

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: "David S. Miller" <[email protected]>

[ Upstream commit a5a737e090e25981e99d69f01400e3a80356581c ]

%g2 is meant to hold the CPUID number throughout this routine, since
at the very beginning, and at the very end, we use %g2 to calculate
indexes into per-cpu arrays.

However we erroneously clobber it in order to hold the %cwp register
value mid-stream.

Fix this code to use %g3 for the %cwp read and related calulcations
instead.

Reported-by: Meelis Roos <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/sparc/kernel/central.c | 2 +-
arch/sparc/mm/ultra.S | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)

--- a/arch/sparc/kernel/central.c
+++ b/arch/sparc/kernel/central.c
@@ -268,4 +268,4 @@ static int __init sunfire_init(void)
return 0;
}

-subsys_initcall(sunfire_init);
+fs_initcall(sunfire_init);
--- a/arch/sparc/mm/ultra.S
+++ b/arch/sparc/mm/ultra.S
@@ -495,11 +495,11 @@ xcall_fetch_glob_regs:
stx %o7, [%g1 + GR_SNAP_O7]
stx %i7, [%g1 + GR_SNAP_I7]
/* Don't try this at home kids... */
- rdpr %cwp, %g2
- sub %g2, 1, %g7
+ rdpr %cwp, %g3
+ sub %g3, 1, %g7
wrpr %g7, %cwp
mov %i7, %g7
- wrpr %g2, %cwp
+ wrpr %g3, %cwp
stx %g7, [%g1 + GR_SNAP_RPC]
sethi %hi(trap_block), %g7
or %g7, %lo(trap_block), %g7

2012-05-18 23:04:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 27/54] media: rc: Postpone ISR registration

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Luis Henriques <[email protected]>

commit 9ef449c6b31bb6a8e6dedc24de475a3b8c79be20 upstream.

An early registration of an ISR was causing a crash to several users (for
example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
The reason was that IRQs were being triggered before a driver
initialisation was completed.

This patch fixes this by moving the invocation to request_irq() and to
request_region() to a later stage on the driver probe function.

Signed-off-by: Luis Henriques <[email protected]>
Acked-by: Jarod Wilson <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/rc/ene_ir.c | 32 ++++++++--------
drivers/media/rc/fintek-cir.c | 20 +++++-----
drivers/media/rc/ite-cir.c | 20 +++++-----
drivers/media/rc/nuvoton-cir.c | 36 +++++++++---------
drivers/media/rc/winbond-cir.c | 78 ++++++++++++++++++++---------------------
5 files changed, 93 insertions(+), 93 deletions(-)

--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1017,22 +1017,6 @@ static int ene_probe(struct pnp_dev *pnp

spin_lock_init(&dev->hw_lock);

- /* claim the resources */
- error = -EBUSY;
- dev->hw_io = pnp_port_start(pnp_dev, 0);
- if (!request_region(dev->hw_io, ENE_IO_SIZE, ENE_DRIVER_NAME)) {
- dev->hw_io = -1;
- dev->irq = -1;
- goto error;
- }
-
- dev->irq = pnp_irq(pnp_dev, 0);
- if (request_irq(dev->irq, ene_isr,
- IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev)) {
- dev->irq = -1;
- goto error;
- }
-
pnp_set_drvdata(pnp_dev, dev);
dev->pnp_dev = pnp_dev;

@@ -1085,6 +1069,22 @@ static int ene_probe(struct pnp_dev *pnp
device_set_wakeup_capable(&pnp_dev->dev, true);
device_set_wakeup_enable(&pnp_dev->dev, true);

+ /* claim the resources */
+ error = -EBUSY;
+ dev->hw_io = pnp_port_start(pnp_dev, 0);
+ if (!request_region(dev->hw_io, ENE_IO_SIZE, ENE_DRIVER_NAME)) {
+ dev->hw_io = -1;
+ dev->irq = -1;
+ goto error;
+ }
+
+ dev->irq = pnp_irq(pnp_dev, 0);
+ if (request_irq(dev->irq, ene_isr,
+ IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev)) {
+ dev->irq = -1;
+ goto error;
+ }
+
error = rc_register_device(rdev);
if (error < 0)
goto error;
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -504,16 +504,6 @@ static int fintek_probe(struct pnp_dev *

spin_lock_init(&fintek->fintek_lock);

- ret = -EBUSY;
- /* now claim resources */
- if (!request_region(fintek->cir_addr,
- fintek->cir_port_len, FINTEK_DRIVER_NAME))
- goto failure;
-
- if (request_irq(fintek->cir_irq, fintek_cir_isr, IRQF_SHARED,
- FINTEK_DRIVER_NAME, (void *)fintek))
- goto failure;
-
pnp_set_drvdata(pdev, fintek);
fintek->pdev = pdev;

@@ -548,6 +538,16 @@ static int fintek_probe(struct pnp_dev *
/* rx resolution is hardwired to 50us atm, 1, 25, 100 also possible */
rdev->rx_resolution = US_TO_NS(CIR_SAMPLE_PERIOD);

+ ret = -EBUSY;
+ /* now claim resources */
+ if (!request_region(fintek->cir_addr,
+ fintek->cir_port_len, FINTEK_DRIVER_NAME))
+ goto failure;
+
+ if (request_irq(fintek->cir_irq, fintek_cir_isr, IRQF_SHARED,
+ FINTEK_DRIVER_NAME, (void *)fintek))
+ goto failure;
+
ret = rc_register_device(rdev);
if (ret)
goto failure;
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1519,16 +1519,6 @@ static int ite_probe(struct pnp_dev *pde
/* initialize raw event */
init_ir_raw_event(&itdev->rawir);

- ret = -EBUSY;
- /* now claim resources */
- if (!request_region(itdev->cir_addr,
- dev_desc->io_region_size, ITE_DRIVER_NAME))
- goto failure;
-
- if (request_irq(itdev->cir_irq, ite_cir_isr, IRQF_SHARED,
- ITE_DRIVER_NAME, (void *)itdev))
- goto failure;
-
/* set driver data into the pnp device */
pnp_set_drvdata(pdev, itdev);
itdev->pdev = pdev;
@@ -1604,6 +1594,16 @@ static int ite_probe(struct pnp_dev *pde
rdev->driver_name = ITE_DRIVER_NAME;
rdev->map_name = RC_MAP_RC6_MCE;

+ ret = -EBUSY;
+ /* now claim resources */
+ if (!request_region(itdev->cir_addr,
+ dev_desc->io_region_size, ITE_DRIVER_NAME))
+ goto failure;
+
+ if (request_irq(itdev->cir_irq, ite_cir_isr, IRQF_SHARED,
+ ITE_DRIVER_NAME, (void *)itdev))
+ goto failure;
+
ret = rc_register_device(rdev);
if (ret)
goto failure;
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -1027,24 +1027,6 @@ static int nvt_probe(struct pnp_dev *pde
spin_lock_init(&nvt->nvt_lock);
spin_lock_init(&nvt->tx.lock);

- ret = -EBUSY;
- /* now claim resources */
- if (!request_region(nvt->cir_addr,
- CIR_IOREG_LENGTH, NVT_DRIVER_NAME))
- goto failure;
-
- if (request_irq(nvt->cir_irq, nvt_cir_isr, IRQF_SHARED,
- NVT_DRIVER_NAME, (void *)nvt))
- goto failure;
-
- if (!request_region(nvt->cir_wake_addr,
- CIR_IOREG_LENGTH, NVT_DRIVER_NAME))
- goto failure;
-
- if (request_irq(nvt->cir_wake_irq, nvt_cir_wake_isr, IRQF_SHARED,
- NVT_DRIVER_NAME, (void *)nvt))
- goto failure;
-
pnp_set_drvdata(pdev, nvt);
nvt->pdev = pdev;

@@ -1091,6 +1073,24 @@ static int nvt_probe(struct pnp_dev *pde
rdev->tx_resolution = XYZ;
#endif

+ ret = -EBUSY;
+ /* now claim resources */
+ if (!request_region(nvt->cir_addr,
+ CIR_IOREG_LENGTH, NVT_DRIVER_NAME))
+ goto failure;
+
+ if (request_irq(nvt->cir_irq, nvt_cir_isr, IRQF_SHARED,
+ NVT_DRIVER_NAME, (void *)nvt))
+ goto failure;
+
+ if (!request_region(nvt->cir_wake_addr,
+ CIR_IOREG_LENGTH, NVT_DRIVER_NAME))
+ goto failure;
+
+ if (request_irq(nvt->cir_wake_irq, nvt_cir_wake_isr, IRQF_SHARED,
+ NVT_DRIVER_NAME, (void *)nvt))
+ goto failure;
+
ret = rc_register_device(rdev);
if (ret)
goto failure;
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1003,39 +1003,10 @@ wbcir_probe(struct pnp_dev *device, cons
"(w: 0x%lX, e: 0x%lX, s: 0x%lX, i: %u)\n",
data->wbase, data->ebase, data->sbase, data->irq);

- if (!request_region(data->wbase, WAKEUP_IOMEM_LEN, DRVNAME)) {
- dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
- data->wbase, data->wbase + WAKEUP_IOMEM_LEN - 1);
- err = -EBUSY;
- goto exit_free_data;
- }
-
- if (!request_region(data->ebase, EHFUNC_IOMEM_LEN, DRVNAME)) {
- dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
- data->ebase, data->ebase + EHFUNC_IOMEM_LEN - 1);
- err = -EBUSY;
- goto exit_release_wbase;
- }
-
- if (!request_region(data->sbase, SP_IOMEM_LEN, DRVNAME)) {
- dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
- data->sbase, data->sbase + SP_IOMEM_LEN - 1);
- err = -EBUSY;
- goto exit_release_ebase;
- }
-
- err = request_irq(data->irq, wbcir_irq_handler,
- IRQF_DISABLED, DRVNAME, device);
- if (err) {
- dev_err(dev, "Failed to claim IRQ %u\n", data->irq);
- err = -EBUSY;
- goto exit_release_sbase;
- }
-
led_trigger_register_simple("cir-tx", &data->txtrigger);
if (!data->txtrigger) {
err = -ENOMEM;
- goto exit_free_irq;
+ goto exit_free_data;
}

led_trigger_register_simple("cir-rx", &data->rxtrigger);
@@ -1074,9 +1045,38 @@ wbcir_probe(struct pnp_dev *device, cons
data->dev->priv = data;
data->dev->dev.parent = &device->dev;

+ if (!request_region(data->wbase, WAKEUP_IOMEM_LEN, DRVNAME)) {
+ dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
+ data->wbase, data->wbase + WAKEUP_IOMEM_LEN - 1);
+ err = -EBUSY;
+ goto exit_free_rc;
+ }
+
+ if (!request_region(data->ebase, EHFUNC_IOMEM_LEN, DRVNAME)) {
+ dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
+ data->ebase, data->ebase + EHFUNC_IOMEM_LEN - 1);
+ err = -EBUSY;
+ goto exit_release_wbase;
+ }
+
+ if (!request_region(data->sbase, SP_IOMEM_LEN, DRVNAME)) {
+ dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
+ data->sbase, data->sbase + SP_IOMEM_LEN - 1);
+ err = -EBUSY;
+ goto exit_release_ebase;
+ }
+
+ err = request_irq(data->irq, wbcir_irq_handler,
+ IRQF_DISABLED, DRVNAME, device);
+ if (err) {
+ dev_err(dev, "Failed to claim IRQ %u\n", data->irq);
+ err = -EBUSY;
+ goto exit_release_sbase;
+ }
+
err = rc_register_device(data->dev);
if (err)
- goto exit_free_rc;
+ goto exit_free_irq;

device_init_wakeup(&device->dev, 1);

@@ -1084,14 +1084,6 @@ wbcir_probe(struct pnp_dev *device, cons

return 0;

-exit_free_rc:
- rc_free_device(data->dev);
-exit_unregister_led:
- led_classdev_unregister(&data->led);
-exit_unregister_rxtrigger:
- led_trigger_unregister_simple(data->rxtrigger);
-exit_unregister_txtrigger:
- led_trigger_unregister_simple(data->txtrigger);
exit_free_irq:
free_irq(data->irq, device);
exit_release_sbase:
@@ -1100,6 +1092,14 @@ exit_release_ebase:
release_region(data->ebase, EHFUNC_IOMEM_LEN);
exit_release_wbase:
release_region(data->wbase, WAKEUP_IOMEM_LEN);
+exit_free_rc:
+ rc_free_device(data->dev);
+exit_unregister_led:
+ led_classdev_unregister(&data->led);
+exit_unregister_rxtrigger:
+ led_trigger_unregister_simple(data->rxtrigger);
+exit_unregister_txtrigger:
+ led_trigger_unregister_simple(data->txtrigger);
exit_free_data:
kfree(data);
pnp_set_drvdata(device, NULL);

2012-05-18 23:04:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 29/54] cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Williams <[email protected]>

commit 4e6304b8420aba5311ba21fd68dab2924ae4d91a upstream.

Needs to be tagged with FLAG_WWAN, which since it has generic
descriptors, won't happen if we don't override the generic
driver info.

Cc: Oliver Neukum <[email protected]>
Cc: [email protected]
Signed-off-by: Dan Williams <[email protected]>
Acked-by: Oliver Neukum <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/usb/cdc_ether.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -482,6 +482,7 @@ static const struct driver_info wwan_inf
/*-------------------------------------------------------------------------*/

#define HUAWEI_VENDOR_ID 0x12D1
+#define NOVATEL_VENDOR_ID 0x1410

static const struct usb_device_id products [] = {
/*
@@ -599,6 +600,21 @@ static const struct usb_device_id produc
* because of bugs/quirks in a given product (like Zaurus, above).
*/
{
+ /* Novatel USB551L */
+ /* This match must come *before* the generic CDC-ETHER match so that
+ * we get FLAG_WWAN set on the device, since it's descriptors are
+ * generic CDC-ETHER.
+ */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_PRODUCT
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = NOVATEL_VENDOR_ID,
+ .idProduct = 0xB001,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long)&wwan_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,

2012-05-18 23:04:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 32/54] hugetlb: prevent BUG_ON in hugetlb_fault() -> hugetlb_cow()

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Chris Metcalf <[email protected]>

commit 4998a6c0edce7fae9c0a5463f6ec3fa585258ee7 upstream.

Commit 66aebce747eaf ("hugetlb: fix race condition in hugetlb_fault()")
added code to avoid a race condition by elevating the page refcount in
hugetlb_fault() while calling hugetlb_cow().

However, one code path in hugetlb_cow() includes an assertion that the
page count is 1, whereas it may now also have the value 2 in this path.

The consensus is that this BUG_ON has served its purpose, so rather than
extending it to cover both cases, we just remove it.

Signed-off-by: Chris Metcalf <[email protected]>
Acked-by: Mel Gorman <[email protected]>
Acked-by: Hillf Danton <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/hugetlb.c | 1 -
1 file changed, 1 deletion(-)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2398,7 +2398,6 @@ retry_avoidcopy:
if (outside_reserve) {
BUG_ON(huge_pte_none(pte));
if (unmap_ref_private(mm, vma, old_page, address)) {
- BUG_ON(page_count(old_page) != 1);
BUG_ON(huge_pte_none(pte));
spin_lock(&mm->page_table_lock);
goto retry_avoidcopy;

2012-05-18 23:04:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 34/54] jffs2: Fix lock acquisition order bug in gc path

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Josh Cartwright <[email protected]>

commit 226bb7df3d22bcf4a1c0fe8206c80cc427498eae upstream.

The locking policy is such that the erase_complete_block spinlock is
nested within the alloc_sem mutex. This fixes a case in which the
acquisition order was erroneously reversed. This issue was caught by
the following lockdep splat:

=======================================================
[ INFO: possible circular locking dependency detected ]
3.0.5 #1
-------------------------------------------------------
jffs2_gcd_mtd6/299 is trying to acquire lock:
(&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890

but task is already holding lock:
(&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&(&c->erase_completion_lock)->rlock){+.+...}:
[<c008bec4>] validate_chain+0xe6c/0x10bc
[<c008c660>] __lock_acquire+0x54c/0xba4
[<c008d240>] lock_acquire+0xa4/0x114
[<c046780c>] _raw_spin_lock+0x3c/0x4c
[<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890
[<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
[<c0071a68>] kthread+0x98/0xa0
[<c000f264>] kernel_thread_exit+0x0/0x8

-> #0 (&c->alloc_sem){+.+.+.}:
[<c008ad2c>] print_circular_bug+0x70/0x2c4
[<c008c08c>] validate_chain+0x1034/0x10bc
[<c008c660>] __lock_acquire+0x54c/0xba4
[<c008d240>] lock_acquire+0xa4/0x114
[<c0466628>] mutex_lock_nested+0x74/0x33c
[<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
[<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
[<c0071a68>] kthread+0x98/0xa0
[<c000f264>] kernel_thread_exit+0x0/0x8

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&(&c->erase_completion_lock)->rlock);
lock(&c->alloc_sem);
lock(&(&c->erase_completion_lock)->rlock);
lock(&c->alloc_sem);

*** DEADLOCK ***

1 lock held by jffs2_gcd_mtd6/299:
#0: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890

stack backtrace:
[<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24)
[<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4)
[<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc)
[<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4)
[<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114)
[<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c)
[<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890)
[<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc)
[<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0)
[<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8)

This was introduce in '81cfc9f jffs2: Fix serious write stall due to erase'.

Signed-off-by: Josh Cartwright <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/jffs2/gc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/jffs2/gc.c
+++ b/fs/jffs2/gc.c
@@ -225,8 +225,8 @@ int jffs2_garbage_collect_pass(struct jf
return 0;

D1(printk(KERN_DEBUG "No progress from erasing blocks; doing GC anyway\n"));
- spin_lock(&c->erase_completion_lock);
mutex_lock(&c->alloc_sem);
+ spin_lock(&c->erase_completion_lock);
}

/* First, work out which block we're garbage-collecting */

2012-05-18 23:04:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 40/54] ext4: avoid deadlock on sync-mounted FS w/o journal

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Sandeen <[email protected]>

commit c1bb05a657fb3d8c6179a4ef7980261fae4521d7 upstream.

Processes hang forever on a sync-mounted ext2 file system that
is mounted with the ext4 module (default in Fedora 16).

I can reproduce this reliably by mounting an ext2 partition with
"-o sync" and opening a new file an that partition with vim. vim
will hang in "D" state forever. The same happens on ext4 without
a journal.

I am attaching a small patch here that solves this issue for me.
In the sync mounted case without a journal,
ext4_handle_dirty_metadata() may call sync_dirty_buffer(), which
can't be called with buffer lock held.

Also move mb_cache_entry_release inside lock to avoid race
fixed previously by 8a2bfdcb ext[34]: EA block reference count racing fix
Note too that ext2 fixed this same problem in 2006 with
b2f49033 [PATCH] fix deadlock in ext2

Signed-off-by: [email protected]
[[email protected]: move mb_cache_entry_release before unlock, edit commit msg]
Signed-off-by: Eric Sandeen <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/xattr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -487,18 +487,19 @@ ext4_xattr_release_block(handle_t *handl
ext4_free_blocks(handle, inode, bh, 0, 1,
EXT4_FREE_BLOCKS_METADATA |
EXT4_FREE_BLOCKS_FORGET);
+ unlock_buffer(bh);
} else {
le32_add_cpu(&BHDR(bh)->h_refcount, -1);
+ if (ce)
+ mb_cache_entry_release(ce);
+ unlock_buffer(bh);
error = ext4_handle_dirty_metadata(handle, inode, bh);
if (IS_SYNC(inode))
ext4_handle_sync(handle);
dquot_free_block(inode, 1);
ea_bdebug(bh, "refcount now=%d; releasing",
le32_to_cpu(BHDR(bh)->h_refcount));
- if (ce)
- mb_cache_entry_release(ce);
}
- unlock_buffer(bh);
out:
ext4_std_error(inode->i_sb, error);
return;

2012-05-18 23:05:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 46/54] ACPI / PM: Add Sony Vaio VPCCW29FX to nonvs blacklist.

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Lan Tianyu <[email protected]>

commit 93f770846e8dedc5d9117bd4ad9d7efd18420627 upstream.

Sony Vaio VPCCW29FX does not resume correctly without
acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.

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

Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/sleep.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -422,6 +422,14 @@ static struct dmi_system_id __initdata a
},
{
.callback = init_nvs_nosave,
+ .ident = "Sony Vaio VPCCW29FX",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VPCCW29FX"),
+ },
+ },
+ {
+ .callback = init_nvs_nosave,
.ident = "Averatec AV1020-ED2",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "AVERATEC"),

2012-05-18 23:05:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 48/54] wake up s_wait_unfrozen when ->freeze_fs fails

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Kazuya Mio <[email protected]>

commit e1616300a20c80396109c1cf013ba9a36055a3da upstream.

dd slept infinitely when fsfeeze failed because of EIO.
To fix this problem, if ->freeze_fs fails, freeze_super() wakes up
the tasks waiting for the filesystem to become unfrozen.

When s_frozen isn't SB_UNFROZEN in __generic_file_aio_write(),
the function sleeps until FITHAW ioctl wakes up s_wait_unfrozen.

However, if ->freeze_fs fails, s_frozen is set to SB_UNFROZEN and then
freeze_super() returns an error number. In this case, FITHAW ioctl returns
EINVAL because s_frozen is already SB_UNFROZEN. There is no way to wake up
s_wait_unfrozen, so __generic_file_aio_write() sleeps infinitely.

Signed-off-by: Kazuya Mio <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/fs/super.c
+++ b/fs/super.c
@@ -1009,6 +1009,8 @@ int freeze_super(struct super_block *sb)
printk(KERN_ERR
"VFS:Filesystem freeze failed\n");
sb->s_frozen = SB_UNFROZEN;
+ smp_wmb();
+ wake_up(&sb->s_wait_unfrozen);
deactivate_locked_super(sb);
return ret;
}

2012-05-18 23:05:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 51/54] pch_gbe: support ML7831 IOH

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Toshiharu Okada <[email protected]>

commit 7756332f5b64c9c1535712b9679792e8bd4f0019 upstream.

Support new device OKI SEMICONDUCTOR ML7831 IOH(Input/Output Hub)

ML7831 is for general purpose use.
ML7831 is companion chip for Intel Atom E6xx series.
ML7831 is completely compatible for Intel EG20T PCH.

Signed-off-by: Toshiharu Okada <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Tomoya MORINAGA <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/Kconfig | 11 ++++++-----
drivers/net/pch_gbe/pch_gbe_main.c | 10 ++++++++++
2 files changed, 16 insertions(+), 5 deletions(-)

--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2543,7 +2543,7 @@ config S6GMAC
source "drivers/net/stmmac/Kconfig"

config PCH_GBE
- tristate "Intel EG20T PCH / OKI SEMICONDUCTOR ML7223 IOH GbE"
+ tristate "Intel EG20T PCH/OKI SEMICONDUCTOR IOH(ML7223/ML7831) GbE"
depends on PCI
select MII
---help---
@@ -2556,10 +2556,11 @@ config PCH_GBE
This driver enables Gigabit Ethernet function.

This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
- Output Hub), ML7223.
- ML7223 IOH is for MP(Media Phone) use.
- ML7223 is companion chip for Intel Atom E6xx series.
- ML7223 is completely compatible for Intel EG20T PCH.
+ Output Hub), ML7223/ML7831.
+ ML7223 IOH is for MP(Media Phone) use. ML7831 IOH is for general
+ purpose use.
+ ML7223/ML7831 is companion chip for Intel Atom E6xx series.
+ ML7223/ML7831 is completely compatible for Intel EG20T PCH.

endif # NETDEV_1000

--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -39,6 +39,9 @@ const char pch_driver_version[] = DRV_VE
#define PCI_VENDOR_ID_ROHM 0x10db
#define PCI_DEVICE_ID_ROHM_ML7223_GBE 0x8013

+/* Macros for ML7831 */
+#define PCI_DEVICE_ID_ROHM_ML7831_GBE 0x8802
+
#define PCH_GBE_TX_WEIGHT 64
#define PCH_GBE_RX_WEIGHT 64
#define PCH_GBE_RX_BUFFER_WRITE 16
@@ -2457,6 +2460,13 @@ static DEFINE_PCI_DEVICE_TABLE(pch_gbe_p
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
.class = (PCI_CLASS_NETWORK_ETHERNET << 8),
+ .class_mask = (0xFFFF00)
+ },
+ {.vendor = PCI_VENDOR_ID_ROHM,
+ .device = PCI_DEVICE_ID_ROHM_ML7831_GBE,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .class = (PCI_CLASS_NETWORK_ETHERNET << 8),
.class_mask = (0xFFFF00)
},
/* required last entry */

2012-05-18 23:05:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 44/54] ext3: Fix error handling on inode bitmap corruption

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Jan Kara <[email protected]>

commit 1415dd8705394399d59a3df1ab48d149e1e41e77 upstream.

When insert_inode_locked() fails in ext3_new_inode() it most likely
means inode bitmap got corrupted and we allocated again inode which
is already in use. Also doing unlock_new_inode() during error recovery
is wrong since inode does not have I_NEW set. Fix the problem by jumping
to fail: (instead of fail_drop:) which declares filesystem error and
does not call unlock_new_inode().

Reviewed-by: Eric Sandeen <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext3/ialloc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/fs/ext3/ialloc.c
+++ b/fs/ext3/ialloc.c
@@ -561,8 +561,12 @@ got:
if (IS_DIRSYNC(inode))
handle->h_sync = 1;
if (insert_inode_locked(inode) < 0) {
- err = -EINVAL;
- goto fail_drop;
+ /*
+ * Likely a bitmap corruption causing inode to be allocated
+ * twice.
+ */
+ err = -EIO;
+ goto fail;
}
spin_lock(&sbi->s_next_gen_lock);
inode->i_generation = sbi->s_next_generation++;

2012-05-18 23:05:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 52/54] pch_gbe: Fixed the issue on which PC was frozen when link was downed.

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Toshiharu Okada <[email protected]>

commit 5f3a11419099d5cc010cfbfc524ca10d8fb81f89 upstream.

When a link was downed during network use,
there is an issue on which PC freezes.

This patch fixed this issue.

Signed-off-by: Toshiharu Okada <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Tomoya MORINAGA <[email protected]>

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

--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -2128,7 +2128,7 @@ static int pch_gbe_napi_poll(struct napi
/* If no Tx and not enough Rx work done,
* exit the polling mode
*/
- if ((work_done < budget) || !netif_running(netdev))
+ if (work_done < budget)
poll_end_flag = true;
}


2012-05-18 23:05:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 54/54] pch_gbe: memory corruption calling pch_gbe_validate_option()

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

commit 73f98eab9b9e0bab492ca06add5657d9e702ddb1 upstream.

pch_gbe_validate_option() modifies 32 bits of memory but we pass
&hw->phy.autoneg_advertised which only has 16 bits and &hw->mac.fc
which only has 8 bits.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Tomoya MORINAGA <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/pch_gbe/pch_gbe_param.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)

--- a/drivers/net/pch_gbe/pch_gbe_param.c
+++ b/drivers/net/pch_gbe/pch_gbe_param.c
@@ -320,10 +320,10 @@ static void pch_gbe_check_copper_options
pr_debug("AutoNeg specified along with Speed or Duplex, AutoNeg parameter ignored\n");
hw->phy.autoneg_advertised = opt.def;
} else {
- hw->phy.autoneg_advertised = AutoNeg;
- pch_gbe_validate_option(
- (int *)(&hw->phy.autoneg_advertised),
- &opt, adapter);
+ int tmp = AutoNeg;
+
+ pch_gbe_validate_option(&tmp, &opt, adapter);
+ hw->phy.autoneg_advertised = tmp;
}
}

@@ -494,9 +494,10 @@ void pch_gbe_check_options(struct pch_gb
.arg = { .l = { .nr = (int)ARRAY_SIZE(fc_list),
.p = fc_list } }
};
- hw->mac.fc = FlowControl;
- pch_gbe_validate_option((int *)(&hw->mac.fc),
- &opt, adapter);
+ int tmp = FlowControl;
+
+ pch_gbe_validate_option(&tmp, &opt, adapter);
+ hw->mac.fc = tmp;
}

pch_gbe_check_copper_options(adapter);

2012-05-18 23:22:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 53/54] pch_gbe: Do not abort probe on bad MAC

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Darren Hart <[email protected]>

commit 2b53d07891630dead46d65c8f896955fd3ae0302 upstream.

If the MAC is invalid or not implemented, do not abort the probe. Issue
a warning and prevent bringing the interface up until a MAC is set manually
(via ifconfig $IFACE hw ether $MAC).

Tested on two platforms, one with a valid MAC, the other without a MAC. The real
MAC is used if present, the interface fails to come up until the MAC is set on
the other. They successfully get an IP over DHCP and pass a simple ping and
login over ssh test.

This is meant to allow the Inforce SYS940X development board:
http://www.inforcecomputing.com/SYS940X_ECX.html
(and others suffering from a missing MAC) to work with the mainline kernel.
Without this patch, the probe will fail and the interface will not be created,
preventing the user from configuring the MAC manually.

This does not make any attempt to address a missing or invalid MAC for the
pch_phub driver.

Signed-off-by: Darren Hart <[email protected]>
CC: Arjan van de Ven <[email protected]>
CC: Alan Cox <[email protected]>
CC: Tomoya MORINAGA <[email protected]>
CC: Jeff Kirsher <[email protected]>
CC: "David S. Miller" <[email protected]>
CC: Paul Gortmaker <[email protected]>
CC: Jon Mason <[email protected]>
CC: [email protected]
CC: Mark Brown <[email protected]>
CC: David Laight <[email protected]>
CC: Joe Perches <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Tomoya MORINAGA <[email protected]>

---
drivers/net/pch_gbe/pch_gbe_main.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)

--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -1710,6 +1710,12 @@ int pch_gbe_up(struct pch_gbe_adapter *a
struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
int err;

+ /* Ensure we have a valid MAC */
+ if (!is_valid_ether_addr(adapter->hw.mac.addr)) {
+ pr_err("Error: Invalid MAC address\n");
+ return -EINVAL;
+ }
+
/* hardware has been reset, we need to reload some things */
pch_gbe_set_multi(netdev);

@@ -2402,9 +2408,14 @@ static int pch_gbe_probe(struct pci_dev

memcpy(netdev->dev_addr, adapter->hw.mac.addr, netdev->addr_len);
if (!is_valid_ether_addr(netdev->dev_addr)) {
- dev_err(&pdev->dev, "Invalid MAC Address\n");
- ret = -EIO;
- goto err_free_adapter;
+ /*
+ * If the MAC is invalid (or just missing), display a warning
+ * but do not abort setting up the device. pch_gbe_up will
+ * prevent the interface from being brought up until a valid MAC
+ * is set.
+ */
+ dev_err(&pdev->dev, "Invalid MAC address, "
+ "interface disabled.\n");
}
setup_timer(&adapter->watchdog_timer, pch_gbe_watchdog,
(unsigned long)adapter);

2012-05-18 23:22:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 50/54] pch_gbe: fixed the issue which receives an unnecessary packet.

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Toshiharu Okada <[email protected]>

commit 5229d87edcd80a3bceb0708ebd767faff2e589a9 upstream.

This patch fixed the issue which receives an unnecessary packet before link

When using PHY of GMII, an unnecessary packet is received,
And it becomes impossible to receive a packet after link up.

Signed-off-by: Toshiharu Okada <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Tomoya MORINAGA <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/pch_gbe/pch_gbe_main.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)

--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -717,13 +717,6 @@ static void pch_gbe_configure_rx(struct
iowrite32(rdba, &hw->reg->RX_DSC_BASE);
iowrite32(rdlen, &hw->reg->RX_DSC_SIZE);
iowrite32((rdba + rdlen), &hw->reg->RX_DSC_SW_P);
-
- /* Enables Receive DMA */
- rxdma = ioread32(&hw->reg->DMA_CTRL);
- rxdma |= PCH_GBE_RX_DMA_EN;
- iowrite32(rxdma, &hw->reg->DMA_CTRL);
- /* Enables Receive */
- iowrite32(PCH_GBE_MRE_MAC_RX_EN, &hw->reg->MAC_RX_EN);
}

/**
@@ -1097,6 +1090,19 @@ void pch_gbe_update_stats(struct pch_gbe
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}

+static void pch_gbe_start_receive(struct pch_gbe_hw *hw)
+{
+ u32 rxdma;
+
+ /* Enables Receive DMA */
+ rxdma = ioread32(&hw->reg->DMA_CTRL);
+ rxdma |= PCH_GBE_RX_DMA_EN;
+ iowrite32(rxdma, &hw->reg->DMA_CTRL);
+ /* Enables Receive */
+ iowrite32(PCH_GBE_MRE_MAC_RX_EN, &hw->reg->MAC_RX_EN);
+ return;
+}
+
/**
* pch_gbe_intr - Interrupt Handler
* @irq: Interrupt number
@@ -1717,6 +1723,7 @@ int pch_gbe_up(struct pch_gbe_adapter *a
pch_gbe_alloc_tx_buffers(adapter, tx_ring);
pch_gbe_alloc_rx_buffers(adapter, rx_ring, rx_ring->count);
adapter->tx_queue_len = netdev->tx_queue_len;
+ pch_gbe_start_receive(&adapter->hw);

mod_timer(&adapter->watchdog_timer, jiffies);


2012-05-18 23:23:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 49/54] pch_gpio: Support new device LAPIS Semiconductor ML7831 IOH

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Tomoya MORINAGA <[email protected]>

commit 868fea0507308b6548bba7debe5f5c2d5ca47fca upstream.

ML7831 is companion chip for Intel Atom E6xx series.

Signed-off-by: Grant Likely <[email protected]>
Signed-off-by: Tomoya MORINAGA <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpio/Kconfig | 11 ++++++-----
drivers/gpio/pch_gpio.c | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)

--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -350,18 +350,19 @@ config GPIO_LANGWELL
Say Y here to support Intel Langwell/Penwell GPIO.

config GPIO_PCH
- tristate "Intel EG20T PCH / OKI SEMICONDUCTOR ML7223 IOH GPIO"
+ tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7223/ML7831) GPIO"
depends on PCI && X86
help
This driver is for PCH(Platform controller Hub) GPIO of Intel Topcliff
which is an IOH(Input/Output Hub) for x86 embedded processor.
This driver can access PCH GPIO device.

- This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
- Output Hub), ML7223.
+ This driver also can be used for LAPIS Semiconductor IOH(Input/
+ Output Hub), ML7223 and ML7831.
ML7223 IOH is for MP(Media Phone) use.
- ML7223 is companion chip for Intel Atom E6xx series.
- ML7223 is completely compatible for Intel EG20T PCH.
+ ML7831 IOH is for general purpose use.
+ ML7223/ML7831 is companion chip for Intel Atom E6xx series.
+ ML7223/ML7831 is completely compatible for Intel EG20T PCH.

config GPIO_ML_IOH
tristate "OKI SEMICONDUCTOR ML7213 IOH GPIO support"
--- a/drivers/gpio/pch_gpio.c
+++ b/drivers/gpio/pch_gpio.c
@@ -287,6 +287,7 @@ static int pch_gpio_resume(struct pci_de
static DEFINE_PCI_DEVICE_TABLE(pch_gpio_pcidev_id) = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) },
{ PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) },
+ { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) },
{ 0, }
};
MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id);

2012-05-18 23:23:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 47/54] SCSI: hpsa: Add IRQF_SHARED back in for the non-MSI(X) interrupt handler

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: "Stephen M. Cameron" <[email protected]>

commit 45bcf018d1a4779d592764ef57517c92589d55d7 upstream.

IRQF_SHARED is required for older controllers that don't support MSI(X)
and which may end up sharing an interrupt. All the controllers hpsa
normally supports have MSI(X) capability, but older controllers may be
encountered via the hpsa_allow_any=1 module parameter.

Also remove deprecated IRQF_DISABLED.

Signed-off-by: Stephen M. Cameron <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/hpsa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4037,10 +4037,10 @@ static int hpsa_request_irq(struct ctlr_

if (h->msix_vector || h->msi_vector)
rc = request_irq(h->intr[h->intr_mode], msixhandler,
- IRQF_DISABLED, h->devname, h);
+ 0, h->devname, h);
else
rc = request_irq(h->intr[h->intr_mode], intxhandler,
- IRQF_DISABLED, h->devname, h);
+ IRQF_SHARED, h->devname, h);
if (rc) {
dev_err(&h->pdev->dev, "unable to get irq %d for %s\n",
h->intr[h->intr_mode], h->devname);

2012-05-18 23:04:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 45/54] ext4: fix error handling on inode bitmap corruption

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Jan Kara <[email protected]>

commit acd6ad83517639e8f09a8c5525b1dccd81cd2a10 upstream.

When insert_inode_locked() fails in ext4_new_inode() it most likely means inode
bitmap got corrupted and we allocated again inode which is already in use. Also
doing unlock_new_inode() during error recovery is wrong since the inode does
not have I_NEW set. Fix the problem by jumping to fail: (instead of fail_drop:)
which declares filesystem error and does not call unlock_new_inode().

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/ialloc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -1021,8 +1021,12 @@ got:
if (IS_DIRSYNC(inode))
ext4_handle_sync(handle);
if (insert_inode_locked(inode) < 0) {
- err = -EINVAL;
- goto fail_drop;
+ /*
+ * Likely a bitmap corruption causing inode to be allocated
+ * twice.
+ */
+ err = -EIO;
+ goto fail;
}
spin_lock(&sbi->s_next_gen_lock);
inode->i_generation = sbi->s_next_generation++;

2012-05-18 23:24:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 35/54] arch/tile: apply commit 74fca9da0 to the compat signal handling as well

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Chris Metcalf <[email protected]>

commit a134d228298c6aa9007205c6b81cae0cac0acb5d upstream.

This passes siginfo and mcontext to tilegx32 signal handlers that
don't have SA_SIGINFO set just as we have been doing for tilegx64.

Signed-off-by: Chris Metcalf <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/tile/kernel/compat_signal.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)

--- a/arch/tile/kernel/compat_signal.c
+++ b/arch/tile/kernel/compat_signal.c
@@ -406,19 +406,17 @@ int compat_setup_rt_frame(int sig, struc
* Set up registers for signal handler.
* Registers that we don't modify keep the value they had from
* user-space at the time we took the signal.
+ * We always pass siginfo and mcontext, regardless of SA_SIGINFO,
+ * since some things rely on this (e.g. glibc's debug/segfault.c).
*/
regs->pc = ptr_to_compat_reg(ka->sa.sa_handler);
regs->ex1 = PL_ICS_EX1(USER_PL, 1); /* set crit sec in handler */
regs->sp = ptr_to_compat_reg(frame);
regs->lr = restorer;
regs->regs[0] = (unsigned long) usig;
-
- if (ka->sa.sa_flags & SA_SIGINFO) {
- /* Need extra arguments, so mark to restore caller-saves. */
- regs->regs[1] = ptr_to_compat_reg(&frame->info);
- regs->regs[2] = ptr_to_compat_reg(&frame->uc);
- regs->flags |= PT_FLAGS_CALLER_SAVES;
- }
+ regs->regs[1] = ptr_to_compat_reg(&frame->info);
+ regs->regs[2] = ptr_to_compat_reg(&frame->uc);
+ regs->flags |= PT_FLAGS_CALLER_SAVES;

/*
* Notify any tracer that was single-stepping it.

2012-05-18 23:24:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 43/54] compat: Fix RT signal mask corruption via sigprocmask

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Jan Kiszka <[email protected]>

commit b7dafa0ef3145c31d7753be0a08b3cbda51f0209 upstream.

compat_sys_sigprocmask reads a smaller signal mask from userspace than
sigprogmask accepts for setting. So the high word of blocked.sig[0]
will be cleared, releasing any potentially blocked RT signal.

This was discovered via userspace code that relies on get/setcontext.
glibc's i386 versions of those functions use sigprogmask instead of
rt_sigprogmask to save/restore signal mask and caused RT signal
unblocking this way.

As suggested by Linus, this replaces the sys_sigprocmask based compat
version with one that open-codes the required logic, including the merge
of the existing blocked set with the new one provided on SIG_SETMASK.

Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/compat.c | 65 ++++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 47 insertions(+), 18 deletions(-)

--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -318,25 +318,54 @@ asmlinkage long compat_sys_sigpending(co

#ifdef __ARCH_WANT_SYS_SIGPROCMASK

-asmlinkage long compat_sys_sigprocmask(int how, compat_old_sigset_t __user *set,
- compat_old_sigset_t __user *oset)
+/*
+ * sys_sigprocmask SIG_SETMASK sets the first (compat) word of the
+ * blocked set of signals to the supplied signal set
+ */
+static inline void compat_sig_setmask(sigset_t *blocked, compat_sigset_word set)
{
- old_sigset_t s;
- long ret;
- mm_segment_t old_fs;
-
- if (set && get_user(s, set))
- return -EFAULT;
- old_fs = get_fs();
- set_fs(KERNEL_DS);
- ret = sys_sigprocmask(how,
- set ? (old_sigset_t __user *) &s : NULL,
- oset ? (old_sigset_t __user *) &s : NULL);
- set_fs(old_fs);
- if (ret == 0)
- if (oset)
- ret = put_user(s, oset);
- return ret;
+ memcpy(blocked->sig, &set, sizeof(set));
+}
+
+asmlinkage long compat_sys_sigprocmask(int how,
+ compat_old_sigset_t __user *nset,
+ compat_old_sigset_t __user *oset)
+{
+ old_sigset_t old_set, new_set;
+ sigset_t new_blocked;
+
+ old_set = current->blocked.sig[0];
+
+ if (nset) {
+ if (get_user(new_set, nset))
+ return -EFAULT;
+ new_set &= ~(sigmask(SIGKILL) | sigmask(SIGSTOP));
+
+ new_blocked = current->blocked;
+
+ switch (how) {
+ case SIG_BLOCK:
+ sigaddsetmask(&new_blocked, new_set);
+ break;
+ case SIG_UNBLOCK:
+ sigdelsetmask(&new_blocked, new_set);
+ break;
+ case SIG_SETMASK:
+ compat_sig_setmask(&new_blocked, new_set);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ set_current_blocked(&new_blocked);
+ }
+
+ if (oset) {
+ if (put_user(old_set, oset))
+ return -EFAULT;
+ }
+
+ return 0;
}

#endif

2012-05-18 23:04:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 41/54] NFSv4: Revalidate uid/gid after open

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Jonathan Nieder <[email protected]>

This is a shorter (and more appropriate for stable kernels) analog to
the following upstream commit:

commit 6926afd1925a54a13684ebe05987868890665e2b
Author: Trond Myklebust <[email protected]>
Date: Sat Jan 7 13:22:46 2012 -0500

NFSv4: Save the owner/group name string when doing open

...so that we can do the uid/gid mapping outside the asynchronous RPC
context.
This fixes a bug in the current NFSv4 atomic open code where the client
isn't able to determine what the true uid/gid fields of the file are,
(because the asynchronous nature of the OPEN call denies it the ability
to do an upcall) and so fills them with default values, marking the
inode as needing revalidation.
Unfortunately, in some cases, the VFS will do some additional sanity
checks on the file, and may override the server's decision to allow
the open because it sees the wrong owner/group fields.

Signed-off-by: Trond Myklebust <[email protected]>

Without this patch, logging into two different machines with home
directories mounted over NFS4 and then running "vim" and typing ":q"
in each reliably produces the following error on the second machine:

E137: Viminfo file is not writable: /users/system/rtheys/.viminfo

This regression was introduced by 80e52aced138 ("NFSv4: Don't do
idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32
cycle) --- after the OPEN call, .viminfo has the default values for
st_uid and st_gid (0xfffffffe) cached because we do not want to let
rpciod wait for an idmapper upcall to fill them in.

The fix used in mainline is to save the owner and group as strings and
perform the upcall in _nfs4_proc_open outside the rpciod context,
which takes about 600 lines. For stable, we can do something similar
with a one-liner: make open check for the stale fields and make a
(synchronous) GETATTR call to fill them when needed.

Trond dictated the patch, I typed it in, and Rik tested it.

Addresses http://bugs.debian.org/659111 and
https://bugzilla.redhat.com/789298

Reported-by: Rik Theys <[email protected]>
Explained-by: David Flyn <[email protected]>
Signed-off-by: Jonathan Nieder <[email protected]>
Tested-by: Rik Theys <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/nfs4proc.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1771,6 +1771,7 @@ static int _nfs4_do_open(struct inode *d
nfs_setattr_update_inode(state->inode, sattr);
nfs_post_op_update_inode(state->inode, opendata->o_res.f_attr);
}
+ nfs_revalidate_inode(server, state->inode);
nfs4_opendata_put(opendata);
nfs4_put_state_owner(sp);
*res = state;

2012-05-18 23:24:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 42/54] memcg: free spare array to avoid memory leak

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sha Zhengju <[email protected]>

commit 8c7577637ca31385e92769a77e2ab5b428e8b99c upstream.

When the last event is unregistered, there is no need to keep the spare
array anymore. So free it to avoid memory leak.

Signed-off-by: Sha Zhengju <[email protected]>
Acked-by: KAMEZAWA Hiroyuki <[email protected]>
Reviewed-by: Kirill A. Shutemov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/memcontrol.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4605,6 +4605,12 @@ static void mem_cgroup_usage_unregister_
swap_buffers:
/* Swap primary and spare array */
thresholds->spare = thresholds->primary;
+ /* If all events are unregistered, free the spare array */
+ if (!new) {
+ kfree(thresholds->spare);
+ thresholds->spare = NULL;
+ }
+
rcu_assign_pointer(thresholds->primary, new);

/* To be sure that nobody uses thresholds */

2012-05-18 23:04:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 36/54] crypto: mv_cesa requires on CRYPTO_HASH to build

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Alexander Clouter <[email protected]>

commit 1ebfefcf37a6e308266a8d786e8cfea0a454058c upstream.

Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks
into undefined exports.
----
MODPOST 81 modules
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy.gzip
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
----

Signed-off-by: Alexander Clouter <[email protected]>
Signed-off-by: Jason Cooper <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -173,6 +173,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_ALGAPI
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
+ select CRYPTO_HASH
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Marvell Orion

2012-05-18 23:25:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 39/54] init: dont try mounting device as nfs root unless type fully matches

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sasha Levin <[email protected]>

commit 377485f6244af255b04d662cf19cddbbc4ae4310 upstream.

Currently, we'll try mounting any device who's major device number is
UNNAMED_MAJOR as NFS root. This would happen for non-NFS devices as
well (such as 9p devices) but it wouldn't cause any issues since
mounting the device as NFS would fail quickly and the code proceeded to
doing the proper mount:

[ 101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[ 101.534499] VFS: Mounted root (9p filesystem) on device 0:18.

Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
when mounting NFS root, which means that now we don't immediately fail
and instead it takes an additional 90+ seconds until we stop retrying,
which has revealed the issue this patch fixes.

This meant that it would take an additional 90 seconds to boot when
we're not using a device type which gets detected in order before NFS.

This patch modifies the NFS type check to require device type to be
'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
major. This makes boot process cleaner since we now won't go through
the NFS mounting code at all when the device isn't an NFS root
("/dev/nfs").

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
init/do_mounts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -432,7 +432,7 @@ void __init change_floppy(char *fmt, ...
void __init mount_root(void)
{
#ifdef CONFIG_ROOT_NFS
- if (MAJOR(ROOT_DEV) == UNNAMED_MAJOR) {
+ if (ROOT_DEV == Root_NFS) {
if (mount_nfs_root())
return;


2012-05-18 23:26:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 38/54] tcp: do_tcp_sendpages() must try to push data out on oom conditions

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Willy Tarreau <[email protected]>

commit bad115cfe5b509043b684d3a007ab54b80090aa1 upstream.

Since recent changes on TCP splicing (starting with commits 2f533844
"tcp: allow splice() to build full TSO packets" and 35f9c09f "tcp:
tcp_sendpages() should call tcp_push() once"), I started seeing
massive stalls when forwarding traffic between two sockets using
splice() when pipe buffers were larger than socket buffers.

Latest changes (net: netdev_alloc_skb() use build_skb()) made the
problem even more apparent.

The reason seems to be that if do_tcp_sendpages() fails on out of memory
condition without being able to send at least one byte, tcp_push() is not
called and the buffers cannot be flushed.

After applying the attached patch, I cannot reproduce the stalls at all
and the data rate it perfectly stable and steady under any condition
which previously caused the problem to be permanent.

The issue seems to have been there since before the kernel migrated to
git, which makes me think that the stalls I occasionally experienced
with tux during stress-tests years ago were probably related to the
same issue.

This issue was first encountered on 3.0.31 and 3.2.17, so please backport
to -stable.

Signed-off-by: Willy Tarreau <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/ipv4/tcp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -850,8 +850,7 @@ new_segment:
wait_for_sndbuf:
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
wait_for_memory:
- if (copied)
- tcp_push(sk, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);
+ tcp_push(sk, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);

if ((err = sk_stream_wait_memory(sk, &timeo)) != 0)
goto do_error;

2012-05-18 23:26:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 37/54] MD: Add del_timer_sync to mddev_suspend (fix nasty panic)

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Jonathan Brassow <[email protected]>

commit 0d9f4f135eb6dea06bdcb7065b1e4ff78274a5e9 upstream.

Use del_timer_sync to remove timer before mddev_suspend finishes.

We don't want a timer going off after an mddev_suspend is called. This is
especially true with device-mapper, since it can call the destructor function
immediately following a suspend. This results in the removal (kfree) of the
structures upon which the timer depends - resulting in a very ugly panic.
Therefore, we add a del_timer_sync to mddev_suspend to prevent this.

Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -348,6 +348,8 @@ void mddev_suspend(mddev_t *mddev)
synchronize_rcu();
wait_event(mddev->sb_wait, atomic_read(&mddev->active_io) == 0);
mddev->pers->quiesce(mddev, 1);
+
+ del_timer_sync(&mddev->safemode_timer);
}
EXPORT_SYMBOL_GPL(mddev_suspend);


2012-05-18 23:27:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 33/54] mm: nobootmem: fix sign extend problem in __free_pages_memory()

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Russ Anderson <[email protected]>

commit 6bc2e853c6b46a6041980d58200ad9b0a73a60ff upstream.

Systems with 8 TBytes of memory or greater can hit a problem where only
the the first 8 TB of memory shows up. This is due to "int i" being
smaller than "unsigned long start_aligned", causing the high bits to be
dropped.

The fix is to change `i' to unsigned long to match start_aligned
and end_aligned.

Thanks to Jack Steiner for assistance tracking this down.

Signed-off-by: Russ Anderson <[email protected]>
Cc: Jack Steiner <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Yinghai Lu <[email protected]>
Cc: Gavin Shan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/nobootmem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -83,8 +83,7 @@ void __init free_bootmem_late(unsigned l

static void __init __free_pages_memory(unsigned long start, unsigned long end)
{
- int i;
- unsigned long start_aligned, end_aligned;
+ unsigned long i, start_aligned, end_aligned;
int order = ilog2(BITS_PER_LONG);

start_aligned = (start + (BITS_PER_LONG - 1)) & ~(BITS_PER_LONG - 1);

2012-05-18 23:27:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 31/54] kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Catalin Marinas <[email protected]>

commit 100d13c3b5b9410f604b86f5e0a34da64b8cf659 upstream.

Kmemleak tracks the percpu allocations via a specific API and the
originally allocated areas must be removed from kmemleak (via
kmemleak_free). The code was already doing this for SMP systems.

Reported-by: Sami Liedes <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Christoph Lameter <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/percpu.c | 2 ++
1 file changed, 2 insertions(+)

--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1873,6 +1873,8 @@ void __init setup_per_cpu_areas(void)
fc = __alloc_bootmem(unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS));
if (!ai || !fc)
panic("Failed to allocate memory for percpu areas.");
+ /* kmemleak tracks the percpu allocations separately */
+ kmemleak_free(fc);

ai->dyn_size = unit_size;
ai->unit_size = unit_size;

2012-05-18 23:28:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 30/54] percpu: pcpu_embed_first_chunk() should free unused parts after all allocs are complete

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Tejun Heo <[email protected]>

commit 42b64281453249dac52861f9b97d18552a7ec62b upstream.

pcpu_embed_first_chunk() allocates memory for each node, copies percpu
data and frees unused portions of it before proceeding to the next
group. This assumes that allocations for different nodes doesn't
overlap; however, depending on memory topology, the bootmem allocator
may end up allocating memory from a different node than the requested
one which may overlap with the portion freed from one of the previous
percpu areas. This leads to percpu groups for different nodes
overlapping which is a serious bug.

This patch separates out copy & partial free from the allocation loop
such that all allocations are complete before partial frees happen.

This also fixes overlapping frees which could happen on allocation
failure path - out_free_areas path frees whole groups but the groups
could have portions freed at that point.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: "Pavel V. Panteleev" <[email protected]>
Tested-by: "Pavel V. Panteleev" <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/percpu.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1630,6 +1630,16 @@ int __init pcpu_embed_first_chunk(size_t
areas[group] = ptr;

base = min(ptr, base);
+ }
+
+ /*
+ * Copy data and free unused parts. This should happen after all
+ * allocations are complete; otherwise, we may end up with
+ * overlapping groups.
+ */
+ for (group = 0; group < ai->nr_groups; group++) {
+ struct pcpu_group_info *gi = &ai->groups[group];
+ void *ptr = areas[group];

for (i = 0; i < gi->nr_units; i++, ptr += ai->unit_size) {
if (gi->cpu_map[i] == NR_CPUS) {

2012-05-18 23:28:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 26/54] ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Russell King <[email protected]>

commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream.

Reported-by: Al Viro <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/mm/fault.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -266,7 +266,9 @@ good_area:
return fault;

check_stack:
- if (vma->vm_flags & VM_GROWSDOWN && !expand_stack(vma, addr))
+ /* Don't allow expansion below FIRST_USER_ADDRESS */
+ if (vma->vm_flags & VM_GROWSDOWN &&
+ addr >= FIRST_USER_ADDRESS && !expand_stack(vma, addr))
goto good_area;
out:
return fault;

2012-05-18 23:28:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 28/54] cdc_ether: Ignore bogus union descriptor for RNDIS devices

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Bjørn Mork <[email protected]>

commit 6eddcb4c82883451aec3be1240f17793370fa62f upstream.

Some RNDIS devices include a bogus CDC Union descriptor pointing
to non-existing interfaces. The RNDIS code is already prepared
to handle devices without a CDC Union descriptor by hardwiring
the driver to use interfaces 0 and 1, which is correct for the
devices with the bogus descriptor as well. So we can reuse the
existing workaround.

Cc: Markus Kolb <[email protected]>
Cc: Iker Salmón San Millán <[email protected]>
Cc: Jonathan Nieder <[email protected]>
Cc: Oliver Neukum <[email protected]>
Cc: [email protected]
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/usb/cdc_ether.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -83,6 +83,7 @@ int usbnet_generic_cdc_bind(struct usbne
struct cdc_state *info = (void *) &dev->data;
int status;
int rndis;
+ bool android_rndis_quirk = false;
struct usb_driver *driver = driver_of(intf);
struct usb_cdc_mdlm_desc *desc = NULL;
struct usb_cdc_mdlm_detail_desc *detail = NULL;
@@ -195,6 +196,11 @@ int usbnet_generic_cdc_bind(struct usbne
info->control,
info->u->bSlaveInterface0,
info->data);
+ /* fall back to hard-wiring for RNDIS */
+ if (rndis) {
+ android_rndis_quirk = true;
+ goto next_desc;
+ }
goto bad_desc;
}
if (info->control != intf) {
@@ -271,11 +277,15 @@ next_desc:
/* Microsoft ActiveSync based and some regular RNDIS devices lack the
* CDC descriptors, so we'll hard-wire the interfaces and not check
* for descriptors.
+ *
+ * Some Android RNDIS devices have a CDC Union descriptor pointing
+ * to non-existing interfaces. Ignore that and attempt the same
+ * hard-wired 0 and 1 interfaces.
*/
- if (rndis && !info->u) {
+ if (rndis && (!info->u || android_rndis_quirk)) {
info->control = usb_ifnum_to_if(dev->udev, 0);
info->data = usb_ifnum_to_if(dev->udev, 1);
- if (!info->control || !info->data) {
+ if (!info->control || !info->data || info->control != intf) {
dev_dbg(&intf->dev,
"rndis: master #0/%p slave #1/%p\n",
info->control,

2012-05-18 23:29:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 17/54] tg3: Avoid panic from reserved statblk field access

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: Matt Carlson <[email protected]>

[ Upstream commit f891ea1634ce41f5f47ae40d8594809f4cd2ca66 ]

When RSS is enabled, interrupt vector 0 does not receive any rx traffic.
The rx producer index fields for vector 0's status block should be
considered reserved in this case. This patch changes the code to
respect these reserved fields, which avoids a kernel panic when these
fields take on non-zero values.

Signed-off-by: Matt Carlson <[email protected]>
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/tg3.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)

--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -740,8 +740,13 @@ static inline unsigned int tg3_has_work(
if (sblk->status & SD_STATUS_LINK_CHG)
work_exists = 1;
}
- /* check for RX/TX work to do */
- if (sblk->idx[0].tx_consumer != tnapi->tx_cons ||
+
+ /* check for TX work to do */
+ if (sblk->idx[0].tx_consumer != tnapi->tx_cons)
+ work_exists = 1;
+
+ /* check for RX work to do */
+ if (tnapi->rx_rcb_prod_idx &&
*(tnapi->rx_rcb_prod_idx) != tnapi->rx_rcb_ptr)
work_exists = 1;

@@ -5216,6 +5221,9 @@ static int tg3_poll_work(struct tg3_napi
return work_done;
}

+ if (!tnapi->rx_rcb_prod_idx)
+ return work_done;
+
/* run RX thread, within the bounds set by NAPI.
* All RX "locking" is done by ensuring outside
* code synchronizes with tg3->napi.poll()
@@ -6626,6 +6634,12 @@ static int tg3_alloc_consistent(struct t
*/
switch (i) {
default:
+ if (tg3_flag(tp, ENABLE_RSS)) {
+ tnapi->rx_rcb_prod_idx = NULL;
+ break;
+ }
+ /* Fall through */
+ case 1:
tnapi->rx_rcb_prod_idx = &sblk->idx[0].rx_producer;
break;
case 2:

2012-05-18 23:03:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 23/54] usbnet: fix skb traversing races during unlink(v2)

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Ming Lei <[email protected]>

commit 5b6e9bcdeb65634b4ad604eb4536404bbfc62cfa upstream.

Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock before unlink, but may
cause skb traversing races:
- after URB is unlinked and the queue lock is released,
the refered skb and skb->next may be moved to done queue,
even be released
- in skb_queue_walk_safe, the next skb is still obtained
by next pointer of the last skb
- so maybe trigger oops or other problems

This patch extends the usage of entry->state to describe 'start_unlink'
state, so always holding the queue(rx/tx) lock to change the state if
the referd skb is in rx or tx queue because we need to know if the
refered urb has been started unlinking in unlink_urbs.

The other part of this patch is based on Huajun's patch:
always traverse from head of the tx/rx queue to get skb which is
to be unlinked but not been started unlinking.

Signed-off-by: Huajun Li <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Cc: Oliver Neukum <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/usb/usbnet.c | 54 +++++++++++++++++++++++++++++++--------------
include/linux/usb/usbnet.h | 3 +-
2 files changed, 40 insertions(+), 17 deletions(-)

--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -277,17 +277,32 @@ int usbnet_change_mtu (struct net_device
}
EXPORT_SYMBOL_GPL(usbnet_change_mtu);

+/* The caller must hold list->lock */
+static void __usbnet_queue_skb(struct sk_buff_head *list,
+ struct sk_buff *newsk, enum skb_state state)
+{
+ struct skb_data *entry = (struct skb_data *) newsk->cb;
+
+ __skb_queue_tail(list, newsk);
+ entry->state = state;
+}
+
/*-------------------------------------------------------------------------*/

/* some LK 2.4 HCDs oopsed if we freed or resubmitted urbs from
* completion callbacks. 2.5 should have fixed those bugs...
*/

-static void defer_bh(struct usbnet *dev, struct sk_buff *skb, struct sk_buff_head *list)
+static enum skb_state defer_bh(struct usbnet *dev, struct sk_buff *skb,
+ struct sk_buff_head *list, enum skb_state state)
{
unsigned long flags;
+ enum skb_state old_state;
+ struct skb_data *entry = (struct skb_data *) skb->cb;

spin_lock_irqsave(&list->lock, flags);
+ old_state = entry->state;
+ entry->state = state;
__skb_unlink(skb, list);
spin_unlock(&list->lock);
spin_lock(&dev->done.lock);
@@ -295,6 +310,7 @@ static void defer_bh(struct usbnet *dev,
if (dev->done.qlen == 1)
tasklet_schedule(&dev->bh);
spin_unlock_irqrestore(&dev->done.lock, flags);
+ return old_state;
}

/* some work can't be done in tasklets, so we use keventd
@@ -335,7 +351,6 @@ static int rx_submit (struct usbnet *dev
entry = (struct skb_data *) skb->cb;
entry->urb = urb;
entry->dev = dev;
- entry->state = rx_start;
entry->length = 0;

usb_fill_bulk_urb (urb, dev->udev, dev->in,
@@ -367,7 +382,7 @@ static int rx_submit (struct usbnet *dev
tasklet_schedule (&dev->bh);
break;
case 0:
- __skb_queue_tail (&dev->rxq, skb);
+ __usbnet_queue_skb(&dev->rxq, skb, rx_start);
}
} else {
netif_dbg(dev, ifdown, dev->net, "rx: stopped\n");
@@ -418,16 +433,17 @@ static void rx_complete (struct urb *urb
struct skb_data *entry = (struct skb_data *) skb->cb;
struct usbnet *dev = entry->dev;
int urb_status = urb->status;
+ enum skb_state state;

skb_put (skb, urb->actual_length);
- entry->state = rx_done;
+ state = rx_done;
entry->urb = NULL;

switch (urb_status) {
/* success */
case 0:
if (skb->len < dev->net->hard_header_len) {
- entry->state = rx_cleanup;
+ state = rx_cleanup;
dev->net->stats.rx_errors++;
dev->net->stats.rx_length_errors++;
netif_dbg(dev, rx_err, dev->net,
@@ -466,7 +482,7 @@ static void rx_complete (struct urb *urb
"rx throttle %d\n", urb_status);
}
block:
- entry->state = rx_cleanup;
+ state = rx_cleanup;
entry->urb = urb;
urb = NULL;
break;
@@ -477,17 +493,18 @@ block:
// FALLTHROUGH

default:
- entry->state = rx_cleanup;
+ state = rx_cleanup;
dev->net->stats.rx_errors++;
netif_dbg(dev, rx_err, dev->net, "rx status %d\n", urb_status);
break;
}

- defer_bh(dev, skb, &dev->rxq);
+ state = defer_bh(dev, skb, &dev->rxq, state);

if (urb) {
if (netif_running (dev->net) &&
- !test_bit (EVENT_RX_HALT, &dev->flags)) {
+ !test_bit (EVENT_RX_HALT, &dev->flags) &&
+ state != unlink_start) {
rx_submit (dev, urb, GFP_ATOMIC);
return;
}
@@ -573,16 +590,23 @@ EXPORT_SYMBOL_GPL(usbnet_purge_paused_rx
static int unlink_urbs (struct usbnet *dev, struct sk_buff_head *q)
{
unsigned long flags;
- struct sk_buff *skb, *skbnext;
+ struct sk_buff *skb;
int count = 0;

spin_lock_irqsave (&q->lock, flags);
- skb_queue_walk_safe(q, skb, skbnext) {
+ while (!skb_queue_empty(q)) {
struct skb_data *entry;
struct urb *urb;
int retval;

- entry = (struct skb_data *) skb->cb;
+ skb_queue_walk(q, skb) {
+ entry = (struct skb_data *) skb->cb;
+ if (entry->state != unlink_start)
+ goto found;
+ }
+ break;
+found:
+ entry->state = unlink_start;
urb = entry->urb;

/*
@@ -1033,8 +1057,7 @@ static void tx_complete (struct urb *urb
}

usb_autopm_put_interface_async(dev->intf);
- entry->state = tx_done;
- defer_bh(dev, skb, &dev->txq);
+ (void) defer_bh(dev, skb, &dev->txq, tx_done);
}

/*-------------------------------------------------------------------------*/
@@ -1087,7 +1110,6 @@ netdev_tx_t usbnet_start_xmit (struct sk
entry = (struct skb_data *) skb->cb;
entry->urb = urb;
entry->dev = dev;
- entry->state = tx_start;
entry->length = length;

usb_fill_bulk_urb (urb, dev->udev, dev->out,
@@ -1146,7 +1168,7 @@ netdev_tx_t usbnet_start_xmit (struct sk
break;
case 0:
net->trans_start = jiffies;
- __skb_queue_tail (&dev->txq, skb);
+ __usbnet_queue_skb(&dev->txq, skb, tx_start);
if (dev->txq.qlen >= TX_QLEN (dev))
netif_stop_queue (net);
}
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -191,7 +191,8 @@ extern void usbnet_cdc_status(struct usb
enum skb_state {
illegal = 0,
tx_start, tx_done,
- rx_start, rx_done, rx_cleanup
+ rx_start, rx_done, rx_cleanup,
+ unlink_start
};

struct skb_data { /* skb->cb is one of these */

2012-05-18 23:29:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 24/54] namespaces, pid_ns: fix leakage on fork() failure

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Mike Galbraith <[email protected]>

commit 5e2bf0142231194d36fdc9596b36a261ed2b9fe7 upstream.

Fork() failure post namespace creation for a child cloned with
CLONE_NEWPID leaks pid_namespace/mnt_cache due to proc being mounted
during creation, but not unmounted during cleanup. Call
pid_ns_release_proc() during cleanup.

Signed-off-by: Mike Galbraith <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Reviewed-by: "Eric W. Biederman" <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Cc: Cyrill Gorcunov <[email protected]>
Cc: Louis Rilling <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/fork.c | 3 +++
1 file changed, 3 insertions(+)

--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -48,6 +48,7 @@
#include <linux/audit.h>
#include <linux/memcontrol.h>
#include <linux/ftrace.h>
+#include <linux/proc_fs.h>
#include <linux/profile.h>
#include <linux/rmap.h>
#include <linux/ksm.h>
@@ -1378,6 +1379,8 @@ bad_fork_cleanup_io:
if (p->io_context)
exit_io_context(p);
bad_fork_cleanup_namespaces:
+ if (unlikely(clone_flags & CLONE_NEWPID))
+ pid_ns_release_proc(p->nsproxy->pid_ns);
exit_task_namespaces(p);
bad_fork_cleanup_mm:
if (p->mm) {

2012-05-18 23:03:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 19/54] tcp: change tcp_adv_win_scale and tcp_rmem[2]

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: Eric Dumazet <[email protected]>

[ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ]

tcp_adv_win_scale default value is 2, meaning we expect a good citizen
skb to have skb->len / skb->truesize ratio of 75% (3/4)

In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392.
So these skbs were considered as not bloated.

With recent truesize fixes, a typical MSS=1460 frame truesize is now the
more precise :
2048 + 256 = 2304. But 2304 * 3/4 = 1728.
So these skb are not good citizen anymore, because 1460 < 1728

(GRO can escape this problem because it build skbs with a too low
truesize.)

This also means tcp advertises a too optimistic window for a given
allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
especially when application is slow to drain its receive queue or in
case of losses (netperf is fast, scp is slow). This is a major latency
source.

We should adjust the len/truesize ratio to 50% instead of 75%

This patch :

1) changes tcp_adv_win_scale default to 1 instead of 2

2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
better truesize tracking and to allow autotuning tcp receive window to
reach same value than before. Note that same amount of kernel memory is
consumed compared to 2.6 kernels.

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Neal Cardwell <[email protected]>
Cc: Tom Herbert <[email protected]>
Cc: Yuchung Cheng <[email protected]>
Acked-by: Neal Cardwell <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/networking/ip-sysctl.txt | 4 ++--
net/ipv4/tcp.c | 9 +++++----
net/ipv4/tcp_input.c | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)

--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -147,7 +147,7 @@ tcp_adv_win_scale - INTEGER
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Possible values are [-31, 31], inclusive.
- Default: 2
+ Default: 1

tcp_allowed_congestion_control - STRING
Show/set the congestion control choices available to non-privileged
@@ -407,7 +407,7 @@ tcp_rmem - vector of 3 INTEGERs: min, de
net.core.rmem_max. Calling setsockopt() with SO_RCVBUF disables
automatic tuning of that socket's receive buffer size, in which
case this value is ignored.
- Default: between 87380B and 4MB, depending on RAM size.
+ Default: between 87380B and 6MB, depending on RAM size.

tcp_sack - BOOLEAN
Enable select acknowledgments (SACKS).
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3221,7 +3221,7 @@ void __init tcp_init(void)
{
struct sk_buff *skb = NULL;
unsigned long limit;
- int i, max_share, cnt;
+ int i, max_rshare, max_wshare, cnt;
unsigned long jiffy = jiffies;

BUILD_BUG_ON(sizeof(struct tcp_skb_cb) > sizeof(skb->cb));
@@ -3285,15 +3285,16 @@ void __init tcp_init(void)

/* Set per-socket limits to no more than 1/128 the pressure threshold */
limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);
- max_share = min(4UL*1024*1024, limit);
+ max_wshare = min(4UL*1024*1024, limit);
+ max_rshare = min(6UL*1024*1024, limit);

sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
sysctl_tcp_wmem[1] = 16*1024;
- sysctl_tcp_wmem[2] = max(64*1024, max_share);
+ sysctl_tcp_wmem[2] = max(64*1024, max_wshare);

sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;
sysctl_tcp_rmem[1] = 87380;
- sysctl_tcp_rmem[2] = max(87380, max_share);
+ sysctl_tcp_rmem[2] = max(87380, max_rshare);

printk(KERN_INFO "TCP: Hash tables configured "
"(established %u bind %u)\n",
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -83,7 +83,7 @@ int sysctl_tcp_ecn __read_mostly = 2;
EXPORT_SYMBOL(sysctl_tcp_ecn);
int sysctl_tcp_dsack __read_mostly = 1;
int sysctl_tcp_app_win __read_mostly = 31;
-int sysctl_tcp_adv_win_scale __read_mostly = 2;
+int sysctl_tcp_adv_win_scale __read_mostly = 1;
EXPORT_SYMBOL(sysctl_tcp_adv_win_scale);

int sysctl_tcp_stdurg __read_mostly;

2012-05-18 23:29:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 22/54] ALSA: HDA: Lessen CPU usage when waiting for chip to respond

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: David Henningsson <[email protected]>

commit 32cf4023e689ad5b3a81a749d8cc99d7f184cb99 upstream.

When an IRQ for some reason gets lost, we wait up to a second using
udelay, which is CPU intensive. This patch improves the situation by
waiting about 30 ms in the CPU intensive mode, then stepping down to
using msleep(2) instead. In essence, we trade some granularity in
exchange for less CPU consumption when the waiting time is a bit longer.

As a result, PulseAudio should no longer be killed by the kernel
for taking up to much RT-prio CPU time. At least not for *this* reason.

Signed-off-by: David Henningsson <[email protected]>
Tested-by: Arun Raghavan <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/hda_intel.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -702,11 +702,13 @@ static unsigned int azx_rirb_get_respons
{
struct azx *chip = bus->private_data;
unsigned long timeout;
+ unsigned long loopcounter;
int do_poll = 0;

again:
timeout = jiffies + msecs_to_jiffies(1000);
- for (;;) {
+
+ for (loopcounter = 0;; loopcounter++) {
if (chip->polling_mode || do_poll) {
spin_lock_irq(&chip->reg_lock);
azx_update_rirb(chip);
@@ -722,7 +724,7 @@ static unsigned int azx_rirb_get_respons
}
if (time_after(jiffies, timeout))
break;
- if (bus->needs_damn_long_delay)
+ if (bus->needs_damn_long_delay || loopcounter > 3000)
msleep(2); /* temporary workaround */
else {
udelay(10);

2012-05-18 23:30:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 21/54] ALSA: echoaudio: Remove incorrect part of assertion

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Mark Hills <[email protected]>

commit c914f55f7cdfafe9d7d5b248751902c7ab57691e upstream.

This assertion seems to imply that chip->dsp_code_to_load is a pointer.
It's actually an integer handle on the actual firmware, and 0 has no
special meaning.

The assertion prevents initialisation of a Darla20 card, but would also
affect other models. It seems it was introduced in commit dd7b254d.

ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting...
ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000
ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware...
ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20
------------[ cut here ]------------
WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]()
Hardware name: Dell DM051
BUG? (!chip->dsp_code_to_load || !chip->comm_page)

Signed-off-by: Mark Hills <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/echoaudio/echoaudio_dsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/pci/echoaudio/echoaudio_dsp.c
+++ b/sound/pci/echoaudio/echoaudio_dsp.c
@@ -475,7 +475,7 @@ static int load_firmware(struct echoaudi
const struct firmware *fw;
int box_type, err;

- if (snd_BUG_ON(!chip->dsp_code_to_load || !chip->comm_page))
+ if (snd_BUG_ON(!chip->comm_page))
return -EPERM;

/* See if the ASIC is present and working - only if the DSP is already loaded */

2012-05-18 23:30:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 20/54] sony-laptop: Enable keyboard backlight by default

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Josh Boyer <[email protected]>

commit 6fe6ae56a7cebaebc2e6daa11c423e4692f9b592 upstream.

When the keyboard backlight support was originally added, the commit said
to default it to on with a 10 second timeout. That actually wasn't the
case, as the default value is commented out for the kbd_backlight parameter.
Because it is a static variable, it gets set to 0 by default without some
other form of initialization.

However, it seems the function to set the value wasn't actually called
immediately, so whatever state the keyboard was in initially would remain.
Then commit df410d522410e67660 was introduced during the 2.6.39 timeframe to
immediately set whatever value was present (as well as attempt to
restore/reset the state on module removal or resume). That seems to have
now forced the light off immediately when the module is loaded unless
the option kbd_backlight=1 is specified.

Let's enable it by default again (for the first time). This should solve
https://bugzilla.redhat.com/show_bug.cgi?id=728478

Signed-off-by: Josh Boyer <[email protected]>
Acked-by: Mattia Dongili <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Cc: maximilian attems <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/platform/x86/sony-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -127,7 +127,7 @@ MODULE_PARM_DESC(minor,
"default is -1 (automatic)");
#endif

-static int kbd_backlight; /* = 1 */
+static int kbd_backlight = 1;
module_param(kbd_backlight, int, 0444);
MODULE_PARM_DESC(kbd_backlight,
"set this to 0 to disable keyboard backlight, "

2012-05-18 23:03:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 14/54] net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: Sasha Levin <[email protected]>

[ Upstream commit 84768edbb2721637620b2d84501bb0d5aed603f1 ]

l2tp_ip_sendmsg could return without releasing socket lock, making it all the
way to userspace, and generating the following warning:

[ 130.891594] ================================================
[ 130.894569] [ BUG: lock held when returning to user space! ]
[ 130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G W
[ 130.900336] ------------------------------------------------
[ 130.902996] trinity/8384 is leaving the kernel with locks still held!
[ 130.906106] 1 lock held by trinity/8384:
[ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550

Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").

Signed-off-by: Sasha Levin <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/l2tp/l2tp_ip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -441,8 +441,9 @@ static int l2tp_ip_sendmsg(struct kiocb

daddr = lip->l2tp_addr.s_addr;
} else {
+ rc = -EDESTADDRREQ;
if (sk->sk_state != TCP_ESTABLISHED)
- return -EDESTADDRREQ;
+ goto out;

daddr = inet->inet_daddr;
connected = 1;

2012-05-18 23:31:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 08/54] ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Colin Cross <[email protected]>

commit fde165b2a29673aabf18ceff14dea1f1cfb0daad upstream.

Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use
idmap_pgd for mapping MMU enable during secondary booting)
switched secondary boot to use idmap_pgd, which is initialized
during early_initcall, instead of a page table initialized during
__cpu_up. This causes idmap_pgd to contain the static mappings
but be missing all dynamic mappings.

If a console is registered that creates a dynamic mapping, the
printk in secondary_start_kernel will trigger a data abort on
the missing mapping before the exception handlers have been
initialized, leading to a hang. Initial boot is not affected
because no consoles have been registered, and resume is usually
not affected because the offending console is suspended.
Onlining a cpu with hotplug triggers the problem.

A workaround is to the printk in secondary_start_kernel until
after the page tables have been switched back to init_mm.

Signed-off-by: Colin Cross <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/smp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -279,8 +279,6 @@ asmlinkage void __cpuinit secondary_star
struct mm_struct *mm = &init_mm;
unsigned int cpu = smp_processor_id();

- printk("CPU%u: Booted secondary processor\n", cpu);
-
/*
* All kernel threads share the same mm context; grab a
* reference and switch to it.
@@ -292,6 +290,8 @@ asmlinkage void __cpuinit secondary_star
enter_lazy_tlb(mm, current);
local_flush_tlb_all();

+ printk("CPU%u: Booted secondary processor\n", cpu);
+
cpu_init();
preempt_disable();
trace_hardirqs_off();

2012-05-18 23:31:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 16/54] sky2: fix receive length error in mixed non-VLAN/VLAN traffic

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: stephen hemminger <[email protected]>

[ Upstream commit e072b3fad5f3915102c94628b4971f52ff99dd05 ]

Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
and also sometimes the VLAN bit is set for non-VLAN packets that came after
a VLAN packet. This results in a receive length error when VLAN hardware
tagging is enabled.

Fix: Variation on original fix proposed by Mirko.
The VLAN information is decoded in the status loop, and can be
applied to the received SKB there. This eliminates the need for the
separate tag field in the interface data structure. The tag has to
be copied and cleared if packet is copied. This version checked out
with vlan and normal traffic.

Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that
is outside scope of this.

Reported-by: Mirko Lindner <[email protected]>
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/sky2.c | 28 +++++++++++++++++-----------
drivers/net/sky2.h | 1 -
2 files changed, 17 insertions(+), 12 deletions(-)

--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2345,9 +2345,11 @@ static struct sk_buff *receive_copy(stru
skb->ip_summed = re->skb->ip_summed;
skb->csum = re->skb->csum;
skb->rxhash = re->skb->rxhash;
+ skb->vlan_tci = re->skb->vlan_tci;

pci_dma_sync_single_for_device(sky2->hw->pdev, re->data_addr,
length, PCI_DMA_FROMDEVICE);
+ re->skb->vlan_tci = 0;
re->skb->rxhash = 0;
re->skb->ip_summed = CHECKSUM_NONE;
skb_put(skb, length);
@@ -2433,9 +2435,6 @@ static struct sk_buff *sky2_receive(stru
struct sk_buff *skb = NULL;
u16 count = (status & GMR_FS_LEN) >> 16;

- if (status & GMR_FS_VLAN)
- count -= VLAN_HLEN; /* Account for vlan tag */
-
netif_printk(sky2, rx_status, KERN_DEBUG, dev,
"rx slot %u status 0x%x len %d\n",
sky2->rx_next, status, length);
@@ -2443,6 +2442,9 @@ static struct sk_buff *sky2_receive(stru
sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
prefetch(sky2->rx_ring + sky2->rx_next);

+ if (vlan_tx_tag_present(re->skb))
+ count -= VLAN_HLEN; /* Account for vlan tag */
+
/* This chip has hardware problems that generates bogus status.
* So do only marginal checking and expect higher level protocols
* to handle crap frames.
@@ -2500,11 +2502,8 @@ static inline void sky2_tx_done(struct n
}

static inline void sky2_skb_rx(const struct sky2_port *sky2,
- u32 status, struct sk_buff *skb)
+ struct sk_buff *skb)
{
- if (status & GMR_FS_VLAN)
- __vlan_hwaccel_put_tag(skb, be16_to_cpu(sky2->rx_tag));
-
if (skb->ip_summed == CHECKSUM_NONE)
netif_receive_skb(skb);
else
@@ -2558,6 +2557,14 @@ static void sky2_rx_checksum(struct sky2
}
}

+static void sky2_rx_tag(struct sky2_port *sky2, u16 length)
+{
+ struct sk_buff *skb;
+
+ skb = sky2->rx_ring[sky2->rx_next].skb;
+ __vlan_hwaccel_put_tag(skb, be16_to_cpu(length));
+}
+
static void sky2_rx_hash(struct sky2_port *sky2, u32 status)
{
struct sk_buff *skb;
@@ -2616,8 +2623,7 @@ static int sky2_status_intr(struct sky2_
}

skb->protocol = eth_type_trans(skb, dev);
-
- sky2_skb_rx(sky2, status, skb);
+ sky2_skb_rx(sky2, skb);

/* Stop after net poll weight */
if (++work_done >= to_do)
@@ -2625,11 +2631,11 @@ static int sky2_status_intr(struct sky2_
break;

case OP_RXVLAN:
- sky2->rx_tag = length;
+ sky2_rx_tag(sky2, length);
break;

case OP_RXCHKSVLAN:
- sky2->rx_tag = length;
+ sky2_rx_tag(sky2, length);
/* fall through */
case OP_RXCHKS:
if (likely(dev->features & NETIF_F_RXCSUM))
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2236,7 +2236,6 @@ struct sky2_port {
u16 rx_pending;
u16 rx_data_size;
u16 rx_nfrags;
- u16 rx_tag;

struct {
unsigned long last;

2012-05-18 23:32:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 15/54] sky2: propogate rx hash when packet is copied

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: stephen hemminger <[email protected]>

[ Upstream commit 3f42941b5d1d13542b1a755a9e4f633aa72e4d3e ]

When a small packet is received, the driver copies it to a new skb to allow
reusing the full size Rx buffer. The copy was propogating the checksum offload
but not the receive hash information. The bug is impact was mostly harmless
and therefore not observed until reviewing this area of code.

Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/sky2.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2344,8 +2344,11 @@ static struct sk_buff *receive_copy(stru
skb_copy_from_linear_data(re->skb, skb->data, length);
skb->ip_summed = re->skb->ip_summed;
skb->csum = re->skb->csum;
+ skb->rxhash = re->skb->rxhash;
+
pci_dma_sync_single_for_device(sky2->hw->pdev, re->data_addr,
length, PCI_DMA_FROMDEVICE);
+ re->skb->rxhash = 0;
re->skb->ip_summed = CHECKSUM_NONE;
skb_put(skb, length);
}

2012-05-18 23:32:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 12/54] netem: fix possible skb leak

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: Eric Dumazet <[email protected]>

[ Upstream commit 116a0fc31c6c9b8fc821be5a96e5bf0b43260131 ]

skb_checksum_help(skb) can return an error, we must free skb in this
case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if
skb_unshare() failed), so lets use this generic helper.

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_netem.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -350,10 +350,8 @@ static int netem_enqueue(struct sk_buff
if (q->corrupt && q->corrupt >= get_crandom(&q->corrupt_cor)) {
if (!(skb = skb_unshare(skb, GFP_ATOMIC)) ||
(skb->ip_summed == CHECKSUM_PARTIAL &&
- skb_checksum_help(skb))) {
- sch->qstats.drops++;
- return NET_XMIT_DROP;
- }
+ skb_checksum_help(skb)))
+ return qdisc_drop(skb, sch);

skb->data[net_random() % skb_headlen(skb)] ^= 1<<(net_random() % 8);
}

2012-05-18 23:03:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 06/54] Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Linus Torvalds <[email protected]>

commit 2f624278626677bfaf73fef97f86b37981621f5c upstream.

We really need to use a ACCESS_ONCE() on the sequence value read in
__read_seqcount_begin(), because otherwise the compiler might end up
reloading the value in between the test and the return of it. As a
result, it might end up returning an odd value (which means that a write
is in progress).

If the reader is then fast enough that that odd value is still the
current one when the read_seqcount_retry() is done, we might end up with
a "successful" read sequence, even despite the concurrent write being
active.

In practice this probably never really happens - there just isn't
anything else going on around the read of the sequence count, and the
common case is that we end up having a read barrier immediately
afterwards.

So the code sequence in which gcc might decide to reaload from memory is
small, and there's no reason to believe it would ever actually do the
reload. But if the compiler ever were to decide to do so, it would be
incredibly annoying to debug. Let's just make sure.

Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/seqlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -141,7 +141,7 @@ static inline unsigned __read_seqcount_b
unsigned ret;

repeat:
- ret = s->sequence;
+ ret = ACCESS_ONCE(s->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;

2012-05-18 23:33:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 11/54] asix: Fix tx transfer padding for full-speed USB

3.0-stable review patch. If anyone has any objections, please let me know.

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


From: Ingo van Lil <[email protected]>

[ Upstream commit 2a5809499e35b53a6044fd34e72b242688b7a862 ]

The asix.c USB Ethernet driver avoids ending a tx transfer with a zero-
length packet by appending a four-byte padding to transfers whose length
is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket
length is valid for high-speed USB only; full-speed USB uses 64 byte
packets.

Signed-off-by: Ingo van Lil <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/asix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -398,7 +398,7 @@ static struct sk_buff *asix_tx_fixup(str
u32 packet_len;
u32 padbytes = 0xffff0000;

- padlen = ((skb->len + 4) % 512) ? 0 : 4;
+ padlen = ((skb->len + 4) & (dev->maxpacket - 1)) ? 0 : 4;

if ((!skb_cloned(skb)) &&
((headroom + tailroom) >= (4 + padlen))) {
@@ -420,7 +420,7 @@ static struct sk_buff *asix_tx_fixup(str
cpu_to_le32s(&packet_len);
skb_copy_to_linear_data(skb, &packet_len, sizeof(packet_len));

- if ((skb->len % 512) == 0) {
+ if (padlen) {
cpu_to_le32s(&padbytes);
memcpy(skb_tail_pointer(skb), &padbytes, sizeof(padbytes));
skb_put(skb, sizeof(padbytes));

2012-05-18 23:03:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 07/54] ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Tim Bird <[email protected]>

commit e787ec1376e862fcea1bfd523feb7c5fb43ecdb9 upstream.

The inline assembly in kernel_execve() uses r8 and r9. Since this
code sequence does not return, it usually doesn't matter if the
register clobber list is accurate. However, I saw a case where a
particular version of gcc used r8 as an intermediate for the value
eventually passed to r9. Because r8 is used in the inline
assembly, and not mentioned in the clobber list, r9 was set
to an incorrect value.

This resulted in a kernel panic on execution of the first user-space
program in the system. r9 is used in ret_to_user as the thread_info
pointer, and if it's wrong, bad things happen.

Signed-off-by: Tim Bird <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/arch/arm/kernel/sys_arm.c
+++ b/arch/arm/kernel/sys_arm.c
@@ -115,7 +115,7 @@ int kernel_execve(const char *filename,
"Ir" (THREAD_START_SP - sizeof(regs)),
"r" (&regs),
"Ir" (sizeof(regs))
- : "r0", "r1", "r2", "r3", "ip", "lr", "memory");
+ : "r0", "r1", "r2", "r3", "r8", "r9", "ip", "lr", "memory");

out:
return ret;

2012-05-18 23:33:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 05/54] asm-generic: Use __BITS_PER_LONG in statfs.h

3.0-stable review patch. If anyone has any objections, please let me know.

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

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

commit f5c2347ee20a8d6964d6a6b1ad04f200f8d4dfa7 upstream.

<asm-generic/statfs.h> is exported to userspace, so using
BITS_PER_LONG is invalid. We need to use __BITS_PER_LONG instead.

This is kernel bugzilla 43165.

Reported-by: H.J. Lu <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/asm-generic/statfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/asm-generic/statfs.h
+++ b/include/asm-generic/statfs.h
@@ -15,7 +15,7 @@ typedef __kernel_fsid_t fsid_t;
* with a 10' pole.
*/
#ifndef __statfs_word
-#if BITS_PER_LONG == 64
+#if __BITS_PER_LONG == 64
#define __statfs_word long
#else
#define __statfs_word __u32

2012-05-18 23:33:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 09/54] regulator: Fix the logic to ensure new voltage setting in valid range

3.0-stable review patch. If anyone has any objections, please let me know.

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

From: Axel Lin <[email protected]>

commit f55205f4d4a8823a11bb8b37ef2ecbd78fb09463 upstream.

I think this is a typo.
To ensure new voltage setting won't greater than desc->max,
the equation should be desc->min + desc->step * new_val <= desc->max.

Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/regulator/max8997.c
+++ b/drivers/regulator/max8997.c
@@ -688,7 +688,7 @@ static int max8997_set_voltage_buck(stru
}

new_val++;
- } while (desc->min + desc->step + new_val <= desc->max);
+ } while (desc->min + desc->step * new_val <= desc->max);

new_idx = tmp_idx;
new_val = tmp_val;

2012-05-19 01:01:10

by Steven Rostedt

[permalink] [raw]
Subject: Re: [ 00/54] 3.0.32-stable review

On Fri, May 18, 2012 at 02:26:56PM -0700, Greg KH wrote:
> This is the start of the stable review cycle for the 3.0.32 release.
> There are 54 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 Sun May 20 21:15:57 UTC 2012.
> Anything received after that time might be too late.

You really want people to work over the weekends don't you? ;-)

Well, I set up a box to run ktest randconfigs and some other checks.
Right now it's running on the 3.2.18-rc release. If I can sneak away
from the misses, I may be able to kick off tests against these releases
too. But I only have one box dedicated for this, so everything needs to
be processed serially.

-- Steve

>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.32-rc1.gz
> and the diffstat can be found below.

2012-05-19 04:20:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/54] 3.0.32-stable review

On Fri, May 18, 2012 at 09:01:05PM -0400, Steven Rostedt wrote:
> On Fri, May 18, 2012 at 02:26:56PM -0700, Greg KH wrote:
> > This is the start of the stable review cycle for the 3.0.32 release.
> > There are 54 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 Sun May 20 21:15:57 UTC 2012.
> > Anything received after that time might be too late.
>
> You really want people to work over the weekends don't you? ;-)

Sorry :)

I will wait until late on Monday before doing the real release, so you
do get an extra day here.

> Well, I set up a box to run ktest randconfigs and some other checks.
> Right now it's running on the 3.2.18-rc release. If I can sneak away
> from the misses, I may be able to kick off tests against these releases
> too. But I only have one box dedicated for this, so everything needs to
> be processed serially.

No rush, do it on Monday if needed. Thanks for testing, I appreciate
it.

greg k-h

2012-05-19 13:36:19

by Christoph Biedl

[permalink] [raw]
Subject: Re: [ 31/54] kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP

Greg KH wrote...

> 3.0-stable review patch. If anyone has any objections, please let me know.

> From: Catalin Marinas <[email protected]>
>
> commit 100d13c3b5b9410f604b86f5e0a34da64b8cf659 upstream.

> + /* kmemleak tracks the percpu allocations separately */
> + kmemleak_free(fc);

That one causes:

mm/percpu.c: In function ‘setup_per_cpu_areas’:
mm/percpu.c:1877: error: implicit declaration of function ‘kmemleak_free’
make[1]: *** [mm/percpu.o] Error 1
make: *** [mm] Error 2

Trivial fix, works for me: Add

#include <linux/kmemleak.h>

to mm/percpu.c. FWIW, upstream did this in in f528f0b but I cannot
tell whether that commit is in any way of interest for 3.0.x.

Regards,

Christoph


Attachments:
(No filename) (737.00 B)
signature.asc (198.00 B)
Digital signature
Download all attachments

2012-05-19 14:47:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 31/54] kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP

On Sat, May 19, 2012 at 03:27:33PM +0200, Christoph Biedl wrote:
> Greg KH wrote...
>
> > 3.0-stable review patch. If anyone has any objections, please let me know.
>
> > From: Catalin Marinas <[email protected]>
> >
> > commit 100d13c3b5b9410f604b86f5e0a34da64b8cf659 upstream.
>
> > + /* kmemleak tracks the percpu allocations separately */
> > + kmemleak_free(fc);
>
> That one causes:
>
> mm/percpu.c: In function ‘setup_per_cpu_areas’:
> mm/percpu.c:1877: error: implicit declaration of function ‘kmemleak_free’
> make[1]: *** [mm/percpu.o] Error 1
> make: *** [mm] Error 2

Odd, it doesn't cause that problem here for me, what ARCH are you
building for? I'm on x86-64.

> Trivial fix, works for me: Add
>
> #include <linux/kmemleak.h>
>
> to mm/percpu.c. FWIW, upstream did this in in f528f0b but I cannot
> tell whether that commit is in any way of interest for 3.0.x.

Actually, I don't think this is needed at all for 3.0 as percpu memleak
handling went in with the patch you reference above, so this would cause
problems on 3.0. So I'll go delete that patch from the queue, thanks
for letting me know.

greg k-h

2012-05-19 15:45:58

by Christoph Biedl

[permalink] [raw]
Subject: Re: [ 31/54] kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP

Greg KH wrote...

> On Sat, May 19, 2012 at 03:27:33PM +0200, Christoph Biedl wrote:
> > Greg KH wrote...
> >
> > > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > > From: Catalin Marinas <[email protected]>
> > >
> > > commit 100d13c3b5b9410f604b86f5e0a34da64b8cf659 upstream.
> >
> > > + /* kmemleak tracks the percpu allocations separately */
> > > + kmemleak_free(fc);
> >
> > That one causes:
> >
> > mm/percpu.c: In function ‘setup_per_cpu_areas’:
> > mm/percpu.c:1877: error: implicit declaration of function ‘kmemleak_free’
> > make[1]: *** [mm/percpu.o] Error 1
> > make: *** [mm] Error 2
>
> Odd, it doesn't cause that problem here for me, what ARCH are you
> building for? I'm on x86-64.

x86-64 and ARM, not x86-32 for whatever reason, parisc not tested yet.

But, if I read the nested #ifdef right, CONFIG_CMP must be disabled to
hit that code.

> Actually, I don't think this is needed at all for 3.0 as percpu memleak
> handling went in with the patch you reference above, so this would cause
> problems on 3.0. So I'll go delete that patch from the queue, thanks
> for letting me know.

I'm fine with that descision.

Christoph

2012-05-19 21:46:32

by Catalin Marinas

[permalink] [raw]
Subject: Re: [ 31/54] kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP

On Sat, May 19, 2012 at 03:46:52PM +0100, Greg KH wrote:
> On Sat, May 19, 2012 at 03:27:33PM +0200, Christoph Biedl wrote:
> > Greg KH wrote...
> >
> > > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > > From: Catalin Marinas <[email protected]>
> > >
> > > commit 100d13c3b5b9410f604b86f5e0a34da64b8cf659 upstream.
> >
> > > + /* kmemleak tracks the percpu allocations separately */
> > > + kmemleak_free(fc);
> >
> > That one causes:
> >
> > mm/percpu.c: In function ‘setup_per_cpu_areas’:
> > mm/percpu.c:1877: error: implicit declaration of function ‘kmemleak_free’
> > make[1]: *** [mm/percpu.o] Error 1
> > make: *** [mm] Error 2
>
> Odd, it doesn't cause that problem here for me, what ARCH are you
> building for? I'm on x86-64.

This patch propagated to far in the past. Support for per-cpu areas in
kmemleak was added with commit f528f0b8e5 (kmemleak: Handle percpu
memory allocation) in 3.3-rc1. That patch introduced the correct
#include for kmemleak.h.

Commit 100d13c should only be applied to stable 3.3 and not earlier.

Thanks.

--
Catalin

2012-05-20 02:01:52

by Steven Rostedt

[permalink] [raw]
Subject: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [ 00/54] 3.0.32-stable review)

On Fri, 2012-05-18 at 21:20 -0700, Greg KH wrote:

> > Well, I set up a box to run ktest randconfigs and some other checks.
> > Right now it's running on the 3.2.18-rc release. If I can sneak away
> > from the misses, I may be able to kick off tests against these releases
> > too. But I only have one box dedicated for this, so everything needs to
> > be processed serially.
>
> No rush, do it on Monday if needed. Thanks for testing, I appreciate
> it.

Ran 18 tests against 3.0.32-rc, 2 failed (16 passed!). One failed by a
lock up (still looking into it) and the other is this one:

Calibrating delay loop (skipped), value calculated using timer frequency.. 4799.59 BogoMIPS (lpj=2399799)
pid_max: default: 32768 minimum: 301
BUG: scheduling while atomic: swapper/0/0x10000002
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.1.0-rc9-test+ #1
Call Trace:
[<ffffffff81435b3e>] __schedule_bug+0x57/0x5b
[<ffffffff8143c44f>] __schedule+0x90/0x672
[<ffffffff810636dd>] ? kzalloc.constprop.2+0x24/0x26
[<ffffffff810460d1>] __cond_resched+0x23/0x2f
[<ffffffff8143ca83>] _cond_resched+0x14/0x1d^M
[<ffffffff810f7cd3>] slab_pre_alloc_hook.isra.52+0x28/0x2c
[<ffffffff810f8b1a>] kmem_cache_alloc_trace+0x29/0xbd
[<ffffffff810636dd>] kzalloc.constprop.2+0x24/0x26
[<ffffffff81b7a434>] pidmap_init+0x81/0xc0
[<ffffffff81b61b03>] start_kernel+0x330/0x3c2
[<ffffffff81b612c4>] x86_64_start_reservations+0xaf/0xb3
[<ffffffff81b61140>] ? early_idt_handlers+0x140/0x140
[<ffffffff81b613ca>] x86_64_start_kernel+0x102/0x111
Security Framework initialized

Had CONFIG_SLUB, IRQ_FORCED_THREADING and voluntary preempt enabled.
Seems the might_resched() check from might_sleep_if() in
pre_alloc_hook() caused a schedule in early boot (pidmap_init). Not sure
why it scheduled that early, perhaps a threaded interrupt was added? I
haven't been able to reproduce it again.

Perhaps we should not be using GFP_KERNEL when allocating memory for
pidmap_init()? As we have preemption disabled at this point, we should
be using GFP_ATOMIC. Also add a BUG_ON if the page fails to get
allocated.

Signed-off-by: Steven Rostedt <[email protected]>

This patch is against 3.4-rc2 (just happened to be a kernel checkout I
had).

diff --git a/kernel/pid.c b/kernel/pid.c
index 9f08dfa..32dab20 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -563,7 +563,9 @@ void __init pidmap_init(void)
PIDS_PER_CPU_MIN * num_possible_cpus());
pr_info("pid_max: default: %u minimum: %u\n", pid_max, pid_max_min);

- init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ /* Preemption is still disabled at this point */
+ init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_ATOMIC);
+ BUG_ON(!init_pid_ns.pidmap[0].page);
/* Reserve PID 0. We never call free_pidmap(0) */
set_bit(0, init_pid_ns.pidmap[0].page);
atomic_dec(&init_pid_ns.pidmap[0].nr_free);

2012-05-20 02:33:05

by David Rientjes

[permalink] [raw]
Subject: Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [ 00/54] 3.0.32-stable review)

On Sat, 19 May 2012, Steven Rostedt wrote:

> Ran 18 tests against 3.0.32-rc, 2 failed (16 passed!). One failed by a
> lock up (still looking into it) and the other is this one:
>
> Calibrating delay loop (skipped), value calculated using timer frequency.. 4799.59 BogoMIPS (lpj=2399799)
> pid_max: default: 32768 minimum: 301
> BUG: scheduling while atomic: swapper/0/0x10000002
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 3.1.0-rc9-test+ #1
> Call Trace:
> [<ffffffff81435b3e>] __schedule_bug+0x57/0x5b
> [<ffffffff8143c44f>] __schedule+0x90/0x672
> [<ffffffff810636dd>] ? kzalloc.constprop.2+0x24/0x26
> [<ffffffff810460d1>] __cond_resched+0x23/0x2f
> [<ffffffff8143ca83>] _cond_resched+0x14/0x1d^M
> [<ffffffff810f7cd3>] slab_pre_alloc_hook.isra.52+0x28/0x2c
> [<ffffffff810f8b1a>] kmem_cache_alloc_trace+0x29/0xbd
> [<ffffffff810636dd>] kzalloc.constprop.2+0x24/0x26
> [<ffffffff81b7a434>] pidmap_init+0x81/0xc0
> [<ffffffff81b61b03>] start_kernel+0x330/0x3c2
> [<ffffffff81b612c4>] x86_64_start_reservations+0xaf/0xb3
> [<ffffffff81b61140>] ? early_idt_handlers+0x140/0x140
> [<ffffffff81b613ca>] x86_64_start_kernel+0x102/0x111
> Security Framework initialized
>
> Had CONFIG_SLUB, IRQ_FORCED_THREADING and voluntary preempt enabled.
> Seems the might_resched() check from might_sleep_if() in
> pre_alloc_hook() caused a schedule in early boot (pidmap_init). Not sure
> why it scheduled that early, perhaps a threaded interrupt was added? I
> haven't been able to reproduce it again.
>
> Perhaps we should not be using GFP_KERNEL when allocating memory for
> pidmap_init()? As we have preemption disabled at this point, we should
> be using GFP_ATOMIC. Also add a BUG_ON if the page fails to get
> allocated.
>
> Signed-off-by: Steven Rostedt <[email protected]>
>
> This patch is against 3.4-rc2 (just happened to be a kernel checkout I
> had).
>
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 9f08dfa..32dab20 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -563,7 +563,9 @@ void __init pidmap_init(void)
> PIDS_PER_CPU_MIN * num_possible_cpus());
> pr_info("pid_max: default: %u minimum: %u\n", pid_max, pid_max_min);
>
> - init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + /* Preemption is still disabled at this point */
> + init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_ATOMIC);
> + BUG_ON(!init_pid_ns.pidmap[0].page);
> /* Reserve PID 0. We never call free_pidmap(0) */
> set_bit(0, init_pid_ns.pidmap[0].page);
> atomic_dec(&init_pid_ns.pidmap[0].nr_free);

Why wasn't this caught by gfp_allowed_mask in slab_pre_alloc_hook()?
GFP_KERNEL should be allowed in this context.

2012-05-20 19:04:06

by Linus Torvalds

[permalink] [raw]
Subject: Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [ 00/54] 3.0.32-stable review)

On Sat, May 19, 2012 at 7:32 PM, David Rientjes <[email protected]> wrote:
>
> Why wasn't this caught by gfp_allowed_mask in slab_pre_alloc_hook()?
> GFP_KERNEL should be allowed in this context.

We set gfp_allowed_mask to allow all allocations before this point: it
happens when we enable interrupts fairly early during start_kernel().

So by the time pidmap_init() is called, GFP_KERNEL does imply that
scheduling can happen.

Which does imply that we set gfp_allowed_mask *much* too early. We
still cannot schedule at that point (well, at least there's a comment
saying so):

/*
* Disable preemption - early bootup scheduling is extremely
* fragile until we cpu_idle() for the first time.
*/
preempt_disable();

so logically we should move the gfp_allowed_mask setting down to where
we really are properly alive.

How about moving it down to after we've done the full smp_init() and
after we've actually done the first schedule and have proper idle
CPU's?

Something like the attached (UNTESTED!) patch?

Linus


Attachments:
patch.diff (742.00 B)

2012-05-20 23:22:37

by David Rientjes

[permalink] [raw]
Subject: Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [ 00/54] 3.0.32-stable review)

On Sun, 20 May 2012, Linus Torvalds wrote:

> > Why wasn't this caught by gfp_allowed_mask in slab_pre_alloc_hook()?
> > GFP_KERNEL should be allowed in this context.
>
> We set gfp_allowed_mask to allow all allocations before this point: it
> happens when we enable interrupts fairly early during start_kernel().
>
> So by the time pidmap_init() is called, GFP_KERNEL does imply that
> scheduling can happen.
>

Steven notes that he's using CONFIG_PREEMPT_VOLUNTARY which means all
might_sleep()'s in the kernel actually get turned into cond_resched()'s.
I had thought that might_sleep() and might_sleep_if() such as in the slab
allocators were simply for CONFIG_DEBUG_ATOMIC_SLEEP, but it has been
hijacked for other purposes. Do we really want to infuse cond_resched()'s
on every slab allocation for desktop users who are urged in the Kconfig to
enable CONFIG_PREEMPT_VOLUNTARY?

> Which does imply that we set gfp_allowed_mask *much* too early. We
> still cannot schedule at that point (well, at least there's a comment
> saying so):
>
> /*
> * Disable preemption - early bootup scheduling is extremely
> * fragile until we cpu_idle() for the first time.
> */
> preempt_disable();
>
> so logically we should move the gfp_allowed_mask setting down to where
> we really are properly alive.
>
> How about moving it down to after we've done the full smp_init() and
> after we've actually done the first schedule and have proper idle
> CPU's?
>
> Something like the attached (UNTESTED!) patch?
>
> init/main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 44b2433334c7..0cf00943d755 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -560,9 +560,6 @@ asmlinkage void __init start_kernel(void)
> early_boot_irqs_disabled = false;
> local_irq_enable();
>
> - /* Interrupts are enabled now so all GFP allocations are safe. */
> - gfp_allowed_mask = __GFP_BITS_MASK;
> -
> kmem_cache_init_late();
>
> /*
> @@ -861,6 +858,9 @@ static int __init kernel_init(void * unused)
> smp_init();
> sched_init_smp();
>
> + /* Now we're finally set up and can do any allocation */
> + gfp_allowed_mask = __GFP_BITS_MASK;
> +
> do_basic_setup();
>
> /* Open the /dev/console on the rootfs, this should never fail */

I think this may be unnecessarily too late; smp_init() will rely on the
arch-dependent cpu_up to guarantee that cpu_idle() has been called and
sched_init_smp() seems to think we can do GFP_KERNEL.

So putting this in between smp_init() and sched_init_smp() may be the
first time we can absolutely guarantee that we are scheduable. BUT, we
typically become schedulable when kernel_init() returns from the
wait_for_completion(&kthreadd_done) because cpu_idle() has been called in
rest_init() right after doing complete(&kthreadd_done) so it's slightly
racy.

I think we should look in between that wait_for_completion() and
smp_init() to determine if there's anything that would benefit from
GFP_KERNEL over GFP_NOWAIT and I can't see anything. I do think
sched_init_smp() unnecessarily suppresses __GFP_WAIT with your patch, so
perhaps it should be moved right before it if we're actually going to
allow CONFIG_PREEMPT_VOLUNTARY to schedule on might_sleep()'s.

2012-05-20 23:36:21

by Linus Torvalds

[permalink] [raw]
Subject: Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [ 00/54] 3.0.32-stable review)

On Sun, May 20, 2012 at 4:22 PM, David Rientjes <[email protected]> wrote:
>
> I think this may be unnecessarily too late; smp_init() will rely on the
> arch-dependent cpu_up to guarantee that cpu_idle() has been called and
> sched_init_smp() seems to think we can do GFP_KERNEL.

Well, yes, we can pretty much rely on scheduling having to work at the
top of kernel_init(), since kernel_init is being run in a new thread
(and thus must have scheduled from the original thread that becomes
the first idle thread).

But I thought we might as well delay it until the system was really
up, since I wasn't entirely sure what the heck the other CPU's might
be doing. That said, I don't really care deeply, I think that anywhere
in kernel_init should be fine. I have no strong opinions, but the
current location does seem buggy.

That said, I'm not going to delay 3.4 over this (in fact, I already
tagged it locally, but haven't pushed out yet because the back-end
kernel.org machines seem to be unreachable right now). It apparently
only matters for configurations that are not really all that
realistic.

Linus

Subject: Re: [ 13/54] net: In unregister_netdevice_notifier unregister the netdevices.

On Fri, May 18, 2012 at 02:16:12PM -0700, Greg KH wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
>
> From: "Eric W. Biederman" <[email protected]>
>
> [ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ]
>
> We already synthesize events in register_netdevice_notifier and synthesizing
> events in unregister_netdevice_notifier allows to us remove the need for
> special case cleanup code.
>
> This change should be safe as it adds no new cases for existing callers
> of unregiser_netdevice_notifier to handle.
>
> Signed-off-by: Eric W. Biederman <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Please also include these two commits in addition to this change, to
avoid a regression with pktgen:
commit c57b54684060c8aced64a5b78ff69ff289af97b9
commit d4b1133558e0d417342d5d2c49e4c35b428ff20d

> ---
> net/core/dev.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1406,14 +1406,34 @@ EXPORT_SYMBOL(register_netdevice_notifie
> * register_netdevice_notifier(). The notifier is unlinked into the
> * kernel structures and may then be reused. A negative errno code
> * is returned on a failure.
> + *
> + * After unregistering unregister and down device events are synthesized
> + * for all devices on the device list to the removed notifier to remove
> + * the need for special case cleanup code.
> */
>
> int unregister_netdevice_notifier(struct notifier_block *nb)
> {
> + struct net_device *dev;
> + struct net *net;
> int err;
>
> rtnl_lock();
> err = raw_notifier_chain_unregister(&netdev_chain, nb);
> + if (err)
> + goto unlock;
> +
> + for_each_net(net) {
> + for_each_netdev(net, dev) {
> + if (dev->flags & IFF_UP) {
> + nb->notifier_call(nb, NETDEV_GOING_DOWN, dev);
> + nb->notifier_call(nb, NETDEV_DOWN, dev);
> + }
> + nb->notifier_call(nb, NETDEV_UNREGISTER, dev);
> + nb->notifier_call(nb, NETDEV_UNREGISTER_BATCH, dev);
> + }
> + }
> +unlock:
> rtnl_unlock();
> return err;
> }
>
>
> --
> 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
>

--
[]'s
Herton

2012-05-27 00:13:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 13/54] net: In unregister_netdevice_notifier unregister the netdevices.

On Mon, May 21, 2012 at 02:35:12PM -0300, Herton Ronaldo Krzesinski wrote:
> On Fri, May 18, 2012 at 02:16:12PM -0700, Greg KH wrote:
> > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> >
> > From: "Eric W. Biederman" <[email protected]>
> >
> > [ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ]
> >
> > We already synthesize events in register_netdevice_notifier and synthesizing
> > events in unregister_netdevice_notifier allows to us remove the need for
> > special case cleanup code.
> >
> > This change should be safe as it adds no new cases for existing callers
> > of unregiser_netdevice_notifier to handle.
> >
> > Signed-off-by: Eric W. Biederman <[email protected]>
> > Signed-off-by: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Please also include these two commits in addition to this change, to
> avoid a regression with pktgen:
> commit c57b54684060c8aced64a5b78ff69ff289af97b9
> commit d4b1133558e0d417342d5d2c49e4c35b428ff20d

I need an ack from the network maintainers for me to be able to accept
this.

thanks,

greg k-h

2012-05-27 00:18:34

by David Miller

[permalink] [raw]
Subject: Re: [ 13/54] net: In unregister_netdevice_notifier unregister the netdevices.

From: Greg KH <[email protected]>
Date: Sun, 27 May 2012 09:13:49 +0900

> On Mon, May 21, 2012 at 02:35:12PM -0300, Herton Ronaldo Krzesinski wrote:
>> On Fri, May 18, 2012 at 02:16:12PM -0700, Greg KH wrote:
>> > 3.0-stable review patch. If anyone has any objections, please let me know.
>> >
>> > ------------------
>> >
>> >
>> > From: "Eric W. Biederman" <[email protected]>
>> >
>> > [ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ]
>> >
>> > We already synthesize events in register_netdevice_notifier and synthesizing
>> > events in unregister_netdevice_notifier allows to us remove the need for
>> > special case cleanup code.
>> >
>> > This change should be safe as it adds no new cases for existing callers
>> > of unregiser_netdevice_notifier to handle.
>> >
>> > Signed-off-by: Eric W. Biederman <[email protected]>
>> > Signed-off-by: David S. Miller <[email protected]>
>> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>
>> Please also include these two commits in addition to this change, to
>> avoid a regression with pktgen:
>> commit c57b54684060c8aced64a5b78ff69ff289af97b9
>> commit d4b1133558e0d417342d5d2c49e4c35b428ff20d
>
> I need an ack from the network maintainers for me to be able to accept
> this.

These bugs only effect networking hackers doing low-level packet
spamming on their network using pktgen, who furthermore try to unload
the pktgen module.

Low level network packet spamming using pktgen, and trying to unload
that module, adds up to an extremely small minority of users.

Therefore these changes are not worth putting into -stable by any
measurement.

Ben decided to add them to 3.2.x, but that is entirely his perogative.

2012-05-27 00:23:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 13/54] net: In unregister_netdevice_notifier unregister the netdevices.

On Sat, May 26, 2012 at 08:18:14PM -0400, David Miller wrote:
> From: Greg KH <[email protected]>
> Date: Sun, 27 May 2012 09:13:49 +0900
>
> > On Mon, May 21, 2012 at 02:35:12PM -0300, Herton Ronaldo Krzesinski wrote:
> >> On Fri, May 18, 2012 at 02:16:12PM -0700, Greg KH wrote:
> >> > 3.0-stable review patch. If anyone has any objections, please let me know.
> >> >
> >> > ------------------
> >> >
> >> >
> >> > From: "Eric W. Biederman" <[email protected]>
> >> >
> >> > [ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ]
> >> >
> >> > We already synthesize events in register_netdevice_notifier and synthesizing
> >> > events in unregister_netdevice_notifier allows to us remove the need for
> >> > special case cleanup code.
> >> >
> >> > This change should be safe as it adds no new cases for existing callers
> >> > of unregiser_netdevice_notifier to handle.
> >> >
> >> > Signed-off-by: Eric W. Biederman <[email protected]>
> >> > Signed-off-by: David S. Miller <[email protected]>
> >> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >>
> >> Please also include these two commits in addition to this change, to
> >> avoid a regression with pktgen:
> >> commit c57b54684060c8aced64a5b78ff69ff289af97b9
> >> commit d4b1133558e0d417342d5d2c49e4c35b428ff20d
> >
> > I need an ack from the network maintainers for me to be able to accept
> > this.
>
> These bugs only effect networking hackers doing low-level packet
> spamming on their network using pktgen, who furthermore try to unload
> the pktgen module.
>
> Low level network packet spamming using pktgen, and trying to unload
> that module, adds up to an extremely small minority of users.
>
> Therefore these changes are not worth putting into -stable by any
> measurement.

Ok, thanks, I'll not do this for 3.0-stable then, as no developer should
really be using that kernel anymore :)

greg k-h