Added arm definitions in buildtar by AlinaNova21 · Pull Request #1 · mtx512/linux-imx

AlinaNova21 · 2013-11-11T21:44:06Z

Added armhf and armel to buildtar so that running make targz-pkg will properly grab the uImage

…x_3.0.35_4.1.0-udoo

If platform data provides -EINVAL for gpio_reset field, the below crash can be observed. -------------------cut-------------------- Unable to handle kernel paging request at virtual address 0009012f pgd = c0004000 [0009012f] *pgd=00000000 Internal error: Oops: 5 [#1] SMP Modules linked in: CPU: 0 Not tainted (3.0.35-cm-fx6-02054-g6dfb446-dirty #77) PC is at gpio_set_value_cansleep+0x1c/0x34 LR is at 0x900ff pc : [<c027db50>] lr : [<000900ff>] psr: 20000013 sp : e9fdded8 ip : ffffffea fp : 00000000 r10: 00000000 r9 : 00000000 r8 : ffffffea r7 : ffffffea r6 : c07560dc r5 : e9ce6480 r4 : ffffffea r3 : c07a0e00 r2 : 00000001 r1 : 00000001 r0 : ffffffbe Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000015 Process swapper (pid: 1, stack limit = 0xe9fdc2f0) Stack: (0xe9fdded8 to 0xe9fde000) dec0: e9d9ed20 c02a41f8 dee0: e9d99600 c05786fc e9d99600 e9d99608 c07661d4 c0000000 c07a4ffc c07661d4 df00: e9d99600 c02e2730 c07661d4 c0341814 c03417fc c02e25d4 e9d99600 c07661d4 df20: e9d99634 c02e2730 c001ccf4 c02e2718 00000000 e9d99600 c07661d4 c02e27bc df40: c07661d4 00000000 e9fddf50 c02e1dd0 e9e5f79c e9d9ed54 c075966c c07661d4 df60: c076fab8 e9eb4e60 00000000 c02e15dc c06a1d80 c078a5a0 c078a5a0 c07661d4 df80: 00000000 00000000 c001ccf4 00000000 00000000 c02e2da8 c078a5a0 c0032dd0 dfa0: c004695c 00000000 c001ccf4 c003f4d0 00000000 c0140000 00000000 c0758880 dfc0: 000001f0 c004695c c0032bb8 c0032dd0 c004695c 00000013 00000000 00000000 dfe0: 00000000 c0008454 00000000 00000000 c000839c c004695c 29040e94 950b8a00 [<c027db50>] (gpio_set_value_cansleep+0x1c/0x34) from [<c02a41f8>] (scf0403_gpio_reset+0x10/0x44) [<c02a41f8>] (scf0403_gpio_reset+0x10/0x44) from [<c05786fc>] (scf0403_probe+0xe0/0x1dc) [<c05786fc>] (scf0403_probe+0xe0/0x1dc) from [<c0341814>] (spi_drv_probe+0x18/0x1c) [<c0341814>] (spi_drv_probe+0x18/0x1c) from [<c02e25d4>] (really_probe+0x64/0x160) [<c02e25d4>] (really_probe+0x64/0x160) from [<c02e2718>] (driver_probe_device+0x48/0x60) [<c02e2718>] (driver_probe_device+0x48/0x60) from [<c02e27bc>] (__driver_attach+0x8c/0x90) [<c02e27bc>] (__driver_attach+0x8c/0x90) from [<c02e1dd0>] (bus_for_each_dev+0x60/0x8c) [<c02e1dd0>] (bus_for_each_dev+0x60/0x8c) from [<c02e15dc>] (bus_add_driver+0xa8/0x298) [<c02e15dc>] (bus_add_driver+0xa8/0x298) from [<c02e2da8>] (driver_register+0x78/0x18c) [<c02e2da8>] (driver_register+0x78/0x18c) from [<c003f4d0>] (do_one_initcall+0x34/0x180) [<c003f4d0>] (do_one_initcall+0x34/0x180) from [<c0008454>] (kernel_init+0xb8/0x148) [<c0008454>] (kernel_init+0xb8/0x148) from [<c004695c>] (kernel_thread_exit+0x0/0x8) Code: e0800080 e34c307a e1a02001 e793e100 (e59e1030) ---[ end trace 65f8ea860415c04f ]--- Kernel panic - not syncing: Attempted to kill init! ----------------------cut-------------- Fix the above crash by checking if the GPIO is valid before toggling. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>

Having the 4 IPU tasks blocked on wait_event artificially inflates the load average by 4. wait_event_interruptible should be an acceptable alternative.

Errata Titles: i103: Delay needed to read some GP timer, WD timer and sync timer registers after wakeup (OMAP3/4) i767: Delay needed to read some GP timer registers after wakeup (OMAP5) Description (i103/i767): If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1), due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2 registers right after the timer interface clock (L4) goes from stopped to active may not return the expected values. The most common event leading to this situation occurs upon wake up from idle. GPTimer non-posted synchronization mode is not impacted by this limitation. Workarounds: 1). Disable posted mode 2). Use static dependency between timer clock domain and MPUSS clock domain 3). Use no-idle mode when the timer is active Workarounds imx6-dongle#2 and imx6-dongle#3 are not pratical from a power standpoint and so workaround #1 has been implemented. Disabling posted mode adds some CPU overhead for configuring and reading the timers as the CPU has to wait for accesses to be re-synchronised within the timer. However, disabling posted mode guarantees correct operation. Please note that it is safe to use posted mode for timers if the counter (TCRR) and capture (TCARx) registers will never be read. An example of this is the clock-event system timer. This is used by the kernel to schedule events however, the timers counter is never read and capture registers are not used. Given that the kernel configures this timer often yet never reads the counter register it is safe to enable posted mode in this case. Hence, for the timer used for kernel clock-events, posted mode is enabled by overriding the errata for devices that are impacted by this defect. For drivers using the timers that do not read the counter or capture registers and wish to use posted mode, can override the errata and enable posted mode by making the following function calls. __omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767); __omap_dm_timer_enable_posted(timer); Both dmtimers and watchdogs are impacted by this defect this patch only implements the workaround for the dmtimer. Currently the watchdog driver does not read the counter register and so no workaround is necessary. Posted mode will be disabled for all OMAP2+ devices (including AM33xx) using a GP timer as a clock-source timer to guarantee correct operation. This is not necessary for OMAP24xx devices but the default clock-source timer for OMAP24xx devices is the 32k-sync timer and not the GP timer and so should not have any impact. This should be re-visited for future devices if this errata is fixed. Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

A number of Huawei 3G and LTE modems implement a CDC NCM function, including the necessary functional descriptors, but using a non standard interface layout and class/subclass/protocol codes. These devices can be handled by this driver with only a minor change to the probing logic, allowing a single combined control and data interface. This works because the devices - include a CDC Union descriptor labelling the combined interface as both master and slave, and - have an alternate setting #1 for the bulk endpoints on the combined interface. The 3G/LTE network connection is managed by vendor specific AT commands on a serial function in the same composite device. Handling the managment function is out of the scope of this driver. It will be handled by an appropriate USB serial driver. Reported-and-Tested-by: Olof Ermis <olof.ermis@gmail.com> Reported-and-Tested-by: Tommy Cheng <tommy7765@yahoo.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>

The 3215 console always has the RAW3215_FIXED flag set, which causes raw3215_shutdown() not to wait for outstanding I/O requests if an attached tty gets closed. The flag however can be simply removed, so we can guarantee that all requests belonging to the tty have been processed when the tty is closed. However the tasklet that belongs to the 3215 device may be scheduled even if there is no tty attached anymore, since we have a race between console and tty processing. Thefore unconditional tty_wakekup() in raw3215_wakeup() can cause the following NULL pointer dereference: 3.465368 Unable to handle kernel pointer dereference at virtual kernel address (null) 3.465448 Oops: 0004 #1 SMP 3.465454 Modules linked in: 3.465459 CPU: 1 Not tainted 3.6.0 #1 3.465462 Process swapper/1 (pid: 0, task: 000000003ffa4428, ksp: 000000003ffb7ce0) 3.465466 Krnl PSW : 0404100180000000 0000000000162f86 (__wake_up+0x46/0xb8) 3.465480 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3 Krnl GPRS: fffffffffffffffe 0000000000000000 0000000000000160 0000000000000001 3.465492 0000000000000001 0000000000000004 0000000000000004 000000000096b490 3.465499 0000000000000001 0000000000000100 0000000000000001 0000000000000001 3.465506 070000003fc87d60 0000000000000160 000000003fc87d68 000000003fc87d00 3.465526 Krnl Code: 0000000000162f76: e3c0f0a80004 lg %r12,168(%r15) 0000000000162f7c: 58000370 l %r0,880 #0000000000162f80: c007ffffffff00 xilf %r0,4294967295 >0000000000162f86: ba102000 cs %r1,%r0,0(%r2) 0000000000162f8a: 1211 ltr %r1,%r1 0000000000162f8c: a774002f brc 7,162fea 0000000000162f90: b904002d lgr %r2,%r13 0000000000162f94: b904003a lgr %r3,%r10 3.465597 Call Trace: 3.465599 (<0400000000000000> 0x400000000000000) 3.465602 <000000000048c77e> raw3215_wakeup+0x2e/0x40 3.465607 <0000000000134d66> tasklet_action+0x96/0x168 3.465612 <000000000013423c> __do_softirq+0xd8/0x21c 3.465615 <0000000000134678> irq_exit+0xa8/0xac 3.465617 <000000000046c232> do_IRQ+0x182/0x248 3.465621 <00000000005c8296> io_return+0x0/0x8 3.465625 <00000000005c7cac> vtime_stop_cpu+0x4c/0xb8 3.465629 (<0000000000194e06> tick_nohz_idle_enter+0x4e/0x74) 3.465633 <0000000000104760> cpu_idle+0x170/0x184 3.465636 <00000000005b5182> smp_start_secondary+0xd6/0xe0 3.465641 <00000000005c86be> restart_int_handler+0x56/0x6c 3.465643 <0000000000000000> 0x0 3.465645 Last Breaking-Event-Address: 3.465647 <0000000000403136> tty_wakeup+0x46/0x98 3.465652 3.465654 Kernel panic - not syncing: Fatal exception in interrupt 01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 0010F63C The easiest solution is simply to check if tty is NULL in the tasklet. If it is NULL nothing is to do (no tty attached), otherwise tty_wakeup() can be called, since we hold a reference to the tty. This is not nice... but it is a small patch and it works. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

When sched_show_task() is invoked from try_to_freeze_tasks(), there is no RCU read-side critical section, resulting in the following splat: [ 125.780730] =============================== [ 125.780766] [ INFO: suspicious RCU usage. ] [ 125.780804] 3.7.0-rc3+ #988 Not tainted [ 125.780838] ------------------------------- [ 125.780875] /home/rafael/src/linux/kernel/sched/core.c:4497 suspicious rcu_dereference_check() usage! [ 125.780946] [ 125.780946] other info that might help us debug this: [ 125.780946] [ 125.781031] [ 125.781031] rcu_scheduler_active = 1, debug_locks = 0 [ 125.781087] 4 locks held by s2ram/4211: [ 125.781120] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff811e2acf>] sysfs_write_file+0x3f/0x160 [ 125.781233] #1: (s_active#94){.+.+.+}, at: [<ffffffff811e2b58>] sysfs_write_file+0xc8/0x160 [ 125.781339] imx6-dongle#2: (pm_mutex){+.+.+.}, at: [<ffffffff81090a81>] pm_suspend+0x81/0x230 [ 125.781439] imx6-dongle#3: (tasklist_lock){.?.?..}, at: [<ffffffff8108feed>] try_to_freeze_tasks+0x2cd/0x3f0 [ 125.781543] [ 125.781543] stack backtrace: [ 125.781584] Pid: 4211, comm: s2ram Not tainted 3.7.0-rc3+ #988 [ 125.781632] Call Trace: [ 125.781662] [<ffffffff810a3c73>] lockdep_rcu_suspicious+0x103/0x140 [ 125.781719] [<ffffffff8107cf21>] sched_show_task+0x121/0x180 [ 125.781770] [<ffffffff8108ffb4>] try_to_freeze_tasks+0x394/0x3f0 [ 125.781823] [<ffffffff810903b5>] freeze_kernel_threads+0x25/0x80 [ 125.781876] [<ffffffff81090b65>] pm_suspend+0x165/0x230 [ 125.781924] [<ffffffff8108fa29>] state_store+0x99/0x100 [ 125.781975] [<ffffffff812f5867>] kobj_attr_store+0x17/0x20 [ 125.782038] [<ffffffff811e2b71>] sysfs_write_file+0xe1/0x160 [ 125.782091] [<ffffffff811667a6>] vfs_write+0xc6/0x180 [ 125.782138] [<ffffffff81166ada>] sys_write+0x5a/0xa0 [ 125.782185] [<ffffffff812ff6ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 125.782242] [<ffffffff81669dd2>] system_call_fastpath+0x16/0x1b This commit therefore adds the needed RCU read-side critical section. Reported-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Iterating over the vma->anon_vma_chain without anon_vma_lock may cause NULL ptr deref in anon_vma_interval_tree_verify(), because the node in the chain might have been removed. BUG: unable to handle kernel paging request at fffffffffffffff0 IP: [<ffffffff8122c29c>] anon_vma_interval_tree_verify+0xc/0xa0 PGD 4e28067 PUD 4e29067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU 0 Pid: 9050, comm: trinity-child64 Tainted: G W 3.7.0-rc2-next-20121025-sasha-00001-g673f98e-dirty #77 RIP: 0010: anon_vma_interval_tree_verify+0xc/0xa0 Process trinity-child64 (pid: 9050, threadinfo ffff880045f80000, task ffff880048eb0000) Call Trace: validate_mm+0x58/0x1e0 vma_adjust+0x635/0x6b0 __split_vma.isra.22+0x161/0x220 split_vma+0x24/0x30 sys_madvise+0x5da/0x7b0 tracesys+0xe1/0xe6 RIP anon_vma_interval_tree_verify+0xc/0xa0 CR2: fffffffffffffff0 Figured out by Bob Liu. Reported-by: Sasha Levin <sasha.levin@oracle.com> Cc: Bob Liu <lliubbo@gmail.com> Signed-off-by: Michel Lespinasse <walken@google.com> Reviewed-by: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

…el/git/jgarzik/libata-dev Pull libata fixes from Jeff Garzik: "If you were going to shoot me for not sending these earlier, you would be right. -rc6 beat me by ~2 hours it seems, and they really should have gone out long before that. These have been in libata-dev.git for a day or so (unfortunately linux-next is on vacation). The main one is #1, with the others being minor bits. #1 has multiple tested-by, and can be considered a regression fix IMO. 1) Fix ACPI oops: https://bugzilla.kernel.org/show_bug.cgi?id=48211 2) Temporary WARN_ONCE() debugging patch for further ACPI debugging. The code already oopses here, and so this merely gives slightly better info. Related to https://bugzilla.kernel.org/show_bug.cgi?id=49151 which has been bisected down to a patch that _exposes_ a latest bug, but said bisection target does not actually appear to be the root cause itself. 3) sata_svw: fix longstanding error recovery bug, which was preventing kdump, by adding missing DMA-start bit check. Core code was already checking DMA-start, but ancillary, less-used routines were not. Fixed. 4) sata_highbank: fix minor __init/__devinit warning 5) Fix minor warning, if CONFIG_PM is set, but CONFIG_PM_SLEEP is not set 6) pata_arasan: proper functioning requires clock setting" * tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: [libata] PM callbacks should be conditionally compiled on CONFIG_PM_SLEEP sata_svw: check DMA start bit before reset libata debugging: Warn when unable to find timing descriptor based on xfer_mode sata_highbank: mark ahci_highbank_probe as __devinit pata_arasan: Initialize cf clock to 166MHz libata-acpi: Fix NULL ptr derference in ata_acpi_dev_handle

cgroup_create_dir() does weird dancing with dentry refcnt. On success, it gets and then puts it achieving nothing. On failure, it puts but there isn't no matching get anywhere leading to the following oops if cgroup_create_file() fails for whatever reason. ------------[ cut here ]------------ kernel BUG at /work/os/work/fs/dcache.c:552! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: CPU 2 Pid: 697, comm: mkdir Not tainted 3.7.0-rc4-work+ imx6-dongle#3 Bochs Bochs RIP: 0010:[<ffffffff811d9c0c>] [<ffffffff811d9c0c>] dput+0x1dc/0x1e0 RSP: 0018:ffff88001a3ebef8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88000e5b1ef8 RCX: 0000000000000403 RDX: 0000000000000303 RSI: 2000000000000000 RDI: ffff88000e5b1f58 RBP: ffff88001a3ebf18 R08: ffffffff82c76960 R09: 0000000000000001 R10: ffff880015022080 R11: ffd9bed70f48a041 R12: 00000000ffffffea R13: 0000000000000001 R14: ffff88000e5b1f58 R15: 00007fff57656d60 FS: 00007ff05fcb3800(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004046f0 CR3: 000000001315f000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process mkdir (pid: 697, threadinfo ffff88001a3ea000, task ffff880015022080) Stack: ffff88001a3ebf48 00000000ffffffea 0000000000000001 0000000000000000 ffff88001a3ebf38 ffffffff811cc889 0000000000000001 ffff88000e5b1ef8 ffff88001a3ebf68 ffffffff811d1fc9 ffff8800198d7f18 ffff880019106ef8 Call Trace: [<ffffffff811cc889>] done_path_create+0x19/0x50 [<ffffffff811d1fc9>] sys_mkdirat+0x59/0x80 [<ffffffff811d2009>] sys_mkdir+0x19/0x20 [<ffffffff81be1e02>] system_call_fastpath+0x16/0x1b Code: 00 48 8d 90 18 01 00 00 48 89 93 c0 00 00 00 4c 89 a0 18 01 00 00 48 8b 83 a0 00 00 00 83 80 28 01 00 00 01 e8 e6 6f a0 00 eb 92 <0f> 0b 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 RIP [<ffffffff811d9c0c>] dput+0x1dc/0x1e0 RSP <ffff88001a3ebef8> ---[ end trace 1277bcfd9561ddb0 ]--- Fix it by dropping the unnecessary dget/dput() pair. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org

In 32 bit the stack address provided by kernel_stack_pointer() may point to an invalid range causing NULL pointer access or page faults while in NMI (see trace below). This happens if called in softirq context and if the stack is empty. The address at &regs->sp is then out of range. Fixing this by checking if regs and &regs->sp are in the same stack context. Otherwise return the previous stack pointer stored in struct thread_info. If that address is invalid too, return address of regs. BUG: unable to handle kernel NULL pointer dereference at 0000000a IP: [<c1004237>] print_context_stack+0x6e/0x8d *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 imx6-dongle#4 Hewlett-Packard HP xw9400 Workstation/0A1Ch EIP: 0060:[<c1004237>] EFLAGS: 00010093 CPU: 0 EIP is at print_context_stack+0x6e/0x8d EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000) Stack: 000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000 f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c Call Trace: [<c1003723>] dump_trace+0x7b/0xa1 [<c12dce1c>] x86_backtrace+0x40/0x88 [<c12db712>] ? oprofile_add_sample+0x56/0x84 [<c12db731>] oprofile_add_sample+0x75/0x84 [<c12ddb5b>] op_amd_check_ctrs+0x46/0x260 [<c12dd40d>] profile_exceptions_notify+0x23/0x4c [<c1395034>] nmi_handle+0x31/0x4a [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 [<c13950ed>] do_nmi+0xa0/0x2ff [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 [<c13949e5>] nmi_stack_correct+0x28/0x2d [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 [<c1003603>] ? do_softirq+0x4b/0x7f <IRQ> [<c102a06f>] irq_exit+0x35/0x5b [<c1018f56>] smp_apic_timer_interrupt+0x6c/0x7a [<c1394746>] apic_timer_interrupt+0x2a/0x30 Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc EIP: [<c1004237>] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0 CR2: 000000000000000a ---[ end trace 62afee3481b00012 ]--- Kernel panic - not syncing: Fatal exception in interrupt V2: * add comments to kernel_stack_pointer() * always return a valid stack address by falling back to the address of regs Reported-by: Yang Wei <wei.yang@windriver.com> Cc: <stable@vger.kernel.org> Signed-off-by: Robert Richter <robert.richter@amd.com> Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: Jun Zhang <jun.zhang@intel.com>

I saw this suspicious RCU usage on the next tree of 11/15 [ 67.123404] =============================== [ 67.123413] [ INFO: suspicious RCU usage. ] [ 67.123423] 3.7.0-rc5-next-20121115-dirty #1 Not tainted [ 67.123434] ------------------------------- [ 67.123444] include/trace/events/timer.h:186 suspicious rcu_dereference_check() usage! [ 67.123458] [ 67.123458] other info that might help us debug this: [ 67.123458] [ 67.123474] [ 67.123474] RCU used illegally from idle CPU! [ 67.123474] rcu_scheduler_active = 1, debug_locks = 0 [ 67.123493] RCU used illegally from extended quiescent state! [ 67.123507] 1 lock held by swapper/1/0: [ 67.123516] #0: (&cpu_base->lock){-.-...}, at: [<c0000000000979b0>] .__hrtimer_start_range_ns+0x28c/0x524 [ 67.123555] [ 67.123555] stack backtrace: [ 67.123566] Call Trace: [ 67.123576] [c0000001e2ccb920] [c00000000001275c] .show_stack+0x78/0x184 (unreliable) [ 67.123599] [c0000001e2ccb9d0] [c0000000000c15a0] .lockdep_rcu_suspicious+0x120/0x148 [ 67.123619] [c0000001e2ccba70] [c00000000009601c] .enqueue_hrtimer+0x1c0/0x1c8 [ 67.123639] [c0000001e2ccbb00] [c000000000097aa0] .__hrtimer_start_range_ns+0x37c/0x524 [ 67.123660] [c0000001e2ccbc20] [c0000000005c9698] .menu_select+0x508/0x5bc [ 67.123678] [c0000001e2ccbd20] [c0000000005c740c] .cpuidle_idle_call+0xa8/0x6e4 [ 67.123699] [c0000001e2ccbdd0] [c0000000000459a0] .pSeries_idle+0x10/0x34 [ 67.123717] [c0000001e2ccbe40] [c000000000014dc8] .cpu_idle+0x130/0x280 [ 67.123738] [c0000001e2ccbee0] [c0000000006ffa8c] .start_secondary+0x378/0x384 [ 67.123758] [c0000001e2ccbf90] [c00000000000936c] .start_secondary_prolog+0x10/0x14 hrtimer_start was added in 198fd638 and ae515197. The patch below tries to use RCU_NONIDLE around it to avoid the above report. Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Rik van Riel <riel@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

We need to first destroy the floppy_wq workqueue before cleaning up the queue. Otherwise we might race with still pending work with the workqueue, but all the block queue already gone. This might lead to various oopses, such as CPU 0 Pid: 6, comm: kworker/u:0 Not tainted 3.7.0-rc4 #1 Bochs Bochs RIP: 0010:[<ffffffff8134eef5>] [<ffffffff8134eef5>] blk_peek_request+0xd5/0x1c0 RSP: 0000:ffff88000dc7dd88 EFLAGS: 00010092 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88000f602688 RSI: ffffffff81fd95d8 RDI: 6b6b6b6b6b6b6b6b RBP: ffff88000dc7dd98 R08: ffffffff81fd95c8 R09: 0000000000000000 R10: ffffffff81fd9480 R11: 0000000000000001 R12: 6b6b6b6b6b6b6b6b R13: ffff88000dc7dfd8 R14: ffff88000dc7dfd8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000001e11000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/u:0 (pid: 6, threadinfo ffff88000dc7c000, task ffff88000dc5ecc0) Stack: 0000000000000000 0000000000000000 ffff88000dc7ddb8 ffffffff8134efee ffff88000dc7ddb8 0000000000000000 ffff88000dc7dde8 ffffffff814aef3c ffffffff81e75d80 ffff88000dc0c640 ffff88000fbfb000 ffffffff814aed90 Call Trace: [<ffffffff8134efee>] blk_fetch_request+0xe/0x30 [<ffffffff814aef3c>] redo_fd_request+0x1ac/0x400 [<ffffffff814aed90>] ? start_motor+0x130/0x130 [<ffffffff8106b526>] process_one_work+0x136/0x450 [<ffffffff8106af65>] ? manage_workers+0x205/0x2e0 [<ffffffff8106bb6d>] worker_thread+0x14d/0x420 [<ffffffff8106ba20>] ? rescuer_thread+0x1a0/0x1a0 [<ffffffff8107075a>] kthread+0xba/0xc0 [<ffffffff810706a0>] ? __kthread_parkme+0x80/0x80 [<ffffffff818b553a>] ret_from_fork+0x7a/0xb0 [<ffffffff810706a0>] ? __kthread_parkme+0x80/0x80 Code: 0f 84 c0 00 00 00 83 f8 01 0f 85 e2 00 00 00 81 4b 40 00 00 80 00 48 89 df e8 58 f8 ff ff be fb ff ff ff fe ff ff <49> 8b 1c 24 49 39 dc 0f 85 2e ff ff ff 41 0f b6 84 24 28 04 00 RIP [<ffffffff8134eef5>] blk_peek_request+0xd5/0x1c0 RSP <ffff88000dc7dd88> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Tested-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jens Axboe <axboe@kernel.dk>

On continuous loading and unloading of AR6004 ath6kl USB driver it triggers a panic due to NULL pointer dereference of 'target' pointer. while true; do sudo modprobe -v ath6kl_core; sudo modprobe -v ath6kl_usb; sudo modprobe -r usb; sudo modprobe -r ath6kl_core; done ar->htc_target can be NULL due to a race condition that can occur during driver initialization(we do 'ath6kl_hif_power_on' before initializing 'ar->htc_target' via 'ath6kl_htc_create'). 'ath6kl_hif_power_on' assigns 'ath6kl_recv_complete' as usb_complete_t/callback function for 'usb_fill_bulk_urb'. Thus the possibility of ar->htc_target being NULL via ath6kl_recv_complete -> ath6kl_usb_io_comp_work before even 'ath6kl_htc_create' is finished to initialize ar->htc_create. Worth noting is the obvious solution of doing 'ath6kl_hif_power_on' later(i.e after we are done with 'ath6kl_htc_create', causes a h/w bring up failure in AR6003 SDIO, as 'ath6kl_hif_power_on' is a pre-requisite to get the target version 'ath6kl_bmi_get_target_info'. So simply check for NULL pointer for 'ar->htc_target' and bail out. [23614.518282] BUG: unable to handle kernel NULL pointer dereference at 00000904 [23614.518463] IP: [<c012e7a6>] __ticket_spin_trylock+0x6/0x30 [23614.518570] *pde = 00000000 [23614.518664] Oops: 0000 [#1] SMP [23614.518795] Modules linked in: ath6kl_usb(O+) ath6kl_core(O) [23614.520012] EIP: 0060:[<c012e7a6>] EFLAGS: 00010286 CPU: 0 [23614.520012] EIP is at __ticket_spin_trylock+0x6/0x30 Call Trace: [<c03f2a44>] do_raw_spin_trylock+0x14/0x40 [<c06daa12>] _raw_spin_lock_bh+0x52/0x80 [<f85464b4>] ? ath6kl_htc_pipe_rx_complete+0x3b4/0x4c0 [ath6kl_core] [<f85464b4>] ath6kl_htc_pipe_rx_complete+0x3b4/0x4c0 [ath6kl_core] [<c05bc272>] ? skb_dequeue+0x22/0x70 [<c05bc272>] ? skb_dequeue+0x22/0x70 [<f855bb32>] ath6kl_core_rx_complete+0x12/0x20 [ath6kl_core] [<f848771a>] ath6kl_usb_io_comp_work+0xaa/0xb0 [ath6kl_usb] [<c015b863>] process_one_work+0x1a3/0x5e0 [<c015b7e7>] ? process_one_work+0x127/0x5e0 [<f8487670>] ? ath6kl_usb_reset_resume+0x30/0x30 [ath6kl_usb] [<c015bfde>] worker_thread+0x11e/0x3f0 Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

An earlier commit cd00608 ("ata_piix: defer disks to the Hyper-V drivers by default") broke MS Virtual PC guests. Hyper-V guests and Virtual PC guests have nearly identical DMI info. As a result the driver does currently ignore the emulated hardware in Virtual PC guests and defers the handling to hv_blkvsc. Since Virtual PC does not offer paravirtualized drivers no disks will be found in the guest. One difference in the DMI info is the product version. This patch adds a match for MS Virtual PC 2007 and "unignores" the emulated hardware. This was reported for openSuSE 12.1 in bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=737532 Here is a detailed list of DMI info from example guests: hwinfo --bios: virtual pc guest: System Info: #1 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "VS2005R2" Serial: "3178-9905-1533-4840-9282-0569-59" UUID: undefined, but settable Wake-up: 0x06 (Power Switch) Board Info: imx6-dongle#2 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "5.0" Serial: "3178-9905-1533-4840-9282-0569-59" Chassis Info: imx6-dongle#3 Manufacturer: "Microsoft Corporation" Version: "5.0" Serial: "3178-9905-1533-4840-9282-0569-59" Asset Tag: "7188-3705-6309-9738-9645-0364-00" Type: 0x03 (Desktop) Bootup State: 0x03 (Safe) Power Supply State: 0x03 (Safe) Thermal State: 0x01 (Other) Security Status: 0x01 (Other) win2k8 guest: System Info: #1 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "9106-3420-9819-5495-1514-2075-48" UUID: undefined, but settable Wake-up: 0x06 (Power Switch) Board Info: imx6-dongle#2 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "9106-3420-9819-5495-1514-2075-48" Chassis Info: imx6-dongle#3 Manufacturer: "Microsoft Corporation" Version: "7.0" Serial: "9106-3420-9819-5495-1514-2075-48" Asset Tag: "7076-9522-6699-1042-9501-1785-77" Type: 0x03 (Desktop) Bootup State: 0x03 (Safe) Power Supply State: 0x03 (Safe) Thermal State: 0x01 (Other) Security Status: 0x01 (Other) win2k12 guest: System Info: #1 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "8179-1954-0187-0085-3868-2270-14" UUID: undefined, but settable Wake-up: 0x06 (Power Switch) Board Info: imx6-dongle#2 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "8179-1954-0187-0085-3868-2270-14" Chassis Info: imx6-dongle#3 Manufacturer: "Microsoft Corporation" Version: "7.0" Serial: "8179-1954-0187-0085-3868-2270-14" Asset Tag: "8374-0485-4557-6331-0620-5845-25" Type: 0x03 (Desktop) Bootup State: 0x03 (Safe) Power Supply State: 0x03 (Safe) Thermal State: 0x01 (Other) Security Status: 0x01 (Other) Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>

I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20. It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is only used for kernel direct mapping address, but sparse-vmemmap uses vmemmap address, so it is going wrong here. ------------[ cut here ]------------ kernel BUG at arch/x86/mm/physaddr.c:20! invalid opcode: 0000 [#1] SMP Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod CPU 39 Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ #45 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffff8103c908>] [<ffffffff8103c908>] __phys_addr+0x88/0x90 RSP: 0018:ffff8804440d7c08 EFLAGS: 00010006 RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c ... Signed-off-by: Jianguo Wu <wujianguo@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Reviewd-by: Wen Congyang <wency@cn.fujitsu.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

…et_dst() Trinity (the syscall fuzzer) triggered the following BUG, reproducible only when the kernel is configured with CONFIG_SCTP_DBG_MSG=y. When CONFIG_SCTP_DBG_MSG is not set, the null pointer is never dereferenced. ---[ end trace a4de0bfcb38a3642 ]--- BUG: unable to handle kernel NULL pointer dereference at 0000000000000100 IP: [<ffffffff8136796e>] ip6_string+0x1e/0xa0 PGD 4eead067 PUD 4e472067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU 3 Pid: 21324, comm: trinity-child11 Tainted: G W 3.7.0-rc7+ #61 ASUSTeK Computer INC. EB1012/EB1012 RIP: 0010:[<ffffffff8136796e>] [<ffffffff8136796e>] ip6_string+0x1e/0xa0 RSP: 0018:ffff88004e4637a0 EFLAGS: 00010046 RAX: ffff88004e4637da RBX: ffff88004e4637da RCX: 0000000000000000 RDX: ffffffff8246e92a RSI: 0000000000000100 RDI: ffff88004e4637da RBP: ffff88004e4637a8 R08: 000000000000ffff R09: 000000000000ffff R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8289d600 R13: ffffffff8289d230 R14: ffffffff8246e928 R15: ffffffff8289d600 FS: 00007fed95153700(0000) GS:ffff88005fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000100 CR3: 000000004eeac000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process trinity-child11 (pid: 21324, threadinfo ffff88004e462000, task ffff8800524b0000) Stack: ffff88004e4637da ffff88004e463828 ffffffff81368eee 000000004e4637d8 ffffffff0000ffff ffff88000000ffff 0000000000000000 000000004e4637f8 ffffffff826285d8 ffff88004e4637f8 0000000000000000 ffff8800524b06b0 Call Trace: [<ffffffff81368eee>] ip6_addr_string.isra.11+0x3e/0xa0 [<ffffffff81369183>] pointer.isra.12+0x233/0x2d0 [<ffffffff810a413a>] ? vprintk_emit+0x1ba/0x450 [<ffffffff8110953d>] ? trace_hardirqs_on_caller+0x10d/0x1a0 [<ffffffff81369757>] vsnprintf+0x187/0x5d0 [<ffffffff81369c62>] vscnprintf+0x12/0x30 [<ffffffff810a4028>] vprintk_emit+0xa8/0x450 [<ffffffff81e5cb00>] printk+0x49/0x4b [<ffffffff81d17221>] sctp_v6_get_dst+0x731/0x780 [<ffffffff81d16e15>] ? sctp_v6_get_dst+0x325/0x780 [<ffffffff81d00a96>] sctp_transport_route+0x46/0x120 [<ffffffff81cff0f1>] sctp_assoc_add_peer+0x161/0x350 [<ffffffff81d0fd8d>] sctp_sendmsg+0x6cd/0xcb0 [<ffffffff81b55bf0>] ? inet_create+0x670/0x670 [<ffffffff81b55cfb>] inet_sendmsg+0x10b/0x220 [<ffffffff81b55bf0>] ? inet_create+0x670/0x670 [<ffffffff81a72a64>] ? sock_update_classid+0xa4/0x2b0 [<ffffffff81a72ab0>] ? sock_update_classid+0xf0/0x2b0 [<ffffffff81a6ac1c>] sock_sendmsg+0xdc/0xf0 [<ffffffff8118e9e5>] ? might_fault+0x85/0x90 [<ffffffff8118e99c>] ? might_fault+0x3c/0x90 [<ffffffff81a6e12a>] sys_sendto+0xfa/0x130 [<ffffffff810a9887>] ? do_setitimer+0x197/0x380 [<ffffffff81e960d5>] ? sysret_check+0x22/0x5d [<ffffffff81e960a9>] system_call_fastpath+0x16/0x1b Code: 01 eb 89 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 f8 31 c9 48 89 e5 53 eb 12 0f 1f 40 00 48 83 c1 01 48 83 c0 04 48 83 f9 08 74 70 <0f> b6 3c 4e 89 fb 83 e7 0f c0 eb 04 41 89 d8 41 83 e0 0f 0f b6 RIP [<ffffffff8136796e>] ip6_string+0x1e/0xa0 RSP <ffff88004e4637a0> CR2: 0000000000000100 ---[ end trace a4de0bfcb38a3643 ]--- Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>

A rescue thread exiting TASK_INTERRUPTIBLE can lead to a task scheduling off, never to be seen again. In the case where this occurred, an exiting thread hit reiserfs homebrew conditional resched while holding a mutex, bringing the box to its knees. PID: 18105 TASK: ffff8807fd412180 CPU: 5 COMMAND: "kdmflush" #0 [ffff8808157e7670] schedule at ffffffff8143f489 #1 [ffff8808157e77b8] reiserfs_get_block at ffffffffa038ab2d [reiserfs] imx6-dongle#2 [ffff8808157e79a8] __block_write_begin at ffffffff8117fb14 imx6-dongle#3 [ffff8808157e7a98] reiserfs_write_begin at ffffffffa0388695 [reiserfs] imx6-dongle#4 [ffff8808157e7ad8] generic_perform_write at ffffffff810ee9e2 imx6-dongle#5 [ffff8808157e7b58] generic_file_buffered_write at ffffffff810eeb41 imx6-dongle#6 [ffff8808157e7ba8] __generic_file_aio_write at ffffffff810f1a3a imx6-dongle#7 [ffff8808157e7c58] generic_file_aio_write at ffffffff810f1c88 imx6-dongle#8 [ffff8808157e7cc8] do_sync_write at ffffffff8114f850 imx6-dongle#9 [ffff8808157e7dd8] do_acct_process at ffffffff810a268f [exception RIP: kernel_thread_helper] RIP: ffffffff8144a5c0 RSP: ffff8808157e7f58 RFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8107af60 RDI: ffff8803ee491d18 RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 Signed-off-by: Mike Galbraith <mgalbraith@suse.de> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org

Loading cs553x_nand with Hynix H27U1G8F2BTR NAND flash causes this bug: kernel BUG at drivers/mtd/nand/nand_base.c:3345! invalid opcode: 0000 [#1] Modules linked in: cs553x_nand(+) vfat fat usb_storage ehci_hcd usbcore usb_comr Pid: 436, comm: modprobe Not tainted 3.6.7 #1 EIP: 0060:[<c118d205>] EFLAGS: 00010296 CPU: 0 EIP is at nand_scan_tail+0x64c/0x69c EAX: 00000034 EBX: cea6ed98 ECX: 00000000 EDX: 00000000 ESI: cea6ec00 EDI: cea6ec00 EBP: 20000000 ESP: cdd17e48 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: 0804e119 CR3: 0d850000 CR4: 00000090 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 436, ti=cdd16000 task=cdd1c320 task.ti=cdd16000) Stack: c12e962c c118f7ef 00000003 cea6ed98 d014b25c 20000000 fffff007 00000001 00000000 cdd53b00 d014b000 c1001021 cdd53b00 d01493c0 cdd53b00 cdd53b00 d01493c0 c1047f83 d014b4a0 00000000 cdd17f9c ce4be454 cdd17f48 cdd1c320 Call Trace: [<c118f7ef>] ? nand_scan+0x1b/0x4d [<d014b25c>] ? init_module+0x25c/0x2de [cs553x_nand] [<d014b000>] ? 0xd014afff [<c1001021>] ? do_one_initcall+0x21/0x111 [<c1047f83>] ? sys_init_module+0xe4/0x1261 [<c1031207>] ? task_work_run+0x36/0x43 [<c1265ced>] ? syscall_call+0x7/0xb Code: fa ff ff c7 86 d8 00 00 00 01 00 00 00 e9 5f fc ff ff 68 f8 26 2e c1 e8 a7 EIP: [<c118d205>] nand_scan_tail+0x64c/0x69c SS:ESP 0068:cdd17e48 Initialising ecc.strength before the call to nand_scan() fixes this. Signed-off-by: Nathan Williams <nathan@traverse.com.au> Cc: stable@vger.kernel.org [3.4+] Acked-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

Trying to access the OTP memory on the AR9340 causes a data bus error like this: Data bus error, epc == 86e84164, ra == 86e84164 Oops[#1]: Cpu 0 $ 0 : 00000000 00000061 deadc0de 00000000 $ 4 : b8115f18 00015f18 00000007 00000004 $ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c $12 : 7c7c3c7c 001f0041 00000000 7c7c7c3c $16 : 86ee0000 00015f18 00000000 00000007 $20 : 00000004 00000064 00000004 86d71c44 $24 : 00000000 86e6ca00 $28 : 86d70000 86d71b20 86ece0c0 86e84164 Hi : 00000000 Lo : 00000064 epc : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Tainted: G O ra : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Status: 1100d403 KERNEL EXL IE Cause : 4080801c PrId : 0001974c (MIPS 74Kc) Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440) Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88 86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20 000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938 fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000 99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000 ... Call Trace: [<86e84164>] ath9k_hw_wait+0x58/0xb0 [ath9k_hw] [<86e9fcd0>] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw] Code: 0000a812 0040f809 00000000 <00531024> 1054000b 24020001 0c05b5dc 2404000a 26520001 The cause of the error is that the OTP register offsets are different on the AR9340 than the actually used values. Cc: <stable@vger.kernel.org> # 3.0+ Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>

The offset must be multiplied by 4 to be sure to access the correct 32bit word in the stack scratch space. For instance, a store at scratch memory cell #1 was generating the following: st r4, [sp, #1] While the correct code for this is: st r4, [sp, imx6-dongle#4] To reproduce the bug (assuming your system has a NIC with the mac address 52:54:00:12:34:56): echo 0 > /proc/sys/net/core/bpf_jit_enable tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \ == -0x3AA" # this will capture packets as expected echo 1 > /proc/sys/net/core/bpf_jit_enable tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \ == -0x3AA" # this will not. This bug was present since the original inclusion of bpf_jit for ARM (ddecdfc: ARM: 7259/3: net: JIT compiler for packet filters). Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

On Mon, Aug 01, 2011 at 04:38:22PM -0400, Eric Paris wrote: > > I finally built and tested a v3.0 kernel with these patches (I know I'm > SOOOOOO far behind). Not what I hoped for: > > > [ 150.937798] VFS: Busy inodes after unmount of tmpfs. Self-destruct in 5 seconds. Have a nice day... > > [ 150.945290] BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 > > [ 150.946012] IP: [<ffffffff810ffd58>] shmem_free_inode+0x18/0x50 > > [ 150.946012] PGD 2bf9e067 PUD 2bf9f067 PMD 0 > > [ 150.946012] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > [ 150.946012] CPU 0 > > [ 150.946012] Modules linked in: nfs lockd fscache auth_rpcgss nfs_acl sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ext4 jbd2 crc16 joydev ata_piix i2c_piix4 pcspkr uinput ipv6 autofs4 usbhid [last unloaded: scsi_wait_scan] > > [ 150.946012] > > [ 150.946012] Pid: 2764, comm: syscall_thrash Not tainted 3.0.0+ #1 Red Hat KVM > > [ 150.946012] RIP: 0010:[<ffffffff810ffd58>] [<ffffffff810ffd58>] shmem_free_inode+0x18/0x50 > > [ 150.946012] RSP: 0018:ffff88002c2e5df8 EFLAGS: 00010282 > > [ 150.946012] RAX: 000000004e370d9f RBX: 0000000000000000 RCX: ffff88003a029438 > > [ 150.946012] RDX: 0000000033630a5f RSI: 0000000000000000 RDI: ffff88003491c240 > > [ 150.946012] RBP: ffff88002c2e5e08 R08: 0000000000000000 R09: 0000000000000000 > > [ 150.946012] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a029428 > > [ 150.946012] R13: ffff88003a029428 R14: ffff88003a029428 R15: ffff88003499a610 > > [ 150.946012] FS: 00007f5a05420700(0000) GS:ffff88003f600000(0000) knlGS:0000000000000000 > > [ 150.946012] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > [ 150.946012] CR2: 0000000000000070 CR3: 000000002a662000 CR4: 00000000000006f0 > > [ 150.946012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [ 150.946012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > [ 150.946012] Process syscall_thrash (pid: 2764, threadinfo ffff88002c2e4000, task ffff88002bfbc760) > > [ 150.946012] Stack: > > [ 150.946012] ffff88003a029438 ffff88003a029428 ffff88002c2e5e38 ffffffff81102f76 > > [ 150.946012] ffff88003a029438 ffff88003a029598 ffffffff8160f9c0 ffff88002c221250 > > [ 150.946012] ffff88002c2e5e68 ffffffff8115e9be ffff88002c2e5e68 ffff88003a029438 > > [ 150.946012] Call Trace: > > [ 150.946012] [<ffffffff81102f76>] shmem_evict_inode+0x76/0x130 > > [ 150.946012] [<ffffffff8115e9be>] evict+0x7e/0x170 > > [ 150.946012] [<ffffffff8115ee40>] iput_final+0xd0/0x190 > > [ 150.946012] [<ffffffff8115ef33>] iput+0x33/0x40 > > [ 150.946012] [<ffffffff81180205>] fsnotify_destroy_mark_locked+0x145/0x160 > > [ 150.946012] [<ffffffff81180316>] fsnotify_destroy_mark+0x36/0x50 > > [ 150.946012] [<ffffffff81181937>] sys_inotify_rm_watch+0x77/0xd0 > > [ 150.946012] [<ffffffff815aca52>] system_call_fastpath+0x16/0x1b > > [ 150.946012] Code: 67 4a 00 b8 e4 ff ff ff eb aa 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 64 24 08 48 8b 9f 40 05 00 00 > > [ 150.946012] 83 7b 70 00 74 1c 4c 8d a3 80 00 00 00 4c 89 e7 e8 d2 5d 4a > > [ 150.946012] RIP [<ffffffff810ffd58>] shmem_free_inode+0x18/0x50 > > [ 150.946012] RSP <ffff88002c2e5df8> > > [ 150.946012] CR2: 0000000000000070 > > Looks at aweful lot like the problem from: > http://www.spinics.net/lists/linux-fsdevel/msg46101.html > I tried to reproduce this bug with your test program, but without success. However, if I understand correctly, this occurs since we dont hold any locks when we call iput() in mark_destroy(), right? With the patches you tested, iput() is also not called within any lock, since the groups mark_mutex is released temporarily before iput() is called. This is, since the original codes behaviour is similar. However since we now have a mutex as the biggest lock, we can do what you suggested (http://www.spinics.net/lists/linux-fsdevel/msg46107.html) and call iput() with the mutex held to avoid the race. The patch below implements this. It uses nested locking to avoid deadlock in case we do the final iput() on an inode which still holds marks and thus would take the mutex again when calling fsnotify_inode_delete() in destroy_inode(). Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by: Eric Paris <eparis@redhat.com>

… built as a module [ 12.761956] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [ 12.762016] IP: [<ffffffffa0005277>] handle_thermal_trip+0x47/0x130 [thermal_sys] [ 12.762060] PGD 1fec74067 PUD 1fee5b067 PMD 0 [ 12.762127] Oops: 0000 [#1] SMP [ 12.762177] Modules linked in: hid_generic crc32c_intel usbhid hid firewire_ohci(+) e1000e(+) firewire_core crc_itu_t xhci_hcd(+) thermal(+) fan thermal_sys hwmon [ 12.762423] CPU 1 [ 12.762443] Pid: 187, comm: modprobe Tainted: G A 3.7.0-thermal-module+ #25 /DH77DF [ 12.762496] RIP: 0010:[<ffffffffa0005277>] [<ffffffffa0005277>] handle_thermal_trip+0x47/0x130 [thermal_sys] [ 12.762682] RSP: 0018:ffff8801fe7ddc18 EFLAGS: 00010282 [ 12.762704] RAX: 0000000000000000 RBX: ffff8801ff3e9c00 RCX: ffff8801fdc39800 [ 12.762728] RDX: ffff8801fe7ddc24 RSI: 0000000000000001 RDI: ffff8801ff3e9c00 [ 12.762764] RBP: ffff8801fe7ddc48 R08: 0000000004000000 R09: ffffffffa001f568 [ 12.762797] R10: ffffffff81363083 R11: 0000000000000001 R12: 0000000000000001 [ 12.762832] R13: 0000000000000000 R14: 0000000000000001 R15: ffff8801fde73e68 [ 12.762866] FS: 00007f5548516700(0000) GS:ffff88021f240000(0000) knlGS:0000000000000000 [ 12.762912] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 12.762946] CR2: 0000000000000018 CR3: 00000001fefe2000 CR4: 00000000001407e0 [ 12.762979] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 12.763014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 12.763048] Process modprobe (pid: 187, threadinfo ffff8801fe7dc000, task ffff8801fe5bdb40) [ 12.763095] Stack: [ 12.763122] 0000000000019640 00000000fdc39800 ffff8801fe7ddc48 ffff8801ff3e9c00 [ 12.763225] 0000000000000002 0000000000000000 ffff8801fe7ddc78 ffffffffa00053e7 [ 12.763338] ffff8801ff3e9c00 0000000000006c98 ffffffffa0007480 ffff8801ff3e9c00 [ 12.763440] Call Trace: [ 12.763470] [<ffffffffa00053e7>] thermal_zone_device_update+0x77/0xa0 [thermal_sys] [ 12.763515] [<ffffffffa0006d38>] thermal_zone_device_register+0x788/0xa88 [thermal_sys] [ 12.763562] [<ffffffffa001f394>] acpi_thermal_add+0x360/0x4c8 [thermal] [ 12.763598] [<ffffffff8133902a>] acpi_device_probe+0x50/0x190 [ 12.763632] [<ffffffff811bd793>] ? sysfs_create_link+0x13/0x20 [ 12.763666] [<ffffffff813cc41b>] driver_probe_device+0x7b/0x240 [ 12.763699] [<ffffffff813cc68b>] __driver_attach+0xab/0xb0 [ 12.763732] [<ffffffff813cc5e0>] ? driver_probe_device+0x240/0x240 [ 12.763766] [<ffffffff813ca836>] bus_for_each_dev+0x56/0x90 [ 12.763799] [<ffffffff813cbf4e>] driver_attach+0x1e/0x20 [ 12.763831] [<ffffffff813cbac0>] bus_add_driver+0x190/0x290 [ 12.763864] [<ffffffffa0022000>] ? 0xffffffffa0021fff [ 12.763896] [<ffffffff813ccbea>] driver_register+0x7a/0x160 [ 12.763928] [<ffffffffa0022000>] ? 0xffffffffa0021fff [ 12.763960] [<ffffffff813399fb>] acpi_bus_register_driver+0x43/0x45 [ 12.763995] [<ffffffffa002203a>] acpi_thermal_init+0x3a/0x42 [thermal] [ 12.764029] [<ffffffff8100207f>] do_one_initcall+0x3f/0x170 [ 12.764063] [<ffffffff810b1a5f>] sys_init_module+0x8f/0x200 [ 12.764097] [<ffffffff815ff259>] system_call_fastpath+0x16/0x1b [ 12.764129] Code: 48 8b 87 c8 02 00 00 41 89 f4 48 8d 55 dc ff 50 28 44 8b 6d dc 41 8d 45 fe 83 f8 01 76 5e 48 8b 83 d8 02 00 00 44 89 e6 48 89 df <ff> 50 18 4c 8d a3 10 03 00 00 4c 89 e7 e8 87 f1 5e e1 8b 83 bc [ 12.765164] RIP [<ffffffffa0005277>] handle_thermal_trip+0x47/0x130 [thermal_sys] [ 12.765223] RSP <ffff8801fe7ddc18> [ 12.765252] CR2: 0000000000000018 [ 12.765284] ---[ end trace 7723294cdfb00d2a ]--- This is because thermal_zone_device_update() is invoked before any thermal governors being registered. Signed-off-by: Zhang Rui <rui.zhang@intel.com>

On Wed, 2012-12-12 at 23:16 -0500, Dave Jones wrote: > Since todays net merge, I see this when I start openvpn.. > > general protection fault: 0000 [#1] PREEMPT SMP > Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables xfs iTCO_wdt iTCO_vendor_support snd_emu10k1 snd_util_mem snd_ac97_codec coretemp ac97_bus microcode snd_hwdep snd_seq pcspkr snd_pcm snd_page_alloc snd_timer lpc_ich i2c_i801 snd_rawmidi mfd_core snd_seq_device snd e1000e soundcore emu10k1_gp gameport i82975x_edac edac_core vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc nfsd auth_rpcgss nfs_acl lockd sunrpc btrfs libcrc32c zlib_deflate firewire_ohci sata_sil firewire_core crc_itu_t radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core floppy > CPU 0 > Pid: 1381, comm: openvpn Not tainted 3.7.0+ imx6-dongle#14 /D975XBX > RIP: 0010:[<ffffffff815b54a4>] [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0 > RSP: 0018:ffff88007d0d9c48 EFLAGS: 00010206 > RAX: 000000000000055d RBX: 6b6b6b6b6b6b6b4b RCX: 1471030a0180040a > RDX: 0000000000000005 RSI: 00000000ffffffe0 RDI: ffff8800ba83fa80 > RBP: ffff88007d0d9cb8 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000101 R12: ffff8800ba83fa80 > R13: 0000000000000008 R14: ffff88007d0d9cc8 R15: ffff8800ba83fa80 > FS: 00007f6637104800(0000) GS:ffff8800bf600000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f563f5b01c4 CR3: 000000007d140000 CR4: 00000000000007f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process openvpn (pid: 1381, threadinfo ffff88007d0d8000, task ffff8800a540cd60) > Stack: > ffff8800ba83fa80 0000000000000296 0000000000000000 0000000000000000 > ffff88007d0d9cc8 ffffffff815bcff4 ffff88007d0d9ce8 ffffffff815b1831 > ffff88007d0d9ca8 00000000703f6364 ffff8800ba83fa80 0000000000000000 > Call Trace: > [<ffffffff815bcff4>] ? netif_rx+0x114/0x4c0 > [<ffffffff815b1831>] ? skb_copy_datagram_from_iovec+0x61/0x290 > [<ffffffff815b672a>] __skb_get_rxhash+0x1a/0xd0 > [<ffffffffa03b9538>] tun_get_user+0x418/0x810 [tun] > [<ffffffff8135f468>] ? delay_tsc+0x98/0xf0 > [<ffffffff8109605c>] ? __rcu_read_unlock+0x5c/0xa0 > [<ffffffffa03b9a41>] tun_chr_aio_write+0x81/0xb0 [tun] > [<ffffffff81145011>] ? __buffer_unlock_commit+0x41/0x50 > [<ffffffff811db917>] do_sync_write+0xa7/0xe0 > [<ffffffff811dc01f>] vfs_write+0xaf/0x190 > [<ffffffff811dc375>] sys_write+0x55/0xa0 > [<ffffffff81705540>] tracesys+0xdd/0xe2 > Code: 41 8b 44 24 68 41 2b 44 24 6c 01 de 29 f0 83 f8 03 0f 8e a0 00 00 00 48 63 de 49 03 9c 24 e0 00 00 00 48 85 db 0f 84 72 fe ff ff <8b> 03 41 89 46 08 b8 01 00 00 00 e9 43 fd ff ff 0f 1f 40 00 48 > RIP [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0 > RSP <ffff88007d0d9c48> > ---[ end trace 6d42c834c72c002e ]--- > > > Faulting instruction is > > 0: 8b 03 mov (%rbx),%eax > > rbx is slab poison (-20) so this looks like a use-after-free here... > > flow->ports = *ports; > 314: 8b 03 mov (%rbx),%eax > 316: 41 89 46 08 mov %eax,0x8(%r14) > > in the inlined skb_header_pointer in skb_flow_dissect > > Dave > commit 96442e4 (tuntap: choose the txq based on rxq) added a use after free. Cache rxhash in a temp variable before calling netif_rx_ni() Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jason Wang <jasowang@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>

Following oops were observed when disk error happened: [ 4272.896937] sd 0:0:0:0: [sda] Unhandled error code [ 4272.896939] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [ 4272.896942] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 5a de a7 00 00 08 00 [ 4272.896951] end_request: I/O error, dev sda, sector 5955239 [ 4291.574947] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4291.658305] IP: [] ahci_activity_show+0x1/0x40 [ 4291.730090] PGD 76dbbc067 PUD 6c4fba067 PMD 0 [ 4291.783408] Oops: 0000 [#1] SMP [ 4291.822100] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sw_activity [ 4291.934235] CPU 9 [ 4291.958301] Pid: 27942, comm: hwinfo ...... ata_scsi_find_dev could return NULL, so ata_scsi_activity_{show,store} should check if atadev is NULL. Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com> Cc: James Bottomley <JBottomley@Parallels.com> Cc: stable@kernel.org Signed-off-by: Jeff Garzik <jgarzik@redhat.com>

…eset The problem occurs when iptables constructs the tcp reset packet. It doesn't initialize the pointer to the tcp header within the skb. When the skb is passed to the ixgbe driver for transmit, the ixgbe driver attempts to access the tcp header and crashes. Currently, other drivers (such as our 1G e1000e or igb drivers) don't access the tcp header on transmit unless the TSO option is turned on. <1>BUG: unable to handle kernel NULL pointer dereference at 0000000d <1>IP: [<d081621c>] ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe] <4>*pdpt = 0000000085e5d001 *pde = 0000000000000000 <0>Oops: 0000 [#1] SMP [...] <4>Pid: 0, comm: swapper Tainted: P 2.6.35.12 #1 Greencity/Thurley <4>EIP: 0060:[<d081621c>] EFLAGS: 00010246 CPU: 16 <4>EIP is at ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe] <4>EAX: c7628820 EBX: 00000007 ECX: 00000000 EDX: 00000000 <4>ESI: 00000008 EDI: c6882180 EBP: dfc6b000 ESP: ced95c48 <4> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 <0>Process swapper (pid: 0, ti=ced94000 task=ced73bd0 task.ti=ced94000) <0>Stack: <4> cbec7418 c779e0d8 c77cc888 c77cc8a8 0903010a 00000000 c77c0008 00000002 <4><0> cd4997c0 00000010 dfc6b000 00000000 d0d176c9 c77cc8d8 c6882180 cbec7318 <4><0> 00000004 00000004 cbec7230 cbec7110 00000000 cbec70c0 c779e000 00000002 <0>Call Trace: <4> [<d0d176c9>] ? 0xd0d176c9 <4> [<d0d18a4d>] ? 0xd0d18a4d <4> [<411e243e>] ? dev_hard_start_xmit+0x218/0x2d7 <4> [<411f03d7>] ? sch_direct_xmit+0x4b/0x114 <4> [<411f056a>] ? __qdisc_run+0xca/0xe0 <4> [<411e28b0>] ? dev_queue_xmit+0x2d1/0x3d0 <4> [<411e8120>] ? neigh_resolve_output+0x1c5/0x20f <4> [<411e94a1>] ? neigh_update+0x29c/0x330 <4> [<4121cf29>] ? arp_process+0x49c/0x4cd <4> [<411f80c9>] ? nf_hook_slow+0x3f/0xac <4> [<4121ca8d>] ? arp_process+0x0/0x4cd <4> [<4121ca8d>] ? arp_process+0x0/0x4cd <4> [<4121c6d5>] ? T.901+0x38/0x3b <4> [<4121c918>] ? arp_rcv+0xa3/0xb4 <4> [<4121ca8d>] ? arp_process+0x0/0x4cd <4> [<411e1173>] ? __netif_receive_skb+0x32b/0x346 <4> [<411e19e1>] ? netif_receive_skb+0x5a/0x5f <4> [<411e1ea9>] ? napi_skb_finish+0x1b/0x30 <4> [<d0816eb4>] ? ixgbe_xmit_frame_ring+0x1564/0x2260 [ixgbe] <4> [<41013468>] ? lapic_next_event+0x13/0x16 <4> [<410429b2>] ? clockevents_program_event+0xd2/0xe4 <4> [<411e1b03>] ? net_rx_action+0x55/0x127 <4> [<4102da1a>] ? __do_softirq+0x77/0xeb <4> [<4102dab1>] ? do_softirq+0x23/0x27 <4> [<41003a67>] ? do_IRQ+0x7d/0x8e <4> [<41002a69>] ? common_interrupt+0x29/0x30 <4> [<41007bcf>] ? mwait_idle+0x48/0x4d <4> [<4100193b>] ? cpu_idle+0x37/0x4c <0>Code: df 09 d7 0f 94 c2 0f b6 d2 e9 e7 fb ff ff 31 db 31 c0 e9 38 ff ff ff 80 78 06 06 0f 85 3e fb ff ff 8b 7c 24 38 8b 8f b8 00 00 00 <0f> b6 51 0d f6 c2 01 0f 85 27 fb ff ff 80 e2 02 75 0d 8b 6c 24 <0>EIP: [<d081621c>] ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe] SS:ESP Signed-off-by: Mukund Jampala <jbmukund@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Sasha Levin recently reported a lockdep problem resulting from the new attribute propagation introduced by kmemcg series. In short, slab_mutex will be called from within the sysfs attribute store function. This will create a dependency, that will later be held backwards when a cache is destroyed - since destruction occurs with the slab_mutex held, and then calls in to the sysfs directory removal function. In this patch, I propose to adopt a strategy close to what __kmem_cache_create does before calling sysfs_slab_add, and release the lock before the call to sysfs_slab_remove. This is pretty much the last operation in the kmem_cache_shutdown() path, so we could do better by splitting this and moving this call alone to later on. This will fit nicely when sysfs handling is consistent between all caches, but will look weird now. Lockdep info: ====================================================== [ INFO: possible circular locking dependency detected ] 3.7.0-rc4-next-20121106-sasha-00008-g353b62f #117 Tainted: G W ------------------------------------------------------- trinity-child13/6961 is trying to acquire lock: (s_active#43){++++.+}, at: sysfs_addrm_finish+0x31/0x60 but task is already holding lock: (slab_mutex){+.+.+.}, at: kmem_cache_destroy+0x22/0xe0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (slab_mutex){+.+.+.}: lock_acquire+0x1aa/0x240 __mutex_lock_common+0x59/0x5a0 mutex_lock_nested+0x3f/0x50 slab_attr_store+0xde/0x110 sysfs_write_file+0xfa/0x150 vfs_write+0xb0/0x180 sys_pwrite64+0x60/0xb0 tracesys+0xe1/0xe6 -> #0 (s_active#43){++++.+}: __lock_acquire+0x14df/0x1ca0 lock_acquire+0x1aa/0x240 sysfs_deactivate+0x122/0x1a0 sysfs_addrm_finish+0x31/0x60 sysfs_remove_dir+0x89/0xd0 kobject_del+0x16/0x40 __kmem_cache_shutdown+0x40/0x60 kmem_cache_destroy+0x40/0xe0 mon_text_release+0x78/0xe0 __fput+0x122/0x2d0 ____fput+0x9/0x10 task_work_run+0xbe/0x100 do_exit+0x432/0xbd0 do_group_exit+0x84/0xd0 get_signal_to_deliver+0x81d/0x930 do_signal+0x3a/0x950 do_notify_resume+0x3e/0x90 int_signal+0x12/0x17 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slab_mutex); lock(s_active#43); lock(slab_mutex); lock(s_active#43); *** DEADLOCK *** 2 locks held by trinity-child13/6961: #0: (mon_lock){+.+.+.}, at: mon_text_release+0x25/0xe0 #1: (slab_mutex){+.+.+.}, at: kmem_cache_destroy+0x22/0xe0 stack backtrace: Pid: 6961, comm: trinity-child13 Tainted: G W 3.7.0-rc4-next-20121106-sasha-00008-g353b62f #117 Call Trace: print_circular_bug+0x1fb/0x20c __lock_acquire+0x14df/0x1ca0 lock_acquire+0x1aa/0x240 sysfs_deactivate+0x122/0x1a0 sysfs_addrm_finish+0x31/0x60 sysfs_remove_dir+0x89/0xd0 kobject_del+0x16/0x40 __kmem_cache_shutdown+0x40/0x60 kmem_cache_destroy+0x40/0xe0 mon_text_release+0x78/0xe0 __fput+0x122/0x2d0 ____fput+0x9/0x10 task_work_run+0xbe/0x100 do_exit+0x432/0xbd0 do_group_exit+0x84/0xd0 get_signal_to_deliver+0x81d/0x930 do_signal+0x3a/0x950 do_notify_resume+0x3e/0x90 int_signal+0x12/0x17 Signed-off-by: Glauber Costa <glommer@parallels.com> Reported-by: Sasha Levin <sasha.levin@oracle.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Pekka Enberg <penberg@kernel.org> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Sasha was fuzzing with trinity and reported the following problem: BUG: sleeping function called from invalid context at kernel/mutex.c:269 in_atomic(): 1, irqs_disabled(): 0, pid: 6361, name: trinity-main 2 locks held by trinity-main/6361: #0: (&mm->mmap_sem){++++++}, at: [<ffffffff810aa314>] __do_page_fault+0x1e4/0x4f0 #1: (&(&mm->page_table_lock)->rlock){+.+...}, at: [<ffffffff8122f017>] handle_pte_fault+0x3f7/0x6a0 Pid: 6361, comm: trinity-main Tainted: G W 3.7.0-rc2-next-20121024-sasha-00001-gd95ef01-dirty #74 Call Trace: __might_sleep+0x1c3/0x1e0 mutex_lock_nested+0x29/0x50 mpol_shared_policy_lookup+0x2e/0x90 shmem_get_policy+0x2e/0x30 get_vma_policy+0x5a/0xa0 mpol_misplaced+0x41/0x1d0 handle_pte_fault+0x465/0x6a0 This was triggered by a different version of automatic NUMA balancing but in theory the current version is vunerable to the same problem. do_numa_page -> numa_migrate_prep -> mpol_misplaced -> get_vma_policy -> shmem_get_policy It's very unlikely this will happen as shared pages are not marked pte_numa -- see the page_mapcount() check in change_pte_range() -- but it is possible. To address this, this patch restores sp->lock as originally implemented by Kosaki Motohiro. In the path where get_vma_policy() is called, it should not be calling sp_alloc() so it is not necessary to treat the PTL specially. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Tested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The missing NULL terminator can cause a panic on PPC405 boards during boot: Linux/PowerPC load: console=ttyS0,115200 root=/dev/mtdblock1 rootfstype=squashfs,jffs2 noinitrd init=/etc/preinit Finalizing device tree... flat tree at 0x6a5160 bootconsole [udbg0] enabled Page fault in user mode with in_atomic() = 1 mm = (null) NIP = c0275f50 MSR = fffffffe Oops: Weird page fault, sig: 11 [#1] PowerPC 40x Platform Modules linked in: NIP: c0275f50 LR: c0275f60 CTR: c0280000 REGS: c0275eb0 TRAP: 636f7265 Not tainted (3.7.1) MSR: fffffffe <VEC,VSX,EE,PR,FP,ME,SE,BE,IR,DR,PMM,RI> CR: c06a6190 XER: 00000001 TASK = c02662a8[0] 'swapper' THREAD: c0274000 GPR00: c0275ec0 c000c658 c027c4bf 00000000 c0275ee0 c000a0ec c020a1a8 c020a1f0 GPR08: c020f631 c020f404 c025f078 c025f080 c0275f10 Call Trace: ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill the idle task! The panic happens since commit 9597abe (sections: fix section conflicts in arch/powerpc), however the root cause of this is that the NULL terminator were not added in commit a4f740c (of/flattree: Add of_flat_dt_match() helper function). Cc: Grant Likely <grant.likely@secretlab.ca> Cc: <stable@vger.kernel.org> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

All boards, except Amstrad E3, mark USB config with __initdata. As a result, when you compile USB into modules, they will try to refer already released platform data and the behaviour is undefined. For example on Nokia 770, I get the following kernel panic when modprobing ohci-hcd: [ 3.462158] Unable to handle kernel paging request at virtual address e7fddef0 [ 3.477050] pgd = c3434000 [ 3.487365] [e7fddef0] *pgd=00000000 [ 3.498535] Internal error: Oops: 80000005 [#1] ARM [ 3.510955] Modules linked in: ohci_hcd(+) [ 3.522705] CPU: 0 Not tainted (3.7.0-770_tiny+ imx6-dongle#5) [ 3.535552] PC is at 0xe7fddef0 [ 3.546508] LR is at ohci_omap_init+0x5c/0x144 [ohci_hcd] [ 3.560272] pc : [<e7fddef0>] lr : [<bf003140>] psr: a0000013 [ 3.560272] sp : c344bdb0 ip : c344bce0 fp : c344bdcc [ 3.589782] r10: 00000001 r9 : 00000000 r8 : 00000000 [ 3.604553] r7 : 00000026 r6 : 000000de r5 : c0227300 r4 : c342d620 [ 3.621032] r3 : e7fddef0 r2 : c048b880 r1 : 00000000 r0 : 0000000a [ 3.637786] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 3.655822] Control: 0005317f Table: 13434000 DAC: 00000015 [ 3.672790] Process modprobe (pid: 425, stack limit = 0xc344a1b8) [ 3.690643] Stack: (0xc344bdb0 to 0xc344c000) [ 3.707031] bda0: bf0030e4 c342d620 00000000 c049e62c [ 3.727905] bdc0: c344be04 c344bdd0 c0150ff0 bf0030f4 bf001b88 00000000 c048a4ac c345b020 [ 3.748870] bde0: c342d620 00000000 c048a468 bf003968 00000001 bf006000 c344be34 c344be08 [ 3.769836] be00: bf001bf0 c0150e48 00000000 c344be18 c00b9bfc c048a478 c048a4ac bf0037f8 [ 3.790985] be20: c012ca04 c000e024 c344be44 c344be38 c012d968 bf001a84 c344be64 c344be48 [ 3.812164] be40: c012c8ac c012d95c 00000000 c048a478 c048a4ac bf0037f8 c344be84 c344be68 [ 3.833740] be60: c012ca74 c012c80c 20000013 00000000 c344be88 bf0037f8 c344beac c344be88 [ 3.855468] be80: c012b038 c012ca14 c38093cc c383ee10 bf0037f8 c35be5a0 c049d5e8 00000000 [ 3.877166] bea0: c344bebc c344beb0 c012c40c c012aff4 c344beec c344bec0 c012bfc0 c012c3fc [ 3.898834] bec0: bf00378c 00000000 c344beec bf0037f8 00067f39 00000000 00005c44 c000e024 [ 3.920837] bee0: c344bf14 c344bef0 c012cd54 c012befc c04ce080 00067f39 00000000 00005c44 [ 3.943023] bf00: c000e024 bf006000 c344bf24 c344bf18 c012db14 c012ccc0 c344bf3c c344bf28 [ 3.965423] bf20: bf00604c c012dad8 c344a000 bf003834 c344bf7c c344bf40 c00087ac bf006010 [ 3.987976] bf40: 0000000f bf003834 00067f39 00000000 00005c44 bf003834 00067f39 00000000 [ 4.010711] bf60: 00005c44 c000e024 c344a000 00000000 c344bfa4 c344bf80 c004c35c c0008720 [ 4.033569] bf80: c344bfac c344bf90 01422192 01427ea0 00000000 00000080 00000000 c344bfa8 [ 4.056518] bfa0: c000dec0 c004c2f0 01422192 01427ea0 01427ea0 00005c44 00067f39 00000000 [ 4.079406] bfc0: 01422192 01427ea0 00000000 00000080 b6e11008 014221aa be941fcc b6e1e008 [ 4.102569] bfe0: b6ef6300 be941758 0000e93c b6ef6310 60000010 01427ea0 00000000 00000000 [ 4.125946] Backtrace: [ 4.143463] [<bf0030e4>] (ohci_omap_init+0x0/0x144 [ohci_hcd]) from [<c0150ff0>] (usb_add_hcd+0x1b8/0x61c) [ 4.183898] r6:c049e62c r5:00000000 r4:c342d620 r3:bf0030e4 [ 4.205596] [<c0150e38>] (usb_add_hcd+0x0/0x61c) from [<bf001bf0>] (ohci_hcd_omap_drv_probe+0x17c/0x224 [ohci_hcd]) [ 4.248138] [<bf001a74>] (ohci_hcd_omap_drv_probe+0x0/0x224 [ohci_hcd]) from [<c012d968>] (platform_drv_probe+0x1c/0x20) [ 4.292144] r8:c000e024 r7:c012ca04 r6:bf0037f8 r5:c048a4ac r4:c048a478 [ 4.316192] [<c012d94c>] (platform_drv_probe+0x0/0x20) from [<c012c8ac>] (driver_probe_device+0xb0/0x208) [ 4.360168] [<c012c7fc>] (driver_probe_device+0x0/0x208) from [<c012ca74>] (__driver_attach+0x70/0x94) [ 4.405548] r6:bf0037f8 r5:c048a4ac r4:c048a478 r3:00000000 [ 4.429809] [<c012ca04>] (__driver_attach+0x0/0x94) from [<c012b038>] (bus_for_each_dev+0x54/0x90) [ 4.475708] r6:bf0037f8 r5:c344be88 r4:00000000 r3:20000013 [ 4.500366] [<c012afe4>] (bus_for_each_dev+0x0/0x90) from [<c012c40c>] (driver_attach+0x20/0x28) [ 4.528442] r7:00000000 r6:c049d5e8 r5:c35be5a0 r4:bf0037f8 [ 4.553466] [<c012c3ec>] (driver_attach+0x0/0x28) from [<c012bfc0>] (bus_add_driver+0xd4/0x228) [ 4.581878] [<c012beec>] (bus_add_driver+0x0/0x228) from [<c012cd54>] (driver_register+0xa4/0x134) [ 4.629730] r8:c000e024 r7:00005c44 r6:00000000 r5:00067f39 r4:bf0037f8 [ 4.656738] [<c012ccb0>] (driver_register+0x0/0x134) from [<c012db14>] (platform_driver_register+0x4c/0x60) [ 4.706542] [<c012dac8>] (platform_driver_register+0x0/0x60) from [<bf00604c>] (ohci_hcd_mod_init+0x4c/0x8c [ohci_hcd]) [ 4.757843] [<bf006000>] (ohci_hcd_mod_init+0x0/0x8c [ohci_hcd]) from [<c00087ac>] (do_one_initcall+0x9c/0x174) [ 4.808990] r4:bf003834 r3:c344a000 [ 4.832641] [<c0008710>] (do_one_initcall+0x0/0x174) from [<c004c35c>] (sys_init_module+0x7c/0x194) [ 4.881530] [<c004c2e0>] (sys_init_module+0x0/0x194) from [<c000dec0>] (ret_fast_syscall+0x0/0x2c) [ 4.930664] r7:00000080 r6:00000000 r5:01427ea0 r4:01422192 [ 4.956481] Code: bad PC value [ 4.978729] ---[ end trace 58280240f08342c4 ]--- [ 5.002258] Kernel panic - not syncing: Fatal exception Fix this by taking a copy of the data. Also mark Amstrad E3's data with __initdata to save some memory with multi-board kernels. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com>

Since commit e303297 ("mm: extended batches for generic mmu_gather") we are batching pages to be freed until either tlb_next_batch cannot allocate a new batch or we are done. This works just fine most of the time but we can get in troubles with non-preemptible kernel (CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY) on large machines where too aggressive batching might lead to soft lockups during process exit path (exit_mmap) because there are no scheduling points down the free_pages_and_swap_cache path and so the freeing can take long enough to trigger the soft lockup. The lockup is harmless except when the system is setup to panic on softlockup which is not that unusual. The simplest way to work around this issue is to limit the maximum number of batches in a single mmu_gather. 10k of collected pages should be safe to prevent from soft lockups (we would have 2ms for one) even if they are all freed without an explicit scheduling point. This patch doesn't add any new explicit scheduling points because it relies on zap_pmd_range during page tables zapping which calls cond_resched per PMD. The following lockup has been reported for 3.0 kernel with a huge process (in order of hundreds gigs but I do know any more details). BUG: soft lockup - CPU#56 stuck for 22s! [kernel:31053] Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc mptctl mptbase autofs4 binfmt_misc dm_round_robin dm_multipath bonding cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf microcode fuse loop osst sg sd_mod crc_t10dif st qla2xxx scsi_transport_fc scsi_tgt netxen_nic i7core_edac iTCO_wdt joydev e1000e serio_raw pcspkr edac_core iTCO_vendor_support acpi_power_meter rtc_cmos hpwdt hpilo button container usbhid hid dm_mirror dm_region_hash dm_log linear uhci_hcd ehci_hcd usbcore usb_common scsi_dh_emc scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh dm_snapshot pcnet32 mii edd dm_mod raid1 ext3 mbcache jbd fan thermal processor thermal_sys hwmon cciss scsi_mod Supported: Yes CPU 56 Pid: 31053, comm: kernel Not tainted 3.0.31-0.9-default #1 HP ProLiant DL580 G7 RIP: 0010: _raw_spin_unlock_irqrestore+0x8/0x10 RSP: 0018:ffff883ec1037af0 EFLAGS: 00000206 RAX: 0000000000000e00 RBX: ffffea01a0817e28 RCX: ffff88803ffd9e80 RDX: 0000000000000200 RSI: 0000000000000206 RDI: 0000000000000206 RBP: 0000000000000002 R08: 0000000000000001 R09: ffff887ec724a400 R10: 0000000000000000 R11: dead000000200200 R12: ffffffff8144c26e R13: 0000000000000030 R14: 0000000000000297 R15: 000000000000000e FS: 00007ed834282700(0000) GS:ffff88c03f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000068b240 CR3: 0000003ec13c5000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kernel (pid: 31053, threadinfo ffff883ec1036000, task ffff883ebd5d4100) Call Trace: release_pages+0xc5/0x260 free_pages_and_swap_cache+0x9d/0xc0 tlb_flush_mmu+0x5c/0x80 tlb_finish_mmu+0xe/0x50 exit_mmap+0xbd/0x120 mmput+0x49/0x120 exit_mm+0x122/0x160 do_exit+0x17a/0x430 do_group_exit+0x3d/0xb0 get_signal_to_deliver+0x247/0x480 do_signal+0x71/0x1b0 do_notify_resume+0x98/0xb0 int_signal+0x12/0x17 DWARF2 unwinder stuck at int_signal+0x12/0x17 Signed-off-by: Michal Hocko <mhocko@suse.cz> Cc: <stable@vger.kernel.org> [3.0+] Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug. Fixed the dma_sync_single_for_device() call to use the correct direction. [ 226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550() [ 226.288948] Hardware name: ProLiant DL380p Gen8 [ 226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE] [ 226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod [ 226.288967] Pid: 1055, comm: work_for_cpu Tainted: G W 3.3.0-0.20.el7.x86_64 #1 [ 226.288968] Call Trace: [ 226.288974] [<ffffffff810644cf>] warn_slowpath_common+0x7f/0xc0 [ 226.288977] [<ffffffff810645c6>] warn_slowpath_fmt+0x46/0x50 [ 226.288980] [<ffffffff81345502>] check_sync+0x132/0x550 [ 226.288983] [<ffffffff81345c9f>] debug_dma_sync_single_for_device+0x3f/0x50 [ 226.288988] [<ffffffff81661002>] ? wait_for_common+0x72/0x180 [ 226.288995] [<ffffffffa019590f>] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma] [ 226.288999] [<ffffffff811a5739>] ? kfree+0x259/0x270 [ 226.289004] [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma] [ 226.289008] [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma] [ 226.289011] [<ffffffffa0195f51>] ioat3_dma_probe+0x1d5/0x2aa [ioatdma] [ 226.289016] [<ffffffffa0194d12>] ioat_pci_probe+0x139/0x17c [ioatdma] [ 226.289020] [<ffffffff81354b8c>] local_pci_probe+0x5c/0xd0 [ 226.289023] [<ffffffff81083e50>] ? destroy_work_on_stack+0x20/0x20 [ 226.289025] [<ffffffff81083e68>] do_work_for_cpu+0x18/0x30 [ 226.289029] [<ffffffff8108d997>] kthread+0xb7/0xc0 [ 226.289033] [<ffffffff8166cef4>] kernel_thread_helper+0x4/0x10 [ 226.289036] [<ffffffff81662d20>] ? _raw_spin_unlock_irq+0x30/0x50 [ 226.289038] [<ffffffff81663234>] ? retint_restore_args+0x13/0x13 [ 226.289041] [<ffffffff8108d8e0>] ? kthread_worker_fn+0x1a0/0x1a0 [ 226.289044] [<ffffffff8166cef0>] ? gs_change+0x13/0x13 [ 226.289045] ---[ end trace e1618afc7a606089 ]--- [ 226.289047] Mapped at: [ 226.289048] [<ffffffff81345307>] debug_dma_map_page+0x87/0x150 [ 226.289050] [<ffffffffa019653c>] dma_map_page.constprop.18+0x70/0xb34 [ioatdma] [ 226.289054] [<ffffffffa0195702>] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma] [ 226.289058] [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma] [ 226.289061] [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma] Signed-off-by: Shuah Khan <shuah.khan@hp.com> CC: <stable@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>

Pursuant to this review https://lkml.org/lkml/2012/11/12/500 by Stefan Richter, update the TODO file. - Clarify purpose of TODO file - Remove firewire item imx6-dongle#4. As discussed in this conversation https://lkml.org/lkml/2012/11/13/564 knowing the AR buffer size is not a hard requirement. The required rx buffer size can be determined experimentally. - Remove firewire item imx6-dongle#5. This was a private note for further experimentation. - Change firewire item #1. Change suggested header from uapi header to kernel-only header. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The as-documented rcu_nocb_poll will fail to enable this feature for two reasons. (1) there is an extra "s" in the documented name which is not in the code, and (2) since it uses module_param, it really is expecting a prefix, akin to "rcutree.fanout_leaf" and the prefix isn't documented. However, there are several reasons why we might not want to simply fix the typo and add the prefix: 1) we'd end up with rcutree.rcu_nocb_poll, and rather probably make a change to rcutree.nocb_poll 2) if we did #1, then the prefix wouldn't be consistent with the rcu_nocbs=<cpumap> parameter (i.e. one with, one without prefix) 3) the use of module_param in a header file is less than desired, since it isn't immediately obvious that it will get processed via rcutree.c and get the prefix from that (although use of module_param_named() could clarify that.) 4) the implied export of /sys/module/rcutree/parameters/rcu_nocb_poll data to userspace via module_param() doesn't really buy us anything, as it is read-only and we can tell if it is enabled already without it, since there is a printk at early boot telling us so. In light of all that, just change it from a module_param() to an early_setup() call, and worry about adding it to /sys later on if we decide to allow a dynamic setting of it. Also change the variable to be tagged as read_mostly, since it will only ever be fiddled with at most, once at boot. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

The check in omap_musb_mailbox does not properly check if the module has been fully initialized. The patch fixes that, and the kernel panic below: $ modprobe twl4030-usb [ 13.924743] twl4030_usb twl4030-usb.33: HW_CONDITIONS 0xe0/224; link 3 [ 13.940307] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 13.948883] pgd = ef27c000 [ 13.951751] [00000004] *pgd=af256831, *pte=00000000, *ppte=00000000 [ 13.958374] Internal error: Oops: 17 [#1] ARM [ 13.962921] Modules linked in: twl4030_usb(+) omap2430 libcomposite [ 13.969543] CPU: 0 Not tainted (3.8.0-rc1-n9xx-11758-ge37a37c-dirty imx6-dongle#6) [ 13.976867] PC is at omap_musb_mailbox+0x18/0x54 [omap2430] [ 13.982727] LR is at twl4030_usb_probe+0x240/0x354 [twl4030_usb] [ 13.989013] pc : [<bf013b6c>] lr : [<bf018958>] psr: 60000013 [ 13.989013] sp : ef273cf0 ip : ef273d08 fp : ef273d04 [ 14.001068] r10: bf01b000 r9 : bf0191d8 r8 : 00000001 [ 14.006530] r7 : 00000000 r6 : ef140e10 r5 : 00000003 r4 : 00000000 [ 14.013397] r3 : bf0142dc r2 : 00000006 r1 : 00000000 r0 : 00000003 [ 14.020233] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 14.027740] Control: 10c5387d Table: af27c019 DAC: 00000015 [ 14.033752] Process modprobe (pid: 616, stack limit = 0xef272238) [ 14.040161] Stack: (0xef273cf0 to 0xef274000) [ 14.044708] 3ce0: ef254310 00000001 ef273d34 ef273d08 [ 14.053314] 3d00: bf018958 bf013b60 bf0190a4 ef254310 c0101550 c0c3a138 ef140e10 ef140e44 [ 14.061889] 3d20: bf019150 00000001 ef273d44 ef273d38 c019890c bf018724 ef273d64 ef273d48 [ 14.070495] 3d40: c01974fc c01988f8 ef140e10 bf019150 ef140e44 00000000 ef273d84 ef273d68 [ 14.079071] 3d60: c0197728 c019748c c0197694 00000000 bf019150 c0197694 ef273dac ef273d88 [ 14.087677] 3d80: c0195c38 c01976a0 ef03610c ef143eb0 c0128954 ef254780 bf019150 c0b19548 [ 14.096252] 3da0: ef273dbc ef273db0 c0197098 c0195bf0 ef273dec ef273dc0 c0196c98 c0197080 [ 14.104858] 3dc0: bf0190a4 c0b27bc0 ef273dec bf019150 bf019190 c0b27bc0 ef272000 00000001 [ 14.113433] 3de0: ef273e14 ef273df0 c0197c18 c0196b30 ef273f48 bf019190 c0b27bc0 ef272000 [ 14.122039] 3e00: 00000001 bf01b000 ef273e24 ef273e18 c0198b28 c0197ba4 ef273e34 ef273e28 [ 14.130615] 3e20: bf01b014 c0198ae8 ef273e8c ef273e38 c0008918 bf01b00c c004f730 c012ba1c [ 14.139221] 3e40: ef273e74 00000000 c00505b0 c004f72c 00000000 ef273e60 ef273f48 bf019190 [ 14.147796] 3e60: 00000001 ef273f48 bf019190 00000001 ef286340 00000001 bf0191d8 c0065414 [ 14.156402] 3e80: ef273f44 ef273e90 c0067754 c00087fc bf01919c 00007fff c0064794 00000000 [ 14.164978] 3ea0: ef273ecc f0064000 00000001 ef272000 ef272000 00067f39 bf0192b0 bf01919c [ 14.173583] 3ec0: ef273f0c ef273ed0 c00a6bf0 c00a53fc ff000000 000000d2 c0067dc8 00000000 [ 14.182159] 3ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 14.190765] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff 00002968 [ 14.199340] 3f20: 00080878 00067f39 00000080 c000e2e8 ef272000 00000000 ef273fa4 ef273f48 [ 14.207946] 3f40: c0067e54 c0066188 f0064000 00002968 f0065530 f0065463 f0065fb0 000012c4 [ 14.216522] 3f60: 00001664 00000000 00000000 00000000 00000014 00000015 0000000c 00000000 [ 14.225128] 3f80: 00000008 00000000 00000000 00080370 00080878 0007422c 00000000 ef273fa8 [ 14.233703] 3fa0: c000e140 c0067d80 00080370 00080878 00080878 00002968 00067f39 00000000 [ 14.242309] 3fc0: 00080370 00080878 0007422c 00000080 00074030 00067f39 bec7aef8 00000000 [ 14.250885] 3fe0: b6f05300 bec7ab68 0000e93c b6f05310 60000010 00080878 af7fe821 af7fec21 [ 14.259460] Backtrace: [ 14.262054] [<bf013b54>] (omap_musb_mailbox+0x0/0x54 [omap2430]) from [<bf018958>] (twl4030_usb_probe+0x240/0x354 [twl4030_usb]) [ 14.274200] r5:00000001 r4:ef254310 [ 14.277984] [<bf018718>] (twl4030_usb_probe+0x0/0x354 [twl4030_usb]) from [<c019890c>] (platform_drv_probe+0x20/0x24) [ 14.289123] r8:00000001 r7:bf019150 r6:ef140e44 r5:ef140e10 r4:c0c3a138 [ 14.296203] [<c01988ec>] (platform_drv_probe+0x0/0x24) from [<c01974fc>] (driver_probe_device+0x7c/0x214) [ 14.306243] [<c0197480>] (driver_probe_device+0x0/0x214) from [<c0197728>] (__driver_attach+0x94/0x98) [ 14.316009] r7:00000000 r6:ef140e44 r5:bf019150 r4:ef140e10 [ 14.321990] [<c0197694>] (__driver_attach+0x0/0x98) from [<c0195c38>] (bus_for_each_dev+0x54/0x88) [ 14.331390] r6:c0197694 r5:bf019150 r4:00000000 r3:c0197694 [ 14.337371] [<c0195be4>] (bus_for_each_dev+0x0/0x88) from [<c0197098>] (driver_attach+0x24/0x28) [ 14.346588] r6:c0b19548 r5:bf019150 r4:ef254780 [ 14.351440] [<c0197074>] (driver_attach+0x0/0x28) from [<c0196c98>] (bus_add_driver+0x174/0x244) [ 14.360687] [<c0196b24>] (bus_add_driver+0x0/0x244) from [<c0197c18>] (driver_register+0x80/0x154) [ 14.370086] r8:00000001 r7:ef272000 r6:c0b27bc0 r5:bf019190 r4:bf019150 [ 14.377136] [<c0197b98>] (driver_register+0x0/0x154) from [<c0198b28>] (platform_driver_register+0x4c/0x60) [ 14.387390] [<c0198adc>] (platform_driver_register+0x0/0x60) from [<bf01b014>] (twl4030_usb_init+0x14/0x1c [twl4030_usb]) [ 14.398895] [<bf01b000>] (twl4030_usb_init+0x0/0x1c [twl4030_usb]) from [<c0008918>] (do_one_initcall+0x128/0x1a8) [ 14.409790] [<c00087f0>] (do_one_initcall+0x0/0x1a8) from [<c0067754>] (load_module+0x15d8/0x1bf8) [ 14.419189] [<c006617c>] (load_module+0x0/0x1bf8) from [<c0067e54>] (sys_init_module+0xe0/0xf4) [ 14.428344] [<c0067d74>] (sys_init_module+0x0/0xf4) from [<c000e140>] (ret_fast_syscall+0x0/0x30) [ 14.437652] r6:0007422c r5:00080878 r4:00080370 [ 14.442504] Code: e24cb004 e59f3038 e1a05000 e593401c (e5940004) [ 14.448944] ---[ end trace dbf47e5bc5ba03c2 ]--- [ 14.453826] Kernel panic - not syncing: Fatal exception Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Felipe Balbi <balbi@ti.com>

Commit 5a50508 ("mm/rmap: Convert the struct anon_vma::mutex to an rwsem") turned anon_vma mutex to rwsem. However, the properly annotated nested locking in mm_take_all_locks() has been converted from mutex_lock_nest_lock(&anon_vma->root->mutex, &mm->mmap_sem); to down_write(&anon_vma->root->rwsem); which is incomplete, and causes the false positive report from lockdep below. Annotate the fact that mmap_sem is used as an outter lock to serialize taking of all the anon_vma rwsems at once no matter the order, using the down_write_nest_lock() primitive. This patch fixes this lockdep report: ============================================= [ INFO: possible recursive locking detected ] 3.8.0-rc2-00036-g5f73896 #171 Not tainted --------------------------------------------- qemu-kvm/2315 is trying to acquire lock: (&anon_vma->rwsem){+.+...}, at: mm_take_all_locks+0x149/0x1b0 but task is already holding lock: (&anon_vma->rwsem){+.+...}, at: mm_take_all_locks+0x149/0x1b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&anon_vma->rwsem); lock(&anon_vma->rwsem); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by qemu-kvm/2315: #0: (&mm->mmap_sem){++++++}, at: do_mmu_notifier_register+0xfc/0x170 #1: (mm_all_locks_mutex){+.+...}, at: mm_take_all_locks+0x36/0x1b0 imx6-dongle#2: (&mapping->i_mmap_mutex){+.+...}, at: mm_take_all_locks+0xc9/0x1b0 imx6-dongle#3: (&anon_vma->rwsem){+.+...}, at: mm_take_all_locks+0x149/0x1b0 stack backtrace: Pid: 2315, comm: qemu-kvm Not tainted 3.8.0-rc2-00036-g5f73896 #171 Call Trace: print_deadlock_bug+0xf2/0x100 validate_chain+0x4f6/0x720 __lock_acquire+0x359/0x580 lock_acquire+0x121/0x190 down_write+0x3f/0x70 mm_take_all_locks+0x149/0x1b0 do_mmu_notifier_register+0x68/0x170 mmu_notifier_register+0xe/0x10 kvm_create_vm+0x22b/0x330 [kvm] kvm_dev_ioctl+0xf8/0x1a0 [kvm] do_vfs_ioctl+0x9d/0x350 sys_ioctl+0x91/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Rik van Riel <riel@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mel Gorman <mel@csn.ul.ie> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Zhouping Liu reported the following against 3.8-rc1 when running a mmap testcase from LTP. mapcount 0 page_mapcount 3 ------------[ cut here ]------------ kernel BUG at mm/huge_memory.c:1798! invalid opcode: 0000 [#1] SMP Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables bnep bluetooth rfkill iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi vfat fat dm_mirror dm_region_hash dm_log dm_mod cdc_ether iTCO_wdt i7core_edac coretemp usbnet iTCO_vendor_support mii crc32c_intel edac_core lpc_ich shpchp ioatdma mfd_core i2c_i801 pcspkr serio_raw bnx2 microcode dca vhost_net tun macvtap macvlan kvm_intel kvm uinput mgag200 sr_mod cdrom i2c_algo_bit sd_mod drm_kms_helper crc_t10dif ata_generic pata_acpi ttm ata_piix drm libata i2c_core megaraid_sas CPU 1 Pid: 23217, comm: mmap10 Not tainted 3.8.0-rc1mainline+ imx6-dongle#17 IBM IBM System x3400 M3 Server -[7379I08]-/69Y4356 RIP: __split_huge_page+0x677/0x6d0 RSP: 0000:ffff88017a03fc08 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff88027a6c22e0 RCX: 00000000000034d2 RDX: 000000000000748b RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff88017a03fcb8 R08: ffffffff819d2440 R09: 000000000000054a R10: 0000000000aaaaaa R11: 00000000ffffffff R12: 0000000000000000 R13: 00007f4f11a00000 R14: ffff880179e96e00 R15: ffffea0005c08000 FS: 00007f4f11f4a740(0000) GS:ffff88017bc20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000037e9ebb404 CR3: 000000017a436000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process mmap10 (pid: 23217, threadinfo ffff88017a03e000, task ffff880172dd32e0) Stack: ffff88017a540ec8 ffff88017a03fc20 ffffffff816017b5 ffff88017a03fc88 ffffffff812fa014 0000000000000000 ffff880279ebd5c0 00000000f4f11a4c 00000007f4f11f49 00000007f4f11a00 ffff88017a540ef0 ffff88017a540ee8 Call Trace: split_huge_page+0x68/0xb0 __split_huge_page_pmd+0x134/0x330 split_huge_page_pmd_mm+0x51/0x60 split_huge_page_address+0x3b/0x50 __vma_adjust_trans_huge+0x9c/0xf0 vma_adjust+0x684/0x750 __split_vma.isra.28+0x1fa/0x220 do_munmap+0xf9/0x420 vm_munmap+0x4e/0x70 sys_munmap+0x2b/0x40 system_call_fastpath+0x16/0x1b Alexander Beregalov and Alex Xu reported similar bugs and Hillf Danton identified that commit 5a50508 ("mm/rmap: Convert the struct anon_vma::mutex to an rwsem") and commit 4fc3f1d ("mm/rmap, migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable") were likely the problem. Reverting these commits was reported to solve the problem for Alexander. Despite the reason for these commits, NUMA balancing is not the direct source of the problem. split_huge_page() expects the anon_vma lock to be exclusive to serialise the whole split operation. Ordinarily it is expected that the anon_vma lock would only be required when updating the avcs but THP also uses the anon_vma rwsem for collapse and split operations where the page lock or compound lock cannot be used (as the page is changing from base to THP or vice versa) and the page table locks are insufficient. This patch takes the anon_vma lock for write to serialise against parallel split_huge_page as THP expected before the conversion to rwsem. Reported-and-tested-by: Zhouping Liu <zliu@redhat.com> Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Reported-by: Alex Xu <alex_y_xu@yahoo.ca> Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mpc5121e doesn't have system interface registers, accessing this register address space cause the machine check exception and a kernel crash: ... Machine check in kernel mode. Caused by (from SRR1=49030): Transfer error ack signal Oops: Machine check, sig: 7 [#1] MPC5121 ADS Modules linked in: NIP: c025fd60 LR: c0265bb4 CTR: 00000000 REGS: df82dac0 TRAP: 0200 Not tainted (3.7.0-rc7-00641-g81e6c91) MSR: 00049030 <EE,ME,IR,DR> CR: 42002024 XER: 20000000 TASK = df824b70[1] 'swapper' THREAD: df82c000 GPR00: 00000000 df82db70 df824b70 df3ed0f0 00000003 00000000 00000000 00000000 GPR08: 00000020 32000000 c03550ec 20000000 22002028 00000000 c0003f5c 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0423898 c0450000 GPR24: 00000077 00000002 e5086180 1c000c00 e5086000 df33ec00 00000003 df34e000 NIP [c025fd60] ehci_fsl_setup_phy+0xd0/0x354 LR [c0265bb4] ehci_fsl_setup+0x220/0x284 ... Fix it by checking 'have_sysif_regs' flag before register access. Signed-off-by: Anatolij Gustschin <agust@denx.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

On systems where wd and amthif is not initialized we will hit cl->dev == NULL. This condition is okay so we don't need to be laud about it. Fixes the follwing warning during suspend [ 137.061985] WARNING: at drivers/misc/mei/client.c:315 mei_cl_unlink+0x86/0x90 [mei]() [ 137.061986] Hardware name: 530U3BI/530U4BI/530U4BH [ 137.062140] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek joydev coretemp kvm_intel snd_hda_intel snd_hda_codec kvm arc4 iwldvm snd_hwdep i915 snd_pcm mac80211 ghash_clmulni_intel snd_page_alloc aesni_intel snd_seq_midi xts snd_seq_midi_event aes_x86_64 rfcomm snd_rawmidi parport_pc bnep lrw snd_seq uvcvideo i2c_algo_bit ppdev gf128mul iwlwifi snd_timer drm_kms_helper ablk_helper cryptd drm snd_seq_device videobuf2_vmalloc psmouse videobuf2_memops snd cfg80211 btusb videobuf2_core soundcore videodev lp bluetooth samsung_laptop wmi microcode mei serio_raw mac_hid video hid_generic lpc_ich parport usbhid hid r8169 [ 137.062143] Pid: 2706, comm: kworker/u:15 Tainted: G D W 3.8.0-rc2-next20130109-1-iniza-generic #1 [ 137.062144] Call Trace: [ 137.062156] [<ffffffff8105860f>] warn_slowpath_common+0x7f/0xc0 [ 137.062159] [<ffffffff8135b1ea>] ? ioread32+0x3a/0x40 [ 137.062162] [<ffffffff8105866a>] warn_slowpath_null+0x1a/0x20 [ 137.062168] [<ffffffffa0076be6>] mei_cl_unlink+0x86/0x90 [mei] [ 137.062173] [<ffffffffa0071325>] mei_reset+0xc5/0x240 [mei] [ 137.062178] [<ffffffffa0073703>] mei_pci_resume+0xa3/0x110 [mei] [ 137.062183] [<ffffffff81379cae>] pci_pm_resume+0x7e/0xe0 [ 137.062185] [<ffffffff81379c30>] ? pci_pm_thaw+0x80/0x80 [ 137.062189] [<ffffffff8145a415>] dpm_run_callback.isra.6+0x25/0x50 [ 137.062192] [<ffffffff8145a6cf>] device_resume+0x9f/0x140 [ 137.062194] [<ffffffff8145a791>] async_resume+0x21/0x50 [ 137.062200] [<ffffffff810858b0>] async_run_entry_fn+0x90/0x1c0 [ 137.062203] [<ffffffff810778e5>] process_one_work+0x155/0x460 [ 137.062207] [<ffffffff81078578>] worker_thread+0x168/0x400 [ 137.062210] [<ffffffff81078410>] ? manage_workers+0x2b0/0x2b0 [ 137.062214] [<ffffffff8107d9f0>] kthread+0xc0/0xd0 [ 137.062218] [<ffffffff8107d930>] ? flush_kthread_worker+0xb0/0xb0 [ 137.062222] [<ffffffff816bac6c>] ret_from_fork+0x7c/0xb0 [ 137.062228] [<ffffffff8107d930>] ? flush_kthread_worker+0xb0/0xb0 Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

5d21cc2 ("cpuset: replace cgroup_mutex locking with cpuset internal locking") incorrectly converted proc_cpuset_show() from cgroup_lock() to cpuset_mutex. proc_cpuset_show() is accessing cgroup hierarchy proper to determine cgroup path which can't be protected by cpuset_mutex. This triggered the following RCU warning. =============================== [ INFO: suspicious RCU usage. ] 3.8.0-rc3-next-20130114-sasha-00016-ga107525-dirty #262 Tainted: G W ------------------------------- include/linux/cgroup.h:534 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by trinity/7514: #0: (&p->lock){+.+.+.}, at: [<ffffffff812b06aa>] seq_read+0x3a/0x3e0 #1: (cpuset_mutex){+.+...}, at: [<ffffffff811abae4>] proc_cpuset_show+0x84/0x190 stack backtrace: Pid: 7514, comm: trinity Tainted: G W +3.8.0-rc3-next-20130114-sasha-00016-ga107525-dirty #262 Call Trace: [<ffffffff81182cab>] lockdep_rcu_suspicious+0x10b/0x120 [<ffffffff811abb71>] proc_cpuset_show+0x111/0x190 [<ffffffff812b0827>] seq_read+0x1b7/0x3e0 [<ffffffff812b0670>] ? seq_lseek+0x110/0x110 [<ffffffff8128b4fb>] do_loop_readv_writev+0x4b/0x90 [<ffffffff8128b776>] do_readv_writev+0xf6/0x1d0 [<ffffffff8128b8ee>] vfs_readv+0x3e/0x60 [<ffffffff8128b960>] sys_readv+0x50/0xd0 [<ffffffff83d33d18>] tracesys+0xe1/0xe6 The operation can be performed under RCU read lock. Replace cpuset_mutex locking with RCU read locking. tj: Rewrote patch description. Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Li Zefan <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org>

Commit 85ff6ac (xen/granttable: Grant tables V2 implementation) changed the GREFS_PER_GRANT_FRAME macro from a constant to a conditional expression. The expression depends on grant_table_version being appropriately set. Unfortunately, at init time grant_table_version will be 0. The GREFS_PER_GRANT_FRAME conditional expression checks for "grant_table_version == 1", and therefore returns the number of grant references per frame for v2. This causes gnttab_init() to allocate fewer pages for gnttab_list, as a frame can old half the number of v2 entries than v1 entries. After gnttab_resume() is called, grant_table_version is appropriately set. nr_init_grefs will then be miscalculated and gnttab_free_count will hold a value larger than the actual number of free gref entries. If a guest is heavily utilizing improperly initialized v1 grant tables, memory corruption can occur. One common manifestation is corruption of the vmalloc list, resulting in a poisoned pointer derefrence when accessing /proc/meminfo or /proc/vmallocinfo: [ 40.770064] BUG: unable to handle kernel paging request at 0000200200001407 [ 40.770083] IP: [<ffffffff811a6fb0>] get_vmalloc_info+0x70/0x110 [ 40.770102] PGD 0 [ 40.770107] Oops: 0000 [#1] SMP [ 40.770114] CPU 10 This patch introduces a static variable, grefs_per_grant_frame, to cache the calculated value. gnttab_init() now calls gnttab_request_version() early so that grant_table_version and grefs_per_grant_frame can be appropriately set. A few BUG_ON()s have been added to prevent this type of bug from reoccurring in the future. Signed-off-by: Matt Wilson <msw@amazon.com> Reviewed-and-Tested-by: Steven Noonan <snoonan@amazon.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Annie Li <annie.li@oracle.com> Cc: xen-devel@lists.xen.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v3.3 and newer Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Since commit 89c8d91 ("tty: localise the lock") I see a dead lock in one of my dummy_hcd + g_nokia test cases. The first run was usually okay, the second often resulted in a splat by lockdep and the third was usually a dead lock. Lockdep complained about tty->hangup_work and tty->legacy_mutex taken both ways: | ====================================================== | [ INFO: possible circular locking dependency detected ] | 3.7.0-rc6+ #204 Not tainted | ------------------------------------------------------- | kworker/2:1/35 is trying to acquire lock: | (&tty->legacy_mutex){+.+.+.}, at: [<c14051e6>] tty_lock_nested+0x36/0x80 | | but task is already holding lock: | ((&tty->hangup_work)){+.+...}, at: [<c104f6e4>] process_one_work+0x124/0x5e0 | | which lock already depends on the new lock. | | the existing dependency chain (in reverse order) is: | | -> imx6-dongle#2 ((&tty->hangup_work)){+.+...}: | [<c107fe74>] lock_acquire+0x84/0x190 | [<c104d82d>] flush_work+0x3d/0x240 | [<c12e6986>] tty_ldisc_flush_works+0x16/0x30 | [<c12e7861>] tty_ldisc_release+0x21/0x70 | [<c12e0dfc>] tty_release+0x35c/0x470 | [<c1105e28>] __fput+0xd8/0x270 | [<c1105fcd>] ____fput+0xd/0x10 | [<c1051dd9>] task_work_run+0xb9/0xf0 | [<c1002a51>] do_notify_resume+0x51/0x80 | [<c140550a>] work_notifysig+0x35/0x3b | | -> #1 (&tty->legacy_mutex/1){+.+...}: | [<c107fe74>] lock_acquire+0x84/0x190 | [<c140276c>] mutex_lock_nested+0x6c/0x2f0 | [<c14051e6>] tty_lock_nested+0x36/0x80 | [<c1405279>] tty_lock_pair+0x29/0x70 | [<c12e0bb8>] tty_release+0x118/0x470 | [<c1105e28>] __fput+0xd8/0x270 | [<c1105fcd>] ____fput+0xd/0x10 | [<c1051dd9>] task_work_run+0xb9/0xf0 | [<c1002a51>] do_notify_resume+0x51/0x80 | [<c140550a>] work_notifysig+0x35/0x3b | | -> #0 (&tty->legacy_mutex){+.+.+.}: | [<c107f3c9>] __lock_acquire+0x1189/0x16a0 | [<c107fe74>] lock_acquire+0x84/0x190 | [<c140276c>] mutex_lock_nested+0x6c/0x2f0 | [<c14051e6>] tty_lock_nested+0x36/0x80 | [<c140523f>] tty_lock+0xf/0x20 | [<c12df8e4>] __tty_hangup+0x54/0x410 | [<c12dfcb2>] do_tty_hangup+0x12/0x20 | [<c104f763>] process_one_work+0x1a3/0x5e0 | [<c104fec9>] worker_thread+0x119/0x3a0 | [<c1055084>] kthread+0x94/0xa0 | [<c140ca37>] ret_from_kernel_thread+0x1b/0x28 | |other info that might help us debug this: | |Chain exists of: | &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work) | | Possible unsafe locking scenario: | | CPU0 CPU1 | ---- ---- | lock((&tty->hangup_work)); | lock(&tty->legacy_mutex/1); | lock((&tty->hangup_work)); | lock(&tty->legacy_mutex); | | *** DEADLOCK *** Before the path mentioned tty_ldisc_release() look like this: | tty_ldisc_halt(tty); | tty_ldisc_flush_works(tty); | tty_lock(); As it can be seen, it first flushes the workqueue and then grabs the tty_lock. Now we grab the lock first: | tty_lock_pair(tty, o_tty); | tty_ldisc_halt(tty); | tty_ldisc_flush_works(tty); so lockdep's complaint seems valid. The earlier version of this patch took the ldisc_mutex since the other user of tty_ldisc_flush_works() (tty_set_ldisc()) did this. Peter Hurley then said that it is should not be requried. Since it wasn't done earlier, I dropped this part. The code under tty_ldisc_kill() was executed earlier with the tty lock taken so it is taken again. I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the problem in my testcase. I didn't notice any problems so far. Cc: Alan Cox <alan@linux.intel.com> Cc: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The tty is NULL when the port is hanging up. chase_port() needs to check for this. This patch is intended for stable series. The behavior was observed and tested in Linux 3.2 and 3.7.1. Johan Hovold submitted a more elaborate patch for the mainline kernel. [ 56.277883] usb 1-1: edge_bulk_in_callback - nonzero read bulk status received: -84 [ 56.278811] usb 1-1: USB disconnect, device number 3 [ 56.278856] usb 1-1: edge_bulk_in_callback - stopping read! [ 56.279562] BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8 [ 56.280536] IP: [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35 [ 56.281212] PGD 1dc1b067 PUD 1e0f7067 PMD 0 [ 56.282085] Oops: 0002 [#1] SMP [ 56.282744] Modules linked in: [ 56.283512] CPU 1 [ 56.283512] Pid: 25, comm: khubd Not tainted 3.7.1 #1 innotek GmbH VirtualBox/VirtualBox [ 56.283512] RIP: 0010:[<ffffffff8144e62a>] [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35 [ 56.283512] RSP: 0018:ffff88001fa99ab0 EFLAGS: 00010046 [ 56.283512] RAX: 0000000000000046 RBX: 00000000000001c8 RCX: 0000000000640064 [ 56.283512] RDX: 0000000000010000 RSI: ffff88001fa99b20 RDI: 00000000000001c8 [ 56.283512] RBP: ffff88001fa99b20 R08: 0000000000000000 R09: 0000000000000000 [ 56.283512] R10: 0000000000000000 R11: ffffffff812fcb4c R12: ffff88001ddf53c0 [ 56.283512] R13: 0000000000000000 R14: 00000000000001c8 R15: ffff88001e19b9f4 [ 56.283512] FS: 0000000000000000(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000 [ 56.283512] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 56.283512] CR2: 00000000000001c8 CR3: 000000001dc51000 CR4: 00000000000006e0 [ 56.283512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 56.283512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 56.283512] Process khubd (pid: 25, threadinfo ffff88001fa98000, task ffff88001fa94f80) [ 56.283512] Stack: [ 56.283512] 0000000000000046 00000000000001c8 ffffffff810578ec ffffffff812fcb4c [ 56.283512] ffff88001e19b980 0000000000002710 ffffffff812ffe81 0000000000000001 [ 56.283512] ffff88001fa94f80 0000000000000202 ffffffff00000001 0000000000000296 [ 56.283512] Call Trace: [ 56.283512] [<ffffffff810578ec>] ? add_wait_queue+0x12/0x3c [ 56.283512] [<ffffffff812fcb4c>] ? usb_serial_port_work+0x28/0x28 [ 56.283512] [<ffffffff812ffe81>] ? chase_port+0x84/0x2d6 [ 56.283512] [<ffffffff81063f27>] ? try_to_wake_up+0x199/0x199 [ 56.283512] [<ffffffff81263a5c>] ? tty_ldisc_hangup+0x222/0x298 [ 56.283512] [<ffffffff81300171>] ? edge_close+0x64/0x129 [ 56.283512] [<ffffffff810612f7>] ? __wake_up+0x35/0x46 [ 56.283512] [<ffffffff8106135b>] ? should_resched+0x5/0x23 [ 56.283512] [<ffffffff81264916>] ? tty_port_shutdown+0x39/0x44 [ 56.283512] [<ffffffff812fcb4c>] ? usb_serial_port_work+0x28/0x28 [ 56.283512] [<ffffffff8125d38c>] ? __tty_hangup+0x307/0x351 [ 56.283512] [<ffffffff812e6ddc>] ? usb_hcd_flush_endpoint+0xde/0xed [ 56.283512] [<ffffffff8144e625>] ? _raw_spin_lock_irqsave+0x14/0x35 [ 56.283512] [<ffffffff812fd361>] ? usb_serial_disconnect+0x57/0xc2 [ 56.283512] [<ffffffff812ea99b>] ? usb_unbind_interface+0x5c/0x131 [ 56.283512] [<ffffffff8128d738>] ? __device_release_driver+0x7f/0xd5 [ 56.283512] [<ffffffff8128d9cd>] ? device_release_driver+0x1a/0x25 [ 56.283512] [<ffffffff8128d393>] ? bus_remove_device+0xd2/0xe7 [ 56.283512] [<ffffffff8128b7a3>] ? device_del+0x119/0x167 [ 56.283512] [<ffffffff812e8d9d>] ? usb_disable_device+0x6a/0x180 [ 56.283512] [<ffffffff812e2ae0>] ? usb_disconnect+0x81/0xe6 [ 56.283512] [<ffffffff812e4435>] ? hub_thread+0x577/0xe82 [ 56.283512] [<ffffffff8144daa7>] ? __schedule+0x490/0x4be [ 56.283512] [<ffffffff8105798f>] ? abort_exclusive_wait+0x79/0x79 [ 56.283512] [<ffffffff812e3ebe>] ? usb_remote_wakeup+0x2f/0x2f [ 56.283512] [<ffffffff812e3ebe>] ? usb_remote_wakeup+0x2f/0x2f [ 56.283512] [<ffffffff810570b4>] ? kthread+0x81/0x89 [ 56.283512] [<ffffffff81057033>] ? __kthread_parkme+0x5c/0x5c [ 56.283512] [<ffffffff8145387c>] ? ret_from_fork+0x7c/0xb0 [ 56.283512] [<ffffffff81057033>] ? __kthread_parkme+0x5c/0x5c [ 56.283512] Code: 8b 7c 24 08 e8 17 0b c3 ff 48 8b 04 24 48 83 c4 10 c3 53 48 89 fb 41 50 e8 e0 0a c3 ff 48 89 04 24 e8 e7 0a c3 ff ba 00 00 01 00 <f0> 0f c1 13 48 8b 04 24 89 d1 c1 ea 10 66 39 d1 74 07 f3 90 66 [ 56.283512] RIP [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35 [ 56.283512] RSP <ffff88001fa99ab0> [ 56.283512] CR2: 00000000000001c8 [ 56.283512] ---[ end trace 49714df27e1679ce ]--- Signed-off-by: Wolfgang Frisch <wfpub@roembden.net> Cc: Johan Hovold <jhovold@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Update efi_call_phys_prelog to install an identity mapping of all available memory. This corrects a bug on very large systems with more then 512 GB in which bios would not be able to access addresses above not in the mapping. The result is a crash that looks much like this. BUG: unable to handle kernel paging request at 000000effd870020 IP: [<0000000078bce331>] 0x78bce330 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU 0 Pid: 0, comm: swapper/0 Tainted: G W 3.8.0-rc1-next-20121224-medusa_ntz+ imx6-dongle#2 Intel Corp. Stoutland Platform RIP: 0010:[<0000000078bce331>] [<0000000078bce331>] 0x78bce330 RSP: 0000:ffffffff81601d28 EFLAGS: 00010006 RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004 RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000 RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030 R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000 FS: 0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400) Stack: 0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff 0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400 0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a Call Trace: [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83 [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed [<ffffffff81035946>] ? efi_call4+0x46/0x80 [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305 [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2 [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60 [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1 [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120 [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163 Code: Bad RIP value. RIP [<0000000078bce331>] 0x78bce330 RSP <ffffffff81601d28> CR2: 000000effd870020 ---[ end trace ead828934fef5eab ]--- Cc: stable@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Nathan Zimmer <nzimmer@sgi.com> Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>

Unlike the unlink path that is called from the VFS layer, we need to call d_delete() ourselves when a variable is deleted in efivarfs_file_write(). Failure to do so means we can access a stale struct efivar_entry when reading/writing the file, which can result in the following oops, [ 59.978216] general protection fault: 0000 [#1] SMP [ 60.038660] CPU 9 [ 60.040501] Pid: 1001, comm: cat Not tainted 3.7.0-2.fc19.x86_64 #1 IBM System x3550 M3 -[7944I21]-/69Y4438 [ 60.050840] RIP: 0010:[<ffffffff810d5d1e>] [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0 [ 60.059198] RSP: 0018:ffff880270595ce8 EFLAGS: 00010046 [ 60.064500] RAX: 0000000000000046 RBX: 0000000000000002 RCX: 0000000000000000 [ 60.071617] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6b83 [ 60.078735] RBP: ffff880270595dd8 R08: 0000000000000002 R09: 0000000000000000 [ 60.085852] R10: 6b6b6b6b6b6b6b83 R11: 0000000000000000 R12: 0000000000000000 [ 60.092971] R13: ffff88027170cd20 R14: 0000000000000000 R15: 0000000000000000 [ 60.100091] FS: 00007fc0c8ff3740(0000) GS:ffff880277000000(0000) knlGS:0000000000000000 [ 60.108164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.113899] CR2: 0000000001520000 CR3: 000000026d594000 CR4: 00000000000007e0 [ 60.121016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 60.128135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 60.135254] Process cat (pid: 1001, threadinfo ffff880270594000, task ffff88027170cd20) [ 60.143239] Stack: [ 60.145251] ffff880270595cf8 ffffffff81021da3 ffff880270595d08 ffffffff81021e19 [ 60.152714] ffff880270595d38 ffffffff810acdb5 ffff880200000168 0000000000000086 [ 60.160175] ffff88027170d5e8 ffffffff810d25ed ffff880270595d58 ffffffff810ace7f [ 60.167638] Call Trace: [ 60.170088] [<ffffffff81021da3>] ? native_sched_clock+0x13/0x80 [ 60.176085] [<ffffffff81021e19>] ? sched_clock+0x9/0x10 [ 60.181389] [<ffffffff810acdb5>] ? sched_clock_cpu+0xc5/0x120 [ 60.187211] [<ffffffff810d25ed>] ? trace_hardirqs_off+0xd/0x10 [ 60.193121] [<ffffffff810ace7f>] ? local_clock+0x6f/0x80 [ 60.198513] [<ffffffff810d2f6f>] ? lock_release_holdtime.part.26+0xf/0x180 [ 60.205465] [<ffffffff810d7b57>] ? lock_release_non_nested+0x2e7/0x320 [ 60.212073] [<ffffffff815638bb>] ? efivarfs_file_write+0x5b/0x280 [ 60.218242] [<ffffffff810d7f41>] lock_acquire+0xa1/0x1f0 [ 60.223633] [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280 [ 60.229892] [<ffffffff8118b47c>] ? might_fault+0x5c/0xb0 [ 60.235287] [<ffffffff816f1bf6>] _raw_spin_lock+0x46/0x80 [ 60.240762] [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280 [ 60.247018] [<ffffffff81563971>] efivarfs_file_write+0x111/0x280 [ 60.253103] [<ffffffff811d307f>] vfs_write+0xaf/0x190 [ 60.258233] [<ffffffff811d33d5>] sys_write+0x55/0xa0 [ 60.263278] [<ffffffff816fbd19>] system_call_fastpath+0x16/0x1b [ 60.269271] Code: 41 0f 45 d8 4c 89 75 f0 4c 89 7d f8 85 c0 0f 84 09 01 00 00 8b 05 a3 f9 ff 00 49 89 fa 41 89 f6 41 89 d3 85 c0 0f 84 12 01 00 00 <49> 8b 02 ba 01 00 00 00 48 3d a0 07 14 82 0f 44 da 41 83 fe 01 [ 60.289431] RIP [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0 [ 60.295444] RSP <ffff880270595ce8> [ 60.298928] ---[ end trace 1bbfd41a2cf6a0d8 ]--- Cc: Josh Boyer <jwboyer@redhat.com> Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Cc: Lee, Chun-Yi <jlee@suse.com> Cc: Andy Whitcroft <apw@canonical.com> Reported-by: Lingzhu Xiang <lxiang@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>

The 'intel_idle_probe' probes the CPU and sets the CPU notifier. But if later on during the module initialization we fail (say in cpuidle_register_driver), we stop loading, but we neglect to unregister the CPU notifier. This means that during CPU hotplug events the system will fail: calling intel_idle_init+0x0/0x326 @ 1 intel_idle: MWAIT substates: 0x1120 intel_idle: v0.4 model 0x2A intel_idle: lapic_timer_reliable_states 0xffffffff intel_idle: intel_idle yielding to none initcall intel_idle_init+0x0/0x326 returned -19 after 14 usecs ... some time later, offlining and onlining a CPU: cpu 3 spinlock event irq 62 BUG: unable to ] __cpuidle_register_device+0x1c/0x120 PGD 99b8b067 PUD 99b95067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: xen_evtchn nouveau mxm_wmi wmi radeon ttm i915 fbcon tileblit font atl1c bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 0 Pid: 2302, comm: udevd Not tainted 3.8.0-rc3upstream-00249-g09ad159 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[<ffffffff814d956c>] [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120 RSP: e02b:ffff88009dacfcb8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff880105380000 RCX: 000000000000001c RDX: 0000000000000000 RSI: 0000000000000055 RDI: ffff880105380000 RBP: ffff88009dacfce8 R08: ffffffff81a4f048 R09: 0000000000000008 R10: 0000000000000008 R11: 0000000000000000 R12: ffff880105380000 R13: 00000000ffffffdd R14: 0000000000000000 R15: ffffffff81a523d0 FS: 00007f37bd83b7a0(0000) GS:ffff880105200000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 00000000a09ea000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process udevd (pid: 2302, threadinfo ffff88009dace000, task ffff88009afb47f0) Stack: ffffffff8107f2d0 ffffffff810c2fb7 ffff88009dacfce8 00000000ffffffea ffff880105380000 00000000ffffffdd ffff88009dacfd08 ffffffff814d9882 0000000000000003 ffff880105380000 ffff88009dacfd28 ffffffff81340afd Call Trace: [<ffffffff8107f2d0>] ? collect_cpu_info_local+0x30/0x30 [<ffffffff810c2fb7>] ? __might_sleep+0xe7/0x100 [<ffffffff814d9882>] cpuidle_register_device+0x32/0x70 [<ffffffff81340afd>] intel_idle_cpu_init+0xad/0x110 [<ffffffff81340bc8>] cpu_hotplug_notify+0x68/0x80 [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70 [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30 [<ffffffff81652cf7>] _cpu_up+0x103/0x14b [<ffffffff81652e18>] cpu_up+0xd9/0xec [<ffffffff8164a254>] store_online+0x94/0xd0 [<ffffffff814122fb>] dev_attr_store+0x1b/0x20 [<ffffffff81216404>] sysfs_write_file+0xf4/0x170 [<ffffffff811a1024>] vfs_write+0xb4/0x130 [<ffffffff811a17ea>] sys_write+0x5a/0xa0 [<ffffffff816643a9>] system_call_fastpath+0x16/0x1b Code: 03 18 00 c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d e8 4c 89 65 f0 48 89 fb 4c 89 6d f8 e8 84 08 00 00 <48> 8b 78 08 49 89 c4 e8 f8 7f c1 ff 89 c2 b8 ea ff ff ff 84 d2 RIP [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120 RSP <ffff88009dacfcb8> This patch fixes that by moving the CPU notifier registration as the last item to be done by the module. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: 3.6+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If cpuidle is disabled, that means that: per_cpu(acpi_cpuidle_device, pr->id) is set to NULL as the acpi_processor_power_init ends up failing at retval = cpuidle_register_driver(&acpi_idle_driver) (in acpi_processor_power_init) and never sets the per_cpu idle device. So when acpi_processor_hotplug on CPU online notification tries to reference said device it crashes: cpu 3 spinlock event irq 62 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105 PGD a259b067 PUD ab38b067 PMD 0 Oops: 0002 [#1] SMP odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 1 Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[<ffffffff81381013>] [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105 RSP: e02b:ffff88001742dca8 EFLAGS: 00010202 RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000 RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800 RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200 R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800 R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0 FS: 00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000) Stack: 0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800 0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0 ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336 Call Trace: [<ffffffff813815b1>] acpi_processor_hotplug+0x7c/0x9f [<ffffffff810ae336>] ? schedule_delayed_work_on+0x16/0x20 [<ffffffff8137ee8f>] acpi_cpu_soft_notify+0x90/0xca [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70 [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30 [<ffffffff81652cf7>] _cpu_up+0x103/0x14b [<ffffffff81652e18>] cpu_up+0xd9/0xec [<ffffffff8164a254>] store_online+0x94/0xd0 [<ffffffff814122fb>] dev_attr_store+0x1b/0x20 [<ffffffff81216404>] sysfs_write_file+0xf4/0x170 This patch fixes it. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

devcgroup_css_free() calls dev_exception_clean() without the devcgroup_mutex being locked. Shutting down a kvm virt was giving me the following trace: [36280.732764] ------------[ cut here ]------------ [36280.732778] WARNING: at /home/snits/dev/linux/security/device_cgroup.c:172 dev_exception_clean+0xa9/0xc0() [36280.732782] Hardware name: Studio XPS 8100 [36280.732785] Modules linked in: xt_REDIRECT fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc nf_conntrack_ipv4 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter it87 hwmon_vid xt_state nf_conntrack ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq coretemp snd_seq_device crc32c_intel snd_pcm snd_page_alloc snd_timer snd broadcom tg3 serio_raw i7core_edac edac_core ptp pps_core lpc_ich pcspkr mfd_core soundcore microcode i2c_i801 nfsd auth_rpcgss nfs_acl lockd vhost_net sunrpc tun macvtap macvlan kvm_intel kvm uinput binfmt_misc autofs4 usb_storage firewire_ohci firewire_core crc_itu_t radeon drm_kms_helper ttm [36280.732921] Pid: 933, comm: libvirtd Tainted: G W 3.8.0-rc3-00307-g4c217de #1 [36280.732922] Call Trace: [36280.732927] [<ffffffff81044303>] warn_slowpath_common+0x93/0xc0 [36280.732930] [<ffffffff8104434a>] warn_slowpath_null+0x1a/0x20 [36280.732932] [<ffffffff812deaf9>] dev_exception_clean+0xa9/0xc0 [36280.732934] [<ffffffff812deb2a>] devcgroup_css_free+0x1a/0x30 [36280.732938] [<ffffffff810ccd76>] cgroup_diput+0x76/0x210 [36280.732941] [<ffffffff8119eac0>] d_delete+0x120/0x180 [36280.732943] [<ffffffff81195cff>] vfs_rmdir+0xef/0x130 [36280.732945] [<ffffffff81195e47>] do_rmdir+0x107/0x1c0 [36280.732949] [<ffffffff8132d17e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [36280.732951] [<ffffffff81198646>] sys_rmdir+0x16/0x20 [36280.732954] [<ffffffff8173bd82>] system_call_fastpath+0x16/0x1b [36280.732956] ---[ end trace ca39dced899a7d9f ]--- Signed-off-by: Jerry Snitselaar <jerry.snitselaar@oracle.com> Cc: stable@kernel.org Signed-off-by: James Morris <james.l.morris@oracle.com>

If some other kernel subsystem has a module notifier, and adds a kprobe to a ftrace mcount point (now that kprobes work on ftrace points), when the ftrace notifier runs it will fail and disable ftrace, as well as kprobes that are attached to ftrace points. Here's the error: WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280() Hardware name: Bochs Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared] Pid: 8068, comm: modprobe Tainted: GF 3.7.0-0.rc8.git0.1.fc19.x86_64 #1 Call Trace: [<ffffffff8105e70f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81134106>] ? __probe_kernel_read+0x46/0x70 [<ffffffffa0180000>] ? 0xffffffffa017ffff [<ffffffffa0180000>] ? 0xffffffffa017ffff [<ffffffff8105e76a>] warn_slowpath_null+0x1a/0x20 [<ffffffff810fd189>] ftrace_bug+0x239/0x280 [<ffffffff810fd626>] ftrace_process_locs+0x376/0x520 [<ffffffff810fefb7>] ftrace_module_notify+0x47/0x50 [<ffffffff8163912d>] notifier_call_chain+0x4d/0x70 [<ffffffff810882f8>] __blocking_notifier_call_chain+0x58/0x80 [<ffffffff81088336>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff810c2a23>] sys_init_module+0x73/0x220 [<ffffffff8163d719>] system_call_fastpath+0x16/0x1b ---[ end trace 9ef46351e53bbf80 ]--- ftrace failed to modify [<ffffffffa0180000>] init_once+0x0/0x20 [fat] actual: cc:bb:d2:4b:e1 A kprobe was added to the init_once() function in the fat module on load. But this happened before ftrace could have touched the code. As ftrace didn't run yet, the kprobe system had no idea it was a ftrace point and simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1). Then when ftrace went to modify the location from a call to mcount/fentry into a nop, it didn't see a call op, but instead it saw the breakpoint op and not knowing what to do with it, ftrace shut itself down. The solution is to simply give the ftrace module notifier the max priority. This should have been done regardless, as the core code ftrace modification also happens very early on in boot up. This makes the module modification closer to core modification. Link: http://lkml.kernel.org/r/20130107140333.593683061@goodmis.org Cc: stable@vger.kernel.org Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Reported-by: Frank Ch. Eigler <fche@redhat.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Bjørn Mork says: ==================== The 2 first patches in this series are required to make the Sierra Wireless MC7710 card work in MBIM mode. They may also be required for other Qualcomm firmware based MBIM devices. Patch #1 was previously posted as a standalone patch. This version is a replacement, removing a theoretical NULL pointer exception. Patch imx6-dongle#3 fixes a bug I introduced in v3.7 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>

Allow multiple listener sockets to bind to the same port. Motivation for soresuseport would be something like a web server binding to port 80 running with multiple threads, where each thread might have it's own listener socket. This could be done as an alternative to other models: 1) have one listener thread which dispatches completed connections to workers. 2) accept on a single listener socket from multiple threads. In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case imx6-dongle#2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets. We have seen the disproportion to be as high as 3:1 ratio between thread accepting most connections and the one accepting the fewest. With so_reusport the distribution is uniform. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>

Motivation for soreuseport would be something like a web server binding to port 80 running with multiple threads, where each thread might have it's own listener socket. This could be done as an alternative to other models: 1) have one listener thread which dispatches completed connections to workers. 2) accept on a single listener socket from multiple threads. In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case imx6-dongle#2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets. We have seen the disproportion to be as high as 3:1 ratio between thread accepting most connections and the one accepting the fewest. With so_reusport the distribution is uniform. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>

Tom Herbert says: ==================== This series implements so_reuseport (SO_REUSEPORT socket option) for TCP and UDP. For TCP, so_reuseport allows multiple listener sockets to be bound to the same port. In the case of UDP, so_reuseport allows multiple sockets to bind to the same port. To prevent port hijacking all sockets bound to the same port using so_reuseport must have the same uid. Received packets are distributed to multiple sockets bound to the same port using a 4-tuple hash. The motivating case for so_resuseport in TCP would be something like a web server binding to port 80 running with multiple threads, where each thread might have it's own listener socket. This could be done as an alternative to other models: 1) have one listener thread which dispatches completed connections to workers. 2) accept on a single listener socket from multiple threads. In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case imx6-dongle#2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets. We have seen the disproportion to be as high as 3:1 ratio between thread accepting most connections and the one accepting the fewest. With so_reusport the distribution is uniform. The TCP implementation has a problem in that the request sockets for a listener are attached to a listener socket. If a SYN is received, a listener socket is chosen and request structure is created (SYN-RECV state). If the subsequent ack in 3WHS does not match the same port by so_reusport, the connection state is not found (reset) and the request structure is orphaned. This scenario would occur when the number of listener sockets bound to a port changes (new ones are added, or old ones closed). We are looking for a solution to this, maybe allow multiple sockets to share the same request table... The motivating case for so_reuseport in UDP would be something like a DNS server. An alternative would be to recv on the same socket from multiple threads. As in the case of TCP, the load across these threads tends to be disproportionate and we also see a lot of contection on the socket lock. Note that SO_REUSEADDR already allows multiple UDP sockets to bind to the same port, however there is no provision to prevent hijacking and nothing to distribute packets across all the sockets sharing the same bound port. This patch does not change the semantics of SO_REUSEADDR, but provides usable functionality of it for unicast. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>

For drivers that don't actually flush their queues when aggregation stop with the IEEE80211_AMPDU_TX_STOP_FLUSH or IEEE80211_AMPDU_TX_STOP_FLUSH_CONT reasons is done, like iwlwifi or iwlegacy, mac80211 can then transmit on a TID that the driver still considers busy. This happens in the following way: - IEEE80211_AMPDU_TX_STOP_FLUSH requested - driver marks TID as emptying - mac80211 removes tid_tx data, this can copy packets to the TX pending queues and also let new packets through to the driver - driver gets unexpected TX as it wasn't completely converted to the new API In iwlwifi, this lead to the following warning: WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:442 iwlagn_tx_skb+0xc47/0xce0 Tx while agg.state = 4 Modules linked in: [...] Pid: 0, comm: kworker/0:0 Tainted: G W 3.1.0 #1 Call Trace: [<c1046e42>] warn_slowpath_common+0x72/0xa0 [<c1046f13>] warn_slowpath_fmt+0x33/0x40 [<fddffa17>] iwlagn_tx_skb+0xc47/0xce0 [iwldvm] [<fddfcaa3>] iwlagn_mac_tx+0x23/0x40 [iwldvm] [<fd8c98b6>] __ieee80211_tx+0xf6/0x3c0 [mac80211] [<fd8cbe00>] ieee80211_tx+0xd0/0x100 [mac80211] [<fd8cc176>] ieee80211_xmit+0x96/0xe0 [mac80211] [<fd8cc578>] ieee80211_subif_start_xmit+0x348/0xc80 [mac80211] [<c1445207>] dev_hard_start_xmit+0x337/0x6d0 [<c145eee9>] sch_direct_xmit+0xa9/0x210 [<c14462c0>] dev_queue_xmit+0x1b0/0x8e0 Fortunately, solving this problem is easy as the station is being destroyed, so such transmit packets can only happen due to races. Instead of trying to close the race just let the race not reach the drivers by making two changes: 1) remove the explicit aggregation session teardown in the managed mode code, the same thing will be done when the station is removed, in __sta_info_destroy. 2) When aggregation stop with AGG_STOP_DESTROY_STA is requested, leave the tid_tx data around as stopped. It will be cleared and freed in cleanup_single_sta later, but until then any racy packets will be put onto the tid_tx pending queue instead of transmitted which is fine since the station is being removed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>

device eth0 entered promiscuous mode BUG: sleeping function called from invalid context at mm/slub.c:930 in_atomic(): 1, irqs_disabled(): 0, pid: 5911, name: brctl INFO: lockdep is turned off. Pid: 5911, comm: brctl Tainted: GF W O 3.6.0-0.rc7.git1.4.fc18.x86_64 #1 Call Trace: [<ffffffff810a29ca>] __might_sleep+0x18a/0x240 [<ffffffff811b5d77>] __kmalloc+0x67/0x2d0 [<ffffffffa00a61a9>] ? qlcnic_alloc_lb_filters_mem+0x59/0xa0 [qlcnic] [<ffffffffa00a61a9>] qlcnic_alloc_lb_filters_mem+0x59/0xa0 [qlcnic] [<ffffffffa009e1c1>] qlcnic_set_multi+0x81/0x100 [qlcnic] [<ffffffff8159cccf>] __dev_set_rx_mode+0x5f/0xb0 [<ffffffff8159cd4f>] dev_set_rx_mode+0x2f/0x50 [<ffffffff8159d00c>] dev_set_promiscuity+0x3c/0x50 [<ffffffffa05ed728>] br_add_if+0x1e8/0x400 [bridge] [<ffffffffa05ee2df>] add_del_if+0x5f/0x90 [bridge] [<ffffffffa05eee0b>] br_dev_ioctl+0x4b/0x90 [bridge] [<ffffffff8159d613>] dev_ifsioc+0x373/0x3b0 [<ffffffff8159d78f>] dev_ioctl+0x13f/0x860 [<ffffffff812dd6e1>] ? avc_has_perm_flags+0x31/0x2c0 [<ffffffff8157c18d>] sock_do_ioctl+0x5d/0x70 [<ffffffff8157c21d>] sock_ioctl+0x7d/0x2c0 [<ffffffff812df922>] ? inode_has_perm.isra.48.constprop.61+0x62/0xa0 [<ffffffff811e4979>] do_vfs_ioctl+0x99/0x5a0 [<ffffffff812df9f7>] ? file_has_perm+0x97/0xb0 [<ffffffff810d716d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff811e4f19>] sys_ioctl+0x99/0xa0 [<ffffffff816e7369>] system_call_fastpath+0x16/0x1b br0: port 1(eth0) entered forwarding state br0: port 1(eth0) entered forwarding state Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>

commit f96972f "kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()" added a call to disable_nonboot_cpus() on kernel_restart(), which tries to shutdown all the CPUs except the first one. The issue with the PA Semi, is that it does not support CPU hotplug. When the call is made to __cpu_down(), it calls the notifiers CPU_DOWN_PREPARE, and then tries to take the CPU down. One of the notifiers to the CPU hotplug code, is the cpufreq. The DOWN_PREPARE will call __cpufreq_remove_dev() which calls cpufreq_driver->exit. The PA Semi exit handler unmaps regions of I/O that is used by an interrupt that goes off constantly (system_reset_common, but it goes off during normal system operations too). I'm not sure exactly what this interrupt does. Running a simple function trace, you can see it goes off quite a bit: # tracer: function # # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | <idle>-0 [001] 1558.859363: .pasemi_system_reset_exception <-.system_reset_exception <idle>-0 [000] 1558.860112: .pasemi_system_reset_exception <-.system_reset_exception <idle>-0 [000] 1558.861109: .pasemi_system_reset_exception <-.system_reset_exception <idle>-0 [001] 1558.861361: .pasemi_system_reset_exception <-.system_reset_exception <idle>-0 [000] 1558.861437: .pasemi_system_reset_exception <-.system_reset_exception When the region is unmapped, the system crashes with: Disabling non-boot CPUs ... Error taking CPU1 down: -38 Unable to handle kernel paging request for data at address 0xd0000800903a0100 Faulting instruction address: 0xc000000000055fcc Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=64 NUMA PA Semi PWRficient Modules linked in: shpchp NIP: c000000000055fcc LR: c000000000055fb4 CTR: c0000000000df1fc REGS: c0000000012175d0 TRAP: 0300 Not tainted (3.8.0-rc4-test-dirty) MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24000088 XER: 00000000 SOFTE: 0 DAR: d0000800903a0100, DSISR: 42000000 TASK = c0000000010e9008[0] 'swapper/0' THREAD: c000000001214000 CPU: 0 GPR00: d0000800903a0000 c000000001217850 c0000000012167e0 0000000000000000 GPR04: 0000000000000000 0000000000000724 0000000000000724 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000001 0000000000a70000 GPR12: 0000000024000080 c00000000fff0000 ffffffffffffffff 000000003ffffae0 GPR16: ffffffffffffffff 0000000000a21198 0000000000000060 0000000000000000 GPR20: 00000000008fdd35 0000000000a21258 000000003ffffaf0 0000000000000417 GPR24: 0000000000a226d0 c000000000000000 0000000000000000 0000000000000000 GPR28: c00000000138b358 0000000000000000 c000000001144818 d0000800903a0100 NIP [c000000000055fcc] .set_astate+0x5c/0xa4 LR [c000000000055fb4] .set_astate+0x44/0xa4 Call Trace: [c000000001217850] [c000000000055fb4] .set_astate+0x44/0xa4 (unreliable) [c0000000012178f0] [c00000000005647c] .restore_astate+0x2c/0x34 [c000000001217980] [c000000000054668] .pasemi_system_reset_exception+0x6c/0x88 [c000000001217a00] [c000000000019ef0] .system_reset_exception+0x48/0x84 [c000000001217a80] [c000000000001e40] system_reset_common+0x140/0x180 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

This patch reduces the critical section protected by sco_conn_lock in sco_conn_ready function. The lock is acquired only when it is really needed. This patch fixes the following lockdep warning which is generated when the host terminates a SCO connection. Today, this warning is a false positive. There is no way those two threads reported by lockdep are running at the same time since hdev->workqueue (where rx_work is queued) is single-thread. However, if somehow this behavior is changed in future, we will have a potential deadlock. ====================================================== [ INFO: possible circular locking dependency detected ] 3.8.0-rc1+ imx6-dongle#7 Not tainted ------------------------------------------------------- kworker/u:1H/1018 is trying to acquire lock: (&(&conn->lock)->rlock){+.+...}, at: [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] but task is already holding lock: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}: [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa003436e>] sco_connect_cfm+0xbe/0x350 [bluetooth] [<ffffffffa0015d6c>] hci_event_packet+0xd3c/0x29b0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 -> #0 (&(&conn->lock)->rlock){+.+...}: [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70 [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth] [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth] [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth] [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(&(&conn->lock)->rlock); lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(&(&conn->lock)->rlock); *** DEADLOCK *** 4 locks held by kworker/u:1H/1018: #0: (hdev->name#2){.+.+.+}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0 #1: ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0 imx6-dongle#2: (&hdev->lock){+.+.+.}, at: [<ffffffffa000fbe9>] hci_disconn_complete_evt.isra.54+0x59/0x3c0 [bluetooth] imx6-dongle#3: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth] stack backtrace: Pid: 1018, comm: kworker/u:1H Not tainted 3.8.0-rc1+ imx6-dongle#7 Call Trace: [<ffffffff813e92f9>] print_circular_bug+0x1fb/0x20c [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70 [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth] [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth] [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth] [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth] [<ffffffffa000fbd0>] ? hci_disconn_complete_evt.isra.54+0x40/0x3c0 [bluetooth] [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth] [<ffffffff81202e90>] ? __dynamic_pr_debug+0x80/0x90 [<ffffffff8133ff7d>] ? kfree_skb+0x2d/0x40 [<ffffffffa0021644>] ? hci_send_to_monitor+0x1a4/0x1c0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0 [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0 [<ffffffff8104fdc1>] ? worker_thread+0x51/0x3e0 [<ffffffffa0004450>] ? hci_tx_work+0x800/0x800 [bluetooth] [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff8104fd70>] ? busy_worker_rebind_fn+0x100/0x100 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0 Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

AlinaNova21 and others added 2 commits November 11, 2013 15:39

Added arm definitions in buildtar

f24766a

Merge remote-tracking branch 'upstream/imx_3.0.35_4.1.0-udoo' into im…

ec8d869

…x_3.0.35_4.1.0-udoo

projectgus and others added 2 commits November 18, 2013 16:59

MXC IPU: Replace wait_event with wait_event_interruptible

5b9e499

Having the 4 IPU tasks blocked on wait_event artificially inflates the load average by 4. wait_event_interruptible should be an acceptable alternative.

Merged Upstream

a9e28fb

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added arm definitions in buildtar#1

Added arm definitions in buildtar#1
AlinaNova21 wants to merge 4 commits into
mtx512:imx_3.0.35_4.1.0-udoofrom
AlinaNova21:imx_3.0.35_4.1.0-udoo

AlinaNova21 commented Nov 11, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

AlinaNova21 commented Nov 11, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants