summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-04-28irda: validate peer name and attribute lengthsDan Rosenberg
commit d370af0ef7951188daeb15bae75db7ba57c67846 upstream. Length fields provided by a peer for names and attributes may be longer than the destination array sizes. Validate lengths to prevent stack buffer overflows. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-04-28xfs: prevent leaking uninitialized stack memory in FSGEOMETRY_V1Dan Rosenberg
commit c4d0c3b097f7584772316ee4d64a09fe0e4ddfca upstream. The FSGEOMETRY_V1 ioctl (and its compat equivalent) calls out to xfs_fs_geometry() with a version number of 3. This code path does not fill in the logsunit member of the passed xfs_fsop_geom_t, leading to the leaking of four bytes of uninitialized stack data to potentially unprivileged callers. v2 switches to memset() to avoid future issues if structure members change, on suggestion of Dave Chinner. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Eugene Teo <eugeneteo@kernel.org> Signed-off-by: Alex Elder <aelder@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-28staging: hv: use sync_bitops when interacting with the hypervisorOlaf Hering
commit 22356585712d1ff08fbfed152edd8b386873b238 upstream. Locking is required when tweaking bits located in a shared page, use the sync_ version of bitops. Without this change vmbus_on_event() will miss events and as a result, vmbus_isr() will not schedule the receive tasklet. [Backported to 2.6.32 stable kernel by Haiyang Zhang <haiyangz@microsoft.com>] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Acked-by: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-04-28staging: hv: Fix GARP not sent after Quick MigrationHaiyang Zhang
commit c996edcf1c451b81740abbcca5257ed7e353fcc6 upstream. After Quick Migration, the network is not immediately operational in the current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, I added another netif_notify_peers() into a scheduled work, otherwise GARP packet will not be sent after quick migration, and cause network disconnection. Thanks to Mike Surcouf <mike@surcouf.co.uk> for reporting the bug and testing the patch. Reported-by: Mike Surcouf <mike@surcouf.co.uk> Tested-by: Mike Surcouf <mike@surcouf.co.uk> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Abhishek Kane <v-abkane@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-04-28staging: usbip: bugfix for isochronous packets and optimizationArjan Mels
commit 28276a28d8b3cd19f4449991faad4945fe557656 upstream. For isochronous packets the actual_length is the sum of the actual length of each of the packets, however between the packets might be padding, so it is not sufficient to just send the first actual_length bytes of the buffer. To fix this and simultanesouly optimize the bandwidth the content of the isochronous packets are send without the padding, the padding is restored on the receiving end. Signed-off-by: Arjan Mels <arjan.mels@gmx.net> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Cc: Max Vozeler <max@vozeler.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-28staging: usbip: bugfix add number of packets for isochronous framesArjan Mels
commit 1325f85fa49f57df034869de430f7c302ae23109 upstream. The number_of_packets was not transmitted for RET_SUBMIT packets. The linux client used the stored number_of_packet from the submitted request. The windows userland client does not do this however and needs to know the number_of_packets to determine the size of the transmission. Signed-off-by: Arjan Mels <arjan.mels@gmx.net> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Cc: Max Vozeler <max@vozeler.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-28staging: usbip: bugfixes related to kthread conversionArjan Mels
commit d2dd0b07c3e725d386d20294ec906f7ddef207fa upstream. When doing a usb port reset do a queued reset instead to prevent a deadlock: the reset will cause the driver to unbind, causing the usb_driver_lock_for_reset to stall. Signed-off-by: Arjan Mels <arjan.mels@gmx.net> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Cc: Max Vozeler <max@vozeler.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-28qla2xxx: Make the FC port capability mutual exclusive.Andrew Vasquez
[ upstream commit b0cd579cde8ee0c7ed52239531ba09bcbc5b54c2 ] In case of both target and initiator capabilities reported by fc port, the fc port port capability is made mutualy exclusive with priority given for target capabilities. Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Acked-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-04-28mm: page allocator: adjust the per-cpu counter threshold when memory is lowMel Gorman
Upstream commit 88f5acf88ae6a9778f6d25d0d5d7ec2d57764a97 Commit aa45484 ("calculate a better estimate of NR_FREE_PAGES when memory is low") noted that watermarks were based on the vmstat NR_FREE_PAGES. To avoid synchronization overhead, these counters are maintained on a per-cpu basis and drained both periodically and when a threshold is above a threshold. On large CPU systems, the difference between the estimate and real value of NR_FREE_PAGES can be very high. The system can get into a case where pages are allocated far below the min watermark potentially causing livelock issues. The commit solved the problem by taking a better reading of NR_FREE_PAGES when memory was low. Unfortately, as reported by Shaohua Li this accurate reading can consume a large amount of CPU time on systems with many sockets due to cache line bouncing. This patch takes a different approach. For large machines where counter drift might be unsafe and while kswapd is awake, the per-cpu thresholds for the target pgdat are reduced to limit the level of drift to what should be a safe level. This incurs a performance penalty in heavy memory pressure by a factor that depends on the workload and the machine but the machine should function correctly without accidentally exhausting all memory on a node. There is an additional cost when kswapd wakes and sleeps but the event is not expected to be frequent - in Shaohua's test case, there was one recorded sleep and wake event at least. To ensure that kswapd wakes up, a safe version of zone_watermark_ok() is introduced that takes a more accurate reading of NR_FREE_PAGES when called from wakeup_kswapd, when deciding whether it is really safe to go back to sleep in sleeping_prematurely() and when deciding if a zone is really balanced or not in balance_pgdat(). We are still using an expensive function but limiting how often it is called. When the test case is reproduced, the time spent in the watermark functions is reduced. The following report is on the percentage of time spent cumulatively spent in the functions zone_nr_free_pages(), zone_watermark_ok(), __zone_watermark_ok(), zone_watermark_ok_safe(), zone_page_state_snapshot(), zone_page_state(). vanilla 11.6615% disable-threshold 0.2584% David said: : We had to pull aa454840 "mm: page allocator: calculate a better estimate : of NR_FREE_PAGES when memory is low and kswapd is awake" from 2.6.36 : internally because tests showed that it would cause the machine to stall : as the result of heavy kswapd activity. I merged it back with this fix as : it is pending in the -mm tree and it solves the issue we were seeing, so I : definitely think this should be pushed to -stable (and I would seriously : consider it for 2.6.37 inclusion even at this late date). Signed-off-by: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Andi Kleen <ak@linux.intel.com> Reported-by: Shaohua Li <shaohua.li@intel.com> Reviewed-by: Christoph Lameter <cl@linux.com> Tested-by: Nicolas Bareil <nico@chdir.org> Cc: David Rientjes <rientjes@google.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: <stable@kernel.org> [2.6.37.1, 2.6.36.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> backported from 88f5acf88ae6a9778f6d25d0d5d7ec2d57764a97 BugLink: http://bugs.launchpad.net/bugs/719446 Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31Release 2.6.35.12v2.6.35.12Andi Kleen
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31Relax si_code check in rt_sigqueueinfo and rt_tgsigqueueinfoRoland Dreier
[ upstream commit 243b422 ] Commit da48524eb206 ("Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code") made the check on si_code too strict. There are several legitimate places where glibc wants to queue a negative si_code different from SI_QUEUE: - This was first noticed with glibc's aio implementation, which wants to queue a signal with si_code SI_ASYNCIO; the current kernel causes glibc's tst-aio4 test to fail because rt_sigqueueinfo() fails with EPERM. - Further examination of the glibc source shows that getaddrinfo_a() wants to use SI_ASYNCNL (which the kernel does not even define). The timer_create() fallback code wants to queue signals with SI_TIMER. As suggested by Oleg Nesterov <oleg@redhat.com>, loosen the check to forbid only the problematic SI_TKILL case. Reported-by: Klaus Dittrich <kladit@arcor.de> Acked-by: Julien Tinnes <jln@google.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: <stable@kernel.org> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-31KVM: VMX: Fix host userspace gsbase corruptionMarcelo Tosatti
commit c8770e7ba63bb5dd8fe5f9d251275a8fa717fb78 upstream. We now use load_gs_index() to load gs safely; unfortunately this also changes MSR_KERNEL_GS_BASE, which we managed separately. This resulted in confusion and breakage running 32-bit host userspace on a 64-bit kernel. Fix by - saving guest MSR_KERNEL_GS_BASE before we we reload the host's gs - doing the host save/load unconditionally, instead of only when in guest long mode Things can be cleaned up further, but this is the minmal fix for now. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31KVM: Correct ordering of ldt reload wrt fs/gs reloadAvi Kivity
commit 0a77fe4c188e25917799f2356d4aa5e6d80c39a2 upstream. If fs or gs refer to the ldt, they must be reloaded after the ldt. Reorder the code to that effect. Userspace code that uses the ldt with kvm is nonexistent, so this doesn't fix a user-visible bug. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31KVM: Fix fs/gs reload oops with invalid ldtAvi Kivity
commit 9581d442b9058d3699b4be568b6e5eae38a41493 upstream. kvm reloads the host's fs and gs blindly, however the underlying segment descriptors may be invalid due to the user modifying the ldt after loading them. Fix by using the safe accessors (loadsegment() and load_gs_index()) instead of home grown unsafe versions. This is CVE-2010-3698. KVM-Stable-Tag. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31Revert "KVM: Correct ordering of ldt reload wrt fs/gs reload"Marcelo Tosatti
This reverts commit d3f813da18f83a31f2678988b450e6a1c94c95ed. Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31KVM: i8259: initialize isr_ackAvi Kivity
commit a0272630bb594b4eac03a79e77957df7dad8eade upstream. isr_ack is never initialized. So, until the first PIC reset, interrupts may fail to be injected. This can cause Windows XP to fail to boot, as reported in the fallout from the fix to https://bugzilla.kernel.org/show_bug.cgi?id=21962. Reported-and-tested-by: Nicolas Prochazka <prochazka.nicolas@gmail.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31KVM: enlarge number of possible CPUID leavesAndre Przywara
commit 73c1160ce377d8fc6d84cb630ebf9658808bec49 upstream. Currently the number of CPUID leaves KVM handles is limited to 40. My desktop machine (AthlonII) already has 35 and future CPUs will expand this well beyond the limit. Extend the limit to 80 to make room for future processors. KVM-Stable-Tag. Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31iwl3945: remove plcp checkStanislaw Gruszka
commit c91d01556f52255a31575be0cb1981c92a2a5028 upstream. Patch fixes: https://bugzilla.redhat.com/show_bug.cgi?id=654599 Many users report very low speed problem on 3945 devices, this patch fixes problem, but only for some of them. For unknown reason, sometimes after hw scanning, device is not able to receive frames at high rate. Since plcp health check may request hw scan to "reset radio", performance problem start to be observable after update kernel to .35, where plcp check was introduced. Bug reporter confirmed that removing plcp check fixed problem for him. Reported-and-tested-by: SilvioTO <silviotoya@yahoo.it> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31md: Fix - again - partition detection when array becomes activeNeilBrown
[ upstream commit f0b4f7e2f29af678bd9af43422c537dcb6008603 ] Revert b821eaa572fd737faaf6928ba046e571526c36c6 and f3b99be19ded511a1bf05a148276239d9f13eefa When I wrote the first of these I had a wrong idea about the lifetime of 'struct block_device'. It can disappear at any time that the block device is not open if it falls out of the inode cache. So relying on the 'size' recorded with it to detect when the device size has changed and so we need to revalidate, is wrong. Rather, we really do need the 'changed' attribute stored directly in the mddev and set/tested as appropriate. Without this patch, a sequence of: mknod / open / close / unlink (which can cause a block_device to be created and then destroyed) will result in a rescan of the partition table and consequence removal and addition of partitions. Several of these in a row can get udev racing to create and unlink and other code can get confused. With the patch, the rescan is only performed when needed and so there are no races. This is suitable for any stable kernel from 2.6.35. Reported-by: "Wojcik, Krzysztof" <krzysztof.wojcik@intel.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org
2011-03-31hwmon: (w83627ehf) Driver cleanupGuenter Roeck
[ upstream commit da2e025590cf7038440132d4bbc967a579b11112 ] - Moved fan pwm register array pointers into per-instance data. - Only read fan pwm data for installed/supported fans. - Update fan max output and fan step output information from data in registers. - Create max_output and step_output attribute files only if respective fan pwm registers exist. Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31net: Fix ip link add netns oopsEric W. Biederman
[ upstream commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 ] Ed Swierk <eswierk@bigswitch.com> writes: > On 2.6.35.7 > ip link add link eth0 netns 9999 type macvlan > where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang: > [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d > [10663.821917] IP: [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170 > [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0 > [10663.821944] Oops: 0000 [#1] SMP > [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [10663.821959] CPU 3 > [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class > [10663.822155] > [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO > [10663.822167] RIP: 0010:[<ffffffff8149c2fa>] [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170 > [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286 > [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000 > [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000 > [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041 > [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818 > [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000 > [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000 > [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0 > [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0) > [10663.822236] Stack: > [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6 > [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818 > [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413 > [10663.822281] Call Trace: > [10663.822290] [<ffffffff814a2bb5>] ? dev_addr_init+0x75/0xb0 > [10663.822298] [<ffffffff8149c413>] dev_alloc_name+0x43/0x90 > [10663.822307] [<ffffffff814a85ee>] rtnl_create_link+0xbe/0x1b0 > [10663.822314] [<ffffffff814ab2aa>] rtnl_newlink+0x48a/0x570 > [10663.822321] [<ffffffff814aafcc>] ? rtnl_newlink+0x1ac/0x570 > [10663.822332] [<ffffffff81030064>] ? native_x2apic_icr_read+0x4/0x20 > [10663.822339] [<ffffffff814a8c17>] rtnetlink_rcv_msg+0x177/0x290 > [10663.822346] [<ffffffff814a8aa0>] ? rtnetlink_rcv_msg+0x0/0x290 > [10663.822354] [<ffffffff814c25d9>] netlink_rcv_skb+0xa9/0xd0 > [10663.822360] [<ffffffff814a8a85>] rtnetlink_rcv+0x25/0x40 > [10663.822367] [<ffffffff814c223e>] netlink_unicast+0x2de/0x2f0 > [10663.822374] [<ffffffff814c303e>] netlink_sendmsg+0x1fe/0x2e0 > [10663.822383] [<ffffffff81488533>] sock_sendmsg+0xf3/0x120 > [10663.822391] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20 > [10663.822400] [<ffffffff81168656>] ? __d_lookup+0x136/0x150 > [10663.822406] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20 > [10663.822414] [<ffffffff812b7a0d>] ? _atomic_dec_and_lock+0x4d/0x80 > [10663.822422] [<ffffffff8116ea90>] ? mntput_no_expire+0x30/0x110 > [10663.822429] [<ffffffff81486ff5>] ? move_addr_to_kernel+0x65/0x70 > [10663.822435] [<ffffffff81493308>] ? verify_iovec+0x88/0xe0 > [10663.822442] [<ffffffff81489020>] sys_sendmsg+0x240/0x3a0 > [10663.822450] [<ffffffff8111e2a9>] ? __do_fault+0x479/0x560 > [10663.822457] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20 > [10663.822465] [<ffffffff8116cf4a>] ? alloc_fd+0x10a/0x150 > [10663.822473] [<ffffffff8158d76e>] ? do_page_fault+0x15e/0x350 > [10663.822482] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b > [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55 > [10663.822618] RIP [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170 > [10663.822627] RSP <ffff88014aebf7b8> > [10663.822631] CR2: 000000000000006d > [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]--- This bug was introduced in: commit 81adee47dfb608df3ad0b91d230fb3cef75f0060 Author: Eric W. Biederman <ebiederm@aristanetworks.com> Date: Sun Nov 8 00:53:51 2009 -0800 net: Support specifying the network namespace upon device creation. There is no good reason to not support userspace specifying the network namespace during device creation, and it makes it easier to create a network device and pass it to a child network namespace with a well known name. We have to be careful to ensure that the target network namespace for the new device exists through the life of the call. To keep that logic clear I have factored out the network namespace grabbing logic into rtnl_link_get_net. In addtion we need to continue to pass the source network namespace to the rtnl_link_ops.newlink method so that we can find the base device source network namespace. Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Where apparently I forgot to add error handling to the path where we create a new network device in a new network namespace, and pass in an invalid pid. Cc: stable@kernel.org Reported-by: Ed Swierk <eswierk@bigswitch.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31Revert "slab: Fix missing DEBUG_SLAB last user"Pekka Enberg
[ upstream commit 3ff84a7f36554b257cd57325b1a7c1fa4b49fbe3 ] This reverts commit 5c5e3b33b7cb959a401f823707bee006caadd76e. The commit breaks ARM thusly: | Mount-cache hash table entries: 512 | slab error in verify_redzone_free(): cache `idr_layer_cache': memory outside object was overwritten | Backtrace: | [<c0227088>] (dump_backtrace+0x0/0x110) from [<c0431afc>] (dump_stack+0x18/0x1c) | [<c0431ae4>] (dump_stack+0x0/0x1c) from [<c0293304>] (__slab_error+0x28/0x30) | [<c02932dc>] (__slab_error+0x0/0x30) from [<c0293a74>] (cache_free_debugcheck+0x1c0/0x2b8) | [<c02938b4>] (cache_free_debugcheck+0x0/0x2b8) from [<c0293f78>] (kmem_cache_free+0x3c/0xc0) | [<c0293f3c>] (kmem_cache_free+0x0/0xc0) from [<c032b1c8>] (ida_get_new_above+0x19c/0x1c0) | [<c032b02c>] (ida_get_new_above+0x0/0x1c0) from [<c02af7ec>] (alloc_vfsmnt+0x54/0x144) | [<c02af798>] (alloc_vfsmnt+0x0/0x144) from [<c0299830>] (vfs_kern_mount+0x30/0xec) | [<c0299800>] (vfs_kern_mount+0x0/0xec) from [<c0299908>] (kern_mount_data+0x1c/0x20) | [<c02998ec>] (kern_mount_data+0x0/0x20) from [<c02146c4>] (sysfs_init+0x68/0xc8) | [<c021465c>] (sysfs_init+0x0/0xc8) from [<c02137d4>] (mnt_init+0x90/0x1b0) | [<c0213744>] (mnt_init+0x0/0x1b0) from [<c0213388>] (vfs_caches_init+0x100/0x140) | [<c0213288>] (vfs_caches_init+0x0/0x140) from [<c0208c0c>] (start_kernel+0x2e8/0x368) | [<c0208924>] (start_kernel+0x0/0x368) from [<c0208034>] (__enable_mmu+0x0/0x2c) | c0113268: redzone 1:0xd84156c5c032b3ac, redzone 2:0xd84156c5635688c0. | slab error in cache_alloc_debugcheck_after(): cache `idr_layer_cache': double free, or memory outside object was overwritten | ... | c011307c: redzone 1:0x9f91102ffffffff, redzone 2:0x9f911029d74e35b | slab: Internal list corruption detected in cache 'idr_layer_cache'(24), slabp c0113000(16). Hexdump: | | 000: 20 4f 10 c0 20 4f 10 c0 7c 00 00 00 7c 30 11 c0 | 010: 10 00 00 00 10 00 00 00 00 00 c9 17 fe ff ff ff | 020: fe ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff | 030: fe ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff | 040: fe ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff | 050: fe ff ff ff fe ff ff ff fe ff ff ff 11 00 00 00 | 060: 12 00 00 00 13 00 00 00 14 00 00 00 15 00 00 00 | 070: 16 00 00 00 17 00 00 00 c0 88 56 63 | kernel BUG at /home/rmk/git/linux-2.6-rmk/mm/slab.c:2928! Reference: https://lkml.org/lkml/2011/2/7/238 Cc: <stable@kernel.org> # 2.6.35.y and later Reported-and-analyzed-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31perf: Fix tear-down of inherited group eventsPeter Zijlstra
[ upstream commit 38b435b16c36b0d863efcf3f07b34a6fac9873fd ] When destroying inherited events, we need to destroy groups too, otherwise the event iteration in perf_event_exit_task_context() will miss group siblings and we leak events with all the consequences. Reported-and-tested-by: Vince Weaver <vweaver1@eecs.utk.edu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: <stable@kernel.org> # .35+ LKML-Reference: <1300196470.2203.61.camel@twins> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-03-31xhci: Update internal dequeue pointers after stalls.Sarah Sharp
[ upstream commit bf161e85fb153c0dd5a95faca73fd6a9d237c389 ] When an endpoint stalls, the xHCI driver must move the endpoint ring's dequeue pointer past the stalled transfer. To do that, the driver issues a Set TR Dequeue Pointer command, which will complete some time later. Takashi was having issues with USB 1.1 audio devices that stalled, and his analysis of the code was that the old code would not update the xHCI driver's ring dequeue pointer after the command completes. However, the dequeue pointer is set in xhci_find_new_dequeue_state(), just before the set command is issued to the hardware. Setting the dequeue pointer before the Set TR Dequeue Pointer command completes is a dangerous thing to do, since the xHCI hardware can fail the command. Instead, store the new dequeue pointer in the xhci_virt_ep structure, and update the ring's dequeue pointer when the Set TR dequeue pointer command completes. While we're at it, make sure we can't queue another Set TR Dequeue Command while the first one is still being processed. This just won't work with the internal xHCI state code. I'm still not sure if this is the right thing to do, since we might have a case where a driver queues multiple URBs to a control ring, one of the URBs Stalls, and then the driver tries to cancel the second URB. There may be a race condition there where the xHCI driver might try to issue multiple Set TR Dequeue Pointer commands, but I would have to think very hard about how the Stop Endpoint and cancellation code works. Keep the fix simple until when/if we run into that case. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org
2011-03-31USB: isp1760: Implement solution for erratum 2Sebastian Andrzej Siewior
The document says: |2.1 Problem description | When at least two USB devices are simultaneously running, it is observed that | sometimes the INT corresponding to one of the USB devices stops occurring. This may | be observed sometimes with USB-to-serial or USB-to-network devices. | The problem is not noticed when only USB mass storage devices are running. |2.2 Implication | This issue is because of the clearing of the respective Done Map bit on reading the ATL | PTD Done Map register when an INT is generated by another PTD completion, but is not | found set on that read access. In this situation, the respective Done Map bit will remain | reset and no further INT will be asserted so the data transfer corresponding to that USB | device will stop. |2.3 Workaround | An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can | be implemented and if a certain Done bit is never set, verification of the PTD completion | can be done by reading PTD contents (valid bit). | This is a proven workaround implemented in software. Russell King run into this with an USB-to-serial converter. This patch implements his suggestion to enable the high frequent SOF interrupt only at the time we have ATL packages queued. It goes even one step further and enables the SOF interrupt only if we have more than one ATL packet queued at the same time. Cc: <stable@kernel.org> # [2.6.35.x, 2.6.36.x, 2.6.37.x] Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31cfg80211: fix can_beacon_sec_chan, reenable HT40Mark Mentovai
[ upstream commit 09a02fdb919876c01e8f05960750a418b3f7fa48 ] This follows wireless-testing 9236d838c920e90708570d9bbd7bb82d30a38130 ("cfg80211: fix extension channel checks to initiate communication") and fixes accidental case fall-through. Without this fix, HT40 is entirely blocked. Signed-off-by: Mark Mentovai <mark@moxienet.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-03-31revert misc: uss720.c: add another vendor/product IDChuck Ebbert
In 2.6.35.10: [ 122.146074] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 122.325102] usb 2-1: New USB device found, idVendor=050d, idProduct=0002 [ 122.325110] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 122.325117] usb 2-1: Product: IEEE-1284 Controller [ 122.325121] usb 2-1: Manufacturer: Belk USB Printing Support [ 123.531167] usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x050D pid 0x0002 [ 123.531208] usbcore: registered new interface driver usblp In 2.6.35.11: [ 8046.227051] usb 2-1: new full speed USB device using uhci_hcd and address 6 [ 8046.408083] usb 2-1: New USB device found, idVendor=050d, idProduct=0002 [ 8046.408088] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 8046.408092] usb 2-1: Product: IEEE-1284 Controller [ 8046.408094] usb 2-1: Manufacturer: Belk USB Printing Support [ 8047.552140] get_1284_register timeout [ 8047.554102] uss720: async_complete: urb error -104 [repeats] [ 8047.556111] uss720: async_complete: urb error -32 [sequence repeats] [unplug connector] [ 8485.688067] parport0: fix this legacy no-device port driver! [ 8485.688427] uss720: async_complete: urb error -32 Blacklisting the uss720 driver fixes the problem. From 0a67b7cf26d73ed1dbea7e99d63673b5c4aa479e Mon Sep 17 00:00:00 2001 From: Thomas Sailer <t.sailer@alumni.ethz.ch> Date: Tue, 14 Dec 2010 16:04:05 +0100 Subject: [PATCH] USB: misc: uss720.c: add another vendor/product ID commit ecc1624a2fff45780959efbcb73ace18fdb3c58d upstream. Fabio Battaglia report that he has another cable that works with this driver, so this patch adds its vendor/product ID. Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31Patch cab9e9848b9a8283b0504a2d7c435a9f5ba026de to the 2.6.35.y stable treeDavid Howells
stored a ref to the current cred struct in struct scm_cookie. This was fine with AF_UNIX as that calls scm_destroy() from its packet sending functions, but AF_NETLINK, which also uses scm_send(), does not call scm_destroy() - meaning that the copied credentials leak each time SCM data is sent over a netlink socket. This can be triggered quite simply on a Fedora 13 or 14 userspace with the 2.6.35.11 kernel (or something based off of that) by calling: #!/bin/bash for ((i=0; i<100; i++)) do su - -c /bin/true cut -d: -f1 /proc/slabinfo | grep 'cred\|key\|task_struct' cat /proc/keys | wc -l done This leaks the session key that pam_keyinit creates for 'su -', which appears in /proc/keys as being revoked (has the R flag set against it) afterward su is called. Furthermore, if CONFIG_SLAB=y, then the cred and key slab object usage counts can be viewed and seen to increase. The key slab increases by one object per loop, and this can be seen after the system has had a couple of minutes to stand after the script above has been run on it. If the system is working correctly, the key and cred counts should return to roughly what they were before. This patch from upstream (b47030c71dfd6c8cd5cb6e551b6f7f7cfc96f6a6) is needed to fix the problem: =============================================================================== From: Eric W. Biederman <ebiederm@xmission.com> af_netlink: Add needed scm_destroy after scm_send. scm_send occasionally allocates state in the scm_cookie, so I have modified netlink_sendmsg to guarantee that when scm_send succeeds scm_destory will be called to free that state. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@free.fr> Acked-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-03-31netfilter: arpt_mangle: fix return values of checkentryPablo Neira Ayuso
In 135367b "netfilter: xtables: change xt_target.checkentry return type", the type returned by checkentry was changed from boolean to int, but the return values where not adjusted. arptables: Input/output error This broke arptables with the mangle target since it returns true under success, which is interpreted by xtables as >0, thus returning EIO. The following Linux kernels are affected: * 2.6.35.9 * 2.6.36.4 * 2.6.37.3 Cc: stable@kernel.org Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Andi Kleen <ak@linux.intel.com> (cherry picked from commit 9d0db8b6b1da9e3d4c696ef29449700c58d589db)
2011-03-31classmate-laptop: depends on RFKILL or RFKILL=nThadeu Lima de Souza Cascardo
[ upstream commit f35843ed8d17562f7c5da4b34a4a81b0cc450e9e ] Randy Dunlap has reported that building classmate-laptop fails when CONFIG_RFKILL=m and CONFIG_ACPI_CMPC=y. He suggested depending on RFKILL, but, then, it will not be possible to select classmate-laptop when RFKILL is off. There's no known problem with building and using classmate-laptop with RFKILL off. So depend on RFKILL or RFKILL=n. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: platform-driver-x86@vger.kernel.org Cc: Daniel Oliveira Nascimento <don@syst.com.br>
2011-03-31PM / Hibernate: Make default image size depend on total RAM sizeRafael J. Wysocki
[ upstream commit ac5c24ec1e983313ef0015258fba6f630e54e7cf ] The default hibernation image size is currently hard coded and euqal to 500 MB, which is not a reasonable default on many contemporary systems. Make it equal 2/5 of the total RAM size (this is slightly below the maximum, i.e. 1/2 of the total RAM size, and seems to be generally suitable). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: M. Vefa Bicakci <bicave@superonline.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31PM / Hibernate: Improve comments in hibernate_preallocate_memory()Rafael J. Wysocki
[ upstream commit 266f1a25eff5ff98c498d7754a419aacfd88f71c ] One comment in hibernate_preallocate_memory() is wrong, so fix it and add one more comment to clarify the meaning of the fixed one. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31eCryptfs: ecryptfs_keyring_auth_tok_for_sig() bug fixRoberto Sassu
commit 1821df040ac3cd6a57518739f345da6d50ea9d3f upstream. The pointer '(*auth_tok_key)' is set to NULL in case request_key() fails, in order to prevent its use by functions calling ecryptfs_keyring_auth_tok_for_sig(). Signed-off-by: Roberto Sassu <roberto.sassu@polito.it> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31eCryptfs: Unlock page in write_begin error pathTyler Hicks
commit 50f198ae16ac66508d4b8d5a40967a8507ad19ee upstream. Unlock the page in error path of ecryptfs_write_begin(). This may happen, for example, if decryption fails while bring the page up-to-date. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31ses: Avoid kernel panic when lun 0 is not mappedKrishnasamy, Somasundaram
commit d1e12de804f9d8ad114786ca7c2ce593cba79891 upstream. During device discovery, scsi mid layer sends INQUIRY command to LUN 0. If the LUN 0 is not mapped to host, it creates a temporary scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After the REPORT_LUNS succeeds, it walks through the LUN table and adds each LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will delete the temporary scsi_device of LUN 0. When scsi devices are added to sysfs, it calls add_dev function of all the registered class interfaces. If ses driver has been registered, ses_intf_add() of ses module will be called. This function calls scsi_device_enclosure() to check the inquiry data for EncServ bit. Since inquiry was not allocated for temporary LUN 0 scsi_device, it will cause NULL pointer exception. To fix the problem, sdev->inquiry is checked for NULL before reading it. Signed-off-by: Somasundaram Krishnasamy <Somasundaram.Krishnasamy@lsi.com> Signed-off-by: Babu Moger <babu.moger@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31ses: show devices for enclosures with no page 7John Hughes
commit 877a55979c189c590e819a61cbbe2b7947875f17 upstream. enclosure page 7 gives us the "pretty" names of the enclosure slots. Without a page 7, we can still use the enclosure code as long as we make up numeric names for the slots. Unfortunately, the current code fails to add any devices because the check for page 10 is in the wrong place if we have no page 7. Fix it so that devices show up even if the enclosure has no page 7. Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31mac80211: initialize sta->last_rx in sta_info_allocFelix Fietkau
commit 8bc8aecdc5e26cfda12dbd6867af4aa67836da6a upstream. This field is used to determine the inactivity time. When in AP mode, hostapd uses it for kicking out inactive clients after a while. Without this patch, hostapd immediately deauthenticates a new client if it checks the inactivity time before the client sends its first data frame. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31sound/oss/opl3: validate voice and channel indexesDan Rosenberg
commit 4d00135a680727f6c3be78f8befaac009030e4df upstream. User-controllable indexes for voice and channel values may cause reading and writing beyond the bounds of their respective arrays, leading to potentially exploitable memory corruption. Validate these indexes. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31cciss: fix lost command issueBud Brown
commit 1ddd5049545e0aa1a0ed19bca4d9c9c3ce1ac8a2 upstream. Under certain workloads a command may seem to get lost. IOW, the Smart Array thinks all commands have been completed but we still have commands in our completion queue. This may lead to system instability, filesystems going read-only, or even panics depending on the affected filesystem. We add an extra read to force the write to complete. Testing shows this extra read avoids the problem. Signed-off-by: Mike Miller <mike.miller@hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31myri10ge: fix rmmod crashStanislaw Gruszka
commit cda6587c21a887254c8ed4b58da8fcc4040ab557 upstream. Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi structures are already deallocated. To fix call netif_napi_del() before kfree() at myri10ge_free_slices(). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31perf: Better fit max unprivileged mlock pages for tools needsFrederic Weisbecker
commit 880f57318450dbead6a03f9e31a1468924d6dd88 upstream. The maximum kilobytes of locked memory that an unprivileged user can reserve is of 512 kB = 128 pages by default, scaled to the number of onlined CPUs, which fits well with the tools that use 128 data pages by default. However tools actually use 129 pages, because they need one more for the user control page. Thus the default mlock threshold is not sufficient for the default tools needs and we always end up to evaluate the constant mlock rlimit policy, which doesn't have this scaling with the number of online CPUs. Hence, on systems that have more than 16 CPUs, we overlap the rlimit threshold and fail to mmap: $ perf record ls Error: failed to mmap with 1 (Operation not permitted) Just increase the max unprivileged mlock threshold by one page so that it supports well perf tools even after 16 CPUs. Reported-by: Han Pingtian <phan@redhat.com> Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Stephane Eranian <eranian@google.com> LKML-Reference: <1300904979-5508-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-03-31ALSA: Fix yet another race in disconnectionTakashi Iwai
commit a45e3d6b13e97506b616980c0f122c3389bcefa4 upstream. This patch fixes a race between snd_card_file_remove() and snd_card_disconnect(). When the card is added to shutdown_files list in snd_card_disconnect(), but it's freed in snd_card_file_remove() at the same time, the shutdown_files list gets corrupted. The list member must be freed in snd_card_file_remove() as well. Reported-and-tested-by: Russ Dill <russ.dill@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31ALSA: hda - Fix SPDIF out regression on ALC889Takashi Iwai
commit 20b67dddcc5f29d3d0c900225d85e0ac655bc69d upstream. The commit 5a8cfb4e8ae317d283f84122ed20faa069c5e0c4 ALSA: hda - Use ALC_INIT_DEFAULT for really default initialization changed to use the default initialization method for ALC889, but this caused a regression on SPDIF output on some machines. This seems due to the COEF setup included in the default init procedure. For making SPDIF working again, the COEF-setup has to be avoided for the id 0889. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24342 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31dcdbas: force SMI to happen when expectedStuart Hayes
commit dd65c736d1b5312c80c88a64bf521db4959eded5 upstream. The dcdbas driver can do an I/O write to cause a SMI to occur. The SMI handler looks at certain registers and memory locations, so the SMI needs to happen immediately. On some systems I/O writes are posted, though, causing the SMI to happen well after the "outb" occurred, which causes random failures. Following the "outb" with an "inb" forces the write to go through even if it is posted. Signed-off-by: Stuart Hayes <stuart_hayes@yahoo.com> Acked-by: Doug Warzecha <douglas_warzecha@dell.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-31fs: call security_d_instantiate in d_obtain_alias V2Josef Bacik
commit 24ff6663ccfdaf088dfa7acae489cb11ed4f43c4 upstream. While trying to track down some NFS problems with BTRFS, I kept noticing I was getting -EACCESS for no apparent reason. Eric Paris and printk() helped me figure out that it was SELinux that was giving me grief, with the following denial type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772 comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Turns out this is because in d_obtain_alias if we can't find an alias we create one and do all the normal instantiation stuff, but we don't do the security_d_instantiate. Usually we are protected from getting a hashed dentry that hasn't yet run security_d_instantiate() by the parent's i_mutex, but obviously this isn't an option there, so in order to deal with the case that a second thread comes in and finds our new dentry before we get to run security_d_instantiate(), we go ahead and call it if we find a dentry already. Eric assures me that this is ok as the code checks to see if the dentry has been initialized already so calling security_d_instantiate() against the same dentry multiple times is ok. With this patch I'm no longer getting errant -EACCESS values. Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-31SUNRPC: Never reuse the socket port after an xs_close()Trond Myklebust
commit 246408dcd5dfeef2df437ccb0ef4d6ee87805f58 upstream. If we call xs_close(), we're in one of two situations: - Autoclose, which means we don't expect to resend a request - bind+connect failed, which probably means the port is in use Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31Input: xen-kbdfront - advertise either absolute or relative coordinatesOlaf Hering
commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6 upstream. A virtualized display device is usually viewed with the vncviewer application, either by 'xm vnc domU' or with vncviewer localhost:port. vncviewer and the RFB protocol provides absolute coordinates to the virtual display. These coordinates are either passed through to a PV guest or converted to relative coordinates for a HVM guest. A PV guest receives these coordinates and passes them to the kernels evdev driver. There it can be picked up by applications such as the xorg-input drivers. Using absolute coordinates avoids issues such as guest mouse pointer not tracking host mouse pointer due to wrong mouse acceleration settings in the guests X display. Advertise either absolute or relative coordinates to the input system and the evdev driver, depending on what dom0 provides. The xorg-input driver prefers relative coordinates even if a devices provides both. Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31USB: cdc-acm: fix potential null-pointer dereference on disconnectJohan Hovold
commit 7e7797e7f6f7bfab73fca02c65e40eaa5bb9000c upstream. Fix potential null-pointer exception on disconnect introduced by commit 11ea859d64b69a747d6b060b9ed1520eab1161fe (USB: additional power savings for cdc-acm devices that support remote wakeup). Only access acm->dev after making sure it is non-null in control urb completion handler. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31USB: cdc-acm: fix potential null-pointer dereferenceJohan Hovold
commit 15e5bee33ffc11d0e5c6f819a65e7881c5c407be upstream. Must check return value of tty_port_tty_get. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2011-03-31USB: cdc-acm: fix memory corruption / panicJohan Hovold
commit 23b80550e2aa61d0ba3af98b831b9195be0db9ee upstream. Prevent read urbs from being resubmitted from tasklet after port close. The receive tasklet was not disabled on port close, which could lead to corruption of receive lists on consecutive port open. In particular, read urbs could be re-submitted before port open, added to free list in open, and then added a second time to the free list in the completion handler. cdc-acm.c: Entering acm_tty_open. cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0 cdc-acm.c: Entering acm_rx_tasklet cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64 cdc-acm.c: set line: 115200 0 0 8 cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7 cdc-acm.c: acm_tty_close cdc-acm.c: acm_port_down cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0 cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50 cdc-acm.c: Entering acm_read_bulk with status -2 cdc_acm 4-1:1.1: Aborting, acm not ready cdc-acm.c: Entering acm_read_bulk with status -2 cdc_acm 4-1:1.1: Aborting, acm not ready cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38 cdc-acm.c: Entering acm_tty_open. cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0 cdc-acm.c: Entering acm_rx_tasklet cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64 cdc-acm.c: Entering acm_tty_write to write 3 bytes, cdc-acm.c: Get 3 bytes... cdc-acm.c: acm_write_start susp_count: 0 cdc-acm.c: Entering acm_read_bulk with status 0 Signed-off-by: Andi Kleen <ak@linux.intel.com> ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120() Hardware name: Vostro 1520 list_del corruption. next->prev should be f57fbc10, but was f57fbaf8 Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd8ac>] list_del+0x10c/0x120 [<f8051dbf>] acm_rx_tasklet+0xef/0x3e0 [cdc_acm] [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f0082e ]--- ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120() Hardware name: Vostro 1520 list_del corruption. next->prev should be f57fbd50, but was f57fbdb0 Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd8ac>] list_del+0x10c/0x120 [<f8051dd6>] acm_rx_tasklet+0x106/0x3e0 [cdc_acm] [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f0082f ]--- cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50 cdc-acm.c: disconnected from network cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c cdc-acm.c: Entering acm_rx_tasklet ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120() Hardware name: Vostro 1520 list_del corruption, next is LIST_POISON1 (00100100) Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd875>] ? list_del+0xd5/0x120 [<c11dd875>] ? list_del+0xd5/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd875>] list_del+0xd5/0x120 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f00830 ]--- BUG: unable to handle kernel paging request at 00200200 IP: [<c11dd7bd>] list_del+0x1d/0x120 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 0T816J/Vostro 1520 EIP: 0060:[<c11dd7bd>] EFLAGS: 00010046 CPU: 0 EIP is at list_del+0x1d/0x120 EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200 ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000) Stack: c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30 f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0 Call Trace: [<f8051fac>] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] ? tasklet_action+0xe6/0x140 [<c104342f>] ? __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48 EIP: [<c11dd7bd>] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c CR2: 0000000000200200 ---[ end trace efd9a11434f00831 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.37+ #39 Call Trace: [<c13fede1>] ? printk+0x1d/0x24 [<c13fecce>] panic+0x66/0x15c [<c10067df>] oops_end+0x8f/0x90 [<c1025476>] no_context+0xc6/0x160 [<c10255a8>] __bad_area_nosemaphore+0x98/0x140 [<c103cf68>] ? release_console_sem+0x1d8/0x210 [<c1025667>] bad_area_nosemaphore+0x17/0x20 [<c1025a49>] do_page_fault+0x279/0x420 [<c1006a8f>] ? show_trace+0x1f/0x30 [<c13fede1>] ? printk+0x1d/0x24 [<c10257d0>] ? do_page_fault+0x0/0x420 [<c140333b>] error_code+0x5f/0x64 [<c103007b>] ? select_task_rq_fair+0x37b/0x6a0 [<c10257d0>] ? do_page_fault+0x0/0x420 [<c11dd7bd>] ? list_del+0x1d/0x120 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 panic occurred, switching back to text console ------------[ cut here ]------------ Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>