- May 26, 2010
-
-
Greg Kroah-Hartman authored
-
Herbert Xu authored
commit 180ce7e8 upstream. When Steffen originally wrote the authenc async hash patch, he correctly had EINPROGRESS checks in place so that we did not invoke the original completion handler with it. Unfortuantely I told him to remove it before the patch was applied. As only MAY_BACKLOG request completion handlers are required to handle EINPROGRESS completions, those checks are really needed. This patch restores them. Reported-by:
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Luis R. Rodriguez authored
Johannes' patch 34e89507 titled: mac80211: allow station add/remove to sleep changed the way mac80211 adds and removes peers. The new sta_add() / sta_remove() callbacks allowed the driver callbacks to sleep. Johannes also ported ath9k to use sta_add() / sta_remove() via the patch 4ca77860 titled: ath9k: convert to new station add/remove callbacks but this patch forgot to address a change in locking issue which Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl build includes code for the 802.11 subsystem for 2.6.34 though so did already have the above two patches (ath9k_sta_remove() on his trace), the 2.6.33 kernel did not however have these two patches. Ming eventually cured his lockdep warnign via the patch a9f042cb titled: ath9k: fix lockdep warning when unloading module This went in to 2.6.34 and although it was not marked as a stable fix it did get trickled down and applied on both 2.6.33 and 2.6.32. In review, the culprits: mac80211: allow station add/remove to sleep git describe --contains 34e89507 v2.6.34-rc1~233^2~49^2~107 ath9k: convert to new station add/remove callbacks git describe --contains 4ca77860 v2.6.34-rc1~233^2~49^2~10 ath9k: fix lockdep warning when unloading module This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid). git describe --contains a9f042cb v2.6.34-rc2~48^2~77^2~7 git describe --contains 0524bcfa v2.6.33.2~125 git describe --contains 0dcc9985 v2.6.32.11~79 The patch titled "ath9k: fix lockdep warning when unloading module" should be reverted on both 2.6.33 and 2.6.32 as it is invalid and actually ended up causing the following warning: ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 phy0: device now idle ------------[ cut here ]------------ WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0() Hardware name: 7660A14 Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc> Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6 Call Trace: [<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0 [<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20 [<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0 [<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20 [<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k] [<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k] [<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211] [<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211] [<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211] [<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211] [<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211] [<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211] [<ffffffff81118540>] ? init_object+0x50/0x90 [<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211] [<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211] [<ffffffff81514ca7>] notifier_call_chain+0x47/0x90 [<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20 [<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20 [<ffffffff8144352d>] dev_close+0x4d/0xa0 [<ffffffff814439a8>] rollback_registered+0x48/0x120 [<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70 [<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211] [<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211] [<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k] [<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k] [<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k] [<ffffffff8129d712>] pci_device_remove+0x32/0x60 [<ffffffff81332373>] __device_release_driver+0x53/0xb0 [<ffffffff81332498>] driver_detach+0xc8/0xd0 [<ffffffff81331405>] bus_remove_driver+0x85/0xe0 [<ffffffff81332a5a>] driver_unregister+0x5a/0x90 [<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0 [<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k] [<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k] [<ffffffff81092838>] sys_delete_module+0x1a8/0x270 [<ffffffff8107ebe9>] ? up_read+0x9/0x10 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b ---[ end trace fad957019ffdd40b ]--- phy0: Removed STA 00:22:6b:56:fd:e8 phy0: Destroyed STA 00:22:6b:56:fd:e8 wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3) ath9k 0000:16:00.0: PCI INT A disabled The original lockdep fixed an issue where due to the new changes the driver was not disabling the bottom halves but it is incorrect to do this on the older kernels since IRQs are already disabled. Cc: Ming Lei <tom.leiming@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: John W. Linville <linville@tuxdriver.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Ryusuke Konishi authored
commit 973bec34 upstream. As of 32a88aa1, __sync_filesystem() will return 0 if s_bdi is not set. And nilfs does not set s_bdi anywhere. I noticed this problem by the warning introduced by the recent commit 5129a469 ("Catch filesystem lacking s_bdi"). WARNING: at fs/super.c:959 vfs_kern_mount+0xc5/0x14e() Hardware name: PowerEdge 2850 Modules linked in: nilfs2 loop tpm_tis tpm tpm_bios video shpchp pci_hotplug output dcdbas Pid: 3773, comm: mount.nilfs2 Not tainted 2.6.34-rc6-debug #38 Call Trace: [<c1028422>] warn_slowpath_common+0x60/0x90 [<c102845f>] warn_slowpath_null+0xd/0x10 [<c1095936>] vfs_kern_mount+0xc5/0x14e [<c1095a03>] do_kern_mount+0x32/0xbd [<c10a811e>] do_mount+0x671/0x6d0 [<c1073794>] ? __get_free_pages+0x1f/0x21 [<c10a684f>] ? copy_mount_options+0x2b/0xe2 [<c107b634>] ? strndup_user+0x48/0x67 [<c10a81de>] sys_mount+0x61/0x8f [<c100280c>] sysenter_do_call+0x12/0x32 This ensures to set s_bdi for nilfs and fixes the sync silent failure. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Acked-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Kees Cook authored
commit 4ae69e6b upstream. Redirecting directly to lsm, here's the patch discussed on lkml: http://lkml.org/lkml/2010/4/22/219 The mmap_min_addr value is useful information for an admin to see without being root ("is my system vulnerable to kernel NULL pointer attacks?") and its setting is trivially easy for an attacker to determine by calling mmap() in PAGE_SIZE increments starting at 0, so trying to keep it private has no value. Only require CAP_SYS_RAWIO if changing the value, not reading it. Comment from Serge : Me, I like to write my passwords with light blue pen on dark blue paper, pasted on my window - if you're going to get my password, you're gonna get a headache. Signed-off-by:
Kees Cook <kees.cook@canonical.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> (cherry picked from commit 822cceec ) Signed-off-by:
-
David Howells authored
commit 7ac512aa upstream. cachefiles_determine_cache_security() is expected to return with a security override in place. However, if set_create_files_as() fails, we fail to do this. In this case, we should just reinstate the security override that was set by the caller. Furthermore, if set_create_files_as() fails, we should dispose of the new credentials we were in the process of creating. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Wey-Yi Guy authored
commit a9e10fb9 upstream. All the queues are awake and ready to use after loading firmware, for firmware reload case, if any queues was stopped before reload, mac80211 will wake those queues after restart hardware, so make sure all the flag used to keep track of the queue status are reset correctly. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
commit 45d42700 upstream. Error checking for aggregation frames should go into aggregation queue, if aggregation queue not available, use legacy queue instead. Also make sure the aggregation queue is available to activate, if driver and mac80211 is out-of-sync, try to disable the queue and sync-up with mac80211. Signed-off-by:
-
Robert Hooker authored
commit 8d06a1e1 upstream. It is causing hangs after a suspend/resume cycle with the default powersave=1 module option on these chipsets since 2.6.32-rc. BugLink: http://bugs.launchpad.net/bugs/492392 Signed-off-by:
Robert Hooker <sarvatt@ubuntu.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Vitaliy Kulikov authored
commit c602c8ad upstream. Added a PCI controller id on new Dell laptops. Signed-off-by:
Vitaliy Kulikov <Vitaliy.Kulikov@idt.com> Cc: AmenophisIII <AmenophisIII@gmx.at> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Dan Rosenberg authored
commit 5dc64164 upstream. The existing code would have allowed you to clone a file that was only open for writing Signed-off-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Andreas Herrmann authored
commit f0148711 upstream. If host CPU is exposed to a guest the OSVW MSRs are not guaranteed to be present and a GP fault occurs. Thus checking the feature flag is essential. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20100427101348.GC4489@alberich.amd.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Frank Arnold authored
commit 7f284d3c upstream. When running a quest kernel on xen we get: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df PGD 0 Oops: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: G W 2.6.34-rc3 #1 /HVM domU RIP: 0010:[<ffffffff8142f2fb>] [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x 2ca/0x3df RSP: 0018:ffff880002203e08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000060 RDX: 0000000000000000 RSI: 0000000000000040 RDI: 0000000000000000 RBP: ffff880002203ed8 R08: 00000000000017c0 R09: ffff880002203e38 R10: ffff8800023d5d40 R11: ffffffff81a01e28 R12: ffff880187e6f5c0 R13: ffff880002203e34 R14: ffff880002203e58 R15: ffff880002203e68 FS: 0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000038 CR3: 0000000001a3c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a44020) Stack: ffffffff810d7ecb ffff880002203e20 ffffffff81059140 ffff880002203e30 <0> ffffffff810d7ec9 0000000002203e40 000000000050d140 ffff880002203e70 <0> 0000000002008140 0000000000000086 ffff880040020140 ffffffff81068b8b Call Trace: <IRQ> [<ffffffff810d7ecb>] ? sync_supers_timer_fn+0x0/0x1c [<ffffffff81059140>] ? mod_timer+0x23/0x25 [<ffffffff810d7ec9>] ? arm_supers_timer+0x34/0x36 [<ffffffff81068b8b>] ? hrtimer_get_next_event+0xa7/0xc3 [<ffffffff81058e85>] ? get_next_timer_interrupt+0x19a/0x20d [<ffffffff8142fa23>] get_cpu_leaves+0x5c/0x232 [<ffffffff8106a7b1>] ? sched_clock_local+0x1c/0x82 [<ffffffff8106a9a0>] ? sched_clock_tick+0x75/0x7a [<ffffffff8107748c>] generic_smp_call_function_single_interrupt+0xae/0xd0 [<ffffffff8101f6ef>] smp_call_function_single_interrupt+0x18/0x27 [<ffffffff8100a773>] call_function_single_interrupt+0x13/0x20 <EOI> [<ffffffff8143c468>] ? notifier_call_chain+0x14/0x63 [<ffffffff810295c6>] ? native_safe_halt+0xc/0xd [<ffffffff810114eb>] ? default_idle+0x36/0x53 [<ffffffff81008c22>] cpu_idle+0xaa/0xe4 [<ffffffff81423a9a>] rest_init+0x7e/0x80 [<ffffffff81b10dd2>] start_kernel+0x40e/0x419 [<ffffffff81b102c8>] x86_64_start_reservations+0xb3/0xb7 [<ffffffff81b103c4>] x86_64_start_kernel+0xf8/0x107 Code: 14 d5 40 ff ae 81 8b 14 02 31 c0 3b 15 47 1c 8b 00 7d 0e 48 8b 05 36 1c 8b 00 48 63 d2 48 8b 04 d0 c7 85 5c ff ff ff 00 00 00 00 <8b> 70 38 48 8d 8d 5c ff ff ff 48 8b 78 10 ba c4 01 00 00 e8 eb RIP [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df RSP <ffff880002203e08> CR2: 0000000000000038 ---[ end trace a7919e7f17c0a726 ]--- The L3 cache index disable feature of AMD CPUs has to be disabled if the kernel is running as guest on top of a hypervisor because northbridge devices are not available to the guest. Currently, this fixes a boot crash on top of Xen. In the future this will become an issue on KVM as well. Check if northbridge devices are present and do not enable the feature if there are none. [ hpa: backported to 2.6.34 ] Signed-off-by:
Frank Arnold <frank.arnold@amd.com> LKML-Reference: <1271945222-5283-3-git-send-email-bp@amd64.org> Acked-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Borislav Petkov authored
commit ade029e2 upstream. K8_NB depends on PCI and when the last is disabled (allnoconfig) we fail at the final linking stage due to missing exported num_k8_northbridges. Add a header stub for that. Signed-off-by:
-
Hugh Dickins authored
commit 16a2164b upstream. If the kernel is large or the profiling step small, /proc/profile leaks data and readprofile shows silly stats, until readprofile -r has reset the buffer: clear the prof_buffer when it is vmalloc()ed. Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Pavel Emelyanov authored
commit b3b38d84 upstream. inotify_new_group() receives a get_uid-ed user_struct and saves the reference on group->inotify_data.user. The problem is that free_uid() is never called on it. Issue seem to be introduced by 63c882a0 (inotify: reimplement inotify using fsnotify) after 2.6.30. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Eric Paris <eparis@parisplace.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Eric Paris authored
commit e0873344 upstream. There is a race in the inotify add/rm watch code. A task can find and remove a mark which doesn't have all of it's references. This can result in a use after free/double free situation. Task A Task B ------------ ----------- inotify_new_watch() allocate a mark (refcnt == 1) add it to the idr inotify_rm_watch() inotify_remove_from_idr() fsnotify_put_mark() refcnt hits 0, free take reference because we are on idr [at this point it is a use after free] [time goes on] refcnt may hit 0 again, double free The fix is to take the reference BEFORE the object can be found in the idr. Signed-off-by:
-
Daniel T Chen authored
commit 0ebf9e36 upstream. Reference: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-May/027525.html As reported on the mailing list, we also need to cap to the 0 dB offset for Lenovo models, else the sound will be distorted. Reported-and-Tested-by:
Tim Starling <tstarling@wikimedia.org> Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
-
Clemens Ladisch authored
commit 6a45f782 upstream. Commit 65c3ac88 in 2.6.33 accidentally left out the initialization of the AC97 codec FMIC2MIC bit, which broke recording from the front panel microphone. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Takashi Iwai authored
commit 82134665 upstream. The capture source control of maya44 was wrongly coded with the bit shift instead of the bit mask. Also, the slot for line-in was wrongly assigned (slot 5 instead of 4). Reported-by:
Alex Chernyshoff <alexdsp@gmail.com> Signed-off-by:
-
Alan Cox authored
commit 77945feb upstream. Arnd noted: After the "retry_open:" label, we first get the tty_mutex and then the BKL. However a the end of tty_open, we jump back to retry_open with the BKL still held. If we run into this case, the tty_open function will be left with the BKL still held. Signed-off-by:
Alan Cox <alan@linux.intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Valentin Longchamp authored
commit 1c5250d6 upstream. The imx CTS trigger level is left at its reset value that is 32 chars. Since the RX FIFO has 32 entries, when CTS is raised, the FIFO already is full. However, some serial port devices first empty their TX FIFO before stopping when CTS is raised, resulting in lost chars. This patch sets the trigger level lower so that other chars arrive after CTS is raised, there is still room for 16 of them. Signed-off-by:
Valentin <Longchamp<valentin.longchamp@epfl.ch> Tested-by:
Philippe <Rétornaz<philippe.retornaz@epfl.ch> Acked-by:
Wolfram <Sang<w.sang@pengutronix.de> Signed-off-by:
-
Jeff Layton authored
commit 3d694380 upstream. When we made serverino the default, we trusted that the field sent by the server in the "uniqueid" field was actually unique. It turns out that it isn't reliably so. Samba, in particular, will just put the st_ino in the uniqueid field when unix extensions are enabled. When a share spans multiple filesystems, it's quite possible that there will be collisions. This is a server bug, but when the inodes in question are a directory (as is often the case) and there is a collision with the root inode of the mount, the result is a kernel panic on umount. Fix this by checking explicitly for directory inodes with the same uniqueid. If that is the case, then we can assume that using server inode numbers will be a problem and that they should be disabled. Fixes Samba bugzilla 7407 Signed-off-by:
Jeff Layton <jlayton@redhat.com> Reviewed-and-Tested-by:
Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Paul Mackerras authored
commit 0fe1ac48 upstream. Anton Blanchard found that large POWER systems would occasionally crash in the exception exit path when profiling with perf_events. The symptom was that an interrupt would occur late in the exit path when the MSR[RI] (recoverable interrupt) bit was clear. Interrupts should be hard-disabled at this point but they were enabled. Because the interrupt was not recoverable the system panicked. The reason is that the exception exit path was calling perf_event_do_pending after hard-disabling interrupts, and perf_event_do_pending will re-enable interrupts. The simplest and cleanest fix for this is to use the same mechanism that 32-bit powerpc does, namely to cause a self-IPI by setting the decrementer to 1. This means we can remove the tests in the exception exit path and raw_local_irq_restore. This also makes sure that the call to perf_event_do_pending from timer_interrupt() happens within irq_enter/irq_exit. (Note that calling perf_event_do_pending from timer_interrupt does not mean that there is a possible 1/HZ latency; setting the decrementer to 1 ensures that the timer interrupt will happen immediately, i.e. within one timebase tick, which is a few nanoseconds or 10s of nanoseconds.) Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Stefan Weinhuber authored
commit 1c1e093c upstream. The various dasd_sleep_on functions use a global wait queue when waiting for a cqr. The wait condition checks the status and devlist fields of the cqr to determine if it is safe to continue. This evaluation may return true, although the tasklet has not finished processing of the cqr and the callback function has not been called yet. When the callback is finally called, the data in the cqr may already be invalid. The sleep_on wait condition needs a safe way to determine if the tasklet has finished processing. Use the callback_data field of the cqr to store a token, which is set by the callback function itself. Signed-off-by:
Stefan Weinhuber <wein@de.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Gerald Schaefer authored
commit 545c174d upstream. strace may change the system call number, so regs->gprs[2] must not be read before tracehook_report_syscall_entry(). This fixes a bug where "strace -f" will hang after a vfork(). Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Jesse Barnes authored
commit 1918ad77 upstream. My PIPE_CONTROL fix (just sent via Eric's tree) was buggy; I was testing a whole set of patches together and missed a conversion to the new HAS_PIPE_CONTROL macro, which will cause breakage on non-Ironlake 965 class chips. Fortunately, the fix is trivial and has been tested. Be sure to use the HAS_PIPE_CONTROL macro in i915_get_gem_seqno, or we'll end up reading the wrong graphics memory, likely causing hangs, crashes, or worse. Reported-by:
Zdenek Kabelac <zdenek.kabelac@gmail.com> Reported-by:
Toralf Förster <toralf.foerster@gmx.de> Tested-by:
-
Jesse Barnes authored
commit e552eb70 upstream. Since 965, the hardware has supported the PIPE_CONTROL command, which provides fine grained GPU cache flushing control. On recent chipsets, this instruction is required for reliable interrupt and sequence number reporting in the driver. So add support for this instruction, including workarounds, on Ironlake and Sandy Bridge hardware. https://bugs.freedesktop.org/show_bug.cgi?id=27108 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Nicolas Ferre authored
commit abc2c9fd upstream. Disable data error interrupts while we are actually recording that there is not such errors. This will prevent, in some cases, the warning message printed at new request queuing (in atmci_start_request()). Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Nicolas Ferre authored
commit 009a891b upstream. The removing of an SD card in certain circumstances can lead to a kernel oops if we do not make sure that the "data" field of the host structure is valid. This patch adds a test in atmci_dma_cleanup() function and also calls atmci_stop_dma() before throwing away the reference to data. Signed-off-by:
-
Nicolas Ferre authored
commit ebb1fea9 upstream. Two parameters were swapped in the calls to atmci_init_slot(). Signed-off-by:
Anders Grahn <anders.grahn@hd-wireless.se> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Alex Chiang authored
commit 7d6fb7bd upstream. Duplicate entries ended up acpisleep_dmi_table[] by accident. They don't hurt functionality, but they are ugly, so let's get rid of them. Signed-off-by:
Alex Chiang <achiang@canonical.com> Signed-off-by:
-
Wu Fengguang authored
commit 4d26f446 upstream. This reverts part of commit 52dc4386 , in order to fix a regression: broken SPDIF output on Intel DG45FC motherboard (IDT 92HD73E1X5 codec). --- DG45FC-IDT-codec-2.6.32 (SPDIF OK) +++ DG45FC-IDT-codec-2.6.33 (SPDIF broken) Node 0x22 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x00000010: OUT - Pin Default 0x40f000f0: [N/A] Other at Ext N/A - Conn = Unknown, Color = Unknown - DefAssociation = 0xf, Sequence = 0x0 - Pin-ctls: 0x00: + Pin Default 0x014510a0: [Jack] SPDIF Out at Ext Rear + Conn = Optical, Color = Black + DefAssociation = 0xa, Sequence = 0x0 + Pin-ctls: 0x40: OUT Connection: 3 0x25* 0x20 0x21 Node 0x23 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x00000010: OUT - Pin Default 0x01451140: [Jack] SPDIF Out at Ext Rear + Pin Default 0x074510b0: [Jack] SPDIF Out at Ext Rear Panel Conn = Optical, Color = Black - DefAssociation = 0x4, Sequence = 0x0 - Misc = NO_PRESENCE - Pin-ctls: 0x40: OUT + DefAssociation = 0xb, Sequence = 0x0 + Pin-ctls: 0x00: Connection: 3 0x26* 0x20 0x21 Cc: Alexey Fisher <bug-track@fisher-privat.net> Tested-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
Robin Holt authored
commit 34441427 upstream. Originally, commit d899bf7b ("procfs: provide stack information for threads") attempted to introduce a new feature for showing where the threadstack was located and how many pages are being utilized by the stack. Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was applied to fix the NO_MMU case. Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on 64-bit") was applied to fix a bug in ia32 executables being loaded. Commit 9ebd4eba ("procfs: fix /proc/<pid>/stat stack pointer for kernel threads") was applied to fix a bug which had kernel threads printing a userland stack address. Commit 1306d603 ('proc: partially revert "procfs: provide stack information for threads"') was then applied to revert the stack pages being used to solve a significant performance regression. This patch nearly undoes the effect of all these patches. The reason for reverting these is it provides an unusable value in field 28. For x86_64, a fork will result in the task->stack_start value being updated to the current user top of stack and not the stack start address. This unpredictability of the stack_start value makes it worthless. That includes the intended use of showing how much stack space a thread has. Other architectures will get different values. As an example, ia64 gets 0. The do_fork() and copy_process() functions appear to treat the stack_start and stack_size parameters as architecture specific. I only partially reverted c44972f1 ("procfs: disable per-task stack usage on NOMMU") . If I had completely reverted it, I would have had to change mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is configured. Since I could not test the builds without significant effort, I decided to not change mm/Makefile. I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on 64-bit") . I left the KSTK_ESP() change in place as that seemed worthwhile. Signed-off-by:
Robin Holt <holt@sgi.com> Cc: Stefani Seibold <stefani@seibold.net> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Stefan Lippers-Hollmann authored
commit 482c4533 upstream. This reverts commit 7aee6746 . As it doesn't seem to be universally valid for all mainboard revisions of the D945GCLF2 and breaks snd-hda-intel/ snd-hda-codec-realtek on the Intel Corporation "D945GCLF2" (LF94510J.86A.0229.2009.0729.0209) mainboard. 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 01) Signed-off-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
-
FUJITA Tomonori authored
commit f33d7e2d upstream. dma_sync_single_range_for_cpu() and dma_sync_single_range_for_device() use a wrong address with a partial synchronization. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Mel Gorman authored
commit 4a6018f7 upstream. Ordinarily, application using hugetlbfs will create mappings with reserves. For shared mappings, these pages are reserved before mmap() returns success and for private mappings, the caller process is guaranteed and a child process that cannot get the pages gets killed with sigbus. An application that uses MAP_NORESERVE gets no reservations and mmap() will always succeed at the risk the page will not be available at fault time. This might be used for example on very large sparse mappings where the developer is confident the necessary huge pages exist to satisfy all faults even though the whole mapping cannot be backed by huge pages. Unfortunately, if an allocation does fail, VM_FAULT_OOM is returned to the fault handler which proceeds to trigger the OOM-killer. This is unhelpful. Even without hugetlbfs mounted, a user using mmap() can trivially trigger the OOM-killer because VM_FAULT_OOM is returned (will provide example program if desired - it's a whopping 24 lines long). It could be considered a DOS available to an unprivileged user. This patch alters hugetlbfs to kill a process that uses MAP_NORESERVE where huge pages were not available with SIGBUS instead of triggering the OOM killer. This change affects hugetlb_cow() as well. I feel there is a failure case in there, but I didn't create one. It would need a fairly specific target in terms of the faulting application and the hugepage pool size. The hugetlb_no_page() path is much easier to hit but both might as well be closed. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: David Rientjes <rientjes@google.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by:
-
Michael Hennerich authored
commit de145b44 upstream. The current allocation does not include the memory required for blanking lines. So avoid memory corruption when multiple devices are using the DMA memory near each other. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Oliver Neukum authored
commit 06efbeb4 upstream. The work queue has to be flushed after the device has been made inaccessible. The patch closes a window during which a work queue might remain active after the device is removed and would then lead to ACPI calls with undefined behavior. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Acked-by:
Eric Piel <eric.piel@tremplin-utc.net> Acked-by:
Pavel Machek <pavel@ucw.cz> Cc: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by:
-
Bjørn Mork authored
commit ccc2d97c upstream. commit 2783ef23 moved the initialisation of saddr and daddr after pskb_may_pull() to avoid a potential data corruption. Unfortunately also placing it after the short packet and bad checksum error paths, where these variables are used for logging. The result is bogus output like [92238.389505] UDP: short packet: From 2.0.0.0:65535 23715/178 to 0.0.0.0:65535 Moving the saddr and daddr initialisation above the error paths, while still keeping it after the pskb_may_pull() to keep the fix from commit 2783ef23 . Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
