- 30 May, 2018 40 commits
-
-
Govindarajulu Varadarajan authored
[ Upstream commit e8588e26 ] rq should be enabled before posting the buffers to rq desc. If not hw sees stale value and casuses DMAR errors. Signed-off-by:
Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yoshihiro Shimoda authored
[ Upstream commit 3e081628 ] This patch fixes an issue that a race condition happens between a client driver and the rcar-dmac driver: - The rcar_dmac_isr_transfer_end() is called. - The done list appears, and desc.running is the next active list. - rcar_dmac_chan_get_residue() is called by a client driver before rcar_dmac_isr_channel_thread() is called. - The rcar_dmac_chan_get_residue() will not find any descriptors. - And, the following WARNING happens: WARN(1, "No descriptor for cookie!"); The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this situation. So, this patch checks the done lists in rcar_dmac_chan_get_residue() and returns zero if the done lists has the argument cookie. Tested-by:
Nguyen Viet Dung <dung.nguyen.aj@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Qi Hou authored
[ Upstream commit a3ca8312 ] When booting up with "threadirqs" in command line, all irq handlers of the DMA controller pl330 will be threaded forcedly. These threads will race for the same list, pl330->req_done. Before the callback, the spinlock was released. And after it, the spinlock was taken. This opened an race window where another threaded irq handler could steal the spinlock and be permitted to delete entries of the list, pl330->req_done. If the later deleted an entry that was still referred to by the former, there would be a kernel panic when the former was scheduled and tried to get the next sibling of the deleted entry. The scenario could be depicted as below: Thread: T1 pl330->req_done Thread: T2 | | | | -A-B-C-D- | Locked | | | | Waiting Del A | | | -B-C-D- | Unlocked | | | | Locked Waiting | | | | Del B | | | | -C-D- Unlocked Waiting | | | Locked | get C via B \ - Kernel panic The kernel panic looked like as below: Unable to handle kernel paging request at virtual address dead000000000108 pgd = ffffff8008c9e000 [dead000000000108] *pgd=000000027fffe003, *pud=000000027fffe003, *pmd=0000000000000000 Internal error: Oops: 96000044 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 85 Comm: irq/59-66330000 Not tainted 4.8.24-WR9.0.0.12_standard #2 Hardware name: Broadcom NS2 SVK (DT) task: ffffffc1f5cc3c00 task.stack: ffffffc1f5ce0000 PC is at pl330_irq_handler+0x27c/0x390 LR is at pl330_irq_handler+0x2a8/0x390 pc : [<ffffff80084cb694>] lr : [<ffffff80084cb6c0>] pstate: 800001c5 sp : ffffffc1f5ce3d00 x29: ffffffc1f5ce3d00 x28: 0000000000000140 x27: ffffffc1f5c530b0 x26: dead000000000100 x25: dead000000000200 x24: 0000000000418958 x23: 0000000000000001 x22: ffffffc1f5ccd668 x21: ffffffc1f5ccd590 x20: ffffffc1f5ccd418 x19: dead000000000060 x18: 0000000000000001 x17: 0000000000000007 x16: 0000000000000001 x15: ffffffffffffffff x14: ffffffffffffffff x13: ffffffffffffffff x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000840 x9 : ffffffc1f5ce0000 x8 : ffffffc1f5cc3338 x7 : ffffff8008ce2020 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : dead000000000200 x2 : dead000000000100 x1 : 0000000000000140 x0 : ffffffc1f5ccd590 Process irq/59-66330000 (pid: 85, stack limit = 0xffffffc1f5ce0020) Stack: (0xffffffc1f5ce3d00 to 0xffffffc1f5ce4000) 3d00: ffffffc1f5ce3d80 ffffff80080f09d0 ffffffc1f5ca0c00 ffffffc1f6f7c600 3d20: ffffffc1f5ce0000 ffffffc1f6f7c600 ffffffc1f5ca0c00 ffffff80080f0998 3d40: ffffffc1f5ce0000 ffffff80080f0000 0000000000000000 0000000000000000 3d60: ffffff8008ce202c ffffff8008ce2020 ffffffc1f5ccd668 ffffffc1f5c530b0 3d80: ffffffc1f5ce3db0 ffffff80080f0d70 ffffffc1f5ca0c40 0000000000000001 3da0: ffffffc1f5ce0000 ffffff80080f0cfc ffffffc1f5ce3e20 ffffff80080bf4f8 3dc0: ffffffc1f5ca0c80 ffffff8008bf3798 ffffff8008955528 ffffffc1f5ca0c00 3de0: ffffff80080f0c30 0000000000000000 0000000000000000 0000000000000000 3e00: 0000000000000000 0000000000000000 0000000000000000 ffffff80080f0b68 3e20: 0000000000000000 ffffff8008083690 ffffff80080bf420 ffffffc1f5ca0c80 3e40: 0000000000000000 0000000000000000 0000000000000000 ffffff80080cb648 3e60: ffffff8008b1c780 0000000000000000 0000000000000000 ffffffc1f5ca0c00 3e80: ffffffc100000000 ffffff8000000000 ffffffc1f5ce3e90 ffffffc1f5ce3e90 3ea0: 0000000000000000 ffffff8000000000 ffffffc1f5ce3eb0 ffffffc1f5ce3eb0 3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000 3fe0: 0000000000000000 0000000000000000 0000000275ce3ff0 0000000275ce3ff8 Call trace: Exception stack(0xffffffc1f5ce3b30 to 0xffffffc1f5ce3c60) 3b20: dead000000000060 0000008000000000 3b40: ffffffc1f5ce3d00 ffffff80084cb694 0000000000000008 0000000000000e88 3b60: ffffffc1f5ce3bb0 ffffff80080dac68 ffffffc1f5ce3b90 ffffff8008826fe4 3b80: 00000000000001c0 00000000000001c0 ffffffc1f5ce3bb0 ffffff800848dfcc 3ba0: 0000000000020000 ffffff8008b15ae4 ffffffc1f5ce3c00 ffffff800808f000 3bc0: 0000000000000010 ffffff80088377f0 ffffffc1f5ccd590 0000000000000140 3be0: dead000000000100 dead000000000200 0000000000000001 0000000000000000 3c00: 0000000000000000 ffffff8008ce2020 ffffffc1f5cc3338 ffffffc1f5ce0000 3c20: 0000000000000840 0000000000000001 0000000000000000 ffffffffffffffff 3c40: ffffffffffffffff ffffffffffffffff 0000000000000001 0000000000000007 [<ffffff80084cb694>] pl330_irq_handler+0x27c/0x390 [<ffffff80080f09d0>] irq_forced_thread_fn+0x38/0x88 [<ffffff80080f0d70>] irq_thread+0x140/0x200 [<ffffff80080bf4f8>] kthread+0xd8/0xf0 [<ffffff8008083690>] ret_from_fork+0x10/0x40 Code: f2a00838 f9405763 aa1c03e1 aa1503e0 (f9000443) ---[ end trace f50005726d31199c ]--- Kernel panic - not syncing: Fatal exception in interrupt SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0-1 Kernel Offset: disabled Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception in interrupt To fix this, re-start with the list-head after dropping the lock then re-takeing it. Reviewed-by:
Frank Mori Hess <fmh6jj@gmail.com> Tested-by:
Qi Hou <qi.hou@windriver.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 2e2c177c ] In slave_update() of vmaster code ignores the error from the slave get() callback and copies the values. It's not only about the missing error code but also that this may potentially lead to a leak of uninitialized variables when the slave get() don't clear them. This patch fixes slave_update() not to copy the potentially uninitialized values when an error is returned from the slave get() callback, and to propagate the error value properly. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ivan Gorinov authored
[ Upstream commit 0a5169ad ] IRQ parameters for the SoC devices connected directly to I/O APIC lines (without PCI IRQ routing) may be specified in the Device Tree. Called from DT IRQ parser, irq_create_fwspec_mapping() calls irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg. But x86-specific DT IRQ allocation code casts @arg to of_phandle_args structure pointer and crashes trying to read the IRQ parameters. The function was not converted when the mapping descriptor was changed to irq_fwspec in the generic irqdomain code. Fixes: 11e4438e ("irqdomain: Introduce a firmware-specific IRQ specifier structure") Signed-off-by:
Ivan Gorinov <ivan.gorinov@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robh+dt@kernel.org> Link: https://lkml.kernel.org/r/a234dee27ea60ce76141872da0d6bdb378b2a9ee.1520450752.git.ivan.gorinov@intel.comSigned-off-by:
-
Ivan Gorinov authored
[ Upstream commit 628df9dc ] Commit 08d53aa5 added CRC32 calculation in early_init_dt_verify() and checking in late initcall of_fdt_raw_init(), making early_init_dt_verify() mandatory. The required call to early_init_dt_verify() was not added to the x86-specific implementation, causing failure to create the sysfs entry in of_fdt_raw_init(). Fixes: 08d53aa5 ("of/fdt: export fdt blob as /sys/firmware/fdt") Signed-off-by:
-
Andreas Gruenbacher authored
[ Upstream commit 174d1232 ] The chunk size of allocations in __gfs2_fallocate is calculated incorrectly. The size can collapse, causing __gfs2_fallocate to allocate one block at a time, which is very inefficient. This needs fixing in two places: In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate that there is no quota limit. This fixes callers that rely on ap->allowed to be set even when quotas are off. In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the loop to make sure that allocation limits from one resource group won't spill over into another resource group. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Bjorn Andersson authored
[ Upstream commit 90c29ed7 ] hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data. Instead use fragment size steps through the firmware blob. Fixes: ea7a1f27 ("soc: qcom: Introduce WCNSS_CTRL SMD client") Reported-by:
Will Newton <will.newton@gmail.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Ilia Lin authored
[ Upstream commit e723795c ] Set correct clocks and interrupt values. Fixes the incorrect SPI master configuration. This is mandatory to make the SPI5 interface functional. Signed-off-by:
Ilia Lin <ilialin@codeaurora.org> Signed-off-by:
-
Kan Liang authored
[ Upstream commit d31fc13f ] There is a bug when reading event->count with large PEBS enabled. Here is an example: # ./read_count 0x71f0 0x122c0 0x1000000001c54 0x100000001257d 0x200000000bdc5 In fixed period mode, the auto-reload mechanism could be enabled for PEBS events, but the calculation of event->count does not take the auto-reload values into account. Anyone who reads event->count will get the wrong result, e.g x86_pmu_read(). This bug was introduced with the auto-reload mechanism enabled since commit: 851559e3 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible") Introduce intel_pmu_save_and_restart_reload() to calculate the event->count only for auto-reload. Since the counter increments a negative counter value and overflows on the sign switch, giving the interval: [-period, 0] the difference between two consequtive reads is: A) value2 - value1; when no overflows have happened in between, B) (0 - value1) + (value2 - (-period)); when one overflow happened in between, C) (0 - value1) + (n - 1) * (period) + (value2 - (-period)); when @n overflows happened in between. Here A) is the obvious difference, B) is the extension to the discrete interval, where the first term is to the top of the interval and the second term is from the bottom of the next interval and C) the extension to multiple intervals, where the middle term is the whole intervals covered. The equation for all cases is: value2 - value1 + n * period Previously the event->count is updated right before the sample output. But for case A, there is no PEBS record ready. It needs to be specially handled. Remove the auto-reload code from x86_perf_event_set_period() since we'll not longer call that function in this case. Based-on-code-from: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: acme@kernel.org Fixes: 851559e3 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible") Link: http://lkml.kernel.org/r/1518474035-21006-2-git-send-email-kan.liang@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Kan Liang authored
[ Upstream commit f605cfca ] Large fixed period values could be truncated on Broadwell, for example: perf record -e cycles -c 10000000000 Here the fixed period is 0x2540BE400, but the period which finally applied is 0x540BE400 - which is wrong. The reason is that x86_pmu::limit_period() uses an u32 parameter, so the high 32 bits of 'period' get truncated. This bug was introduced in: commit 294fe0f5 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds") It's safe to use u64 instead of u32: - Although the 'left' is s64, the value of 'left' must be positive when calling limit_period(). - bdw_limit_period() only modifies the lowest 6 bits, it doesn't touch the higher 32 bits. Signed-off-by:
-
Maurizio Lombardi authored
[ Upstream commit 2bbea6e1 ] when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks. PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount" #0 [ffff880078447ae0] __schedule at ffffffff8168d605 #1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 #2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 #3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef #4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] #5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 #6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 #7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] #8 [ffff880078447da8] mount_bdev at ffffffff81202570 #9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs] #10 [ffff880078447e28] mount_fs at ffffffff81202d09 #11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f #12 [ffff880078447ea8] do_mount at ffffffff81220fee #13 [ffff880078447f28] sys_mount at ffffffff812218d6 #14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49 RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246 RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010 RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30 RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010 R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040 R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30 ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b This task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock. PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd" #0 [ffff880078417898] __schedule at ffffffff8168d605 #1 [ffff880078417900] schedule at ffffffff8168dc59 #2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 #3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 #4 [ffff8800784179d0] down_read at ffffffff8168cde0 #5 [ffff8800784179e8] get_super at ffffffff81201cc7 #6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de #7 [ffff880078417a40] flush_disk at ffffffff8123a94b #8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 #9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom] #10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] #11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86 #12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65 #13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b #14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf #16 [ffff880078417d00] do_last at ffffffff8120d53d #17 [ffff880078417db0] path_openat at ffffffff8120e6b2 #18 [ffff880078417e48] do_filp_open at ffffffff8121082b #19 [ffff880078417f18] do_sys_open at ffffffff811fdd33 #20 [ffff880078417f70] sys_open at ffffffff811fde4e #21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49 RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246 RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000 RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70 RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020 R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010 ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b This task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device. As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device. This was the same super_block as created and locked by the previous task. The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock. This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Kan Liang authored
[ Upstream commit 82d71ed0 ] The PMU is disabled in intel_pmu_handle_irq(), but cpuc->enabled is not updated accordingly. This is fine in current usage because no-one checks it - but fix it for future code: for example, the drain_pebs() will be modified to fix an auto-reload bug. Properly save/restore the old PMU state. Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit ecb29abd ] A negative page register value means that no page needs to be selected. This is used by status register read operations and needs to be accepted. The failure to do so so results in missed status and limit registers. Fixes: da8e48ab ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit a46f8cd6 ] A negative page register value means that no page needs to be selected. This is used by status register evaluations and needs to be accepted. Fixes: da8e48ab ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver") Signed-off-by:
-
Eric Anholt authored
[ Upstream commit 5651e5e0 ] This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel. Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: e8b6f561 ("drm/panel: simple: Add the 7" DPI panel from Adafruit") Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180309233332.1769-1-eric@anholt.netSigned-off-by:
-
Peter Zijlstra authored
[ Upstream commit 9e5b127d ] Mark reported his arm64 perf fuzzer runs sometimes splat like: armv8pmu_read_counter+0x1e8/0x2d8 armpmu_event_update+0x8c/0x188 armpmu_read+0xc/0x18 perf_output_read+0x550/0x11e8 perf_event_read_event+0x1d0/0x248 perf_event_exit_task+0x468/0xbb8 do_exit+0x690/0x1310 do_group_exit+0xd0/0x2b0 get_signal+0x2e8/0x17a8 do_signal+0x144/0x4f8 do_notify_resume+0x148/0x1e8 work_pending+0x8/0x14 which asserts that we only call pmu::read() on ACTIVE events. The above callchain does: perf_event_exit_task() perf_event_exit_task_context() task_ctx_sched_out() // INACTIVE perf_event_exit_event() perf_event_set_state(EXIT) // EXIT sync_child_event() perf_event_read_event() perf_output_read() perf_output_read_group() leader->pmu->read() Which results in doing a pmu::read() on an !ACTIVE event. I _think_ this is 'new' since we added attr.inherit_stat, which added the perf_event_read_event() to the exit path, without that perf_event_read_output() would only trigger from samples and for @event to trigger a sample, it's leader _must_ be ACTIVE too. Still, adding this check makes it consistent with the @sub case for the siblings. Reported-and-Tested-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Chao Yu authored
[ Upstream commit bf617f7a ] If noextent_cache mount option is on, we will never initialize extent tree in inode, but still we're going to access it in f2fs_drop_extent_tree, result in kernel panic as below: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: _raw_write_lock+0xc/0x30 Call Trace: ? f2fs_drop_extent_tree+0x41/0x70 [f2fs] f2fs_fallocate+0x5a0/0xdd0 [f2fs] ? common_file_perm+0x47/0xc0 ? apparmor_file_permission+0x1a/0x20 vfs_fallocate+0x15b/0x290 SyS_fallocate+0x44/0x70 do_syscall_64+0x6e/0x160 entry_SYSCALL64_slow_path+0x25/0x25 This patch fixes to check extent cache status before using in f2fs_drop_extent_tree. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Mathieu Malaterre authored
[ Upstream commit f5246862 ] In commit 4f8b50bb ("irq_work, ppc: Fix up arch hooks") a new function arch_irq_work_raise() was added without a prototype in header irq_work.h. Fix the following warning (treated as error in W=1): arch/powerpc/kernel/time.c:523:6: error: no previous prototype for ‘arch_irq_work_raise’ Signed-off-by:
Mathieu Malaterre <malat@debian.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Kamlakant Patel authored
[ Upstream commit f002612b ] This happens when BMC doesn't return any data and the code is trying to print the value of data[2]. Getting following crash: [ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002 [ 484.736496] pgd = ffff0000094a2000 [ 484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000 [ 484.748158] Internal error: Oops: 96000005 [#1] SMP [...] [ 485.101451] Call trace: [...] [ 485.188473] [<ffff000000a46e68>] msg_done_handler+0x668/0x700 [ipmi_ssif] [ 485.195249] [<ffff000000a456b8>] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif] [ 485.202038] [<ffff0000080f1430>] kthread+0x108/0x138 [ 485.206994] [<ffff0000080838e0>] ret_from_fork+0x10/0x30 [ 485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3) Adding a check to validate the data len before printing data[2] to fix this issue. Signed-off-by:
Kamlakant Patel <kamlakant.patel@cavium.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 5775b843 ] We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child goes to D3cold, its internal state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost. One example are recent hybrid graphics laptops which cut power to the discrete GPU when the root port above it goes to ACPI power state D3. Users may provoke this by unbinding the GPU driver and allowing runtime PM on the GPU via sysfs: The PM core will then treat the GPU as "suspended", which in turn allows the root port to runtime suspend, causing the power resources listed in its _PR3 object to be powered off. The GPU's BARs will be uninitialized when a driver later probes it. Another example are hybrid graphics laptops where the GPU itself (rather than the root port) is capable of runtime suspending to D3cold. If the GPU's integrated HDA controller is not bound and the GPU's driver decides to runtime suspend to D3cold, the HDA controller's BARs will be uninitialized when a driver later probes it. Fix by saving and restoring config space over a runtime suspend cycle even if the device is not bound. Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Tested-by: Peter Wu <peter@lekensteyn.nl> # Nvidia Optimus Tested-by: Lukas Wunner <lukas@wunner.de> # MacBook Pro Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> [lukas: add commit message, bikeshed code comments for clarity] Signed-off-by:
Lukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.deSigned-off-by:
-
Mathias Kresin authored
[ Upstream commit 05454c1b ] According to the QCA u-boot source the "PCIE Phase Lock Loop Configuration (PCIE_PLL_CONFIG)" register is for all SoCs except the QCA955X and QCA956X at offset 0x10. Since the PCIE PLL config register is only defined for the AR724x fix only this value. The value is wrong since the day it was added and isn't used by any driver yet. Signed-off-by:
Mathias Kresin <dev@kresin.me> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16048/Signed-off-by:
James Hogan <jhogan@kernel.org> Signed-off-by:
-
Christophe Jaillet authored
[ Upstream commit bc3cc752 ] For some reason, commit c0368e4d ("spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path") has updated some gotos, but not all of them. This looks spurious, so fix it. Fixes: fa236a7e ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Christophe Jaillet authored
[ Upstream commit ed8cffda ] Re-order error handling code and gotos to avoid leaks in error handling paths. Fixes: 9f946099 ("regulator: gpio: fix parsing of gpio list") Signed-off-by:
-
Parav Pandit authored
[ Upstream commit 563c4ba3 ] ah_attr contains the port number to which cm_id is bound. However, while searching for GID table for matching GID entry, the port number is ignored. This could cause the wrong GID to be used when the ah_attr is converted to an AH. Reviewed-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Thomas Richter authored
[ Upstream commit fca32340 ] Executing command 'perf stat -T -- ls' dumps core on x86 and s390. Here is the call back chain (done on x86): # gdb ./perf .... (gdb) r stat -T -- ls ... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6 #1 0x00007ffff56ae484 in asprintf () from /lib64/libc.so.6 #2 0x00000000004f1982 in __parse_events_add_pmu (parse_state=0x7fffffffd580, list=0xbfb970, name=0xbf3ef0 "cpu", head_config=0xbfb930, auto_merge_stats=false) at util/parse-events.c:1233 #3 0x00000000004f1c8e in parse_events_add_pmu (parse_state=0x7fffffffd580, list=0xbfb970, name=0xbf3ef0 "cpu", head_config=0xbfb930) at util/parse-events.c:1288 #4 0x0000000000537ce3 in parse_events_parse (_parse_state=0x7fffffffd580, scanner=0xbf4210) at util/parse-events.y:234 #5 0x00000000004f2c7a in parse_events__scanner (str=0x6b66c0 "task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", parse_state=0x7fffffffd580, start_token=258) at util/parse-events.c:1673 #6 0x00000000004f2e23 in parse_events (evlist=0xbe9990, str=0x6b66c0 "task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", err=0x0) at util/parse-events.c:1713 #7 0x000000000044e137 in add_default_attributes () at builtin-stat.c:2281 #8 0x000000000044f7b5 in cmd_stat (argc=1, argv=0x7fffffffe3b0) at builtin-stat.c:2828 #9 0x00000000004c8b0f in run_builtin (p=0xab01a0 <commands+288>, argc=4, argv=0x7fffffffe3b0) at perf.c:297 #10 0x00000000004c8d7c in handle_internal_command (argc=4, argv=0x7fffffffe3b0) at perf.c:349 #11 0x00000000004c8ece in run_argv (argcp=0x7fffffffe20c, argv=0x7fffffffe200) at perf.c:393 #12 0x00000000004c929c in main (argc=4, argv=0x7fffffffe3b0) at perf.c:537 (gdb) It turns out that a NULL pointer is referenced. Here are the function calls: ... cmd_stat() +---> add_default_attributes() +---> parse_events(evsel_list, transaction_attrs, NULL); 3rd parameter set to NULL Function parse_events(xx, xx, struct parse_events_error *err) dives into a bison generated scanner and creates parser state information for it first: struct parse_events_state parse_state = { .list = LIST_HEAD_INIT(parse_state.list), .idx = evlist->nr_entries, .error = err, <--- NULL POINTER !!! .evlist = evlist, }; Now various functions inside the bison scanner are called to end up in __parse_events_add_pmu(struct parse_events_state *parse_state, ..) with first parameter being a pointer to above structure definition. Now the PMU event name is not found (because being executed in a VM) and this function tries to create an error message with asprintf(&parse_state->error.str, ....) which references a NULL pointer and dumps core. Fix this by providing a pointer to the necessary error information instead of NULL. Technically only the else part is needed to avoid the core dump, just lets be safe... Signed-off-by:
Thomas Richter <tmricht@linux.vnet.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/20180308145735.64717-1-tmricht@linux.vnet.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Yisheng Xie authored
[ Upstream commit a3a4a3b3 ] When trying to add the "call-graph" variable for top into the .perfconfig file, like: [top] call-graph = fp I that perf_top_config() do not parse this variable. Fix it by calling perf_default_config() when the top.call-graph variable is set. Signed-off-by:
Yisheng Xie <xieyisheng1@huawei.com> Tested-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 0bcc3fb9 ] Devices which use level-triggered interrupts under Windows 2016 with Hyper-V role enabled don't work: Windows disables EOI broadcast in SPIV unconditionally. Our in-kernel IOAPIC implementation emulates an old IOAPIC version which has no EOI register so EOI never happens. The issue was discovered and discussed a while ago: https://www.spinics.net/lists/kvm/msg148098.html While this is a guest OS bug (it should check that IOAPIC has the required capabilities before disabling EOI broadcast) we can workaround it in KVM: advertising DIRECTED_EOI with in-kernel IOAPIC makes little sense anyway. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit 31184d8c ] The errata FE-8471889 description has been updated. There is still a timing violation for repeated start. But the errata now states that it was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz) there is no issue. This patch limit the errata fix to the Standard mode. It has been tesed successfully on the clearfog (Aramda 388 based board). Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Arjun Vynipadath authored
[ Upstream commit d7cb4449 ] Setting sge_uld_rxq_info to NULL in free_queues_uld(). We are referencing sge_uld_rxq_info in cxgb_up(). This will fix a panic when interface is brought up after a ULDq creation failure. Fixes: 94cdb8bb (cxgb4: Add support for dynamic allocation of resources for ULD) Signed-off-by:
Arjun Vynipadath <arjun@chelsio.com> Signed-off-by:
Casey Leedom <leedom@chelsio.com> Signed-off-by:
Ganesh Goudhar <ganeshgr@chelsio.com> Signed-off-by:
-
Seunghun Han authored
[ Upstream commit 97f3c0a4 ] I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.464168] ACPI: Added _OSI(Module Device) >[ 0.467022] ACPI: Added _OSI(Processor Device) >[ 0.469376] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.471647] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) >[ 0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461) >[ 0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.497683] ACPI: Interpreter enabled >[ 0.499385] ACPI: (supports S0) >[ 0.501151] ACPI: Using IOAPIC for interrupt routing >[ 0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) >[ 0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461) >[ 0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991) >[ 0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.526795] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.529668] Call Trace: >[ 0.530811] ? dump_stack+0x5c/0x81 >[ 0.532240] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.533905] ? acpi_os_delete_cache+0xa/0x10 >[ 0.535497] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.537237] ? acpi_terminate+0xa/0x14 >[ 0.538701] ? acpi_init+0x2af/0x34f >[ 0.540008] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.541593] ? do_one_initcall+0x4e/0x1a0 >[ 0.543008] ? kernel_init_freeable+0x19e/0x21f >[ 0.546202] ? rest_init+0x80/0x80 >[ 0.547513] ? kernel_init+0xa/0x100 >[ 0.548817] ? ret_from_fork+0x25/0x30 >[ 0.550587] vgaarb: loaded >[ 0.551716] EDAC MC: Ver: 3.0.0 >[ 0.553744] PCI: Probing PCI hardware >[ 0.555038] PCI host bridge to bus 0000:00 > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ns_evaluate() function only removes Info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->return_object is also not null. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Signed-off-by:
Seunghun Han <kkamagui@gmail.com> Signed-off-by:
Erik Schmauss <erik.schmauss@intel.com> Signed-off-by:
-
Erik Schmauss authored
[ Upstream commit b4c0de31 ] This ensures that acpi_ev_fixed_event_detect() does not use fixed_status and and fixed_enable as uninitialized variables. Signed-off-by:
-
Coly Li authored
[ Upstream commit fadd94e0 ] In patch "bcache: fix cached_dev->count usage for bch_cache_set_error()", cached_dev_get() is called when creating dc->writeback_thread, and cached_dev_put() is called when exiting dc->writeback_thread. This modification works well unless people detach the bcache device manually by 'echo 1 > /sys/block/bcache<N>/bcache/detach' Because this sysfs interface only calls bch_cached_dev_detach() which wakes up dc->writeback_thread but does not stop it. The reason is, before patch "bcache: fix cached_dev->count usage for bch_cache_set_error()", inside bch_writeback_thread(), if cache is not dirty after writeback, cached_dev_put() will be called here. And in cached_dev_make_request() when a new write request makes cache from clean to dirty, cached_dev_get() will be called there. Since we don't operate dc->count in these locations, refcount d->count cannot be dropped after cache becomes clean, and cached_dev_detach_finish() won't be called to detach bcache device. This patch fixes the issue by checking whether BCACHE_DEV_DETACHING is set inside bch_writeback_thread(). If this bit is set and cache is clean (no existing writeback_keys), break the while-loop, call cached_dev_put() and quit the writeback thread. Please note if cache is still dirty, even BCACHE_DEV_DETACHING is set the writeback thread should continue to perform writeback, this is the original design of manually detach. It is safe to do the following check without locking, let me explain why, + if (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) && + (!atomic_read(&dc->has_dirty) || !dc->writeback_running)) { If the kenrel thread does not sleep and continue to run due to conditions are not updated in time on the running CPU core, it just consumes more CPU cycles and has no hurt. This should-sleep-but-run is safe here. We just focus on the should-run-but-sleep condition, which means the writeback thread goes to sleep in mistake while it should continue to run. 1, First of all, no matter the writeback thread is hung or not, kthread_stop() from cached_dev_detach_finish() will wake up it and terminate by making kthread_should_stop() return true. And in normal run time, bit on index BCACHE_DEV_DETACHING is always cleared, the condition !test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) is always true and can be ignored as constant value. 2, If one of the following conditions is true, the writeback thread should go to sleep, "!atomic_read(&dc->has_dirty)" or "!dc->writeback_running)" each of them independently controls the writeback thread should sleep or not, let's analyse them one by one. 2.1 condition "!atomic_read(&dc->has_dirty)" If dc->has_dirty is set from 0 to 1 on another CPU core, bcache will call bch_writeback_queue() immediately or call bch_writeback_add() which indirectly calls bch_writeback_queue() too. In bch_writeback_queue(), wake_up_process(dc->writeback_thread) is called. It sets writeback thread's task state to TASK_RUNNING and following an implicit memory barrier, then tries to wake up the writeback thread. In writeback thread, its task state is set to TASK_INTERRUPTIBLE before doing the condition check. If other CPU core sets the TASK_RUNNING state after writeback thread setting TASK_INTERRUPTIBLE, the writeback thread will be scheduled to run very soon because its state is not TASK_INTERRUPTIBLE. If other CPU core sets the TASK_RUNNING state before writeback thread setting TASK_INTERRUPTIBLE, the implict memory barrier of wake_up_process() will make sure modification of dc->has_dirty on other CPU core is updated and observed on the CPU core of writeback thread. Therefore the condition check will correctly be false, and continue writeback code without sleeping. 2.2 condition "!dc->writeback_running)" dc->writeback_running can be changed via sysfs file, every time it is modified, a following bch_writeback_queue() is alwasy called. So the change is always observed on the CPU core of writeback thread. If dc->writeback_running is changed from 0 to 1 on other CPU core, this condition check will observe the modification and allow writeback thread to continue to run without sleeping. Now we can see, even without a locking protection, multiple conditions check is safe here, no deadlock or process hang up will happen. I compose a separte patch because that patch "bcache: fix cached_dev->count usage for bch_cache_set_error()" already gets a "Reviewed-by:" from Hannes Reinecke. Also this fix is not trivial and good for a separate patch. Signed-off-by:
Coly Li <colyli@suse.de> Reviewed-by:
Michael Lyle <mlyle@lyle.org> Cc: Hannes Reinecke <hare@suse.com> Cc: Huijun Tang <tang.junhui@zte.com.cn> Signed-off-by:
-
Michael Schmitz authored
[ Upstream commit 55496d3f ] The generic DMA API uses dev->dma_mask to check the DMA addressable memory bitmask, and warns if no mask is set or even allocated. Set z->dev.dma_coherent_mask on Zorro bus scan, and make z->dev.dma_mask to point to z->dev.dma_coherent_mask so device drivers that need DMA have everything set up to avoid warnings from dma_alloc_coherent(). Drivers can still use dma_set_mask_and_coherent() to explicitly set their DMA bit mask. Signed-off-by:
Michael Schmitz <schmitzmic@gmail.com> [geert: Handle Zorro II with 24-bit address space] Acked-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Chunyu Hu authored
[ Upstream commit 55b55abc ] Kmemleak reported the below leak. When cppc_cpufreq_init went into failure path, the cpu mask is not freed. After fix, this report is gone. And to avaoid potential NULL pointer reference, check the cpu value first. unreferenced object 0xffff800fd5ea4880 (size 128): comm "swapper/0", pid 1, jiffies 4294939510 (age 668.680s) hex dump (first 32 bytes): 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffff0000082c4ae4>] __kmalloc_node+0x278/0x634 [<ffff0000088f4a74>] alloc_cpumask_var_node+0x28/0x60 [<ffff0000088f4af0>] zalloc_cpumask_var+0x14/0x1c [<ffff000008d20254>] cppc_cpufreq_init+0xd0/0x19c [<ffff000008083828>] do_one_initcall+0xec/0x15c [<ffff000008cd1018>] kernel_init_freeable+0x1f4/0x2a4 [<ffff0000089099b0>] kernel_init+0x18/0x10c [<ffff000008084d50>] ret_from_fork+0x10/0x18 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:
Chunyu Hu <chuhu@redhat.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Philipp Puschmann authored
[ Upstream commit 6d97d5ab ] Fixes the warning "GIC: PPI13 is secure or misconfigured" by changing the interrupt type from level_low to edge_raising Signed-off-by:
Philipp Puschmann <pp@emlix.com> Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
Jay Vosburgh authored
[ Upstream commit bda7fab5 ] The operstate update logic will leave an interface in the default UNKNOWN operstate if the interface carrier state never changes from the default carrier up state set at creation. This includes the case of an explicit call to netif_carrier_on, as the carrier on to on transition has no effect on operstate. This affects virtio-net for the case that the virtio peer does not support VIRTIO_NET_F_STATUS (the feature that provides carrier state updates). Without this feature, the virtio specification states that "the link should be assumed active," so, logically, the operstate should be UP instead of UNKNOWN. This has impact on user space applications that use the operstate to make availability decisions for the interface. Resolve this by changing the virtio probe logic slightly to call netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS cases, and then the existing call to netif_carrier_on for the "without" case will cause an operstate transition. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Petr Vorel authored
[ Upstream commit ab60368a ] IMA requires having it's hash algorithm be compiled-in due to it's early use. The default IMA algorithm is protected by Kconfig to be compiled-in. The ima_hash kernel parameter allows to choose the hash algorithm. When the specified algorithm is not available or available as a module, IMA initialization fails, which leads to a kernel panic (mknodat syscall calls ima_post_path_mknod()). Therefore as fallback we force IMA to use the default builtin Kconfig hash algorithm. Fixed crash: $ grep CONFIG_CRYPTO_MD4 .config CONFIG_CRYPTO_MD4=m [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-2.3-default root=UUID=74ae8202-9ca7-4e39-813b-22287ec52f7a video=1024x768-16 plymouth.ignore-serial-consoles console=ttyS0 console=tty resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent showopts ima_hash=md4 ... [ 1.545190] ima: Can not allocate md4 (reason: -2) ... [ 2.610120] BUG: unable to handle kernel NULL pointer dereference at (null) [ 2.611903] IP: ima_match_policy+0x23/0x390 [ 2.612967] PGD 0 P4D 0 [ 2.613080] Oops: 0000 [#1] SMP [ 2.613080] Modules linked in: autofs4 [ 2.613080] Supported: Yes [ 2.613080] CPU: 0 PID: 1 Comm: systemd Not tainted 4.12.14-2.3-default #1 [ 2.613080] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 [ 2.613080] task: ffff88003e2d0040 task.stack: ffffc90000190000 [ 2.613080] RIP: 0010:ima_match_policy+0x23/0x390 [ 2.613080] RSP: 0018:ffffc90000193e88 EFLAGS: 00010296 [ 2.613080] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000004 [ 2.613080] RDX: 0000000000000010 RSI: 0000000000000001 RDI: ffff880037071728 [ 2.613080] RBP: 0000000000008000 R08: 0000000000000000 R09: 0000000000000000 [ 2.613080] R10: 0000000000000008 R11: 61c8864680b583eb R12: 00005580ff10086f [ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000008000 [ 2.613080] FS: 00007f5c1da08940(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 [ 2.613080] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.613080] CR2: 0000000000000000 CR3: 0000000037002000 CR4: 00000000003406f0 [ 2.613080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.613080] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.613080] Call Trace: [ 2.613080] ? shmem_mknod+0xbf/0xd0 [ 2.613080] ima_post_path_mknod+0x1c/0x40 [ 2.613080] SyS_mknod+0x210/0x220 [ 2.613080] entry_SYSCALL_64_fastpath+0x1a/0xa5 [ 2.613080] RIP: 0033:0x7f5c1bfde570 [ 2.613080] RSP: 002b:00007ffde1c90dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000085 [ 2.613080] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c1bfde570 [ 2.613080] RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00005580ff10086f [ 2.613080] RBP: 00007ffde1c91040 R08: 00005580ff10086f R09: 0000000000000000 [ 2.613080] R10: 0000000000104000 R11: 0000000000000246 R12: 00005580ffb99660 [ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002 [ 2.613080] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 44 8d 14 09 41 55 41 54 55 53 44 89 d3 09 cb 48 83 ec 38 48 8b 05 c5 03 29 01 <4c> 8b 20 4c 39 e0 0f 84 d7 01 00 00 4c 89 44 24 08 89 54 24 20 [ 2.613080] RIP: ima_match_policy+0x23/0x390 RSP: ffffc90000193e88 [ 2.613080] CR2: 0000000000000000 [ 2.613080] ---[ end trace 9a9f0a8a73079f6a ]--- [ 2.673052] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.673052] [ 2.675337] Kernel Offset: disabled [ 2.676405] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Signed-off-by:
Petr Vorel <pvorel@suse.cz> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Arjun Vynipadath authored
[ Upstream commit 843bd7db ] When NetworkManager is enabled, there are chances that interface up is called even before probe completes. This means we have not yet allocated the FW sge queues, hence rest of ingress queue allocation wont be proper. Fix this by calling setup_fw_sge_queues() before register_netdev(). Fixes: 0fbc81b3 ('chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's') Signed-off-by:
-
Karthikeyan Periyasamy authored
[ Upstream commit 8b2d93dd ] When attempt to run worker (ath10k_sta_rc_update_wk) after the station object (ieee80211_sta) delete will trigger the kernel panic. This problem arise in AP + Mesh configuration, Where the current node AP VAP and neighbor node mesh VAP MAC address are same. When the current mesh node try to establish the mesh link with neighbor node, driver peer creation for the neighbor mesh node fails due to duplication MAC address. Already the AP VAP created with same MAC address. It is caused by the following scenario steps. Steps: 1. In above condition, ath10k driver sta_state callback (ath10k_sta_state) fails to do the state change for a station from IEEE80211_STA_NOTEXIST to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is called from ieee80211_add_station() to handle the new station (neighbor mesh node) request from the wpa_supplicant. 2. Concurrently ath10k receive the sta_rc_update callback notification from the mesh_neighbour_update() to handle the beacon frames of the above neighbor mesh node. since its atomic callback, ath10k driver queue the work (ath10k_sta_rc_update_wk) to handle rc update. 3. Due to driver sta_state callback fails (step 1), mac80211 free the station object. 4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access the station object which is already deleted. so it will trigger kernel panic. Added the peer exist check in sta_rc_update callback before queue the work. Kernel Panic log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1 task: dcef0000 ti: d72b6000 task.ti: d72b6000 PC is at pwq_activate_delayed_work+0x10/0x40 LR is at pwq_activate_delayed_work+0xc/0x40 pc : [<c023f988>] lr : [<c023f984>] psr: 40000193 sp : d72b7f18 ip : 0000007a fp : d72b6000 r10: 00000000 r9 : dd404414 r8 : d8c31998 r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300 r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 595bc06a DAC: 00000015 ... Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238) Stack: (0xd72b7f18 to 0xd72b8000) 7f00: 00000001 dcee1300 7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089 7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000 7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000 7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340 7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4) [<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360) [<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec) [<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34) Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs Rebooting in 3 seconds.. Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
