- 27 Jul, 2017 40 commits
-
-
Seunghun Han authored
commit e708e35b upstream. One of the rarely executed code pathes in check_timer() calls unmask_ioapic_irq() passing irq_get_chip_data(0) as argument. That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of interrupt 0. irq_get_chip_data(0) returns NULL, so the following dereference in unmask_ioapic_irq() causes a kernel panic. The issue went unnoticed in the first place because irq_get_chip_data() returns a void pointer so the compiler cannot do a type check on the argument. The code path was added for machines with broken configuration, but it seems that those machines are either not running current kernels or simply do not longer exist. Hand in irq_get_irq_data(0) as argument which provides the correct data. [ tglx: Rewrote changelog ] Fixes: 4467715a ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c") Signed-off-by:
Seunghun Han <kkamagui@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkamagui@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Seunghun Han authored
commit dad5ab0d upstream. The bus_irq argument of mp_override_legacy_irq() is used as the index into the isa_irq_to_gsi[] array. The bus_irq argument originates from ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI tables, but is nowhere sanity checked. That allows broken or malicious ACPI tables to overwrite memory, which might cause malfunction, panic or arbitrary code execution. Add a sanity check and emit a warning when that triggers. [ tglx: Added warning and rewrote changelog ] Signed-off-by:
-
Lv Zheng authored
commit 9c40f956 upstream. On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier EC event freezing timing causes acpitz-virtual-0 to report a stuck 48C temparature. And with EC firmware revisioned as 1.14, without reverting back to old EC event freezing timing, the fan still blows up after a system resume. This reverts the culprit change so that the regression can be fixed without upgrading the EC firmware. Fixes: d3028305 (ACPI / EC: Enable event freeze mode to improve event handling) Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168Tested-by:
Damjan Georgievski <gdamjan@gmail.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Lv Zheng authored
commit 66259146 upstream. According to bug reports, although the busy polling mode can make noirq stages execute faster, it causes abnormal fan blowing up after system resume (see the first link below for a video demonstration) on Lenovo ThinkPad X1 Carbon - the 5th Generation. The problem can be fixed by upgrading the EC firmware on that machine. However, many reporters confirm that the problem can be fixed by stopping busy polling during suspend/resume and for some of them upgrading the EC firmware is not an option. For this reason, drop the noirq stage hooks from the EC driver to fix the regression. Fixes: c3a696b6 (ACPI / EC: Use busy polling mode when GPE is not enabled) Link: https://youtu.be/9NQ9x-Jm99Q Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129Reported-by:
Andreas Lindhe <andreas@lindhe.io> Tested-by:
Gjorgji Jankovski <j.gjorgji@gmail.com> Tested-by:
Fernando Chaves <nanochaves@gmail.com> Tested-by:
Tomislav Ivek <tomislav.ivek@gmail.com> Tested-by:
Denis P. <theoriginal.skullburner@gmail.com> Signed-off-by:
-
Richard Weinberger authored
commit 4acadda7 upstream. When UBIFS prepares data structures which will be written to the MTD it ensues that their lengths are multiple of 8. Since it uses kmalloc() the padded bytes are left uninitialized and we leak a few bytes of kernel memory to the MTD. To make sure that all bytes are initialized, let's switch to kzalloc(). Kzalloc() is fine in this case because the buffers are not huge and in the IO path the performance bottleneck is anyway the MTD. Fixes: 1e51764a ("UBIFS: add new flash file system") Signed-off-by:
Richard Weinberger <richard@nod.at> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
James Hogan authored
commit 4f32a39d upstream. The sys_exit trace event takes a single return value for the system call, which MIPS passes the value of the $v0 (result) register, however MIPS returns positive error codes in $v0 with $a3 specifying that $v0 contains an error code. As a result erroring system calls are traced returning positive error numbers that can't always be distinguished from success. Use regs_return_value() to negate the error code if $a3 is set. Fixes: 1d7bf993 ("MIPS: ftrace: Add support for syscall tracepoints.") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16651/Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
James Hogan authored
commit 4915e1b0 upstream. EVA linked loads (LLE) and conditional stores (SCE) should be used on EVA kernels for the MIPS_ATOMIC_SET operation of the sysmips system call, or else the atomic set will apply to the kernel view of the virtual address space (potentially unmapped on EVA kernels) rather than the user view (TLB mapped). Signed-off-by:
-
James Hogan authored
commit 2ec420b2 upstream. The inline asm retry check in the MIPS_ATOMIC_SET operation of the sysmips system call has been backwards since commit f1e39a4a ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler") merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying until the operation was inatomic, before returning the new value that was probably just written multiple times instead of the old value. Invert the branch condition to fix that particular issue. Fixes: f1e39a4a ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler") Signed-off-by:
-
Dan Carpenter authored
commit 2e028c4f upstream. My static checker complains that if "func" is NULL then "clear_filter" is uninitialized. This seems like it could be true, although it's possible something subtle is happening that I haven't seen. kernel/trace/ftrace.c:3844 match_records() error: uninitialized symbol 'clear_filter'. Link: http://lkml.kernel.org/r/20170712073556.h6tkpjcdzjaozozs@mwanda Fixes: f0a3b154 ("ftrace: Clarify code for mod command") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Marta Rybczynska authored
commit 5e599d73 upstream. This patch improves the way the RDMA IB signalling is done by using atomic operations for the signalling variable. This avoids race conditions on sig_count. The signalling interval changes slightly and is now the largest power of two not larger than queue depth / 2. ilog() usage idea by Bart Van Assche. Signed-off-by:
Marta Rybczynska <marta.rybczynska@kalray.eu> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Alex Williamson authored
commit 5d6dee80 upstream. At the point where the kvm-vfio pseudo device wants to release its vfio group reference, we can't always acquire a new reference to make that happen. The group can be in a state where we wouldn't allow a new reference to be added. This new helper function allows a caller to match a file to a group to facilitate this. Given a file and group, report if they match. Thus the caller needs to already have a group reference to match to the file. This allows the deletion of a group without acquiring a new reference. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Tested-by:
-
Alex Williamson authored
commit 811642d8 upstream. If vfio_iommu_group_notifier() acquires a group reference and that reference becomes the last reference to the group, then vfio_group_put introduces a deadlock code path where we're trying to unregister from the iommu notifier chain from within a callout of that chain. Use a work_struct to release this reference asynchronously. Signed-off-by:
-
Konstantin Khlebnikov authored
commit 51f8f3c4 upstream. If overlay was mounted by root then quota set for upper layer does not work because overlay now always use mounter's credentials for operations. Also overlay might deplete reserved space and inodes in ext4. This patch drops capability SYS_RESOURCE from saved credentials. This affects creation new files, whiteouts, and copy-up operations. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Fixes: 1175b6b8 ("ovl: do operations on underlying file system in mounter's context") Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Cc: Amir Goldstein <amir73il@gmail.com> Signed-off-by:
-
John Brooks authored
commit 8046e195 upstream. We unref the man->move fence in ttm_bo_clean_mm() and then call ttm_bo_force_list_clean() which waits on it, except the refcount is now zero so a warning is generated (or worse): [149492.279301] refcount_t: increment on 0; use-after-free. [149492.279309] ------------[ cut here ]------------ [149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30 [149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu( -) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [149492.279327] task: ffff8804ddfedcc0 task.stack: ffffc90008d20000 [149492.279329] RIP: 0010:refcount_inc+0x2b/0x30 [149492.279330] RSP: 0018:ffffc90008d23c30 EFLAGS: 00010286 [149492.279331] RAX: 000000000000002b RBX: 0000000000000170 RCX: 0000000000000000 [149492.279331] RDX: 0000000000000000 RSI: ffff88051ecccbe8 RDI: ffff88051ecccbe8 [149492.279332] RBP: ffffc90008d23c30 R08: 0000000000000001 R09: 00000000000003ee [149492.279333] R10: ffffc90008d23bb0 R11: 00000000000003ee R12: ffff88043aaac960 [149492.279333] R13: ffff8805005e28a8 R14: 0000000000000002 R15: ffff88050115e178 [149492.279334] FS: 00007fc540168700(0000) GS:ffff88051ecc0000(0000) knlGS:0000000000000000 [149492.279335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [149492.279336] CR2: 00007fc3e8654140 CR3: 000000027ba77000 CR4: 00000000001426e0 [149492.279337] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [149492.279337] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [149492.279338] Call Trace: [149492.279345] ttm_bo_force_list_clean+0xb9/0x110 [ttm] [149492.279348] ttm_bo_clean_mm+0x7a/0xe0 [ttm] [149492.279375] amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu] [149492.279392] amdgpu_bo_fini+0x12/0x40 [amdgpu] [149492.279415] gmc_v7_0_sw_fini+0x32/0x40 [amdgpu] [149492.279430] amdgpu_fini+0x2c9/0x490 [amdgpu] [149492.279445] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [149492.279461] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [149492.279470] drm_dev_unregister+0x3c/0xe0 [drm] [149492.279485] amdgpu_pci_remove+0x19/0x30 [amdgpu] [149492.279487] pci_device_remove+0x39/0xc0 [149492.279490] device_release_driver_internal+0x155/0x210 [149492.279491] driver_detach+0x38/0x70 [149492.279493] bus_remove_driver+0x4c/0xa0 [149492.279494] driver_unregister+0x2c/0x40 [149492.279496] pci_unregister_driver+0x21/0x90 [149492.279520] amdgpu_exit+0x15/0x406 [amdgpu] [149492.279523] SyS_delete_module+0x1a8/0x270 [149492.279525] ? exit_to_usermode_loop+0x92/0xa0 [149492.279528] entry_SYSCALL_64_fastpath+0x13/0x94 [149492.279529] RIP: 0033:0x7fc53fcb68e7 [149492.279529] RSP: 002b:00007ffcfbfaabb8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [149492.279531] RAX: ffffffffffffffda RBX: 0000563117adb200 RCX: 00007fc53fcb68e7 [149492.279531] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000563117adb268 [149492.279532] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [149492.279533] R10: 0000000000000883 R11: 0000000000000206 R12: 00007ffcfbfa9ba0 [149492.279533] R13: 0000000000000000 R14: 0000000000000000 R15: 0000563117adb200 [149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff [149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]--- Unref the fence *after* waiting for it. v2: Set man->move to NULL after dropping the last ref (Christian König) Fixes: aff98ba1 (drm/ttm: wait for eviction in ttm_bo_force_list_clean) Signed-off-by:
John Brooks <john@fastquake.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Jaegeuk Kim authored
commit c925dc16 upstream. This patch copies commit b7f8a09f: "btrfs: Don't clear SGID when inheriting ACLs" written by Jan. Fixes: 07393101Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Reviewed-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Jin Qian authored
commit 21d3f8e1 upstream. Make sure number of entires doesn't exceed max journal size. Signed-off-by:
Jin Qian <jinqian@android.com> Reviewed-by:
-
Jan Kara authored
commit 8ba35875 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when setting up inode in xfs_generic_create(). That prevents SGID bit clearing and mode is properly set by posix_acl_create() anyway. We also reorder arguments of __xfs_set_acl() to match the ordering of xfs_set_acl() to make things consistent. Fixes: 07393101 CC: Darrick J. Wong <darrick.wong@oracle.com> CC: linux-xfs@vger.kernel.org Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Corey Minyard authored
commit 4495ec6d upstream. When getting flags, a response to a different message would result in a deadlock because of a missing unlock. Add that unlock and a comment. Found by static analysis. Reported-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Tony Camuso authored
commit cdea4656 upstream. A vendor with a system having more than 128 CPUs occasionally encounters the following crash during shutdown. This is not an easily reproduceable event, but the vendor was able to provide the following analysis of the crash, which exhibits the same footprint each time. crash> bt PID: 0 TASK: ffff88017c70ce70 CPU: 5 COMMAND: "swapper/5" #0 [ffff88085c143ac8] machine_kexec at ffffffff81059c8b #1 [ffff88085c143b28] __crash_kexec at ffffffff811052e2 #2 [ffff88085c143bf8] crash_kexec at ffffffff811053d0 #3 [ffff88085c143c10] oops_end at ffffffff8168ef88 #4 [ffff88085c143c38] no_context at ffffffff8167ebb3 #5 [ffff88085c143c88] __bad_area_nosemaphore at ffffffff8167ec49 #6 [ffff88085c143cd0] bad_area_nosemaphore at ffffffff8167edb3 #7 [ffff88085c143ce0] __do_page_fault at ffffffff81691d1e #8 [ffff88085c143d40] do_page_fault at ffffffff81691ec5 #9 [ffff88085c143d70] page_fault at ffffffff8168e188 [exception RIP: unknown or invalid address] RIP: ffffffffa053c800 RSP: ffff88085c143e28 RFLAGS: 00010206 RAX: ffff88017c72bfd8 RBX: ffff88017a8dc000 RCX: ffff8810588b5ac8 RDX: ffff8810588b5a00 RSI: ffffffffa053c800 RDI: ffff8810588b5a00 RBP: ffff88085c143e58 R8: ffff88017c70d408 R9: ffff88017a8dc000 R10: 0000000000000002 R11: ffff88085c143da0 R12: ffff8810588b5ac8 R13: 0000000000000100 R14: ffffffffa053c800 R15: ffff8810588b5a00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 <IRQ stack> [exception RIP: cpuidle_enter_state+82] RIP: ffffffff81514192 RSP: ffff88017c72be50 RFLAGS: 00000202 RAX: 0000001e4c3c6f16 RBX: 000000000000f8a0 RCX: 0000000000000018 RDX: 0000000225c17d03 RSI: ffff88017c72bfd8 RDI: 0000001e4c3c6f16 RBP: ffff88017c72be78 R8: 000000000000237e R9: 0000000000000018 R10: 0000000000002494 R11: 0000000000000001 R12: ffff88017c72be20 R13: ffff88085c14f8e0 R14: 0000000000000082 R15: 0000001e4c3bb400 ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018 This is the corresponding stack trace It has crashed because the area pointed with RIP extracted from timer element is already removed during a shutdown process. The function is smi_timeout(). And we think ffff8810588b5a00 in RDX is a parameter struct smi_info crash> rd ffff8810588b5a00 20 ffff8810588b5a00: ffff8810588b6000 0000000000000000 .`.X............ ffff8810588b5a10: ffff880853264400 ffffffffa05417e0 .D&S......T..... ffff8810588b5a20: 24a024a000000000 0000000000000000 .....$.$........ ffff8810588b5a30: 0000000000000000 0000000000000000 ................ ffff8810588b5a30: 0000000000000000 0000000000000000 ................ ffff8810588b5a40: ffffffffa053a040 ffffffffa053a060 @.S.....`.S..... ffff8810588b5a50: 0000000000000000 0000000100000001 ................ ffff8810588b5a60: 0000000000000000 0000000000000e00 ................ ffff8810588b5a70: ffffffffa053a580 ffffffffa053a6e0 ..S.......S..... ffff8810588b5a80: ffffffffa053a4a0 ffffffffa053a250 ..S.....P.S..... ffff8810588b5a90: 0000000500000002 0000000000000000 ................ Unfortunately the top of this area is already detroyed by someone. But because of two reasonns we think this is struct smi_info 1) The address included in between ffff8810588b5a70 and ffff8810588b5a80: are inside of ipmi_si_intf.c see crash> module ffff88085779d2c0 2) We've found the area which point this. It is offset 0x68 of ffff880859df4000 crash> rd ffff880859df4000 100 ffff880859df4000: 0000000000000000 0000000000000001 ................ ffff880859df4010: ffffffffa0535290 dead000000000200 .RS............. ffff880859df4020: ffff880859df4020 ffff880859df4020 @.Y.... @.Y.... ffff880859df4030: 0000000000000002 0000000000100010 ................ ffff880859df4040: ffff880859df4040 ffff880859df4040 @@.Y....@@.Y.... ffff880859df4050: 0000000000000000 0000000000000000 ................ ffff880859df4060: 0000000000000000 ffff8810588b5a00 .........Z.X.... ffff880859df4070: 0000000000000001 ffff880859df4078 ........x@.Y.... If we regards it as struct ipmi_smi in shutdown process it looks consistent. The remedy for this apparent race is affixed below. Signed-off-by:
Tony Camuso <tcamuso@redhat.com> Signed-off-by:
-
Mario Kleiner authored
commit 564d8a2c upstream. The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via MiniDP to DVI or HDMI adapter. However, booting the machine single-display with only eDP panel results in a completely black display - even backlight powering off, as soon as the radeon modesetting driver loads. This patch fixes the single dispay eDP case by assigning encoders based on dig->linkb, similar to DCE-4+. While this should not be generally necessary (Alex: "...atom on normal boards should be able to handle any mapping."), Apple seems to use some special routing here. One remaining problem not solved by this patch is that an external Minidisplayport->DP sink does still not work on iMac10,1, whereas external DVI and HDMI sinks continue to work. The problem affects at least all tested kernels since Linux 3.13 - didn't test earlier kernels, so backporting to stable probably makes sense. v2: With the original patch from 2016, Alex was worried it will break other DCE3.2 systems. Use dmi_match() to apply this special encoder assignment only for the Apple iMac 10,1 from late 2009. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Alex Deucher authored
commit ab03d9fe upstream. Even if the vblank period would allow it, it still seems to be problematic on some cards. v2: fix logic inversion (Nils) bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868Acked-by:
-
Tom St Denis authored
commit 9156e723 upstream. If you initiate a read that is out of the VRAM address space return ENXIO instead of 0. Reads that begin below that point will read upto the VRAM limit as before. Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
-
Jiri Olsa authored
commit c46fc042 upstream. Zorro reported following crash while having enabled syscall tracing (CONFIG_FTRACE_SYSCALLS): Unable to handle kernel pointer dereference at virtual ... Oops: 0011 [#1] SMP DEBUG_PAGEALLOC SNIP Call Trace: ([<000000000024d79c>] ftrace_syscall_enter+0xec/0x1d8) [<00000000001099c6>] do_syscall_trace_enter+0x236/0x2f8 [<0000000000730f1c>] sysc_tracesys+0x1a/0x32 [<000003fffcf946a2>] 0x3fffcf946a2 INFO: lockdep is turned off. Last Breaking-Event-Address: [<000000000022dd44>] rb_event_data+0x34/0x40 ---[ end trace 8c795f86b1b3f7b9 ]--- The crash happens in syscall_get_arguments function for syscalls with zero arguments, that will try to access first argument (args[0]) in event entry, but it's not allocated. Bail out of there are no arguments. Reported-by:
Zorro Lang <zlang@redhat.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Xiao Ni authored
commit b5d27718 upstream. The raid5 md device is created by the disks which we don't use the total size. For example, the size of the device is 5G and it just uses 3G of the devices to create one raid5 device. Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid and assemble it again. It fails. mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean mdadm /dev/md0 --grow --chunk=64 wait reshape to finish mdadm -S /dev/md0 mdadm -As The error messages: [197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing! [197519.821686] md: md_import_device returned -22 After reshape the data offset is changed. It selects backwards direction in this condition. In function super_1_load it compares the available space of the underlying device with sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL. rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based on rdev->sectors. So add md_finish_reshape in end_reshape. Signed-off-by:
Xiao Ni <xni@redhat.com> Acked-by:
Guoqing Jiang <gqjiang@suse.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Jan Kara authored
commit a992f2d3 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by creating __ext2_set_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 07393101 CC: linux-ext4@vger.kernel.org Signed-off-by:
-
Toshi Kani authored
commit 4e3f0701 upstream. __add_badblock_range() does not account sector alignment when it sets 'num_sectors'. Therefore, an ARS error record range spanning across two sectors is set to a single sector length, which leaves the 2nd sector unprotected. Change __add_badblock_range() to set 'num_sectors' properly. Fixes: 0caeef63 ("libnvdimm: Add a poison list and export badblocks") Signed-off-by:
Toshi Kani <toshi.kani@hpe.com> Reviewed-by:
Vishal Verma <vishal.l.verma@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Vishal Verma authored
commit c13c43d5 upstream. btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any IO errors via the rw_page path going unnoticed. the pmem driver recently fixed this in e10624f8 pmem: fail io-requests to known bad blocks but same problem in BTT went neglected. Fixes: 5212e11f ("nd_btt: atomic sector updates") Cc: Toshi Kani <toshi.kani@hpe.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
-
Devin Heitmueller authored
commit 4e0973a9 upstream. Setting initial standard at the top of cx8800_initdev would cause the first call to cx88_set_tvnorm() to return without programming any registers (leaving the driver saying it's set to NTSC but the hardware isn't programmed). Even worse, any subsequent attempt to explicitly set it to NTSC-M will return success but actually fail to program the underlying registers unless first changing the standard to something other than NTSC-M. Set the initial standard later in the process, and make sure the field is zero at the beginning to ensure that the call always goes through. This regression was introduced in the following commit: commit ccd6f1d4 ("[media] cx88: move width, height and field to core struct") Author: Hans Verkuil <hans.verkuil@cisco.com> [media] cx88: move width, height and field to core struct Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Marek Marczykowski-Górecki authored
commit c54590ca upstream. Userspace application can do a hypercall through /dev/xen/privcmd, and some for some hypercalls argument is a pointers to user-provided structure. When SMAP is supported and enabled, hypervisor can't access. So, lets allow it. The same applies to HYPERVISOR_dm_op, where additionally privcmd driver carefully verify buffer addresses. Cc: stable@vger.kernel.org Signed-off-by:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by:
Juergen Gross <jgross@suse.com> [HYPERVISOR_dm_op dropped - not present until 4.11] Signed-off-by:
-
Mikulas Patocka authored
commit f9c79bc0 upstream. The function flush_signals clears all pending signals for the process. It may be used by kernel threads when we need to prepare a kernel thread for responding to signals. However using this function for an userspaces processes is incorrect - clearing signals without the program expecting it can cause misbehavior. The raid1 and raid5 code uses flush_signals in its request routine because it wants to prepare for an interruptible wait. This patch drops flush_signals and uses sigprocmask instead to block all signals (including SIGKILL) around the schedule() call. The signals are not lost, but the schedule() call won't respond to them. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Acked-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit b8b9c974 upstream. A gadget driver will not disable eps immediately when ->disconnect() is called. But, since this driver assumes all eps stop after the ->disconnect(), unexpected behavior happens (especially in system suspend). So, this patch disables all eps in usbhsg_try_stop(). After disabling eps by renesas_usbhs driver, since some functions will be called by both a gadget and renesas_usbhs driver, renesas_usbhs driver should protect uep->pipe. To protect uep->pipe easily, this patch adds a new lock in struct usbhsg_uep. Fixes: 2f98382d ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit 59a0879a upstream. This patch fixes an issue that some registers may be not initialized after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise, if a cable is not connected, the driver will not enable INTENB0.VBSE after resume. And then, the driver cannot detect the VBUS. Fixes: ca8a282a ("usb: gadget: renesas_usbhs: add suspend/resume support") Signed-off-by:
-
Johan Hovold authored
commit fe855789 upstream. Add device-id entry for DATECS FP-2000 fiscal printer needing the NO_UNION_NORMAL quirk. Reported-by:
Anton Avramov <lukav@lukav.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Colin Ian King authored
commit 446230f5 upstream. When us->extra is null the driver is not initialized, however, a later call to osd200_scsi_to_ata is made that dereferences us->extra, causing a null pointer dereference. The code currently detects and reports that the driver is not initialized; add a return to avoid the subsequent dereference issue in this check. Thanks to Alan Stern for pointing out that srb->result needs setting to DID_ERROR << 16 Detected by CoverityScan, CID#100308 ("Dereference after null check") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Devin Heitmueller authored
commit d90b336f upstream. The recent changes in 4.9 to mandate USB buffers be heap allocated broke this driver, which was allocating the buffers on the stack. This resulted in the device failing at initialization. Introduce dedicated send/receive buffers as part of the state structure, and add a mutex to protect access to them. Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass the pointer to the state struct rather than the device, since we need it inside the function to access the buffers and the mutex. This patch adjusts the callers to match the API change. Signed-off-by:
Doug Lung <dlung0@gmail.com> Cc: Michael Ira Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Jiahau Chang authored
commit 9da5a109 upstream. When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias] Signed-off-by:
Jiahau Chang <Lars_chang@asmedia.com.tw> Signed-off-by:
Ian Pilcher <arequipeno@gmail.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 4b895868 upstream. This off by one in stream_id indexing caused NULL pointer dereference and soft lockup on machines with USB attached SCSI devices connected to a hotpluggable xhci controller. The code that cleans up pending URBs for dead hosts tried to dereference a stream ring at the invalid stream_id 0. ep->stream_info->stream_rings[0] doesn't point to a ring. Start looping stream_id from 1 like in all the other places in the driver, and check that the ring exists before trying to kill URBs on it. Reported-by:
rocko r <rockorequin@gmail.com> Signed-off-by:
-
Mathias Nyman authored
commit a54408d0 upstream. A uncleared PLC (port link change) bit will prevent furuther port event interrupts for that port. Leaving it uncleared caused get_port_status() to timeout after 20000ms while waiting to get the final port event interrupt for resume -> U0 state change. This is a targeted fix for a specific case where we get a port resume event racing with xhci resume. The port event interrupt handler notices xHC is not yet running and bails out early, leaving PLC uncleared. The whole xhci port resuming needs more attention, but while working on it it anyways makes sense to always ensure PLC is cleared in get_port_status before setting a new link state and waiting for its completion. Signed-off-by:
-
Julian Anastasov authored
commit 3c5ab3f3 upstream. We do not check if packet from real server is for NAT connection before performing SNAT. This causes problems for setups that use DR/TUN and allow local clients to access the real server directly, for example: - local client in director creates IPVS-DR/TUN connection CIP->VIP and the request packets are routed to RIP. Talks are finished but IPVS connection is not expired yet. - second local client creates non-IPVS connection CIP->RIP with same reply tuple RIP->CIP and when replies are received on LOCAL_IN we wrongly assign them for the first client connection because RIP->CIP matches the reply direction. As result, IPVS SNATs replies for non-IPVS connections. The problem is more visible to local UDP clients but in rare cases it can happen also for TCP or remote clients when the real server sends the reply traffic via the director. So, better to be more precise for the reply traffic. As replies are not expected for DR/TUN connections, better to not touch them. Reported-by:
Nick Moriarty <nick.moriarty@york.ac.uk> Tested-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Chen Yu authored
commit e60514bd upstream. Currently we saw a lot of "No irq handler" errors during hibernation, which caused the system hang finally: ata4.00: qc timeout (cmd 0xec) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata4.00: revalidation failed (errno=-5) ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) do_IRQ: 31.151 No irq handler for vector According to above logs, there is an interrupt triggered and it is dispatched to CPU31 with a vector number 151, but there is no handler for it, thus this IRQ will not get acked and will cause an IRQ flood which kills the system. To be more specific, the 31.151 is an interrupt from the AHCI host controller. After some investigation, the reason why this issue is triggered is because the thaw_noirq() function does not restore the MSI/MSI-X settings across hibernation. The scenario is illustrated below: 1. Before hibernation, IRQ 34 is the handler for the AHCI device, which is bound to CPU31. 2. Hibernation starts, the AHCI device is put into low power state. 3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to the last alive one - CPU0. 4. After the snapshot has been created, all the nonboot CPUs are brought up again; IRQ 34 remains bound to CPU0. 5. AHCI devices are put into D0. 6. The snapshot is written to the disk. The issue is triggered in step 6. The AHCI interrupt should be delivered to CPU0, however it is delivered to the original CPU31 instead, which causes the "No irq handler" issue. Ying Huang has provided a clue that, in step 3 it is possible that writing to the register might not take effect as the PCI devices have been suspended. In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but in fact it is not. In __pci_write_msi_msg(), if the device is already in low power state, the low level MSI message entry will not be updated but cached. During the device restore process after a normal suspend/resume, pci_restore_msi_state() writes the cached MSI back to the hardware. But this is not the case for hibernation. pci_restore_msi_state() is not currently called in pci_pm_thaw_noirq(), although pci_save_state() has saved the necessary PCI cached information in pci_pm_freeze_noirq(). Restore the PCI status for the device during hibernation. Otherwise the status might be lost across hibernation (for example, settings for MSI, MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation. Suggested-by:
Ying Huang <ying.huang@intel.com> Suggested-by:
Chen Yu <yu.c.chen@intel.com> [bhelgaas: changelog] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
-
