aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-05-21NET: slip, fix ldisc->open retvalMatvejchikov Ilya
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>
2011-05-21ehea: fix wrongly reported speed and portKleber Sacilotto de Souza
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>
2011-05-21vmxnet3: Consistently disable irqs when taking adapter->cmd_lockRoland Dreier
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>
2011-05-21ipheth: Properly distinguish length and alignment in URBs and skbsBen Hutchings
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>
2011-05-21can: fix SJA1000 dlc for RTR packetsKurt Van Dijck
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>
2011-05-21net: ip_expire() must revalidate routeEric Dumazet
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>
2011-05-21PM / Hibernate: Fix ioctl SNAPSHOT_S2RAMRafael J. Wysocki
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>
2011-05-21PM / Hibernate: Make snapshot_release() restore GFP maskRafael J. Wysocki
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>
2011-05-21PM: Fix warning in pm_restrict_gfp_mask() during SNAPSHOT_S2RAM ioctlRafael J. Wysocki
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>
2011-05-21ARM: zImage: make sure the stack is 64-bit alignedNicolas Pitre
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>
2011-05-21tmpfs: fix race between umount and swapoffHugh Dickins
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>
2011-05-21mm: use alloc_bootmem_node_nopanic() on really needed pathYinghai Lu
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>
2011-05-21drivers/rtc/rtc-s3c.c: fixup wake support for rtcBen Dooks
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>
2011-05-21CIFS: Fix memory over bound bug in cifs_parse_mount_optionsPavel Shilovsky
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>
2011-05-21dccp: handle invalid feature options lengthDan Rosenberg
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>
2011-05-21drm/i915: Release object along create user fb error pathChris Wilson
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>
2011-05-21drm/i915/lvds: Only act on lid notify when the device is onAlex Williamson
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>
2011-05-21drm/i915/dp: Be paranoid in case we disable a DP before it is attachedChris Wilson
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>
2011-05-21Don't lock guardpage if the stack is growing upMikulas Patocka
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>
2011-05-21vm: fix vm_pgoff wrap in upward expansionHugh Dickins
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>
2011-05-21drm/radeon/kms: fix gart setup on fusion parts (v2) backportAlex Deucher
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>
2011-05-21iwlwifi: add {ack, plpc}_check module parametersStanislaw Gruszka
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>
2011-05-21hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ↵Frederic Weisbecker
ptrace_set_debugreg() 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>
2011-05-21ptrace: Prepare to fix racy accesses on task breakpointsFrederic Weisbecker
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>
2011-05-21x86, hw_breakpoints: Fix racy access to ptrace breakpointsFrederic Weisbecker
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>
2011-05-21thinkpad-acpi: module autoloading for newer Lenovo ThinkPads.Manoj Iyer
commit 9fbdaeb4f4dd14a0caa9fc35c496d5440c251a3a upstream. The newer Lenovo ThinkPads have HKEY HID of LEN0068 instead of IBM0068. Added new HID so that thinkpad_acpi module will auto load on these newer Lenovo ThinkPads. Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-21drm/radeon/kms: add pci id to acer travelmate quirk for 5730Alex Deucher
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>
2011-05-21Validate size of EFI GUID partition entries.Timo Warns
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>
2011-05-21cifs: handle errors from coalesce_t2Jeff Layton
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>
2011-05-21cifs: refactor mid finding loop in cifs_demultiplex_threadJeff Layton
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>
2011-05-21cifs: sanitize length checking in coalesce_t2 (try #3)Jeff Layton
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>
2011-05-21cifs: check for bytes_remaining going to zero in CIFS_SessSetupJeff Layton
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>
2011-05-21cifs: change bleft in decode_unicode_ssetup back to signed typeJeff Layton
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>
2011-05-18arm: Add unwinding support for division functionsLaura Abbott
The software division functions never had unwinding annotations added. Currently, when a division by zero occurs the backtrace shown will stop at Ldiv0 or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace when a division by zero occurs. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Tested-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
2011-05-18ARM: sparsemem: fix highmem detection when using SPARSEMEMWill Deacon
sanity_check_meminfo walks over the registered memory banks and attempts to split banks across lowmem and highmem when they would otherwise overlap with the vmalloc space. When SPARSEMEM is used, there are two potential problems that occur when the virtual address of the start of a bank is equal to vmalloc_min. 1.) The end of lowmem is calculated as __pa(vmalloc_min - 1) + 1. In the above scenario, this will give the end address of the previous bank, rather than the actual bank we are interested in. This value is later used as the memblock limit and artificially restricts the total amount of available memory. 2.) The checks to determine whether or not a bank belongs to highmem or not only check if __va(bank->start) is greater or less than vmalloc_min. In the case that it is equal, the bank is incorrectly treated as lowmem, which hoses the vmalloc area. This patch fixes these two problems by checking whether the virtual start address of a bank is >= vmalloc_min and then calculating lowmem_end by finding the virtual end address of the highest lowmem bank. Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
2011-05-17Merge branch 'rsalveti-andy-for-nicolas' of ↵Nicolas Pitre
git://kernel.ubuntu.com/rsalveti/linux-linaro-2.6.38 into linaro-2.6.38
2011-05-17DRM: OMAP: replace request_module with request_module_nowaitRicardo Salveti de Araujo
Otherwise it'll hang while trying to identify the DRM cards and loading for the pvrsrvkm module. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP2: DSS: HDMI: removing error msg from check_timingRicardo Salveti de Araujo
The check_timing call is used to validate the timing before actually appling it, so it's expected to treat unsupported timings. It makes no sense to print an error message for the user saying that the timing could not be applied (it's not even being applied by this function). Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16DRM: OMAP: Fixing PVR kernel module nameRicardo Salveti de Araujo
We currently expect it to be "pvrsrvkm" and not "omap_gpu_pvr", so change it to load the correct driver. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: DRM: Using same numbers of CRTCS and PIPES for OMAP 3 and 4Ricardo Salveti de Araujo
So we avoid having on extra vout resource when we enable both ARCH_OMAP3 and ARCH_OMAP4. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: I2C: "controller timed out" message should use dev_warnRicardo Salveti de Araujo
The OMAP DRM driver pools the I2C bus to find if the monitor is connected or not, and also to grab the EDID data from the monitor. Having the timed out messages as an error error doesn't really help, and is quite annoying for the user, so moving it to dev_warn. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: DSS2: Avoid enabling panel if none is aroundRicardo Salveti de Araujo
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP4: DSS2: HDMI: adding a workaround for LG monitorsRicardo Salveti de Araujo
Some monitors report a disconnect just after a connect, so if force is enabled, give some time and check at least one more time. This is a needed workaround to make the driver work with LG monitors. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: DSS2: adding force argument to is_detected()Ricardo Salveti de Araujo
Force is available from (*detect) at drm_connector_funcs, and can be used by the driver to avoid expensive, destructive operations during automated probing. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16DRM: OMAP: Add HDMI supportJohn Rigby
This is a port from Rob Clark <rob@ti.com> patch. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: DSS: HDMI: tame hdmi driverRob Clark
Main change is to avoid automatically picking timings. Now the driver defaults to a safe 640x480, and leaves it to the upper layer (drm driver) to pick the desired resolution based on what the user selects and the drm infrastucture's parsing of the EDID. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: DSS2: HDMI: Adding is_detected callback supportRicardo Salveti de Araujo
This is a port from Rob Clark <rob@ti.com> patch. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: DSS2: HDMI: Adding get_edid callback supportRicardo Salveti de Araujo
This is a port from Rob Clark <rob@ti.com> patch. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: Panda: adding i2c_bus_num to make it work with omap drm driverRicardo Salveti de Araujo
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
2011-05-16OMAP: devices: register first the drm omap device, and then the SGX oneRicardo Salveti de Araujo
Avoid failing to load omap drm module in cases there the hardware doesn't have SGX hwmode description available. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>