Lars-Peter Clausen [Thu, 5 May 2011 14:59:16 +0000 (16:59 +0200)]
ASoC: SSM2602: Fix 'Mic Boost2' control
BugLink: http://bugs.launchpad.net/bugs/788691
commit
36c90ab33feabbd63da775bd92ad356e5bd5cf56 upstream.
The 'Mic Boost2' control's shift was off by one and thus was not working.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Marek Belisko [Tue, 3 May 2011 12:46:32 +0000 (14:46 +0200)]
ASoC: UDA134x: Remove POWER_OFF_ON_STANDBY define.
BugLink: http://bugs.launchpad.net/bugs/788691
commit
bf707de21fec7bb203dace2d0a2bbd124d1b36ca upstream.
Define POWER_OFF_ON_STANDBY cause trobles when trying to get some
sound from codec because code for bias setup was not compiled
(define wasn't defined). This define was removed in commit:
cc3202f5 but again introduced by commit:
f0fba2ad1 which then
completely break codec functionality so remove it again.
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Oliver Hartkopp [Tue, 10 May 2011 20:12:30 +0000 (13:12 -0700)]
slcan: fix ldisc->open retval
BugLink: http://bugs.launchpad.net/bugs/788691
commit
0d4420a90b51abdea71585f571bad6d789ff8eb7 upstream.
TTY layer expects 0 if the ldisc->open operation succeeded.
Reported-by: Matvejchikov Ilya <matvejchikov@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Eric Dumazet [Tue, 10 May 2011 19:26:06 +0000 (12:26 -0700)]
net: dev_close() should check IFF_UP
BugLink: http://bugs.launchpad.net/bugs/788691
commit
e14a599335427f81bbb0008963e59aa9c6449dce upstream.
Commit
443457242beb (factorize sync-rcu call in
unregister_netdevice_many) mistakenly removed one test from dev_close()
Following actions trigger a BUG :
modprobe bonding
modprobe dummy
ifconfig bond0 up
ifenslave bond0 dummy0
rmmod dummy
dev_close() must not close a non IFF_UP device.
With help from Frank Blaschka and Einar EL Lueck
Reported-by: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Reported-by: Einar EL Lueck <ELELUECK@de.ibm.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Tomoya [Mon, 9 May 2011 01:19:37 +0000 (01:19 +0000)]
pch_gbe: support ML7223 IOH
BugLink: http://bugs.launchpad.net/bugs/788691
commit
b0e6baf5619a6fa3eaf43b55fdb4daa362c3c916 upstream.
Support new device OKI SEMICONDUCTOR ML7223 IOH(Input/Output Hub).
The ML7223 IOH is for MP(Media Phone) use.
The ML7223 is companion chip for Intel Atom E6xx series.
The ML7223 is completely compatible for Intel EG20T PCH.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Toshiharu Okada [Fri, 6 May 2011 02:53:56 +0000 (02:53 +0000)]
PCH_GbE : Fixed the issue of checksum judgment
BugLink: http://bugs.launchpad.net/bugs/788691
commit
5d05a04d283061b586e8dc819cfa6f4b8cfd5948 upstream.
The checksum judgment was mistaken.
Judgment result
0:Correct 1:Wrong
This patch fixes the issue.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Toshiharu Okada [Fri, 6 May 2011 02:53:51 +0000 (02:53 +0000)]
PCH_GbE : Fixed the issue of collision detection
BugLink: http://bugs.launchpad.net/bugs/788691
commit
ce3dad0f74e6b240f0b1dedbd8ea268a3f298d82 upstream.
The collision detection setting was invalid.
When collision occurred, because data was not resent,
there was an issue to which a transmitting throughput falls.
This patch enables the collision detection.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Matvejchikov Ilya [Fri, 6 May 2011 06:23:09 +0000 (06:23 +0000)]
NET: slip, fix ldisc->open retval
BugLink: http://bugs.launchpad.net/bugs/788691
commit
057bef938896e6266ae24ec4266d24792d27c29a upstream.
TTY layer expects 0 if the ldisc->open operation succeeded.
Signed-off-by : Matvejchikov Ilya <matvejchikov@gmail.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Kleber Sacilotto de Souza [Wed, 4 May 2011 13:05:11 +0000 (13:05 +0000)]
ehea: fix wrongly reported speed and port
BugLink: http://bugs.launchpad.net/bugs/788691
commit
dcbe14b91a920657ff3a9ba0efb7c5b5562f956a upstream.
Currently EHEA reports to ethtool as supporting 10M, 100M, 1G and
10G and connected to FIBRE independent of the hardware configuration.
However, when connected to FIBRE the only supported speed is 10G
full-duplex, and the other speeds and modes are only supported
when connected to twisted pair.
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Roland Dreier [Fri, 6 May 2011 08:32:53 +0000 (08:32 +0000)]
vmxnet3: Consistently disable irqs when taking adapter->cmd_lock
BugLink: http://bugs.launchpad.net/bugs/788691
commit
e328d410826d52e9ee348aff9064c4a207f2adb1 upstream.
Using the vmxnet3 driver produces a lockdep warning because
vmxnet3_set_mc(), which is called with mc->mca_lock held, takes
adapter->cmd_lock. However, there are a couple of places where
adapter->cmd_lock is taken with softirqs enabled, lockdep warns that a
softirq that tries to take mc->mca_lock could happen while
adapter->cmd_lock is held, leading to an AB-BA deadlock.
I'm not sure if this is a real potential deadlock or not, but the
simplest and best fix seems to be simply to make sure we take cmd_lock
with spin_lock_irqsave() everywhere -- the places with plain spin_lock
just look like oversights.
The full enormous lockdep warning is:
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.39-rc6+ #1
---------------------------------------------------------
ifconfig/567 just changed the state of lock:
(&(&mc->mca_lock)->rlock){+.-...}, at: [<
ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
but this lock took another, SOFTIRQ-unsafe lock in the past:
(&(&adapter->cmd_lock)->rlock){+.+...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
4 locks held by ifconfig/567:
#0: (rtnl_mutex){+.+.+.}, at: [<
ffffffff8147d547>] rtnl_lock+0x17/0x20
#1: ((inetaddr_chain).rwsem){.+.+.+}, at: [<
ffffffff810896cf>] __blocking_notifier_call_chain+0x5f/0xb0
#2: (&idev->mc_ifc_timer){+.-...}, at: [<
ffffffff8106f21b>] run_timer_softirq+0xeb/0x3f0
#3: (&ndev->lock){++.-..}, at: [<
ffffffff81531dd2>] mld_ifc_timer_expire+0x32/0x280
the shortest dependencies between 2nd lock and 1st lock:
-> (&(&adapter->cmd_lock)->rlock){+.+...} ops: 11 {
HARDIRQ-ON-W at:
[<
ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff81571156>] _raw_spin_lock+0x36/0x70
[<
ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3]
[<
ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3]
[<
ffffffff812df67f>] local_pci_probe+0x5f/0xd0
[<
ffffffff812dfde9>] pci_device_probe+0x119/0x120
[<
ffffffff81373df6>] driver_probe_device+0x96/0x1c0
[<
ffffffff81373fcb>] __driver_attach+0xab/0xb0
[<
ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
[<
ffffffff81373a2e>] driver_attach+0x1e/0x20
[<
ffffffff813735b8>] bus_add_driver+0xc8/0x290
[<
ffffffff813745b6>] driver_register+0x76/0x140
[<
ffffffff812e0046>] __pci_register_driver+0x66/0xe0
[<
ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff810aa76b>] sys_init_module+0xfb/0x250
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
SOFTIRQ-ON-W at:
[<
ffffffff8109adb7>] __lock_acquire+0x827/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff81571156>] _raw_spin_lock+0x36/0x70
[<
ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3]
[<
ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3]
[<
ffffffff812df67f>] local_pci_probe+0x5f/0xd0
[<
ffffffff812dfde9>] pci_device_probe+0x119/0x120
[<
ffffffff81373df6>] driver_probe_device+0x96/0x1c0
[<
ffffffff81373fcb>] __driver_attach+0xab/0xb0
[<
ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
[<
ffffffff81373a2e>] driver_attach+0x1e/0x20
[<
ffffffff813735b8>] bus_add_driver+0xc8/0x290
[<
ffffffff813745b6>] driver_register+0x76/0x140
[<
ffffffff812e0046>] __pci_register_driver+0x66/0xe0
[<
ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff810aa76b>] sys_init_module+0xfb/0x250
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
INITIAL USE at:
[<
ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff81571156>] _raw_spin_lock+0x36/0x70
[<
ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3]
[<
ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3]
[<
ffffffff812df67f>] local_pci_probe+0x5f/0xd0
[<
ffffffff812dfde9>] pci_device_probe+0x119/0x120
[<
ffffffff81373df6>] driver_probe_device+0x96/0x1c0
[<
ffffffff81373fcb>] __driver_attach+0xab/0xb0
[<
ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
[<
ffffffff81373a2e>] driver_attach+0x1e/0x20
[<
ffffffff813735b8>] bus_add_driver+0xc8/0x290
[<
ffffffff813745b6>] driver_register+0x76/0x140
[<
ffffffff812e0046>] __pci_register_driver+0x66/0xe0
[<
ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff810aa76b>] sys_init_module+0xfb/0x250
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
}
... key at: [<
ffffffffa0017590>] __key.42516+0x0/0xffffffffffffda70 [vmxnet3]
... acquired at:
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff81571bb5>] _raw_spin_lock_irqsave+0x55/0xa0
[<
ffffffffa000de27>] vmxnet3_set_mc+0x97/0x1a0 [vmxnet3]
[<
ffffffff8146ffa0>] __dev_set_rx_mode+0x40/0xb0
[<
ffffffff81470040>] dev_set_rx_mode+0x30/0x50
[<
ffffffff81470127>] __dev_open+0xc7/0x100
[<
ffffffff814703c1>] __dev_change_flags+0xa1/0x180
[<
ffffffff81470568>] dev_change_flags+0x28/0x70
[<
ffffffff814da960>] devinet_ioctl+0x730/0x800
[<
ffffffff814db508>] inet_ioctl+0x88/0xa0
[<
ffffffff814541f0>] sock_do_ioctl+0x30/0x70
[<
ffffffff814542a9>] sock_ioctl+0x79/0x2f0
[<
ffffffff81188798>] do_vfs_ioctl+0x98/0x570
[<
ffffffff81188d01>] sys_ioctl+0x91/0xa0
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
-> (_xmit_ETHER){+.....} ops: 6 {
HARDIRQ-ON-W at:
[<
ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81475618>] __dev_mc_add+0x38/0x90
[<
ffffffff814756a0>] dev_mc_add+0x10/0x20
[<
ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0
[<
ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
[<
ffffffff81515e17>] ipv6_add_dev+0x357/0x450
[<
ffffffff81519f27>] addrconf_notify+0x2f7/0xb10
[<
ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
[<
ffffffff81089586>] raw_notifier_call_chain+0x16/0x20
[<
ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70
[<
ffffffff8146a944>] register_netdevice+0x244/0x2d0
[<
ffffffff8146aa0f>] register_netdev+0x3f/0x60
[<
ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3]
[<
ffffffff812df67f>] local_pci_probe+0x5f/0xd0
[<
ffffffff812dfde9>] pci_device_probe+0x119/0x120
[<
ffffffff81373df6>] driver_probe_device+0x96/0x1c0
[<
ffffffff81373fcb>] __driver_attach+0xab/0xb0
[<
ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
[<
ffffffff81373a2e>] driver_attach+0x1e/0x20
[<
ffffffff813735b8>] bus_add_driver+0xc8/0x290
[<
ffffffff813745b6>] driver_register+0x76/0x140
[<
ffffffff812e0046>] __pci_register_driver+0x66/0xe0
[<
ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff810aa76b>] sys_init_module+0xfb/0x250
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
INITIAL USE at:
[<
ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81475618>] __dev_mc_add+0x38/0x90
[<
ffffffff814756a0>] dev_mc_add+0x10/0x20
[<
ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0
[<
ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
[<
ffffffff81515e17>] ipv6_add_dev+0x357/0x450
[<
ffffffff81519f27>] addrconf_notify+0x2f7/0xb10
[<
ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
[<
ffffffff81089586>] raw_notifier_call_chain+0x16/0x20
[<
ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70
[<
ffffffff8146a944>] register_netdevice+0x244/0x2d0
[<
ffffffff8146aa0f>] register_netdev+0x3f/0x60
[<
ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3]
[<
ffffffff812df67f>] local_pci_probe+0x5f/0xd0
[<
ffffffff812dfde9>] pci_device_probe+0x119/0x120
[<
ffffffff81373df6>] driver_probe_device+0x96/0x1c0
[<
ffffffff81373fcb>] __driver_attach+0xab/0xb0
[<
ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
[<
ffffffff81373a2e>] driver_attach+0x1e/0x20
[<
ffffffff813735b8>] bus_add_driver+0xc8/0x290
[<
ffffffff813745b6>] driver_register+0x76/0x140
[<
ffffffff812e0046>] __pci_register_driver+0x66/0xe0
[<
ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff810aa76b>] sys_init_module+0xfb/0x250
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
}
... key at: [<
ffffffff827fd868>] netdev_addr_lock_key+0x8/0x1e0
... acquired at:
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81475618>] __dev_mc_add+0x38/0x90
[<
ffffffff814756a0>] dev_mc_add+0x10/0x20
[<
ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0
[<
ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
[<
ffffffff81515e17>] ipv6_add_dev+0x357/0x450
[<
ffffffff81519f27>] addrconf_notify+0x2f7/0xb10
[<
ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
[<
ffffffff81089586>] raw_notifier_call_chain+0x16/0x20
[<
ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70
[<
ffffffff8146a944>] register_netdevice+0x244/0x2d0
[<
ffffffff8146aa0f>] register_netdev+0x3f/0x60
[<
ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3]
[<
ffffffff812df67f>] local_pci_probe+0x5f/0xd0
[<
ffffffff812dfde9>] pci_device_probe+0x119/0x120
[<
ffffffff81373df6>] driver_probe_device+0x96/0x1c0
[<
ffffffff81373fcb>] __driver_attach+0xab/0xb0
[<
ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
[<
ffffffff81373a2e>] driver_attach+0x1e/0x20
[<
ffffffff813735b8>] bus_add_driver+0xc8/0x290
[<
ffffffff813745b6>] driver_register+0x76/0x140
[<
ffffffff812e0046>] __pci_register_driver+0x66/0xe0
[<
ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff810aa76b>] sys_init_module+0xfb/0x250
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
-> (&(&mc->mca_lock)->rlock){+.-...} ops: 6 {
HARDIRQ-ON-W at:
[<
ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81532bd5>] igmp6_group_added+0x45/0x1b0
[<
ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
[<
ffffffff81515e17>] ipv6_add_dev+0x357/0x450
[<
ffffffff81ce0d16>] addrconf_init+0x4e/0x183
[<
ffffffff81ce0ba1>] inet6_init+0x191/0x2a6
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff81ca4d3f>] kernel_init+0xe3/0x168
[<
ffffffff8157b2e4>] kernel_thread_helper+0x4/0x10
IN-SOFTIRQ-W at:
[<
ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
[<
ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0
[<
ffffffff810666d0>] __do_softirq+0xc0/0x210
[<
ffffffff8157b3dc>] call_softirq+0x1c/0x30
[<
ffffffff8100d42d>] do_softirq+0xad/0xe0
[<
ffffffff81066afe>] irq_exit+0x9e/0xb0
[<
ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b
[<
ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20
[<
ffffffff8149d857>] rt_do_flush+0x87/0x2a0
[<
ffffffff814a16b6>] rt_cache_flush+0x46/0x60
[<
ffffffff814e36e0>] fib_disable_ip+0x40/0x60
[<
ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0
[<
ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
[<
ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0
[<
ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20
[<
ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0
[<
ffffffff814d8223>] inet_del_ifa+0x13/0x20
[<
ffffffff814da731>] devinet_ioctl+0x501/0x800
[<
ffffffff814db508>] inet_ioctl+0x88/0xa0
[<
ffffffff814541f0>] sock_do_ioctl+0x30/0x70
[<
ffffffff814542a9>] sock_ioctl+0x79/0x2f0
[<
ffffffff81188798>] do_vfs_ioctl+0x98/0x570
[<
ffffffff81188d01>] sys_ioctl+0x91/0xa0
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
INITIAL USE at:
[<
ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81532bd5>] igmp6_group_added+0x45/0x1b0
[<
ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
[<
ffffffff81515e17>] ipv6_add_dev+0x357/0x450
[<
ffffffff81ce0d16>] addrconf_init+0x4e/0x183
[<
ffffffff81ce0ba1>] inet6_init+0x191/0x2a6
[<
ffffffff81002165>] do_one_initcall+0x45/0x190
[<
ffffffff81ca4d3f>] kernel_init+0xe3/0x168
[<
ffffffff8157b2e4>] kernel_thread_helper+0x4/0x10
}
... key at: [<
ffffffff82801be2>] __key.40877+0x0/0x8
... acquired at:
[<
ffffffff810997bc>] check_usage_forwards+0x9c/0x110
[<
ffffffff8109a32c>] mark_lock+0x19c/0x400
[<
ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
[<
ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0
[<
ffffffff810666d0>] __do_softirq+0xc0/0x210
[<
ffffffff8157b3dc>] call_softirq+0x1c/0x30
[<
ffffffff8100d42d>] do_softirq+0xad/0xe0
[<
ffffffff81066afe>] irq_exit+0x9e/0xb0
[<
ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b
[<
ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20
[<
ffffffff8149d857>] rt_do_flush+0x87/0x2a0
[<
ffffffff814a16b6>] rt_cache_flush+0x46/0x60
[<
ffffffff814e36e0>] fib_disable_ip+0x40/0x60
[<
ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0
[<
ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
[<
ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0
[<
ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20
[<
ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0
[<
ffffffff814d8223>] inet_del_ifa+0x13/0x20
[<
ffffffff814da731>] devinet_ioctl+0x501/0x800
[<
ffffffff814db508>] inet_ioctl+0x88/0xa0
[<
ffffffff814541f0>] sock_do_ioctl+0x30/0x70
[<
ffffffff814542a9>] sock_ioctl+0x79/0x2f0
[<
ffffffff81188798>] do_vfs_ioctl+0x98/0x570
[<
ffffffff81188d01>] sys_ioctl+0x91/0xa0
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
stack backtrace:
Pid: 567, comm: ifconfig Not tainted 2.6.39-rc6+ #1
Call Trace:
<IRQ> [<
ffffffff810996f6>] print_irq_inversion_bug+0x146/0x170
[<
ffffffff81099720>] ? print_irq_inversion_bug+0x170/0x170
[<
ffffffff810997bc>] check_usage_forwards+0x9c/0x110
[<
ffffffff8109a32c>] mark_lock+0x19c/0x400
[<
ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10
[<
ffffffff8109a383>] ? mark_lock+0x1f3/0x400
[<
ffffffff8109b497>] ? __lock_acquire+0xf07/0x1e10
[<
ffffffff81012255>] ? native_sched_clock+0x15/0x70
[<
ffffffff8109ca4d>] lock_acquire+0x9d/0x130
[<
ffffffff81531e9f>] ? mld_ifc_timer_expire+0xff/0x280
[<
ffffffff8109759d>] ? lock_release_holdtime+0x3d/0x1a0
[<
ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
[<
ffffffff81531e9f>] ? mld_ifc_timer_expire+0xff/0x280
[<
ffffffff8157170b>] ? _raw_spin_unlock+0x2b/0x40
[<
ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
[<
ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0
[<
ffffffff8106f21b>] ? run_timer_softirq+0xeb/0x3f0
[<
ffffffff810122b9>] ? sched_clock+0x9/0x10
[<
ffffffff81531da0>] ? mld_gq_timer_expire+0x30/0x30
[<
ffffffff810666d0>] __do_softirq+0xc0/0x210
[<
ffffffff8109455f>] ? tick_program_event+0x1f/0x30
[<
ffffffff8157b3dc>] call_softirq+0x1c/0x30
[<
ffffffff8100d42d>] do_softirq+0xad/0xe0
[<
ffffffff81066afe>] irq_exit+0x9e/0xb0
[<
ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b
[<
ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20
<EOI> [<
ffffffff81571f14>] ? retint_restore_args+0x13/0x13
[<
ffffffff810974a7>] ? lock_is_held+0x17/0xd0
[<
ffffffff8149d857>] rt_do_flush+0x87/0x2a0
[<
ffffffff814a16b6>] rt_cache_flush+0x46/0x60
[<
ffffffff814e36e0>] fib_disable_ip+0x40/0x60
[<
ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0
[<
ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
[<
ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0
[<
ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20
[<
ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0
[<
ffffffff814d8223>] inet_del_ifa+0x13/0x20
[<
ffffffff814da731>] devinet_ioctl+0x501/0x800
[<
ffffffff8108a3af>] ? local_clock+0x6f/0x80
[<
ffffffff81575898>] ? do_page_fault+0x268/0x560
[<
ffffffff814db508>] inet_ioctl+0x88/0xa0
[<
ffffffff814541f0>] sock_do_ioctl+0x30/0x70
[<
ffffffff814542a9>] sock_ioctl+0x79/0x2f0
[<
ffffffff810dfe87>] ? __call_rcu+0xa7/0x190
[<
ffffffff81188798>] do_vfs_ioctl+0x98/0x570
[<
ffffffff8117737e>] ? fget_light+0x33e/0x430
[<
ffffffff81571ef9>] ? retint_swapgs+0x13/0x1b
[<
ffffffff81188d01>] sys_ioctl+0x91/0xa0
[<
ffffffff8157a142>] system_call_fastpath+0x16/0x1b
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Ben Hutchings [Tue, 3 May 2011 07:49:25 +0000 (07:49 +0000)]
ipheth: Properly distinguish length and alignment in URBs and skbs
BugLink: http://bugs.launchpad.net/bugs/788691
commit
9c412942a0bb19ba18f7bd939d42eff1e132a901 upstream.
The USB protocol this driver implements appears to require 2 bytes of
padding in front of each received packet. This used to be equal to
the value of NET_IP_ALIGN on x86, so the driver abused that constant
and mostly worked, but this is no longer the case. The driver also
mixed up the URB and packet lengths, resulting in 2 bytes of junk at
the end of the skb.
Introduce a private constant for the 2 bytes of padding; fix this
confusion and check for the under-length case.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Kurt Van Dijck [Mon, 2 May 2011 04:50:48 +0000 (04:50 +0000)]
can: fix SJA1000 dlc for RTR packets
BugLink: http://bugs.launchpad.net/bugs/788691
commit
87e9af6cc67d842cd92b52b81f3f14e665e7ab05 upstream.
RTR frames do have a valid data length code on CAN.
The driver for SJA1000 did not handle that situation properly.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Eric Dumazet [Wed, 4 May 2011 10:02:26 +0000 (10:02 +0000)]
net: ip_expire() must revalidate route
BugLink: http://bugs.launchpad.net/bugs/788691
commit
64f3b9e203bd06855072e295557dca1485a2ecba upstream.
Commit
4a94445c9a5c (net: Use ip_route_input_noref() in input path)
added a bug in IP defragmentation handling, in case timeout is fired.
When a frame is defragmented, we use last skb dst field when building
final skb. Its dst is valid, since we are in rcu read section.
But if a timeout occurs, we take first queued fragment to build one ICMP
TIME EXCEEDED message. Problem is all queued skb have weak dst pointers,
since we escaped RCU critical section after their queueing. icmp_send()
might dereference a now freed (and possibly reused) part of memory.
Calling skb_dst_drop() and ip_route_input_noref() to revalidate route is
the only possible choice.
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Rafael J. Wysocki [Tue, 10 May 2011 19:10:13 +0000 (21:10 +0200)]
PM / Hibernate: Fix ioctl SNAPSHOT_S2RAM
BugLink: http://bugs.launchpad.net/bugs/788691
commit
36cb7035ea0c11ef2c7fa2bbe0cd181b23569b29 upstream.
The SNAPSHOT_S2RAM ioctl used for implementing the feature allowing
one to suspend to RAM after creating a hibernation image is currently
broken, because it doesn't clear the "ready" flag in the struct
snapshot_data object handled by it. As a result, the
SNAPSHOT_UNFREEZE doesn't work correctly after SNAPSHOT_S2RAM has
returned and the user space hibernate task cannot thaw the other
processes as appropriate. Make SNAPSHOT_S2RAM clear data->ready
to fix this problem.
Tested-by: Alexandre Felipe Muller de Souza <alexandrefm@mandriva.com.br>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Rafael J. Wysocki [Tue, 10 May 2011 19:10:01 +0000 (21:10 +0200)]
PM / Hibernate: Make snapshot_release() restore GFP mask
BugLink: http://bugs.launchpad.net/bugs/788691
commit
9744997a8a2280e67984d4bffd87221d24f3b6b1 upstream.
If the process using the hibernate user space interface closes
/dev/snapshot after creating a hibernation image without thawing
tasks, snapshot_release() should call pm_restore_gfp_mask() to
restore the GFP mask used before the creation of the image. Make
that happen.
Tested-by: Alexandre Felipe Muller de Souza <alexandrefm@mandriva.com.br>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Rafael J. Wysocki [Tue, 10 May 2011 19:09:53 +0000 (21:09 +0200)]
PM: Fix warning in pm_restrict_gfp_mask() during SNAPSHOT_S2RAM ioctl
BugLink: http://bugs.launchpad.net/bugs/788691
commit
87186475a402391a1ca7d42a675c9b35a18dc348 upstream.
A warning is printed by pm_restrict_gfp_mask() while the
SNAPSHOT_S2RAM ioctl is being executed after creating a hibernation
image, because pm_restrict_gfp_mask() has been called once already
before the image creation and suspend_devices_and_enter() calls it
once again. This happens after commit
452aa6999e6703ffbddd7f6ea124d3
(mm/pm: force GFP_NOIO during suspend/hibernation and resume).
To avoid this issue, move pm_restrict_gfp_mask() and
pm_restore_gfp_mask() from suspend_devices_and_enter() to its caller
in kernel/power/suspend.c.
Reported-by: Alexandre Felipe Muller de Souza <alexandrefm@mandriva.com.br>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Nicolas Pitre [Fri, 22 Apr 2011 01:45:08 +0000 (21:45 -0400)]
ARM: zImage: make sure the stack is 64-bit aligned
BugLink: http://bugs.launchpad.net/bugs/788691
commit
3bd2cbb95543acf44fe123eb9f038de54e655eb4 upstream.
With ARMv5+ and EABI, the compiler expects a 64-bit aligned stack so
instructions like STRD and LDRD can be used. Without this, mysterious
boot failures were seen semi randomly with the LZMA decompressor.
While at it, let's align .bss as well.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Wed, 11 May 2011 22:13:37 +0000 (15:13 -0700)]
tmpfs: fix race between umount and swapoff
BugLink: http://bugs.launchpad.net/bugs/788691
commit
778dd893ae785c5fd505dac30b5fc40aae188bf1 upstream.
The use of igrab() in swapoff's shmem_unuse_inode() is just as vulnerable
to umount as that in shmem_writepage().
Fix this instance by extending the protection of shmem_swaplist_mutex
right across shmem_unuse_inode(): while it's on the list, the inode cannot
be evicted (and the filesystem cannot be unmounted) without
shmem_evict_inode() taking that mutex to remove it from the list.
But since shmem_writepage() might take that mutex, we should avoid making
memory allocations or memcg charges while holding it: prepare them at the
outer level in shmem_unuse(). When mem_cgroup_cache_charge() was
originally placed, we didn't know until that point that the page from swap
was actually a shmem page; but nowadays it's noted in the swap_map, so
we're safe to charge upfront. For the radix_tree, do as is done in
shmem_getpage(): preload upfront, but don't pin to the cpu; so we make a
habit of refreshing the node pool, but might dip into GFP_NOWAIT reserves
on occasion if subsequently preempted.
With the allocation and charge moved out from shmem_unuse_inode(),
we can also hold index map and info->lock over from finding the entry.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Yinghai Lu [Wed, 11 May 2011 22:13:32 +0000 (15:13 -0700)]
mm: use alloc_bootmem_node_nopanic() on really needed path
BugLink: http://bugs.launchpad.net/bugs/788691
commit
8f389a99b652aab5b42297280bd94d95933ad12f upstream.
Stefan found nobootmem does not work on his system that has only 8M of
RAM. This causes an early panic:
BIOS-provided physical RAM map:
BIOS-88:
0000000000000000 -
000000000009f000 (usable)
BIOS-88:
0000000000100000 -
0000000000840000 (usable)
bootconsole [earlyser0] enabled
Notice: NX (Execute Disable) protection missing in CPU or disabled in BIOS!
DMI not present or invalid.
last_pfn = 0x840 max_arch_pfn = 0x100000
init_memory_mapping:
0000000000000000-
0000000000840000
8MB LOWMEM available.
mapped low ram: 0 -
00840000
low ram: 0 -
00840000
Zone PFN ranges:
DMA 0x00000001 -> 0x00001000
Normal empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000001 -> 0x0000009f
0: 0x00000100 -> 0x00000840
BUG: Int 6: CR2 (null)
EDI
c034663c ESI (null) EBP
c0329f38 ESP
c0329ef4
EBX
c0346380 EDX
00000006 ECX
ffffffff EAX
fffffff4
err (null) EIP
c0353191 CS
c0320060 flg
00010082
Stack: (null)
c030c533 000007cd (null)
c030c533 00000001 (null) (null)
00000003 0000083f 00000018 00000002 00000002 c0329f6c c03534d6 (null)
(null)
00000100 00000840 (null)
c0329f64 00000001 00001000 (null)
Pid: 0, comm: swapper Not tainted 2.6.36 #5
Call Trace:
[<
c02e3707>] ? 0xc02e3707
[<
c035e6e5>] 0xc035e6e5
[<
c0353191>] ? 0xc0353191
[<
c03534d6>] 0xc03534d6
[<
c034f1cd>] 0xc034f1cd
[<
c034a824>] 0xc034a824
[<
c03513cb>] ? 0xc03513cb
[<
c0349432>] 0xc0349432
[<
c0349066>] 0xc0349066
It turns out that we should ignore the low limit of 16M.
Use alloc_bootmem_node_nopanic() in this case.
[akpm@linux-foundation.org: less mess]
Signed-off-by: Yinghai LU <yinghai@kernel.org>
Reported-by: Stefan Hellermann <stefan@the2masters.de>
Tested-by: Stefan Hellermann <stefan@the2masters.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Ben Dooks [Wed, 11 May 2011 22:13:28 +0000 (15:13 -0700)]
drivers/rtc/rtc-s3c.c: fixup wake support for rtc
BugLink: http://bugs.launchpad.net/bugs/788691
commit
52cd4e5c620af9e21b5298bf01844b98573505a7 upstream.
The driver is not balancing set_irq and disable_irq_wake() calls, so
ensure that it keeps track of whether the wake is enabled.
The fixes the following error on S3C6410 devices:
WARNING: at kernel/irq/manage.c:382 set_irq_wake+0x84/0xec()
Unbalanced IRQ 92 wake disable
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Pavel Shilovsky [Thu, 14 Apr 2011 18:00:56 +0000 (22:00 +0400)]
CIFS: Fix memory over bound bug in cifs_parse_mount_options
BugLink: http://bugs.launchpad.net/bugs/788691
commit
4906e50b37e6f6c264e7ee4237343eb2b7f8d16d upstream.
While password processing we can get out of options array bound if
the next character after array is delimiter. The patch adds a check
if we reach the end.
Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Dan Rosenberg [Fri, 6 May 2011 03:27:18 +0000 (03:27 +0000)]
dccp: handle invalid feature options length
BugLink: http://bugs.launchpad.net/bugs/788691
commit
a294865978b701e4d0d90135672749531b9a900d upstream.
A length of zero (after subtracting two for the type and len fields) for
the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to
the subtraction. The subsequent code may read past the end of the
options value buffer when parsing. I'm unsure of what the consequences
of this might be, but it's probably not good.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Chris Wilson [Sat, 16 Apr 2011 09:23:51 +0000 (10:23 +0100)]
drm/i915: Release object along create user fb error path
BugLink: http://bugs.launchpad.net/bugs/788691
commit
2dd251f0a294300a1cf8f4b63768145fa6153c4d upstream.
Reported-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Alex Williamson [Thu, 21 Apr 2011 22:08:14 +0000 (16:08 -0600)]
drm/i915/lvds: Only act on lid notify when the device is on
BugLink: http://bugs.launchpad.net/bugs/788691
commit
2fb4e61d9471867677c97bf11dba8f1e9dfa7f7c upstream.
If we're using vga switcheroo, the device may be turned off
and poking it can return random state. This provokes an OOPS fixed
separately by
8ff887c847 (drm/i915/dp: Be paranoid in case we disable a
DP before it is attached). Trying to use and respond to events on a
device that has been turned off by the user is in principle a silly thing
to do.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Chris Wilson [Sun, 17 Apr 2011 05:38:35 +0000 (06:38 +0100)]
drm/i915/dp: Be paranoid in case we disable a DP before it is attached
BugLink: http://bugs.launchpad.net/bugs/788691
commit
31acbcc408f412d1ba73765b846c38642be553c3 upstream.
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
without us ever enabling/attaching the DP encoder to a pipe. Thus
causing a NULL deference when we attempt to wait for a vblank on that
crtc.
Reported-and-tested-by: Bryan Christ <bryan.christ@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456
Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Mikulas Patocka [Mon, 9 May 2011 11:01:09 +0000 (13:01 +0200)]
Don't lock guardpage if the stack is growing up
BugLink: http://bugs.launchpad.net/bugs/788691
commit
a09a79f66874c905af35d5bb5e5f2fdc7b6b894d upstream.
Linux kernel excludes guard page when performing mlock on a VMA with
down-growing stack. However, some architectures have up-growing stack
and locking the guard page should be excluded in this case too.
This patch fixes lvm2 on PA-RISC (and possibly other architectures with
up-growing stack). lvm2 calculates number of used pages when locking and
when unlocking and reports an internal error if the numbers mismatch.
[ Patch changed fairly extensively to also fix /proc/<pid>/maps for the
grows-up case, and to move things around a bit to clean it all up and
share the infrstructure with the /proc bits.
Tested on ia64 that has both grow-up and grow-down segments - Linus ]
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Tested-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Hugh Dickins [Tue, 10 May 2011 00:44:42 +0000 (17:44 -0700)]
vm: fix vm_pgoff wrap in upward expansion
BugLink: http://bugs.launchpad.net/bugs/788691
commit
42c36f63ac1366ab0ecc2d5717821362c259f517 upstream.
Commit
a626ca6a6564 ("vm: fix vm_pgoff wrap in stack expansion") fixed
the case of an expanding mapping causing vm_pgoff wrapping when you had
downward stack expansion. But there was another case where IA64 and
PA-RISC expand mappings: upward expansion.
This fixes that case too.
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Alex Deucher [Fri, 6 May 2011 18:29:55 +0000 (14:29 -0400)]
drm/radeon/kms: fix gart setup on fusion parts (v2) backport
BugLink: http://bugs.launchpad.net/bugs/788691
Backport of
8aeb96f80232e9a701b5c4715504f4c9173978bd
(drm/radeon/kms: fix gart setup on fusion parts (v2))
to the stable tree.
Out of the entire GART/VM subsystem, the hw designers changed
the location of 3 regs.
v2: airlied: add parameter for userspace to work from.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Stanislaw Gruszka [Mon, 9 May 2011 19:27:30 +0000 (21:27 +0200)]
iwlwifi: add {ack, plpc}_check module parameters
BugLink: http://bugs.launchpad.net/bugs/788691
commit
b7977ffaab5187ad75edaf04ac854615cea93828 upstream.
Add module ack_check, and plcp_check parameters. Ack_check is disabled
by default since is proved that check ack health can cause troubles.
Plcp_check is enabled by default.
This prevent connection hangs with "low ack count detected" messages.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=666646
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Frederic Weisbecker [Thu, 5 May 2011 23:53:18 +0000 (01:53 +0200)]
hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()
BugLink: http://bugs.launchpad.net/bugs/788691
commit
925f83c085e1bb08435556c5b4844a60de002e31 upstream.
We make use of ptrace_get_breakpoints() / ptrace_put_breakpoints() to
protect ptrace_set_debugreg() even if CONFIG_HAVE_HW_BREAKPOINT if off.
However in this case, these APIs are not implemented.
To fix this, push the protection down inside the relevant ifdef.
Best would be to export the code inside
CONFIG_HAVE_HW_BREAKPOINT into a standalone function to cleanup
the ifdefury there and call the breakpoint ref API inside. But
as it is more invasive, this should be rather made in an -rc1.
Fixes this build error:
arch/powerpc/kernel/ptrace.c:1594: error: implicit declaration of function 'ptrace_get_breakpoints' make[2]: ***
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LPPC <linuxppc-dev@lists.ozlabs.org>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/
1304639598-4707-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Frederic Weisbecker [Thu, 7 Apr 2011 14:53:20 +0000 (16:53 +0200)]
ptrace: Prepare to fix racy accesses on task breakpoints
BugLink: http://bugs.launchpad.net/bugs/788691
commit
bf26c018490c2fce7fe9b629083b96ce0e6ad019 upstream.
When a task is traced and is in a stopped state, the tracer
may execute a ptrace request to examine the tracee state and
get its task struct. Right after, the tracee can be killed
and thus its breakpoints released.
This can happen concurrently when the tracer is in the middle
of reading or modifying these breakpoints, leading to dereferencing
a freed pointer.
Hence, to prepare the fix, create a generic breakpoint reference
holding API. When a reference on the breakpoints of a task is
held, the breakpoints won't be released until the last reference
is dropped. After that, no more ptrace request on the task's
breakpoints can be serviced for the tracer.
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Link: http://lkml.kernel.org/r/
1302284067-7860-2-git-send-email-fweisbec@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Frederic Weisbecker [Fri, 8 Apr 2011 15:29:36 +0000 (17:29 +0200)]
x86, hw_breakpoints: Fix racy access to ptrace breakpoints
BugLink: http://bugs.launchpad.net/bugs/788691
commit
87dc669ba25777b67796d7262c569429e58b1ed4 upstream.
While the tracer accesses ptrace breakpoints, the child task may
concurrently exit due to a SIGKILL and thus release its breakpoints
at the same time. We can then dereference some freed pointers.
To fix this, hold a reference on the child breakpoints before
manipulating them.
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Link: http://lkml.kernel.org/r/
1302284067-7860-3-git-send-email-fweisbec@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Alex Deucher [Wed, 4 May 2011 15:41:47 +0000 (11:41 -0400)]
drm/radeon/kms: add pci id to acer travelmate quirk for 5730
BugLink: http://bugs.launchpad.net/bugs/788691
commit
4f87af46107499415afd238be104587b5a9d7ac3 upstream.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=34082
Reported by: Sampo Laaksonen <zhamahn@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Timo Warns [Fri, 6 May 2011 11:47:35 +0000 (13:47 +0200)]
Validate size of EFI GUID partition entries.
BugLink: http://bugs.launchpad.net/bugs/788691
commit
fa039d5f6b126fbd65eefa05db2f67e44df8f121 upstream.
Otherwise corrupted EFI partition tables can cause total confusion.
Signed-off-by: Timo Warns <warns@pre-sense.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Fri, 29 Apr 2011 10:52:44 +0000 (06:52 -0400)]
cifs: handle errors from coalesce_t2
BugLink: http://bugs.launchpad.net/bugs/788691
commit
16541ba11c4f04ffe94b073e301f00b749fb84a1 upstream.
cifs_demultiplex_thread calls coalesce_t2 to try and merge follow-on t2
responses into the original mid buffer. coalesce_t2 however can return
errors, but the caller doesn't handle that situation properly. Fix the
thread to treat such a case as it would a malformed packet. Mark the
mid as being malformed and issue the callback.
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Fri, 29 Apr 2011 10:52:43 +0000 (06:52 -0400)]
cifs: refactor mid finding loop in cifs_demultiplex_thread
BugLink: http://bugs.launchpad.net/bugs/788691
commit
146f9f65bd13f56665205aed7205d531c810cb35 upstream.
...to reduce the extreme indentation. This should introduce no
behavioral changes.
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Wed, 27 Apr 2011 17:29:49 +0000 (13:29 -0400)]
cifs: sanitize length checking in coalesce_t2 (try #3)
BugLink: http://bugs.launchpad.net/bugs/788691
commit
2a2047bc94d0efc316401170c3d078d9edc20dc4 upstream.
There are a couple of places in this code where these values can wrap or
go negative, and that could potentially end up overflowing the buffer.
Ensure that that doesn't happen. Do all of the length calculation and
checks first, and only perform the memcpy after they pass.
Also, increase some stack variables to 32 bits to ensure that they don't
wrap without being detected.
Finally, change the error codes to be a bit more descriptive of any
problems detected. -EINVAL isn't very accurate.
Reported-and-Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Wed, 27 Apr 2011 17:25:51 +0000 (13:25 -0400)]
cifs: check for bytes_remaining going to zero in CIFS_SessSetup
BugLink: http://bugs.launchpad.net/bugs/788691
commit
fcda7f4578bbf9717444ca6da8a421d21489d078 upstream.
It's possible that when we go to decode the string area in the
SESSION_SETUP response, that bytes_remaining will be 0. Decrementing it at
that point will mean that it can go "negative" and wrap. Check for a
bytes_remaining value of 0, and don't try to decode the string area if
that's the case.
Reported-and-Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Jeff Layton [Wed, 27 Apr 2011 17:25:51 +0000 (13:25 -0400)]
cifs: change bleft in decode_unicode_ssetup back to signed type
BugLink: http://bugs.launchpad.net/bugs/788691
commit
bfacf2225a955bea9c41c707fc72ba16009674a0 upstream.
The buffer length checks in this function depend on this value being a
signed data type, but
690c522fa converted it to an unsigned type.
Also, eliminate a problem with the null termination check in the same
function. cifs_strndup_from_ucs handles that situation correctly
already, and the existing check could potentially lead to a buffer
overrun since it increments bleft without checking to see whether it
falls off the end of the buffer.
Reported-and-Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Robert Nelson [Tue, 26 Apr 2011 05:12:11 +0000 (02:12 -0300)]
UBUNTU: SAUCE: omap3: beagle: if rev unknown, assume xM revision C
BugLink: http://bugs.launchpad.net/bugs/770679
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Robert Nelson [Tue, 26 Apr 2011 05:09:44 +0000 (02:09 -0300)]
UBUNTU: SAUCE: omap3: beagle: detect new xM revision C
Beagle xM rev C has nEN_USB_PWR inverted again, so we need
proper check for revision C.
BugLink: http://bugs.launchpad.net/bugs/770679
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Robert Nelson [Tue, 26 Apr 2011 04:59:58 +0000 (01:59 -0300)]
UBUNTU: SAUCE: omap3: beagle: detect new xM revision B
The xM B uses a DM3730 ES1.1 over the ES1.0 on xM A's, no other board changes.
BugLink: http://bugs.launchpad.net/bugs/770679
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Leann Ogasawara [Mon, 23 May 2011 16:46:59 +0000 (09:46 -0700)]
ips: use interruptible waits in ips-monitor
Hi,
Please consider the following patch for Natty SRU. It has been
confirmed to resolve LP bug 765082. I've also submitted it to upstream
stable for 2.6.38.y but it is still waiting to get accepted.
Thanks,
Leann
SRU Justification:
Impact: ips-monitor is in 'D' state continuously and produces a constant
load of 1
Fix: upstream commit
a3424216e4935221fdaa5ca3c26e024f11297164
Test case: Boot a kernel with the patch applied and confirm ips-monitor
is no loner is a 'D' state and load drops below 1.
The following changes since commit
4a93549299ec1b4b5c137449a13b5efd535487d9:
Greg Kroah-Hartman (1):
Linux 2.6.38.6
are available in the git repository at:
git://kernel.ubuntu.com/ogasawara/ubuntu-natty.git lp765082
Jesse Barnes (1):
ips: use interruptible waits in ips-monitor
drivers/platform/x86/intel_ips.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
>From
727d78d90d2a337ef124a41524493cdd5a540094 Mon Sep 17 00:00:00 2001
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Mon, 28 Mar 2011 06:36:30 -0400
Subject: [PATCH] ips: use interruptible waits in ips-monitor
BugLink: https://bugs.launchpad.net/ubuntu/+bug/765082
This is what I intended to do since:
1) the driver handles variable waits just fine, and
2) interruptible waits aren't reported as load in the load avg.
Reported-and-tested-by: Andreas Hartmann <andihartmann@freenet.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
(cherry picked from commit
a3424216e4935221fdaa5ca3c26e024f11297164)
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Thomas Schlichter [Thu, 19 May 2011 13:54:14 +0000 (14:54 +0100)]
UBUNTU: SAUCE: vesafb: mtrr module parameter is uint, not bool
BugLink: http://bugs.launchpad.net/bugs/778043
As noted by the reporter the mtrr kernel command line option is actually a
positive numeric not a boolean, move the module parameter we add to match.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
Greg Kroah-Hartman [Mon, 9 May 2011 22:16:23 +0000 (15:16 -0700)]
Linux 2.6.38.6
BugLink: http://bugs.launchpad.net/bugs/780546
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Linus Torvalds [Thu, 5 May 2011 04:30:28 +0000 (21:30 -0700)]
VM: skip the stack guard page lookup in get_user_pages only for mlock
BugLink: http://bugs.launchpad.net/bugs/780546
commit
a1fde08c74e90accd62d4cfdbf580d2ede938fe7 upstream.
The logic in __get_user_pages() used to skip the stack guard page lookup
whenever the caller wasn't interested in seeing what the actual page
was. But Michel Lespinasse points out that there are cases where we
don't care about the physical page itself (so 'pages' may be NULL), but
do want to make sure a page is mapped into the virtual address space.
So using the existence of the "pages" array as an indication of whether
to look up the guard page or not isn't actually so great, and we really
should just use the FOLL_MLOCK bit. But because that bit was only set
for the VM_LOCKED case (and not all vma's necessarily have it, even for
mlock()), we couldn't do that originally.
Fix that by moving the VM_LOCKED check deeper into the call-chain, which
actually simplifies many things. Now mlock() gets simpler, and we can
also check for FOLL_MLOCK in __get_user_pages() and the code ends up
much more straightforward.
Reported-and-reviewed-by: Michel Lespinasse <walken@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
James Bottomley [Sun, 1 May 2011 14:42:07 +0000 (09:42 -0500)]
fix oops in scsi_run_queue()
BugLink: http://bugs.launchpad.net/bugs/780546
commit
c055f5b2614b4f758ae6cc86733f31fa4c2c5844 upstream.
The recent commit closing the race window in device teardown:
commit
86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b
Author: James Bottomley <James.Bottomley@suse.de>
Date: Fri Apr 22 10:39:59 2011 -0500
[SCSI] put stricter guards on queue dead checks
is causing a potential NULL deref in scsi_run_queue() because the
q->queuedata may already be NULL by the time this function is called.
Since we shouldn't be running a queue that is being torn down, simply
add a NULL check in scsi_run_queue() to forestall this.
Tested-by: Jim Schutt <jaschut@sandia.gov>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Oliver Hartkopp [Wed, 20 Apr 2011 01:57:15 +0000 (01:57 +0000)]
can: add missing socket check in can/raw release
BugLink: http://bugs.launchpad.net/bugs/780546
commit
10022a6c66e199d8f61d9044543f38785713cbbd upstream.
v2: added space after 'if' according code style.
We can get here with a NULL socket argument passed from userspace,
so we need to handle it accordingly.
Thanks to Dave Jones pointing at this issue in net/can/bcm.c
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alex Deucher [Tue, 3 May 2011 19:15:55 +0000 (15:15 -0400)]
drm/radeon/kms: add some new pci ids
BugLink: http://bugs.launchpad.net/bugs/780546
commit
e2c85d8e3974c9041ad7b080846b28d2243e771b upstream.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Avi Kivity [Thu, 3 Feb 2011 13:29:52 +0000 (15:29 +0200)]
KVM: SVM: check for progress after IRET interception
BugLink: http://bugs.launchpad.net/bugs/780546
commit
bd3d1ec3d26b61120bb4f60b18ee99aa81839e6b upstream.
When we enable an NMI window, we ask for an IRET intercept, since
the IRET re-enables NMIs. However, the IRET intercept happens before
the instruction executes, while the NMI window architecturally opens
afterwards.
To compensate for this mismatch, we only open the NMI window in the
following exit, assuming that the IRET has by then executed; however,
this assumption is not always correct; we may exit due to a host interrupt
or page fault, without having executed the instruction.
Fix by checking for forward progress by recording and comparing the IRET's
rip. This is somewhat of a hack, since an unchaging rip does not mean that
no forward progress has been made, but is the simplest fix for now.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Lawrence Rust [Thu, 5 May 2011 02:25:10 +0000 (23:25 -0300)]
cx88: Fix HVR4000 IR keymap
BugLink: http://bugs.launchpad.net/bugs/780546
[fixed in .39 in a much different way that is too big to backport to
.38 - gregkh]
Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in
the 2.6.38 kernel.
Signed-off-by: Lawrence Rust <lvr@softsystem.dot.uk>
Acked-by: Jarod Wilson <jarod@wilsonet.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Jones [Wed, 20 Apr 2011 03:36:59 +0000 (20:36 -0700)]
can: Add missing socket check in can/bcm release.
BugLink: http://bugs.launchpad.net/bugs/780546
commit
c6914a6f261aca0c9f715f883a353ae7ff51fe83 upstream.
We can get here with a NULL socket argument passed from userspace,
so we need to handle it accordingly.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Sachin Prabhu [Wed, 20 Apr 2011 12:09:35 +0000 (13:09 +0100)]
Open with O_CREAT flag set fails to open existing files on non writable directories
BugLink: http://bugs.launchpad.net/bugs/780546
commit
1574dff8996ab1ed92c09012f8038b5566fce313 upstream.
An open on a NFS4 share using the O_CREAT flag on an existing file for
which we have permissions to open but contained in a directory with no
write permissions will fail with EACCES.
A tcpdump shows that the client had set the open mode to UNCHECKED which
indicates that the file should be created if it doesn't exist and
encountering an existing flag is not an error. Since in this case the
file exists and can be opened by the user, the NFS server is wrong in
attempting to check create permissions on the parent directory.
The patch adds a conditional statement to check for create permissions
only if the file doesn't exist.
Signed-off-by: Sachin S. Prabhu <sprabhu@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Lasse Collin [Sun, 1 May 2011 16:38:42 +0000 (19:38 +0300)]
XZ decompressor: Fix decoding of empty LZMA2 streams
BugLink: http://bugs.launchpad.net/bugs/780546
commit
646032e3b05b32d3f20cb108a030593d9d792eb5 upstream.
The old code considered valid empty LZMA2 streams to be corrupt.
Note that a typical empty .xz file has no LZMA2 data at all,
and thus most .xz files having no uncompressed data are handled
correctly even without this fix.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dan Rosenberg [Fri, 29 Apr 2011 14:48:07 +0000 (15:48 +0100)]
ARM: 6891/1: prevent heap corruption in OABI semtimedop
BugLink: http://bugs.launchpad.net/bugs/780546
commit
0f22072ab50cac7983f9660d33974b45184da4f9 upstream.
When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not
bound the nsops argument. A sufficiently large value will cause an
integer overflow in allocation size, followed by copying too much data
into the allocated buffer. Fix this by restricting nsops to SEMOPM.
Untested.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Eric W. Biederman [Sun, 24 Apr 2011 01:54:57 +0000 (01:54 +0000)]
af_unix: Only allow recv on connected seqpacket sockets.
BugLink: http://bugs.launchpad.net/bugs/780546
commit
a05d2ad1c1f391c7f514a1d1e09b5417968a7d07 upstream.
This fixes the following oops discovered by Dan Aloni:
> Anyway, the following is the output of the Oops that I got on the
> Ubuntu kernel on which I first detected the problem
> (2.6.37-12-generic). The Oops that followed will be more useful, I
> guess.
>[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference
> at (null)
> [ 5594.681606] IP: [<
ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420
> [ 5594.687576] PGD
2a05d067 PUD
2b951067 PMD 0
> [ 5594.693720] Oops: 0002 [#1] SMP
> [ 5594.699888] last sysfs file:
The bug was that unix domain sockets use a pseduo packet for
connecting and accept uses that psudo packet to get the socket.
In the buggy seqpacket case we were allowing unconnected
sockets to call recvmsg and try to receive the pseudo packet.
That is always wrong and as of commit
7361c36c5 the pseudo
packet had become enough different from a normal packet
that the kernel started oopsing.
Do for seqpacket_recv what was done for seqpacket_send in 2.5
and only allow it on connected seqpacket sockets.
Tested-by: Dan Aloni <dan@aloni.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Johannes Berg [Tue, 19 Apr 2011 18:44:04 +0000 (20:44 +0200)]
mac80211: fix SMPS debugfs locking
BugLink: http://bugs.launchpad.net/bugs/780546
commit
243e6df4ed919880d079d717641ad699c6530a03 upstream.
The locking with SMPS requests means that the
debugs file should lock the mgd mutex, not the
iflist mutex. Calls to __ieee80211_request_smps()
need to hold that mutex, so add an assertion.
This has always been wrong, but for some reason
never been noticed, probably because the locking
error only happens while unassociated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Felix Fietkau [Thu, 14 Apr 2011 22:41:43 +0000 (00:41 +0200)]
ath9k: fix the return value of ath_stoprecv
BugLink: http://bugs.launchpad.net/bugs/780546
commit
2232d31bf18ba02f5cd632bbfc3466aeca394c75 upstream.
The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect
a condition where rx DMA was stopped, but the MAC failed to enter the idle
state. This condition requires a hardware reset, however the return value
of ath_stoprecv was 'true' in that case, which allowed it to skip the reset
when issuing a fast channel change.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Paul Stewart <pstew@google.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Boris Ostrovsky [Fri, 29 Apr 2011 21:47:43 +0000 (17:47 -0400)]
x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
BugLink: http://bugs.launchpad.net/bugs/780546
commit
e20a2d205c05cef6b5783df339a7d54adeb50962 upstream.
Older AMD K8 processors (Revisions A-E) are affected by erratum
400 (APIC timer interrupts don't occur in C states greater than
C1). This, for example, means that X86_FEATURE_ARAT flag should
not be set for these parts.
This addresses regression introduced by commit
b87cf80af3ba4b4c008b4face3c68d604e1715c6 ("x86, AMD: Set ARAT
feature on AMD processors") where the system may become
unresponsive until external interrupt (such as keyboard input)
occurs. This results, for example, in time not being reported
correctly, lack of progress on the system and other lockups.
Reported-by: Joerg-Volker Peetz <jvpeetz@web.de>
Tested-by: Joerg-Volker Peetz <jvpeetz@web.de>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Link: http://lkml.kernel.org/r/
1304113663-6586-1-git-send-email-ostr@amd64.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Eric Paris [Thu, 28 Apr 2011 19:55:52 +0000 (15:55 -0400)]
flex_arrays: allow zero length flex arrays
BugLink: http://bugs.launchpad.net/bugs/780546
commit
bf69d41d198138e3c601e9a6645f4f1369aff7e0 upstream.
Just like kmalloc will allow one to allocate a 0 length segment of memory
flex arrays should do the same thing. It should bomb if you try to use
something, but it should at least allow the allocation.
This is needed because when SELinux switched to using flex_arrays in 2.6.38
the inability to allocate a 0 length array resulted in SELinux policy load
returning -ENOSPC when previously it worked.
Based-on-patch-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Tested-by: Chris Richards <gizmo@giz-works.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Eric Paris [Thu, 28 Apr 2011 19:55:52 +0000 (15:55 -0400)]
flex_array: flex_array_prealloc takes a number of elements, not an end
BugLink: http://bugs.launchpad.net/bugs/780546
commit
5d30b10bd68df007e7ae21e77d1e0ce184b53040 upstream.
Change flex_array_prealloc to take the number of elements for which space
should be allocated instead of the last (inclusive) element. Users
and documentation are updated accordingly. flex_arrays got introduced before
they had users. When folks started using it, they ended up needing a
different API than was coded up originally. This swaps over to the API that
folks apparently need.
Based-on-patch-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Tested-by: Chris Richards <gizmo@giz-works.com>
Acked-by: Dave Hansen <dave@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jarod Wilson [Wed, 27 Apr 2011 22:01:44 +0000 (19:01 -0300)]
imon: add conditional locking in change_protocol
BugLink: http://bugs.launchpad.net/bugs/780546
commit
23ef710e1a6c4d6b9ef1c2fa19410f7f1479401e upstream.
The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.
In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.
Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.
With a lock-debugging-enabled kernel, I was getting this:
[ 15.014153] =====================================
[ 15.015048] [ BUG: bad unlock balance detected! ]
[ 15.015048] -------------------------------------
[ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[ 15.015048] [<
ffffffff814c6297>] mutex_unlock+0xe/0x10
[ 15.015048] but there are no more locks to release!
[ 15.015048]
[ 15.015048] other info that might help us debug this:
[ 15.015048] 2 locks held by ir-keytable/773:
[ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [<
ffffffff8119d400>] sysfs_write_file+0x3c/0x144
[ 15.015048] #1: (s_active#87){.+.+.+}, at: [<
ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144
[ 15.015048]
[ 15.015048] stack backtrace:
[ 15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[ 15.015048] Call Trace:
[ 15.015048] [<
ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5
[ 15.015048] [<
ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263
[ 15.015048] [<
ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<
ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<
ffffffff8108b67b>] ? lock_release+0x17d/0x1a4
[ 15.015048] [<
ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125
[ 15.015048] [<
ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<
ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon]
[ 15.015048] [<
ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263
[ 15.015048] [<
ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon]
[ 15.015048] [<
ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core]
[ 15.015048] [<
ffffffff81326e4e>] ? dev_attr_store+0x20/0x22
[ 15.015048] [<
ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144
...
The original report that led to the investigation was the following:
[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd D
ffff88010fcd89c8 0 8460 1 0x00000000
[ 1679.457312]
ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314]
00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316]
ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324] [<
ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
[ 1679.457327] [<
ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330] [<
ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335] [<
ffffffff813b0c41>] mutex_lock+0x11/0x30
[ 1679.457338] [<
ffffffffa0d54216>] display_open+0x66/0x130 [imon]
[ 1679.457345] [<
ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
[ 1679.457349] [<
ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
[ 1679.457350] [<
ffffffff8113d93d>] __dentry_open+0x10d/0x370
[ 1679.457352] [<
ffffffff81143980>] ? chrdev_open+0x0/0x2d0
...
Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.
Reported-by: Benjamin Hodgetts <ben@xnode.org>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dan Williams [Wed, 27 Apr 2011 09:54:28 +0000 (09:54 +0000)]
usbnet: add support for some Huawei modems with cdc-ether ports
BugLink: http://bugs.launchpad.net/bugs/780546
commit
b3c914aa84f4e4bbb3efc8f41c359d96e5e932d2 upstream.
Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether
compatible ports, so recognize and expose them.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
B.J. Buchalter [Mon, 2 May 2011 17:33:42 +0000 (13:33 -0400)]
firewire: Fix for broken configrom updates in quick succession
BugLink: http://bugs.launchpad.net/bugs/780546
commit
2e053a27d9d5ad5e0831e002cbf8043836fb2060 upstream.
Current implementation of ohci_set_config_rom() uses a deferred
bus reset via fw_schedule_bus_reset(). If clients add multiple
unit descriptors to the config_rom in quick succession, the
deferred bus reset may not have fired before succeeding update
requests have come in. This can lead to an incorrect partial
update of the config_rom for both addition and removal of
config_rom descriptors, as the ohci_set_config_rom() routine
will return -EBUSY if a previous pending update has not been
completed yet; the requested update just gets dropped on the floor.
This patch recognizes that the "in-flight" update can be modified
until it has been processed by the bus-reset, and the locking
in the bus_reset_tasklet ensures that the update is done atomically
with respect to modifications made by ohci_set_config_rom(). The
-EBUSY error case is simply removed.
[Stefan R: The bug always existed at least theoretically. But it
became easy to trigger since 2.6.36 commit
02d37bed188c "firewire: core:
integrate software-forced bus resets with bus management" which
introduced long mandatory delays between janitorial bus resets.]
Signed-off-by: Benjamin Buchalter <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alan Stern [Mon, 2 May 2011 18:21:44 +0000 (14:21 -0400)]
USB: fix regression in usbip by setting has_tt flag
BugLink: http://bugs.launchpad.net/bugs/780546
commit
cee6a262550f53a13acfefbc1e3e5ff35c96182c upstream.
This patch (as1460) fixes a regression in the usbip driver caused by
the new check for Transaction Translators in USB-2 hubs. The root hub
registered by vhci_hcd needs to have the has_tt flag set, because it
can connect to low- and full-speed devices as well as high-speed
devices.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Airlie [Sun, 1 May 2011 10:16:30 +0000 (20:16 +1000)]
drm/radeon: fix regression on atom cards with hardcoded EDID record.
BugLink: http://bugs.launchpad.net/bugs/780546
commit
eaa4f5e1d0b816291a59a47917e569c0384f2b6f upstream.
Since
fafcf94e2b5732d1e13b440291c53115d2b172e9 introduced an edid size, it seems to have broken this path.
This manifest as oops on T500 Lenovo laptops with dual graphics primarily.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Chris Ball [Wed, 27 Apr 2011 21:35:31 +0000 (17:35 -0400)]
mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish
BugLink: http://bugs.launchpad.net/bugs/780546
commit
0c9c99a765321104cc5f9c97f949382a9ba4927e upstream.
It seems that under certain circumstances the sdhci_tasklet_finish()
call can be entered with mrq set to NULL, causing the system to crash
with a NULL pointer de-reference.
Seen on S3C6410 system. Based on a patch by Dimitris Papastamos.
Reported-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Ben Dooks [Wed, 27 Apr 2011 13:24:19 +0000 (14:24 +0100)]
mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish
BugLink: http://bugs.launchpad.net/bugs/780546
commit
b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream.
It seems that under certain circumstances that the sdhci_tasklet_finish()
call can be entered with mrq->cmd set to NULL, causing the system to crash
with a NULL pointer de-reference.
Unable to handle kernel NULL pointer dereference at virtual address
00000000
PC is at sdhci_tasklet_finish+0x34/0xe8
LR is at sdhci_tasklet_finish+0x24/0xe8
Seen on S3C6410 system.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Chris Ball [Tue, 29 Mar 2011 04:46:12 +0000 (00:46 -0400)]
mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()
BugLink: http://bugs.launchpad.net/bugs/780546
commit
9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream.
If pci_ioremap_bar() fails during probe, we "goto release;" and free the
host, but then we return 0 -- which tells sdhci_pci_probe() that the probe
succeeded. Since we think the probe succeeded, when we unload sdhci we'll
go to sdhci_pci_remove_slot() and it will try to dereference slot->host,
which is now NULL because we freed it in the error path earlier.
The patch simply sets ret appropriately, so that sdhci_pci_probe() will
detect the failure immediately and bail out.
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Guennadi Liakhovetski [Fri, 15 Apr 2011 18:08:19 +0000 (20:08 +0200)]
mmc: fix a race between card-detect rescan and clock-gate work instances
BugLink: http://bugs.launchpad.net/bugs/780546
commit
26fc8775b51484d8c0a671198639c6d5ae60533e upstream.
Currently there is a race in the MMC core between a card-detect
rescan work and the clock-gating work, scheduled from a command
completion. Fix it by removing the dedicated clock-gating mutex
and using the MMC standard locking mechanism instead.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <damm@opensource.se>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Artem Bityutskiy [Mon, 25 Apr 2011 15:46:31 +0000 (18:46 +0300)]
UBIFS: seek journal heads to the latest bud in replay
BugLink: http://bugs.launchpad.net/bugs/780546
commit
52c6e6f990669deac3f370f1603815adb55a1dbd upstream.
This is the second fix of the following symptom:
UBIFS error (pid 34456): could not find an empty LEB
which sometimes happens after power cuts when we mount the file-system - UBIFS
refuses it with the above error message which comes from the
'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test
with the UBIFS power cut emulation enabled.
Analysis of the problem.
Currently UBIFS replay seeks the journal heads to the last _replayed_ bud.
But the buds are replayed out-of-order, so the replay basically seeks journal
heads to the "random" bud belonging to this head, and not to the _last_ one.
The result of this is that the GC head may be seeked to a full LEB with no free
space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a
fully or mostly dirty LEB to match the current GC head (because we need to
garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum).
So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and
also fail. As a result - recovery fails and mounting fails.
This patch teaches the replay to initialize the GC heads exactly to the latest
buds, i.e. the buds which have the largest sequence number in corresponding
log reference nodes.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Artem Bityutskiy [Mon, 25 Apr 2011 15:17:09 +0000 (18:17 +0300)]
UBIFS: do not free write-buffers when in R/O mode
BugLink: http://bugs.launchpad.net/bugs/780546
commit
b50b9f408502a2ea90459ae36ba8cdc9cc005cfe upstream.
Currently UBIFS has a small optimization - it frees write-buffers when it is
re-mounted from R/W mode to R/O mode. Of course, when it is mounted R/O, it
does not allocate write-buffers as well.
This optimization is nice but it leads to subtle problems and complications
in recovery, which I can reproduce using the integck test. The symptoms are
that after a power cut the file-system cannot be mounted if we first mount
it R/O, and then re-mount R/W - 'ubifs_rcvry_gc_commit()' prints:
UBIFS error (pid 34456): could not find an empty LEB
Analysis of the problem.
When mounting R/W, the reply process sets journal heads to buds [1], but
when mounting R/O - it does not do this, because the write-buffers are not
allocated. So 'ubifs_rcvry_gc_commit()' works completely differently for the
same file-system but for the following 2 cases:
1. mounting R/W after a power cut and recover
2. mounting R/O after a power cut, re-mounting R/W and run deferred recovery
In the former case, we have journal heads seeked to the a bud, in the latter
case, they are non-seeked (wbuf->lnum == -1). So in the latter case we do not
try to recover the GC LEB by garbage-collecting to the GC head, but we just
try to find an empty LEB, and there may be no empty LEBs, so we just fail.
On the other hand, in the former case (mount R/W), we are able to make a GC LEB
(@c->gc_lnum) by garbage-collecting.
Thus, let's remove this small nice optimization and always allocate
write-buffers. This should not make too big difference - we have only 3
of them, each of max. write unit size, which is usually 2KiB. So this is
about 6KiB of RAM for the typical case, and only when mounted R/O.
[1]: Note, currently the replay process is setting (seeking) the journal heads
to _some_ buds, not necessarily to the buds which had been the journal heads
before the power cut happened. This will be fixed separately.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Wed, 20 Apr 2011 09:00:49 +0000 (09:00 +0000)]
atl1c: Fix work event interrupt/task races
BugLink: http://bugs.launchpad.net/bugs/780546
commit
cb771838715b1c470bc5735bdae709b33b18e0ad upstream.
The mechanism used to initiate work events from the interrupt
handler has a classic read/modify/write race between the interrupt
handler that sets the condition, and the worker task that reads and
clears the condition. Close these races by using atomic
bit fields.
Cc: Jie Yang <jie.yang@atheros.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stanislaw Gruszka [Fri, 29 Apr 2011 15:51:06 +0000 (17:51 +0200)]
iwlagn: fix "Received BA when not expected"
BugLink: http://bugs.launchpad.net/bugs/780546
commit
bfd36103ec26599557c2bd3225a1f1c9267f8fcb upstream.
Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:
"Received BA when not expected"
or (on older kernels):
"BA scd_flow 0 does not match txq_id 10"
This fix regression introduced in 2.6.35 during station management
code rewrite by:
commit
2a87c26bbe9587baeb9e56d3ce0b4971bd777643
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri Apr 30 11:30:45 2010 -0700
iwlwifi: use iwl_find_station less
Patch partially resolve:
https://bugzilla.kernel.org/show_bug.cgi?id=16691
However, there are still 11n performance problems on 4965 and 5xxx
devices that need to be investigated.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stanislaw Gruszka [Wed, 20 Apr 2011 13:57:14 +0000 (15:57 +0200)]
iwlwifi: fix skb usage after free
BugLink: http://bugs.launchpad.net/bugs/780546
commit
b25026981aecde3685dd0e45ad980fff9f528daa upstream.
Since
commit
a120e912eb51e347f36c71b60a1d13af74d30e83
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Feb 19 15:47:33 2010 -0800
iwlwifi: sanity check before counting number of tfds can be free
we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.
On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tejun Heo [Fri, 29 Apr 2011 16:08:37 +0000 (18:08 +0200)]
workqueue: fix deadlock in worker_maybe_bind_and_lock()
BugLink: http://bugs.launchpad.net/bugs/780546
commit
5035b20fa5cd146b66f5f89619c20a4177fb736d upstream.
If a rescuer and stop_machine() bringing down a CPU race with each
other, they may deadlock on non-preemptive kernel. The CPU won't
accept a new task, so the rescuer can't migrate to the target CPU,
while stop_machine() can't proceed because the rescuer is holding one
of the CPU retrying migration. GCWQ_DISASSOCIATED is never cleared
and worker_maybe_bind_and_lock() retries indefinitely.
This problem can be reproduced semi reliably while the system is
entering suspend.
http://thread.gmane.org/gmane.linux.kernel/1122051
A lot of kudos to Thilo-Alexander for reporting this tricky issue and
painstaking testing.
stable: This affects all kernels with cmwq, so all kernels since and
including v2.6.36 need this fix.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Thilo-Alexander Ginkel <thilo@ginkel.com>
Tested-by: Thilo-Alexander Ginkel <thilo@ginkel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Delvare [Sun, 1 May 2011 16:18:49 +0000 (18:18 +0200)]
i2c-parport: Fix adapter list handling
BugLink: http://bugs.launchpad.net/bugs/780546
commit
56acc7a39ac4ac7638cdc32cd3d0832ebbc834e4 upstream.
Use a standard list with proper locking to handle the list of
adapters. Thankfully it only matters on systems with more than one
parallel port, which are very rare.
Thanks to Lukasz Kapiec for reporting the problem to me.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Takashi Iwai [Mon, 2 May 2011 11:55:36 +0000 (13:55 +0200)]
ALSA: hda - Fix Realtek's chained fixup checks
BugLink: http://bugs.launchpad.net/bugs/780546
commit
24af2b1cc418d6791b1d9e56bf6070cccb752db3 upstream.
The check of chained fixup list entry was done against the wrong element.
A stupid mistake during refactoring.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Takashi Iwai [Mon, 2 May 2011 08:37:29 +0000 (10:37 +0200)]
Revert "ALSA: hda - Fix pin-config of Gigabyte mobo"
BugLink: http://bugs.launchpad.net/bugs/780546
commit
ebb47241ea0eac6a5a23404821a2d62f64c68496 upstream.
This reverts commit
c6b358748e19ce7e230b0926ac42696bc485a562.
It turned out that there are different pin configurations for this
PCI SSID, including multi-channel modes. And more proper fix for
allowing line-out mutes will come up in 2.6.40 tree, so we won't need
this fixup any more there.
Reported-by: Andrew Clayton <andrew@digital-domain.net>
Reported-by: Emmanuel Benisty <benisty.e@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
David Henningsson [Fri, 29 Apr 2011 12:10:55 +0000 (14:10 +0200)]
ALSA: HDA: Fix automute for Gateway NV79
BugLink: http://bugs.launchpad.net/bugs/780546
commit
94024cd1aefa0f8bcc9dfe46c05bd7ce3f471a1c upstream.
The PCI SSID is 1025:031c and the codec SSID is 1025:031d,
so the driver mistakes this for a SKU value, but looking at
the numbers, this is obviously wrong.
BugLink: http://bugs.launchpad.net/bugs/761861
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
James Bottomley [Fri, 22 Apr 2011 15:39:59 +0000 (10:39 -0500)]
put stricter guards on queue dead checks
BugLink: http://bugs.launchpad.net/bugs/780546
commit
86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream.
SCSI uses request_queue->queuedata == NULL as a signal that the queue
is dying. We set this state in the sdev release function. However,
this allows a small window where we release the last reference but
haven't quite got to this stage yet and so something will try to take
a reference in scsi_request_fn and oops. It's very rare, but we had a
report here, so we're pushing this as a bug fix
The actual fix is to set request_queue->queuedata to NULL in
scsi_remove_device() before we drop the reference. This causes
correct automatic rejects from scsi_request_fn as people who hold
additional references try to submit work and prevents anything from
getting a new reference to the sdev that way.
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mike Snitzer [Fri, 8 Apr 2011 19:05:36 +0000 (15:05 -0400)]
scsi_dh: fix reference counting in scsi_dh_activate error path
BugLink: http://bugs.launchpad.net/bugs/780546
commit
0b8393578c70bc1f09790eeae7d918f38da2e010 upstream.
Commit
db422318cbca55168cf965f655471dbf8be82433 ([SCSI] scsi_dh:
propagate SCSI device deletion) introduced a regression where the device
reference is not dropped prior to scsi_dh_activate's early return from
the error path.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dan Rosenberg [Tue, 5 Apr 2011 16:45:59 +0000 (12:45 -0400)]
mpt2sas: prevent heap overflows and unchecked reads
BugLink: http://bugs.launchpad.net/bugs/780546
commit
a1f74ae82d133ebb2aabb19d181944b4e83e9960 upstream.
At two points in handling device ioctls via /dev/mpt2ctl, user-supplied
length values are used to copy data from userspace into heap buffers
without bounds checking, allowing controllable heap corruption and
subsequently privilege escalation.
Additionally, user-supplied values are used to determine the size of a
copy_to_user() as well as the offset into the buffer to be read, with no
bounds checking, allowing users to read arbitrary kernel memory.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Acked-by: Eric Moore <eric.moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dan Rosenberg [Tue, 5 Apr 2011 17:27:31 +0000 (13:27 -0400)]
pmcraid: reject negative request size
BugLink: http://bugs.launchpad.net/bugs/780546
commit
5f6279da3760ce48f478f2856aacebe0c59a39f3 upstream.
There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering
the OOM killer due to consecutive allocation of large numbers of pages.
Not especially relevant from a security perspective, since users must
have CAP_SYS_ADMIN to open the character device.
First, the user can call pmcraid_chr_ioctl() with a type
PMCRAID_PASSTHROUGH_IOCTL. A pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed
value provided by the user.
If a negative value is provided here, bad things can happen. For
example, pmcraid_build_passthrough_ioadls() is called with this
request_size, which immediately calls pmcraid_alloc_sglist() with a
negative size. The resulting math on allocating a scatter list can
result in an overflow in the kzalloc() call (if num_elem is 0, the
sglist will be smaller than expected), or if num_elem is unexpectedly
large the subsequent loop will call alloc_pages() repeatedly, a high
number of pages will be allocated and the OOM killer might be invoked.
Prevent this value from being negative in pmcraid_ioctl_passthrough().
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Anil Ravindranath <anil_ravindranath@pmc-sierra.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Tue, 10 May 2011 14:36:14 +0000 (08:36 -0600)]
UBUNTU: updateconfigs after update to v2.6.38.6
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Greg Kroah-Hartman [Mon, 2 May 2011 16:30:53 +0000 (09:30 -0700)]
Linux 2.6.38.5
BugLink: http://bugs.launchpad.net/bugs/775809
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Igor Mammedov [Mon, 18 Apr 2011 17:17:17 +0000 (10:17 -0700)]
Input: xen-kbdfront - fix mouse getting stuck after save/restore
BugLink: http://bugs.launchpad.net/bugs/775809
commit
c36b58e8a9112017c2bcc322cc98e71241814303 upstream.
Mouse gets "stuck" after restore of PV guest but buttons are in working
condition.
If driver has been configured for ABS coordinates at start it will get
XENKBD_TYPE_POS events and then suddenly after restore it'll start getting
XENKBD_TYPE_MOTION events, that will be dropped later and they won't get
into user-space.
Regression was introduced by hunk 5 and 6 of
5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
("Input: xen-kbdfront - advertise either absolute or relative
coordinates").
Driver on restore should ask xen for request-abs-pointer again if it is
available. So restore parts that did it before 5ea5254.
Acked-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
[v1: Expanded the commit description]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stanislaw Gruszka [Wed, 13 Apr 2011 08:56:51 +0000 (10:56 +0200)]
iwlegacy: fix tx_power initialization
BugLink: http://bugs.launchpad.net/bugs/775809
commit
332704a51498a7e29aa92c19dc03f11f80b71bfe upstream.
priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like
[ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).
if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: Robin Dong <hao.bigrat@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stanislaw Gruszka [Tue, 29 Mar 2011 09:24:21 +0000 (11:24 +0200)]
iwl3945: disable hw scan by default
BugLink: http://bugs.launchpad.net/bugs/775809
commit
0263aa45293838b514b8af674a03faf040991a90 upstream.
After new NetworkManager 0.8.996 changes, hardware scanning is causing
microcode errors as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=683571
and sometimes kernel crashes:
https://bugzilla.redhat.com/show_bug.cgi?id=688252
Also with hw scan there are very bad performance on some systems
as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=671366
Since Intel no longer supports 3945, there is no chance to get proper
firmware fixes, we need workaround problems by disable hardware scanning
by default.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stanislaw Gruszka [Mon, 14 Mar 2011 13:15:06 +0000 (14:15 +0100)]
iwl3945: do not deprecate software scan
BugLink: http://bugs.launchpad.net/bugs/775809
commit
3bda50e3eaf58a4b9c4ce34204e5faa15c8b1b97 upstream.
Software scanning can be used for workaround some performance problems,
so do not deprecate it.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stanislaw Gruszka [Fri, 28 Jan 2011 15:47:44 +0000 (16:47 +0100)]
iwlwifi: do not set tx power when channel is changing
BugLink: http://bugs.launchpad.net/bugs/775809
commit
f844a709a7d8f8be61a571afc31dfaca9e779621 upstream.
Mac80211 can request for tx power and channel change in one ->config
call. If that happens, *_send_tx_power functions will try to setup tx
power for old channel, what can be not correct because we already change
the band. I.e error "Failed to get channel info for channel 140 [0]",
can be printed frequently when operating in software scanning mode.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Vasiliy Kulikov [Thu, 14 Apr 2011 16:55:19 +0000 (20:55 +0400)]
agp: fix OOM and buffer overflow
BugLink: http://bugs.launchpad.net/bugs/775809
commit
b522f02184b413955f3bc952e3776ce41edc6355 upstream.
page_count is copied from userspace. agp_allocate_memory() tries to
check whether this number is too big, but doesn't take into account the
wrap case. Also agp_create_user_memory() doesn't check whether
alloc_size is calculated from num_agp_pages variable without overflow.
This may lead to allocation of too small buffer with following buffer
overflow.
Another problem in agp code is not addressed in the patch - kernel memory
exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked
whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()).
Each allocation is limited to 16KB, though, there is no per-process limit.
This might lead to OOM situation, which is not even solved in case of the
caller death by OOM killer - the memory is allocated for another (faked) process.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Vasiliy Kulikov [Thu, 14 Apr 2011 16:55:16 +0000 (20:55 +0400)]
agp: fix arbitrary kernel memory writes
BugLink: http://bugs.launchpad.net/bugs/775809
commit
194b3da873fd334ef183806db751473512af29ce upstream.
pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the
comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
and it is not checked at all in case of AGPIOC_UNBIND. As a result, user
with sufficient privileges (usually "video" group) may generate either
local DoS or privilege escalation.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Airlie [Thu, 21 Apr 2011 21:51:33 +0000 (07:51 +1000)]
drm: select FRAMEBUFFER_CONSOLE_PRIMARY if we have FRAMEBUFFER_CONSOLE
BugLink: http://bugs.launchpad.net/bugs/775809
commit
bf5192edcbc1f0a7f9c054649dbf1a0b3210d9b7 upstream.
Multi-gpu/switcheroo relies on this option to get the console on the
correct GPU at bootup, some distros enable it but it seems some get
it wrong.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Richard Weinberger [Wed, 27 Apr 2011 22:26:51 +0000 (15:26 -0700)]
um: mdd support for 64 bit atomic operations
BugLink: http://bugs.launchpad.net/bugs/775809
commit
57d8e02e3cd21bccf2b84b26b42feb79e1f0f83e upstream.
This adds support for 64 bit atomic operations on 32 bit UML systems. XFS
needs them since 2.6.38.
$ make ARCH=um SUBARCH=i386
...
LD .tmp_vmlinux1
fs/built-in.o: In function `xlog_regrant_reserve_log_space':
xfs_log.c:(.text+0xd8584): undefined reference to `atomic64_read_386'
xfs_log.c:(.text+0xd85ac): undefined reference to `cmpxchg8b_emu'
...
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=32812
Reported-by: Martin Walch <walch.martin@web.de>
Tested-by: Martin Walch <walch.martin@web.de>
Cc: Martin Walch <walch.martin@web.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Trond Myklebust [Fri, 15 Apr 2011 21:34:18 +0000 (17:34 -0400)]
NFSv4.1: Ensure state manager thread dies on last umount
BugLink: http://bugs.launchpad.net/bugs/775809
commit
47c2199b6eb5fbe38ddb844db7cdbd914d304f9c upstream.
Currently, the state manager may continue to try recovering state forever
even after the last filesystem to reference that nfs_client has umounted.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jeff Layton [Wed, 27 Apr 2011 15:49:09 +0000 (11:49 -0400)]
nfs: don't lose MS_SYNCHRONOUS on remount of noac mount
BugLink: http://bugs.launchpad.net/bugs/775809
commit
26c4c170731f00008f4317a2888a0a07ac99d90d upstream.
On a remount, the VFS layer will clear the MS_SYNCHRONOUS bit on the
assumption that the flags on the mount syscall will have it set if the
remounted fs is supposed to keep it.
In the case of "noac" though, MS_SYNCHRONOUS is implied. A remount of
such a mount will lose the MS_SYNCHRONOUS flag since "sync" isn't part
of the mount options.
Reported-by: Max Matveev <makc@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Andrew Morton [Wed, 27 Apr 2011 22:26:41 +0000 (15:26 -0700)]
vfs: avoid large kmalloc()s for the fdtable
BugLink: http://bugs.launchpad.net/bugs/775809
commit
6d4831c283530a5f2c6bd8172c13efa236eb149d upstream.
Azurit reports large increases in system time after 2.6.36 when running
Apache. It was bisected down to
a892e2d7dcdfa6c76e6 ("vfs: use kmalloc()
to allocate fdmem if possible").
That patch caused the vfs to use kmalloc() for very large allocations and
this is causing excessive work (and presumably excessive reclaim) within
the page allocator.
Fix it by falling back to vmalloc() earlier - when the allocation attempt
would have been considered "costly" by reclaim.
Reported-by: azurIt <azurit@pobox.sk>
Tested-by: azurIt <azurit@pobox.sk>
Acked-by: Changli Gao <xiaosuo@gmail.com>
Cc: Americo Wang <xiyou.wangcong@gmail.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Michael Schmitz [Tue, 26 Apr 2011 02:51:53 +0000 (14:51 +1200)]
m68k/mm: Set all online nodes in N_NORMAL_MEMORY
BugLink: http://bugs.launchpad.net/bugs/775809
commit
4aac0b4815ba592052758f4b468f253d383dc9d6 upstream.
For m68k, N_NORMAL_MEMORY represents all nodes that have present memory
since it does not support HIGHMEM. This patch sets the bit at the time
node_present_pages has been set by free_area_init_node.
At the time the node is brought online, the node state would have to be
done unconditionally since information about present memory has not yet
been recorded.
If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it
uses this nodemask to setup per-cache kmem_cache_node data structures.
This pach is an alternative to the one proposed by David Rientjes
<rientjes@google.com> attempting to set node state immediately when
bringing the node online.
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Tested-by: Thorsten Glaser <tg@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Andrea Arcangeli [Wed, 27 Apr 2011 22:26:45 +0000 (15:26 -0700)]
mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups
BugLink: http://bugs.launchpad.net/bugs/775809
commit
78f11a255749d09025f54d4e2df4fbcb031530e2 upstream.
The huge_memory.c THP page fault was allowed to run if vm_ops was null
(which would succeed for /dev/zero MAP_PRIVATE, as the f_op->mmap wouldn't
setup a special vma->vm_ops and it would fallback to regular anonymous
memory) but other THP logics weren't fully activated for vmas with vm_file
not NULL (/dev/zero has a not NULL vma->vm_file).
So this removes the vm_file checks so that /dev/zero also can safely use
THP (the other albeit safer approach to fix this bug would have been to
prevent the THP initial page fault to run if vm_file was set).
After removing the vm_file checks, this also makes huge_memory.c stricter
in khugepaged for the DEBUG_VM=y case. It doesn't replace the vm_file
check with a is_pfn_mapping check (but it keeps checking for VM_PFNMAP
under VM_BUG_ON) because for a is_cow_mapping() mapping VM_PFNMAP should
only be allowed to exist before the first page fault, and in turn when
vma->anon_vma is null (so preventing khugepaged registration). So I tend
to think the previous comment saying if vm_file was set, VM_PFNMAP might
have been set and we could still be registered in khugepaged (despite
anon_vma was not NULL to be registered in khugepaged) was too paranoid.
The is_linear_pfn_mapping check is also I think superfluous (as described
by comment) but under DEBUG_VM it is safe to stay.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=33682
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Reported-by: Caspar Zhang <bugs@casparzhang.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
projects / linux-flexiantxendom0-natty.git / log