- 26 Aug, 2010 37 commits
-
-
Rajkumar Manoharan authored
commit da93f106 upstream. This should fix the oops which occurs during the packet injection on monitor interface. EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc] [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211] [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc] [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211] [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211] [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211] [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211] [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210 [<c04b97c2>] ? __alloc_skb+0x52/0x130 [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170 [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0 [<c0567e1e>] ? packet_snd+0x21e/0x250 [<c05684a2>] ? packet_sendmsg+0x32/0x40 [<c04b4c63>] ? sock_aio_write+0x113/0x130 [<c0207934>] ? do_sync_write+0xc4/0x100 [<c0167740>] ? autoremove_wake_function+0x0/0x50 [<c02f4414>] ? security_file_permission+0x14/0x20 [<c0207ad4>] ? rw_verify_area+0x64/0xe0 [<c01e6458>] ? handle_mm_fault+0x338/0x390 [<c0207cd5>] ? vfs_write+0x185/0x1a0 [<c058db20>] ? do_page_fault+0x160/0x3a0 [<c0208512>] ? sys_write+0x42/0x70 [<c01033ec>] ? syscall_call+0x7/0xb Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Marek Vasut authored
commit ef56609f upstream. These two platforms didn't properly fill nr_chips in gen_nand registration and therefore depended on gen_nand bug fixed by by commit 81cbb0b1 ("mtd: gen_nand: fix support for multiple chips") Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Marek Vasut authored
commit ef077179 upstream. These three platforms didn't properly fill nr_chips in gen_nand registration and therefore depended on gen_nand bug fixed by commit 81cbb0b1 ("mtd: gen_nand: fix support for multiple chips") Signed-off-by:
-
Russell King authored
commit 41e2e8fd upstream. Reviewed-by:
Arve Hjønnevåg <arve@android.com> Acked-by:
Dima Zavin <dima@android.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Jean Delvare authored
commit b9783dce upstream. It's not OK to call platform_device_add_resources() multiple times in a row. Despite its name, this functions sets the resources, it doesn't add them. So we have to prepare an array with all the resources, and then call platform_device_add_resources() once. Before this fix, only the last I/O resource would be actually registered. The other I/O resources were leaked. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Jim Cromie <jim.cromie@gmail.com> Signed-off-by:
-
Dr. David Alan Gilbert authored
commit d8ab3557 upstream. This hasn't mattered up until the ioctl started using the value, and it fell apart. fixes fd.o 29340, Ubuntu LP 606081 [airlied: cleaned up whitespace and don't need an error before pushing] Signed-off-by:
Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 9ea2c4be upstream. HPD pins are reversed Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29387Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Jiaju Zhang authored
commit 845b6cf3 upstream. Hi, Thanks a lot for all the review and comments so far;) I'd like to send the improved (V4) version of this patch. This patch fixes a deadlock in OCFS2 ACL. We found this bug in OCFS2 and Samba integration using scenario, the symptom is several smbd processes will be hung under heavy workload. Finally we found out it is the nested PR lock calling that leads to this deadlock: node1 node2 gr PR | V PR(EX)---> BAST:OCFS2_LOCK_BLOCKED | V rq PR | V wait=1 After requesting the 2nd PR lock, the process "smbd" went into D state. It can only be woken up when the 1st PR lock's RO holder equals zero. There should be an ocfs2_inode_unlock in the calling path later on, which can decrement the RO holder. But since it has been in uninterruptible sleep, the unlock function has no chance to be called. The related stack trace is: smbd D ffff8800013d0600 0 9522 5608 0x00000000 ffff88002ca7fb18 0000000000000282 ffff88002f964500 ffff88002ca7fa98 ffff8800013d0600 ffff88002ca7fae0 ffff88002f964340 ffff88002f964340 ffff88002ca7ffd8 ffff88002ca7ffd8 ffff88002f964340 ffff88002f964340 Call Trace: [<ffffffff80350425>] schedule_timeout+0x175/0x210 [<ffffffff8034f580>] wait_for_common+0xf0/0x210 [<ffffffffa03e12b9>] __ocfs2_cluster_lock+0x3b9/0xa90 [ocfs2] [<ffffffffa03e7665>] ocfs2_inode_lock_full_nested+0x255/0xdb0 [ocfs2] [<ffffffffa0446019>] ocfs2_get_acl+0x69/0x120 [ocfs2] [<ffffffffa0446368>] ocfs2_check_acl+0x28/0x80 [ocfs2] [<ffffffff800e3507>] acl_permission_check+0x57/0xb0 [<ffffffff800e357d>] generic_permission+0x1d/0xc0 [<ffffffffa03eecea>] ocfs2_permission+0x10a/0x1d0 [ocfs2] [<ffffffff800e3f65>] inode_permission+0x45/0x100 [<ffffffff800d86b3>] sys_chdir+0x53/0x90 [<ffffffff80007458>] system_call_fastpath+0x16/0x1b [<00007f34a4ef6927>] 0x7f34a4ef6927 For details, please see: https://bugzilla.novell.com/show_bug.cgi?id=614332 and http://oss.oracle.com/bugzilla/show_bug.cgi?id=1278Signed-off-by:
Jiaju Zhang <jjzhang@suse.de> Acked-by:
Mark Fasheh <mfasheh@suse.com> Signed-off-by:
Joel Becker <joel.becker@oracle.com> Signed-off-by:
-
Daniel Kiper authored
commit 05e40760 upstream. Fix a boot crash when apic=debug is used and the APIC is not properly initialized. This issue appears during Xen Dom0 kernel boot but the fix is generic and the crash could occur on real hardware as well. Signed-off-by:
Daniel Kiper <dkiper@net-space.pl> Cc: xen-devel@lists.xensource.com Cc: konrad.wilk@oracle.com Cc: jeremy@goop.org LKML-Reference: <20100819224616.GB9967@router-fw-old.local.net-space.pl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Zhang, Yanmin authored
commit 351af072 upstream. Fix the Errata AAK100/AAP53/BD53 workaround, the officialy documented workaround we implemented in: 11164cd4: perf, x86: Add Nehelem PMU programming errata workaround doesn't actually work fully and causes a stuck PMU state under load and non-functioning perf profiling. A functional workaround was found by trial & error. Affects all Nehalem-class Intel PMUs. Signed-off-by:
Zhang Yanmin <yanmin_zhang@linux.intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1281073148.2125.63.camel@ymzhang.sh.intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Borislav Petkov authored
commit d7c53c9e upstream. When testing cpu hotplug code on 32-bit we kept hitting the "CPU%d: Stuck ??" message due to multiple cores concurrently accessing the cpu_callin_mask, among others. Since these codepaths are not protected from concurrent access due to the fact that there's no sane reason for making an already complex code unnecessarily more complex - we hit the issue only when insanely switching cores off- and online - serialize hotplugging cores on the sysfs level and be done with it. [ v2.1: fix !HOTPLUG_CPU build ] Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> LKML-Reference: <20100819181029.GC17171@aftab> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Victor van den Elzen authored
commit c3f755e3 upstream. Like others in the Mini series, the Dell Mini 1012 does not support the smbios hook required by dell-laptop. Signed-off-by:
Victor van den Elzen <victor.vde@gmail.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Eric W. Biederman authored
commit 5989cd6a upstream. This fixes a regression in 2.6.35 from 2.6.34, that is present for select models of Intel cpus when people are using an MP table. The commit cf7500c0 "x86, ioapic: In mpparse use mp_register_ioapic" started calling mp_register_ioapic from MP_ioapic_info. An extremely simple change that was obviously correct. Unfortunately mp_register_ioapic did just a little more than the previous hand crafted code and so we gained this call path. The problem call path is: MP_ioapic_info() mp_register_ioapic() io_apic_unique_id() io_apic_get_unique_id() get_physical_broadcast() modern_apic() lapic_get_version() apic_read(APIC_LVR) Which turned out to be a problem because the local apic was not mapped, at that point, unlike the similar point in the ACPI parsing code. This problem is fixed by mapping the local apic when parsing the mptable as soon as we reasonably can. Looking at the number of places we setup the fixmap for the local apic, I see some serious simplification opportunities. For the moment except for not duplicating the setting up of the fixmap in init_apic_mappings, I have not acted on them. The regression from 2.6.34 is tracked in bug https://bugzilla.kernel.org/show_bug.cgi?id=16173Reported-by:
David Hill <hilld@binarystorm.net> Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@sophos.com> Tested-by:
Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <m1eiee86jg.fsf_-_@fess.ebiederm.org> Signed-off-by:
-
Cyrill Gorcunov authored
commit 1c250d70 upstream. In case if last active performance counter is not overflowed at moment of NMI being triggered by another counter, the irq statistics may miss an update stage. As a more serious consequence -- apic quirk may not be triggered so apic lvt entry stay masked. Tested-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Cc: Stephane Eranian <eranian@google.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <20100805150917.GA6311@lenovo> Signed-off-by:
-
Luca Barbieri authored
commit 30246557 upstream. The old code didn't work on binutils 2.12 because setting a symbol to a register apparently requires a fairly recent version. This commit refactors the code to use the C preprocessor instead, and in the process makes the whole code a bit easier to understand. The object code produced is unchanged as expected. This fixes kernel bugzilla 16506. Reported-by:
Dieter Stussy <kd6lvw+software@kd6lvw.ampr.org> Signed-off-by:
Luca Barbieri <luca@luca-barbieri.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> LKML-Reference: <tip-*@git.kernel.org> Signed-off-by:
-
Johannes Berg authored
commit fe100acd upstream. Accesses to "wdev->current_bss" must be locked with the wdev lock, which action frame transmission is missing. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Huang Ying authored
commit 18fab912 upstream. With the configuration: CONFIG_DEBUG_PAGEALLOC=y and Shaohua's patch: [PATCH]x86: make spurious_fault check correct pte bit Function call graph trace with the following will trigger a page fault. # cd /sys/kernel/debug/tracing/ # echo function_graph > current_tracer # cat per_cpu/cpu1/trace_pipe_raw > /dev/null BUG: unable to handle kernel paging request at ffff880006e99000 IP: [<ffffffff81085572>] rb_event_length+0x1/0x3f PGD 1b19063 PUD 1b1d063 PMD 3f067 PTE 6e99160 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/virtual/net/lo/operstate CPU 1 Modules linked in: Pid: 1982, comm: cat Not tainted 2.6.35-rc6-aes+ #300 /Bochs RIP: 0010:[<ffffffff81085572>] [<ffffffff81085572>] rb_event_length+0x1/0x3f RSP: 0018:ffff880006475e38 EFLAGS: 00010006 RAX: 0000000000000ff0 RBX: ffff88000786c630 RCX: 000000000000001d RDX: ffff880006e98000 RSI: 0000000000000ff0 RDI: ffff880006e99000 RBP: ffff880006475eb8 R08: 000000145d7008bd R09: 0000000000000000 R10: 0000000000008000 R11: ffffffff815d9336 R12: ffff880006d08000 R13: ffff880006e605d8 R14: 0000000000000000 R15: 0000000000000018 FS: 00007f2b83e456f0(0000) GS:ffff880002100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff880006e99000 CR3: 00000000064a8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process cat (pid: 1982, threadinfo ffff880006474000, task ffff880006e40770) Stack: ffff880006475eb8 ffffffff8108730f 0000000000000ff0 000000145d7008bd <0> ffff880006e98010 ffff880006d08010 0000000000000296 ffff88000786c640 <0> ffffffff81002956 0000000000000000 ffff8800071f4680 ffff8800071f4680 Call Trace: [<ffffffff8108730f>] ? ring_buffer_read_page+0x15a/0x24a [<ffffffff81002956>] ? return_to_handler+0x15/0x2f [<ffffffff8108a575>] tracing_buffers_read+0xb9/0x164 [<ffffffff810debfe>] vfs_read+0xaf/0x150 [<ffffffff81002941>] return_to_handler+0x0/0x2f [<ffffffff810248b0>] __bad_area_nosemaphore+0x17e/0x1a1 [<ffffffff81002941>] return_to_handler+0x0/0x2f [<ffffffff810248e6>] bad_area_nosemaphore+0x13/0x15 Code: 80 25 b2 16 b3 00 fe c9 c3 55 48 89 e5 f0 80 0d a4 16 b3 00 02 c9 c3 55 31 c0 48 89 e5 48 83 3d 94 16 b3 00 01 c9 0f 94 c0 c3 55 <8a> 0f 48 89 e5 83 e1 1f b8 08 00 00 00 0f b6 d1 83 fa 1e 74 27 RIP [<ffffffff81085572>] rb_event_length+0x1/0x3f RSP <ffff880006475e38> CR2: ffff880006e99000 ---[ end trace a6877bb92ccb36bb ]--- The root cause is that ring_buffer_read_page() may read out of page boundary, because the boundary checking is done after reading. This is fixed via doing boundary checking before reading. Reported-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
Huang Ying <ying.huang@intel.com> LKML-Reference: <1280297641.2771.307.camel@yhuang-dev> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Shaohua Li authored
commit 575570f0 upstream. With CONFIG_DEBUG_PAGEALLOC, I observed an unallocated memory access in function_graph trace. It appears we find a small size entry in ring buffer, but we access it as a big size entry. The access overflows the page size and touches an unallocated page. Signed-off-by:
-
Ryusuke Konishi authored
commit af4e3631 upstream. If nilfs_attach_checkpoint() gets a memory allocation failure during creation of ifile, it will return without removing nilfs_sb_info struct from ns_supers list. When a concurrently mounted snapshot is unmounted or another new snapshot is mounted after that, this causes kernel oops as below: > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [<f83662ff>] nilfs_find_sbinfo+0x74/0xa4 [nilfs2] > *pde = 00000000 > Oops: 0000 [#1] SMP <snip> > Call Trace: > [<f835dc29>] ? nilfs_get_sb+0x165/0x532 [nilfs2] > [<c1173c87>] ? ida_get_new_above+0x16d/0x187 > [<c109a7f8>] ? alloc_vfsmnt+0x7e/0x10a > [<c1070790>] ? kstrdup+0x2c/0x40 > [<c1089041>] ? vfs_kern_mount+0x96/0x14e > [<c108913d>] ? do_kern_mount+0x32/0xbd > [<c109b331>] ? do_mount+0x642/0x6a1 > [<c101a415>] ? do_page_fault+0x0/0x2d1 > [<c1099c00>] ? copy_mount_options+0x80/0xe2 > [<c10705d8>] ? strndup_user+0x48/0x67 > [<c109b3f1>] ? sys_mount+0x61/0x90 > [<c10027cc>] ? sysenter_do_call+0x12/0x22 This fixes the problem. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
-
Yuri Kululin authored
commit fe0dbcc9 upstream. Use appropriate command (CMD_TRIGGER_SCAN_TO) instead of scan command (CMD_SCAN) to configure trigger scan timeout. This was broken in commit 3a98c30f. This fix address the bug reported here: https://bugzilla.kernel.org/show_bug.cgi?id=16554Signed-off-by:
Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
Yuri Kululin <ext-yuri.kululin@nokia.com> Acked-by:
Kalle Valo <kvalo@adurom.com> Signed-off-by:
-
Wengang Wang authored
commit b11f1f1a upstream. When we need to take both dlm_domain_lock and dlm->spinlock, we should take them in order of: dlm_domain_lock then dlm->spinlock. There is pathes disobey this order. That is calling dlm_lockres_put() with dlm->spinlock held in dlm_run_purge_list. dlm_lockres_put() calls dlm_put() at the ref and dlm_put() locks on dlm_domain_lock. Fix: Don't grab/put the dlm when the initialising/releasing lockres. That grab is not required because we don't call dlm_unregister_domain() based on refcount. Signed-off-by:
Wengang Wang <wen.gang.wang@oracle.com> Signed-off-by:
-
Wengang Wang authored
commit a524812b upstream. In the following situation, there remains an incorrect bit in refmap on the recovery master. Finally the recovery master will fail at purging the lockres due to the incorrect bit in refmap. 1) node A has no interest on lockres A any longer, so it is purging it. 2) the owner of lockres A is node B, so node A is sending de-ref message to node B. 3) at this time, node B crashed. node C becomes the recovery master. it recovers lockres A(because the master is the dead node B). 4) node A migrated lockres A to node C with a refbit there. 5) node A failed to send de-ref message to node B because it crashed. The failure is ignored. no other action is done for lockres A any more. For mormal, re-send the deref message to it to recovery master can fix it. Well, ignoring the failure of deref to the original master and not recovering the lockres to recovery master has the same effect. And the later is simpler. Signed-off-by:
Srinivas Eeda <srinivas.eeda@oracle.com> Signed-off-by:
-
Tao Ma authored
commit 8a2e70c4 upstream. The refcount record calculation in ocfs2_calc_refcount_meta_credits is too optimistic that we can always allocate contiguous clusters and handle an already existed refcount rec as a whole. Actually because of file system fragmentation, we may have the chance to split a refcount record into 3 parts during the transaction. So consider the worst case in record calculation. Signed-off-by:
Tao Ma <tao.ma@oracle.com> Signed-off-by:
-
Srinivas Eeda authored
commit 7beaf243 upstream. This patch fixes two problems in dlm_run_purgelist 1. If a lockres is found to be in use, dlm_run_purgelist keeps trying to purge the same lockres instead of trying the next lockres. 2. When a lockres is found unused, dlm_run_purgelist releases lockres spinlock before setting DLM_LOCK_RES_DROPPING_REF and calls dlm_purge_lockres. spinlock is reacquired but in this window lockres can get reused. This leads to BUG. This patch modifies dlm_run_purgelist to skip lockres if it's in use and purge next lockres. It also sets DLM_LOCK_RES_DROPPING_REF before releasing the lockres spinlock protecting it from getting reused. Signed-off-by:
Sunil Mushran <sunil.mushran@oracle.com> Signed-off-by:
-
Wengang Wang authored
commit 6d98c3cc upstream. When we have to take both dlm->master_lock and lockres->spinlock, take them in order lockres->spinlock and then dlm->master_lock. The patch fixes a violation of the rule. We can simply move taking dlm->master_lock to where we have dropped res->spinlock since when we access res->state and free mle memory we don't need master_lock's protection. Signed-off-by:
-
Tiger Yang authored
commit 6eda3dd3 upstream. Setting the acl while creating a new inode depends on the error codes of posix_acl_create_masq. This patch fix a issue of overwriting the error codes of it. Reported-by:
Pawel Zawora <pzawora@gmail.com> Signed-off-by:
Tiger Yang <tiger.yang@oracle.com> Signed-off-by:
-
Takashi Iwai authored
commit c3e68fad upstream. model=dell-vostro is needed for Dell Vostro 1220 with Coexnat 5067. Reference: Novell bnc#631066 https://bugzilla.novell.com/show_bug.cgi?id=631066Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jonathan Woithe authored
commit 53bacfbb upstream. I discovered tonight that ALSA no longer sets up a stream for the second ADC provided by the Realtek ALC260 HDA codec. At some point alc_build_pcms() started using stream_analog_alt_capture when constructing the second ADC stream, but patch_alc260() was never updated accordingly. I have no idea when this regression occurred. The trivial patch to patch_alc260() given below fixes the problem as far as I can tell. The patch is against 2.6.35. Signed-off-by:
Jonathan Woithe <jwoithe@physics.adelaide.edu.au> Signed-off-by:
-
Jaroslav Kysela authored
commit 56385a12 upstream. With some hardware combinations, the PCM interrupts are acknowledged before the period boundary from the emu10k1 chip. The midlevel PCM code gets confused and the playback stream is interrupted. It seems that the interrupt processing shift by 2 samples is enough to fix this issue. This default value does not harm other, non-affected hardware. More information: Kernel bugzilla bug#16300 [A copmile warning fixed by tiwai] Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Takashi Iwai authored
commit a5ba6beb upstream. The detection and loading of firmeware on riptide driver has been broken due to rewrite of some codes, checking the presense wrongly. This patch fixes the logic again. Reference: kernel bug 16596 https://bugzilla.kernel.org/show_bug.cgi?id=16596Signed-off-by:
-
Joonyoung Shim authored
commit c4604e49 upstream. This ensures that if the GPIO was not enabled prior to the driver starting the regulator API will insert the required powerup ramp delay when it enables the regulator. The gpiolib API does not provide this information. [Rewrote changelog to describe the actual change -- broonie.] Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Cliff Cai authored
commit ac770267 upstream. Signed-off-by:
Cliff Cai <cliff.cai@analog.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Acked-by:
-
Mark Brown authored
commit b2c1e07b upstream. This is not supported by current hardware revisions. Signed-off-by:
-
Mark Brown authored
commit 4f0ed9a5 upstream. Signed-off-by:
-
Thomas Gleixner authored
commit 0a7992c9 upstream. The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d1 (ACPICA: add preemption point after each opcode parse). The follow up commits abe1dfab, 138d1569, c084ca70 tried to fix the preemption logic back and forth, but nobody noticed that the usage of in_atomic_preempt_off() in that context is wrong. The check which guards the call of cond_resched() is: if (!in_atomic_preempt_off() && !irqs_disabled()) in_atomic_preempt_off() is not intended for general use as the comment above the macro definition clearly says: * Check whether we were atomic before we did preempt_disable(): * (used by the scheduler, *after* releasing the kernel lock) On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by accident, but with CONFIG_PREEMPT=y it's just broken. The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210 [akpm@linux-foundation.org: fix build] Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Len Brown <lenb@kernel.org> Cc: Francois Valenduc <francois.valenduc@tvcablenet.be> Cc: Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Maxim Levitsky authored
commit d862b13b upstream. mspro_block_remove() is called from detect thread that first calls the mspro_block_stop(), which stops the request queue. If we call del_gendisk() with the queue stopped we get a deadlock. Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
-
Maxim Levitsky authored
commit 21fd0495 upstream. Otherwise lockdep complains. Signed-off-by:
-
- 20 Aug, 2010 3 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This fixes a build error reported in vmware.c due to commit 9f242dc1Reported-by:
Sven Joachim <svenjoac@gmx.de> Cc: Alok Kataria <akataria@vmware.com> Signed-off-by:
-
Linus Torvalds authored
commit d7824370 upstream. This commit makes the stack guard page somewhat less visible to user space. It does this by: - not showing the guard page in /proc/<pid>/maps It looks like lvm-tools will actually read /proc/self/maps to figure out where all its mappings are, and effectively do a specialized "mlockall()" in user space. By not showing the guard page as part of the mapping (by just adding PAGE_SIZE to the start for grows-up pages), lvm-tools ends up not being aware of it. - by also teaching the _real_ mlock() functionality not to try to lock the guard page. That would just expand the mapping down to create a new guard page, so there really is no point in trying to lock it in place. It would perhaps be nice to show the guard page specially in /proc/<pid>/maps (or at least mark grow-down segments some way), but let's not open ourselves up to more breakage by user space from programs that depends on the exact deails of the 'maps' file. Special thanks to Henrique de Moraes Holschuh for diving into lvm-tools source code to see what was going on with the whole new warning. Reported-and-tested-by: François Valenduc <francois.valenduc@tvcablenet.be Reported-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
-
