aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-04-25virtio_console: move removal codeMichael S. Tsirkin1-36/+36
Will make it reusable for error handling. Cc: [email protected] Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-04-25virtio_console: drop custom control queue cleanupMichael S. Tsirkin1-17/+0
We now cleanup all VQs on device removal - no need to handle the control VQ specially. Cc: [email protected] Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-04-25virtio_console: free buffers after resetMichael S. Tsirkin1-25/+24
Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose” buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers until device unplug. Of course this means we might get an interrupt for a vq without an attached port now. Handle that by discarding the consumed buffer. Reported-by: Tiwei Bie <[email protected]> Fixes: b3258ff1d6 ("virtio: Decrement avail idx on buffer detach") Cc: [email protected] Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-04-25virtio: add ability to iterate over vqsMichael S. Tsirkin1-0/+3
For cleanup it's helpful to be able to simply scan all vqs and discard all data. Add an iterator to do that. Cc: [email protected] Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-04-25virtio_console: don't tie bufs to a vqMichael S. Tsirkin1-7/+7
an allocated buffer doesn't need to be tied to a vq - only vq->vdev is ever used. Pass the function the just what it needs - the vdev. Cc: [email protected] Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-04-25firmware: some documentation fixesAndres Rodriguez3-6/+6
Including: - Fixup outdated kernel-doc paths - Slightly too short title underline - Some typos Signed-off-by: Andres Rodriguez <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-25cifs: smbd: Avoid allocating iov on the stackLong Li1-24/+12
It's not necessary to allocate another iov when going through the buffers in smbd_send() through RDMA send. Remove it to reduce stack size. Thanks to Matt for spotting a printk typo in the earlier version of this. CC: Matt Redfearn <[email protected]> Signed-off-by: Long Li <[email protected]> Acked-by: Ronnie Sahlberg <[email protected]> Cc: [email protected] Signed-off-by: Steve French <[email protected]>
2018-04-25cifs: smbd: Don't use RDMA read/write when signing is usedLong Li3-6/+19
SMB server will not sign data transferred through RDMA read/write. When signing is used, it's a good idea to have all the data signed. In this case, use RDMA send/recv for all data transfers. This will degrade performance as this is not generally configured in RDMA environemnt. So warn the user on signing and RDMA send/recv. Signed-off-by: Long Li <[email protected]> Acked-by: Ronnie Sahlberg <[email protected]> Cc: [email protected] Signed-off-by: Steve French <[email protected]>
2018-04-25SMB311: Fix reconnectSteve French1-2/+2
The preauth hash was not being recalculated properly on reconnect of SMB3.11 dialect mounts (which caused access denied repeatedly on auto-reconnect). Fixes: 8bd68c6e47ab ("CIFS: implement v3.11 preauth integrity") Signed-off-by: Steve French <[email protected]> CC: Stable <[email protected]> Reviewed-by: Ronnie Sahlberg <[email protected]>
2018-04-25ARM: amba: Don't read past the end of sysfs "driver_override" bufferGeert Uytterhoeven1-1/+2
When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count + 1 bytes for printing. Cfr. commits 4efe874aace57dba ("PCI: Don't read past the end of sysfs "driver_override" buffer") and bf563b01c2895a4b ("driver core: platform: Don't read past the end of "driver_override" buffer"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Todd Kjos <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-25ARM: amba: Fix race condition with driver_overrideGeert Uytterhoeven1-2/+9
The driver_override implementation is susceptible to a race condition when different threads are reading vs storing a different driver override. Add locking to avoid this race condition. Cfr. commits 6265539776a0810b ("driver core: platform: fix race condition with driver_override") and 9561475db680f714 ("PCI: Fix race condition with driver_override"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Todd Kjos <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-25Revert "blk-mq: remove code for dealing with remapping queue"Ming Lei1-3/+31
This reverts commit 37c7c6c76d431dd7ef9c29d95f6052bd425f004c. Turns out some drivers(most are FC drivers) may not use managed IRQ affinity, and has their customized .map_queues meantime, so still keep this code for avoiding regression. Reported-by: Laurence Oberman <[email protected]> Tested-by: Laurence Oberman <[email protected]> Tested-by: Christian Borntraeger <[email protected]> Tested-by: Stefan Haberland <[email protected]> Cc: Ewan Milne <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Sagi Grimberg <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-04-25selftests:firmware: fixes a call to a wrong function nameJeffrin Jose T1-1/+1
This is a patch to the tools/testing/selftests/firmware/fw_run_tests.sh file which fixes a bug which calls to a wrong function name,which in turn blocks the execution of certain tests. Signed-off-by: Jeffrin Jose T <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-25drm/amd/display: Check dc_sink every time in MST hotplugJerry (Fangzhi) Zuo1-7/+9
Extended fix to: "Don't read EDID in atomic_check" Fix issue of missing dc_sink in .mode_valid in hot plug routine. Need to check dc_sink everytime in .get_modes hook after checking edid, since edid is not getting removed in hot unplug but dc_sink doesn't. Signed-off-by: Jerry (Fangzhi) Zuo <[email protected]> Reviewed-by: Roman Li <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-04-25drm/amd/display: Update MST edid property every timeJerry (Fangzhi) Zuo1-3/+3
Extended fix to: "Don't read EDID in atomic_check" Fix display property not observed in GUI display after hot plug. Call drm_mode_connector_update_edid_property every time in .get_modes hook, due to the fact that edid property is getting removed from usermode ioctl DRM_IOCTL_MODE_GETCONNECTOR each time in hot unplug. Signed-off-by: Jerry (Fangzhi) Zuo <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-04-25drm/amd/display: Don't read EDID in atomic_checkHarry Wentland1-22/+10
We shouldn't attempt to read EDID in atomic_check. We really shouldn't even be modifying the connector object, or any other non-state object, but this is a start at least. Moving EDID cleanup to dm_dp_mst_connector_destroy from dm_dp_destroy_mst_connector to ensure the EDID is still available for headless mode. Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-04-25drm/amd/display: Disallow enabling CRTC without primary plane with FBHarry Wentland1-1/+9
The below commit "drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2" introduces a slight behavioral change to rmfb. Instead of disabling a crtc when the primary plane is disabled, it now preserves it. Since DC is currently not equipped to handle this we need to fail such a commit, otherwise we might see a corrupted screen. This is based on Shirish's previous approach but avoids adding all planes to the new atomic state which leads to a full update in DC for any commit, and is not what we intend. Theoretically DM should be able to deal with states with fully populated planes, even for simple updates, such as cursor updates. This should still be addressed in the future. Signed-off-by: Harry Wentland <[email protected]> Tested-by: Michel Dänzer <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2018-04-25drm/amd/display: Fix deadlock when flushing irqMikita Lipski1-2/+3
Lock irq table when reading a work in queue, unlock to flush the work, lock again till all tasks are cleared Signed-off-by: Mikita Lipski <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-04-25ALSA: hda - Skip jack and others for non-existing PCM streamsTakashi Iwai1-1/+8
When CONFIG_SND_DYNAMIC_MINORS isn't set, there are only limited number of devices available, and HD-audio, especially with HDMI/DP codec, will fail to create more than two devices. The driver warns about the lack of such devices and skips the PCM device creations, but the HDMI driver still tries to create the corresponding JACK, SPDIF and ELD controls even for the non-existing PCM substreams. This results in confusion on user-space, and even may break the operation. Similarly, Intel HDMI/DP codec builds the ELD notification from i915 graphics driver, and this may be broken if a notification is sent for the non-existing PCM stream. This patch adds the check of the existence of the assigned PCM substream in the both scenarios above, and skips the further operation if the PCM substream is not assigned. Fixes: 9152085defb6 ("ALSA: hda - add DP MST audio support") Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25tracing: Fix missing tab for hwlat_detector print formatPeter Xu1-1/+1
It's been missing for a while but no one is touching that up. Fix it. Link: http://lkml.kernel.org/r/[email protected] CC: Ingo Molnar <[email protected]> Cc:[email protected] Fixes: 7b2c86250122d ("tracing: Add NMI tracing in hwlat detector") Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-25selftests: ftrace: Add a testcase for multiple actions on triggerMasami Hiramatsu1-0/+44
Add a testcase for multiple actions with different parameters on an event trigger, which has been fixed by commit 192c283e93bd ("tracing: Add action comparisons when testing matching hist triggers"). Link: http://lkml.kernel.org/r/152292055227.15769.6327959816123227152.stgit@devbox Reviewed-by: Tom Zanussi <[email protected]> Tested-by: Tom Zanussi <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-25selftests: ftrace: Fix trigger extended error testcaseMasami Hiramatsu1-1/+1
Previous testcase redirects echo-out into /dev/null using "&>" as below echo "trigger-command" >> trigger &> /dev/null But this means redirecting both stdout and stderr into /dev/null because it is same as below echo "trigger-command" >> trigger > /dev/null 2>&1 So ">> trigger" redirects stdout to trigger file, but next "> /dev/null" redirects stdout to /dev/null again and the last "2>/&1" redirects stderr to stdout (/dev/null) This fixes it by "2> /dev/null". And also, since it must fail, add "!" to echo command. Link: http://lkml.kernel.org/r/152292052250.15769.12565292689264162435.stgit@devbox Fixes: f06eec4d0f2c ("selftests: ftrace: Add inter-event hist triggers testcases") Reviewed-by: Tom Zanussi <[email protected]> Tested-by: Tom Zanussi <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-25kprobes: Fix random address output of blacklist fileThomas Richter1-1/+1
File /sys/kernel/debug/kprobes/blacklist displays random addresses: [root@s8360046 linux]# cat /sys/kernel/debug/kprobes/blacklist 0x0000000047149a90-0x00000000bfcb099a print_type_x8 .... This breaks 'perf probe' which uses the blacklist file to prohibit probes on certain functions by checking the address range. Fix this by printing the correct (unhashed) address. The file mode is read all but this is not an issue as the file hierarchy points out: # ls -ld /sys/ /sys/kernel/ /sys/kernel/debug/ /sys/kernel/debug/kprobes/ /sys/kernel/debug/kprobes/blacklist dr-xr-xr-x 12 root root 0 Apr 19 07:56 /sys/ drwxr-xr-x 8 root root 0 Apr 19 07:56 /sys/kernel/ drwx------ 16 root root 0 Apr 19 06:56 /sys/kernel/debug/ drwxr-xr-x 2 root root 0 Apr 19 06:56 /sys/kernel/debug/kprobes/ -r--r--r-- 1 root root 0 Apr 19 06:56 /sys/kernel/debug/kprobes/blacklist Everything in and below /sys/kernel/debug is rwx to root only, no group or others have access. Background: Directory /sys/kernel/debug/kprobes is created by debugfs_create_dir() which sets the mode bits to rwxr-xr-x. Maybe change that to use the parent's directory mode bits instead? Link: http://lkml.kernel.org/r/[email protected] Fixes: ad67b74d2469 ("printk: hash addresses printed with %p") Cc: [email protected] Cc: <[email protected]> # v4.15+ Cc: Ananth N Mavinakayanahalli <[email protected]> Cc: Anil S Keshavamurthy <[email protected]> Cc: David S Miller <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: [email protected] Signed-off-by: Thomas Richter <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-25tracing: Fix kernel crash while using empty filter with perfRavi Bangoria1-7/+7
Kernel is crashing when user tries to record 'ftrace:function' event with empty filter: # perf record -e ftrace:function --filter="" ls # dmesg BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 Oops: 0000 [#1] SMP PTI ... RIP: 0010:ftrace_profile_set_filter+0x14b/0x2d0 RSP: 0018:ffffa4a7c0da7d20 EFLAGS: 00010246 RAX: ffffa4a7c0da7d64 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffff8c48ffc968f0 ... Call Trace: _perf_ioctl+0x54a/0x6b0 ? rcu_all_qs+0x5/0x30 ... After patch: # perf record -e ftrace:function --filter="" ls failed to set filter "" on event ftrace:function with 22 (Invalid argument) Also, if user tries to echo "" > filter, it used to throw an error. This behavior got changed by commit 80765597bc58 ("tracing: Rewrite filter logic to be simpler and faster"). This patch restores the behavior as a side effect: Before patch: # echo "" > filter # After patch: # echo "" > filter bash: echo: write error: Invalid argument # Link: http://lkml.kernel.org/r/[email protected] Fixes: 80765597bc58 ("tracing: Rewrite filter logic to be simpler and faster") Signed-off-by: Ravi Bangoria <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-25tracing/x86: Update syscall trace events to handle new prefixed syscall func ↵Steven Rostedt (VMware)1-2/+17
names Arnaldo noticed that the latest kernel is missing the syscall event system directory in x86. I bisected it down to d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()"). The system call trace events are special, as there is only one trace event for all system calls (the raw_syscalls). But a macro that wraps the system calls creates meta data for them that copies the name to find the system call that maps to the system call table (the number). At boot up, it does a kallsyms lookup of the system call table to find the function that maps to the meta data of the system call. If it does not find a function, then that system call is ignored. Because the x86 system calls had "__x64_", or "__ia32_" prefixed to the "sys" for the names, they do not match the default compare algorithm. As this was a problem for power pc, the algorithm can be overwritten by the architecture. The solution is to have x86 have its own algorithm to do the compare and this brings back the system call trace events. Link: http://lkml.kernel.org/r/[email protected] Reported-by: Arnaldo Carvalho de Melo <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Acked-by: Dominik Brodowski <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()") Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-25block: mq: Add some minor doc for core structsLinus Walleij2-0/+6
As it came up in discussion on the mailing list that the semantic meaning of 'blk_mq_ctx' and 'blk_mq_hw_ctx' isn't completely obvious to everyone, let's add some minimal kerneldoc for a starter. Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-04-25bcache: mark Coly Li as bcache maintainerJens Axboe1-0/+1
Since Michael had to step back, Coly has agreed to be the new maintainer. Mark him as such. Signed-off-by: Jens Axboe <[email protected]>
2018-04-25MAINTAINERS: Remove me as maintainer of bcacheMichael Lyle1-1/+0
Too much to do with other projects. I've enjoyed working with everyone here, and hope to occasionally contribute on bcache. Signed-off-by: Michael Lyle <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-04-25tty: Use __GFP_NOFAIL for tty_ldisc_get()Tetsuo Handa1-6/+5
syzbot is reporting crashes triggered by memory allocation fault injection at tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we have tried commit 5362544bebe85071 ("tty: don't panic on OOM in tty_set_ldisc()"). But we reverted that attempt by commit a8983d01f9b7d600 ("Revert "tty: don't panic on OOM in tty_set_ldisc()"") due to reproducible crash. We should spend resource for finding and fixing race condition bugs rather than complicate error paths for 2 * sizeof(void *) bytes allocation failure. [1] https://syzkaller.appspot.com/bug?id=489d33fa386453859ead58ff5171d43772b13aa3 Signed-off-by: Tetsuo Handa <[email protected]> Reported-by: syzbot <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Vegard Nossum <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Peter Hurley <[email protected]> Cc: One Thousand Gnomes <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-25hwmon: (k10temp) Add support for AMD Ryzen w/ Vega graphicsGuenter Roeck1-0/+5
Enable k10temp for AMD Ryzen APUs w/ Vega Mobile Gfx. Based on patch from René Rebe <[email protected]>. Dropped temperature offsets since those are not supposed to apply for the affected CPUs. Cc: [email protected] # v4.16+ Cc: René Rebe <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2018-04-25hwmon: (k10temp) Add temperature offset for Ryzen 2700XGuenter Roeck1-3/+9
Ryzen 2700X has a temperature offset of 10 degrees C. If bit 19 of the Temperature Control register is set, there is an additional offset of 49 degrees C. Take this into account as well. Cc: [email protected] # v4.16+ Signed-off-by: Guenter Roeck <[email protected]>
2018-04-25Merge tag 'kvmarm-fixes-for-4.17-1' of ↵Radim Krčmář14-15/+178
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm KVM/arm fixes for 4.17, take #1 - PSCI selection API, a leftover from 4.16 - Kick vcpu on active interrupt affinity change - Plug a VMID allocation race on oversubscribed systems - Silence debug messages - Update Christoffer's email address
2018-04-25powerpc: Fix smp_send_stop NMI IPI handlingNicholas Piggin1-5/+17
The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count over the handler function call, which causes later smp_send_nmi_ipi() callers to spin until the call is finished. The stop_this_cpu() function never returns, so the busy count is never decremeted, which can cause the system to hang in some cases. For example panic() will call smp_send_stop() early on which calls stop_this_cpu() on other CPUs, then later in the reboot path, pnv_restart() will call smp_send_stop() again, which hangs. Fix this by adding a special case to the stop_this_cpu() handler to decrement the busy count, because it will never return. Now that the NMI/non-NMI versions of stop_this_cpu() are different, split them out into separate functions rather than doing #ifdef tricks to share the body between the two functions. Fixes: 6bed3237624e3 ("powerpc: use NMI IPI for smp_send_stop") Reported-by: Abdul Haleem <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> [mpe: Split out the functions, tweak change log a bit] Signed-off-by: Michael Ellerman <[email protected]>
2018-04-25Merge tag 'asoc-fix-4.17-rc2' of ↵Takashi Iwai11-33/+85
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.17 A small batch of fixes collected since the merge window, none of which are particularly large or remarkable. They've all been cooking in -next for a while.
2018-04-25ALSA: hda/realtek - change the location for one of two front micsKailang Yang1-0/+1
On this Lenovo ThinkCentre machine. There are two front mics, we change the location for one of them. Relation: f33f79f3d0e5 ("ALSA: hda/realtek - change the location for one of two front microphones") Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25x86/pti: Filter at vma->vm_page_prot populationDave Hansen3-1/+19
commit ce9962bf7e22bb3891655c349faff618922d4a73 0day reported warnings at boot on 32-bit systems without NX support: attempted to set unsupported pgprot: 8000000000000025 bits: 8000000000000000 supported: 7fffffffffffffff WARNING: CPU: 0 PID: 1 at arch/x86/include/asm/pgtable.h:540 handle_mm_fault+0xfc1/0xfe0: check_pgprot at arch/x86/include/asm/pgtable.h:535 (inlined by) pfn_pte at arch/x86/include/asm/pgtable.h:549 (inlined by) do_anonymous_page at mm/memory.c:3169 (inlined by) handle_pte_fault at mm/memory.c:3961 (inlined by) __handle_mm_fault at mm/memory.c:4087 (inlined by) handle_mm_fault at mm/memory.c:4124 The problem is that due to the recent commit which removed auto-massaging of page protections, filtering page permissions at PTE creation time is not longer done, so vma->vm_page_prot is passed unfiltered to PTE creation. Filter the page protections before they are installed in vma->vm_page_prot. Fixes: fb43d6cb91 ("x86/mm: Do not auto-massage page protections") Reported-by: Fengguang Wu <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Kees Cook <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Dan Williams <[email protected]> Cc: Arjan van de Ven <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-25x86/pti: Disallow global kernel text with RANDSTRUCTDave Hansen1-0/+10
commit 26d35ca6c3776784f8156e1d6f80cc60d9a2a915 RANDSTRUCT derives its hardening benefits from the attacker's lack of knowledge about the layout of kernel data structures. Keep the kernel image non-global in cases where RANDSTRUCT is in use to help keep the layout a secret. Fixes: 8c06c7740 (x86/pti: Leave kernel text global for !PCID) Reported-by: Kees Cook <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Dan Williams <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Vlastimil Babka <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-25x86/pti: Reduce amount of kernel text allowed to be GlobalDave Hansen1-3/+13
commit abb67605203687c8b7943d760638d0301787f8d9 Kees reported to me that I made too much of the kernel image global. It was far more than just text: I think this is too much set global: _end is after data, bss, and brk, and all kinds of other stuff that could hold secrets. I think this should match what mark_rodata_ro() is doing. This does exactly that. We use __end_rodata_hpage_align as our marker both because it is huge-page-aligned and it does not contain any sections we expect to hold secrets. Kees's logic was that r/o data is in the kernel image anyway and, in the case of traditional distributions, can be freely downloaded from the web, so there's no reason to hide it. Fixes: 8c06c7740 (x86/pti: Leave kernel text global for !PCID) Reported-by: Kees Cook <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Dan Williams <[email protected]> Cc: Arjan van de Ven <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-25x86/pti: Fix boot warning from Global-bit settingDave Hansen1-10/+30
commit 231df823c4f04176f607afc4576c989895cff40e The pageattr.c code attempts to process "faults" when it goes looking for PTEs to change and finds non-present entries. It allows these faults in the linear map which is "expected to have holes", but WARN()s about them elsewhere, like when called on the kernel image. However, change_page_attr_clear() is now called on the kernel image in the process of trying to clear the Global bit. This trips the warning in __cpa_process_fault() if a non-present PTE is encountered in the kernel image. The "holes" in the kernel image result from free_init_pages()'s use of set_memory_np(). These holes are totally fine, and result from normal operation, just as they would be in the kernel linear map. Just silence the warning when holes in the kernel image are encountered. Fixes: 39114b7a7 (x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image) Reported-by: Mariusz Ceier <[email protected]> Reported-by: Aaro Koskinen <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Kees Cook <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dan Williams <[email protected]> Cc: Arjan van de Ven <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-25x86/pti: Fix boot problems from Global-bit settingDave Hansen1-2/+2
commit 16dce603adc9de4237b7bf2ff5c5290f34373e7b Part of the global bit _setting_ patches also includes clearing the Global bit when it should not be enabled. That is done with set_memory_nonglobal(), which uses change_page_attr_clear() in pageattr.c under the covers. The TLB flushing code inside pageattr.c has has checks like BUG_ON(irqs_disabled()), looking for interrupt disabling that might cause deadlocks. But, these also trip in early boot on certain preempt configurations. Just copy the existing BUG_ON() sequence from cpa_flush_range() to the other two sites and check for early boot. Fixes: 39114b7a7 (x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image) Reported-by: Mariusz Ceier <[email protected]> Reported-by: Aaro Koskinen <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Kees Cook <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dan Williams <[email protected]> Cc: Arjan van de Ven <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-25ALSA: rme9652: Hardening for potential Spectre v1Takashi Iwai1-2/+4
As recently Smatch suggested, one place in RME9652 driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652->channel_map' (local cap) This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: hdspm: Hardening for potential Spectre v1Takashi Iwai1-10/+14
As recently Smatch suggested, a couple of places in HDSP MADI driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_out' (local cap) sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_in' (local cap) This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: asihpi: Hardening for potential Spectre v1Takashi Iwai2-5/+12
As recently Smatch suggested, a couple of places in ASIHPI driver may expand the array directly from the user-space value with speculation: sound/pci/asihpi/hpimsginit.c:70 hpi_init_response() warn: potential spectre issue 'res_size' (local cap) sound/pci/asihpi/hpioctl.c:189 asihpi_hpi_ioctl() warn: potential spectre issue 'adapters' This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: opl3: Hardening for potential Spectre v1Takashi Iwai1-2/+5
As recently Smatch suggested, one place in OPL3 driver may expand the array directly from the user-space value with speculation: sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap' This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: hda: Hardening for potential Spectre v1Takashi Iwai1-1/+11
As recently Smatch suggested, one place in HD-audio hwdep ioctl codes may expand the array directly from the user-space value with speculation: sound/pci/hda/hda_local.h:467 get_wcaps() warn: potential spectre issue 'codec->wcaps' As get_wcaps() itself is a fairly frequently called inline function, and there is only one single call with a user-space value, we replace only the latter one to open-code locally with array_index_nospec() hardening in this patch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: control: Hardening for potential Spectre v1Takashi Iwai1-2/+5
As recently Smatch suggested, a few places in ALSA control core codes may expand the array directly from the user-space value with speculation: sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd' sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd' sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. In this patch, we put array_index_nospec() to the common snd_ctl_get_ioff*() helpers instead of each caller. These helpers are also referred from some drivers, too, and basically all usages are to calculate the array index from the user-space value, hence it's better to cover there. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: seq: oss: Hardening for potential Spectre v1Takashi Iwai4-40/+55
As Smatch recently suggested, a few places in OSS sequencer codes may expand the array directly from the user-space value with speculation, namely there are a significant amount of references to either info->ch[] or dp->synths[] array: sound/core/seq/oss/seq_oss_event.c:315 note_on_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_event.c:362 note_off_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_synth.c:470 snd_seq_oss_synth_load_patch() warn: potential spectre issue 'dp->synths' (local cap) sound/core/seq/oss/seq_oss_event.c:293 note_on_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_event.c:353 note_off_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:506 snd_seq_oss_synth_sysex() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:580 snd_seq_oss_synth_ioctl() warn: potential spectre issue 'dp->synths' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. We may put array_index_nospec() at each place, but here we take a different approach: - For dp->synths[], change the helpers to retrieve seq_oss_synthinfo pointer directly instead of the array expansion at each place - For info->ch[], harden in a normal way, as there are only a couple of places As a result, the existing helper, snd_seq_oss_synth_is_valid() is replaced with snd_seq_oss_synth_info(). Also, we cover MIDI device where a similar array expansion is done, too, although it wasn't reported by Smatch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: seq: oss: Fix unbalanced use lock for synth MIDI deviceTakashi Iwai1-4/+8
When get_synthdev() is called for a MIDI device, it returns the fixed midi_synth_dev without the use refcounting. OTOH, the caller is supposed to unreference unconditionally after the usage, so this would lead to unbalanced refcount. This patch corrects the behavior and keep up the refcount balance also for the MIDI synth device. Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: hda/realtek - Update ALC255 depop optimizeKailang Yang1-0/+2
Add ALC255 its own depop functions for alc_init and alc_shutup. Assign it to ALC256 usage. Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-04-25ALSA: hda/realtek - Add some fixes for ALC233Kailang Yang1-0/+2
Fill COEF to change EAPD to verb control. Assigned codec type. This is an additional fix over 92f974df3460 ("ALSA: hda/realtek - New vendor ID for ALC233"). [ More notes: according to Kailang, the chip is 10ec:0235 bonding for ALC233b, which is equivalent with ALC255. It's only used for Lenovo. The chip needs no alc_process_coef_fw() for headset unlike ALC255. ] Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.