- 02 Oct, 2016 12 commits
-
-
Kai-Heng Feng authored
[ Upstream commit fd06c77e ] The subwoofer on Inspiron 7559 was disabled originally. Applying a pin fixup to node 0x1b can enable it and make it work. Old pin: 0x411111f0 New pin: 0x90170151 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Ken Lin authored
[ Upstream commit 83d9956b ] Avoid getting sample rate on B850V3 CP2114 as it is unsupported and causes noisy "current rate is different from the runtime rate" messages when playback starts. Signed-off-by: Ken Lin <ken.lin@advantech.com.tw> Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Vegard Nossum authored
[ Upstream commit 8ddc0563 ] I hit this with syzkaller: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff88011278d600 task.stack: ffff8801120c0000 RIP: 0010:[<ffffffff82c8ba07>] [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100 RSP: 0018:ffff8801120c7a60 EFLAGS: 00010006 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007 RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048 RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790 R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980 R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286 FS: 00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0 Stack: ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0 ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000 ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0 Call Trace: [<ffffffff82c81ab1>] snd_timer_start1+0x331/0x670 [<ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0 [<ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830 [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430 [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80 [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90 [<ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0 [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80 [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050 [<ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0 [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200 [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0 [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0 [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190 [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0 [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0 [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0 [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050 [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0 [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25 Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46 RIP [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100 RSP <ffff8801120c7a60> ---[ end trace 5955b08db7f2b029 ]--- This can happen if snd_hrtimer_open() fails to allocate memory and returns an error, which is currently not checked by snd_timer_open(): ioctl(SNDRV_TIMER_IOCTL_SELECT) - snd_timer_user_tselect() - snd_timer_close() - snd_hrtimer_close() - (struct snd_timer *) t->private_data = NULL - snd_timer_open() - snd_hrtimer_open() - kzalloc() fails; t->private_data is still NULL ioctl(SNDRV_TIMER_IOCTL_START) - snd_timer_user_start() - snd_timer_start() - snd_timer_start1() - snd_hrtimer_start() - t->private_data == NULL // boom Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Vegard Nossum authored
[ Upstream commit 6b760bb2 ] I got this: divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff8801120a9580 task.stack: ffff8801120b0000 RIP: 0010:[<ffffffff82c8bd9a>] [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0 RSP: 0018:ffff88011aa87da8 EFLAGS: 00010006 RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001 RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048 R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00 R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000 FS: 00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0 Stack: 0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76 ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0 00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0 Call Trace: <IRQ> [<ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00 [<ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130 [<ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0 [<ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0 [<ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0 [<ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0 [<ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0 [<ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0 [<ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0 <EOI> [<ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60 [<ffffffff82c8185d>] snd_timer_start1+0xdd/0x670 [<ffffffff82c87015>] snd_timer_continue+0x45/0x80 [<ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830 [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430 [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80 [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90 [<ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0 [<ffffffff815a9930>] ? __pmd_alloc+0x370/0x370 [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80 [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050 [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200 [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0 [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0 [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190 [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0 [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0 [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0 [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050 [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0 [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25 Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00 RIP [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0 RSP <ffff88011aa87da8> ---[ end trace 6aa380f756a21074 ]--- The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a completely new/unused timer -- it will have ->sticks == 0, which causes a divide by 0 in snd_hrtimer_callback(). Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Simon Baatz authored
[ Upstream commit a7789378 ] Commit 148c274e ("ARM: kirkwood: ib62x0: add u-boot environment partition") split the "u-boot" partition into "u-boot" and "u-boot environment". However, instead of the size of the environment, an offset was given, resulting in overlapping partitions. Signed-off-by: Simon Baatz <gmbnomis@gmail.com> Fixes: 148c274e ("ARM: kirkwood: ib62x0: add u-boot environment partition") Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Luka Perkov <luka@openwrt.org> Cc: stable@vger.kernel.org # 3.13+ Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Miklos Szeredi authored
[ Upstream commit 8fba54ae ] When reading from a loop device backed by a fuse file it deadlocks on lock_page(). This is because the page is already locked by the read() operation done on the loop device. In this case we don't want to either lock the page or dirty it. So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors. Reported-by: Sheng Yang <sheng@yasker.org> Fixes: aa4d8616 ("block: loop: switch to VFS ITER_BVEC") Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Cc: <stable@vger.kernel.org> # v4.1+ Reviewed-by: Sheng Yang <sheng@yasker.org> Reviewed-by: Ashish Samant <ashish.samant@oracle.com> Tested-by: Sheng Yang <sheng@yasker.org> Tested-by: Ashish Samant <ashish.samant@oracle.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Felix Fietkau authored
[ Upstream commit 7711aaf0 ] A station pointer can be passed to the driver on tx, before it has been marked as associated. Since ath9k_sta_state was initializing the entry too late, it resulted in some spurious crashes. Fixes: df3c6eb3 ("ath9k: Use sta_state() callback") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Pawel Moll authored
[ Upstream commit b928466b ] The code setting XP watchpoint comparator and mask registers should, in order to be fully compliant with specification, zero one or more most significant bits of each field. In both L cases it means zeroing bit 63. The bitmask doing this was wrong, though, zeroing bit 60 instead. Fortunately, due to a lucky coincidence, this turned out to be fairly innocent with the existing hardware. Fixed now. Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Pawel Moll authored
[ Upstream commit b7c1beb2 ] Fuzzing the CCN perf driver revealed a small but definitely dangerous mistake in the event setup code. When a cycle counter is requested, the driver should not reconfigure the events bus at all, otherwise it will corrupt (in most but the simplest cases) its configuration and may end up accessing XP array out of its bounds and corrupting control registers. Reported-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Tyrel Datwyler authored
[ Upstream commit a87eeb90 ] Commit 655ee63c ("scsi constants: command, sense key + additional sense string") added a "Completed" sense string with key 0xF to snstext[], but failed to updated the upper bounds check of the sense key in scsi_sense_key_string(). Fixes: 655ee63c ("[SCSI] scsi constants: command, sense key + additional sense strings") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Johannes Berg authored
[ Upstream commit 4d0bd46a ] This reverts commit 3d5fdff4. Ben Hutchings pointed out that the commit isn't safe since it assumes that the structure used by the driver is iw_point, when in fact there's no way to know about that. Fortunately, the only driver in the tree that ever runs this code path is the wilc1000 staging driver, so it doesn't really matter. Clearly I should have investigated this better before applying, sorry. Reported-by: Ben Hutchings <ben@decadent.org.uk> Cc: stable@vger.kernel.org [though I guess it doesn't matter much] Fixes: 3d5fdff4 ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Sebastian Reichel authored
[ Upstream commit b46211d6 ] Add missing sysconfig/sysstatus information to OMAP3 hwmod. The information has been checked against OMAP34xx and OMAP36xx TRM. Without this change DSI block is not reset during boot, which is required for working Nokia N950 display. Signed-off-by: Sebastian Reichel <sre@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
- 18 Sep, 2016 1 commit
-
-
James Hogan authored
commit ba913e4f upstream. When mapping a page into the guest we error check using is_error_pfn(), however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an error HVA for the page. This can only happen on MIPS right now due to unusual memslot management (e.g. being moved / removed / resized), or with an Enhanced Virtual Memory (EVA) configuration where the default KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed in a later patch). This case will be treated as a pfn of zero, mapping the first page of physical memory into the guest. It would appear the MIPS KVM port wasn't updated prior to being merged (in v3.10) to take commit 81c52c56 ("KVM: do not treat noslot pfn as a error pfn") into account (merged v3.8), which converted a bunch of is_error_pfn() calls to is_error_noslot_pfn(). Switch to using is_error_noslot_pfn() instead to catch this case properly. Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [james.hogan@imgtec.com: Backport to v4.7.y] Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
- 17 Sep, 2016 1 commit
-
-
Sasha Levin authored
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
- 15 Sep, 2016 15 commits
-
-
Sasha Levin authored
This reverts commit 93c0b008. Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Emanuel Czirai authored
[ Upstream commit d1992996 ] AMD F12h machines have an erratum which can cause DIV/IDIV to behave unpredictably. The workaround is to set MSRC001_1029[31] but sometimes there is no BIOS update containing that workaround so let's do it ourselves unconditionally. It is simple enough. [ Borislav: Wrote commit message. ] Signed-off-by: Emanuel Czirai <icanrealizeum@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Yaowu Xu <yaowu@google.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20160902053550.18097-1-bp@alien8.deSigned-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Steven Rostedt authored
[ Upstream commit 15301a57 ] Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means that those functions are most likely called within critical sections of the funtion tracer, and must not be traced. In newer kenels _paravirt_nop() is defined within gcc asm(), and is no longer an issue. But both _paravirt_ident_{32,64}() causes the following splat when they are traced: mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054) mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070) mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054) mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054) NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469] Modules linked in: e1000e CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000 RIP: 0010:[<ffffffff81134148>] [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0 RSP: 0018:ffff8800d4aefb90 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40 RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030 RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000 R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8 R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0 FS: 00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0 Call Trace: _raw_spin_lock+0x27/0x30 handle_pte_fault+0x13db/0x16b0 handle_mm_fault+0x312/0x670 __do_page_fault+0x1b1/0x4e0 do_page_fault+0x22/0x30 page_fault+0x28/0x30 __vfs_read+0x28/0xe0 vfs_read+0x86/0x130 SyS_read+0x46/0xa0 entry_SYSCALL_64_fastpath+0x1e/0xa8 Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b Reported-by: Łukasz Daniluk <lukasz.daniluk@intel.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Miklos Szeredi authored
[ Upstream commit 7cb35119 ] Be defensive about what underlying fs provides us in the returned xattr list buffer. If it's not properly null terminated, bail out with a warning insead of BUG. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Miklos Szeredi authored
[ Upstream commit c11b9fdd ] Clear out posix acl xattrs on workdir and also reset the mode after creation so that an inherited sgid bit is cleared. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Jimi Damon authored
[ Upstream commit c8d19242 ] Added devices ids for acces i/o products quad and octal serial cards that make use of existing Pericom PI7C9X7954 and PI7C9X7958 configurations . Signed-off-by: Jimi Damon <jdamon@accesio.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Konstantin Khlebnikov authored
[ Upstream commit 17d0774f ] Attributes declared with __ATTR_PREALLOC use sysfs_kf_read() which returns zero bytes for non-zero offset. This breaks script checkarray in mdadm tool in debian where /bin/sh is 'dash' because its builtin 'read' reads only one byte at a time. Script gets 'i' instead of 'idle' when reads current action from /sys/block/$dev/md/sync_action and as a result does nothing. This patch adds trivial implementation of partial read: generate whole string and move required part into buffer head. Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Fixes: 4ef67a8c ("sysfs/kernfs: make read requests on pre-alloc files use the buffer.") Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787950 Cc: Stable <stable@vger.kernel.org> # v3.19+ Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
NeilBrown authored
[ Upstream commit 65da3484 ] attributes declared with __ATTR_PREALLOC use sysfs_kf_read() which ignores the 'count' arg. So a 1-byte read request can return more bytes than that. This is seen with the 'dash' shell when 'read' is used on some 'md' sysfs attributes. So only return the 'min' of count and the attribute length. Signed-off-by: NeilBrown <neilb@suse.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Tejun Heo authored
[ Upstream commit df6a58c5 ] kernfs_notify_workfn() sends out file modified events for the scheduled kernfs_nodes. Because the modifications aren't from userland, it doesn't have the matching file struct at hand and can't use fsnotify_modify(). Instead, it looked up the inode and then used d_find_any_alias() to find the dentry and used fsnotify_parent() and fsnotify() directly to generate notifications. The assumption was that the relevant dentries would have been pinned if there are listeners, which isn't true as inotify doesn't pin dentries at all and watching the parent doesn't pin the child dentries even for dnotify. This led to, for example, inotify watchers not getting notifications if the system is under memory pressure and the matching dentries got reclaimed. It can also be triggered through /proc/sys/vm/drop_caches or a remount attempt which involves shrinking dcache. fsnotify_parent() only uses the dentry to access the parent inode, which kernfs can do easily. Update kernfs_notify_workfn() so that it uses fsnotify() directly for both the parent and target inodes without going through d_find_any_alias(). While at it, supply the target file name to fsnotify() from kernfs_node->name. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Fixes: d911d987 ("kernfs: make kernfs_notify() trigger inotify events too") Cc: John McCutchan <john@johnmccutchan.com> Cc: Robert Love <rlove@rlove.org> Cc: Eric Paris <eparis@parisplace.org> Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Eric Biggers authored
[ Upstream commit 5d0be84e ] If crypt_alloc_tfms() had to allocate multiple tfms and it failed before the last allocation, then it would call crypt_free_tfms() and could free pointers from uninitialized memory -- due to the crypt_free_tfms() check for non-zero cc->tfms[i]. Fix by allocating zeroed memory. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Mikulas Patocka authored
[ Upstream commit 4e870e94 ] When dm-crypt processes writes, it allocates a new bio in crypt_alloc_buffer(). The bio is allocated from a bio set and it can have at most BIO_MAX_PAGES vector entries, however the incoming bio can be larger (e.g. if it was allocated by bcache). If the incoming bio is larger, bio_alloc_bioset() fails and an error is returned. To avoid the error, we test for a too large bio in the function crypt_map() and use dm_accept_partial_bio() to split the bio. dm_accept_partial_bio() trims the current bio to the desired size and asks DM core to send another bio with the rest of the data. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Vladimir Zapolskiy authored
[ Upstream commit 91e630d9 ] The kthread_run() function returns either a valid task_struct or ERR_PTR() value, check for NULL is invalid. This change fixes potential for oops, e.g. in OOM situation. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Mikulas Patocka authored
[ Upstream commit 7efb3673 ] bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector entries. However, the incoming bio may have more vector entries if it was allocated by other means. For example, bcache submits bios with more than BIO_MAX_PAGES entries. This results in bio_alloc() failure. To avoid the failure, change the code so that it allocates bio with at most BIO_MAX_PAGES entries. If the incoming bio has more entries, bio_add_page() will fail and a new bio will be allocated - the code that handles bio_add_page() failure already exists in the dm-log-writes target. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Josef Bacik <jbacik@fb,com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Mikulas Patocka authored
[ Upstream commit a5d60783 ] Move log_one_block()'s atomic_inc(&lc->io_blocks) before bio_alloc() to fix a bug that the target hangs if bio_alloc() fails. The error path does put_io_block(lc), so atomic_inc(&lc->io_blocks) must occur before invoking the error path to avoid underflow of lc->io_blocks. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Josef Bacik <jbacik@fb,com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Trond Myklebust authored
[ Upstream commit 98b0f80c ] On error, the callers expect us to return without bumping nn->cb_users[]. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Cc: stable@vger.kernel.org # v3.7+ Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
- 12 Sep, 2016 11 commits
-
-
Brian Foster authored
[ Upstream commit 800b2694 ] xfs_wait_buftarg() waits for all pending I/O, drains the ioend completion workqueue and walks the LRU until all buffers in the cache have been released. This is traditionally an unmount operation` but the mechanism is also reused during filesystem freeze. xfs_wait_buftarg() invokes drain_workqueue() as part of the quiesce, which is intended more for a shutdown sequence in that it indicates to the queue that new operations are not expected once the drain has begun. New work jobs after this point result in a WARN_ON_ONCE() and are otherwise dropped. With filesystem freeze, however, read operations are allowed and can proceed during or after the workqueue drain. If such a read occurs during the drain sequence, the workqueue infrastructure complains about the queued ioend completion work item and drops it on the floor. As a result, the buffer remains on the LRU and the freeze never completes. Despite the fact that the overall buffer cache cleanup is not necessary during freeze, fix up this operation such that it is safe to invoke during non-unmount quiesce operations. Replace the drain_workqueue() call with flush_workqueue(), which runs a similar serialization on pending workqueue jobs without causing new jobs to be dropped. This is safe for unmount as unmount independently locks out new operations by the time xfs_wait_buftarg() is invoked. cc: <stable@vger.kernel.org> Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Dave Chinner authored
[ Upstream commit f3d7ebde ] From inspection, the superblock sb_inprogress check is done in the verifier and triggered only for the primary superblock via a "bp->b_bn == XFS_SB_DADDR" check. Unfortunately, the primary superblock is an uncached buffer, and hence it is configured by xfs_buf_read_uncached() with: bp->b_bn = XFS_BUF_DADDR_NULL; /* always null for uncached buffers */ And so this check never triggers. Fix it. cc: <stable@vger.kernel.org> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Aleksandr Makarov authored
[ Upstream commit 40d9c325 ] These product IDs are listed in Windows driver. 0x6803 corresponds to WeTelecom WM-D300. 0x6802 name is unknown. Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Alan Stern authored
[ Upstream commit 53e5f36f ] UBSAN complains about a left shift by -1 in proc_do_submiturb(). This can occur when an URB is submitted for a bulk or control endpoint on a high-speed device, since the code doesn't bother to check the endpoint type; normally only interrupt or isochronous endpoints have a nonzero bInterval value. Aside from the fact that the operation is illegal, it shouldn't matter because the result isn't used. Still, in theory it could cause a hardware exception or other problem, so we should work around it. This patch avoids doing the left shift unless the shift amount is >= 0. The same piece of code has another problem. When checking the device speed (the exponential encoding for interrupt endpoints is used only by high-speed or faster devices), we need to look for speed >= USB_SPEED_SUPER as well as speed == USB_SPEED HIGH. The patch adds this check. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Vittorio Zecca <zeccav@gmail.com> Tested-by: Vittorio Zecca <zeccav@gmail.com> Suggested-by: Bjørn Mork <bjorn@mork.no> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Trond Myklebust authored
[ Upstream commit b88fa69e ] Ensure that the client conforms to the normative behaviour described in RFC5661 Section 12.7.2: "If a client believes its lease has expired, it MUST NOT send I/O to the storage device until it has validated its lease." So ensure that we wait for the lease to be validated before using the layout. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Cc: stable@vger.kernel.org # v3.20+ Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Linus Walleij authored
[ Upstream commit 7ac61a06 ] Any readings from the raw interface of the KXSD9 driver will return an empty string, because it does not return IIO_VAL_INT but rather some random value from the accelerometer to the caller. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Ian Abbott authored
[ Upstream commit f0f4b0cc ] Commit ebb657ba ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use") introduced a backwards compatibility issue in the use of asynchronous commands on the AO subdevice when `start_src` is `TRIG_EXT`. Valid values for `start_src` are `TRIG_INT` (for internal, software trigger), and `TRIG_EXT` (for external trigger). When set to `TRIG_EXT`. In both cases, the driver relies on an internal, software trigger to set things up (allowing the user application to write sufficient samples to the data buffer before the trigger), so it acts as a software "pre-trigger" in the `TRIG_EXT` case. The software trigger is handled by `ni_ao_inttrig()`. Prior to the above change, when `start_src` was `TRIG_INT`, `start_arg` was required to be 0, and `ni_ao_inttrig()` checked that the software trigger number was also 0. After the above change, when `start_src` was `TRIG_INT`, any value was allowed for `start_arg`, and `ni_ao_inttrig()` checked that the software trigger number matched this `start_arg` value. The backwards compatibility issue is that the internal trigger number now has to match `start_arg` when `start_src` is `TRIG_EXT` when it previously had to be 0. Fix the backwards compatibility issue in `ni_ao_inttrig()` by always allowing software trigger number 0 when `start_src` is something other than `TRIG_INT`. Thanks to Spencer Olson for reporting the issue. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Reported-by: Spencer Olson <olsonse@umich.edu> Fixes: ebb657ba ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use") Cc: stable <stable@vger.kernel.org> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Ian Abbott authored
[ Upstream commit 5ca05345 ] For counter subdevices, the `s->insn_write` handler is being set to the wrong function, `ni_tio_insn_read()`. It should be `ni_tio_insn_write()`. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Reported-by: Éric Piel <piel@delmic.com> Fixes: 10f74377 ("staging: comedi: ni_tio: make ni_tio_winsn() a proper comedi (*insn_write)" Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Ian Abbott authored
[ Upstream commit 80e162ee ] `daqboard2000_find_boardinfo()` is supposed to check if the DaqBoard/2000 series model is supported, based on the PCI subvendor and subdevice ID. The current code is wrong as it is comparing the PCI device's subdevice ID to an expected, fixed value for the subvendor ID. It should be comparing the PCI device's subvendor ID to this fixed value. Correct it. Fixes: 7e8401b2 ("staging: comedi: daqboard2000: add back subsystem_device check") Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Cc: <stable@vger.kernel.org> # 3.7+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Aleksandr Makarov authored
[ Upstream commit 6695593e ] Add support for WeTelecom WM-D200. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22de ProdID=6801 Rev=00.00 S: Manufacturer=WeTelecom Incorporated S: Product=WeTelecom Mobile Products C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-
Li Jun authored
[ Upstream commit c4e94174 ] When the controller is configured to be dual role and it's in host mode, if bind udc and gadgt driver, those gadget operations will do gadget disconnect and finally pull down DP line, which will break host function. Cc: <stable@vger.kernel.org> # 4.1+ Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
-