commit 6f20f6d4c095967c3debdb1d4c224ebf3da85452 Author: Sasha Levin Date: Mon Mar 5 16:35:54 2018 -0500 Linux 4.1.50 Signed-off-by: Sasha Levin commit d8a0064eb23acd53e8dc32976b3f855ebe2c1871 Author: Daniel Mentz Date: Wed Feb 14 12:54:19 2018 +0100 media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic commit a1dfb4c48cc1e64eeb7800a27c66a6f7e88d075a upstream. The 32-bit compat v4l2 ioctl handling is implemented based on its 64-bit equivalent. It converts 32-bit data structures into its 64-bit equivalents and needs to provide the data to the 64-bit ioctl in user space memory which is commonly allocated using compat_alloc_user_space(). However, due to how that function is implemented, it can only be called a single time for every syscall invocation. Supposedly to avoid this limitation, the existing code uses a mix of memory from the kernel stack and memory allocated through compat_alloc_user_space(). Under normal circumstances, this would not work, because the 64-bit ioctl expects all pointers to point to user space memory. As a workaround, set_fs(KERNEL_DS) is called to temporarily disable this extra safety check and allow kernel pointers. However, this might introduce a security vulnerability: The result of the 32-bit to 64-bit conversion is writeable by user space because the output buffer has been allocated via compat_alloc_user_space(). A malicious user space process could then manipulate pointers inside this output buffer, and due to the previous set_fs(KERNEL_DS) call, functions like get_user() or put_user() no longer prevent kernel memory access. The new approach is to pre-calculate the total amount of user space memory that is needed, allocate it using compat_alloc_user_space() and then divide up the allocated memory to accommodate all data structures that need to be converted. An alternative approach would have been to retain the union type karg that they allocated on the kernel stack in do_video_ioctl(), copy all data from user space into karg and then back to user space. However, we decided against this approach because it does not align with other compat syscall implementations. Instead, we tried to replicate the get_user/put_user pairs as found in other places in the kernel: if (get_user(clipcount, &up->clipcount) || put_user(clipcount, &kp->clipcount)) return -EFAULT; Notes from hans.verkuil@cisco.com: This patch was taken from: https://github.com/LineageOS/android_kernel_samsung_apq8084/commit/97b733953c06e4f0398ade18850f0817778255f7 Clearly nobody could be bothered to upstream this patch or at minimum tell us :-( We only heard about this a week ago. This patch was rebased and cleaned up. Compared to the original I also swapped the order of the convert_in_user arguments so that they matched copy_in_user. It was hard to review otherwise. I also replaced the ALLOC_USER_SPACE/ALLOC_AND_GET by a normal function. Fixes: 6b5a9492ca ("v4l: introduce string control support.") Signed-off-by: Daniel Mentz Co-developed-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 77a6ac91c1fd375e45e642f199a4cd434c493905 Author: Hans Verkuil Date: Wed Feb 14 12:54:18 2018 +0100 media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors commit d83a8243aaefe62ace433e4384a4f077bed86acb upstream. Some ioctls need to copy back the result even if the ioctl returned an error. However, don't do this for the error code -ENOTTY. It makes no sense in that cases. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 60e5b2805609e833f6e4e58210198f1ba1081bf6 Author: Hans Verkuil Date: Wed Feb 14 12:54:17 2018 +0100 media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type commit 169f24ca68bf0f247d111aef07af00dd3a02ae88 upstream. There is nothing wrong with using an unknown buffer type. So stop spamming the kernel log whenever this happens. The kernel will just return -EINVAL to signal this. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 77868b7ebc535860ef6154287d250661dfd7b96e Author: Hans Verkuil Date: Wed Feb 14 12:54:16 2018 +0100 media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32 commit a751be5b142ef6bcbbb96d9899516f4d9c8d0ef4 upstream. put_v4l2_window32() didn't copy back the clip list to userspace. Drivers can update the clip rectangles, so this should be done. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 014b8280199049b634cb603ac1261b617ada0b4d Author: Daniel Mentz Date: Wed Feb 14 12:54:15 2018 +0100 media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha commit 025a26fa14f8fd55d50ab284a30c016a5be953d0 upstream. Commit b2787845fb91 ("V4L/DVB (5289): Add support for video output overlays.") added the field global_alpha to struct v4l2_window but did not update the compat layer accordingly. This change adds global_alpha to struct v4l2_window32 and copies the value for global_alpha back and forth. Signed-off-by: Daniel Mentz Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c39df2a767949a678f14d9120a94b1a1d7376924 Author: Hans Verkuil Date: Wed Feb 14 12:54:14 2018 +0100 media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs commit 273caa260035c03d89ad63d72d8cd3d9e5c5e3f1 upstream. If the device is of type VFL_TYPE_SUBDEV then vdev->ioctl_ops is NULL so the 'if (!ops->vidioc_query_ext_ctrl)' check would crash. Add a test for !ops to the condition. All sub-devices that have controls will use the control framework, so they do not have an equivalent to ops->vidioc_query_ext_ctrl. Returning false if ops is NULL is the correct thing to do here. Fixes: b8c601e8af ("v4l2-compat-ioctl32.c: fix ctrl_is_pointer") Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Reported-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f610be05b2a8b962ccb593e72c9cb11b40280cc4 Author: Hans Verkuil Date: Wed Feb 14 12:54:13 2018 +0100 media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer commit b8c601e8af2d08f733d74defa8465303391bb930 upstream. ctrl_is_pointer just hardcoded two known string controls, but that caused problems when using e.g. custom controls that use a pointer for the payload. Reimplement this function: it now finds the v4l2_ctrl (if the driver uses the control framework) or it calls vidioc_query_ext_ctrl (if the driver implements that directly). In both cases it can now check if the control is a pointer control or not. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 834ccb4843d20009860f8c8c3ac890c0166aa1b9 Author: Hans Verkuil Date: Wed Feb 14 12:54:12 2018 +0100 media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32 commit 8ed5a59dcb47a6f76034ee760b36e089f3e82529 upstream. The struct v4l2_plane32 should set m.userptr as well. The same happens in v4l2_buffer32 and v4l2-compliance tests for this. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cb93dfd73bee8223288224c819ecb3ae6d78f1ec Author: Hans Verkuil Date: Wed Feb 14 12:54:11 2018 +0100 media: v4l2-compat-ioctl32.c: avoid sizeof(type) commit 333b1e9f96ce05f7498b581509bb30cde03018bf upstream. Instead of doing sizeof(struct foo) use sizeof(*up). There even were cases where 4 * sizeof(__u32) was used instead of sizeof(kp->reserved), which is very dangerous when the size of the reserved array changes. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0d22adeea8035c6d0033d1492a26022253723161 Author: Hans Verkuil Date: Wed Feb 14 12:54:10 2018 +0100 media: v4l2-compat-ioctl32.c: move 'helper' functions to __get/put_v4l2_format32 commit 486c521510c44a04cd756a9267e7d1e271c8a4ba upstream. These helper functions do not really help. Move the code to the __get/put_v4l2_format32 functions. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0ac25fe31ec71b345a4fdd31e6f31810a9a655a6 Author: Hans Verkuil Date: Wed Feb 14 12:54:09 2018 +0100 media: v4l2-compat-ioctl32.c: fix the indentation commit b7b957d429f601d6d1942122b339474f31191d75 upstream. The indentation of this source is all over the place. Fix this. This patch only changes whitespace. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 68819319e746635c8eb96b150f36290c1d2851a9 Author: Hans Verkuil Date: Wed Feb 14 12:54:08 2018 +0100 media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF commit 3ee6d040719ae09110e5cdf24d5386abe5d1b776 upstream. The result of the VIDIOC_PREPARE_BUF ioctl was never copied back to userspace since it was missing in the switch. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6842e64101b0cbb1e4c3458167d8b45bd5e68b65 Author: Ricardo Ribalda Date: Wed Feb 14 12:54:07 2018 +0100 vb2: V4L2_BUF_FLAG_DONE is set after DQBUF commit 3171cc2b4eb9831ab4df1d80d0410a945b8bc84e upstream. According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF: V4L2_BUF_FLAG_DONE 0x00000004 ... After calling the VIDIOC_QBUF or VIDIOC_DQBUF it is always cleared ... Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This can be tested with vivid and dev_debug: [257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3, type=vid-cap, flags=0x00002004, field=none, sequence=163, memory=userptr, bytesused=460800, offset/userptr=0x344b000, length=460800 This patch forces FLAG_DONE to 0 after calling DQBUF. Reported-by: Dimitrios Katsaros Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f28e2783d2fbf5b04872b998c48bd21c7842b322 Author: Hans Verkuil Date: Wed Feb 14 12:54:06 2018 +0100 media: v4l2-ioctl.c: don't copy back the result for -ENOTTY commit 181a4a2d5a0a7b43cab08a70710d727e7764ccdd upstream. If the ioctl returned -ENOTTY, then don't bother copying back the result as there is no point. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0edffe75fc811fa5181ea202a1ad26bf17fd58f5 Author: Anton Blanchard Date: Fri Mar 2 15:45:49 2018 +1100 powerpc/vdso64: Use double word compare on pointers commit 5045ea37377ce8cca6890d32b127ad6770e6dce5 upstream. __kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to check if the passed in pointer is non zero. cmpli maps to a 32 bit compare on binutils, so we ignore the top 32 bits. A simple test case can be created by passing in a bogus pointer with the bottom 32 bits clear. Using a clk_id that is handled by the VDSO, then one that is handled by the kernel shows the problem: printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000)); printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000)); And we get: 0 -1 The bigger issue is if we pass a valid pointer with the bottom 32 bits clear, in this case we will return success but won't write any data to the pointer. I stumbled across this issue because the LLVM integrated assembler doesn't accept cmpli with 3 arguments. Fix this by converting them to cmpldi. Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Cc: stable@vger.kernel.org # v2.6.15+ Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f1d035422a54914c03aebda611ad3f6b3ecf0636 Author: Khem Raj Date: Fri Mar 2 15:45:48 2018 +1100 powerpc/ptrace: Fix out of bounds array access warning commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream. gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds] offsetof(struct thread_fp_state, fpr[32][0])); ^ check the end of array instead of beginning of next element to fix this Signed-off-by: Khem Raj Cc: Kees Cook Cc: Michael Ellerman Cc: Segher Boessenkool Tested-by: Aaro Koskinen Acked-by: Olof Johansson Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit fe4de7adb52d72747dd05dd6b2309d7aa6678399 Author: Michal Suchanek Date: Fri Mar 2 15:45:47 2018 +1100 powerpc/pseries: include linux/types.h in asm/hvcall.h commit 1b689a95ce7427075f9ac9fb4aea1af530742b7f upstream. Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings") uses u64 in asm/hvcall.h without including linux/types.h This breaks hvcall.h users that do not include the header themselves. Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings") Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ba9a94142fffa07fe21f7b2c727414a74a6da65a Author: Oliver O'Halloran Date: Fri Mar 2 15:45:45 2018 +1100 powerpc/powernv: Check device-tree for RFI flush settings commit 6e032b350cd1fdb830f18f8320ef0e13b4e24094 upstream. New device-tree properties are available which tell the hypervisor settings related to the RFI flush. Use them to determine the appropriate flush instruction to use, and whether the flush is required. Signed-off-by: Oliver O'Halloran Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e04aa563e8644cb446ec608497b3d4c59b320e49 Author: Nicholas Piggin Date: Fri Mar 2 15:45:43 2018 +1100 powerpc/64s: Improve RFI L1-D cache flush fallback commit bfcd89a1d61a4a6bca3319e2ab70d7c745baf823 upstream. The fallback RFI flush is used when firmware does not provide a way to flush the cache. It's a "displacement flush" that evicts useful data by displacing it with an uninteresting buffer. The flush has to take care to work with implementation specific cache replacment policies, so the recipe has been in flux. The initial slow but conservative approach is to touch all lines of a congruence class, with dependencies between each load. It has since been determined that a linear pattern of loads without dependencies is sufficient, and is significantly faster. Measuring the speed of a null syscall with RFI fallback flush enabled gives the relative improvement: P8 - 1.83x P9 - 1.75x The flush also becomes simpler and more adaptable to different cache geometries. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit bfc3602cced50bc19a02c96d42b27bd08715a399 Author: Nicholas Piggin Date: Fri Mar 2 15:45:37 2018 +1100 powerpc/64s: Simple RFI macro conversions commit 222f20f140623ef6033491d0103ee0875fe87d35 upstream. This commit does simple conversions of rfi/rfid to the new macros that include the expected destination context. By simple we mean cases where there is a single well known destination context, and it's simply a matter of substituting the instruction for the appropriate macro. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman [Balbir fixed issues with backporting to stable] Signed-off-by: Balbir Singh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f99fb439e6aff4e9f8b91a80d48b2a2d97aa2248 Author: Eric Dumazet Date: Fri Dec 2 09:44:53 2016 -0800 net: avoid signed overflows for SO_{SND|RCV}BUFFORCE [ Upstream commit b98b0bc8c431e3ceb4b26b0dfc8db509518fb290 ] CAP_NET_ADMIN users should not be allowed to set negative sk_sndbuf or sk_rcvbuf values, as it can lead to various memory corruptions, crashes, OOM... Note that before commit 82981930125a ("net: cleanups in sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF and SO_RCVBUF were vulnerable. This needs to be backported to all known linux kernels. Again, many thanks to syzkaller team for discovering this gem. Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b921b9340ccb84d5aa649fd38a3edf8dfcc5ef27 Author: Sebastian Andrzej Siewior Date: Fri Aug 5 15:37:39 2016 +0200 x86/mm: Disable preemption during CR3 read+write [ Upstream commit 5cf0791da5c162ebc14b01eb01631cfa7ed4fa6e ] There's a subtle preemption race on UP kernels: Usually current->mm (and therefore mm->pgd) stays the same during the lifetime of a task so it does not matter if a task gets preempted during the read and write of the CR3. But then, there is this scenario on x86-UP: TaskA is in do_exit() and exit_mm() sets current->mm = NULL followed by: -> mmput() -> exit_mmap() -> tlb_finish_mmu() -> tlb_flush_mmu() -> tlb_flush_mmu_tlbonly() -> tlb_flush() -> flush_tlb_mm_range() -> __flush_tlb_up() -> __flush_tlb() -> __native_flush_tlb() At this point current->mm is NULL but current->active_mm still points to the "old" mm. Let's preempt taskA _after_ native_read_cr3() by taskB. TaskB has its own mm so CR3 has changed. Now preempt back to taskA. TaskA has no ->mm set so it borrows taskB's mm and so CR3 remains unchanged. Once taskA gets active it continues where it was interrupted and that means it writes its old CR3 value back. Everything is fine because userland won't need its memory anymore. Now the fun part: Let's preempt taskA one more time and get back to taskB. This time switch_mm() won't do a thing because oldmm (->active_mm) is the same as mm (as per context_switch()). So we remain with a bad CR3 / PGD and return to userland. The next thing that happens is handle_mm_fault() with an address for the execution of its code in userland. handle_mm_fault() realizes that it has a PTE with proper rights so it returns doing nothing. But the CPU looks at the wrong PGD and insists that something is wrong and faults again. And again. And one more time… This pagefault circle continues until the scheduler gets tired of it and puts another task on the CPU. It gets little difficult if the task is a RT task with a high priority. The system will either freeze or it gets fixed by the software watchdog thread which usually runs at RT-max prio. But waiting for the watchdog will increase the latency of the RT task which is no good. Fix this by disabling preemption across the critical code section. Signed-off-by: Sebastian Andrzej Siewior Acked-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Acked-by: Andy Lutomirski Cc: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1470404259-26290-1-git-send-email-bigeasy@linutronix.de [ Prettified the changelog. ] Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9e6aba7422fd988b3345d51f96503cf3b148db6f Author: Theodore Ts'o Date: Fri Mar 2 14:21:13 2018 -0800 ext4 crypto: don't regenerate the per-inode encryption key unnecessarily [ Relevant upstream commit: 1b53cf9815bb4744958d41f3795d5d5a1d365e2d ] This fixes the same problem as upstream commit 1b53cf9815bb: "fscrypt: remove broken support for detecting keyring key revocation". Specifically, key revocations racing with readpage operations will cause the kernel to crash and burn with a BUG_ON or a NULL pointer dereference in a block I/O callback stemming from an ext4_readpage() operation. This fix is needed to fix prevent xfstests test runs from crashing while running the generic/421 test. The root cause is different in the 4.1 kernel, however, since the 4.1's encryption handling is so _primitive_ compared to later kernels. The code isn't actually explicitly checking for revoked keys. Instead, the code is neededly regenerating the per-file encryption key on every mmap() or open() or directory operation (in the case of a directory inode). Yelch! If the file is already opened and actively being read, and while an open() is racing with the read operations, after the user's master key has been revoked, there will be the same net effect as the problem fixed by upstream commit 1b53cf9815bb --- the per-file key will be marked as invalid and this will cause a BUG_ON. The AOSP 3.18 and 4.4 android-common kernels have a much more modern version of ext4 encryption have been backported, which incldes a backport of upstream commit 1b53cf9815bb. This is a (at least) dozen-plus commits, and isn't really suitable for the Upstream LTS kernel. So instead, this is the simplest bug which fixes the same high-level issue as the upstream commit, without dragging in all of the other non-bug-fix improvements to ext4 encryption found in newer kernels. Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit e68557814c7e9e4943caca924ff5537952bb3b4e Author: Eric Biggers Date: Fri Mar 2 14:21:12 2018 -0800 fscrypto: add authorization check for setting encryption policy commit 163ae1c6ad6299b19e22b4a35d5ab24a89791a98 upstream. On an ext4 or f2fs filesystem with file encryption supported, a user could set an encryption policy on any empty directory(*) to which they had readonly access. This is obviously problematic, since such a directory might be owned by another user and the new encryption policy would prevent that other user from creating files in their own directory (for example). Fix this by requiring inode_owner_or_capable() permission to set an encryption policy. This means that either the caller must own the file, or the caller must have the capability CAP_FOWNER. (*) Or also on any regular file, for f2fs v4.6 and later and ext4 v4.8-rc1 and later; a separate bug fix is coming for that. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit ed6923107e5d09dfe1e79bf8f3cdb6815994d216 Author: Richard Weinberger Date: Fri Mar 2 14:21:11 2018 -0800 ext4: require encryption feature for EXT4_IOC_SET_ENCRYPTION_POLICY commit 9a200d075e5d05be1fcad4547a0f8aee4e2f9a04 upstream. ...otherwise an user can enable encryption for certain files even when the filesystem is unable to support it. Such a case would be a filesystem created by mkfs.ext4's default settings, 1KiB block size. Ext4 supports encyption only when block size is equal to PAGE_SIZE. But this constraint is only checked when the encryption feature flag is set. Signed-off-by: Richard Weinberger Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 6e493d18d70209a60b091f706876d54e6ea5ce2b Author: Yoshihiro Shimoda Date: Mon Feb 5 17:12:35 2018 +0900 usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path [ Upstream commit 17aa31f13cad25daa19d3f923323f552e87bc874 ] This fixes an issue that a gadget driver (usb_f_fs) is possible to stop rx transactions after the usb-dmac is used because the following functions missed to set/check the "running" flag. - usbhsf_dma_prepare_pop_with_usb_dmac() - usbhsf_dma_pop_done_with_usb_dmac() So, if next transaction uses pio, the usbhsf_prepare_pop() can not start the transaction because the "running" flag is 0. Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle") Cc: # v3.19+ Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit b177a6a134847538b78c12fffb49afe2f8335be0 Author: Jack Pham Date: Wed Jan 24 00:11:53 2018 -0800 usb: gadget: f_fs: Process all descriptors during bind [ Upstream commit 6cf439e0d37463e42784271179c8a308fd7493c6 ] During _ffs_func_bind(), the received descriptors are evaluated to prepare for binding with the gadget in order to allocate endpoints and optionally set up OS descriptors. However, the high- and super-speed descriptors are only parsed based on whether the gadget_is_dualspeed() and gadget_is_superspeed() calls are true, respectively. This is a problem in case a userspace program always provides all of the {full,high,super,OS} descriptors when configuring a function. Then, for example if a gadget device is not capable of SuperSpeed, the call to ffs_do_descs() for the SS descriptors is skipped, resulting in an incorrect offset calculation for the vla_ptr when moving on to the OS descriptors that follow. This causes ffs_do_os_descs() to fail as it is now looking at the SS descriptors' offset within the raw_descs buffer instead. _ffs_func_bind() should evaluate the descriptors unconditionally, so remove the checks for gadget speed. Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support") Cc: stable@vger.kernel.org Co-Developed-by: Mayank Rana Signed-off-by: Mayank Rana Signed-off-by: Jack Pham Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 65238bd966d75fd7b65f9dd21291f75251390286 Author: Karsten Koop Date: Fri Feb 9 09:12:06 2018 +0000 usb: ldusb: add PIDs for new CASSY devices supported by this driver [ Upstream commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 ] This patch adds support for new CASSY devices to the ldusb driver. The PIDs are also added to the ignore list in hid-quirks. Signed-off-by: Karsten Koop Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b2f7ec117db86b97da67ef46d42562cfc51b3cce Author: Thinh Nguyen Date: Fri Jan 12 18:18:05 2018 -0800 usb: dwc3: gadget: Set maxpacket size for ep0 IN [ Upstream commit 6180026341e852a250e1f97ebdcf71684a3c81b9 ] There are 2 control endpoint structures for DWC3. However, the driver only updates the OUT direction control endpoint structure during ConnectDone event. DWC3 driver needs to update the endpoint max packet size for control IN endpoint as well. If the max packet size is not properly set, then the driver will incorrectly calculate the data transfer size and fail to send ZLP for HS/FS 3-stage control read transfer. The fix is simply to update the max packet size for the ep0 IN direction during ConnectDone event. Cc: stable@vger.kernel.org Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit faaae90fb89bb2efbac639a92c444eb333068aab Author: Jack Stocker Date: Thu Feb 15 18:24:10 2018 +0000 Add delay-init quirk for Corsair K70 RGB keyboards [ Upstream commit 7a1646d922577b5b48c0d222e03831141664bb59 ] Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Device ids found here: usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-3: Product: Corsair K70 RGB Gaming Keyboard Signed-off-by: Jack Stocker Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 112c4b6a199128b3b8bcb6fc98c670d5bcb44ed2 Author: Michael Weiser Date: Thu Feb 1 23:13:38 2018 +0100 arm64: Disable unhandled signal log messages by default [ Upstream commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 ] aarch64 unhandled signal kernel messages are very verbose, suggesting them to be more of a debugging aid: sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000046, in sigsegv[400000+71000] CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3 Hardware name: linux,dummy-virt (DT) pstate: 60000000 (nZCv daif -PAN -UAO) pc : 0x4003f4 lr : 0x4006bc sp : 0000fffffe94a060 x29: 0000fffffe94a070 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 00000000004001b0 x23: 0000000000486ac8 x22: 00000000004001c8 x21: 0000000000000000 x20: 0000000000400be8 x19: 0000000000400b30 x18: 0000000000484728 x17: 000000000865ffc8 x16: 000000000000270f x15: 00000000000000b0 x14: 0000000000000002 x13: 0000000000000001 x12: 0000000000000000 x11: 0000000000000000 x10: 0008000020008008 x9 : 000000000000000f x8 : ffffffffffffffff x7 : 0004000000000000 x6 : ffffffffffffffff x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000004003e4 x2 : 0000fffffe94a1e8 x1 : 000000000000000a x0 : 0000000000000000 Disable them by default, so they can be enabled using /proc/sys/debug/exception-trace. Cc: Signed-off-by: Michael Weiser Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4de9764476aee61413f520328e6ec753feae64ca Author: AMAN DEEP Date: Thu Feb 8 11:55:01 2018 +0800 usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks() [ Upstream commit 46408ea558df13b110e0866b99624384a33bdeba ] There is a race condition between finish_unlinks->finish_urb() function and usb_kill_urb() in ohci controller case. The finish_urb calls spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call, then if during this time, usb_kill_urb is called for another endpoint, then new ed will be added to ed_rm_list at beginning for unlink, and ed_rm_list will point to newly added. When finish_urb() is completed in finish_unlinks() and ed->td_list becomes empty as in below code (in finish_unlinks() function): if (list_empty(&ed->td_list)) { *last = ed->ed_next; ed->ed_next = NULL; } else if (ohci->rh_state == OHCI_RH_RUNNING) { *last = ed->ed_next; ed->ed_next = NULL; ed_schedule(ohci, ed); } The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next and previously added ed by usb_kill_urb will be left unreferenced by ed_rm_list. This causes usb_kill_urb() hang forever waiting for finish_unlink to remove added ed from ed_rm_list. The main reason for hang in this race condtion is addition and removal of ed from ed_rm_list in the beginning during usb_kill_urb and later last* is modified in finish_unlinks(). As suggested by Alan Stern, the solution for proper handling of ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing any URBs. Then at the end, we can add ed back to the list if necessary. This properly handle the updated ohci->ed_rm_list in usb_kill_urb(). Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies") Acked-by: Alan Stern CC: Signed-off-by: Aman Deep Signed-off-by: Jeffy Chen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1bb0e77e4dd294837e99ceb492560074d68c896e Author: Shanker Donthineni Date: Wed Jan 31 18:03:42 2018 -0600 irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() [ Upstream commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e ] A DMB instruction can be used to ensure the relative order of only memory accesses before and after the barrier. Since writes to system registers are not memory operations, barrier DMB is not sufficient for observability of memory accesses that occur before ICC_SGI1R_EL1 writes. A DSB instruction ensures that no instructions that appear in program order after the DSB instruction, can execute until the DSB instruction has completed. Cc: stable@vger.kernel.org Acked-by: Will Deacon , Signed-off-by: Shanker Donthineni Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit e7471c9d2bbfb8289a6a141adbd6737101db847c Author: Arnd Bergmann Date: Tue Feb 20 21:58:21 2018 +0100 x86/oprofile: Fix bogus GCC-8 warning in nmi_setup() [ Upstream commit 85c615eb52222bc5fab6c7190d146bc59fac289e ] GCC-8 shows a warning for the x86 oprofile code that copies per-CPU data from CPU 0 to all other CPUs, which when building a non-SMP kernel turns into a memcpy() with identical source and destination pointers: arch/x86/oprofile/nmi_int.c: In function 'mux_clone': arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict] memcpy(per_cpu(cpu_msrs, cpu).multiplex, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ per_cpu(cpu_msrs, 0).multiplex, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(struct op_msr) * model->num_virt_counters); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/oprofile/nmi_int.c: In function 'nmi_setup': arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] I have analyzed a number of such warnings now: some are valid and the GCC warning is welcome. Others turned out to be false-positives, and GCC was changed to not warn about those any more. This is a corner case that is a false-positive but the GCC developers feel it's better to keep warning about it. In this case, it seems best to work around it by telling GCC a little more clearly that this code path is never hit with an IS_ENABLED() configuration check. Cc:stable as we also want old kernels to build cleanly with GCC-8. Signed-off-by: Arnd Bergmann Cc: Jessica Yu Cc: Kees Cook Cc: Linus Torvalds Cc: Martin Sebor Cc: Peter Zijlstra Cc: Robert Richter Cc: Thomas Gleixner Cc: oprofile-list@lists.sf.net Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095 Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e71aa849fd7a83b1c1e29f79ecee64255d5184ec Author: Lars-Peter Clausen Date: Wed Feb 14 15:43:00 2018 +0100 iio: adis_lib: Initialize trigger before requesting interrupt [ Upstream commit f027e0b3a774e10302207e91d304bbf99e3a8b36 ] The adis_probe_trigger() creates a new IIO trigger and requests an interrupt associated with the trigger. The interrupt uses the generic iio_trigger_generic_data_rdy_poll() function as its interrupt handler. Currently the driver initializes some fields of the trigger structure after the interrupt has been requested. But an interrupt can fire as soon as it has been requested. This opens up a race condition. iio_trigger_generic_data_rdy_poll() will access the trigger data structure and dereference the ops field. If the ops field is not yet initialized this will result in a NULL pointer deref. It is not expected that the device generates an interrupt at this point, so typically this issue did not surface unless e.g. due to a hardware misconfiguration (wrong interrupt number, wrong polarity, etc.). But some newer devices from the ADIS family start to generate periodic interrupts in their power-on reset configuration and unfortunately the interrupt can not be masked in the device. This makes the race condition much more visible and the following crash has been observed occasionally when booting a system using the ADIS16460. Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c0004000 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257 Hardware name: Xilinx Zynq Platform task: ef04f640 task.stack: ef050000 PC is at iio_trigger_notify_done+0x30/0x68 LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20 pc : [] lr : [] psr: 60000193 sp : ef051bb8 ip : 00000000 fp : ef106400 r10: c081d80a r9 : ef3bfa00 r8 : 00000087 r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00 r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 18c5387d Table: 0000404a DAC: 00000051 Process swapper/0 (pid: 1, stack limit = 0xef050210) [] (iio_trigger_notify_done) from [] (__handle_irq_event_percpu+0x88/0x118) [] (__handle_irq_event_percpu) from [] (handle_irq_event_percpu+0x1c/0x58) [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c) [] (handle_irq_event) from [] (handle_level_irq+0xa4/0x130) [] (handle_level_irq) from [] (generic_handle_irq+0x24/0x34) [] (generic_handle_irq) from [] (zynq_gpio_irqhandler+0xb8/0x13c) [] (zynq_gpio_irqhandler) from [] (generic_handle_irq+0x24/0x34) [] (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4) [] (__handle_domain_irq) from [] (gic_handle_irq+0x48/0x8c) [] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8) To fix this make sure that the trigger is fully initialized before requesting the interrupt. Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library") Reported-by: Robin Getz Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4aac881c7ed52922858c8f550e529b6a6861fcba Author: Stefan Windfeldt-Prytz Date: Thu Feb 15 15:02:53 2018 +0100 iio: buffer: check if a buffer has been set up when poll is called [ Upstream commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 ] If no iio buffer has been set up and poll is called return 0. Without this check there will be a null pointer dereference when calling poll on a iio driver without an iio buffer. Cc: stable@vger.kernel.org Signed-off-by: Stefan Windfeldt-Prytz Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 953eb3c3136bb7f881b50e004a5153c068ef84a7 Author: Arnd Bergmann Date: Fri Feb 2 16:31:23 2018 +0100 cfg80211: fix cfg80211_beacon_dup [ Upstream commit bee92d06157fc39d5d7836a061c7d41289a55797 ] gcc-8 warns about some obviously incorrect code: net/mac80211/cfg.c: In function 'cfg80211_beacon_dup': net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] From the context, I conclude that we want to copy from beacon into new_beacon, as we do in the rest of the function. Cc: stable@vger.kernel.org Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks") Signed-off-by: Arnd Bergmann Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7be3c8ec39ae679b764c7ab700e86402a6c2fa77 Author: Tyrel Datwyler Date: Tue Jan 23 20:11:32 2018 -0600 scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info [ Upstream commit c39813652700f3df552b6557530f1e5f782dbe2f ] The fcp_rsp_info structure as defined in the FC spec has an initial 3 bytes reserved field. The ibmvfc driver mistakenly defined this field as 4 bytes resulting in the rsp_code field being defined in what should be the start of the second reserved field and thus always being reported as zero by the driver. Ideally, we should wire ibmvfc up with libfc for the sake of code deduplication, and ease of maintaining standardized structures in a single place. However, for now simply fixup the definition in ibmvfc for backporting to distros on older kernels. Wiring up with libfc will be done in a followup patch. Cc: Reported-by: Hannes Reinecke Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 209a86d22f6ad051d0df9e0ed78a90e9b3248f31 Author: Johan Hovold Date: Fri Nov 17 14:38:31 2017 +0100 PCI: keystone: Fix interrupt-controller-node lookup [ Upstream commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 ] Fix child-node lookup during initialisation which was using the wrong OF-helper and ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent pci node could end up being prematurely freed as of_find_node_by_name() drops a reference to its first argument. Any matching child interrupt-controller node was also leaked. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Cc: stable # 3.18 Acked-by: Murali Karicheri Signed-off-by: Johan Hovold [lorenzo.pieralisi@arm.com: updated commit subject] Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit d079cd7954004b086aceb82c3656048fba9c4ab1 Author: Paolo Abeni Date: Thu Feb 8 12:19:00 2018 +0100 netfilter: drop outermost socket lock in getsockopt() [ Upstream commit 01ea306f2ac2baff98d472da719193e738759d93 ] The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ #301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com Suggested-by: Florian Westphal Signed-off-by: Paolo Abeni Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3c1fb09dd5b1bc5cbcb24b09995641bf3b0eae20 Author: Kamil Konieczny Date: Wed Feb 7 16:52:09 2018 +0100 crypto: s5p-sss - Fix kernel Oops in AES-ECB mode [ Upstream commit c927b080c67e3e97193c81fc1d27f4251bf4e036 ] In AES-ECB mode crypt is done with key only, so any use of IV can cause kernel Oops. Use IV only in AES-CBC and AES-CTR. Signed-off-by: Kamil Konieczny Reported-by: Anand Moon Reviewed-by: Krzysztof Kozlowski Tested-by: Anand Moon Cc: stable@vger.kernel.org # can be applied after commit 8f9702aad138 Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 25442742157ce5fa98d4c17069b391e0351e2e39 Author: David Hildenbrand Date: Fri Feb 23 11:42:15 2018 +0100 KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail [ Upstream commit 6342c50ad12e8ce0736e722184a7dbdea4a3477f ] vmx_complete_nested_posted_interrupt() can't fail, let's turn it into a void function. Signed-off-by: David Hildenbrand Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 604368d421314a4dd93056cbe032a4eff55b657a Author: David Hildenbrand Date: Fri Feb 23 11:42:14 2018 +0100 KVM: nVMX: kmap() can't fail [ Upstream commit 42cf014d38d8822cce63703a467e00f65d000952 ] kmap() can't fail, therefore it will always return a valid pointer. Let's just get rid of the unnecessary checks. Signed-off-by: David Hildenbrand Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 686f71029ec23c50e030d6c5c9ea838d3a4e83ce Author: David Woodhouse Date: Fri Feb 23 11:42:11 2018 +0100 x86/retpoline: Avoid retpolines for built-in __init functions [ Upstream commit 66f793099a636862a71c59d4a6ba91387b155e0c ] There's no point in building init code with retpolines, since it runs before any potentially hostile userspace does. And before the retpoline is actually ALTERNATIVEd into place, for much of it. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Cc: karahmed@amazon.de Cc: peterz@infradead.org Cc: bp@alien8.de Link: https://lkml.kernel.org/r/1517484441-1420-2-git-send-email-dwmw@amazon.co.uk Signed-off-by: Sasha Levin commit 980fe40629da6ca345e734236e3ed1ab8b639ec4 Author: Dan Williams Date: Fri Feb 23 11:42:10 2018 +0100 x86/kvm: Update spectre-v1 mitigation [ Upstream commit 085331dfc6bbe3501fb936e657331ca943827600 ] Commit 75f139aaf896 "KVM: x86: Add memory barrier on vmcs field lookup" added a raw 'asm("lfence");' to prevent a bounds check bypass of 'vmcs_field_to_offset_table'. The lfence can be avoided in this path by using the array_index_nospec() helper designed for these types of fixes. Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Acked-by: Paolo Bonzini Cc: Andrew Honig Cc: kvm@vger.kernel.org Cc: Jim Mattson Link: https://lkml.kernel.org/r/151744959670.6342.3001723920950249067.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit 8b9694307e13a50d30504ab65afaaa9db4a64937 Author: Josh Poimboeuf Date: Fri Feb 23 11:42:09 2018 +0100 x86/paravirt: Remove 'noreplace-paravirt' cmdline option [ Upstream commit 12c69f1e94c89d40696e83804dd2f0965b5250cd ] The 'noreplace-paravirt' option disables paravirt patching, leaving the original pv indirect calls in place. That's highly incompatible with retpolines, unless we want to uglify paravirt even further and convert the paravirt calls to retpolines. As far as I can tell, the option doesn't seem to be useful for much other than introducing surprising corner cases and making the kernel vulnerable to Spectre v2. It was probably a debug option from the early paravirt days. So just remove it. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Reviewed-by: Juergen Gross Cc: Andrea Arcangeli Cc: Peter Zijlstra Cc: Andi Kleen Cc: Ashok Raj Cc: Greg KH Cc: Jun Nakajima Cc: Tim Chen Cc: Rusty Russell Cc: Dave Hansen Cc: Asit Mallick Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Jason Baron Cc: Paolo Bonzini Cc: Alok Kataria Cc: Arjan Van De Ven Cc: David Woodhouse Cc: Dan Williams Link: https://lkml.kernel.org/r/20180131041333.2x6blhxirc2kclrq@treble Signed-off-by: Sasha Levin commit 8b3c7144b1aac60ac60e3aa96c3d56693e16441e Author: Dan Williams Date: Fri Feb 23 11:42:06 2018 +0100 nl80211: Sanitize array index in parse_txq_params [ Upstream commit 259d8c1e984318497c84eef547bbb6b1d9f4eb05 ] Wireless drivers rely on parse_txq_params to validate that txq_params->ac is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx() handler is called. Use a new helper, array_index_nospec(), to sanitize txq_params->ac with respect to speculation. I.e. ensure that any speculation into ->conf_tx() handlers is done with a value of txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Reported-by: Christian Lamparter Reported-by: Elena Reshetova Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Acked-by: Johannes Berg Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: linux-wireless@vger.kernel.org Cc: torvalds@linux-foundation.org Cc: "David S. Miller" Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit fe6154c8db75495ebe81dbc62f4f49d829988c2d Author: Dan Williams Date: Fri Feb 23 11:42:05 2018 +0100 vfs, fdtable: Prevent bounds-check bypass via speculative execution [ Upstream commit 56c30ba7b348b90484969054d561f711ba196507 ] 'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid 'file *' returned from __fcheck_files. Co-developed-by: Elena Reshetova Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: Al Viro Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727418500.33451.17392199002892248656.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit ede858e6a42be9066d2e73f9be1fc714fda9decc Author: Dan Williams Date: Fri Feb 23 11:42:03 2018 +0100 x86/get_user: Use pointer masking to limit speculation [ Upstream commit c7f631cb07e7da06ac1d231ca178452339e32a94 ] Quoting Linus: I do think that it would be a good idea to very expressly document the fact that it's not that the user access itself is unsafe. I do agree that things like "get_user()" want to be protected, but not because of any direct bugs or problems with get_user() and friends, but simply because get_user() is an excellent source of a pointer that is obviously controlled from a potentially attacking user space. So it's a prime candidate for then finding _subsequent_ accesses that can then be used to perturb the cache. Unlike the __get_user() case get_user() includes the address limit check near the pointer de-reference. With that locality the speculation can be mitigated with pointer narrowing rather than a barrier, i.e. array_index_nospec(). Where the narrowing is performed by: cmp %limit, %ptr sbb %mask, %mask and %mask, %ptr With respect to speculation the value of %ptr is either less than %limit or NULL. Co-developed-by: Linus Torvalds Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Cc: linux-arch@vger.kernel.org Cc: Kees Cook Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: Al Viro Cc: Andy Lutomirski Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727417469.33451.11804043010080838495.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit b7b25a5b2fce2622882e6ff69cf98709b99ad673 Author: Dan Williams Date: Fri Feb 23 11:42:01 2018 +0100 x86: Implement array_index_mask_nospec [ Upstream commit babdde2698d482b6c0de1eab4f697cf5856c5859 ] array_index_nospec() uses a mask to sanitize user controllable array indexes, i.e. generate a 0 mask if 'index' >= 'size', and a ~0 mask otherwise. While the default array_index_mask_nospec() handles the carry-bit from the (index - size) result in software. The x86 array_index_mask_nospec() does the same, but the carry-bit is handled in the processor CF flag without conditional instructions in the control flow. Suggested-by: Linus Torvalds Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727414808.33451.1873237130672785331.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit 442a11fcf4dabb8cc754dd46103c6ddc77f81aa5 Author: Dan Williams Date: Fri Feb 23 11:42:00 2018 +0100 array_index_nospec: Sanitize speculative array de-references [ Upstream commit f3804203306e098dae9ca51540fcd5eb700d7f40 ] array_index_nospec() is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks via speculative execution. The array_index_nospec() implementation is expected to be safe for current generation CPUs across multiple architectures (ARM, x86). Based on an original implementation by Linus Torvalds, tweaked to remove speculative flows by Alexei Starovoitov, and tweaked again by Linus to introduce an x86 assembly implementation for the mask generation. Co-developed-by: Linus Torvalds Co-developed-by: Alexei Starovoitov Suggested-by: Cyril Novikov Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: Peter Zijlstra Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Cc: gregkh@linuxfoundation.org Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727414229.33451.18411580953862676575.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit 7b2e383fd418285dfbacc6213682aff59fd3ddea Author: Mark Rutland Date: Fri Feb 23 11:41:59 2018 +0100 Documentation: Document array_index_nospec [ Upstream commit f84a56f73dddaeac1dba8045b007f742f61cd2da ] Document the rationale and usage of the new array_index_nospec() helper. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Reviewed-by: Kees Cook Cc: linux-arch@vger.kernel.org Cc: Jonathan Corbet Cc: Peter Zijlstra Cc: gregkh@linuxfoundation.org Cc: kernel-hardening@lists.openwall.com Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727413645.33451.15878817161436755393.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Sasha Levin commit d19d78f10ded8d012d7d29d1098529f639a2c9a2 Author: Wanpeng Li Date: Thu Sep 14 03:54:16 2017 -0700 KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously [ Upstream commit 9a6e7c39810e4a8bc7fc95056cefb40583fe07ef ] qemu-system-x86-8600 [004] d..1 7205.687530: kvm_entry: vcpu 2 qemu-system-x86-8600 [004] .... 7205.687532: kvm_exit: reason EXCEPTION_NMI rip 0xffffffffa921297d info ffffeb2c0e44e018 80000b0e qemu-system-x86-8600 [004] .... 7205.687532: kvm_page_fault: address ffffeb2c0e44e018 error_code 0 qemu-system-x86-8600 [004] .... 7205.687620: kvm_try_async_get_page: gva = 0xffffeb2c0e44e018, gfn = 0x427e4e qemu-system-x86-8600 [004] .N.. 7205.687628: kvm_async_pf_not_present: token 0x8b002 gva 0xffffeb2c0e44e018 kworker/4:2-7814 [004] .... 7205.687655: kvm_async_pf_completed: gva 0xffffeb2c0e44e018 address 0x7fcc30c4e000 qemu-system-x86-8600 [004] .... 7205.687703: kvm_async_pf_ready: token 0x8b002 gva 0xffffeb2c0e44e018 qemu-system-x86-8600 [004] d..1 7205.687711: kvm_entry: vcpu 2 After running some memory intensive workload in guest, I catch the kworker which completes the GUP too quickly, and queues an "Page Ready" #PF exception after the "Page not Present" exception before the next vmentry as the above trace which will result in #DF injected to guest. This patch fixes it by clearing the queue for "Page not Present" if "Page Ready" occurs before the next vmentry since the GUP has already got the required page and shadow page table has already been fixed by "Page Ready" handler. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li Fixes: 7c90705bf2a3 ("KVM: Inject asynchronous page fault into a PV guest if page is swapped out.") [Changed indentation and added clearing of injected. - Radim] Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit cbb0f47d36dccbe4b0929cfb3cd750209abc801f Author: Sudip Mukherjee Date: Tue Feb 20 12:55:08 2018 +0100 drm/gma500: remove helper function [ Upstream commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 ] We were getting build warning about: drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:2: warning: initialization from incompatible pointer type The callback to dpms was pointing to a helper function which had a return type of void, whereas the callback should point to a function which has a return type of int. On closer look it turned out that we do not need the helper function since if we call drm_helper_connector_dpms() directly, the first check that drm_helper_connector_dpms() does is: if (mode == connector->dpms) Signed-off-by: Sudip Mukherjee Link: http://patchwork.freedesktop.org/patch/msgid/1454393155-13142-1-git-send-email-sudipm.mukherjee@gmail.com Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 8bd0b0c4df4443cc82f982aa8c1de0684515a2b6 Author: Andy Lutomirski Date: Tue Feb 20 12:55:00 2018 +0100 dell-wmi, dell-laptop: depends DMI [ Upstream commit a570af4850043260b87fb1b8aa27a4484e648878 ] dell-wmi and dell-laptop will compile but won't work right if DMI isn't selected. Signed-off-by: Andy Lutomirski Acked-by: Pali Rohár [arnd: Use depends instead of selects to avoid recursive dependencies] Signed-off-by: Arnd Bergmann Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit ae787fcd0bc83e019801ebe03cf4d50042b890b0 Author: Arnd Bergmann Date: Tue Feb 20 12:54:58 2018 +0100 netlink: fix nla_put_{u8,u16,u32} for KASAN [ Upstream commit b4391db42308c9940944b5d7be5ca4b78fb88dd0 ] When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large stack frames in some functions. This goes unnoticed normally because CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y"). The kernelci.org build bot however has the warning enabled and that led me to investigate it a little further, as every build produces these warnings: net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] Most of this problem is now solved in gcc-8, which can consolidate the stack slots for the inline function arguments. On older compilers we can add a workaround by declaring a local variable in each function to pass the inline function argument. Cc: stable@vger.kernel.org Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c6aac26c0c140f7a9356e519adb642f5a5e2bc5 Author: Miklos Szeredi Date: Tue Sep 27 11:03:57 2016 +0200 ncpfs: fix unused variable warning [ Upstream commit 9a232de4999666b2e8ea6775b2b0e3e4feb09b7a ] Without CONFIG_NCPFS_NLS the following warning is seen: fs/ncpfs/dir.c: In function 'ncp_hash_dentry': fs/ncpfs/dir.c:136:23: warning: unused variable 'sb' [-Wunused-variable] struct super_block *sb = dentry->d_sb; Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 73cbc7b9373fe079839b9dad223d6240d9e15305 Author: Arnd Bergmann Date: Fri Feb 17 16:13:44 2017 +0100 gpio: xgene: mark PM functions as __maybe_unused [ Upstream commit b115bebc07f282067eccc06fd5aa3060ab1426da ] When CONFIG_PM_SLEEP is disabled, we get a warning about unused functions: drivers/gpio/gpio-xgene.c:155:12: warning: 'xgene_gpio_resume' defined but not used [-Wunused-function] static int xgene_gpio_resume(struct device *dev) ^~~~~~~~~~~~~~~~~ drivers/gpio/gpio-xgene.c:142:12: warning: 'xgene_gpio_suspend' defined but not used [-Wunused-function] static int xgene_gpio_suspend(struct device *dev) The warnings are harmless and can be avoided by simplifying the code and marking the functions as __maybe_unused. Signed-off-by: Arnd Bergmann Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 20505289ffbc6717f697dc01e980577100efa11f Author: Arnd Bergmann Date: Fri Jan 29 12:39:11 2016 +0100 net: hp100: remove unnecessary #ifdefs [ Upstream commit 747a11279a442b913a57bf38934879babab3b58b ] Building the hp100 ethernet driver causes warnings when both the PCI and EISA drivers are disabled: ethernet/hp/hp100.c: In function 'hp100_module_init': ethernet/hp/hp100.c:3047:2: warning: label 'out3' defined but not used [-Wunused-label] ethernet/hp/hp100.c: At top level: ethernet/hp/hp100.c:2828:13: warning: 'cleanup_dev' defined but not used [-Wunused-function] We can easily avoid the warnings and make the driver look slightly nicer by removing the #ifdefs that check for the CONFIG_PCI and CONFIG_EISA, as all the registration functions are designed to have no effect when the buses are disabled. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0052b1d7ab8f0438347b3ada2f09ff1a8282b5b7 Author: Arnd Bergmann Date: Wed Jul 19 14:52:59 2017 +0200 perf/x86: Shut up false-positive -Wmaybe-uninitialized warning [ Upstream commit 11d8b05855f3749bcb6c57e2c4052921b9605c77 ] The intialization function checks for various failure scenarios, but unfortunately the compiler gets a little confused about the possible combinations, leading to a false-positive build warning when -Wmaybe-uninitialized is set: arch/x86/events/core.c: In function ‘init_hw_perf_events’: arch/x86/events/core.c:264:3: warning: ‘reg_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized] arch/x86/events/core.c:264:3: warning: ‘val_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized] pr_err(FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x is %Lx)\n", We can't actually run into this case, so this shuts up the warning by initializing the variables to a known-invalid state. Suggested-by: Peter Zijlstra Signed-off-by: Arnd Bergmann Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20170719125310.2487451-2-arnd@arndb.de Link: https://patchwork.kernel.org/patch/9392595/ Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit bc9dcdf2b3dfbfb9467854ca8954b79a5b06e51f Author: Arnd Bergmann Date: Tue Oct 25 22:21:04 2016 +0200 cw1200: fix bogus maybe-uninitialized warning [ Upstream commit 7fc1503c906f0fac62d3506a6e993e49fb996248 ] On x86, the cw1200 driver produces a rather silly warning about the possible use of the 'ret' variable without an initialization presumably after being confused by the architecture specific definition of WARN_ON: drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’: drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] We have already checked that 'count' is larger than 0 here, so we know that 'ret' is initialized. Changing the 'for' loop into do/while also makes this clear to the compiler. Suggested-by: David Laight Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 26e8a3ccd7dfc800585141059f4913e0976f2101 Author: Arnd Bergmann Date: Tue Jan 26 19:46:02 2016 -0200 [media] v4l: remove MEDIA_TUNER dependency for VIDEO_TUNER [ Upstream commit 7c8fe516bd81d991feb73ccd969ec29850af3013 ] em28xx selects VIDEO_TUNER, which has a dependency on MEDIA_TUNER, so we get a Kconfig warning if that is disabled: warning: (VIDEO_PVRUSB2 && VIDEO_USBVISION && VIDEO_GO7007 && VIDEO_AU0828_V4L2 && VIDEO_CX231XX && VIDEO_TM6000 && VIDEO_EM28XX && VIDEO_IVTV && VIDEO_MXB && VIDEO_CX18 && VIDEO_CX23885 && VIDEO_CX88 && VIDEO_BT848 && VIDEO_SAA7134 && VIDEO_SAA7164) selects VIDEO_TUNER which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_TUNER) VIDEO_TUNER does not actually depend on MEDIA_TUNER, and the dependency does nothing except cause the above warning, so let's remove it. Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8966f8532c3dbbc0d29aa1008e142e0889ca8241 Author: Arnd Bergmann Date: Tue Jan 26 12:09:56 2016 -0200 [media] hdpvr: hide unused variable [ Upstream commit b97baa3e22e18dac42001e665cf27ad1211bf878 ] The i2c client pointer is only used when CONFIG_I2C is set, and otherwise produces a compile-time warning: drivers/media/usb/hdpvr/hdpvr-core.c: In function 'hdpvr_probe': drivers/media/usb/hdpvr/hdpvr-core.c:276:21: error: unused variable 'client' [-Werror=unused-variable] This uses the same #ifdef to hide the variable when the code using it is hidden. Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 398b3fc0b14094e415dd348494c5eff2adb6d849 Author: Thierry Reding Date: Tue Dec 15 12:20:49 2015 +0100 drm/gma500: Sanity-check pipe index [ Upstream commit 4f250706211cdb949f7580d4fe4dd1fd646de693 ] If the DSI output isn't connected, then mdfld_dsi_encoder_get_pipe() will return -1. The mdfld_dsi_dp_mode_set() function doesn't properly check for this condition and causes the following compiler warnings: CC drivers/gpu/drm/gma500/mdfld_dsi_dpi.o drivers/gpu/drm/gma500/mdfld_dsi_dpi.c: In function ‘mdfld_dsi_dpi_mode_set’: drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:828:35: warning: array subscript is below array bounds [-Warray-bounds] u32 pipeconf = dev_priv->pipeconf[pipe]; ^ drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:829:33: warning: array subscript is below array bounds [-Warray-bounds] u32 dspcntr = dev_priv->dspcntr[pipe]; ^ Fix this by checking for a valid pipe before indexing the pipeconf and dspcntr arrays. Cc: Patrik Jakobsson Reviewed-by: Patrik Jakobsson Signed-off-by: Thierry Reding Signed-off-by: Boris Brezillon Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-2-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 3053e5f664908485d45f51100ec9e007fae535ad Author: Arnd Bergmann Date: Wed Jan 25 23:15:53 2017 +0100 ISDN: eicon: reduce stack size of sig_ind function [ Upstream commit 27d807180ae0a9e50d90adf9b22573c21be904c2 ] I noticed that this function uses a lot of kernel stack when the "latent entropy" plugin is enabled: drivers/isdn/hardware/eicon/message.c: In function 'sig_ind': drivers/isdn/hardware/eicon/message.c:6113:1: error: the frame size of 1168 bytes is larger than 1152 bytes [-Werror=frame-larger-than=] We currently don't warn about this, as we raise the warning limit to 2048 bytes in mainline, but I'd like to lower that limit again in the future, and this function can easily be changed to be more efficient and avoid that warning, by making some of its local variables 'const'. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b2e73bdc4f73040e10055a02286abdaa4b237996 Author: Arnd Bergmann Date: Tue Jan 26 12:09:59 2016 -0200 [media] em28xx: only use mt9v011 if camera support is enabled [ Upstream commit 190b23b4eb997767afad186bd8c96badceabf39e ] In randconfig builds that select VIDEO_EM28XX_V4L2 and MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get a Kconfig warning: warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT) This avoids the warning by making that 'select' conditional on MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as 'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to have any real dependency on that itself. Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ac6049371519965ca166d0703bed858dcebc9fea Author: Arnd Bergmann Date: Tue Jan 26 12:10:01 2016 -0200 [media] go7007: add MEDIA_CAMERA_SUPPORT dependency [ Upstream commit fa6317eedd6341f2144ed1097706d8c34f18b6e4 ] If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT, so we get a Kconfig warning if that is disabled: warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT) This adds another dependency so we don't accidentally select it when it is unavailable. Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 017d85347f4f0b6f2fc25cab5fbbcc3604be366a Author: Arnd Bergmann Date: Wed Oct 26 15:55:02 2016 -0700 Input: tca8418_keypad - hide gcc-4.9 -Wmaybe-uninitialized warning [ Upstream commit ea4348c8462a20e8b1b6455a7145d2b86f8a49b6 ] Older versions of gcc warn about the tca8418_irq_handler function as they can't keep track of the variable assignment inside of the loop when using the -Wmaybe-unintialized flag: drivers/input/keyboard/tca8418_keypad.c: In function ‘tca8418_irq_handler’: drivers/input/keyboard/tca8418_keypad.c:172:9: error: ‘reg’ may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/input/keyboard/tca8418_keypad.c:165:5: note: ‘reg’ was declared here This is fixed in gcc-6, but it's possible to rearrange the code in a way that avoids the warning on older compilers as well. Signed-off-by: Arnd Bergmann Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 21633c4d20dab18549e5763bc86466cf1083b293 Author: Arnd Bergmann Date: Mon Oct 24 17:30:38 2016 +0200 drm/nouveau: hide gcc-4.9 -Wmaybe-uninitialized [ Upstream commit b74c0a9969f25217a5e5bbcac56a11bee16718d3 ] gcc-4.9 notices that the validate_init() function returns unintialized data when called with a zero 'nr_buffers' argument, when called with the -Wmaybe-uninitialized flag: drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’: drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] However, the only caller of this function always passes a nonzero argument, and gcc-6 is clever enough to take this into account and not warn about it any more. Adding an explicit initialization to -EINVAL here is correct even if the caller changed, and it avoids the warning on gcc-4.9 as well. Signed-off-by: Arnd Bergmann Reviewed-By: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 27a77d9d7a0f3dad998d6e7a2d5fd3fea3ace685 Author: Luis R. Rodriguez Date: Tue Jun 7 16:52:27 2016 -0700 i2c: remove __init from i2c_register_board_info() [ Upstream commit 5abe9b26847c65a698f38744a52635b287514294 ] As of next-20160607 with allyesconfig we get this linker failure: MODPOST vmlinux.o WARNING: vmlinux.o(.text+0x21bc0d): Section mismatch in reference from the function intel_scu_devices_create() to the function .init.text:i2c_register_board_info() This is caused by the fact that intel_scu_devices_create() calls i2c_register_board_info() and intel_scu_devices_create() is not annotated with __init. This typically involves manual code inspection and if one is certain this is correct we would just peg intel_scu_devices_create() with a __ref annotation. In this case this would be wrong though as the intel_scu_devices_create() call is exported, and used in the ipc_probe() on drivers/platform/x86/intel_scu_ipc.c. The issue is that even though builtin_pci_driver(ipc_driver) is used this just exposes the probe routine, which can occur at any point in time if this bus supports hotplug. A race can happen between kernel_init_freeable() that calls the init calls (in this case registeres the intel_scu_ipc.c driver, and later free_initmem(), which would free the i2c_register_board_info(). If a probe happens later in boot i2c_register_board_info() would not be present and we should get a page fault. Signed-off-by: Luis R. Rodriguez [wsa: made function declaration a one-liner] Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 4d2a6cf2dabd041526eaf46fe3c4f1224711a791 Author: Colin Ian King Date: Fri Jan 22 17:49:22 2016 +0000 iio: adc: axp288: remove redundant duplicate const on axp288_adc_channels [ Upstream commit 7ca6574a7afb669b0b4b30dd63adeb310e97e250 ] duplicate const can be removed, it is redundant. Found by static analysis using smatch. Signed-off-by: Colin Ian King Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d72bd44dca664ab89e5f572fae348f969bdb1c0e Author: Arnd Bergmann Date: Mon Jan 25 22:54:57 2016 +0100 tty: cyclades: cyz_interrupt is only used for PCI [ Upstream commit 05ead49691d245f67bdd1b30cab5d9af522ac884 ] When CONFIG_PCI is not set, enabling CONFIG_CYZ_INTR has no practical effect other than generating a warning about an unused function: drivers/tty/cyclades.c:1184:20: warning: 'cyz_interrupt' defined but not used [-Wunused-function] static irqreturn_t cyz_interrupt(int irq, void *dev_id) This adds a dependency to avoid that warning. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 265e214fcc55311b8cbc784beb346232be43e7d4 Author: Arnd Bergmann Date: Mon Oct 10 14:41:10 2016 +0200 tlan: avoid unused label with PCI=n [ Upstream commit 1e09c106a44c2b2685a77a1ef27951381c9fcd23 ] While build testing with randconfig on x86, I ran into this warning that appears to have been around forever drivers/net/ethernet/ti/tlan.c: In function ‘tlan_probe1’: drivers/net/ethernet/ti/tlan.c:614:1: error: label ‘err_out’ defined but not used [-Werror=unused-label] This can be trivially avoided by just moving the label into the existing #ifdef. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c47a2de520071c624a8aec463ba8bfdd767e497 Author: Colin Ian King Date: Wed Jan 6 18:02:59 2016 +0000 tc1100-wmi: fix build warning when CONFIG_PM not enabled [ Upstream commit 75d7e7d7a8f4966cb8b1da54a1c74fb2a97ae8fc ] Conditionally declare suspend_data on CONFIG_PM to avoid the following warning when CONFIG_OM is not enabled: drivers/platform/x86/tc1100-wmi.c:55:27: warning: 'suspend_data' defined but not used [-Wunused-variable] Signed-off-by: Colin Ian King Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 33c5e9043ebd61a2b8b063c4f657f5739ef86519 Author: Arnd Bergmann Date: Thu Jan 28 17:39:24 2016 +0100 ipv4: ipconfig: avoid unused ic_proto_used symbol [ Upstream commit 52b79e2bdf92b07b37c805c50811eaf69a33683d ] When CONFIG_PROC_FS, CONFIG_IP_PNP_BOOTP, CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_RARP are all disabled, we get a warning about the ic_proto_used variable being unused: net/ipv4/ipconfig.c:146:12: error: 'ic_proto_used' defined but not used [-Werror=unused-variable] This avoids the warning, by making the definition conditional on whether a dynamic IP configuration protocol is configured. If not, we know that the value is always zero, so we can optimize away the variable and all code that depends on it. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 035c37bc7c06276661f71a0fcb175e7400c71938 Author: Borislav Petkov Date: Sat Nov 26 15:27:06 2016 +0100 x86/platform/olpc: Fix resume handler build warning [ Upstream commit 20ab6677716c7bbdcfd1cdb9aef296a0b3101f73 ] Fix: arch/x86/platform/olpc/olpc-xo15-sci.c:199:12: warning: ‘xo15_sci_resume’ defined but not used [-Wunused-function] static int xo15_sci_resume(struct device *dev) ^ which I see in randconfig builds here. Signed-off-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20161126142706.13602-1-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9cc7eaba8b5cecac7a73a0ff71574d645203dcc7 Author: Arnd Bergmann Date: Wed Feb 17 23:25:11 2016 +0100 USB: cdc_subset: only build when one driver is enabled [ Upstream commit f3bb23764fac042d189129d485d3a9246cb777da ] This avoids a harmless randconfig warning I get when USB_NET_CDC_SUBSET is enabled, but all of the more specific drivers are not: drivers/net/usb/cdc_subset.c:241:2: #warning You need to configure some hardware for this driver The current behavior is clearly intentional, giving a warning when a user picks a configuration that won't do anything good. The only reason for even addressing this is that I'm getting close to eliminating all 'randconfig' warnings on ARM, and this came up a couple of times. My workaround is to not even build the module when none of the configurations are enable. Alternatively we could simply remove the #warning (nothing wrong for compile-testing), turn it into a runtime warning, or change the Kconfig options into a menu to hide CONFIG_USB_NET_CDC_SUBSET. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d287c2eb3ae19086d941145c14c1eb89629d239 Author: Arnd Bergmann Date: Mon Jan 25 16:04:03 2016 +0100 fbdev: s6e8ax0: avoid unused function warnings [ Upstream commit b54729b6cea7d1f46b1ed70cb7065c6bdefaa780 ] The s6e8ax0 suspend/resume functions are hidden inside of an #ifdef when CONFIG_PM is set to avoid unused function warnings, but they call some other functions that nothing else calls, and we get warnings about those: drivers/video/fbdev/exynos/s6e8ax0.c:449:13: error: 's6e8ax0_sleep_in' defined but not used [-Werror=unused-function] drivers/video/fbdev/exynos/s6e8ax0.c:485:13: error: 's6e8ax0_display_off' defined but not used [-Werror=unused-function] This marks the PM functions as __maybe_unused so the compiler can silently drop them when they are not referenced. Signed-off-by: Arnd Bergmann Reviewed-by: Krzysztof Kozlowski Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit a9548926a1c22fb59a3682b8a9e9137e5cb2fba1 Author: Arnd Bergmann Date: Mon Nov 23 14:39:33 2015 +0100 mtd: cfi: enforce valid geometry configuration [ Upstream commit f5f92b36fbbb8ac7d70ff5fa39ec2637cce3094c ] MTD allows compile-time configuration of the possible CFI geometry settings that are allowed by the kernel, but that includes a couple of invalid configurations, where no bank width or no interleave setting is allowed. These are then caught with a compile-time warning: include/linux/mtd/cfi.h:76:2: warning: #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work. include/linux/mtd/map.h:145:2: warning: #warning "No CONFIG_MTD_MAP_BANK_WIDTH_xx selected. No NOR chip support can work" This is a bit annoying for randconfig tests, and can be avoided if we change the Kconfig logic to always select the simplest configuration when no other one is enabled. Signed-off-by: Arnd Bergmann Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit e70f93357c0a66f1ab9182605d9b05c09022deaa Author: Arnd Bergmann Date: Tue Dec 8 16:38:12 2015 +0100 mtd: sh_flctl: pass FIFO as physical address [ Upstream commit 1873315fb156cbc8e46f28e8b128f17ff6c31728 ] By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t. The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping. We also get a warning about a type mismatch for the case that dma_addr_t is wider than a pointer, i.e. when CONFIG_LPAE is set: drivers/mtd/nand/sh_flctl.c: In function 'flctl_setup_dma': drivers/mtd/nand/sh_flctl.c:163:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl); This changes the driver to instead pass the physical address of the FIFO that is extracted from the MMIO resource, making the code more portable and avoiding the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit a784dddc3de916fe9c5bb9d18c759e774cd02e09 Author: Borislav Petkov Date: Sat Nov 26 21:53:52 2016 +0100 amd-xgbe: Fix unused suspend handlers build warning [ Upstream commit 91eefaabf102c539e6f5531e9a1e5ed46d2b41ca ] Fix: drivers/net/ethernet/amd/xgbe/xgbe-main.c:835:12: warning: ‘xgbe_suspend’ defined but not used [-Wunused-function] drivers/net/ethernet/amd/xgbe/xgbe-main.c:855:12: warning: ‘xgbe_resume’ defined but not used [-Wunused-function] I see it during randconfig builds here. Signed-off-by: Borislav Petkov Cc: Tom Lendacky Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fbb1026962a43c0a48a25caa1cf6ef5cb560fb52 Author: Arnd Bergmann Date: Fri Nov 20 22:47:41 2015 +0100 fbdev: auo_k190x: avoid unused function warnings [ Upstream commit a8a31afad5ffa1c7de0cef1c4bc383b50f426bf8 ] The auo_k190x framebuffer driver encloses the power-management functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume functions are only really used when CONFIG_PM_SLEEP is also set, as a frequent gcc warning shows: drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used This changes the driver to remove the #ifdef and instead mark the functions as __maybe_unused, which is a nicer anyway, as it provides build testing for all the code in all configurations and is harder to get wrong. Signed-off-by: Arnd Bergmann Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 9d88694528315217dbb0b4fed650f8948634a89b Author: Arnd Bergmann Date: Thu Mar 24 22:19:40 2016 +0100 driver-core: use 'dev' argument in dev_dbg_ratelimited stub [ Upstream commit 1f62ff34a90471d1b735bac2c79e894afc7c59bc ] dev_dbg_ratelimited() is a macro that ignores its first argument when DEBUG is not set, which can lead to unused variable warnings: ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cqe_sdq_handle': ethernet/mellanox/mlxsw/pci.c:646:18: warning: unused variable 'pdev' [-Wunused-variable] ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cqe_rdq_handle': ethernet/mellanox/mlxsw/pci.c:671:18: warning: unused variable 'pdev' [-Wunused-variable] The macro already ensures that all its other arguments are silently ignored by the compiler without triggering a warning, through the use of the no_printk() macro, but the dev argument is not passed into that. This changes the definition to use the same trick as no_printk() with an if(0) that leads the compiler to not evaluate the side-effects but still see that 'dev' might not be unused. Signed-off-by: Arnd Bergmann Suggested-by: Andrew Lunn Fixes: 6f586e663e3b ("driver-core: Shut up dev_dbg_reatelimited() without DEBUG") Reviewed-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b15476ed501ed15d2b0b864b65b04d9a9276118 Author: Arnd Bergmann Date: Mon Feb 1 17:29:45 2016 +0100 target/user: Fix cast from pointer to phys_addr_t [ Upstream commit 0633e123465b61a12a262b742bebf2a9945f7964 ] The uio_mem structure has a member that is a phys_addr_t, but can be a number of other types too. The target core driver attempts to assign a pointer from vmalloc() to it, by casting it to phys_addr_t, but that causes a warning when phys_addr_t is longer than a pointer: drivers/target/target_core_user.c: In function 'tcmu_configure_device': drivers/target/target_core_user.c:906:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] This adds another cast to uintptr_t to shut up the warning. A nicer fix might be to have additional fields in uio_mem for the different purposes, so we can assign a pointer directly. Signed-off-by: Arnd Bergmann Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 316c580c36c6fb5c8394cfffa87fab57c0aee31a Author: Arnd Bergmann Date: Mon Jan 25 22:54:58 2016 +0100 tty: hvc_xen: hide xen_console_remove when unused [ Upstream commit e36ae3439936e13c33f5841c7c2c1a9875acbb6d ] xencons_disconnect_backend() is only called from xen_console_remove(), which is conditionally compiled, so we get a harmless warning when CONFIG_HVC_XEN_FRONTEND is unset: hvc/hvc_xen.c:350:12: error: 'xen_console_remove' defined but not used [-Werror=unused-function] This moves the function down into the same #ifdef section to silence the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 109dc09b90512383893b5d3e61886660b5e762e7 Author: Arnd Bergmann Date: Thu Jan 28 17:23:15 2016 +0100 usb: musb/ux500: remove duplicate check for dma_is_compatible [ Upstream commit 62a6abdd427b5fc4d8aad5dac874904e96273e6d ] When dma_addr_t is 64-bit, we get a warning about an invalid cast in the call to ux500_dma_is_compatible() from ux500_dma_channel_program(): drivers/usb/musb/ux500_dma.c: In function 'ux500_dma_channel_program': drivers/usb/musb/ux500_dma.c:210:51: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] if (!ux500_dma_is_compatible(channel, packet_sz, (void *)dma_addr, len)) The problem is that ux500_dma_is_compatible() is called from the main musb driver on the virtual address, but here we pass in a DMA address, so the types are fundamentally different but it works because the function only checks the alignment of the buffer and that is the same. We could work around this by adding another cast, but I have checked that the buffer we get passed here is already checked before it gets mapped, so the second check seems completely unnecessary and removing it must be the cleanest solution. Signed-off-by: Arnd Bergmann Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9b76f398ddcf6e2ae1291a089d9bf64f42f40cd2 Author: Arnd Bergmann Date: Tue Jan 26 14:17:24 2016 -0200 [media] pwc: hide unused label [ Upstream commit 1f6bcd011464cb36059e2562f72baf75f98b732d ] The pwc driver causes a warning when CONFIG_USB_PWC_INPUT_EVDEV is unset: drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe': drivers/media/usb/pwc/pwc-if.c:1115:1: warning: label 'err_video_unreg' defined but not used [-Wunused-label] This moves the unused label and code inside another #ifdef to get rid of the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 26c322c9849040b8889227a176a831dc5deda039 Author: Arnd Bergmann Date: Thu Nov 19 15:33:41 2015 +0100 SCSI: initio: remove duplicate module device table [ Upstream commit d282e2b383e3f41a7758e8cbf3076091ef9d9447 ] The initio driver has for many years had two copies of the same module device table. One of them is also used for registering the other driver, the other one is entirely useless after the large scale cleanup that Alan Cox did back in 2007. The compiler warns about this whenever the driver is built-in: drivers/scsi/initio.c:131:29: warning: 'i91u_pci_devices' defined but not used [-Wunused-variable] This removes the extraneous table and the warning. Signed-off-by: Arnd Bergmann Fixes: 72d39fea901 ("[SCSI] initio: Convert into a real Linux driver and update to modern style") Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6348e66c89e1fcf59a3d8943a16e2829e38e18ea Author: Arnd Bergmann Date: Wed Mar 2 16:59:00 2016 +0100 scsi: mvumi: use __maybe_unused to hide pm functions [ Upstream commit fddbeb80a904aae41c84ed566e2b0d1de55907df ] The mvumi scsi hides the references to its suspend/resume functions in an #ifdef but does not hide the implementation the same way: drivers/scsi/mvumi.c:2632:12: error: 'mvumi_suspend' defined but not used [-Werror=unused-function] drivers/scsi/mvumi.c:2651:12: error: 'mvumi_resume' defined but not used [-Werror=unused-function] This adds __maybe_unused annotations so the compiler knows it can silently drop them instead of warning, while avoiding the addition of another #ifdef. Signed-off-by: Arnd Bergmann Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 77bff52c2c82d3b6c3ecb8f33b104f29a3edf732 Author: Daniel Wagner Date: Tue Feb 9 10:18:32 2016 +0100 video: Use bool instead int pointer for get_opt_bool() argument [ Upstream commit 206fc20598157ce15597822cf01b94377e30075b ] As the function name already indicates that get_opt_bool() parses for a bool. It is not a surprise that compiler is complaining about it when -Werror=incompatible-pointer-types is used: drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’: drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types] if (get_opt_bool(this_opt, "accel", &accel)) Signed-off-by: Daniel Wagner Reported-by: Fengguang Wu Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 7a712f25f8471e7954fb7598568908ce92a744d9 Author: Arnd Bergmann Date: Fri Nov 27 15:33:11 2015 +0100 fbdev: sis: enforce selection of at least one backend [ Upstream commit 5b833fea4377577eafecb888141a05470922ef25 ] The sis framebuffer driver complains with a compile-time warning if neither the FB_SIS_300 nor FB_SIS_315 symbols are selected: drivers/video/fbdev/sis/sis_main.c:61:2: warning: #warning Neither CONFIG_FB_SIS_300 nor CONFIG_FB_SIS_315 is se This is reasonable because it doesn't work in that case, but it's also annoying for randconfig builds and is one of the most common warnings I'm seeing on ARM now. This changes the Kconfig logic to prevent the silly configuration, by always selecting the FB_SIS_300 variant if the other one is not set. Signed-off-by: Arnd Bergmann Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 966fe0a5175e77802b452bdacb28ab72b74f4a4b Author: Arnd Bergmann Date: Fri Nov 20 22:59:14 2015 +0100 staging: ste_rmi4: avoid unused function warnings [ Upstream commit 9045a4a7e686a6316129d6d0b21b4fe2520968e4 ] The rmi4 touchscreen driver encloses the power-management functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume functions are only really used when CONFIG_PM_SLEEP is also set, as a frequent gcc warning shows: ste_rmi4/synaptics_i2c_rmi4.c:1050:12: warning: 'synaptics_rmi4_suspend' defined but not used ste_rmi4/synaptics_i2c_rmi4.c:1084:12: warning: 'synaptics_rmi4_resume' defined but not used This changes the driver to remove the #ifdef and instead mark the functions as __maybe_unused, which is a nicer anyway, as it provides build testing for all the code in all configurations and is harder to get wrong. Signed-off-by: Arnd Bergmann Acked-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fe18e13367ea53808de8f914ab7326326bf8e403 Author: Sudip Mukherjee Date: Mon Feb 29 23:32:29 2016 +0530 video: fbdev: sis: remove unused variable [ Upstream commit 32ad61951574d011d363694d6037592e99da9421 ] The variables modeflag and resinfo were only assigned some value but were never used. Signed-off-by: Sudip Mukherjee Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 239214b46584cd951fe4fff1b99b951a53ab3af6 Author: Arnd Bergmann Date: Wed Jan 27 16:57:17 2016 +0100 scsi: fdomain: drop fdomain_pci_tbl when built-in [ Upstream commit 120f83f8d6f2e2e7dea3570646722c62ecee70b0 ] The fdomain SCSI host driver is one of the last remaining drivers that manually search the PCI bus using pci_get_device rather than registering a pci_driver instance. This means the module device table is unused when the driver is built-in, and we get a warning about it: drivers/scsi/fdomain.c:1773:29: warning: 'fdomain_pci_tbl' defined but not used [-Wunused-variable] To avoid the warning, this adds another #ifdef around the table definition. Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e88f69a37cfa13c92e3e9e62cb428f270dd11380 Author: Arnd Bergmann Date: Wed Jan 27 16:57:18 2016 +0100 mptfusion: hide unused seq_mpt_print_ioc_summary function [ Upstream commit 28558f5af50d8335cbbc8bc2726e0747553e29f5 ] The seq_mpt_print_ioc_summary function is used for the /proc/mpt/iocN/summary implementation and never gets called when CONFIG_PROC_FS is disabled: drivers/message/fusion/mptbase.c:6851:13: warning: 'seq_mpt_print_ioc_summary' defined but not used [-Wunused-function] static void seq_mpt_print_ioc_summary(MPT_ADAPTER *ioc, struct seq_file *m, int showlan) This adds an #ifdef to hide the function definition in that case and avoid the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 71e7340520f03a393775ad1884a664a6a05fc740 Author: Julia Lawall Date: Tue Apr 19 14:33:33 2016 +0200 mtd: maps: add __init attribute [ Upstream commit e4106a7c8236eb7b91686d36f3bf33ee43db94b4 ] Add __init attribute on functions that are only called from other __init functions and that are not inlined, at least with gcc version 4.8.4 on an x86 machine with allyesconfig. Currently, the functions are put in the .text.unlikely segment. Declaring them as __init will cause them to be put in the .init.text and to disappear after initialization. The result of objdump -x on the functions before the change is as follows: 00000000000001bc l F .text.unlikely 00000000000006a2 ck804xrom_init_one.isra.1 00000000000001aa l F .text.unlikely 0000000000000764 esb2rom_init_one.isra.1 00000000000001db l F .text.unlikely 0000000000000716 ichxrom_init_one.isra.1 And after the change it is as follows: 0000000000000000 l F .init.text 000000000000069d ck804xrom_init_one.isra.1 0000000000000000 l F .init.text 000000000000075f esb2rom_init_one.isra.1 0000000000000000 l F .init.text 0000000000000711 ichxrom_init_one.isra.1 Done with the help of Coccinelle. The semantic patch checks for local static non-init functions that are called from an __init function and are not called from any other function. Note that in each case, the function is stored in the probe field of a pci_driver structure, but this code is under an #if 0. The #if 0s have been unchanged since 2009 at the latest. Signed-off-by: Julia Lawall Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit 5cf0b5600f594aefc7d64631ad7e28bbc73cf800 Author: Arnd Bergmann Date: Mon Oct 24 17:28:35 2016 +0200 mtd: ichxrom: maybe-uninitialized with gcc-4.9 [ Upstream commit e70dda0868fad0f74c46df21f7f45fec24f29879 ] pci_read_config_word() might fail and not initialize its output, as pointed out by older versions of gcc when using the -Wmaybe-unintialized flag: drivers/mtd/maps/ichxrom.c: In function ‘ichxrom_cleanup’: drivers/mtd/maps/ichxrom.c:63:2: error: ‘word’ is used uninitialized in this function [-Werror=uninitialized] This is apparently a correct warning, though it does not show up with newer compilers. Changing the code to not attempt to write back uninitialized data into PCI config space is a correct fix for the problem and avoids the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Marek Vasut Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit b3f049b421a764156135e4ffb7a7ce08c43a279f Author: Arnd Bergmann Date: Mon Dec 21 10:51:01 2015 +1100 md: avoid warning for 32-bit sector_t [ Upstream commit 3312c951efaba55080958974047414576b9e5d63 ] When CONFIG_LBDAF is not set, sector_t is only 32-bits wide, which means we cannot have devices with more than 2TB, and the code that is trying to handle compatibility support for large devices in md version 0.90 is meaningless but also causes a compile-time warning: drivers/md/md.c: In function 'super_90_load': drivers/md/md.c:1029:19: warning: large integer implicitly truncated to unsigned type [-Woverflow] drivers/md/md.c: In function 'super_90_rdev_size_change': drivers/md/md.c:1323:17: warning: large integer implicitly truncated to unsigned type [-Woverflow] This adds a check for CONFIG_LBDAF to avoid even getting into this code path, and also adds an explicit cast to let the compiler know it doesn't have to warn about the truncation. Signed-off-by: Arnd Bergmann Signed-off-by: NeilBrown Signed-off-by: Sasha Levin commit eb4fdd03e6848a66d1a604d176bc627f8e854963 Author: Arnd Bergmann Date: Tue Mar 22 14:27:26 2016 -0700 profile: hide unused functions when !CONFIG_PROC_FS [ Upstream commit ade356b99a4187578609f2a91c4d2ed88e4e70dc ] A couple of functions and variables in the profile implementation are used only on SMP systems by the procfs code, but are unused if either procfs is disabled or in uniprocessor kernels. gcc prints a harmless warning about the unused symbols: kernel/profile.c:243:13: error: 'profile_flip_buffers' defined but not used [-Werror=unused-function] static void profile_flip_buffers(void) ^ kernel/profile.c:266:13: error: 'profile_discard_flip_buffers' defined but not used [-Werror=unused-function] static void profile_discard_flip_buffers(void) ^ kernel/profile.c:330:12: error: 'profile_cpu_callback' defined but not used [-Werror=unused-function] static int profile_cpu_callback(struct notifier_block *info, ^ This adds further #ifdef to the file, to annotate exactly in which cases they are used. I have done several thousand ARM randconfig kernels with this patch applied and no longer get any warnings in this file. Signed-off-by: Arnd Bergmann Cc: Vlastimil Babka Cc: Robin Holt Cc: Johannes Weiner Cc: Christoph Lameter Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ea6f8c9458bbb1e6fef995d850ce3c30960f252d Author: Sudip Mukherjee Date: Thu Feb 18 13:59:13 2016 +0530 dpt_i2o: fix build warning [ Upstream commit f50abb9b63b1d8773e1ce32115701c06416e6f91 ] We were getting build warning about: drivers/scsi/dpt_i2o.c:183:29: warning: 'dptids' defined but not used dptids[] is only used in the MODULE_DEVICE_TABLE so when MODULE is not defined then dptids[] becomes unused. Signed-off-by: Sudip Mukherjee Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fd77d23ad212f6fad87ba1e5ab04f82db1217c03 Author: Fabian Frederick Date: Sat Dec 12 18:24:38 2015 +0100 drivers/net: fix eisa_driver probe section mismatch [ Upstream commit cb4396edd84ed73081635fb933d19c1410fafaf4 ] Some eisa_driver structures used __init probe functions which generates a warning and could crash if function is called after being deleted. Signed-off-by: Fabian Frederick Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0957a4d4b98d1f373c4082dfbb665e14548db62c Author: Sudip Mukherjee Date: Thu Feb 11 10:29:03 2016 +0530 scsi: sim710: fix build warning [ Upstream commit 648a0a7da34f281410e8e3a59de8c13ec6ea380a ] We are getting build warning about: "Section mismatch in reference from the variable sim710_eisa_driver to the function .init.text:sim710_eisa_probe() The variable sim710_eisa_driver references the function __init sim710_eisa_probe()" sim710_eisa_probe() was having __init but that was being referenced from sim710_eisa_driver. Signed-off-by: Sudip Mukherjee Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2fd8e408a152cc2ebf1091df91db3217b6e9eb77 Author: Arnd Bergmann Date: Wed Nov 16 15:17:09 2016 +0100 x86/boot: Avoid warning for zero-filling .bss [ Upstream commit 553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985 ] The latest binutils are warning about a .fill directive with an explicit value in a .bss section: arch/x86/kernel/head_32.S: Assembler messages: arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned' arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned' This comes from the 'ENTRY()' macro padding the space between the symbols with 'nop' via: .align 4,0x90 Open-coding the .globl directive without the padding avoids that warning, as all the symbols are already page aligned. Signed-off-by: Arnd Bergmann Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20161116141726.2013389-1-arnd@arndb.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 3536d699d0325e5087592677347d0ee9ea4e696c Author: Arnd Bergmann Date: Mon Jan 25 17:44:10 2016 +0100 thermal: spear: use __maybe_unused for PM functions [ Upstream commit d612c64d1f4d6b2464993dfeafd9ec319f774188 ] The spear thermal driver hides its suspend/resume function conditionally based on CONFIG_PM, but references them based on CONFIG_PM_SLEEP, so we get a warning if the former is set but the latter is not: thermal/spear_thermal.c:58:12: warning: 'spear_thermal_suspend' defined but not used [-Wunused-function] thermal/spear_thermal.c:75:12: warning: 'spear_thermal_resume' defined but not used [-Wunused-function] This removes the #ifdef and instead uses a __maybe_uninitialized annotation to avoid the warning and improve compile-time coverage. Signed-off-by: Arnd Bergmann Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit c81419613c45dfb869ac29a64f00d35dc7118d31 Author: Arnd Bergmann Date: Thu Mar 23 16:06:13 2017 +0100 reiserfs: avoid a -Wmaybe-uninitialized warning [ Upstream commit ab4949640d6674b617b314ad3c2c00353304bab9 ] The latest gcc-7.0.1 snapshot warns about an unintialized variable use: In file included from fs/reiserfs/lbalance.c:8:0: fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3': fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); ~~^~~ fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); This happens because the offset/type pair that is stored in ih.key.u.k_offset_v2 is actually uninitialized when we call set_le_ih_k_offset() and set_le_ih_k_type(). After we have called both, all data is correct, but the first of the two reads uninitialized data for the type field and writes it back before it gets overwritten. This works around the warning by initializing the k_offset_v2 through the slightly larger memcpy(). [JK: Remove now unused define and make it obvious we initialize the key] Signed-off-by: Arnd Bergmann Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 4974179d68b6d8ce0cb44f87de3506d2d102d724 Author: Arnd Bergmann Date: Wed Jan 11 14:39:44 2017 +0100 ALSA: hda/ca0132 - fix possible NULL pointer use [ Upstream commit 46a049dae771b95e77ac6c823330f4a60f600236 ] gcc-7 caught what it considers a NULL pointer dereference: sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop': sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull] This is plausible from looking at the function, as we compare 'reply' to NULL earlier in it. I have not tried to analyze if there are constraints that make it impossible to hit the bug, but adding another NULL check in the end kills the warning and makes the function more robust. Signed-off-by: Arnd Bergmann Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f6af9f01e564b430d8a5ab4f927b0ccbebd486d7 Author: Arnd Bergmann Date: Thu Mar 23 16:02:18 2017 +0100 scsi: advansys: fix uninitialized data access [ Upstream commit 44a5b977128c0ffff0654392b40f4c2ce72a619b ] gcc-7.0.1 now warns about a previously unnoticed access of uninitialized struct members: drivers/scsi/advansys.c: In function 'AscMsgOutSDTR': drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]); ^ drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code has existed in this exact form at least since v2.6.12, and the warning seems correct. This uses named initializers to ensure we initialize all members of the structure. Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b256bcce6b8bfdde93c4a234ac04218ae2337edf Author: Arnd Bergmann Date: Wed Jul 19 14:53:04 2017 +0200 x86: add MULTIUSER dependency for KVM [ Upstream commit c2ce3f5d89d57301e2756ac325fe2ebc33bfec30 ] KVM tries to select 'TASKSTATS', which had additional dependencies: warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER) Signed-off-by: Arnd Bergmann Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit f288e690e826420393887da840ac1ae51cd2506c Author: Arnd Bergmann Date: Wed Jul 19 14:53:03 2017 +0200 x86/build: Silence the build with "make -s" [ Upstream commit d460131dd50599e0e9405d5f4ae02c27d529a44a ] Every kernel build on x86 will result in some output: Setup is 13084 bytes (padded to 13312 bytes). System is 4833 kB CRC 6d35fa35 Kernel: arch/x86/boot/bzImage is ready (#2) This shuts it up, so that 'make -s' is truely silent as long as everything works. Building without '-s' should produce unchanged output. Signed-off-by: Arnd Bergmann Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20170719125310.2487451-6-arnd@arndb.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 2b3d37552ba22a2431e16f61a913227bf1490ca7 Author: Borislav Petkov Date: Mon Jan 23 19:35:06 2017 +0100 x86/ras/inject: Make it depend on X86_LOCAL_APIC=y [ Upstream commit d4b2ac63b0eae461fc10c9791084be24724ef57a ] ... and get rid of the annoying: arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function] when doing randconfig builds. Signed-off-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tony Luck Cc: Yazen Ghannam Cc: linux-edac Link: http://lkml.kernel.org/r/20170123183514.13356-2-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 38e479ea9ccbbbe42359e31d90568bdbde707dc4 Author: Arnd Bergmann Date: Mon Oct 24 17:51:55 2016 +0200 scsi: advansys: fix build warning for PCI=n [ Upstream commit f46e7cd36b5f2ce2bfb567e278a10ca717f85b84 ] The advansys probe function tries to handle both ISA and PCI cases, each hidden in an #ifdef when unused. This leads to a warning indicating that when PCI is disabled we could be using uninitialized data: drivers/scsi/advansys.c: In function advansys_board_found : drivers/scsi/advansys.c:11036:5: error: ret may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:28: note: ret was declared here drivers/scsi/advansys.c:11309:8: error: share_irq may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:6: note: share_irq was declared here This cannot happen in practice because the hardware in question only exists for PCI, but changing the code to just error out here is better for consistency and avoids the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3d4ba6d00fd75b6825a4467e29acc6734339e4d6 Author: Arnd Bergmann Date: Wed Jun 14 12:40:36 2017 +0200 video: fbdev: via: remove possibly unused variables [ Upstream commit 484c7bbf2649831714da3a0fa30213977458e9b5 ] When CONFIG_PROC_FS is disabled, we get warnings about unused variables as remove_proc_entry() evaluates to an empty macro. drivers/video/fbdev/via/viafbdev.c: In function 'viafb_remove_proc': drivers/video/fbdev/via/viafbdev.c:1635:4: error: unused variable 'iga2_entry' [-Werror=unused-variable] drivers/video/fbdev/via/viafbdev.c:1634:4: error: unused variable 'iga1_entry' [-Werror=unused-variable] These are easy to avoid by using the pointer from the structure. Signed-off-by: Arnd Bergmann Cc: Florian Tobias Schandinat Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 728e0ad0786d27e1858ebb2c82a0881a30ae8bb0 Author: Borislav Petkov Date: Sat Nov 26 17:01:51 2016 +0100 platform/x86: intel_mid_thermal: Fix suspend handlers unused warning [ Upstream commit b4aca383f9afb5f84b05de272656e6d4a919d995 ] Fix: drivers/platform/x86/intel_mid_thermal.c:424:12: warning: ‘mid_thermal_resume’ defined but not used [-Wunused-function] static int mid_thermal_resume(struct device *dev) ^ drivers/platform/x86/intel_mid_thermal.c:436:12: warning: ‘mid_thermal_suspend’ defined but not used [-Wunused-function] static int mid_thermal_suspend(struct device *dev) ^ which I see during randbuilds here. Signed-off-by: Borislav Petkov Cc: Darren Hart Cc: platform-driver-x86@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 9762db252c13026d2b534a41d596b8017211c129 Author: Augusto Mecking Caringi Date: Mon Jan 16 14:30:41 2017 +0000 gpio: intel-mid: Fix build warning when !CONFIG_PM [ Upstream commit fbc2a294f29e726787a0f5238b27137904f26b81 ] The only usage of function intel_gpio_runtime_idle() is here (in the same file): static const struct dev_pm_ops intel_gpio_pm_ops = { SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle) }; And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to nothing, causing the following compiler warning: drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’ defined but not used [-Wunused-function] static int intel_gpio_runtime_idle(struct device *dev) Fix it by annotating the function with __maybe_unused. Signed-off-by: Augusto Mecking Caringi Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit dbe3c61245bdf755c644a49111a8924c6c207a82 Author: Arnd Bergmann Date: Fri Feb 17 16:08:30 2017 +0100 vmxnet3: prevent building with 64K pages [ Upstream commit fbdf0e28d061708cf18ba0f8e0db5360dc9a15b9 ] I got a warning about broken code on ARM64 with 64K pages: drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_rq_init': drivers/net/vmxnet3/vmxnet3_drv.c:1679:29: error: large integer implicitly truncated to unsigned type [-Werror=overflow] rq->buf_info[0][i].len = PAGE_SIZE; 'len' here is a 16-bit integer, so this clearly won't work. I don't think this driver is used much on anything other than x86, so there is no need to fix this properly and we can work around it with a Kconfig dependency to forbid known-broken configurations. qemu in theory supports it on other architectures too, but presumably only for compatibility with x86 guests that also run on vmware. CONFIG_PAGE_SIZE_64KB is used on hexagon, mips, sh and tile, the other symbols are architecture-specific names for the same thing. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 63408ea91c2c84ad42cb0ef3ff35280ebef31d0d Author: Arnd Bergmann Date: Wed Mar 2 20:06:45 2016 +0100 isdn: icn: remove a #warning [ Upstream commit 01ed1e1504ac83a8b0b365c9f55d3427babbd7d9 ] The icn driver currently produces an unconditional #warning whenever we build it, introduced by Karsten Keil back in 2003: #warning TODO test headroom or use skb->nb to flag ACK Karsten's original commit (from BitKeeper) contains this description: - here are lot of bugs left, so ISDN is not stable yet but I think it's really time to fix it, even if it need some cycles to get it right (normally I'm only send patches if it works 100% for me). - I add some additional #warnings to address places which need fixing (I hope that some of the other ISDN developer jump in) Apparently this has not happened, and it is unlikely that it ever will, given that the driver doesn't seem to work. No substantial bug fixes other than janitorial cleanups have happened in the driver since then, and I see no indication that anyone who patched it had the hardware. We should probably either remove the driver, or remove all of i4l, but for now, this shuts up the distracting #warning by turning it into a comment. Signed-off-by: Arnd Bergmann Link: http://git.meleeweb.net/linux.git/commit/?id=b0deac0886b0056765afd149e9834373b38e096b Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1a500b3156502d98df3fd75f34a8e00d2471cba6 Author: Arnd Bergmann Date: Tue Mar 28 18:46:59 2017 +0200 virtio_balloon: prevent uninitialized variable use [ Upstream commit f0bb2d50dfcc519f06f901aac88502be6ff1df2c ] The latest gcc-7.0.1 snapshot reports a new warning: virtio/virtio_balloon.c: In function 'update_balloon_stats': virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in this function [-Werror=uninitialized] This seems absolutely right, so we should add an extra check to prevent copying uninitialized stack data into the statistics. >From all I can tell, this has been broken since the statistics code was originally added in 2.6.34. Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)") Signed-off-by: Arnd Bergmann Signed-off-by: Ladi Prosek Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit e23daf3ee076379ca01d2a5756ace3b39f24bd6e Author: Jia-Ju Bai Date: Tue Dec 12 16:49:52 2017 +0800 hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close [ Upstream commit 6e266610eb6553cfb7e7eb5d11914bd01509c406 ] The driver may sleep under a spinlock. The function call path is: rr_close (acquire the spinlock) free_irq --> may sleep To fix it, free_irq is moved to the place without holding the spinlock. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a089e6cab4b1e5ce15f940c7a008bfde5f408129 Author: Jan Beulich Date: Tue Dec 12 03:18:11 2017 -0700 xen: XEN_ACPI_PROCESSOR is Dom0-only [ Upstream commit c4f9d9cb2c29ff04c6b4bb09b72802d8aedfc7cb ] Add a respective dependency. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 2a6d40fa2fd3b8c06701f34b422ce64620e2c6d7 Author: Karol Herbst Date: Mon Nov 27 08:51:39 2017 +0100 x86/mm/kmmio: Fix mmiotrace for page unaligned addresses [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to unregister_kmmio_probe() was PAGE_SIZE aligned by the caller leading to a complete freeze of the machine. We should always page align addresses while (un)registerung mappings, because the mmiotracer works on top of pages, not mappings. We still keep track of the probes based on their real addresses and lengths though, because the mmiotrace still needs to know what are mapped memory regions. Also move the call to mmiotrace_iounmap() prior page aligning the address, so that all probes are unregistered properly, otherwise the kernel ends up failing memory allocations randomly after disabling the mmiotracer. Tested-by: Lyude Signed-off-by: Karol Herbst Acked-by: Pekka Paalanen Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Cc: nouveau@lists.freedesktop.org Link: http://lkml.kernel.org/r/20171127075139.4928-1-kherbst@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 806a1beaf513fed3e7cd083f915f19e54077db50 Author: Dave Young Date: Sat Dec 9 12:16:10 2017 +0800 mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep [ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ] earlyprintk=efi,keep does not work any more with a warning in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING): Boot just hangs because of the earlyprintk within the earlyprintk implementation code itself. This is caused by a new introduced middle state in: 69a78ff226fe ("init: Introduce SYSTEM_SCHEDULING state") early_ioremap() is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING states, original condition should be updated accordingly. Signed-off-by: Dave Young Acked-by: Thomas Gleixner Cc: Linus Torvalds Cc: Peter Zijlstra Cc: bp@suse.de Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20171209041610.GA3249@dhcp-128-65.nay.redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 01bd5ae7750e81f8ffcce39c1ef56cf00ab5d831 Author: Tobias Jordan Date: Wed Dec 6 14:28:27 2017 +0100 dmaengine: jz4740: disable/unprepare clk if probe fails [ Upstream commit eb9436966fdc84cebdf222952a99898ab46d9bb0 ] in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean up. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 25ce6c35fea0 MIPS: jz4740: Remove custom DMA API Signed-off-by: Tobias Jordan Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 33acb6cec6d88a7712a8ee8e7d2fd3093b9fddc7 Author: Steffen Klassert Date: Fri Dec 8 08:07:25 2017 +0100 xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies. [ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ] On policies with a transport mode template, we pass the addresses from the flowi to xfrm_state_find(), assuming that the IP addresses (and address family) don't change during transformation. Unfortunately our policy template validation is not strict enough. It is possible to configure policies with transport mode template where the address family of the template does not match the selectors address family. This lead to stack-out-of-bound reads because we compare arddesses of the wrong family. Fix this by refusing such a configuration, address family can not change on transport mode. We use the assumption that, on transport mode, the first templates address family must match the address family of the policy selector. Subsequent transport mode templates must mach the address family of the previous template. Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit e42d0cca6099509422330f656b67495317c2b059 Author: Takuo Koguchi Date: Thu Dec 7 16:20:14 2017 +0900 spi: sun4i: disable clocks in the remove function [ Upstream commit c810daba0ab5226084a56893a789af427a801146 ] mclk and hclk need to be disabled. Since pm_runtime_disable does not disable the clocks, use pm_runtime_force_suspend instead. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Takuo Koguchi Acked-by: Maxime Ripard Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9ad1fd863e8205de3f54a8f24460f3bf11960901 Author: Cai Li Date: Tue Nov 21 17:24:38 2017 +0800 clk: fix a panic error caused by accessing NULL pointer [ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ] In some cases the clock parent would be set NULL when doing re-parent, it will cause a NULL pointer accessing if clk_set trace event is enabled. This patch sets the parent as "none" if the input parameter is NULL. Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations) Signed-off-by: Cai Li Signed-off-by: Chunyan Zhang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 233c8536bf579f6908fc27c050302475afbbef75 Author: Eric Biggers Date: Fri Dec 8 15:13:28 2017 +0000 509: fix printing uninitialized stack memory when OID is empty [ Upstream commit 8dfd2f22d3bf3ab7714f7495ad5d897b8845e8c1 ] Callers of sprint_oid() do not check its return value before printing the result. In the case where the OID is zero-length, -EBADMSG was being returned without anything being written to the buffer, resulting in uninitialized stack memory being printed. Fix this by writing "(bad)" to the buffer in the cases where -EBADMSG is returned. Fixes: 4f73175d0375 ("X.509: Add utility functions to render OIDs as strings") Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Sasha Levin commit bcc0c138f9aabb1234319b9a34c84a482cea8d45 Author: Nikolay Borisov Date: Fri Dec 1 11:19:42 2017 +0200 btrfs: Fix possible off-by-one in btrfs_search_path_in_tree [ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ] The name char array passed to btrfs_search_path_in_tree is of size BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes are in the range of [0, 4079]. Currently the code uses the define but this represents an off-by-one. Implications: Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be written to extra space, not some padding that could be provided by the allocator. btrfs-progs store the arguments on stack, but kernel does own copy of the ioctl buffer and the off-by-one overwrite does not affect userspace, but the ending 0 might be lost. Kernel ioctl buffer is allocated dynamically so we're overwriting somebody else's memory, and the ioctl is privileged if args.objectid is not 256. Which is in most cases, but resolving a subvolume stored in another directory will trigger that path. Before this patch the buffer was one byte larger, but then the -1 was not added. Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls") Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba [ added implications ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 2f12e01e845f5f121e88b78ddc3d3e3774a9288a Author: Nogah Frankel Date: Mon Dec 4 13:31:11 2017 +0200 net_sched: red: Avoid illegal values [ Upstream commit 8afa10cbe281b10371fee5a87ab266e48d71a7f9 ] Check the qmin & qmax values doesn't overflow for the given Wlog value. Check that qmin <= qmax. Fixes: a783474591f2 ("[PKT_SCHED]: Generic RED layer") Signed-off-by: Nogah Frankel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af58e813e11bb0d60c21e5cd8ece183f35016348 Author: Nogah Frankel Date: Mon Dec 4 13:31:10 2017 +0200 net_sched: red: Avoid devision by zero [ Upstream commit 5c472203421ab4f928aa1ae9e1dbcfdd80324148 ] Do not allow delta value to be zero since it is used as a divisor. Fixes: 8af2a218de38 ("sch_red: Adaptative RED AQM") Signed-off-by: Nogah Frankel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b349c2bdea43e99efcefa26da72f69de1896fe7e Author: Zumeng Chen Date: Mon Dec 4 11:22:02 2017 +0800 gianfar: fix a flooded alignment reports because of padding issue. [ Upstream commit 58117672943734715bbe7565ac9f062effa524f0 ] According to LS1021A RM, the value of PAL can be set so that the start of the IP header in the receive data buffer is aligned to a 32-bit boundary. Normally, setting PAL = 2 provides minimal padding to ensure such alignment of the IP header. However every incoming packet's 8-byte time stamp will be inserted into the packet data buffer as padding alignment bytes when hardware time stamping is enabled. So we set the padding 8+2 here to avoid the flooded alignment faults: root@128:~# cat /proc/cpu/alignment User: 0 System: 17539 (inet_gro_receive+0x114/0x2c0) Skipped: 0 Half: 0 Word: 0 DWord: 0 Multi: 17539 User faults: 2 (fixup) Also shown when exception report enablement CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 4.1.21-rt13-WR8.0.0.0_preempt-rt #16 Hardware name: Freescale LS1021A [<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24) [<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac) [<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958) [<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc) [<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60) Exception stack(0x86ad1cc0 to 0x86ad1d08) 1cc0: f9b3e080 86b3d072 2d78d287 00000000 866816c0 86b3d05e 86e785d0 00000000 1ce0: 00000011 0000000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c 1d00: 40070013 ffffffff [<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0) [<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0) [<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c) [<8066133c>] (napi_gro_receive) from [<804f0538>] (gfar_clean_rx_ring+0x39c/0x7d4) [<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0) [<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c) [<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc) [<80033638>] (do_current_softirqs) from [<800338c4>] (__local_bh_enable+0x90/0xa8) [<800338c4>] (__local_bh_enable) from [<8008025c>] (irq_forced_thread_fn+0x70/0x84) [<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244) [<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104) [<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Zumeng Chen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 04142d311c0fddcc22d2561634f80dc05aa51efa Author: Stefan Haberland Date: Thu Oct 26 14:37:35 2017 +0200 s390/dasd: prevent prefix I/O error [ Upstream commit da340f921d3454f1521671c7a5a43ad3331fbe50 ] Prevent that a prefix flag is set based on invalid configuration data. The validity.verify_base flag should only be set for alias devices. Usually the unit address type is either one of base, PAV alias or HyperPAV alias. But in cases where the unit address type is not set or any other value the validity.verify_base flag might be set as well. This would lead to follow on errors. Explicitly check for alias devices and set the validity flag only for them. Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit ffd97e42742dbf3f95499242611b7ad2459bace8 Author: Ravi Bangoria Date: Thu Nov 30 14:03:22 2017 +0530 powerpc/perf: Fix oops when grouping different pmu events [ Upstream commit 5aa04b3eb6fca63d2e9827be656dcadc26d54e11 ] When user tries to group imc (In-Memory Collections) event with normal event, (sometime) kernel crashes with following log: Faulting instruction address: 0x00000000 [link register ] c00000000010ce88 power_check_constraints+0x128/0x980 ... c00000000010e238 power_pmu_event_init+0x268/0x6f0 c0000000002dc60c perf_try_init_event+0xdc/0x1a0 c0000000002dce88 perf_event_alloc+0x7b8/0xac0 c0000000002e92e0 SyS_perf_event_open+0x530/0xda0 c00000000000b004 system_call+0x38/0xe0 'event_base' field of 'struct hw_perf_event' is used as flags for normal hw events and used as memory address for imc events. While grouping these two types of events, collect_events() tries to interpret imc 'event_base' as a flag, which causes a corruption resulting in a crash. Consider only those events which belongs to 'perf_hw_context' in collect_events(). Signed-off-by: Ravi Bangoria Reviewed-By: Madhavan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f2014cf430fb430c0655e06b5195f25abf3e9e82 Author: Gao Feng Date: Fri Dec 1 09:58:42 2017 +0800 ipvlan: Add the skb->mark as flow4's member to lookup route [ Upstream commit a98a4ebc8c61d20f0150d6be66e0e65223a347af ] Current codes don't use skb->mark to assign flowi4_mark, it would make the policy route rule with fwmark doesn't work as expected. Signed-off-by: Gao Feng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 799432ee54fbb64c6afaac2911095c2dd286a24a Author: Will Deacon Date: Wed Nov 29 15:20:03 2017 +0000 scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none [ Upstream commit e814bccbafece52a24e152d2395b5d49eef55841 ] My bisect scripts starting running into build failures when trying to compile 4.15-rc1 with the builds failing with things like: drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union! The line in question is actually just a #define, but after some digging it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea ("Add optional check for bad kernel-doc comments") that results in kernel-doc running on each source file. The file in question has a badly formatted comment immediately before the #define: /** * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for * bus layer usage. */ which causes the regex in dump_struct to fail (lack of braces following struct declaration) and kernel-doc returns 1, which causes the build to fail. Fix the issue by always returning 0 from kernel-doc when invoked with -none. It successfully generates no documentation, and prints out any issues. Cc: Matthew Wilcox Cc: Jonathan Corbet Signed-off-by: Will Deacon Signed-off-by: Jonathan Corbet Signed-off-by: Sasha Levin commit 44b3348aab81354f30213bcf9e78f9717879b1b2 Author: Andre Przywara Date: Sat Nov 25 12:19:48 2017 +0000 pinctrl: sunxi: Fix A80 interrupt pin bank [ Upstream commit 6ad4cc8d1ac483e0fd33f605fb2788b0ecf51ed4 ] On the A80 the pins on port B can trigger interrupts, and those are assigned to the second interrupt bank. Having two pins assigned to the same interrupt bank/pin combination does not look healthy (instead more like a copy&paste bug from pins PA14-PA16), so fix the interrupt bank for pins PB14-PB16, which is actually 1. I don't have any A80 board, so could not test this. Fixes: d5e9fb31baa2 ("pinctrl: sunxi: Add A80 pinctrl muxing options") Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5eab3467438491cd4d58d77e2d94f140d30afd9b Author: Mauro Carvalho Chehab Date: Wed Nov 29 08:44:41 2017 -0500 media: s5k6aa: describe some function parameters [ Upstream commit 070250a1715cee2297de0d9e7e2cea58be999d37 ] as warned: drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 's5k6aa' drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 's5k6aa' drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 's5k6aa' drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 'preset' drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 'sd' Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c48a86aad89e9565596574d5c557974162e5f146 Author: Satheesh Rajendran Date: Wed Nov 22 22:13:53 2017 +0530 perf bench numa: Fixup discontiguous/sparse numa nodes [ Upstream commit 321a7c35c90cc834851ceda18a8ee18f1d032b92 ] Certain systems are designed to have sparse/discontiguous nodes. On such systems, 'perf bench numa' hangs, shows wrong number of nodes and shows values for non-existent nodes. Handle this by only taking nodes that are exposed by kernel to userspace. Signed-off-by: Satheesh Rajendran Reviewed-by: Srikar Dronamraju Acked-by: Naveen N. Rao Link: http://lkml.kernel.org/r/1edbcd353c009e109e93d78f2f46381930c340fe.1511368645.git.sathnaga@linux.vnet.ibm.com Signed-off-by: Balamuruhan S Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7163cbe87b4f7840d92ad04702223c146f0c5ea4 Author: Jiri Olsa Date: Tue Nov 14 10:23:39 2017 +0100 perf top: Fix window dimensions change handling [ Upstream commit b135e5ee1a0e325166c30b16cf5493fea44ede45 ] The stdio perf top crashes when we change the terminal window size. The reason is that we assumed we get the perf_top pointer as a signal handler argument which is not the case. Changing the SIGWINCH handler logic to change global resize variable, which is checked in the main thread loop. Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Tested-by: Ravi Bangoria Cc: Adrian Hunter Cc: Andi Kleen Cc: David Ahern Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-ysuzwz77oev1ftgvdscn9bpu@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8c22751b24520128583bef8f624fb9993b5e73a2 Author: Peter Ujfalusi Date: Wed Nov 1 11:03:31 2017 +0200 ARM: dts: am4372: Correct the interrupts_properties of McASP [ Upstream commit 627395a6f8091c0aa18f49dca7df59ba3ec147ef ] Fixes the following warnings: arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /ocp@44000000/mcasp@48038000 arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /ocp@44000000/mcasp@4803C000 Signed-off-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit ec18040d540e5e35418d76233f3d13dca036afcf Author: Tony Lindgren Date: Fri Nov 17 08:56:58 2017 -0800 ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen [ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ] There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4 for a while that happens after about 20 - 40 minutes on an idle system with some data feeding device being connected, like a USB GPS device or a cellular modem. This issue happens in cpuidle states C2 and C3 and does not happen if cpuidle is limited to C1 state only. The symptoms are that the whole system hangs and never wakes up from idle, and if a watchdog is configured the system reboots after a while. Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC interrupt controller directly as a parent instead of the WUGEN. We need to pass the interrupts through WUGEN to GIC to provide the wakeup events for the processor. Let's fix the issue by removing the gic interrupt-parent and use the default interrupt-parent wakeupgen instead. Note that omap5.dtsi had this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains") but we somehow missed omap4 at that point. Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains") Cc: Dave Gerlach Cc: Nishanth Menon Cc: Marc Zyngier Cc: Sebastian Reichel Reviewed-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 4f3ce486d6db387c9057d1d03c065b7152f3b8a8 Author: Keerthy Date: Fri Nov 10 16:56:52 2017 +0530 ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function [ Upstream commit b6d6af7226465b6d11eac09d0be2ab78a4a9eb62 ] Referring TRM Am335X series: http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf The LastPowerStateEntered bitfield is present only for PM_CEFUSE domain. This is not present in any of the other power domains. Hence remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly reads the reserved bit fields for all the other power domains. Reading the reserved bits leads to wrongly interpreting the low power transitions for various power domains that do not have the LastPowerStateEntered field. The pm debug counters values are wrong currently as we are incrementing them based on the reserved bits. Signed-off-by: Keerthy Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 0736d0a721927d89230e1706d018770384f39a47 Author: Tony Lindgren Date: Mon Nov 27 08:57:26 2017 -0800 ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context [ Upstream commit d09220a887f70368afa79e850c95e74890c0a32d ] With the CMA changes from Joonsoo Kim , it was noticed that n900 stopped booting. After investigating it turned out that n900 save_secure_ram_context does some whacky virtual to physical address translation for the SRAM data address. As we now only have minimal parts of omap3 idle code copied to SRAM, running save_secure_ram_context() in SRAM is not needed. It only gets called on PM init. And it seems there's no need to ever call this from SRAM idle code. So let's just keep save_secure_ram_context() in DDR, and pass it the physical address of the parameters. We can do everything else in omap-secure.c like we already do for other secure code. And since we don't have any documentation, I still have no clue what the values for 0, 1 and 1 for the parameters might be. If somebody has figured it out, please do send a patch to add some comments. Debugged-by: Joonsoo Kim Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 09c6e45c0b14d760cedb14d776cd7a9482492708 Author: Randy Dunlap Date: Fri Nov 17 11:00:45 2017 -0800 usb: build drivers/usb/common/ when USB_SUPPORT is set [ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ] PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT is enabled so that drivers/usb/common/ is built. ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! Signed-off-by: Randy Dunlap Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8b9a860fab64847ee405d9282e1b9c0de6a643dc Author: Shuah Khan Date: Fri Jan 26 11:56:50 2018 -0700 usbip: keep usbip_device sockfd state in sync with tcp_socket [ Upstream commit 009f41aed4b3e11e6dc1e3c07377a10c20f1a5ed ] Keep usbip_device sockfd state in sync with tcp_socket. When tcp_socket is reset to null, reset sockfd to -1 to keep it in sync. Signed-off-by: Shuah Khan Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc79c66ace36ba773dd809d697dc876208909d46 Author: Eric Biggers Date: Tue Jan 30 23:11:24 2018 -0800 binder: check for binder_thread allocation failure in binder_poll() [ Upstream commit f88982679f54f75daa5b8eff3da72508f1e7422f ] If the kzalloc() in binder_get_thread() fails, binder_poll() dereferences the resulting NULL pointer. Fix it by returning POLLERR if the memory allocation failed. This bug was found by syzkaller using fault injection. Reported-by: syzbot Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8ff02edf345956a14a7ad42dc32b9850bedd3a12 Author: Paolo Abeni Date: Thu Feb 15 16:59:49 2018 +0100 dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock [ Upstream commit dfec091439bb2acf763497cfc58f2bdfc67c56b7 ] After commit 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock only in the required scope"), the caller of nf_{get/set}sockopt() must not hold any lock, but, in such changeset, I forgot to cope with DECnet. This commit addresses the issue moving the nf call outside the lock, in the dn_{get,set}sockopt() with the same schema currently used by ipv4 and ipv6. Also moves the unhandled sockopts of the end of the main switch statements, to improve code readability. Reported-by: Petr Vandrovec BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198791#c2 Fixes: 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock only in the required scope") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a8b4a20d8a6063fa30665fbb9828fbfefd77a858 Author: Arnd Bergmann Date: Mon Jan 15 17:04:22 2018 +0100 video: fbdev/mmp: add MODULE_LICENSE [ Upstream commit c1530ac5a3ce93a1f02adabc4508b5fbf862dfe2 ] Kbuild complains about the lack of a license tag in this driver: WARNING: modpost: missing MODULE_LICENSE() in drivers/video/fbdev/mmp/mmp_disp.o This adds the license, author and description tags. Signed-off-by: Arnd Bergmann Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 591509965fc8df42390efbdd963b4d1d357d849c Author: Arnd Bergmann Date: Wed Jan 10 17:34:45 2018 +0100 ASoC: ux500: add MODULE_LICENSE tag [ Upstream commit 1783c9d7cb7bc3181b9271665959b87280d98d8e ] This adds MODULE_LICENSE/AUTHOR/DESCRIPTION tags to the ux500 platform drivers, to avoid these build warnings: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-plat-dma.o WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-mach-mop500.o The company no longer exists, so the email addresses of the authors don't work any more, but I've added them anyway for consistency. Signed-off-by: Arnd Bergmann Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 877ff9790355523ef665d7a377d486e88d04b847 Author: Willem de Bruijn Date: Tue Dec 12 11:39:04 2017 -0500 net: avoid skb_warn_bad_offload on IS_ERR [ Upstream commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada ] skb_warn_bad_offload warns when packets enter the GSO stack that require skb_checksum_help or vice versa. Do not warn on arbitrary bad packets. Packet sockets can craft many. Syzkaller was able to demonstrate another one with eth_type games. In particular, suppress the warning when segmentation returns an error, which is for reasons other than checksum offload. See also commit 36c92474498a ("net: WARN if skb_checksum_help() is called on skb requiring segmentation") for context on this warning. Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f0951b22e97e5f25b41ee99183a5c739bacb93b6 Author: Cong Wang Date: Mon Feb 5 14:41:45 2018 -0800 netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert [ Upstream commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 ] rateest_hash is supposed to be protected by xt_rateest_mutex, and, as suggested by Eric, lookup and insert should be atomic, so we should acquire the xt_rateest_mutex once for both. So introduce a non-locking helper for internal use and keep the locking one for external. Reported-by: Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target") Signed-off-by: Cong Wang Reviewed-by: Florian Westphal Reviewed-by: Eric Dumazet Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8a59c342392bb6bac5913fede4f99d942adf107e Author: Paolo Abeni Date: Tue Jan 30 19:01:40 2018 +0100 netfilter: on sockopt() acquire sock lock only in the required scope [ Upstream commit 3f34cfae1238848fd53f25e5c8fd59da57901f4b ] Syzbot reported several deadlocks in the netfilter area caused by rtnl lock and socket lock being acquired with a different order on different code paths, leading to backtraces like the following one: ====================================================== WARNING: possible circular locking dependency detected 4.15.0-rc9+ #212 Not tainted ------------------------------------------------------ syzkaller041579/3682 is trying to acquire lock: (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] lock_sock include/net/sock.h:1463 [inline] (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167 but task is already holding lock: (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}: __mutex_lock_common kernel/locking/mutex.c:756 [inline] __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 register_netdevice_notifier+0xad/0x860 net/core/dev.c:1607 tee_tg_check+0x1a0/0x280 net/netfilter/xt_TEE.c:106 xt_check_target+0x22c/0x7d0 net/netfilter/x_tables.c:845 check_target net/ipv6/netfilter/ip6_tables.c:538 [inline] find_check_entry.isra.7+0x935/0xcf0 net/ipv6/netfilter/ip6_tables.c:580 translate_table+0xf52/0x1690 net/ipv6/netfilter/ip6_tables.c:749 do_replace net/ipv6/netfilter/ip6_tables.c:1165 [inline] do_ip6t_set_ctl+0x370/0x5f0 net/ipv6/netfilter/ip6_tables.c:1691 nf_sockopt net/netfilter/nf_sockopt.c:106 [inline] nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115 ipv6_setsockopt+0x115/0x150 net/ipv6/ipv6_sockglue.c:928 udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978 SYSC_setsockopt net/socket.c:1849 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1828 entry_SYSCALL_64_fastpath+0x29/0xa0 -> #0 (sk_lock-AF_INET6){+.+.}: lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914 lock_sock_nested+0xc2/0x110 net/core/sock.c:2780 lock_sock include/net/sock.h:1463 [inline] do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167 ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922 udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978 SYSC_setsockopt net/socket.c:1849 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1828 entry_SYSCALL_64_fastpath+0x29/0xa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(sk_lock-AF_INET6); lock(rtnl_mutex); lock(sk_lock-AF_INET6); *** DEADLOCK *** 1 lock held by syzkaller041579/3682: #0: (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 The problem, as Florian noted, is that nf_setsockopt() is always called with the socket held, even if the lock itself is required only for very tight scopes and only for some operation. This patch addresses the issues moving the lock_sock() call only where really needed, namely in ipv*_getorigdst(), so that nf_setsockopt() does not need anymore to acquire both locks. Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Reported-by: syzbot+a4c2dc980ac1af699b36@syzkaller.appspotmail.com Suggested-by: Florian Westphal Signed-off-by: Paolo Abeni Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 905db624e59eb730478d8304af5c34c9944c9bc4 Author: Dmitry Vyukov Date: Tue Jan 30 15:21:34 2018 +0100 netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check() [ Upstream commit 1a38956cce5eabd7b74f94bab70265e4df83165e ] Commit 136e92bbec0a switched local_nodes from an array to a bitmask but did not add proper bounds checks. As the result clusterip_config_init_nodelist() can both over-read ipt_clusterip_tgt_info.local_nodes and over-write clusterip_config.local_nodes. Add bounds checks for both. Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data") Signed-off-by: Dmitry Vyukov Reported-by: syzbot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3779fc38796d5f62d43e9c5b92c165c6977fe119 Author: Eric Dumazet Date: Wed Jan 24 17:16:09 2018 -0800 netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target} [ Upstream commit da17c73b6eb74aad3c3c0654394635675b623b3e ] It looks like syzbot found its way into netfilter territory. Issue here is that @name comes from user space and might not be null terminated. Out-of-bound reads happen, KASAN is not happy. v2 added similar fix for xt_request_find_target(), as Florian advised. Signed-off-by: Eric Dumazet Reported-by: syzbot Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3ff2aade6674dff269732a54da158801afe43c3b Author: Dmitry Vyukov Date: Thu Dec 28 09:48:54 2017 +0100 netfilter: x_tables: fix int overflow in xt_alloc_table_info() [ Upstream commit 889c604fd0b5f6d3b8694ade229ee44124de1127 ] syzkaller triggered OOM kills by passing ipt_replace.size = -1 to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in xt_alloc_table_info() causes int overflow and the size check passes when it should not. SMP_ALIGN() is no longer needed leftover. Remove SMP_ALIGN() call in xt_alloc_table_info(). Reported-by: syzbot+4396883fa8c4f64e0175@syzkaller.appspotmail.com Signed-off-by: Dmitry Vyukov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 45cafc0aac3ff6cd32a14b1edc6ad7eb0649407c Author: Eric Biggers Date: Mon Dec 18 16:40:26 2017 -0800 crypto: x86/twofish-3way - Fix %rbp usage [ Upstream commit d8c7fe9f2a486a6e5f0d5229ca43807af5ab22c6 ] Using %rbp as a temporary register breaks frame pointer convention and breaks stack traces when unwinding from an interrupt in the crypto code. In twofish-3way, we can't simply replace %rbp with another register because there are none available. Instead, we use the stack to hold the values that %rbp, %r11, and %r12 were holding previously. Each of these values represents the half of the output from the previous Feistel round that is being passed on unchanged to the following round. They are only used once per round, when they are exchanged with %rax, %rbx, and %rcx. As a result, we free up 3 registers (one per block) and can reassign them so that %rbp is not used, and additionally %r14 and %r15 are not used so they do not need to be saved/restored. There may be a small overhead caused by replacing 'xchg REG, REG' with the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per round. But, counterintuitively, when I tested "ctr-twofish-3way" on a Haswell processor, the new version was actually about 2% faster. (Perhaps 'xchg' is not as well optimized as plain moves.) Reported-by: syzbot Signed-off-by: Eric Biggers Reviewed-by: Josh Poimboeuf Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 03915a4958d91a7b1c5668bb1773784fcef4777e Author: Paul Moore Date: Tue Dec 5 17:17:43 2017 -0500 selinux: skip bounded transition processing if the policy isn't loaded [ Upstream commit 4b14752ec4e0d87126e636384cf37c8dd9df157c ] We can't do anything reasonable in security_bounded_transition() if we don't have a policy loaded, and in fact we could run into problems with some of the code inside expecting a policy. Fix these problems like we do many others in security/selinux/ss/services.c by checking to see if the policy is loaded (ss_initialized) and returning quickly if it isn't. Reported-by: syzbot Signed-off-by: Paul Moore Acked-by: Stephen Smalley Reviewed-by: James Morris Signed-off-by: Sasha Levin commit 62850f402a7674c5dbaf82e9ce0bab9d177a6c5f Author: Paul Moore Date: Tue Nov 28 18:51:12 2017 -0500 selinux: ensure the context is NUL terminated in security_context_to_sid_core() [ Upstream commit ef28df55ac27e1e5cd122e19fa311d886d47a756 ] The syzbot/syzkaller automated tests found a problem in security_context_to_sid_core() during early boot (before we load the SELinux policy) where we could potentially feed context strings without NUL terminators into the strcmp() function. We already guard against this during normal operation (after the SELinux policy has been loaded) by making a copy of the context strings and explicitly adding a NUL terminator to the end. The patch extends this protection to the early boot case (no loaded policy) by moving the context copy earlier in security_context_to_sid_core(). Reported-by: syzbot Signed-off-by: Paul Moore Reviewed-By: William Roberts Signed-off-by: Sasha Levin commit a0951cc315c655caa47c599c1e1f433cbe02337c Author: David Howells Date: Tue Jul 4 17:25:02 2017 +0100 Provide a function to create a NUL-terminated string from unterminated data [ Upstream commit f35157417215ec138c920320c746fdb3e04ef1d5 ] Provide a function, kmemdup_nul(), that will create a NUL-terminated string from an unterminated character array where the length is known in advance. This is better than kstrndup() in situations where we already know the string length as the strnlen() in kstrndup() is superfluous. Signed-off-by: David Howells Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 247ab8ef2b38ea323132be5880a4ae879ea4ada8 Author: Jens Axboe Date: Sun Nov 5 09:16:09 2017 -0700 blktrace: fix unlocked registration of tracepoints [ Upstream commit a6da0024ffc19e0d47712bb5ca4fd083f76b07df ] We need to ensure that tracepoints are registered and unregistered with the users of them. The existing atomic count isn't enough for that. Add a lock around the tracepoints, so we serialize access to them. This fixes cases where we have multiple users setting up and tearing down tracepoints, like this: CPU: 0 PID: 2995 Comm: syzkaller857118 Not tainted 4.14.0-rc5-next-20171018+ #36 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:52 panic+0x1e4/0x41c kernel/panic.c:183 __warn+0x1c4/0x1e0 kernel/panic.c:546 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:177 do_trap_no_signal arch/x86/kernel/traps.c:211 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:260 do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:297 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:310 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905 RIP: 0010:tracepoint_add_func kernel/tracepoint.c:210 [inline] RIP: 0010:tracepoint_probe_register_prio+0x397/0x9a0 kernel/tracepoint.c:283 RSP: 0018:ffff8801d1d1f6c0 EFLAGS: 00010293 RAX: ffff8801d22e8540 RBX: 00000000ffffffef RCX: ffffffff81710f07 RDX: 0000000000000000 RSI: ffffffff85b679c0 RDI: ffff8801d5f19818 RBP: ffff8801d1d1f7c8 R08: ffffffff81710c10 R09: 0000000000000004 R10: ffff8801d1d1f6b0 R11: 0000000000000003 R12: ffffffff817597f0 R13: 0000000000000000 R14: 00000000ffffffff R15: ffff8801d1d1f7a0 tracepoint_probe_register+0x2a/0x40 kernel/tracepoint.c:304 register_trace_block_rq_insert include/trace/events/block.h:191 [inline] blk_register_tracepoints+0x1e/0x2f0 kernel/trace/blktrace.c:1043 do_blk_trace_setup+0xa10/0xcf0 kernel/trace/blktrace.c:542 blk_trace_setup+0xbd/0x180 kernel/trace/blktrace.c:564 sg_ioctl+0xc71/0x2d90 drivers/scsi/sg.c:1089 vfs_ioctl fs/ioctl.c:45 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685 SYSC_ioctl fs/ioctl.c:700 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x444339 RSP: 002b:00007ffe05bb5b18 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000006d66c0 RCX: 0000000000444339 RDX: 000000002084cf90 RSI: 00000000c0481273 RDI: 0000000000000009 RBP: 0000000000000082 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffffff R13: 00000000c0481273 R14: 0000000000000000 R15: 0000000000000000 since we can now run these in parallel. Ensure that the exported helpers for doing this are grabbing the queue trace mutex. Reported-by: Steven Rostedt Tested-by: Dmitry Vyukov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3f065a1d7cc83800bb68655f6067de71afc5ac62 Author: Cong Wang Date: Mon Nov 27 11:15:16 2017 -0800 xfrm: check id proto in validate_tmpl() [ Upstream commit 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 ] syzbot reported a kernel warning in xfrm_state_fini(), which indicates that we have entries left in the list net->xfrm.state_all whose proto is zero. And xfrm_id_proto_match() doesn't consider them as a match with IPSEC_PROTO_ANY in this case. Proto with value 0 is probably not a valid value, at least verify_newsa_info() doesn't consider it valid either. This patch fixes it by checking the proto value in validate_tmpl() and rejecting invalid ones, like what iproute2 does in xfrm_xfrmproto_getbyname(). Reported-by: syzbot Cc: Steffen Klassert Cc: Herbert Xu Signed-off-by: Cong Wang Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit a8139d020bcc2492fcea74313613807385534ef8 Author: Tetsuo Handa Date: Mon Dec 18 20:31:41 2017 +0900 mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. [ Upstream commit bb422a738f6566f7439cd347d54e321e4fe92a9f ] Syzbot caught an oops at unregister_shrinker() because combination of commit 1d3d4437eae1bb29 ("vmscan: per-node deferred work") and fault injection made register_shrinker() fail and the caller of register_shrinker() did not check for failure. ---------- [ 554.881422] FAULT_INJECTION: forcing a failure. [ 554.881422] name failslab, interval 1, probability 0, space 0, times 0 [ 554.881438] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 [ 554.881443] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 554.881445] Call Trace: [ 554.881459] dump_stack+0x194/0x257 [ 554.881474] ? arch_local_irq_restore+0x53/0x53 [ 554.881486] ? find_held_lock+0x35/0x1d0 [ 554.881507] should_fail+0x8c0/0xa40 [ 554.881522] ? fault_create_debugfs_attr+0x1f0/0x1f0 [ 554.881537] ? check_noncircular+0x20/0x20 [ 554.881546] ? find_next_zero_bit+0x2c/0x40 [ 554.881560] ? ida_get_new_above+0x421/0x9d0 [ 554.881577] ? find_held_lock+0x35/0x1d0 [ 554.881594] ? __lock_is_held+0xb6/0x140 [ 554.881628] ? check_same_owner+0x320/0x320 [ 554.881634] ? lock_downgrade+0x990/0x990 [ 554.881649] ? find_held_lock+0x35/0x1d0 [ 554.881672] should_failslab+0xec/0x120 [ 554.881684] __kmalloc+0x63/0x760 [ 554.881692] ? lock_downgrade+0x990/0x990 [ 554.881712] ? register_shrinker+0x10e/0x2d0 [ 554.881721] ? trace_event_raw_event_module_request+0x320/0x320 [ 554.881737] register_shrinker+0x10e/0x2d0 [ 554.881747] ? prepare_kswapd_sleep+0x1f0/0x1f0 [ 554.881755] ? _down_write_nest_lock+0x120/0x120 [ 554.881765] ? memcpy+0x45/0x50 [ 554.881785] sget_userns+0xbcd/0xe20 (...snipped...) [ 554.898693] kasan: CONFIG_KASAN_INLINE enabled [ 554.898724] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 554.898732] general protection fault: 0000 [#1] SMP KASAN [ 554.898737] Dumping ftrace buffer: [ 554.898741] (ftrace buffer empty) [ 554.898743] Modules linked in: [ 554.898752] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 [ 554.898755] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 554.898760] task: ffff8801d1dbe5c0 task.stack: ffff8801c9e38000 [ 554.898772] RIP: 0010:__list_del_entry_valid+0x7e/0x150 [ 554.898775] RSP: 0018:ffff8801c9e3f108 EFLAGS: 00010246 [ 554.898780] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 554.898784] RDX: 0000000000000000 RSI: ffff8801c53c6f98 RDI: ffff8801c53c6fa0 [ 554.898788] RBP: ffff8801c9e3f120 R08: 1ffff100393c7d55 R09: 0000000000000004 [ 554.898791] R10: ffff8801c9e3ef70 R11: 0000000000000000 R12: 0000000000000000 [ 554.898795] R13: dffffc0000000000 R14: 1ffff100393c7e45 R15: ffff8801c53c6f98 [ 554.898800] FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 [ 554.898804] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 554.898807] CR2: 00000000dbc23000 CR3: 00000001c7269000 CR4: 00000000001406e0 [ 554.898813] DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 [ 554.898816] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 [ 554.898818] Call Trace: [ 554.898828] unregister_shrinker+0x79/0x300 [ 554.898837] ? perf_trace_mm_vmscan_writepage+0x750/0x750 [ 554.898844] ? down_write+0x87/0x120 [ 554.898851] ? deactivate_super+0x139/0x1b0 [ 554.898857] ? down_read+0x150/0x150 [ 554.898864] ? check_same_owner+0x320/0x320 [ 554.898875] deactivate_locked_super+0x64/0xd0 [ 554.898883] deactivate_super+0x141/0x1b0 ---------- Since allowing register_shrinker() callers to call unregister_shrinker() when register_shrinker() failed can simplify error recovery path, this patch makes unregister_shrinker() no-op when register_shrinker() failed. Also, reset shrinker->nr_deferred in case unregister_shrinker() was by error called twice. Signed-off-by: Tetsuo Handa Signed-off-by: Aliaksei Karaliou Reported-by: syzbot Cc: Glauber Costa Cc: Al Viro Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit f6d1d15d0dc8aacf6c41e06f28c72b69fa870feb Author: Johannes Berg Date: Mon Jan 15 09:58:27 2018 +0100 cfg80211: check dev_set_name() return value [ Upstream commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 ] syzbot reported a warning from rfkill_alloc(), and after a while I think that the reason is that it was doing fault injection and the dev_set_name() failed, leaving the name NULL, and we didn't check the return value and got to rfkill_alloc() with a NULL name. Since we really don't want a NULL name, we ought to check the return value. Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()") Reported-by: syzbot+1ddfb3357e1d7bb5b5d3@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 103a894b8f4d452976bb123530ee777f541012bb Author: Arnd Bergmann Date: Thu Nov 30 06:08:05 2017 -0500 media: r820t: fix r820t_write_reg for KASAN [ Upstream commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 ] With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 58d69defc240714e3952251882d47d0ec19a8122 Author: Arnd Bergmann Date: Wed Jan 10 17:10:11 2018 +0100 ARM: dts: s5pv210: add interrupt-parent for ohci [ Upstream commit 5c1037196b9ee75897c211972de370ed1336ec8f ] The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 96f984040a3d93b2b083d4c45765d421c5203cad Author: Linus Torvalds Date: Sun Apr 2 17:10:08 2017 -0700 vfs: don't do RCU lookup of empty pathnames [ Upstream commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 ] Normal pathname lookup doesn't allow empty pathnames, but using AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you can trigger an empty pathname lookup. And not only is the RCU lookup in that case entirely unnecessary (because we'll obviously immediately finalize the end result), it is actively wrong. Why? An empth path is a special case that will return the original 'dirfd' dentry - and that dentry may not actually be RCU-free'd, resulting in a potential use-after-free if we were to initialize the path lazily under the RCU read lock and depend on complete_walk() finalizing the dentry. Found by syzkaller and KASAN. Reported-by: Dmitry Vyukov Reported-by: Vegard Nossum Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f7a709f6557e43078bcf96ca230407d8dbe5dd02 Author: Mikulas Patocka Date: Sun Feb 11 18:10:28 2018 -0500 mvpp2: fix multicast address filter [ Upstream commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 ] IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken multicast address filter in the mvpp2 driver. The driver loads doesn't load any multicast entries if "allmulti" is not set. This condition should be reversed. The condition !netdev_mc_empty(dev) is useless (because netdev_for_each_mc_addr is nop if the list is empty). This patch also fixes a possible overflow of the multicast list - if mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e78748b40e887c6e544dab71653858c370e283ea Author: Takashi Iwai Date: Mon Feb 12 15:20:51 2018 +0100 ALSA: seq: Fix racy pool initializations [ Upstream commit d15d662e89fc667b90cd294b0eb45694e33144da ] ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 52972f71768144eb636650b443203aedc9744ba2 Author: Lassi Ylikojola Date: Fri Feb 9 16:51:36 2018 +0200 ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 [ Upstream commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 ] Add quirk to ensure a sync endpoint is properly configured. This patch is a fix for same symptoms on Behringer UFX1204 as patch from Albertto Aquirre on Dec 8 2016 for Axe-Fx II. Signed-off-by: Lassi Ylikojola Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a2828af8bbb6b2ccb37003cc76e880943bf87bd1 Author: Jan-Marek Glogowski Date: Wed Feb 14 11:29:15 2018 +0100 ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 [ Upstream commit fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 ] These laptops have a combined jack to attach headsets, the U727 on the left, the U757 on the right, but a headsets microphone doesn't work. Using hdajacksensetest I found that pin 0x19 changed the present state when plugging the headset, in addition to 0x21, but didn't have the correct configuration (shown as "Not connected"). So this sets the configuration to the same values as the headphone pin 0x21 except for the device type microphone, which makes it work correctly. With the patch the configured pins for U727 are Pin 0x12 (Internal Mic, Mobile-In): present = No Pin 0x14 (Internal Speaker): present = No Pin 0x19 (Black Mic, Left side): present = No Pin 0x1d (Internal Aux): present = No Pin 0x21 (Black Headphone, Left side): present = No Signed-off-by: Jan-Marek Glogowski Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a3f72a7d9ef3a3d904bc1700f207146ca905e128 Author: Kirill Marinushkin Date: Mon Jan 29 06:37:55 2018 +0100 ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute [ Upstream commit 447cae58cecd69392b74a4a42cd0ab9cabd816af ] The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2362f4fd76febc3145c5c86a6f3a79cafb9a1777 Author: Liu Bo Date: Thu Jan 25 11:02:56 2018 -0700 Btrfs: fix unexpected -EEXIST when creating new inode [ Upstream commit 900c9981680067573671ecc5cbfa7c5770be3a40 ] The highest objectid, which is assigned to new inode, is decided at the time of initializing fs roots. However, in cases where log replay gets processed, the btree which fs root owns might be changed, so we have to search it again for the highest objectid, otherwise creating new inode would end up with -EEXIST. cc: v4.4-rc6+ Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by: Liu Bo Reviewed-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1b555cf3a4d7404c659606606b873e5a5786ea6e Author: Liu Bo Date: Thu Jan 25 11:02:51 2018 -0700 Btrfs: fix crash due to not cleaning up tree log block's dirty bits [ Upstream commit 1846430c24d66e85cc58286b3319c82cd54debb2 ] In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo Reviewed-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9ba95b32566a8eac13233bfb4d116a857b9e5790 Author: Liu Bo Date: Thu Jan 25 11:02:50 2018 -0700 Btrfs: fix deadlock in run_delalloc_nocow [ Upstream commit e89166990f11c3f21e1649d760dd35f9e410321c ] @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: Signed-off-by: Liu Bo Reviewed-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 85f5fd75929e65aa4f1a13ae666b578369a5cedc Author: Nicolas Pitre Date: Mon Jan 15 17:04:22 2018 +0100 console/dummy: leave .con_font_get set to NULL [ Upstream commit 724ba8b30b044aa0d94b1cd374fc15806cdd6f18 ] When this method is set, the caller expects struct console_font fields to be properly initialized when it returns. Leave it unset otherwise nonsensical (leaked kernel stack) values are returned to user space. Signed-off-by: Nicolas Pitre Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 4a9c9a7d977ea335abeb0d97ffbb239001334b14 Author: Johan Hovold Date: Fri Dec 29 19:48:43 2017 +0100 video: fbdev: atmel_lcdfb: fix display-timings lookup [ Upstream commit 9cb18db0701f6b74f0c45c23ad767b3ebebe37f6 ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent display node was also prematurely freed. Note that the display and timings node references are never put after a successful dt-initialisation so the nodes would leak on later probe deferrals and on driver unbind. Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport") Cc: stable # 3.13 Cc: Jean-Christophe PLAGNIOL-VILLARD Cc: Nicolas Ferre Cc: Alexandre Belloni Signed-off-by: Johan Hovold Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 977eb18fa3de04c84cb30e7a41b17b03bc62f8da Author: Arnd Bergmann Date: Fri Feb 16 16:25:53 2018 +0100 mm: hide a #warning for COMPILE_TEST [ Upstream commit af27d9403f5b80685b79c88425086edccecaf711 ] We get a warning about some slow configurations in randconfig kernels: mm/memory.c:83:2: error: #warning Unfortunate NUMA and NUMA Balancing config, growing page-frame for last_cpupid. [-Werror=cpp] The warning is reasonable by itself, but gets in the way of randconfig build testing, so I'm hiding it whenever CONFIG_COMPILE_TEST is set. The warning was added in 2013 in commit 75980e97dacc ("mm: fold page->_last_nid into page->flags where possible"). Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 55e72dd7590b0231def38520cbba82d0ab5a952a Author: Ernesto A. Fernández Date: Thu Jan 11 13:43:33 2018 -0500 ext4: correct documentation for grpid mount option [ Upstream commit 9f0372488cc9243018a812e8cfbf27de650b187b ] The grpid option is currently described as being the same as nogrpid. Signed-off-by: Ernesto A. Fernández Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ac9822f189aed6520cbc8949e3a7e151abb3bc4d Author: Zhouyi Zhou Date: Wed Jan 10 00:34:19 2018 -0500 ext4: save error to disk in __ext4_grp_locked_error() [ Upstream commit 06f29cc81f0350261f59643a505010531130eea0 ] In the function __ext4_grp_locked_error(), __save_error_info() is called to save error info in super block block, but does not sync that information to disk to info the subsequence fsck after reboot. This patch writes the error information to disk. After this patch, I think there is no obvious EXT4 error handle branches which leads to "Remounting filesystem read-only" will leave the disk partition miss the subsequence fsck. Signed-off-by: Zhouyi Zhou Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit efe28dcf96e1f38864e7102e31a598336e48ea3e Author: Stewart Smith Date: Tue Aug 2 11:50:16 2016 +1000 rtc-opal: Fix handling of firmware error codes, prevent busy loops [ Upstream commit 5b8b58063029f02da573120ef4dc9079822e3cda ] According to the OPAL docs: skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this indicates either a transient or permanent error. Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a permanent error particularly well, in that you could end up in a busy loop. This was not too hard to trigger on an AMI BMC based OpenPOWER machine doing a continuous "ipmitool mc reset cold" to the BMC, the result of that being that we'd get stuck in an infinite loop in opal_get_rtc_time(). We now retry a few times before returning the error higher up the stack. Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Stewart Smith Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b0e2ce066eac73903e0b47faef5cdc2267dc7039 Author: Julia Lawall Date: Sat Jan 27 15:28:15 2018 +0100 drm/radeon: adjust tested variable [ Upstream commit 3a61b527b4e1f285d21b6e9e623dc45cf8bb391f ] Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\&e\)) S1 else S2 ( x = g(...); | m = g(...,&x,...); | y = g(...); *if (e) S3 else S4 ) // Signed-off-by: Julia Lawall Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 353135c93f35805acb8d998df4c2e7cfe07c7385 Author: Viresh Kumar Date: Thu Jan 11 11:28:53 2018 +0530 arm: spear13xx: Fix spics gpio controller's warning [ Upstream commit f8975cb1b8a36d0839b6365235778dd9df1d04ca ] This fixes the following warning by also sending the flags argument for gpio controllers: Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable@vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann Signed-off-by: Viresh Kumar Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 999fb14622a38add849d133f90c8aa073902c30a Author: Viresh Kumar Date: Thu Jan 11 11:28:52 2018 +0530 arm: spear13xx: Fix dmas cells [ Upstream commit cdd10409914184c7eee5ae3e11beb890c9c16c61 ] The "dmas" cells for the designware DMA controller need to have only 3 properties apart from the phandle: request line, src master and destination master. But the commit 6e8887f60f60 updated it incorrectly while moving from platform code to DT. Fix it. Cc: stable@vger.kernel.org # v3.10+ Fixes: 6e8887f60f60 ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT") Reported-by: Arnd Bergmann Signed-off-by: Viresh Kumar Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 05fb811ed8baafceed439ebf3aa542fbe73f6b25 Author: Viresh Kumar Date: Thu Jan 11 11:28:51 2018 +0530 arm: spear600: Add missing interrupt-parent of rtc [ Upstream commit 6ffb5b4f248fe53e0361b8cbc2a523b432566442 ] The interrupt-parent of rtc was missing, add it. Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable@vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann Signed-off-by: Viresh Kumar Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit ed1f7ee64bf3d8a9a77e792437a8152b3d1e001e Author: Eugene Syromiatnikov Date: Mon Jan 15 20:38:17 2018 +0100 s390: fix handling of -1 in set{,fs}[gu]id16 syscalls [ Upstream commit 6dd0d2d22aa363fec075cb2577ba273ac8462e94 ] For some reason, the implementation of some 16-bit ID system calls (namely, setuid16/setgid16 and setfsuid16/setfsgid16) used type cast instead of low2highgid/low2highuid macros for converting [GU]IDs, which led to incorrect handling of value of -1 (which ought to be considered invalid). Discovered by strace test suite. Cc: stable@vger.kernel.org Signed-off-by: Eugene Syromiatnikov Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 79db9d04cdb1d19195455fd2218038aeb112bfff Author: Bjorn Andersson Date: Sun Nov 5 21:27:41 2017 -0800 PM / devfreq: Propagate error from devfreq_add_device() [ Upstream commit d1bf2d30728f310f72296b54f0651ecdb09cbb12 ] Propagate the error of devfreq_add_device() in devm_devfreq_add_device() rather than statically returning ENOMEM. This makes it slightly faster to pinpoint the cause of a returned error. Fixes: 8cd84092d35e ("PM / devfreq: Add resource-managed function for devfreq device") Cc: stable@vger.kernel.org Acked-by: Chanwoo Choi Signed-off-by: Bjorn Andersson Signed-off-by: MyungJoo Ham Signed-off-by: Sasha Levin commit f5d8d20ec9900245ac9c465b6e07330872fe4eee Author: Jack Morgenstein Date: Fri Jan 12 07:58:40 2018 +0200 IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports [ Upstream commit 852f6927594d0d3e8632c889b2ab38cbc46476ad ] Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Cc: Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit da411365d42512829466a88dafe9cc7faa8b3782 Author: Eric W. Biederman Date: Tue Aug 1 05:02:38 2017 -0500 mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy [ Upstream commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd ] Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely not correct. With si_code set to SI_USER si_pid and si_uid will be copied to userspace instead of si_addr. Which is very wrong. So fix this by using a sensible si_code (SEGV_MAPERR) for this failure. Cc: stable@vger.kernel.org Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel") Cc: David Howells Cc: Masakazu Urade Cc: Koichi Yasutake Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit f8c71a2ae14d30df74595194f4daaf6987b721bd Author: Amir Goldstein Date: Wed Nov 8 09:39:46 2017 +0200 ovl: fix failure to fsync lower dir [ Upstream commit d796e77f1dd541fe34481af2eee6454688d13982 ] As a writable mount, it is not expected for overlayfs to return EINVAL/EROFS for fsync, even if dir/file is not changed. This commit fixes the case of fsync of directory, which is easier to address, because overlayfs already implements fsync file operation for directories. The problem reported by Raphael is that new PostgreSQL 10.0 with a database in overlayfs where lower layer in squashfs fails to start. The failure is due to fsync error, when PostgreSQL does fsync on all existing db directories on startup and a specific directory exists lower layer with no changes. Reported-by: Raphael Hertzog Cc: # v3.18 Signed-off-by: Amir Goldstein Tested-by: Raphaël Hertzog Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 4e5d88a911f6c610afe11b36c9b3b36f8928daf7 Author: Greg Kroah-Hartman Date: Fri Jan 19 10:06:03 2018 +0100 ACPI: sbshc: remove raw pointer from printk() message [ Upstream commit 43cdd1b716b26f6af16da4e145b6578f98798bf6 ] There's no need to be printing a raw kernel pointer to the kernel log at every boot. So just remove it, and change the whole message to use the correct dev_info() call at the same time. Reported-by: Wang Qize Cc: All applicable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 789d8f6ea2adfed1f4c1df6a12047d9c80ed9f35 Author: Nikolay Borisov Date: Tue Dec 5 09:29:19 2017 +0200 btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker [ Upstream commit f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb ] This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers to deal with pages that have been improperly dirtied") and it didn't do any error handling then. This function might very well fail in ENOMEM situation, yet it's not handled, this could lead to inconsistent state. So let's handle the failure by setting the mapping error bit. Cc: stable@vger.kernel.org Signed-off-by: Nikolay Borisov Reviewed-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 996b7d3177b9860c80d903a650fa803e22f8d35e Author: Bart Van Assche Date: Tue Jan 2 11:39:47 2018 -0800 pktcdvd: Fix pkt_setup_dev() error path [ Upstream commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd ] Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue") modified add_disk() and disk_release() but did not update any of the error paths that trigger a put_disk() call after disk->queue has been assigned. That introduced the following behavior in the pktcdvd driver if pkt_new_dev() fails: Kernel BUG at 00000000e98fd882 [verbose debug info unavailable] Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL, fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev() error path. Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue") Signed-off-by: Bart Van Assche Cc: Tejun Heo Cc: Maciej S. Szmigiero Cc: # v3.2 Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 627af85d2fa7f1ad35514fb4dc475264c9069553 Author: James Hogan Date: Mon Nov 13 16:12:06 2017 +0000 EDAC, octeon: Fix an uninitialized variable warning [ Upstream commit 544e92581a2ac44607d7cc602c6b54d18656f56d ] Fix an uninitialized variable warning in the Octeon EDAC driver, as seen in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU Tools 2016.05-03: drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’: drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \ be used uninitialized in this function [-Wmaybe-uninitialized] if (int_reg.s.sec_err || int_reg.s.ded_err) { ^ Iinitialise the whole int_reg variable to zero before the conditional assignments in the error injection case. Signed-off-by: James Hogan Acked-by: David Daney Cc: linux-edac Cc: linux-mips@linux-mips.org Cc: # 3.15+ Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support") Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin commit fec5bb921e304cf6d0b956f38bdbbfb88272d2d7 Author: Max Filippov Date: Fri Jan 5 14:27:58 2018 -0800 xtensa: fix futex_atomic_cmpxchg_inatomic [ Upstream commit ca47480921587ae30417dd234a9f79af188e3666 ] Return 0 if the operation was successful, not the userspace memory value. Check that userspace value equals passed oldval, not itself. Don't update *uval if the value wasn't read from userspace memory. This fixes process hang due to infinite loop in futex_lock_pi. It also fixes a bunch of glibc tests nptl/tst-mutexpi*. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 0a4e346fc3194abed02361ed8dd4f709122bd0ac Author: Mikulas Patocka Date: Tue Jan 2 13:59:54 2018 -0500 alpha: fix reboot on Avanti platform [ Upstream commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 ] We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get machine check exception when attempting to reboot the machine. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Matt Turner Signed-off-by: Sasha Levin commit f7d21d98d7a981dfea32093c03b17fdef763c4f1 Author: Mikulas Patocka Date: Tue Jan 2 14:01:34 2018 -0500 alpha: fix crash if pthread_create races with signal delivery [ Upstream commit 21ffceda1c8b3807615c40d440d7815e0c85d366 ] On alpha, a process will crash if it attempts to start a thread and a signal is delivered at the same time. The crash can be reproduced with this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html The reason for the crash is this: * we call the clone syscall * we go to the function copy_process * copy process calls copy_thread_tls, it is a wrapper around copy_thread * copy_thread sets the tls pointer: childti->pcb.unique = regs->r20 * copy_thread sets regs->r20 to zero * we go back to copy_process * copy process checks "if (signal_pending(current))" and returns -ERESTARTNOINTR * the clone syscall is restarted, but this time, regs->r20 is zero, so the new thread is created with zero tls pointer * the new thread crashes in start_thread when attempting to access tls The comment in the code says that setting the register r20 is some compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug by zeroing regs->r20 only if CLONE_SETTLS is not set. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Matt Turner Signed-off-by: Sasha Levin commit 0bf095fc674ada33fc76a6dcce4060b2293a3880 Author: Eric W. Biederman Date: Mon Jul 24 17:30:30 2017 -0500 signal/sh: Ensure si_signo is initialized in do_divide_error [ Upstream commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 ] Set si_signo. Cc: Yoshinori Sato Cc: Rich Felker Cc: Paul Mundt Cc: linux-sh@vger.kernel.org Cc: stable@vger.kernel.org Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.") Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 641af40810688d1655460421f667dcfbe316f444 Author: Eric W. Biederman Date: Tue Aug 1 04:16:47 2017 -0500 signal/openrisc: Fix do_unaligned_access to send the proper signal [ Upstream commit 500d58300571b6602341b041f97c082a461ef994 ] While reviewing the signal sending on openrisc the do_unaligned_access function stood out because it is obviously wrong. A comment about an si_code set above when actually si_code is never set. Leading to a random si_code being sent to userspace in the event of an unaligned access. Looking further SIGBUS BUS_ADRALN is the proper pair of signal and si_code to send for an unaligned access. That is what other architectures do and what is required by posix. Given that do_unaligned_access is broken in a way that no one can be relying on it on openrisc fix the code to just do the right thing. Cc: stable@vger.kernel.org Fixes: 769a8a96229e ("OpenRISC: Traps") Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: Arnd Bergmann Cc: openrisc@lists.librecores.org Acked-by: Stafford Horne Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 9b717bfc57945658ff021feb08005f90cc009f3d Author: Kai-Heng Feng Date: Wed Dec 20 19:00:07 2017 +0800 Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" [ Upstream commit 7d06d5895c159f64c46560dc258e553ad8670fe0 ] This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56. This commit causes a regression on some QCA ROME chips. The USB device reset happens in btusb_open(), hence firmware loading gets interrupted. Furthermore, this commit stops working after commit ("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in btusb_suspend() when it's not a wakeup source. If we really want to reset the USB device, we need to do it before btusb_open(). Let's handle it in drivers/usb/core/quirks.c. Cc: stable@vger.kernel.org Cc: Leif Liddy Cc: Matthias Kaehlcke Cc: Brian Norris Cc: Daniel Drake Signed-off-by: Kai-Heng Feng Reviewed-by: Brian Norris Tested-by: Brian Norris Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit f64f863ab43f9560d7a7532d78e3d86cab8f181f Author: Hans de Goede Date: Wed Nov 29 20:29:07 2017 +0100 Bluetooth: btsdio: Do not bind to non-removable BCM43341 [ Upstream commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 ] BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT) use an UART connection for bluetooth. But they also advertise btsdio support on their 3th sdio function, this causes 2 problems: 1) A non functioning BT HCI getting registered 2) Since the btsdio driver does not have suspend/resume callbacks, mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify() to react as if the SDIO-card is removed and since the slot is marked as non-removable it will never get detected as inserted again. Which results in wifi no longer working after a suspend/resume. This commit fixes both by making btsdio ignore BCM43341 devices when connected to a slot which is marked non-removable. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit fad77200e92986f588df1c72dad6fb065124453d Author: Rasmus Villemoes Date: Tue Feb 6 15:37:55 2018 -0800 kernel/async.c: revert "async: simplify lowest_in_progress()" [ Upstream commit 4f7e988e63e336827f4150de48163bed05d653bd ] This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()") which was simply wrong: In the case where domain is NULL, we now use the wrong offsetof() in the list_first_entry macro, so we don't actually fetch the ->cookie value, but rather the eight bytes located sizeof(struct list_head) further into the struct async_entry. On 64 bit, that's the data member, while on 32 bit, that's a u64 built from func and data in some order. I think the bug happens to be harmless in practice: It obviously only affects callers which pass a NULL domain, and AFAICT the only such caller is async_synchronize_full() -> async_synchronize_full_domain(NULL) -> async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL) and the ASYNC_COOKIE_MAX means that in practice we end up waiting for the async_global_pending list to be empty - but it would break if somebody happened to pass (void*)-1 as the data element to async_schedule, and of course also if somebody ever does a async_synchronize_cookie_domain(, NULL) with a "finite" cookie value. Maybe the "harmless in practice" means this isn't -stable material. But I'm not completely confident my quick git grep'ing is enough, and there might be affected code in one of the earlier kernels that has since been removed, so I'll leave the decision to the stable guys. Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk Fixes: 92266d6ef60c "async: simplify lowest_in_progress()" Signed-off-by: Rasmus Villemoes Acked-by: Tejun Heo Cc: Arjan van de Ven Cc: Adam Wallis Cc: Lai Jiangshan Cc: [3.10+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a71f1862a7046515ce60cc2ffe090fa472b3c4cf Author: Mauro Carvalho Chehab Date: Wed Jan 24 06:01:57 2018 -0500 media: cxusb, dib0700: ignore XC2028_I2C_FLUSH [ Upstream commit 9893b905e743ded332575ca04486bd586c0772f7 ] The XC2028_I2C_FLUSH only needs to be implemented on a few devices. Others can safely ignore it. That prevents filling the dmesg with lots of messages like: dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0 Cc: stable@vger.kernel.org Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback") Reported-by: Enrico Mioso Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b18d01b9a132156e875a3e99cbaa9159fd1b72d2 Author: Liran Alon Date: Thu Nov 9 20:27:20 2017 +0200 KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2 [ Upstream commit 6b6977117f50d60455ace86b2d256f6fb4f3de05 ] Consider the following scenario: 1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI to CPU B via virtual posted-interrupt mechanism. 2. CPU B is currently executing L2 guest. 3. vmx_deliver_nested_posted_interrupt() calls kvm_vcpu_trigger_posted_interrupt() which will note that vcpu->mode == IN_GUEST_MODE. 4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR IPI, CPU B exits from L2 to L0 during event-delivery (valid IDT-vectoring-info). 5. CPU A now sends the physical IPI. The IPI is received in host and it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing. 6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT, CPU B continues to run in L0 and reach vcpu_enter_guest(). As KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume L2 guest. 7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be consumed at next L2 entry! Another scenario to consider: 1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI to CPU B via virtual posted-interrupt mechanism. 2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(), CPU B is at L0 and is about to resume into L2. Further assume that it is in vcpu_enter_guest() after check for KVM_REQ_EVENT. 3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and return false. Then, will set pi_pending=true and KVM_REQ_EVENT. 4. Now CPU B continue and resumes into L2 guest without processing the posted-interrupt until next L2 entry! To fix both issues, we just need to change vmx_deliver_nested_posted_interrupt() to set pi_pending=true and KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt(). It will fix the first scenario by chaging step (6) to note that KVM_REQ_EVENT and pi_pending=true and therefore process nested posted-interrupt. It will fix the second scenario by two possible ways: 1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received when CPU resumes into L2. 2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change vcpu->mode it will call kvm_request_pending() which will return true and therefore force another round of vcpu_enter_guest() which will note that KVM_REQ_EVENT and pi_pending=true and therefore process nested posted-interrupt. Cc: stable@vger.kernel.org Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing") Signed-off-by: Liran Alon Reviewed-by: Nikita Leshenko Reviewed-by: Krish Sadhukhan [Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT and L2 executes HLT instruction. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 056d4ed5cafc40e692affbd016c78e0fd5f513f7 Author: Marc Zyngier Date: Tue Feb 6 17:56:06 2018 +0000 arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls [ Upstream commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 ] KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Cc: Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 2ce8a62d862e3bcd16d12d6d7d71c0a343f4f99a Author: Cong Wang Date: Wed Apr 19 15:11:00 2017 -0700 nsfs: mark dentry with DCACHE_RCUACCESS [ Upstream commit 073c516ff73557a8f7315066856c04b50383ac34 ] Andrey reported a use-after-free in __ns_get_path(): spin_lock include/linux/spinlock.h:299 [inline] lockref_get_not_dead+0x19/0x80 lib/lockref.c:179 __ns_get_path+0x197/0x860 fs/nsfs.c:66 open_related_ns+0xda/0x200 fs/nsfs.c:143 sock_ioctl+0x39d/0x440 net/socket.c:1001 vfs_ioctl fs/ioctl.c:45 [inline] do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685 SYSC_ioctl fs/ioctl.c:700 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 We are under rcu read lock protection at that point: rcu_read_lock(); d = atomic_long_read(&ns->stashed); if (!d) goto slow; dentry = (struct dentry *)d; if (!lockref_get_not_dead(&dentry->d_lockref)) goto slow; rcu_read_unlock(); but don't use a proper RCU API on the free path, therefore a parallel __d_free() could free it at the same time. We need to mark the stashed dentry with DCACHE_RCUACCESS so that __d_free() will be called after all readers leave RCU. Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs") Cc: Alexander Viro Cc: Andrew Morton Reported-by: Andrey Konovalov Signed-off-by: Cong Wang Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ee3e3013bda6fdf2b88fb98068c812fffb36d0ad Author: Eric Biggers Date: Wed Jan 3 11:16:23 2018 -0800 crypto: cryptd - pass through absence of ->setkey() [ Upstream commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 ] When the cryptd template is used to wrap an unkeyed hash algorithm, don't install a ->setkey() method to the cryptd instance. This change is necessary for cryptd to keep working with unkeyed hash algorithms once we start enforcing that ->setkey() is called when present. Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 524e9a929b5d1e0396216e9ec64dc7fb3560f050 Author: Eric Biggers Date: Wed Jan 3 11:16:22 2018 -0800 crypto: hash - introduce crypto_hash_alg_has_setkey() [ Upstream commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba ] Templates that use an shash spawn can use crypto_shash_alg_has_setkey() to determine whether the underlying algorithm requires a key or not. But there was no corresponding function for ahash spawns. Add it. Note that the new function actually has to support both shash and ahash algorithms, since the ahash API can be used with either. Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 68215a03981538707e2772bc7a27a20ba95ab276 Author: Mika Westerberg Date: Thu Jan 11 15:55:50 2018 +0300 ahci: Add Intel Cannon Lake PCH-H PCI ID [ Upstream commit f919dde0772a894c693a1eeabc77df69d6a9b937 ] Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers. Signed-off-by: Mika Westerberg Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 973bdff02712de2117ff131c0cebcd4cfa709a61 Author: Hans de Goede Date: Wed Dec 6 16:41:09 2017 +0100 ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI [ Upstream commit 998008b779e424bd7513c434d0ab9c1268459009 ] Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI SATA controllers. This commit is a preparation patch for allowing a different default sata link powermanagement policy for mobile chipsets. Signed-off-by: Hans de Goede Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit d14c2c9dd30d131f3437d013605459e1ee015a86 Author: Ivan Vecera Date: Fri Jan 19 09:18:54 2018 +0100 kernfs: fix regression in kernfs_fop_write caused by wrong type [ Upstream commit ba87977a49913129962af8ac35b0e13e0fa4382d ] Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file") changes type of local variable 'len' from ssize_t to size_t. This change caused that the *ppos value is updated also when the previous write callback failed. Mentioned snippet: ... len = ops->write(...); <- return value can be negative ... if (len > 0) <- true here in this case *ppos += len; ... Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file") Acked-by: Tejun Heo Signed-off-by: Ivan Vecera Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit f1ced2e229e4119e9ce4b4640b7e14f0ef54ccd3 Author: Eric Biggers Date: Fri Jan 19 15:15:34 2018 -0800 NFS: reject request for id_legacy key without auxdata [ Upstream commit 49686cbbb3ebafe42e63868222f269d8053ead00 ] nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing to a 'struct idmap', via the call to request_key_with_auxdata() in nfs_idmap_request_key(). However it can also be reached via the request_key() system call in which case 'aux' will be NULL, causing a NULL pointer dereference in nfs_idmap_prepare_pipe_upcall(), assuming that the key description is valid enough to get that far. Fix this by making nfs_idmap_legacy_upcall() negate the key if no auxdata is provided. As usual, this bug was found by syzkaller. A simple reproducer using the command-line keyctl program is: keyctl request2 id_legacy uid:0 '' @s Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring") Reported-by: syzbot+5dfdbcf7b3eb5912abbb@syzkaller.appspotmail.com Cc: # v3.4+ Signed-off-by: Eric Biggers Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cfdf2414b1f6d133e60c56cf87458dd1a9d8aba7 Author: J. Bruce Fields Date: Tue Jan 16 10:08:00 2018 -0500 NFS: commit direct writes even if they fail partially [ Upstream commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 ] If some of the WRITE calls making up an O_DIRECT write syscall fail, we neglect to commit, even if some of the WRITEs succeed. We also depend on the commit code to free the reference count on the nfs_page taken in the "if (request_commit)" case at the end of nfs_direct_write_completion(). The problem was originally noticed because ENOSPC's encountered partway through a write would result in a closed file being sillyrenamed when it should have been unlinked. Signed-off-by: J. Bruce Fields Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit f40a0ab97f72ec6ed5c97b0e72061038623129a4 Author: Trond Myklebust Date: Mon Dec 18 14:39:13 2017 -0500 NFS: Add a cond_resched() to nfs_commit_release_pages() [ Upstream commit 7f1bda447c9bd48b415acedba6b830f61591601f ] The commit list can get very large, and so we need a cond_resched() in nfs_commit_release_pages() in order to ensure we don't hog the CPU for excessive periods of time. Reported-by: Mike Galbraith Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7fc6a17fff1aa90f3bcfca8718e46ead816d2fab Author: Miquel Raynal Date: Wed Jan 24 23:49:31 2018 +0100 mtd: nand: sunxi: Fix ECC strength choice [ Upstream commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 ] When the requested ECC strength does not exactly match the strengths supported by the ECC engine, the driver is selecting the closest strength meeting the 'selected_strength > requested_strength' constraint. Fix the fact that, in this particular case, ecc->strength value was not updated to match the 'selected_strength'. For instance, one can encounter this issue when no ECC requirement is filled in the device tree while the NAND chip minimum requirement is not a strength/step_size combo natively supported by the ECC engine. Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support") Cc: Suggested-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit eaac9c7828ae92e69060cd57b09e163a5a3f4cbd Author: Miquel Raynal Date: Fri Jan 12 10:13:36 2018 +0100 mtd: nand: Fix nand_do_read_oob() return value [ Upstream commit 87e89ce8d0d14f573c068c61bec2117751fb5103 ] Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a negative error, and the MTD layer expected it. However, the trend for the NAND layer is now to return an error or a positive number of bitflips. Deciding which status to return to the user belongs to the MTD layer. Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") brought this logic to the mtd_read_oob() function while the return value coming from nand_do_read_oob() (called by the ->_read_oob() hook) was left unchanged. Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit b5dd1c90a5245b9b019881c9b6d3087b9c4af662 Author: Arnd Bergmann Date: Wed Oct 11 15:54:10 2017 +0200 mtd: cfi: convert inline functions to macros [ Upstream commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 ] The map_word_() functions, dating back to linux-2.6.8, try to perform bitwise operations on a 'map_word' structure. This may have worked with compilers that were current then (gcc-3.4 or earlier), but end up being rather inefficient on any version I could try now (gcc-4.4 or higher). Specifically we hit a problem analyzed in gcc PR81715 where we fail to reuse the stack space for local variables. This can be seen immediately in the stack consumption for cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN) can be up to 2200 bytes. Changing the inline functions into macros brings this down to 1280 bytes. Without KASAN, the same problem exists, but the stack consumption is lower to start with, my patch shrinks it from 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word structures for each call to one of these helpers. With the latest gcc-8 snapshot, the problem is fixed in upstream gcc, but nobody uses that yet, so we should still work around it in mainline kernels and probably backport the workaround to stable kernels as well. We had a couple of other functions that suffered from the same gcc bug, and all of those had a simpler workaround involving dummy variables in the inline function. Unfortunately that did not work here, the macro hack was the best I could come up with. It would also be helpful to have someone to a little performance testing on the patch, to see how much it helps in terms of CPU utilitzation. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Acked-by: Richard Weinberger Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 72df17455074d12cff3a6b671197ced1ebb83605 Author: Malcolm Priestley Date: Tue Sep 26 17:10:21 2017 -0400 media: dvb-usb-v2: lmedm04: move ts2020 attach to dm04_lme2510_tuner [ Upstream commit 7bf7a7116ed313c601307f7e585419369926ab05 ] When the tuner was split from m88rs2000 the attach function is in wrong place. Move to dm04_lme2510_tuner to trap errors on failure and removing a call to lme_coldreset. Prevents driver starting up without any tuner connected. Fixes to trap for ts2020 fail. LME2510(C): FE Found M88RS2000 ts2020: probe of 0-0060 failed with error -11 ... LME2510(C): TUN Found RS2000 tuner 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 Reported-by: Andrey Konovalov Signed-off-by: Malcolm Priestley Tested-by: Andrey Konovalov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 596a157dfeef68f30e38d3a38e21b9d4d4c6b644 Author: Malcolm Priestley Date: Tue Sep 26 17:10:20 2017 -0400 media: dvb-usb-v2: lmedm04: Improve logic checking of warm start [ Upstream commit 3d932ee27e852e4904647f15b64dedca51187ad7 ] Warm start has no check as whether a genuine device has connected and proceeds to next execution path. Check device should read 0x47 at offset of 2 on USB descriptor read and it is the amount requested of 6 bytes. Fix for kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access as Reported-by: Andrey Konovalov Signed-off-by: Malcolm Priestley Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 203e5dcc6edbe7248c9800689da3dd316f4c434a Author: Mohamed Ghannam Date: Tue Dec 5 20:58:35 2017 +0000 dccp: CVE-2017-8824: use-after-free in DCCP code [ Upstream commit 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 ] Whenever the sock object is in DCCP_CLOSED state, dccp_disconnect() must free dccps_hc_tx_ccid and dccps_hc_rx_ccid and set to NULL. Signed-off-by: Mohamed Ghannam Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 16cd05f25489459d10035ffab9cb7391512f1437 Author: Thomas Gleixner Date: Fri Dec 15 10:32:03 2017 +0100 posix-timer: Properly check sigevent->sigev_notify [ Upstream commit cef31d9af908243421258f1df35a4a644604efbe ] timer_create() specifies via sigevent->sigev_notify the signal delivery for the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD and (SIGEV_SIGNAL | SIGEV_THREAD_ID). The sanity check in good_sigevent() is only checking the valid combination for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is not set it accepts any random value. This has no real effects on the posix timer and signal delivery code, but it affects show_timer() which handles the output of /proc/$PID/timers. That function uses a string array to pretty print sigev_notify. The access to that array has no bound checks, so random sigev_notify cause access beyond the array bounds. Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID masking from various code pathes as SIGEV_NONE can never be set in combination with SIGEV_THREAD_ID. Reported-by: Eric Biggers Reported-by: Dmitry Vyukov Reported-by: Alexey Dobriyan Signed-off-by: Thomas Gleixner Cc: John Stultz Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 57fc0c3f15860e73dadb93748a5bc809415af0bc Author: Yang Shunyong Date: Mon Jan 29 14:40:11 2018 +0800 dmaengine: dmatest: fix container_of member in dmatest_callback [ Upstream commit 66b3bd2356e0a1531c71a3dcf96944621e25c17c ] The type of arg passed to dmatest_callback is struct dmatest_done. It refers to test_done in struct dmatest_thread, not done_wait. Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...") Signed-off-by: Yang Shunyong Acked-by: Adam Wallis Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ec72b8251394d49a3df22ec559887b890ac865be Author: Aurelien Aptel Date: Thu Jan 25 15:59:39 2018 +0100 CIFS: zero sensitive data when freeing [ Upstream commit 97f4b7276b829a8927ac903a119bef2f963ccc58 ] also replaces memset()+kfree() by kzfree(). Signed-off-by: Aurelien Aptel Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Cc: Signed-off-by: Sasha Levin commit 01f70aeede46a5e212c064e74545c5cbbd4089f4 Author: Daniel N Pettersson Date: Thu Jan 11 16:00:12 2018 +0100 cifs: Fix autonegotiate security settings mismatch [ Upstream commit 9aca7e454415f7878b28524e76bebe1170911a88 ] Autonegotiation gives a security settings mismatch error if the SMB server selects an SMBv3 dialect that isn't SMB3.02. The exact error is "protocol revalidation - security settings mismatch". This can be tested using Samba v4.2 or by setting the global Samba setting max protocol = SMB3_00. The check that fails in smb3_validate_negotiate is the dialect verification of the negotiate info response. This is because it tries to verify against the protocol_id in the global smbdefault_values. The protocol_id in smbdefault_values is SMB3.02. In SMB2_negotiate the protocol_id in smbdefault_values isn't updated, it is global so it probably shouldn't be, but server->dialect is. This patch changes the check in smb3_validate_negotiate to use server->dialect instead of server->vals->protocol_id. The patch works with autonegotiate and when using a specific version in the vers mount option. Signed-off-by: Daniel N Pettersson Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 2cf1658d93a4e0aba89a249a70d5cdc6f72eaacb Author: Matthew Wilcox Date: Fri Dec 15 12:48:32 2017 -0800 cifs: Fix missing put_xid in cifs_file_strict_mmap [ Upstream commit f04a703c3d613845ae3141bfaf223489de8ab3eb ] If cifs_zap_mapping() returned an error, we would return without putting the xid that we got earlier. Restructure cifs_file_strict_mmap() and cifs_file_mmap() to be more similar to each other and have a single point of return that always puts the xid. Signed-off-by: Matthew Wilcox Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 1f338384b46b16f9682c8e01f8d158e90e5d6cc2 Author: Eric Biggers Date: Thu Jun 8 14:48:18 2017 +0100 KEYS: encrypted: fix buffer overread in valid_master_desc() [ Upstream commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add ] With the 'encrypted' key type it was possible for userspace to provide a data blob ending with a master key description shorter than expected, e.g. 'keyctl add encrypted desc "new x" @s'. When validating such a master key description, validate_master_desc() could read beyond the end of the buffer. Fix this by using strncmp() instead of memcmp(). [Also clean up the code to deduplicate some logic.] Cc: Mimi Zohar Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Sasha Levin commit e25ba972038116ea8a52f48e07c5e930a368fb18 Author: Jesse Chan Date: Mon Nov 20 15:56:28 2017 -0500 media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE [ Upstream commit 5331aec1bf9c9da557668174e0a4bfcee39f1121 ] This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/soc_camera/soc_scale_crop.o see include/linux/module.h for more information This adds the license as "GPL", which matches the header of the file. MODULE_DESCRIPTION and MODULE_AUTHOR are also added. Signed-off-by: Jesse Chan Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5e6ffd4ed60149550081a5b33ade58b9841e1b1f Author: Jason Wang Date: Thu Jan 25 22:03:52 2018 +0800 vhost_net: stop device during reset owner [ Upstream commit 4cd879515d686849eec5f718aeac62a70b067d82 ] We don't stop device before reset owner, this means we could try to serve any virtqueue kick before reset dev->worker. This will result a warn since the work was pending at llist during owner resetting. Fix this by stopping device during owner reset. Reported-by: syzbot+eb17c6162478cc50632c@syzkaller.appspotmail.com Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server") Signed-off-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d75807a4c28e72583022a8bc7460ecf63e81fc17 Author: Li RongQing Date: Fri Jan 26 16:40:41 2018 +0800 tcp: release sk_frag.page in tcp_disconnect [ Upstream commit 9b42d55a66d388e4dd5550107df051a9637564fc ] socket can be disconnected and gets transformed back to a listening socket, if sk_frag.page is not released, which will be cloned into a new socket by sk_clone_lock, but the reference count of this page is increased, lead to a use after free or double free issue Signed-off-by: Li RongQing Cc: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 55520ed07c974b27562b69786186ada2a7992808 Author: Chunhao Lin Date: Wed Jan 31 01:32:36 2018 +0800 r8169: fix RTL8168EP take too long to complete driver initialization. [ Upstream commit 086ca23d03c0d2f4088f472386778d293e15c5f6 ] Driver check the wrong register bit in rtl_ocp_tx_cond() that keep driver waiting until timeout. Fix this by waiting for the right register bit. Signed-off-by: Chunhao Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ff4a5c365d03ce6dcfce94bf2bac707e055bc705 Author: Junxiao Bi Date: Mon Jan 29 17:53:42 2018 +0800 qlcnic: fix deadlock bug [ Upstream commit 233ac3891607f501f08879134d623b303838f478 ] The following soft lockup was caught. This is a deadlock caused by recusive locking. Process kworker/u40:1:28016 was holding spin lock "mbx->queue_lock" in qlcnic_83xx_mailbox_worker(), while a softirq came in and ask the same spin lock in qlcnic_83xx_enqueue_mbx_cmd(). This lock should be hold by disable bh.. [161846.962125] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/u40:1:28016] [161846.962367] Modules linked in: tun ocfs2 xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc sunrpc 8021q mrp garp bridge stp llc bonding dm_round_robin dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 shpchp lpc_ich mfd_core ioatdma ipmi_devintf ipmi_si ipmi_msghandler sg ext4 jbd2 mbcache2 sr_mod cdrom sd_mod igb i2c_algo_bit i2c_core ahci libahci megaraid_sas ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel qla2xxx scsi_transport_fc qlcnic crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod [161846.962454] [161846.962460] CPU: 1 PID: 28016 Comm: kworker/u40:1 Not tainted 4.1.12-94.5.9.el6uek.x86_64 #2 [161846.962463] Hardware name: Oracle Corporation SUN SERVER X4-2L /ASSY,MB,X4-2L , BIOS 26050100 09/19/2017 [161846.962489] Workqueue: qlcnic_mailbox qlcnic_83xx_mailbox_worker [qlcnic] [161846.962493] task: ffff8801f2e34600 ti: ffff88004ca5c000 task.ti: ffff88004ca5c000 [161846.962496] RIP: e030:[] [] xen_hypercall_sched_op+0xa/0x20 [161846.962506] RSP: e02b:ffff880202e43388 EFLAGS: 00000206 [161846.962509] RAX: 0000000000000000 RBX: ffff8801f6996b70 RCX: ffffffff810013aa [161846.962511] RDX: ffff880202e433cc RSI: ffff880202e433b0 RDI: 0000000000000003 [161846.962513] RBP: ffff880202e433d0 R08: 0000000000000000 R09: ffff8801fe893200 [161846.962516] R10: ffff8801fe400538 R11: 0000000000000206 R12: ffff880202e4b000 [161846.962518] R13: 0000000000000050 R14: 0000000000000001 R15: 000000000000020d [161846.962528] FS: 0000000000000000(0000) GS:ffff880202e40000(0000) knlGS:ffff880202e40000 [161846.962531] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [161846.962533] CR2: 0000000002612640 CR3: 00000001bb796000 CR4: 0000000000042660 [161846.962536] Stack: [161846.962538] ffff880202e43608 0000000000000000 ffffffff813f0442 ffff880202e433b0 [161846.962543] 0000000000000000 ffff880202e433cc ffffffff00000001 0000000000000000 [161846.962547] 00000009813f03d6 ffff880202e433e0 ffffffff813f0460 ffff880202e43440 [161846.962552] Call Trace: [161846.962555] [161846.962565] [] ? xen_poll_irq_timeout+0x42/0x50 [161846.962570] [] xen_poll_irq+0x10/0x20 [161846.962578] [] xen_lock_spinning+0xe2/0x110 [161846.962583] [] __raw_callee_save_xen_lock_spinning+0x11/0x20 [161846.962592] [] ? _raw_spin_lock+0x57/0x80 [161846.962609] [] qlcnic_83xx_enqueue_mbx_cmd+0x7c/0xe0 [qlcnic] [161846.962623] [] qlcnic_83xx_issue_cmd+0x58/0x210 [qlcnic] [161846.962636] [] qlcnic_83xx_sre_macaddr_change+0x162/0x1d0 [qlcnic] [161846.962649] [] qlcnic_83xx_change_l2_filter+0x2b/0x30 [qlcnic] [161846.962657] [] ? __skb_flow_dissect+0x18b/0x650 [161846.962670] [] qlcnic_send_filter+0x205/0x250 [qlcnic] [161846.962682] [] qlcnic_xmit_frame+0x547/0x7b0 [qlcnic] [161846.962691] [] xmit_one+0x82/0x1a0 [161846.962696] [] dev_hard_start_xmit+0x50/0xa0 [161846.962701] [] sch_direct_xmit+0x112/0x220 [161846.962706] [] __dev_queue_xmit+0x1df/0x5e0 [161846.962710] [] dev_queue_xmit_sk+0x13/0x20 [161846.962721] [] bond_dev_queue_xmit+0x35/0x80 [bonding] [161846.962729] [] __bond_start_xmit+0x1cb/0x210 [bonding] [161846.962736] [] bond_start_xmit+0x31/0x60 [bonding] [161846.962740] [] xmit_one+0x82/0x1a0 [161846.962745] [] dev_hard_start_xmit+0x50/0xa0 [161846.962749] [] __dev_queue_xmit+0x4ee/0x5e0 [161846.962754] [] dev_queue_xmit_sk+0x13/0x20 [161846.962760] [] vlan_dev_hard_start_xmit+0xb2/0x150 [8021q] [161846.962764] [] xmit_one+0x82/0x1a0 [161846.962769] [] dev_hard_start_xmit+0x50/0xa0 [161846.962773] [] __dev_queue_xmit+0x4ee/0x5e0 [161846.962777] [] dev_queue_xmit_sk+0x13/0x20 [161846.962789] [] br_dev_queue_push_xmit+0x54/0xa0 [bridge] [161846.962797] [] br_forward_finish+0x2f/0x90 [bridge] [161846.962807] [] ? ttwu_do_wakeup+0x1d/0x100 [161846.962811] [] ? __alloc_skb+0x8b/0x1f0 [161846.962818] [] __br_forward+0x8d/0x120 [bridge] [161846.962822] [] ? __kmalloc_reserve+0x3b/0xa0 [161846.962829] [] ? update_rq_runnable_avg+0xee/0x230 [161846.962836] [] br_forward+0x96/0xb0 [bridge] [161846.962845] [] br_handle_frame_finish+0x1ae/0x420 [bridge] [161846.962853] [] br_handle_frame+0x17f/0x260 [bridge] [161846.962862] [] ? br_handle_frame_finish+0x420/0x420 [bridge] [161846.962867] [] __netif_receive_skb_core+0x1f7/0x870 [161846.962872] [] __netif_receive_skb+0x22/0x70 [161846.962877] [] netif_receive_skb_internal+0x23/0x90 [161846.962884] [] ? xenvif_idx_release+0xea/0x100 [xen_netback] [161846.962889] [] ? _raw_spin_unlock_irqrestore+0x20/0x50 [161846.962893] [] netif_receive_skb_sk+0x24/0x90 [161846.962899] [] xenvif_tx_submit+0x2ca/0x3f0 [xen_netback] [161846.962906] [] xenvif_tx_action+0x9c/0xd0 [xen_netback] [161846.962915] [] xenvif_poll+0x35/0x70 [xen_netback] [161846.962920] [] napi_poll+0xcb/0x1e0 [161846.962925] [] net_rx_action+0x90/0x1c0 [161846.962931] [] __do_softirq+0x10a/0x350 [161846.962938] [] irq_exit+0x125/0x130 [161846.962943] [] xen_evtchn_do_upcall+0x39/0x50 [161846.962950] [] xen_do_hypervisor_callback+0x1e/0x40 [161846.962952] [161846.962959] [] ? _raw_spin_lock+0x4a/0x80 [161846.962964] [] ? _raw_spin_lock_irqsave+0x1e/0xa0 [161846.962978] [] ? qlcnic_83xx_mailbox_worker+0xb9/0x2a0 [qlcnic] [161846.962991] [] ? process_one_work+0x151/0x4b0 [161846.962995] [] ? check_events+0x12/0x20 [161846.963001] [] ? worker_thread+0x120/0x480 [161846.963005] [] ? __schedule+0x30b/0x890 [161846.963010] [] ? process_one_work+0x4b0/0x4b0 [161846.963015] [] ? process_one_work+0x4b0/0x4b0 [161846.963021] [] ? kthread+0xce/0xf0 [161846.963025] [] ? kthread_freezable_should_stop+0x70/0x70 [161846.963031] [] ? ret_from_fork+0x42/0x70 [161846.963035] [] ? kthread_freezable_should_stop+0x70/0x70 [161846.963037] Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc Signed-off-by: Junxiao Bi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d8037dab441921d68ffd53a340bbdf4c33e24325 Author: Eric Dumazet Date: Thu Feb 1 10:26:57 2018 -0800 net: igmp: add a missing rcu locking section [ Upstream commit e7aadb27a5415e8125834b84a74477bfbee4eff5 ] Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ #200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ #200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b00290 ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26f288c21b60120f76882e1106ab80053a2516cc Author: Nikolay Aleksandrov Date: Wed Jan 31 16:29:30 2018 +0200 ip6mr: fix stale iterator [ Upstream commit 4adfa79fc254efb7b0eb3cd58f62c2c3f805f1ba ] When we dump the ip6mr mfc entries via proc, we initialize an iterator with the table to dump but we don't clear the cache pointer which might be initialized from a prior read on the same descriptor that ended. This can result in lock imbalance (an unnecessary unlock) leading to other crashes and hangs. Clear the cache pointer like ipmr does to fix the issue. Thanks for the reliable reproducer. Here's syzbot's trace: WARNING: bad unlock balance detected! 4.15.0-rc3+ #128 Not tainted syzkaller971460/3195 is trying to release lock (mrt_lock) at: [<000000006898068d>] ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553 but there are no more locks to release! other info that might help us debug this: 1 lock held by syzkaller971460/3195: #0: (&p->lock){+.+.}, at: [<00000000744a6565>] seq_read+0xd5/0x13d0 fs/seq_file.c:165 stack backtrace: CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_unlock_imbalance_bug+0x12f/0x140 kernel/locking/lockdep.c:3561 __lock_release kernel/locking/lockdep.c:3775 [inline] lock_release+0x5f9/0xda0 kernel/locking/lockdep.c:4023 __raw_read_unlock include/linux/rwlock_api_smp.h:225 [inline] _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255 ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553 traverse+0x3bc/0xa00 fs/seq_file.c:135 seq_read+0x96a/0x13d0 fs/seq_file.c:189 proc_reg_read+0xef/0x170 fs/proc/inode.c:217 do_loop_readv_writev fs/read_write.c:673 [inline] do_iter_read+0x3db/0x5b0 fs/read_write.c:897 compat_readv+0x1bf/0x270 fs/read_write.c:1140 do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189 C_SYSC_preadv fs/read_write.c:1209 [inline] compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203 do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 RIP: 0023:0xf7f73c79 RSP: 002b:00000000e574a15c EFLAGS: 00000292 ORIG_RAX: 000000000000014d RAX: ffffffffffffffda RBX: 000000000000000f RCX: 0000000020a3afb0 RDX: 0000000000000001 RSI: 0000000000000067 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 BUG: sleeping function called from invalid context at lib/usercopy.c:25 in_atomic(): 1, irqs_disabled(): 0, pid: 3195, name: syzkaller971460 INFO: lockdep is turned off. CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 ___might_sleep+0x2b2/0x470 kernel/sched/core.c:6060 __might_sleep+0x95/0x190 kernel/sched/core.c:6013 __might_fault+0xab/0x1d0 mm/memory.c:4525 _copy_to_user+0x2c/0xc0 lib/usercopy.c:25 copy_to_user include/linux/uaccess.h:155 [inline] seq_read+0xcb4/0x13d0 fs/seq_file.c:279 proc_reg_read+0xef/0x170 fs/proc/inode.c:217 do_loop_readv_writev fs/read_write.c:673 [inline] do_iter_read+0x3db/0x5b0 fs/read_write.c:897 compat_readv+0x1bf/0x270 fs/read_write.c:1140 do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189 C_SYSC_preadv fs/read_write.c:1209 [inline] compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203 do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 RIP: 0023:0xf7f73c79 RSP: 002b:00000000e574a15c EFLAGS: 00000292 ORIG_RAX: 000000000000014d RAX: ffffffffffffffda RBX: 000000000000000f RCX: 0000000020a3afb0 RDX: 0000000000000001 RSI: 0000000000000067 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 WARNING: CPU: 1 PID: 3195 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0 lib/usercopy.c:26 Reported-by: syzbot Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 925843eaa5e3cca8f86f8999e50e48e5b3865240 Author: Laurent Pinchart Date: Mon Jul 10 23:46:39 2017 +0300 drm: rcar-du: Use the VBK interrupt for vblank events [ Upstream commit cbbb90b0c084d7dfb2ed8e3fecf8df200fbdd2a0 ] When implementing support for interlaced modes, the driver switched from reporting vblank events on the vertical blanking (VBK) interrupt to the frame end interrupt (FRM). This incorrectly divided the reported refresh rate by two. Fix it by moving back to the VBK interrupt. Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes") Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Sasha Levin commit 8533b8d52b6ac3a670d1e0d7130dfeb6a82b2d23 Author: Jesse Chan Date: Sun Nov 19 23:45:49 2017 -0800 ASoC: pcm512x: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE [ Upstream commit 0cab20cec0b663b7be8e2be5998d5a4113647f86 ] This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/codecs/snd-soc-pcm512x-spi.o see include/linux/module.h for more information This adds the license as "GPL v2", which matches the header of the file. MODULE_DESCRIPTION and MODULE_AUTHOR are also added. Signed-off-by: Jesse Chan Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 084bf588b312e95d554f90c78d78131fe042e0cd Author: Michael Ellerman Date: Tue Jan 16 22:17:18 2018 +1100 powerpc/64s: Allow control of RFI flush via debugfs [ Upstream commit 236003e6b5443c45c18e613d2b0d776a9f87540e ] Expose the state of the RFI flush (enabled/disabled) via debugfs, and allow it to be enabled/disabled at runtime. eg: $ cat /sys/kernel/debug/powerpc/rfi_flush 1 $ echo 0 > /sys/kernel/debug/powerpc/rfi_flush $ cat /sys/kernel/debug/powerpc/rfi_flush 0 Signed-off-by: Michael Ellerman Reviewed-by: Nicholas Piggin Signed-off-by: Sasha Levin commit 3a5acdf27947b07caa6a11fb95614b9b24184faa Author: Michael Ellerman Date: Tue Jan 16 21:20:05 2018 +1100 powerpc/64s: Wire up cpu_show_meltdown() [ Upstream commit fd6e440f20b1a4304553775fc55938848ff617c9 ] The recent commit 87590ce6e373 ("sysfs/cpu: Add vulnerability folder") added a generic folder and set of files for reporting information on CPU vulnerabilities. One of those was for meltdown: /sys/devices/system/cpu/vulnerabilities/meltdown This commit wires up that file for 64-bit Book3S powerpc. For now we default to "Vulnerable" unless the RFI flush is enabled. That may not actually be true on all hardware, further patches will refine the reporting based on the CPU/platform etc. But for now we default to being pessimists. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit bc323e33f802d4cf954dff26a1020ab9e661514c Author: Michael Neuling Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/pseries: Query hypervisor for RFI flush settings [ Upstream commit 8989d56878a7735dfdb234707a2fee6faf631085 ] A new hypervisor call is available which tells the guest settings related to the RFI flush. Use it to query the appropriate flush instruction(s), and whether the flush is required. Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 252e4540d078d5a8dcb0eb881ca94d9079be3dda Author: Michael Ellerman Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/64s: Support disabling RFI flush with no_rfi_flush and nopti [ Upstream commit bc9c9304a45480797e13a8e1df96ffcf44fb62fe ] Because there may be some performance overhead of the RFI flush, add kernel command line options to disable it. We add a sensibly named 'no_rfi_flush' option, but we also hijack the x86 option 'nopti'. The RFI flush is not the same as KPTI, but if we see 'nopti' we can guess that the user is trying to avoid any overhead of Meltdown mitigations, and it means we don't have to educate every one about a different command line option. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 1fbfa79b69f0fa003bd6135a116738edc7cc8fc8 Author: Michael Ellerman Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/64s: Add support for RFI flush of L1-D cache [ Upstream commit aa8a5e0062ac940f7659394f4817c948dc8c0667 ] On some CPUs we can prevent the Meltdown vulnerability by flushing the L1-D cache on exit from kernel to user mode, and from hypervisor to guest. This is known to be the case on at least Power7, Power8 and Power9. At this time we do not know the status of the vulnerability on other CPUs such as the 970 (Apple G5), pasemi CPUs (AmigaOne X1000) or Freescale CPUs. As more information comes to light we can enable this, or other mechanisms on those CPUs. The vulnerability occurs when the load of an architecturally inaccessible memory region (eg. userspace load of kernel memory) is speculatively executed to the point where its result can influence the address of a subsequent speculatively executed load. In order for that to happen, the first load must hit in the L1, because before the load is sent to the L2 the permission check is performed. Therefore if no kernel addresses hit in the L1 the vulnerability can not occur. We can ensure that is the case by flushing the L1 whenever we return to userspace. Similarly for hypervisor vs guest. In order to flush the L1-D cache on exit, we add a section of nops at each (h)rfi location that returns to a lower privileged context, and patch that with some sequence. Newer firmwares are able to advertise to us that there is a special nop instruction that flushes the L1-D. If we do not see that advertised, we fall back to doing a displacement flush in software. For guest kernels we support migration between some CPU versions, and different CPUs may use different flush instructions. So that we are prepared to migrate to a machine with a different flush instruction activated, we may have to patch more than one flush instruction at boot if the hypervisor tells us to. In the end this patch is mostly the work of Nicholas Piggin and Michael Ellerman. However a cast of thousands contributed to analysis of the issue, earlier versions of the patch, back ports testing etc. Many thanks to all of them. Tested-by: Jon Masters Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 6b07d1c79f533da5d485e7909f0b308c9f836004 Author: Nicholas Piggin Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/64s: Convert slb_miss_common to use RFI_TO_USER/KERNEL [ Upstream commit c7305645eb0c1621351cfc104038831ae87c0053 ] In the SLB miss handler we may be returning to user or kernel. We need to add a check early on and save the result in the cr4 register, and then we bifurcate the return path based on that. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit bd700e0f65a5cc06bb91fab5ee0a49637a667368 Author: Nicholas Piggin Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL [ Upstream commit b8e90cb7bc04a509e821e82ab6ed7a8ef11ba333 ] In the syscall exit path we may be returning to user or kernel context. We already have a test for that, because we conditionally restore r13. So use that existing test and branch, and bifurcate the return based on that. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 29ef0467e5b690479c578c8f02b39dbe4ba66a6c Author: Nicholas Piggin Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/64: Convert fast_exception_return to use RFI_TO_USER/KERNEL [ Upstream commit a08f828cf47e6c605af21d2cdec68f84e799c318 ] Similar to the syscall return path, in fast_exception_return we may be returning to user or kernel context. We already have a test for that, because we conditionally restore r13. So use that existing test and branch, and bifurcate the return based on that. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b7b61b39d55f0e79ff09a948bab0f81c4e2bd10e Author: Nicholas Piggin Date: Wed Jan 10 03:07:15 2018 +1100 powerpc/64: Add macros for annotating the destination of rfid/hrfid [ Upstream commit 50e51c13b3822d14ff6df4279423e4b7b2269bc3 ] The rfid/hrfid ((Hypervisor) Return From Interrupt) instruction is used for switching from the kernel to userspace, and from the hypervisor to the guest kernel. However it can and is also used for other transitions, eg. from real mode kernel code to virtual mode kernel code, and it's not always clear from the code what the destination context is. To make it clearer when reading the code, add macros which encode the expected destination context. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 2e7059a5873845bc6054f0eb14682c576766d273 Author: Michael Neuling Date: Tue Jan 9 03:52:05 2018 +1100 powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper [ Upstream commit 191eccb1580939fb0d47deb405b82a85b0379070 ] A new hypervisor call has been defined to communicate various characteristics of the CPU to guests. Add definitions for the hcall number, flags and a wrapper function. Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit e23317f22c8c6b4ec22a718c41d6852154620d5e Author: Alan Modra Date: Fri Jan 15 20:52:22 2016 +1100 powerpc: Simplify module TOC handling [ Upstream commit c153693d7eb9eeb28478aa2deaaf0b4e7b5ff5e9 ] PowerPC64 uses the symbol .TOC. much as other targets use _GLOBAL_OFFSET_TABLE_. It identifies the value of the GOT pointer (or in powerpc parlance, the TOC pointer). Global offset tables are generally local to an executable or shared library, or in the kernel, module. Thus it does not make sense for a module to resolve a relocation against .TOC. to the kernel's .TOC. value. A module has its own .TOC., and indeed the powerpc64 module relocation processing ignores the kernel value of .TOC. and instead calculates a module-local value. This patch removes code involved in exporting the kernel .TOC., tweaks modpost to ignore an undefined .TOC., and the module loader to twiddle the section symbol so that .TOC. isn't seen as undefined. Note that if the kernel was compiled with -msingle-pic-base then ELFv2 would not have function global entry code setting up r2. In that case the module call stubs would need to be modified to set up r2 using the kernel .TOC. value, requiring some of this code to be reinstated. mpe: Furthermore a change in binutils master (not yet released) causes the current way we handle the TOC to no longer work when building with MODVERSIONS=y and RELOCATABLE=n. The symptom is that modules can not be loaded due to there being no version found for TOC. Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Alan Modra Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d9ee32f1258dbbed90caf3cbb7194dbfe43f7086 Author: Benjamin Herrenschmidt Date: Wed Aug 16 16:01:14 2017 +1000 powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC [ Upstream commit 5a69aec945d27e78abac9fd032533d3aaebf7c1e ] VSX uses a combination of the old vector registers, the old FP registers and new "second halves" of the FP registers. Thus when we need to see the VSX state in the thread struct (flush_vsx_to_thread()) or when we'll use the VSX in the kernel (enable_kernel_vsx()) we need to ensure they are all flushed into the thread struct if either of them is individually enabled. Unfortunately we only tested if the whole VSX was enabled, not if they were individually enabled. Fixes: 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx() routine available") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d57905105d12319b948de00fb751f2a595398b72 Author: Oliver O'Halloran Date: Mon Apr 3 13:25:12 2017 +1000 powerpc/64: Fix flush_(d|i)cache_range() called from modules [ Upstream commit 8f5f525d5b83f7d76a6baf9c4e94d4bf312ea7f6 ] When the kernel is compiled to use 64bit ABIv2 the _GLOBAL() macro does not include a global entry point. A function's global entry point is used when the function is called from a different TOC context and in the kernel this typically means a call from a module into the vmlinux (or vice-versa). There are a few exported asm functions declared with _GLOBAL() and calling them from a module will likely crash the kernel since any TOC relative load will yield garbage. flush_icache_range() and flush_dcache_range() are both exported to modules, and use the TOC, so must use _GLOBAL_TOC(). Fixes: 721aeaa9fdf3 ("powerpc: Build little endian ppc64 kernel with ABIv2") Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Oliver O'Halloran Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 7b89769709d5cb0ae2a7c4815afaa34f94ff5b4b Author: Naveen N. Rao Date: Wed Jun 22 21:55:01 2016 +0530 powerpc/bpf/jit: Disable classic BPF JIT on ppc64le [ Upstream commit 844e3be47693f92a108cb1fb3b0606bf25e9c7a6 ] Classic BPF JIT was never ported completely to work on little endian powerpc. However, it can be enabled and will crash the system when used. As such, disable use of BPF JIT on ppc64le. Fixes: 7c105b63bd98 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.") Reported-by: Thadeu Lima de Souza Cascardo Signed-off-by: Naveen N. Rao Acked-by: Thadeu Lima de Souza Cascardo Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b6aaaaed67b170a9841f0f598cd45ccbfe76e15e Author: Stefan Agner Date: Sun Jan 7 15:05:49 2018 +0100 spi: imx: do not access registers while clocks disabled [ Upstream commit d593574aff0ab846136190b1729c151c736727ec ] Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by: Stefan Agner Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2c0ae3574e12f205ffe0d85cd0b2592c09124c7a Author: Oliver Neukum Date: Thu Jan 11 13:10:16 2018 +0100 usb: uas: unconditionally bring back host after reset [ Upstream commit cbeef22fd611c4f47c494b821b2b105b8af970bb ] Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then hang in the scsi_remove_host call. This is esp. bad because our disconnect handler hanging for ever also stops the USB subsys from enumerating any new USB devices, causes commands like lsusb to hang, etc. In practice this happens when unplugging some uas devices because the hub code may see the device as needing a warm-reset and calls usb_reset_device before seeing the disconnect. In this case uas_configure_endpoints fails with -ENODEV. We do not want to print an error for this, so this commit also silences the shost_printk for -ENODEV. ENDQUOTE However, if we do that we better drop any unconditional execution and report to the SCSI subsystem that we have undergone a reset but we are not operational now. Signed-off-by: Oliver Neukum Reported-by: Hans de Goede CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1f4ac76de1ff4b79c6ef51a1c1d909c54289ff61 Author: Hemant Kumar Date: Tue Jan 9 12:30:53 2018 +0530 usb: f_fs: Prevent gadget unbind if it is already unbound [ Upstream commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a ] Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi Cc: Greg KH Cc: Michal Nazarewicz Cc: John Stultz Cc: Dmitry Shmidt Cc: Badhri Cc: Android Kernel Team Cc: stable@vger.kernel.org Signed-off-by: Hemant Kumar [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by: Amit Pundir Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7b22c08aeb9df42d39f2ad22547bfcd4d3de438e Author: Johan Hovold Date: Thu Jan 18 14:46:41 2018 +1100 USB: serial: simple: add Motorola Tetra driver [ Upstream commit 46fe895e22ab3845515ec06b01eaf1282b342e29 ] Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI devices. D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0cad ProdID=9011 Rev=24.16 S: Manufacturer=Motorola Solutions Inc. S: Product=Motorola Solutions TETRA PEI interface C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Note that these devices do not support the CDC SET_CONTROL_LINE_STATE request (for any interface). Reported-by: Max Schulze Tested-by: Max Schulze Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 94dd5ae2fe3f2c08997079c30745f8ac3444dede Author: Shuah Khan Date: Wed Jan 17 12:08:03 2018 -0700 usbip: list: don't list devices attached to vhci_hcd [ Upstream commit ef824501f50846589f02173d73ce3fe6021a9d2a ] usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Cc: stable@vger.kernel.org Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 55f3c3e2207ba4cc42f735ed0fce8b7cede1d416 Author: Shuah Khan Date: Wed Jan 17 12:07:30 2018 -0700 usbip: prevent bind loops on devices attached to vhci_hcd [ Upstream commit ef54cf0c600fb8f5737fb001a9e357edda1a1de8 ] usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Cc: stable@vger.kernel.org Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a93ca03e9b5aae059993a5a596523977a91b9f6a Author: Jia-Ju Bai Date: Wed Dec 13 20:34:36 2017 +0800 USB: serial: io_edgeport: fix possible sleep-in-atomic [ Upstream commit c7b8f77872c73f69a16528a9eb87afefcccdc18b ] According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 2611c756249f74440c4757c74bad9c37cfbe4eff Author: Oliver Neukum Date: Thu Jan 18 12:13:45 2018 +0100 CDC-ACM: apply quirk for card reader [ Upstream commit df1cc78a52491f71d8170d513d0f6f114faa1bda ] This devices drops random bytes from messages if you talk to it too fast. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 335a5fd23ff8e843fcc20709d7b492a51ecfbd57 Author: Hans de Goede Date: Sun Jan 14 16:09:00 2018 +0100 USB: cdc-acm: Do not log urb submission errors on disconnect [ Upstream commit f0386c083c2ce85284dc0b419d7b89c8e567c09f ] When disconnected sometimes the cdc-acm driver logs errors like these: [20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19 [20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19 [20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19 [20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19 [20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19 [20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19 [20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19 Silence these by not logging errors when the result is -ENODEV. Signed-off-by: Hans de Goede Acked-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 513e0d790d71dd3fdb4918f204e83f97fc1f08ef Author: Greg Kroah-Hartman Date: Thu Jan 25 09:48:55 2018 +0100 USB: serial: pl2303: new device id for Chilitag [ Upstream commit d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 ] This adds a new device id for Chilitag devices to the pl2303 driver. Reported-by: "Chu.Mike [朱堅宜]" Cc: stable Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3eb9d1673a84274f39e2ab1ef5fd81e399a34ab8 Author: OKAMOTO Yoshiaki Date: Tue Jan 16 09:51:17 2018 +0000 usb: option: Add support for FS040U modem [ Upstream commit 69341bd15018da0a662847e210f9b2380c71e623 ] FS040U modem is manufactured by omega, and sold by Fujisoft. This patch adds ID of the modem to use option1 driver. Interface 3 is used as qmi_wwan, so the interface is ignored. Signed-off-by: Yoshiaki Okamoto Signed-off-by: Hiroyuki Yamamoto Cc: stable Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 280cb150d601a3a5ff59f257e322a4331b2a473a Author: Larry Finger Date: Sat Nov 25 13:32:38 2017 -0600 staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID [ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 595f2e67f21134b1ccfa251b543fa4f3c364323c Author: Colin Ian King Date: Tue Nov 14 16:18:28 2017 +0000 usb: gadget: don't dereference g until after it has been null checked [ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by: Colin Ian King Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 11bb67d654a23e27910544a44412b091460d2fff Author: Icenowy Zheng Date: Sun Apr 16 02:51:16 2017 -0400 media: usbtv: add a new usbid [ Upstream commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0 ] A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by: Icenowy Zheng Acked-by: Lubomir Rintel Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3be06f36532514c3b87f48ac60e02f910b23b654 Author: Gustavo A. R. Silva Date: Mon Nov 20 08:12:29 2017 -0600 scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg [ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa4976130934 ("ufs: Add regulator enable support") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Subhash Jadavani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 31f787d798a7521e07b1f577f8537871cc9bf848 Author: Darrick J. Wong Date: Mon Nov 27 09:50:17 2017 -0800 xfs: ubsan fixes [ Upstream commit 22a6c83777ac7c17d6c63891beeeac24cf5da450 ] Fix some complaints from the UBSAN about signed integer addition overflows. Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Signed-off-by: Sasha Levin commit 23050bdab8201c47823c5243b7f014cd70848cc0 Author: Christophe JAILLET Date: Sun Sep 24 08:01:03 2017 +0200 drm/omap: Fix error handling path in 'omap_dmm_probe()' [ Upstream commit 8677b1ac2db021ab30bb1fa34f1e56ebe0051ec3 ] If we don't find a matching device node, we must free the memory allocated in 'omap_dmm' a few lines above. Fixes: 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5") Signed-off-by: Christophe JAILLET Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 1fd0b799beae614c77672b1a5e9d4dbfd6f5f6ed Author: Trond Myklebust Date: Fri Nov 24 12:00:24 2017 -0500 SUNRPC: Allow connect to return EHOSTUNREACH [ Upstream commit 4ba161a793d5f43757c35feff258d9f20a082940 ] Reported-by: Dmitry Vyukov Signed-off-by: Trond Myklebust Tested-by: Dmitry Vyukov Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 25598d24b450a3974e9cbdc1de09e40a6c204faa Author: Tetsuo Handa Date: Wed Nov 29 22:34:50 2017 +0900 quota: Check for register_shrinker() failure. [ Upstream commit 88bc0ede8d35edc969350852894dc864a2dc1859 ] register_shrinker() might return -ENOMEM error since Linux 3.12. Call panic() as with other failure checks in this function if register_shrinker() failed. Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work") Signed-off-by: Tetsuo Handa Cc: Jan Kara Cc: Michal Hocko Reviewed-by: Michal Hocko Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 858635008e6960a64ee16cc077e2675bde13bd30 Author: Geert Uytterhoeven Date: Wed Nov 29 11:01:09 2017 +0100 net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit [ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ] On 64-bit (e.g. powerpc64/allmodconfig): drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer. Note that several other fields in struct cdmac_bd are also too small to hold physical addresses on 64-bit platforms. Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6e464dc08b6573611c6034956c486098b13b22e Author: Robert Lippert Date: Mon Nov 27 15:51:55 2017 -0800 hwmon: (pmbus) Use 64bit math for DIRECT format values [ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ] Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78728e ("hwmon: PMBus device driver") Signed-off-by: Robert Lippert Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2ca600b32b561bf458173d28ef6fe2ff9e99c198 Author: Andrew Elble Date: Thu Nov 9 13:41:10 2017 -0500 nfsd: check for use of the closed special stateid [ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ] Prevent the use of the closed (invalid) special stateid by clients. Signed-off-by: Andrew Elble Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 7207bd5112750712b182253b4cd97528e1ef8fa9 Author: Vasily Averin Date: Mon Nov 6 16:22:48 2017 +0300 grace: replace BUG_ON by WARN_ONCE in exit_net hook [ Upstream commit b872285751c1af010e12d02bce7069e2061a58ca ] Signed-off-by: Vasily Averin Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 049f56a34feb564c464b32518d16a1cfee270782 Author: Trond Myklebust Date: Fri Nov 3 08:00:12 2017 -0400 nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) [ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ] Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 985b1521bf20389f8200f07911bdcdc6a414904a Author: Eduardo Otubo Date: Thu Nov 23 15:18:35 2017 +0100 xen-netfront: remove warning when unloading module [ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ] v2: * Replace busy wait with wait_event()/wake_up_all() * Cannot garantee that at the time xennet_remove is called, the xen_netback state will not be XenbusStateClosed, so added a condition for that * There's a small chance for the xen_netback state is XenbusStateUnknown by the time the xen_netfront switches to Closed, so added a condition for that. When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfront revokes the g.e.'s netback didn't have enough time to free all of them, hence displaying the warnings on dmesg. The trick here is to make netfront to wait until netback frees all the g.e.'s and only then continue to cleanup for the module removal, and this is done by manipulating both device states. Signed-off-by: Eduardo Otubo Acked-by: Juergen Gross Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0b99bae468bb1b1a7246bca1762dbd36e7cd9096 Author: Wanpeng Li Date: Mon Nov 20 14:52:21 2017 -0800 KVM: VMX: Fix rflags cache during vCPU reset [ Upstream commit c37c28730bb031cc8a44a130c2555c0f3efbe2d0 ] Reported by syzkaller: *** Guest State *** CR0: actual=0x0000000080010031, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002061, shadow=0x0000000000000000, gh_mask=ffffffffffffe8f1 CR3 = 0x000000002081e000 RSP = 0x000000000000fffa RIP = 0x0000000000000000 RFLAGS=0x00023000 DR7 = 0x00000000000000 ^^^^^^^^^^ ------------[ cut here ]------------ WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] CPU: 6 PID: 24431 Comm: reprotest Tainted: G W OE 4.14.0+ #26 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] RSP: 0018:ffff880291d179e0 EFLAGS: 00010202 Call Trace: kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The failed vmentry is triggered by the following beautified testcase: #include #include #include #include #include #include #include long r[5]; int main() { struct kvm_debugregs dr = { 0 }; r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_guest_debug debug = { .control = 0xf0403, .arch = { .debugreg[6] = 0x2, .debugreg[7] = 0x2 } }; ioctl(r[4], KVM_SET_GUEST_DEBUG, &debug); ioctl(r[4], KVM_RUN, 0); } which testcase tries to setup the processor specific debug registers and configure vCPU for handling guest debug events through KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit if single step is needed. All regs' caches are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is not reset during vCPU reset. The function vmx_get_rflags() returns an unreset rflags cache value since the cache is marked avail, it is 0 after boot. Vmentry fails if the rflags reserved bit 1 is 0. This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its cache to 0x2 during vCPU reset. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Reviewed-by: David Hildenbrand Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Nadav Amit Cc: Dmitry Vyukov Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 3aa0bdd24fb37ae6d18bd993d7430c868bb60ba0 Author: Josef Bacik Date: Wed Nov 15 16:20:52 2017 -0500 btrfs: fix deadlock when writing out space cache [ Upstream commit b77000ed558daa3bef0899d29bf171b8c9b5e6a8 ] If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity ensues. Signed-off-by: Josef Bacik Reviewed-by: Omar Sandoval Reviewed-by: Liu Bo Reviewed-by: David Sterba [ add label and use existing unlocking code ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e1caa64a6ef0a060f409e135572ca614e9585233 Author: Chun-Yeow Yeoh Date: Tue Nov 14 23:20:05 2017 +0800 mac80211: fix the update of path metric for RANN frame [ Upstream commit fbbdad5edf0bb59786a51b94a9d006bc8c2da9a2 ] The previous path metric update from RANN frame has not considered the own link metric toward the transmitting mesh STA. Fix this. Reported-by: Michael65535 Signed-off-by: Chun-Yeow Yeoh Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3cb33cd841c92ff6ba442f7f15f94b89ba9ce76b Author: zhangliping Date: Sat Nov 25 22:02:12 2017 +0800 openvswitch: fix the incorrect flow action alloc size [ Upstream commit 67c8d22a73128ff910e2287567132530abcf5b71 ] If we want to add a datapath flow, which has more than 500 vxlan outputs' action, we will get the following error reports: openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Actions may not be safe on all matching packets ... ... It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but this is not the root cause. For example, for a vxlan output action, we need about 60 bytes for the nlattr, but after it is converted to the flow action, it only occupies 24 bytes. This means that we can still support more than 1000 vxlan output actions for a single datapath flow under the the current 32k max limitation. So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we shouldn't report EINVAL and keep it move on, as the judgement can be done by the reserve_sfa_size. Signed-off-by: zhangliping Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 94655d5eade15ba1ac1454b4f7afeb433c740aa0 Author: Felix Kuehling Date: Wed Nov 1 19:21:57 2017 -0400 drm/amdkfd: Fix SDMA oversubsription handling [ Upstream commit 8c946b8988acec785bcf67088b6bd0747f36d2d3 ] SDMA only supports a fixed number of queues. HWS cannot handle oversubscription. Signed-off-by: shaoyun liu Signed-off-by: Felix Kuehling Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 47e6d11a36fd2f13dad033cdf02d7a41bde4ace3 Author: Michael Lyle Date: Fri Nov 24 15:14:27 2017 -0800 bcache: check return value of register_shrinker [ Upstream commit 6c4ca1e36cdc1a0a7a84797804b87920ccbebf51 ] register_shrinker is now __must_check, so check it to kill a warning. Caller of bch_btree_cache_alloc in super.c appropriately checks return value so this is fully plumbed through. This V2 fixes checkpatch warnings and improves the commit description, as I was too hasty getting the previous version out. Signed-off-by: Michael Lyle Reviewed-by: Vojtech Pavlik Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 267c729fcc3f494e90d99425bf9ffe379724c667 Author: James Hogan Date: Wed Nov 15 21:17:55 2017 +0000 cpufreq: Add Loongson machine dependencies [ Upstream commit 0d307935fefa6389eb726c6362351c162c949101 ] The MIPS loongson cpufreq drivers don't build unless configured for the correct machine type, due to dependency on machine specific architecture headers and symbols in machine specific platform code. More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU, neither of which is defined in asm/mach-loongson32/regs-clk.h unless CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references loongson2_clockmod_table[], which is only defined in arch/mips/loongson64/lemote-2f/clock.c, i.e. when CONFIG_LEMOTE_MACH2F=y. Add these dependencies to Kconfig to avoid randconfig / allyesconfig build failures (e.g. when based on BMIPS which also has a cpufreq driver). Signed-off-by: James Hogan Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3965926aa1287b361d2149fdc52c586496e0d11a Author: Wanpeng Li Date: Sun Nov 5 16:54:47 2017 -0800 KVM: X86: Fix operand/address-size during instruction decoding [ Upstream commit 3853be2603191829b442b64dac6ae8ba0c027bf9 ] Pedro reported: During tests that we conducted on KVM, we noticed that executing a "PUSH %ES" instruction under KVM produces different results on both memory and the SP register depending on whether EPT support is enabled. With EPT the SP is reduced by 4 bytes (and the written value is 0-padded) but without EPT support it is only reduced by 2 bytes. The difference can be observed when the CS.DB field is 1 (32-bit) but not when it's 0 (16-bit). The internal segment descriptor cache exist even in real/vm8096 mode. The CS.D also should be respected instead of just default operand/address-size/66H prefix/67H prefix during instruction decoding. This patch fixes it by also adjusting operand/address-size according to CS.D. Reported-by: Pedro Fonseca Tested-by: Pedro Fonseca Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Nadav Amit Cc: Pedro Fonseca Signed-off-by: Wanpeng Li Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 6f7811217e59d0611f9f84c1826bb7e2517ea4c6 Author: Liran Alon Date: Sun Nov 5 16:56:34 2017 +0200 KVM: x86: Don't re-execute instruction when not passing CR2 value [ Upstream commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 ] In case of instruction-decode failure or emulation failure, x86_emulate_instruction() will call reexecute_instruction() which will attempt to use the cr2 value passed to x86_emulate_instruction(). However, when x86_emulate_instruction() is called from emulate_instruction(), cr2 is not passed (passed as 0) and therefore it doesn't make sense to execute reexecute_instruction() logic at all. Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction") Signed-off-by: Liran Alon Reviewed-by: Nikita Leshenko Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Wanpeng Li Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 8af9935bd7e1ee19a46f0c9d9b5645d3b9ebef6d Author: Liran Alon Date: Sun Nov 5 16:56:33 2017 +0200 KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure [ Upstream commit 1f4dcb3b213235e642088709a1c54964d23365e9 ] On this case, handle_emulation_failure() fills kvm_run with internal-error information which it expects to be delivered to user-mode for further processing. However, the code reports a wrong return-value which makes KVM to never return to user-mode on this scenario. Fixes: 6d77dbfc88e3 ("KVM: inject #UD if instruction emulation fails and exit to userspace") Signed-off-by: Liran Alon Reviewed-by: Nikita Leshenko Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Wanpeng Li Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 2019162778b4bd8aac58316fd149fd953c173722 Author: Lyude Paul Date: Tue Dec 12 14:31:30 2017 -0500 igb: Free IRQs when device is hotplugged [ Upstream commit 888f22931478a05bc81ceb7295c626e1292bf0ed ] Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon hotplugging my kernel would immediately crash due to igb: [ 680.825801] kernel BUG at drivers/pci/msi.c:352! [ 680.828388] invalid opcode: 0000 [#1] SMP [ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb] [ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6 [ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017 [ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0 [ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286 [ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c [ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178 [ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00 [ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298 [ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000 [ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000 [ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0 [ 680.837954] Call Trace: [ 680.838853] pci_disable_msix+0xce/0xf0 [ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb] [ 680.840278] igb_remove+0x9d/0x110 [igb] [ 680.840764] pci_device_remove+0x36/0xb0 [ 680.841279] device_release_driver_internal+0x157/0x220 [ 680.841739] pci_stop_bus_device+0x7d/0xa0 [ 680.842255] pci_stop_bus_device+0x2b/0xa0 [ 680.842722] pci_stop_bus_device+0x3d/0xa0 [ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20 [ 680.843627] trim_stale_devices+0xf3/0x140 [ 680.844086] trim_stale_devices+0x94/0x140 [ 680.844532] trim_stale_devices+0xa6/0x140 [ 680.845031] ? get_slot_status+0x90/0xc0 [ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140 [ 680.846021] acpiphp_hotplug_notify+0x175/0x200 [ 680.846581] ? free_bridge+0x100/0x100 [ 680.847113] acpi_device_hotplug+0x8a/0x490 [ 680.847535] acpi_hotplug_work_fn+0x1a/0x30 [ 680.848076] process_one_work+0x182/0x3a0 [ 680.848543] worker_thread+0x2e/0x380 [ 680.848963] ? process_one_work+0x3a0/0x3a0 [ 680.849373] kthread+0x111/0x130 [ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50 [ 680.850188] ret_from_fork+0x1f/0x30 [ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b [ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0 As it turns out, normally the freeing of IRQs that would fix this is called inside of the scope of __igb_close(). However, since the device is already gone by the point we try to unregister the netdevice from the driver due to a hotplug we end up seeing that the netif isn't present and thus, forget to free any of the device IRQs. So: make sure that if we're in the process of dismantling the netdev, we always allow __igb_close() to be called so that IRQs may be freed normally. Additionally, only allow igb_close() to be called from __igb_close() if it hasn't already been called for the given adapter. Signed-off-by: Lyude Paul Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach") Cc: Todd Fujinaka Cc: Stephen Hemminger Cc: stable@vger.kernel.org Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 574f2dd71fc56fea5ac610f704ff08de0c061670 Author: Jesse Chan Date: Mon Nov 20 12:54:52 2017 -0800 gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE [ Upstream commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 ] This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o see include/linux/module.h for more information This adds the license as "GPL", which matches the header of the file. MODULE_DESCRIPTION and MODULE_AUTHOR are also added. Signed-off-by: Jesse Chan Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f8a38ab4cd9624fc5ac8a7f965c7b20f5b62c03c Author: Takashi Iwai Date: Tue Jan 9 23:11:03 2018 +0100 ALSA: seq: Make ioctls race-free [ Upstream commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 ] The ALSA sequencer ioctls have no protection against racy calls while the concurrent operations may lead to interfere with each other. As reported recently, for example, the concurrent calls of setting client pool with a combination of write calls may lead to either the unkillable dead-lock or UAF. As a slightly big hammer solution, this patch introduces the mutex to make each ioctl exclusive. Although this may reduce performance via parallel ioctl calls, usually it's not demanded for sequencer usages, hence it should be negligible. Reported-by: Luo Quan Reviewed-by: Kees Cook Reviewed-by: Greg Kroah-Hartman Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 754cfa993ace8a413fd5b34adec9226820bf03a6 Author: Eric Dumazet Date: Tue Jan 30 03:37:44 2018 +0100 bpf: fix divides by zero [ Upstream commit c366287ebd698ef5e3de300d90cd62ee9ee7373e ] Divides by zero are not nice, lets avoid them if possible. Also do_div() seems not needed when dealing with 32bit operands, but this seems a minor detail. Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF interpreter's instruction set") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 31f1fa710257deb8eb3ec5236fd13562ec39dd22 Author: Daniel Borkmann Date: Tue Jan 30 03:37:42 2018 +0100 bpf: arsh is not supported in 32 bit alu thus reject it [ Upstream commit 7891a87efc7116590eaba57acc3c422487802c6f ] The following snippet was throwing an 'unknown opcode cc' warning in BPF interpreter: 0: (18) r0 = 0x0 2: (7b) *(u64 *)(r10 -16) = r0 3: (cc) (u32) r0 s>>= (u32) r0 4: (95) exit Although a number of JITs do support BPF_ALU | BPF_ARSH | BPF_{K,X} generation, not all of them do and interpreter does neither. We can leave existing ones and implement it later in bpf-next for the remaining ones, but reject this properly in verifier for the time being. Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)") Reported-by: syzbot+93c4904c5c70348a6890@syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f3ddd4df852f8c2ed11d09086b64a3be76ea2aed Author: Linus Torvalds Date: Fri Jan 5 16:26:00 2018 -0800 loop: fix concurrent lo_open/lo_release [ Upstream commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 ] 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. Reported-by: 范龙飞 Signed-off-by: Linus Torvalds Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 48978a7cb8586c49875ccbc6d243c880e4cbaf44 Author: Ben Hutchings Date: Mon Jan 22 20:11:06 2018 +0000 nfsd: auth: Fix gid sorting when rootsquash enabled [ Upstream commit 1995266727fa8143897e89b55f5d3c79aa828420 ] Commit bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility group_info allocators") appears to break nfsd rootsquash in a pretty major way. It adds a call to groups_sort() inside the loop that copies/squashes gids, which means the valid gids are sorted along with the following garbage. The net result is that the highest numbered valid gids are replaced with any lower-valued garbage gids, possibly including 0. We should sort only once, after filling in all the gids. Fixes: bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility ...") Signed-off-by: Ben Hutchings Acked-by: J. Bruce Fields Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0a2fe7a6cabf38efcf975ae148c7784bc032ab39 Author: Dan Streetman Date: Thu Jan 18 16:14:26 2018 -0500 net: tcp: close sock if net namespace is exiting [ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ] When a tcp socket is closed, if it detects that its net namespace is exiting, close immediately and do not wait for FIN sequence. For normal sockets, a reference is taken to their net namespace, so it will never exit while the socket is open. However, kernel sockets do not take a reference to their net namespace, so it may begin exiting while the kernel socket is still open. In this case if the kernel socket is a tcp socket, it will stay open trying to complete its close sequence. The sock's dst(s) hold a reference to their interface, which are all transferred to the namespace's loopback interface when the real interfaces are taken down. When the namespace tries to take down its loopback interface, it hangs waiting for all references to the loopback interface to release, which results in messages like: unregister_netdevice: waiting for lo to become free. Usage count = 1 These messages continue until the socket finally times out and closes. Since the net namespace cleanup holds the net_mutex while calling its registered pernet callbacks, any new net namespace initialization is blocked until the current net namespace finishes exiting. After this change, the tcp socket notices the exiting net namespace, and closes immediately, releasing its dst(s) and their reference to the loopback interface, which lets the net namespace continue exiting. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811 Signed-off-by: Dan Streetman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 17ebdebe345fc7fd3730a6df970c5afe3530013e Author: Jim Westfall Date: Sun Jan 14 04:18:51 2018 -0800 ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY [ Upstream commit cd9ff4de0107c65d69d02253bb25d6db93c3dbc1 ] Map all lookup neigh keys to INADDR_ANY for loopback/point-to-point devices to avoid making an entry for every remote ip the device needs to talk to. This used the be the old behavior but became broken in a263b3093641f (ipv4: Make neigh lookups directly in output packet path) and later removed in 0bb4087cbec0 (ipv4: Fix neigh lookup keying over loopback/point-to-point devices) because it was broken. Signed-off-by: Jim Westfall Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 85764452cd39117cba5bde34bbc4c482abbd2ec3 Author: Jim Westfall Date: Sun Jan 14 04:18:50 2018 -0800 net: Allow neigh contructor functions ability to modify the primary_key [ Upstream commit 096b9854c04df86f03b38a97d40b6506e5730919 ] Use n->primary_key instead of pkey to account for the possibility that a neigh constructor function may have modified the primary_key value. Signed-off-by: Jim Westfall Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0c03dd4b6647c2eeac100ca352de2ad38a3dd4a5 Author: Neil Horman Date: Mon Jan 22 16:06:37 2018 -0500 vmxnet3: repair memory leak [ Upstream commit 848b159835ddef99cc4193083f7e786c3992f580 ] with the introduction of commit b0eb57cb97e7837ebb746404c2c58c6f536f23fa, it appears that rq->buf_info is improperly handled. While it is heap allocated when an rx queue is setup, and freed when torn down, an old line of code in vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0] being set to NULL prior to its being freed, causing a memory leak, which eventually exhausts the system on repeated create/destroy operations (for example, when the mtu of a vmxnet3 interface is changed frequently. Fix is pretty straight forward, just move the NULL set to after the free. Tested by myself with successful results Applies to net, and should likely be queued for stable, please Signed-off-by: Neil Horman Reported-By: boyang@redhat.com CC: boyang@redhat.com CC: Shrikrishna Khare CC: "VMware, Inc." CC: David S. Miller Acked-by: Shrikrishna Khare Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2f9b94618de6aa87623e7716e5c78e16efc9a36c Author: Xin Long Date: Mon Jan 15 17:01:36 2018 +0800 sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf [ Upstream commit a0ff660058b88d12625a783ce9e5c1371c87951f ] After commit cea0cc80a677 ("sctp: use the right sk after waking up from wait_buf sleep"), it may change to lock another sk if the asoc has been peeled off in sctp_wait_for_sndbuf. However, the asoc's new sk could be already closed elsewhere, as it's in the sendmsg context of the old sk that can't avoid the new sk's closing. If the sk's last one refcnt is held by this asoc, later on after putting this asoc, the new sk will be freed, while under it's own lock. This patch is to revert that commit, but fix the old issue by returning error under the old sk's lock. Fixes: cea0cc80a677 ("sctp: use the right sk after waking up from wait_buf sleep") Reported-by: syzbot+ac6ea7baa4432811eb50@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c45d37842eaa52352ad3a572183acb6e9ca917c Author: Xin Long Date: Mon Jan 15 17:02:00 2018 +0800 sctp: do not allow the v4 socket to bind a v4mapped v6 address [ Upstream commit c5006b8aa74599ce19104b31d322d2ea9ff887cc ] The check in sctp_sockaddr_af is not robust enough to forbid binding a v4mapped v6 addr on a v4 socket. The worse thing is that v4 socket's bind_verify would not convert this v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4 socket bound a v6 addr. This patch is to fix it by doing the common sa.sa_family check first, then AF_INET check for v4mapped v6 addrs. Fixes: 7dab83de50c7 ("sctp: Support ipv6only AF_INET6 sockets.") Reported-by: syzbot+7b7b518b1228d2743963@syzkaller.appspotmail.com Acked-by: Neil Horman Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 59725ca65b10083d81c1f845df81802edecef0ab Author: Guillaume Nault Date: Mon Jan 22 18:06:37 2018 +0100 pppoe: take ->needed_headroom of lower device into account on xmit [ Upstream commit 02612bb05e51df8489db5e94d0cf8d1c81f87b0c ] In pppoe_sendmsg(), reserving dev->hard_header_len bytes of headroom was probably fine before the introduction of ->needed_headroom in commit f5184d267c1a ("net: Allow netdevices to specify needed head/tailroom"). But now, virtual devices typically advertise the size of their overhead in dev->needed_headroom, so we must also take it into account in skb_reserve(). Allocation size of skb is also updated to take dev->needed_tailroom into account and replace the arbitrary 32 bytes with the real size of a PPPoE header. This issue was discovered by syzbot, who connected a pppoe socket to a gre device which had dev->header_ops->create == ipgre_header and dev->hard_header_len == 0. Therefore, PPPoE didn't reserve any headroom, and dev_hard_header() crashed when ipgre_header() tried to prepend its header to skb->data. skbuff: skb_under_panic: text:000000001d390b3a len:31 put:24 head:00000000d8ed776f data:000000008150e823 tail:0x7 end:0xc0 dev:gre0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 3670 Comm: syzkaller801466 Not tainted 4.15.0-rc7-next-20180115+ #97 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100 RSP: 0018:ffff8801d9bd7840 EFLAGS: 00010282 RAX: 0000000000000083 RBX: ffff8801d4f083c0 RCX: 0000000000000000 RDX: 0000000000000083 RSI: 1ffff1003b37ae92 RDI: ffffed003b37aefc RBP: ffff8801d9bd78a8 R08: 1ffff1003b37ae8a R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff86200de0 R13: ffffffff84a981ad R14: 0000000000000018 R15: ffff8801d2d34180 FS: 00000000019c4880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000208bc000 CR3: 00000001d9111001 CR4: 00000000001606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_under_panic net/core/skbuff.c:114 [inline] skb_push+0xce/0xf0 net/core/skbuff.c:1714 ipgre_header+0x6d/0x4e0 net/ipv4/ip_gre.c:879 dev_hard_header include/linux/netdevice.h:2723 [inline] pppoe_sendmsg+0x58e/0x8b0 drivers/net/ppp/pppoe.c:890 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg+0xca/0x110 net/socket.c:640 sock_write_iter+0x31a/0x5d0 net/socket.c:909 call_write_iter include/linux/fs.h:1775 [inline] do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653 do_iter_write+0x154/0x540 fs/read_write.c:932 vfs_writev+0x18a/0x340 fs/read_write.c:977 do_writev+0xfc/0x2a0 fs/read_write.c:1012 SYSC_writev fs/read_write.c:1085 [inline] SyS_writev+0x27/0x30 fs/read_write.c:1082 entry_SYSCALL_64_fastpath+0x29/0xa0 Admittedly PPPoE shouldn't be allowed to run on non Ethernet-like interfaces, but reserving space for ->needed_headroom is a more fundamental issue that needs to be addressed first. Same problem exists for __pppoe_xmit(), which also needs to take dev->needed_headroom into account in skb_cow_head(). Fixes: f5184d267c1a ("net: Allow netdevices to specify needed head/tailroom") Reported-by: syzbot+ed0838d0fa4c4f2b528e20286e6dc63effc7c14d@syzkaller.appspotmail.com Signed-off-by: Guillaume Nault Reviewed-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 795a64316c0fbefcd6149ebb60861ca61dd708a8 Author: Eric Dumazet Date: Thu Jan 18 19:59:19 2018 -0800 net: qdisc_pkt_len_init() should be more robust [ Upstream commit 7c68d1a6b4db9012790af7ac0f0fdc0d2083422a ] Without proper validation of DODGY packets, we might very well feed qdisc_pkt_len_init() with invalid GSO packets. tcp_hdrlen() might access out-of-bound data, so let's use skb_header_pointer() and proper checks. Whole story is described in commit d0c081b49137 ("flow_dissector: properly cap thoff field") We have the goal of validating DODGY packets earlier in the stack, so we might very well revert this fix in the future. Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Cc: Jason Wang Reported-by: syzbot+9da69ebac7dddd804552@syzkaller.appspotmail.com Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 849bc5e7fd15a0752ef69cf1d59dbcc2569961c8 Author: Craig Gallek Date: Wed Feb 10 11:50:37 2016 -0500 tcp: __tcp_hdrlen() helper [ Upstream commit d9b3fca27385eafe61c3ca6feab6cb1e7dc77482 ] tcp_hdrlen is wasteful if you already have a pointer to struct tcphdr. This splits the size calculation into a helper function that can be used if a struct tcphdr is already available. Signed-off-by: Craig Gallek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 65818f28145df7ba04ef5893bcd1007e401b9377 Author: Felix Fietkau Date: Fri Jan 19 11:50:46 2018 +0100 net: igmp: fix source address check for IGMPv3 reports [ Upstream commit ad23b750933ea7bf962678972a286c78a8fa36aa ] Commit "net: igmp: Use correct source address on IGMPv3 reports" introduced a check to validate the source address of locally generated IGMPv3 packets. Instead of checking the local interface address directly, it uses inet_ifa_match(fl4->saddr, ifa), which checks if the address is on the local subnet (or equal to the point-to-point address if used). This breaks for point-to-point interfaces, so check against ifa->ifa_local directly. Cc: Kevin Cernekee Fixes: a46182b00290 ("net: igmp: Use correct source address on IGMPv3 reports") Reported-by: Sebastian Gottschall Signed-off-by: Felix Fietkau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f86eb8fde443345093ea279982fb9e16afce1b61 Author: Eric Dumazet Date: Thu Jan 11 22:31:18 2018 -0800 ipv6: ip6_make_skb() needs to clear cork.base.dst [ Upstream commit 95ef498d977bf44ac094778fd448b98af158a3e6 ] In my last patch, I missed fact that cork.base.dst was not initialized in ip6_make_skb() : If ip6_setup_cork() returns an error, we might attempt a dst_release() on some random pointer. Fixes: 862c03ee1deb ("ipv6: fix possible mem leaks in ipv6_make_skb()") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5adce373daac791ee2c969414589c0cb44cb9f01 Author: Mike Maloney Date: Wed Jan 10 12:45:10 2018 -0500 ipv6: fix udpv6 sendmsg crash caused by too small MTU [ Upstream commit 749439bfac6e1a2932c582e2699f91d329658196 ] The logic in __ip6_append_data() assumes that the MTU is at least large enough for the headers. A device's MTU may be adjusted after being added while sendmsg() is processing data, resulting in __ip6_append_data() seeing any MTU. For an mtu smaller than the size of the fragmentation header, the math results in a negative 'maxfraglen', which causes problems when refragmenting any previous skb in the skb_write_queue, leaving it possibly malformed. Instead sendmsg returns EINVAL when the mtu is calculated to be less than IPV6_MIN_MTU. Found by syzkaller: kernel BUG at ./include/linux/skbuff.h:2064! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 14216 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task: ffff8801d0b68580 task.stack: ffff8801ac6b8000 RIP: 0010:__skb_pull include/linux/skbuff.h:2064 [inline] RIP: 0010:__ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP: 0018:ffff8801ac6bf570 EFLAGS: 00010216 RAX: 0000000000010000 RBX: 0000000000000028 RCX: ffffc90003cce000 RDX: 00000000000001b8 RSI: ffffffff839df06f RDI: ffff8801d9478ca0 RBP: ffff8801ac6bf780 R08: ffff8801cc3f1dbc R09: 0000000000000000 R10: ffff8801ac6bf7a0 R11: 43cb4b7b1948a9e7 R12: ffff8801cc3f1dc8 R13: ffff8801cc3f1d40 R14: 0000000000001036 R15: dffffc0000000000 FS: 00007f43d740c700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7834984000 CR3: 00000001d79b9000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip6_finish_skb include/net/ipv6.h:911 [inline] udp_v6_push_pending_frames+0x255/0x390 net/ipv6/udp.c:1093 udpv6_sendmsg+0x280d/0x31a0 net/ipv6/udp.c:1363 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 SYSC_sendto+0x352/0x5a0 net/socket.c:1750 SyS_sendto+0x40/0x50 net/socket.c:1718 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4512e9 RSP: 002b:00007f43d740bc08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00000000007180a8 RCX: 00000000004512e9 RDX: 000000000000002e RSI: 0000000020d08000 RDI: 0000000000000005 RBP: 0000000000000086 R08: 00000000209c1000 R09: 000000000000001c R10: 0000000000040800 R11: 0000000000000216 R12: 00000000004b9c69 R13: 00000000ffffffff R14: 0000000000000005 R15: 00000000202c2000 Code: 9e 01 fe e9 c5 e8 ff ff e8 7f 9e 01 fe e9 4a ea ff ff 48 89 f7 e8 52 9e 01 fe e9 aa eb ff ff e8 a8 b6 cf fd 0f 0b e8 a1 b6 cf fd <0f> 0b 49 8d 45 78 4d 8d 45 7c 48 89 85 78 fe ff ff 49 8d 85 ba RIP: __skb_pull include/linux/skbuff.h:2064 [inline] RSP: ffff8801ac6bf570 RIP: __ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP: ffff8801ac6bf570 Reported-by: syzbot Signed-off-by: Mike Maloney Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e075441ac793a20e0ffe11e6289da22f4f10f3e Author: Alexey Kodanev Date: Fri Jan 26 15:14:16 2018 +0300 dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state [ Upstream commit dd5684ecae3bd8e44b644f50e2c12c7e57fdfef5 ] ccid2_hc_tx_rto_expire() timer callback always restarts the timer again and can run indefinitely (unless it is stopped outside), and after commit 120e9dabaf55 ("dccp: defer ccid_hc_tx_delete() at dismantle time"), which moved ccid_hc_tx_delete() (also includes sk_stop_timer()) from dccp_destroy_sock() to sk_destruct(), this started to happen quite often. The timer prevents releasing the socket, as a result, sk_destruct() won't be called. Found with LTP/dccp_ipsec tests running on the bonding device, which later couldn't be unloaded after the tests were completed: unregister_netdevice: waiting for bond0 to become free. Usage count = 148 Fixes: 2a91aa396739 ("[DCCP] CCID2: Initial CCID2 (TCP-Like) implementation") Signed-off-by: Alexey Kodanev Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 27b3d9f0a5dc5c65d0a16ed1a89db015c44e47ec Author: Greg KH Date: Wed Mar 8 19:03:44 2017 +0100 eventpoll.h: add missing epoll event masks [ Upstream commit 7e040726850a106587485c21bdacc0bfc8a0cbed ] [resend due to me forgetting to cc: linux-api the first time around I posted these back on Feb 23] From: Greg Kroah-Hartman For some reason these values are not in the uapi header file, so any libc has to define it themselves. To prevent them from needing to do this, just have the kernel provide the correct values. Reported-by: Elliott Hughes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 66696384a44dce8330ccf3389befe380c964aa94 Author: Thomas Meyer Date: Sun Aug 20 13:26:04 2017 +0200 um: link vmlinux with -no-pie [ Upstream commit 883354afbc109c57f925ccc19840055193da0cc0 ] Debian's gcc defaults to pie. The global Makefile already defines the -fno-pie option. Link UML dynamic kernel image also with -no-pie to fix the build. Signed-off-by: Thomas Meyer Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 5b654a09cff8e0b9f2e1b0c7d45ddba7b73b6b69 Author: Shuah Khan Date: Fri Dec 15 10:50:09 2017 -0700 usbip: prevent leaking socket pointer address in messages [ Upstream commit 90120d15f4c397272aaf41077960a157fc4212bf ] usbip driver is leaking socket pointer address in messages. Remove the messages that aren't useful and print sockfd in the ones that are useful for debugging. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 41ab9559b047a8a3f958a89f0202772a1aeaf4e4 Author: Shuah Khan Date: Thu Dec 7 14:16:48 2017 -0700 usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input [ Upstream commit c6688ef9f29762e65bce325ef4acd6c675806366 ] Harden CMD_SUBMIT path to handle malicious input that could trigger large memory allocations. Add checks to validate transfer_buffer_length and number_of_packets to protect against bad input requesting for unbounded memory allocations. Validate early in get_pipe() and return failure. Reported-by: Secunia Research Cc: stable Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fcd31102e7ff3c83c6a6cda08156393e18c5e8f3 Author: Shuah Khan Date: Thu Dec 7 14:16:47 2017 -0700 usbip: fix stub_rx: get_pipe() to validate endpoint number [ Upstream commit 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 ] get_pipe() routine doesn't validate the input endpoint number and uses to reference ep_in and ep_out arrays. Invalid endpoint number can trigger BUG(). Range check the epnum and returning error instead of calling BUG(). Change caller stub_recv_cmd_submit() to handle the get_pipe() error return. Reported-by: Secunia Research Cc: stable Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 60a98e535b39d5dbc2bb5c8e701b8caecb4a1f6c Author: Aaron Ma Date: Fri Jan 19 09:43:39 2018 -0800 Input: trackpoint - force 3 buttons if 0 button is reported [ Upstream commit f5d07b9e98022d50720e38aa936fc11c67868ece ] Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands. They supposed to reply with 0x02, 0x03, or 0x04 in response to the "Read Extended ID" command, so we would know not to try certain extended commands. Unfortunately even some trackpoints reporting the original IBM version (0x01 firmware 0x0e) now respond with incorrect data to the "Get Extended Buttons" command: thinkpad_acpi: ThinkPad BIOS R0DET87W (1.87 ), EC unknown thinkpad_acpi: Lenovo ThinkPad E470, model 20H1004SGE psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 0/0 Since there are no trackpoints without buttons, let's assume the trackpoint has 3 buttons when we get 0 response to the extended buttons query. Signed-off-by: Aaron Ma Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196253 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 54aa46db043038e6c55e12f7b3b4cf5e564e991b Author: Greg Kroah-Hartman Date: Wed Jan 24 15:28:17 2018 +0100 Revert "module: Add retpoline tag to VERMAGIC" [ Upstream commit 5132ede0fe8092b043dae09a7cc32b8ae7272baa ] This reverts commit 6cfb521ac0d5b97470883ff9b7facae264b7ab12. Turns out distros do not want to make retpoline as part of their "ABI", so this patch should not have been merged. Sorry Andi, this was my fault, I suggested it when your original patch was the "correct" way of doing this instead. Reported-by: Jiri Kosina Fixes: 6cfb521ac0d5 ("module: Add retpoline tag to VERMAGIC") Acked-by: Andi Kleen Cc: Thomas Gleixner Cc: David Woodhouse Cc: rusty@rustcorp.com.au Cc: arjan.van.de.ven@intel.com Cc: jeyu@kernel.org Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6a78b92d2c87e5397a18794c3263b52c4c98b278 Author: Johannes Thumshirn Date: Mon Oct 9 13:33:19 2017 +0200 scsi: libiscsi: fix shifting of DID_REQUEUE host byte [ Upstream commit eef9ffdf9cd39b2986367bc8395e2772bc1284ba ] The SCSI host byte should be shifted left by 16 in order to have scsi_decide_disposition() do the right thing (.i.e. requeue the command). Signed-off-by: Johannes Thumshirn Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep check common") Cc: Lee Duncan Cc: Hannes Reinecke Cc: Bart Van Assche Cc: Chris Leech Acked-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8cfb61f1e723c2ceb65a640af133211847f54ed0 Author: Jiri Slaby Date: Tue Jun 13 13:35:51 2017 +0200 fs/fcntl: f_setown, avoid undefined behaviour [ Upstream commit fc3dc67471461c0efcb1ed22fb7595121d65fad9 ] fcntl(0, F_SETOWN, 0x80000000) triggers: UBSAN: Undefined behaviour in fs/fcntl.c:118:7 negation of -2147483648 cannot be represented in type 'int': CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1 ... Call Trace: ... [] ? f_setown+0x1d8/0x200 [] ? SyS_fcntl+0x999/0xf30 [] ? entry_SYSCALL_64_fastpath+0x23/0xc1 Fix that by checking the arg parameter properly (against INT_MAX) before "who = -who". And return immediatelly with -EINVAL in case it is wrong. Note that according to POSIX we can return EINVAL: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html [EINVAL] The cmd argument is F_SETOWN and the value of the argument is not valid as a process or process group identifier. [v2] returns an error, v1 used to fail silently [v3] implement proper check for the bad value INT_MIN Signed-off-by: Jiri Slaby Cc: Jeff Layton Cc: "J. Bruce Fields" Cc: Alexander Viro Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Jeff Layton Signed-off-by: Sasha Levin commit 0b1ed5917e2c1c63bc416724530c69965e22c2b1 Author: Jan Kara Date: Thu Jun 22 09:32:49 2017 +0200 reiserfs: Don't clear SGID when inheriting ACLs [ Upstream commit 6883cd7f68245e43e91e5ee583b7550abf14523f ] 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 moving posix_acl_update_mode() out of __reiserfs_set_acl() into reiserfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: stable@vger.kernel.org CC: reiserfs-devel@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 844ae9f552a79c5e1ff1069ec2ac5ba84e344d7b Author: Jeff Mahoney Date: Thu Jun 22 16:35:04 2017 -0400 reiserfs: don't preallocate blocks for extended attributes [ Upstream commit 54930dfeb46e978b447af0fb8ab4e181c1bf9d7a ] Most extended attributes will fit in a single block. More importantly, we drop the reference to the inode while holding the transaction open so the preallocated blocks aren't released. As a result, the inode may be evicted before it's removed from the transaction's prealloc list which can cause memory corruption. Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 2a99d735ed08b3249fe4eb68fb67d82e5639cee0 Author: Jeff Mahoney Date: Thu Jun 22 16:47:34 2017 -0400 reiserfs: fix race in prealloc discard [ Upstream commit 08db141b5313ac2f64b844fb5725b8d81744b417 ] The main loop in __discard_prealloc is protected by the reiserfs write lock which is dropped across schedules like the BKL it replaced. The problem is that it checks the value, calls a routine that schedules, and then adjusts the state. As a result, two threads that are calling reiserfs_prealloc_discard at the same time can race when one calls reiserfs_free_prealloc_block, the lock is dropped, and the other calls reiserfs_free_prealloc_block with the same block number. In the right circumstances, it can cause the prealloc count to go negative. Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 74e1022aea68c2575da30558cb7fd6629d5a7f0e Author: Jan Kara Date: Wed Jun 21 14:34:15 2017 +0200 ext2: Don't clear SGID when inheriting ACLs [ Upstream commit a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 ] 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: 073931017b49d9458aa351605b43a7e34598caef CC: stable@vger.kernel.org CC: linux-ext4@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 6a45beb377097053f1b293db3d0e01f35b3a7cbf Author: Kevin Cernekee Date: Tue Dec 5 15:42:41 2017 -0800 netfilter: xt_osf: Add missing permission checks [ Upstream commit 916a27901de01446bcf57ecca4783f6cff493309 ] The capability check in nfnetlink_rcv() verifies that the caller has CAP_NET_ADMIN in the namespace that "owns" the netlink socket. However, xt_osf_fingers is shared by all net namespaces on the system. An unprivileged user can create user and net namespaces in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable() check: vpnns -- nfnl_osf -f /tmp/pf.os vpnns -- nfnl_osf -f /tmp/pf.os -d These non-root operations successfully modify the systemwide OS fingerprint list. Add new capable() checks so that they can't. Signed-off-by: Kevin Cernekee Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6d752a482cf7ce18ca96abaf0a159e801d4c38e8 Author: Kevin Cernekee Date: Sun Dec 3 12:12:45 2017 -0800 netfilter: nfnetlink_cthelper: Add missing permission checks [ Upstream commit 4b380c42f7d00a395feede754f0bc2292eebe6e5 ] The capability check in nfnetlink_rcv() verifies that the caller has CAP_NET_ADMIN in the namespace that "owns" the netlink socket. However, nfnl_cthelper_list is shared by all net namespaces on the system. An unprivileged user can create user and net namespaces in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable() check: $ nfct helper list nfct v1.4.4: netlink error: Operation not permitted $ vpnns -- nfct helper list { .name = ftp, .queuenum = 0, .l3protonum = 2, .l4protonum = 6, .priv_data_len = 24, .status = enabled, }; Add capable() checks in nfnetlink_cthelper, as this is cleaner than trying to generalize the solution. Signed-off-by: Kevin Cernekee Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3f5f08be8f8a3fb351f94f21b9528fee35cc17fd Author: Ulrich Weber Date: Mon Oct 24 18:07:23 2016 +0200 netfilter: nf_conntrack_sip: extend request line validation [ Upstream commit 444f901742d054a4cd5ff045871eac5131646cfb ] on SIP requests, so a fragmented TCP SIP packet from an allow header starting with INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE Content-Length: 0 will not bet interpreted as an INVITE request. Also Request-URI must start with an alphabetic character. Confirm with RFC 3261 Request-Line = Method SP Request-URI SP SIP-Version CRLF Fixes: 30f33e6dee80 ("[NETFILTER]: nf_conntrack_sip: support method specific request/response handling") Signed-off-by: Ulrich Weber Acked-by: Marco Angaroni Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e992ed6678f05da7ece99ba3bcb16f3f9ab2e215 Author: Florian Westphal Date: Thu Aug 25 15:33:29 2016 +0200 netfilter: restart search if moved to other chain [ Upstream commit 95a8d19f28e6b29377a880c6264391a62e07fccc ] In case nf_conntrack_tuple_taken did not find a conflicting entry check that all entries in this hash slot were tested and restart in case an entry was moved to another chain. Reported-by: Eric Dumazet Fixes: ea781f197d6a ("netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu()") Signed-off-by: Florian Westphal Acked-by: Eric Dumazet Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a0860345edc4fa0ef8e2a55e388f40eb0b70c8d4 Author: Liping Zhang Date: Mon Aug 8 21:57:58 2016 +0800 netfilter: nf_ct_expect: remove the redundant slash when policy name is empty [ Upstream commit b173a28f62cf929324a8a6adcc45adadce311d16 ] The 'name' filed in struct nf_conntrack_expect_policy{} is not a pointer, so check it is NULL or not will always return true. Even if the name is empty, slash will always be displayed like follows: # cat /proc/net/nf_conntrack_expect 297 l3proto = 2 proto=6 src=1.1.1.1 dst=2.2.2.2 sport=1 dport=1025 ftp/ ^ Fixes: 3a8fc53a45c4 ("netfilter: nf_ct_helper: allocate 16 bytes for the helper and policy names") Signed-off-by: Liping Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 08b38b01067e8e01449d8d2c7e5885b890a93afe Author: Hongxu Jia Date: Tue Nov 29 21:56:26 2016 -0500 netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed in 64bit kernel [ Upstream commit 17a49cd549d9dc8707dc9262210166455c612dde ] Since 09d9686047db ("netfilter: x_tables: do compat validation via translate_table"), it used compatr structure to assign newinfo structure. In translate_compat_table of ip_tables.c and ip6_tables.c, it used compatr->hook_entry to replace info->hook_entry and compatr->underflow to replace info->underflow, but not do the same replacement in arp_tables.c. It caused invoking 32-bit "arptbale -P INPUT ACCEPT" failed in 64bit kernel. -------------------------------------- root@qemux86-64:~# arptables -P INPUT ACCEPT root@qemux86-64:~# arptables -P INPUT ACCEPT ERROR: Policy for `INPUT' offset 448 != underflow 0 arptables: Incompatible with this kernel -------------------------------------- Fixes: 09d9686047db ("netfilter: x_tables: do compat validation via translate_table") Signed-off-by: Hongxu Jia Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 301ba6723751065951e0f952389c9e04580faad3 Author: Rafael J. Wysocki Date: Thu Jun 2 01:57:50 2016 +0200 ACPI / processor: Avoid reserving IO regions too early [ Upstream commit 86314751c7945fa0c67f459beeda2e7c610ca429 ] Roland Dreier reports that one of his systems cannot boot because of the changes made by commit ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure). The problematic part of it is the request_region() call in acpi_processor_get_info() that used to run at module init time before the above commit and now it runs much earlier. Unfortunately, the region(s) reserved by it fall into a range the PCI subsystem attempts to reserve for AHCI IO BARs. As a result, the PCI reservation fails and AHCI doesn't work, while previously the PCI reservation would be made before acpi_processor_get_info() and it would succeed. That request_region() call, however, was overlooked by commit ac212b6980d8, as it is not necessary for the enumeration of the processors. It only is needed when the ACPI processor driver actually attempts to handle them which doesn't happen before loading the ACPI processor driver module. Therefore that call should have been moved from acpi_processor_get_info() into that module. Address the problem by moving the request_region() call in question out of acpi_processor_get_info() and use the observation that the region reserved by it is only needed if the FADT-based CPU throttling method is going to be used, which means that it should be sufficient to invoke it from acpi_processor_get_throttling_fadt(). Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure) Reported-by: Roland Dreier Tested-by: Roland Dreier Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 27595aa9c585b2862dd33b90e679ad34c1d28439 Author: Rui Wang Date: Wed Jun 8 14:59:52 2016 +0800 x86/ioapic: Fix incorrect pointers in ioapic_setup_resources() [ Upstream commit 9d98bcec731756b8688b59ec998707924d716d7b ] On a 4-socket Brickland system, hot-removing one ioapic is fine. Hot-removing the 2nd one causes panic in mp_unregister_ioapic() while calling release_resource(). It is because the iomem_res pointer has already been released when removing the first ioapic. To explain the use of &res[num] here: res is assigned to ioapic_resources, and later in ioapic_insert_resources() we do: struct resource *r = ioapic_resources; for_each_ioapic(i) { insert_resource(&iomem_resource, r); r++; } Here 'r' is treated as an arry of 'struct resource', and the r++ ensures that each element of the array is inserted separately. Thus we should call release_resouce() on each element at &res[num]. Fix it by assigning the correct pointers to ioapics[i].iomem_res in ioapic_setup_resources(). Signed-off-by: Rui Wang Signed-off-by: Thomas Gleixner Cc: tony.luck@intel.com Cc: linux-pci@vger.kernel.org Cc: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org Cc: bhelgaas@google.com Link: http://lkml.kernel.org/r/1465369193-4816-3-git-send-email-rui.y.wang@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 0f183e38c15d7c98dde437627836ac722aee8429 Author: Jiri Slaby Date: Wed Dec 14 15:06:07 2016 -0800 ipc: msg, make msgrcv work with LONG_MIN [ Upstream commit 999898355e08ae3b92dfd0a08db706e0c6703d30 ] When LONG_MIN is passed to msgrcv, one would expect to recieve any message. But convert_mode does *msgtyp = -*msgtyp and -LONG_MIN is undefined. In particular, with my gcc -LONG_MIN produces -LONG_MIN again. So handle this case properly by assigning LONG_MAX to *msgtyp if LONG_MIN was specified as msgtyp to msgrcv. This code: long msg[] = { 100, 200 }; int m = msgget(IPC_PRIVATE, IPC_CREAT | 0644); msgsnd(m, &msg, sizeof(msg), 0); msgrcv(m, &msg, sizeof(msg), LONG_MIN, 0); produces currently nothing: msgget(IPC_PRIVATE, IPC_CREAT|0644) = 65538 msgsnd(65538, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0 msgrcv(65538, ... Except a UBSAN warning: UBSAN: Undefined behaviour in ipc/msg.c:745:13 negation of -9223372036854775808 cannot be represented in type 'long int': With the patch, I see what I expect: msgget(IPC_PRIVATE, IPC_CREAT|0644) = 0 msgsnd(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0 msgrcv(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, -9223372036854775808, 0) = 16 Link: http://lkml.kernel.org/r/20161024082633.10148-1-jslaby@suse.cz Signed-off-by: Jiri Slaby Cc: Davidlohr Bueso Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e4ddca3f65781e04b66b0f955cde72c1ce2e6baa Author: Doug Berger Date: Mon Jul 10 15:49:44 2017 -0700 cma: fix calculation of aligned offset [ Upstream commit e048cb32f69038aa1c8f11e5c1b331be4181659d ] The align_offset parameter is used by bitmap_find_next_zero_area_off() to represent the offset of map's base from the previous alignment boundary; the function ensures that the returned index, plus the align_offset, honors the specified align_mask. The logic introduced by commit b5be83e308f7 ("mm: cma: align to physical address, not CMA region position") has the cma driver calculate the offset to the *next* alignment boundary. In most cases, the base alignment is greater than that specified when making allocations, resulting in a zero offset whether we align up or down. In the example given with the commit, the base alignment (8MB) was half the requested alignment (16MB) so the math also happened to work since the offset is 8MB in both directions. However, when requesting allocations with an alignment greater than twice that of the base, the returned index would not be correctly aligned. Also, the align_order arguments of cma_bitmap_aligned_mask() and cma_bitmap_aligned_offset() should not be negative so the argument type was made unsigned. Fixes: b5be83e308f7 ("mm: cma: align to physical address, not CMA region position") Link: http://lkml.kernel.org/r/20170628170742.2895-1-opendmb@gmail.com Signed-off-by: Angus Clark Signed-off-by: Doug Berger Acked-by: Gregory Fong Cc: Doug Berger Cc: Angus Clark Cc: Laura Abbott Cc: Vlastimil Babka Cc: Greg Kroah-Hartman Cc: Lucas Stach Cc: Catalin Marinas Cc: Shiraz Hashim Cc: Jaewon Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 034bb18c51e6993b9a16f9a909be4bef53f93c94 Author: Michal Hocko Date: Fri May 12 15:46:26 2017 -0700 hwpoison, memcg: forcibly uncharge LRU pages [ Upstream commit 18365225f0440d09708ad9daade2ec11275c3df9 ] Laurent Dufour has noticed that hwpoinsoned pages are kept charged. In his particular case he has hit a bad_page("page still charged to cgroup") when onlining a hwpoison page. While this looks like something that shouldn't happen in the first place because onlining hwpages and returning them to the page allocator makes only little sense it shows a real problem. hwpoison pages do not get freed usually so we do not uncharge them (at least not since commit 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")). Each charge pins memcg (since e8ea14cc6ead ("mm: memcontrol: take a css reference for each charged page")) as well and so the mem_cgroup and the associated state will never go away. Fix this leak by forcibly uncharging a LRU hwpoisoned page in delete_from_lru_cache(). We also have to tweak uncharge_list because it cannot rely on zero ref count for these pages. [akpm@linux-foundation.org: coding-style fixes] Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API") Link: http://lkml.kernel.org/r/20170502185507.GB19165@dhcp22.suse.cz Signed-off-by: Michal Hocko Reported-by: Laurent Dufour Tested-by: Laurent Dufour Reviewed-by: Balbir Singh Reviewed-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f9a4b91aec5465f82c31e0c450baf141f292d0e2 Author: Michal Hocko Date: Mon Jul 10 15:49:51 2017 -0700 mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack [ Upstream commit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f ] Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") has introduced a regression in some rust and Java environments which are trying to implement their own stack guard page. They are punching a new MAP_FIXED mapping inside the existing stack Vma. This will confuse expand_{downwards,upwards} into thinking that the stack expansion would in fact get us too close to an existing non-stack vma which is a correct behavior wrt safety. It is a real regression on the other hand. Let's work around the problem by considering PROT_NONE mapping as a part of the stack. This is a gros hack but overflowing to such a mapping would trap anyway an we only can hope that usespace knows what it is doing and handle it propely. Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas") Link: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.cz Signed-off-by: Michal Hocko Debugged-by: Vlastimil Babka Cc: Ben Hutchings Cc: Willy Tarreau Cc: Oleg Nesterov Cc: Rik van Riel Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7879c4c3bcf000e166920a36f3b6cd15d5133d6d Author: Vlastimil Babka Date: Tue Oct 11 13:51:14 2016 -0700 fs/select: add vmalloc fallback for select(2) [ Upstream commit 2d19309cf86883f634a4f8ec55a54bda87db19bf ] The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows with the number of fds passed. We had a customer report page allocation failures of order-4 for this allocation. This is a costly order, so it might easily fail, as the VM expects such allocation to have a lower-order fallback. Such trivial fallback is vmalloc(), as the memory doesn't have to be physically contiguous and the allocation is temporary for the duration of the syscall only. There were some concerns, whether this would have negative impact on the system by exposing vmalloc() to userspace. Although an excessive use of vmalloc can cause some system wide performance issues - TLB flushes etc. - a large order allocation is not for free either and an excessive reclaim/compaction can have a similar effect. Also note that the size is effectively limited by RLIMIT_NOFILE which defaults to 1024 on the systems I checked. That means the bitmaps will fit well within single page and thus the vmalloc() fallback could be only excercised for processes where root allows a higher limit. Note that the poll(2) syscall seems to use a linked list of order-0 pages, so it doesn't need this kind of fallback. [eric.dumazet@gmail.com: fix failure path logic] [akpm@linux-foundation.org: use proper type for size] Link: http://lkml.kernel.org/r/20160927084536.5923-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko Cc: Alexander Viro Cc: Eric Dumazet Cc: David Laight Cc: Hillf Danton Cc: Nicholas Piggin Cc: Jason Baron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 12f05604ea9fe94e736d391d226d64c10030acbc Author: Sudeep Holla Date: Fri Oct 28 09:45:28 2016 +0100 drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled [ Upstream commit fac51482577d5e05bbb0efa8d602a3c2111098bf ] With CONFIG_OF enabled on x86, we get the following error on boot: " Failed to find cpu0 device node Unable to detect cache hierarchy from DT for CPU 0 " and the cacheinfo fails to get populated in the corresponding sysfs entries. This is because cache_setup_of_node looks for of_node for setting up the shared cpu_map without checking that it's already populated in the architecture specific callback. In order to indicate that the shared cpu_map is already populated, this patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo that can be used by the generic code to skip cache_shared_cpu_map_setup. This patch also sets that boolean for x86. Cc: Greg Kroah-Hartman Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d90c9aca94812230166ed6fc86b0767304418ba3 Author: Vegard Nossum Date: Sat Aug 13 01:37:04 2016 +0200 time: Avoid undefined behaviour in ktime_add_safe() [ Upstream commit 979515c5645830465739254abc1b1648ada41518 ] I ran into this: ================================================================================ UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16 signed integer overflow: 9223372036854775807 + 50000 cannot be represented in type 'long long int' CPU: 2 PID: 4798 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #91 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 0000000000000000 ffff88010ce6fb88 ffffffff82344740 0000000041b58ab3 ffffffff84f97a20 ffffffff82344694 ffff88010ce6fbb0 ffff88010ce6fb60 000000000000c350 ffff88010ce6f968 dffffc0000000000 ffffffff857bc320 Call Trace: [] dump_stack+0xac/0xfc [] ? _atomic_dec_and_lock+0xc4/0xc4 [] ubsan_epilogue+0xd/0x8a [] handle_overflow+0x202/0x23d [] ? val_to_string.constprop.6+0x11e/0x11e [] ? timerqueue_add+0x151/0x410 [] ? hrtimer_start_range_ns+0x3b8/0x1380 [] ? memset+0x31/0x40 [] __ubsan_handle_add_overflow+0xe/0x10 [] hrtimer_nanosleep+0x5d9/0x790 [] ? hrtimer_init_sleeper+0x80/0x80 [] ? __might_sleep+0x5b/0x260 [] common_nsleep+0x20/0x30 [] SyS_clock_nanosleep+0x197/0x210 [] ? SyS_clock_getres+0x150/0x150 [] ? __this_cpu_preempt_check+0x13/0x20 [] ? __context_tracking_exit.part.3+0x30/0x1b0 [] ? SyS_clock_getres+0x150/0x150 [] do_syscall_64+0x1b3/0x4b0 [] entry_SYSCALL64_slow_path+0x25/0x25 ================================================================================ Add a new ktime_add_unsafe() helper which doesn't check for overflow, but doesn't throw a UBSAN warning when it does overflow either. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Signed-off-by: Vegard Nossum Signed-off-by: John Stultz Signed-off-by: Sasha Levin commit 24932a77ff8678d95cc2272bc69aa84d358ae0a7 Author: Eric Biggers Date: Sun Jan 24 20:08:52 2016 -0600 PM / sleep: declare __tracedata symbols as char[] rather than char [ Upstream commit f97238373b8662a6d580e204df2e7bcbfa43e27a ] Accessing more than one byte from a symbol declared simply 'char' is undefined behavior, as reported by UBSAN: UBSAN: Undefined behaviour in drivers/base/power/trace.c:178:18 load of address ffffffff8203fc78 with insufficient space for an object of type 'char' Avoid this by declaring the symbols as arrays. Signed-off-by: Eric Biggers Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fdfad351ba953f1ade7aa8e2127e87923779a375 Author: Marc Kleine-Budde Date: Tue Jan 16 19:30:14 2018 +0100 can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once [ Upstream commit d4689846881d160a4d12a514e991a740bcb5d65a ] If an invalid CANFD frame is received, from a driver or from a tun interface, a Kernel warning is generated. This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a kernel, bootet with panic_on_warn, does not panic. A printk seems to be more appropriate here. Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com Suggested-by: Dmitry Vyukov Acked-by: Oliver Hartkopp Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit c4e24b53a693123d0af647d2ca16b03d3789771b Author: Marc Kleine-Budde Date: Tue Jan 16 19:30:14 2018 +0100 can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once [ Upstream commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 ] If an invalid CAN frame is received, from a driver or from a tun interface, a Kernel warning is generated. This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a kernel, bootet with panic_on_warn, does not panic. A printk seems to be more appropriate here. Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com Suggested-by: Dmitry Vyukov Acked-by: Oliver Hartkopp Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 64620f574726b6761086215bc0ac4cc2d2c8be14 Author: Dave Hansen Date: Thu Jun 2 17:19:27 2016 -0700 x86/cpu/intel: Introduce macros for Intel family numbers [ Upstream commit 970442c599b22ccd644ebfe94d1d303bf6f87c05 ] Problem: We have a boatload of open-coded family-6 model numbers. Half of them have these model numbers in hex and the other half in decimal. This makes grepping for them tons of fun, if you were to try. Solution: Consolidate all the magic numbers. Put all the definitions in one header. The names here are closely derived from the comments describing the models from arch/x86/events/intel/core.c. We could easily make them shorter by doing things like s/SANDYBRIDGE/SNB/, but they seemed fine even with the longer versions to me. Do not take any of these names too literally, like "DESKTOP" or "MOBILE". These are all colloquial names and not precise descriptions of everywhere a given model will show up. Signed-off-by: Dave Hansen Cc: Adrian Hunter Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Darren Hart Cc: Dave Hansen Cc: Denys Vlasenko Cc: Doug Thompson Cc: Eduardo Valentin Cc: H. Peter Anvin Cc: Jacob Pan Cc: Kan Liang Cc: Len Brown Cc: Linus Torvalds Cc: Mauro Carvalho Chehab Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Rajneesh Bhardwaj Cc: Souvik Kumar Chakravarty Cc: Srinivas Pandruvada Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Tony Luck Cc: Ulf Hansson Cc: Viresh Kumar Cc: Vishwanath Somayaji Cc: Zhang Rui Cc: jacob.jun.pan@intel.com Cc: linux-acpi@vger.kernel.org Cc: linux-edac@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 3c43f68f8d2e0a216bf20450edef682b426c9aed Author: Jonathan Dieter Date: Mon Feb 27 10:31:03 2017 +0200 usbip: Fix potential format overflow in userspace tools [ Upstream commit e5dfa3f902b9a642ae8c6997d57d7c41e384a90b ] The usbip userspace tools call sprintf()/snprintf() and don't check for the return value which can lead the paths to overflow, truncating the final file in the path. More urgently, GCC 7 now warns that these aren't checked with -Wformat-overflow, and with -Werror enabled in configure.ac, that makes these tools unbuildable. This patch fixes these problems by replacing sprintf() with snprintf() in one place and adding checks for the return value of snprintf(). Reviewed-by: Peter Senna Tschudin Signed-off-by: Jonathan Dieter Acked-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 96f8d920cf14f1d01a522500e2435a5d6a368cda Author: Jonathan Dieter Date: Mon Feb 27 10:31:04 2017 +0200 usbip: Fix implicit fallthrough warning [ Upstream commit cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 ] GCC 7 now warns when switch statements fall through implicitly, and with -Werror enabled in configure.ac, that makes these tools unbuildable. We fix this by notifying the compiler that this particular case statement is meant to fall through. Reviewed-by: Peter Senna Tschudin Signed-off-by: Jonathan Dieter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c2b2e645aa47c2e9910e168398f7d28d31a0dc3 Author: Shuah Khan Date: Thu Dec 7 14:16:49 2017 -0700 usbip: prevent vhci_hcd driver from leaking a socket pointer address [ Upstream commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 ] When a client has a USB device attached over IP, the vhci_hcd driver is locally leaking a socket pointer address via the /sys/devices/platform/vhci_hcd/status file (world-readable) and in debug output when "usbip --debug port" is run. Fix it to not leak. The socket pointer address is not used at the moment and it was made visible as a convenient way to find IP address from socket pointer address by looking up /proc/net/{tcp,tcp6}. As this opens a security hole, the fix replaces socket pointer address with sockfd. Reported-by: Secunia Research Cc: stable Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit af7659fb189d0232dabe99010461415c89b65ca8 Author: Andy Lutomirski Date: Fri Dec 9 10:24:05 2016 -0800 x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels [ Upstream commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 ] We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes Signed-off-by: Andy Lutomirski Cc: Juergen Gross Cc: Peter Zijlstra Cc: Brian Gerst Cc: Matthew Whitehead Cc: Borislav Petkov Cc: Henrique de Moraes Holschuh Cc: Andrew Cooper Cc: Boris Ostrovsky Cc: xen-devel Link: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.luto@kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 4b2db6761f30989fa6d7c65b00d459e62a9bce9c Author: Jonas Gorski Date: Sun Oct 29 16:27:21 2017 +0100 MIPS: AR7: ensure the port type's FCR value is used [ Upstream commit 0a5191efe06b5103909206e4fbcff81d30283f8e ] Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers"), the port's default FCR value isn't used in serial8250_do_set_termios anymore, but copied over once in serial8250_config_port and then modified as needed. Unfortunately, serial8250_config_port will never be called if the port is shared between kernel and userspace, and the port's flag doesn't have UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well. This causes garbled output from userspace: [ 5.220000] random: procd urandom read with 49 bits of entropy available ers [kee Fix this by forcing it to be configured on boot, resulting in the expected output: [ 5.250000] random: procd urandom read with 50 bits of entropy available Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers") Signed-off-by: Jonas Gorski Cc: Greg Kroah-Hartman Cc: Yoshihiro YUNOMAE Cc: Florian Fainelli Cc: Nicolas Schichan Cc: linux-mips@linux-mips.org Cc: linux-serial@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17544/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 747d6c5c5a2bb0c757733a75e65c178635b31f59 Author: Nicholas Piggin Date: Tue Nov 1 12:46:19 2016 +1100 kbuild: modversions for EXPORT_SYMBOL() for asm [ Upstream commit 4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187 ] Allow architectures to create asm/asm-prototypes.h file that provides C prototypes for exported asm functions, which enables proper CRC versions to be generated for them. Signed-off-by: Nicholas Piggin Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit 26bfa48da661f380e53780e148cbf30e8f2b8c9c Author: Marc Zyngier Date: Tue Jan 16 10:23:47 2018 +0000 arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls [ Upstream commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd ] KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Cc: Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin commit 8e99fb51d17d12af389b00d44a831de051046b2d Author: Dennis Yang Date: Tue Dec 12 18:21:40 2017 +0800 dm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6 [ Upstream commit 490ae017f54e55bde382d45ea24bddfb6d1a0aaf ] For btree removal, there is a corner case that a single thread could takes 6 locks which is more than THIN_MAX_CONCURRENT_LOCKS(5) and leads to deadlock. A btree removal might eventually call rebalance_children()->rebalance3() to rebalance entries of three neighbor child nodes when shadow_spine has already acquired two write locks. In rebalance3(), it tries to shadow and acquire the write locks of all three child nodes. However, shadowing a child node requires acquiring a read lock of the original child node and a write lock of the new block. Although the read lock will be released after block shadowing, shadowing the third child node in rebalance3() could still take the sixth lock. (2 write locks for shadow_spine + 2 write locks for the first two child nodes's shadow + 1 write lock for the last child node's shadow + 1 read lock for the last child node) Cc: stable@vger.kernel.org Signed-off-by: Dennis Yang Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit c2a38c6dde8ef70fc4545f25b461a955e2be8853 Author: Joe Thornber Date: Wed Dec 20 09:56:06 2017 +0000 dm btree: fix serious bug in btree_split_beneath() [ Upstream commit bc68d0a43560e950850fc69b58f0f8254b28f6d6 ] When inserting a new key/value pair into a btree we walk down the spine of btree nodes performing the following 2 operations: i) space for a new entry ii) adjusting the first key entry if the new key is lower than any in the node. If the _root_ node is full, the function btree_split_beneath() allocates 2 new nodes, and redistibutes the root nodes entries between them. The root node is left with 2 entries corresponding to the 2 new nodes. btree_split_beneath() then adjusts the spine to point to one of the two new children. This means the first key is never adjusted if the new key was lower, ie. operation (ii) gets missed out. This can result in the new key being 'lost' for a period; until another low valued key is inserted that will uncover it. This is a serious bug, and quite hard to make trigger in normal use. A reproducing test case ("thin create devices-in-reverse-order") is available as part of the thin-provision-tools project: https://github.com/jthornber/thin-provisioning-tools/blob/master/functional-tests/device-mapper/dm-tests.scm#L593 Fix the issue by changing btree_split_beneath() so it no longer adjusts the spine. Instead it unlocks both the new nodes, and lets the main loop in btree_insert_raw() relock the appropriate one and make any neccessary adjustments. Cc: stable@vger.kernel.org Reported-by: Monty Pavel Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 7aed04582dcd3d3ec279dbe868a65ceb4db1d1bb Author: Xinyu Lin Date: Sun Dec 17 20:13:39 2017 +0800 libata: apply MAX_SEC_1024 to all LITEON EP1 series devices [ Upstream commit db5ff909798ef0099004ad50a0ff5fde92426fd1 ] LITEON EP1 has the same timeout issues as CX1 series devices. Revert max_sectors to the value of 1024. 'e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")' Signed-off-by: Xinyu Lin Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 166df6fcf6d2f7ab2d6a508b87593e10136f4378 Author: Stephane Grosjean Date: Mon Jan 15 16:31:19 2018 +0100 can: peak: fix potential bug in packet fragmentation [ Upstream commit d8a243af1a68395e07ac85384a2740d4134c67f4 ] In some rare conditions when running one PEAK USB-FD interface over a non high-speed USB controller, one useless USB fragment might be sent. This patch fixes the way a USB command is fragmented when its length is greater than 64 bytes and when the underlying USB controller is not a high-speed one. Signed-off-by: Stephane Grosjean Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit c0eea8c787fde06463a795d24093a0989e485271 Author: Thomas Petazzoni Date: Thu Jan 4 17:53:12 2018 +0100 ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7 [ Upstream commit 56aeb07c914a616ab84357d34f8414a69b140cdf ] MPP7 is currently muxed as "gpio", but this function doesn't exist for MPP7, only "gpo" is available. This causes the following error: kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7 pinctrl core: failed to register map default (6): invalid type given kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22 kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22 kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22 So the pinctrl driver is not probed, all device drivers (including the UART driver) do a -EPROBE_DEFER, and therefore the system doesn't really boot (well, it boots, but with no UART, and no devices that require pin-muxing). Back when the Device Tree file for this board was introduced, the definition was already wrong. The pinctrl driver also always described as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11, a hog pin failing to be muxed was turned from a simple warning to a hard error that caused the entire pinctrl driver probe to bail out. This is probably the result of commit 6118714275f0a ("pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()"). This commit fixes the Device Tree to use the proper "gpo" function for MPP7, which fixes the boot of OpenBlocks A7, which was broken since Linux 4.11. Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform") Cc: Signed-off-by: Thomas Petazzoni Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 06faf7c003bf6c43ec1200029c680d8f051dd5f6 Author: Steven Rostedt (VMware) Date: Thu Jan 18 15:53:10 2018 -0500 tracing: Fix converting enum's from the map in trace_event_eval_update() [ Upstream commit 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 ] Since enums do not get converted by the TRACE_EVENT macro into their values, the event format displaces the enum name and not the value. This breaks tools like perf and trace-cmd that need to interpret the raw binary data. To solve this, an enum map was created to convert these enums into their actual numbers on boot up. This is done by TRACE_EVENTS() adding a TRACE_DEFINE_ENUM() macro. Some enums were not being converted. This was caused by an optization that had a bug in it. All calls get checked against this enum map to see if it should be converted or not, and it compares the call's system to the system that the enum map was created under. If they match, then they call is processed. To cut down on the number of iterations needed to find the maps with a matching system, since calls and maps are grouped by system, when a match is made, the index into the map array is saved, so that the next call, if it belongs to the same system as the previous call, could start right at that array index and not have to scan all the previous arrays. The problem was, the saved index was used as the variable to know if this is a call in a new system or not. If the index was zero, it was assumed that the call is in a new system and would keep incrementing the saved index until it found a matching system. The issue arises when the first matching system was at index zero. The next map, if it belonged to the same system, would then think it was the first match and increment the index to one. If the next call belong to the same system, it would begin its search of the maps off by one, and miss the first enum that should be converted. This left a single enum not converted properly. Also add a comment to describe exactly what that index was for. It took me a bit too long to figure out what I was thinking when debugging this issue. Link: http://lkml.kernel.org/r/717BE572-2070-4C1E-9902-9F2E0FEDA4F8@oracle.com Cc: stable@vger.kernel.org Fixes: 0c564a538aa93 ("tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values") Reported-by: Chuck Lever Teste-by: Chuck Lever Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit cdbf7583af3eecbcd2f54c46f0faf0fc870a323e Author: Johan Hovold Date: Mon Jan 8 17:17:48 2018 -0800 Input: twl6040-vibra - fix child-node lookup [ Upstream commit dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at parent rather than just matching on its children. Later sanity checks on node properties (which would likely be missing) should prevent this from causing much trouble however, especially as the original premature free of the parent node has already been fixed separately (but that "fix" was apparently never backported to stable). Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support") Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management") Cc: stable # 3.6 Signed-off-by: Johan Hovold Acked-by: Peter Ujfalusi Tested-by: H. Nikolaus Schaller (on Pyra OMAP5 hardware) Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 83de113f2ed9a971d1db3b2ec74d4aa0252ee2ec Author: H. Nikolaus Schaller Date: Mon May 9 17:01:01 2016 -0700 Input: twl6040-vibra - fix DT node memory management [ Upstream commit c52c545ead97fcc2f4f8ea38f1ae3c23211e09a8 ] commit e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support") made the separate vibra DT node to a subnode of the twl6040. It now calls of_find_node_by_name() to locate the "vibra" subnode. This function has a side effect to call of_node_put on() for the twl6040 parent node passed in as a parameter. This causes trouble later on. Solution: we must call of_node_get() before of_find_node_by_name() Signed-off-by: H. Nikolaus Schaller Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 7c54647c02652f19c53f24378024865a137160fe Author: Johan Hovold Date: Mon Jan 8 17:20:18 2018 -0800 Input: 88pm860x-ts - fix child-node lookup [ Upstream commit 906bf7daa0618d0ef39f4872ca42218c29a3631f ] Fix child node-lookup during probe, which ended up searching the whole device tree depth-first starting at parent rather than just matching on its children. To make things worse, the parent node was prematurely freed, while the child node was leaked. Fixes: 2e57d56747e6 ("mfd: 88pm860x: Device tree support") Cc: stable # 3.7 Signed-off-by: Johan Hovold Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit f3a06c0160bad89abdc2e3ae1114044ecdd65963 Author: Joe Lawrence Date: Fri Nov 17 15:29:21 2017 -0800 pipe: avoid round_pipe_size() nr_pages overflow on 32-bit [ Upstream commit d3f14c485867cfb2e0c48aa88c41d0ef4bf5209c ] round_pipe_size() contains a right-bit-shift expression which may overflow, which would cause undefined results in a subsequent roundup_pow_of_two() call. static inline unsigned int round_pipe_size(unsigned int size) { unsigned long nr_pages; nr_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; return roundup_pow_of_two(nr_pages) << PAGE_SHIFT; } PAGE_SIZE is defined as (1UL << PAGE_SHIFT), so: - 4 bytes wide on 32-bit (0 to 0xffffffff) - 8 bytes wide on 64-bit (0 to 0xffffffffffffffff) That means that 32-bit round_pipe_size(), nr_pages may overflow to 0: size=0x00000000 nr_pages=0x0 size=0x00000001 nr_pages=0x1 size=0xfffff000 nr_pages=0xfffff size=0xfffff001 nr_pages=0x0 << ! size=0xffffffff nr_pages=0x0 << ! This is bad because roundup_pow_of_two(n) is undefined when n == 0! 64-bit is not a problem as the unsigned int size is 4 bytes wide (similar to 32-bit) and the larger, 8 byte wide unsigned long, is sufficient to handle the largest value of the bit shift expression: size=0xffffffff nr_pages=100000 Modify round_pipe_size() to return 0 if n == 0 and updates its callers to handle accordingly. Link: http://lkml.kernel.org/r/1507658689-11669-3-git-send-email-joe.lawrence@redhat.com Signed-off-by: Joe Lawrence Reported-by: Mikulas Patocka Reviewed-by: Mikulas Patocka Cc: Al Viro Cc: Jens Axboe Cc: Michael Kerrisk Cc: Randy Dunlap Cc: Josh Poimboeuf Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4fddec525c9a0331be47ab58cf26cb8dd978b919 Author: Andi Kleen Date: Tue Jan 16 12:52:28 2018 -0800 module: Add retpoline tag to VERMAGIC [ Upstream commit 6cfb521ac0d5b97470883ff9b7facae264b7ab12 ] Add a marker for retpoline to the module VERMAGIC. This catches the case when a non RETPOLINE compiled module gets loaded into a retpoline kernel, making it insecure. It doesn't handle the case when retpoline has been runtime disabled. Even in this case the match of the retcompile status will be enforced. This implies that even with retpoline run time disabled all modules loaded need to be recompiled. Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Acked-by: David Woodhouse Cc: rusty@rustcorp.com.au Cc: arjan.van.de.ven@intel.com Cc: jeyu@kernel.org Cc: torvalds@linux-foundation.org Link: https://lkml.kernel.org/r/20180116205228.4890-1-andi@firstfloor.org Signed-off-by: Sasha Levin commit b866e768648fcd0b46fe6ba4a21577c12fb42ba1 Author: Eric Biggers Date: Fri Dec 29 18:15:23 2017 -0600 af_key: fix buffer overread in parse_exthdrs() [ Upstream commit 4e765b4972af7b07adcb1feb16e7a525ce1f6b28 ] If a message sent to a PF_KEY socket ended with an incomplete extension header (fewer than 4 bytes remaining), then parse_exthdrs() read past the end of the message, into uninitialized memory. Fix it by returning -EINVAL in this case. Reproducer: #include #include #include int main() { int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2); char buf[17] = { 0 }; struct sadb_msg *msg = (void *)buf; msg->sadb_msg_version = PF_KEY_V2; msg->sadb_msg_type = SADB_DELETE; msg->sadb_msg_len = 2; write(sock, buf, 17); } Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ef5be9afe0eb4edcd711ad2ddb3fa25ad1bdcbda Author: Eric Biggers Date: Fri Dec 29 18:13:05 2017 -0600 af_key: fix buffer overread in verify_address_len() [ Upstream commit 06b335cb51af018d5feeff5dd4fd53847ddb675a ] If a message sent to a PF_KEY socket ended with one of the extensions that takes a 'struct sadb_address' but there were not enough bytes remaining in the message for the ->sa_family member of the 'struct sockaddr' which is supposed to follow, then verify_address_len() read past the end of the message, into uninitialized memory. Fix it by returning -EINVAL in this case. This bug was found using syzkaller with KMSAN. Reproducer: #include #include #include int main() { int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2); char buf[24] = { 0 }; struct sadb_msg *msg = (void *)buf; struct sadb_address *addr = (void *)(msg + 1); msg->sadb_msg_version = PF_KEY_V2; msg->sadb_msg_type = SADB_DELETE; msg->sadb_msg_len = 3; addr->sadb_address_len = 1; addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; write(sock, buf, 24); } Reported-by: Alexander Potapenko Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit b04b590eab4a13cbfa0b5e43bc91c496ce997ef9 Author: Takashi Iwai Date: Wed Jan 10 10:53:18 2018 +0100 ALSA: hda - Apply the existing quirk to iMac 14,1 [ Upstream commit 031f335cda879450095873003abb03ae8ed3b74a ] iMac 14,1 requires the same quirk as iMac 12,2, using GPIO 2 and 3 for headphone and speaker output amps. Add the codec SSID quirk entry (106b:0600) accordingly. BugLink: http://lkml.kernel.org/r/CAEw6Zyteav09VGHRfD5QwsfuWv5a43r0tFBNbfcHXoNrxVz7ew@mail.gmail.com Reported-by: Freaky Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 99811c7f694996108baaa9a79dfcd4cf9c3f927f Author: Takashi Iwai Date: Wed Jan 10 08:34:28 2018 +0100 ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant [ Upstream commit e4c9fd10eb21376f44723c40ad12395089251c28 ] There is another Dell XPS 13 variant (SSID 1028:082a) that requires the existing fixup for reducing the headphone noise. This patch adds the quirk entry for that. BugLink: http://lkml.kernel.org/r/CAHXyb9ZCZJzVisuBARa+UORcjRERV8yokez=DP1_5O5isTz0ZA@mail.gmail.com Reported-and-tested-by: Francisco G. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a1f74b6594ef1afdc41652251e76f743a66b3277 Author: Takashi Iwai Date: Wed Jan 10 23:48:05 2018 +0100 ALSA: pcm: Remove yet superfluous WARN_ON() [ Upstream commit 23b19b7b50fe1867da8d431eea9cd3e4b6328c2c ] muldiv32() contains a snd_BUG_ON() (which is morphed as WARN_ON() with debug option) for checking the case of 0 / 0. This would be helpful if this happens only as a logical error; however, since the hw refine is performed with any data set provided by user, the inconsistent values that can trigger such a condition might be passed easily. Actually, syzbot caught this by passing some zero'ed old hw_params ioctl. So, having snd_BUG_ON() there is simply superfluous and rather harmful to give unnecessary confusions. Let's get rid of it. Reported-by: syzbot+7e6ee55011deeebce15d@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c3e715e4a45301380a1ae1f677de2f1a428b6349 Author: Li Jinyue Date: Thu Dec 14 17:04:54 2017 +0800 futex: Prevent overflow by strengthen input validation [ Upstream commit fbe0e839d1e22d88810f3ee3e2f1479be4c0aa4a ] UBSAN reports signed integer overflow in kernel/futex.c: UBSAN: Undefined behaviour in kernel/futex.c:2041:18 signed integer overflow: 0 - -2147483648 cannot be represented in type 'int' Add a sanity check to catch negative values of nr_wake and nr_requeue. Signed-off-by: Li Jinyue Signed-off-by: Thomas Gleixner Cc: peterz@infradead.org Cc: dvhart@infradead.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1513242294-31786-1-git-send-email-lijinyue@huawei.com Signed-off-by: Sasha Levin commit 3170e194abb27e295da07d215bfbc8ceca21f1df Author: Hannes Reinecke Date: Fri Apr 7 09:34:12 2017 +0200 scsi: sg: disable SET_FORCE_LOW_DMA [ Upstream commit 745dfa0d8ec26b24f3304459ff6e9eacc5c8351b ] The ioctl SET_FORCE_LOW_DMA has never worked since the initial git check-in, and the respective setting is nowadays handled correctly. So disable it entirely. Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 539142804971ee10ff0370d19d6e1ee5bc45babc Author: David Woodhouse Date: Thu Jan 11 21:46:32 2018 +0000 x86/retpoline/checksum32: Convert assembler indirect jumps [ Upstream commit 5096732f6f695001fa2d6f1335a2680b37912c69 ] Convert all indirect jumps in 32bit checksum assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Acked-by: Arjan van de Ven Acked-by: Ingo Molnar Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel Cc: Andi Kleen Cc: Josh Poimboeuf Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Dave Hansen Cc: Kees Cook Cc: Tim Chen Cc: Greg Kroah-Hartman Cc: Paul Turner Link: https://lkml.kernel.org/r/1515707194-20531-11-git-send-email-dwmw@amazon.co.uk Signed-off-by: Sasha Levin commit d0fcf17fad2a999c36b6e4456d6f1fa139777036 Author: Masahiro Yamada Date: Tue Jun 14 14:58:54 2016 +0900 kconfig.h: use __is_defined() to check if MODULE is defined [ Upstream commit 4f920843d248946545415c1bf6120942048708ed ] The macro MODULE is not a config option, it is a per-file build option. So, config_enabled(MODULE) is not sensible. (There is another case in include/linux/export.h, where config_enabled() is used against a non-config option.) This commit renames some macros in include/linux/kconfig.h for the use for non-config macros and replaces config_enabled(MODULE) with __is_defined(MODULE). I am keeping config_enabled() because it is still referenced from some places, but I expect it would be deprecated in the future. Signed-off-by: Masahiro Yamada Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit d55f56c8b2375f1a869bdfb7a723f09ce539ffa0 Author: Al Viro Date: Mon Jan 11 10:54:54 2016 -0500 EXPORT_SYMBOL() for asm [ Upstream commit 22823ab419d8ed884195cfa75483fd3a99bb1462 ] Add asm-usable variants of EXPORT_SYMBOL/EXPORT_SYMBOL_GPL. This commit just adds the default implementation; most of the architectures can simply add export.h to asm/Kbuild and start using from assembler. The rest needs to have their define everal macros and then explicitly include One area where the things might diverge from default is the alignment; normally it's 8 bytes on 64bit targets and 4 on 32bit ones, both for unsigned long and for struct kernel_symbol. Unfortunately, amd64 and m68k are unusual - m68k aligns to 2 bytes (for both) and amd64 aligns struct kernel_symbol to 16 bytes. For those we'll need asm/export.h to override the constants used by generic version - KSYM_ALIGN and KCRC_ALIGN for kernel_symbol and unsigned long resp. And no, __alignof__ would not do the trick - on amd64 __alignof__ of struct kernel_symbol is 8, not 16. More serious source of unpleasantness is treatment of function descriptors on architectures that have those. Things like ppc64, parisc, ia64, etc. need more than the address of the first insn to call an arbitrary function. As the result, their representation of pointers to functions is not the typical "address of the entry point" - it's an address of a small static structure containing all the required information (including the entry point, of course). Sadly, the asm-side conventions differ in what the function name refers to - entry point or the function descriptor. On ppc64 we do the latter; bar: .quad foo is what void (*bar)(void) = foo; turns into and the rare places where we need to explicitly work with the label of entry point are dealt with as DOTSYM(foo). For our purposes it's ideal - generic macros are usable. However, parisc would have foo and P%foo used for label of entry point and address of the function descriptor and bar: .long P%foo woudl be used instead. ia64 goes similar to parisc in that respect, except that there it's @fptr(foo) rather than P%foo. Such architectures need to define KSYM_FUNC that would turn a function name into whatever is needed to refer to function descriptor. What's more, on such architectures we need to know whether we are exporting a function or an object - in assembler we have to tell that explicitly, to decide whether we want EXPORT_SYMBOL(foo) produce e.g. __ksymtab_foo: .quad foo or __ksymtab_foo: .quad @fptr(foo) For that reason we introduce EXPORT_DATA_SYMBOL{,_GPL}(), to be used for exports of data objects. On normal architectures it's the same thing as EXPORT_SYMBOL{,_GPL}(), but on parisc-like ones they differ and the right one needs to be used. Most of the exports are functions, so we keep EXPORT_SYMBOL for those... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit b2798db0a49c83ab3a6cc93764804a9a62c2246e Author: Andy Lutomirski Date: Tue Apr 26 12:23:25 2016 -0700 x86/asm: Make asm/alternative.h safe from assembly [ Upstream commit f005f5d860e0231fe212cfda8c1a3148b99609f4 ] asm/alternative.h isn't directly useful from assembly, but it shouldn't break the build. Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/e5b693fcef99fe6e80341c9e97a002fb23871e91.1461698311.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 2838442092e6b2bc3b7047e47830f71fafe4d326 Author: Adam Borowski Date: Sun Dec 11 02:09:18 2016 +0100 x86/kbuild: enable modversions for symbols exported from asm [ Upstream commit 334bb773876403eae3457d81be0b8ea70f8e4ccc ] Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds modversion support for symbols exported from asm files. Architectures must include C-style declarations for those symbols in asm/asm-prototypes.h in order for them to be versioned. Add these declarations for x86, and an architecture-independent file that can be used for common symbols. With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we produce a scary warning on x86, this commit fixes that. Signed-off-by: Adam Borowski Tested-by: Kalle Valo Acked-by: Nicholas Piggin Tested-by: Peter Wu Tested-by: Oliver Hartkopp Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit 3ea2a5da9fd85be142a0c538c50fbb058df76e93 Author: Andrey Ryabinin Date: Fri Sep 29 17:15:36 2017 +0300 x86/asm: Use register variable to get stack pointer value [ Upstream commit 196bd485ee4f03ce4c690bfcf38138abfcd0a4bc ] Currently we use current_stack_pointer() function to get the value of the stack pointer register. Since commit: f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang") ... we have a stack register variable declared. It can be used instead of current_stack_pointer() function which allows to optimize away some excessive "mov %rsp, %" instructions: -mov %rsp,%rdx -sub %rdx,%rax -cmp $0x3fff,%rax -ja ffffffff810722fd +sub %rsp,%rax +cmp $0x3fff,%rax +ja ffffffff810722fa Remove current_stack_pointer(), rename __asm_call_sp to current_stack_pointer and use it instead of the removed function. Signed-off-by: Andrey Ryabinin Reviewed-by: Josh Poimboeuf Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20170929141537.29167-1-aryabinin@virtuozzo.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 53177c75177ecfd71b01da9d5b16ddd1610b1919 Author: Arnd Bergmann Date: Mon Apr 25 17:35:29 2016 +0200 gcov: disable for COMPILE_TEST [ Upstream commit cc622420798c4bcf093785d872525087a7798db9 ] Enabling gcov is counterproductive to compile testing: it significantly increases the kernel image size, compile time, and it produces lots of false positive "may be used uninitialized" warnings as the result of missed optimizations. This is in line with how UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES work, both of which have similar problems. With an ARM allmodconfig kernel, I see the build time drop from 283 minutes CPU time to 225 minutes, and the vmlinux size drops from 43MB to 26MB. Signed-off-by: Arnd Bergmann Acked-by: Peter Oberparleiter Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit 3c7adb876d401e67e2946fbd9f527dc137b67656 Author: David Woodhouse Date: Thu Jan 4 14:37:05 2018 +0000 x86/alternatives: Add missing '\n' at end of ALTERNATIVE inline asm [ Upstream commit b9e705ef7cfaf22db0daab91ad3cd33b0fa32eb9 ] Where an ALTERNATIVE is used in the middle of an inline asm block, this would otherwise lead to the following instruction being appended directly to the trailing ".popsection", and a failed compile. Fixes: 9cebed423c84 ("x86, alternative: Use .pushsection/.popsection") Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel Cc: ak@linux.intel.com Cc: Tim Chen Cc: Peter Zijlstra Cc: Paul Turner Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Dave Hansen Cc: Kees Cook Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180104143710.8961-8-dwmw@amazon.co.uk Signed-off-by: Sasha Levin commit b1a9b3a6389a2fd3d92bb7ea96f1864f75d4f786 Author: Borislav Petkov Date: Wed Jan 10 12:28:16 2018 +0100 x86/alternatives: Fix optimize_nops() checking [ Upstream commit 612e8e9350fd19cae6900cf36ea0c6892d1a0dca ] The alternatives code checks only the first byte whether it is a NOP, but with NOPs in front of the payload and having actual instructions after it breaks the "optimized' test. Make sure to scan all bytes before deciding to optimize the NOPs in there. Reported-by: David Woodhouse Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Tom Lendacky Cc: Andi Kleen Cc: Tim Chen Cc: Peter Zijlstra Cc: Jiri Kosina Cc: Dave Hansen Cc: Andi Kleen Cc: Andrew Lutomirski Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Paul Turner Link: https://lkml.kernel.org/r/20180110112815.mgciyf5acwacphkq@pd.tnic Signed-off-by: Sasha Levin commit ad3582ec4b98064bc012ed0cd9ff63471bd6d0a0 Author: Thomas Gleixner Date: Mon Dec 4 15:07:32 2017 +0100 x86/cpufeatures: Make CPU bugs sticky [ Upstream commit 6cbd2171e89b13377261d15e64384df60ecb530e ] There is currently no way to force CPU bug bits like CPU feature bits. That makes it impossible to set a bug bit once at boot and have it stick for all upcoming CPUs. Extend the force set/clear arrays to handle bug bits as well. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Dave Hansen Cc: David Laight Cc: Denys Vlasenko Cc: Eduardo Valentin Cc: Greg KH Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: Will Deacon Cc: aliguori@amazon.com Cc: daniel.gruss@iaik.tugraz.at Cc: hughd@google.com Cc: keescook@google.com Link: https://lkml.kernel.org/r/20171204150606.992156574@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit d0a64e30b43de96507d37e84362a155ccb25940f Author: Andy Lutomirski Date: Wed Jan 18 11:15:38 2017 -0800 x86/cpu: Factor out application of forced CPU caps [ Upstream commit 8bf1ebca215c262e48c15a4a15f175991776f57f ] There are multiple call sites that apply forced CPU caps. Factor them into a helper. Signed-off-by: Andy Lutomirski Reviewed-by: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Fenghua Yu Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Matthew Whitehead Cc: Oleg Nesterov Cc: One Thousand Gnomes Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Yu-cheng Yu Link: http://lkml.kernel.org/r/623ff7555488122143e4417de09b18be2085ad06.1484705016.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 505070e920779a19d8e1386d45178459bd479587 Author: Benjamin Poirier Date: Mon Dec 11 16:26:40 2017 +0900 e1000e: Fix e1000_check_for_copper_link_ich8lan return value. [ Upstream commit 4110e02eb45ea447ec6f5459c9934de0a273fb91 ] e1000e_check_for_copper_link() and e1000_check_for_copper_link_ich8lan() are the two functions that may be assigned to mac.ops.check_for_link when phy.media_type == e1000_media_type_copper. Commit 19110cfbb34d ("e1000e: Separate signaling for link check/link up") changed the meaning of the return value of check_for_link for copper media but only adjusted the first function. This patch adjusts the second function likewise. Reported-by: Christian Hesse Reported-by: Gabriel C Link: https://bugzilla.kernel.org/show_bug.cgi?id=198047 Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up") Signed-off-by: Benjamin Poirier Tested-by: Aaron Brown Tested-by: Christian Hesse Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit bac5a7ef66b31585b3e3c512c335561d14c3a861 Author: Icenowy Zheng Date: Sat Jan 6 00:56:44 2018 +0800 uas: ignore UAS for Norelsys NS1068(X) chips [ Upstream commit 928afc85270753657b5543e052cc270c279a3fe9 ] The UAS mode of Norelsys NS1068(X) is reported to fail to work on several platforms with the following error message: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream ring slot 1 ep 8 xhci-hcd xhci-hcd.0.auto: @00000000bf04a400 00000000 00000000 1b000000 01098001 And when trying to mount a partition on the disk the disk will disconnect from the USB controller, then after re-connecting the device will be offlined and not working at all. Falling back to USB mass storage can solve this problem, so ignore UAS function of this chip. Cc: stable@vger.kernel.org Signed-off-by: Icenowy Zheng Acked-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 395cba875fa35b1a23d2bd1951c555d3d0a5d5be Author: Ben Seri Date: Fri Dec 8 15:14:47 2017 +0100 Bluetooth: Prevent stack info leak from the EFS element. [ Upstream commit 06e7e776ca4d36547e503279aeff996cbb292c16 ] In the function l2cap_parse_conf_rsp and in the function l2cap_parse_conf_req the following variable is declared without initialization: struct l2cap_conf_efs efs; In addition, when parsing input configuration parameters in both of these functions, the switch case for handling EFS elements may skip the memcpy call that will write to the efs variable: ... case L2CAP_CONF_EFS: if (olen == sizeof(efs)) memcpy(&efs, (void *)val, olen); ... The olen in the above if is attacker controlled, and regardless of that if, in both of these functions the efs variable would eventually be added to the outgoing configuration request that is being built: l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs); So by sending a configuration request, or response, that contains an L2CAP_CONF_EFS element, but with an element length that is not sizeof(efs) - the memcpy to the uninitialized efs variable can be avoided, and the uninitialized variable would be returned to the attacker (16 bytes). This issue has been assigned CVE-2017-1000410 Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Cc: stable Signed-off-by: Ben Seri Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 700dbec6cafafbe5e018a90e8e92a4762c19884d Author: Viktor Slavkovic Date: Mon Jan 8 10:43:03 2018 -0800 staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl [ Upstream commit 443064cb0b1fb4569fe0a71209da7625129fb760 ] A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a race condition when mmap is called. After the !asma->file check, before setting asma->size, asma->file can be set in mmap. That would result in having different asma->size than the mapped memory size. Combined with ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory corruption. Signed-off-by: Viktor Slavkovic Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1ddd68590f12d4dadd2552b72bd377e8b78eb5b2 Author: Shuah Khan Date: Fri Dec 22 17:00:06 2017 -0700 usbip: remove kernel addresses from usb device and urb debug msgs [ Upstream commit e1346fd87c71a1f61de1fe476ec8df1425ac931c ] usbip_dump_usb_device() and usbip_dump_urb() print kernel addresses. Remove kernel addresses from usb device and urb debug msgs and improve the message content. Instead of printing parent device and bus addresses, print parent device and bus names. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f111a03673a47422a1ebe8c661628b1a93ce070a Author: Pete Zaitcev Date: Mon Jan 8 15:46:41 2018 -0600 USB: fix usbmon BUG trigger [ Upstream commit 46eb14a6e1585d99c1b9f58d0e7389082a5f466b ] Automated tests triggered this by opening usbmon and accessing the mmap while simultaneously resizing the buffers. This bug was with us since 2006, because typically applications only size the buffers once and thus avoid racing. Reported by Kirill A. Shutemov. Reported-by: Signed-off-by: Pete Zaitcev Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 89edb7f8e2533dedf8970235b6b7e2c2204a76ec Author: Stefan Agner Date: Thu Jan 11 14:47:40 2018 +0100 usb: misc: usb3503: make sure reset is low for at least 100us [ Upstream commit b8626f1dc29d3eee444bfaa92146ec7b291ef41c ] When using a GPIO which is high by default, and initialize the driver in USB Hub mode, initialization fails with: [ 111.757794] usb3503 0-0008: SP_ILOCK failed (-5) The reason seems to be that the chip is not properly reset. Probe does initialize reset low, however some lines later the code already set it back high, which is not long enouth. Make sure reset is asserted for at least 100us by inserting a delay after initializing the reset pin during probe. Signed-off-by: Stefan Agner Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 825c49e5c623a808fbac88ffed68691f74532b01 Author: Christian Holl Date: Wed Jan 3 19:53:02 2018 +0100 USB: serial: cp210x: add new device ID ELV ALC 8xxx [ Upstream commit d14ac576d10f865970bb1324d337e5e24d79aaf4 ] This adds the ELV ALC 8xxx Battery Charging device to the list of USB IDs of drivers/usb/serial/cp210x.c Signed-off-by: Christian Holl Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 0036294eb4f2c43a9a753e704747482b439fe21f Author: Diego Elio Pettenò Date: Fri Dec 29 09:54:25 2017 +0000 USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ [ Upstream commit 4307413256ac1e09b8f53e8715af3df9e49beec3 ] Add IDs for the OneTouch Verio IQ that comes with an embedded USB-to-serial converter. Signed-off-by: Diego Elio Pettenò Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 7517b7d0cf83db83049c2af59d56d1cacea3c556 Author: Nicholas Bellinger Date: Fri Oct 27 12:32:59 2017 -0700 iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref [ Upstream commit ae072726f6109bb1c94841d6fb3a82dde298ea85 ] Since commit 59b6986dbf fixed a potential NULL pointer dereference by allocating a se_tmr_req for ISCSI_TM_FUNC_TASK_REASSIGN, the se_tmr_req is currently leaked by iscsit_free_cmd() because no iscsi_cmd->se_cmd.se_tfo was associated. To address this, treat ISCSI_TM_FUNC_TASK_REASSIGN like any other TMR and call transport_init_se_cmd() + target_get_sess_cmd() to setup iscsi_cmd->se_cmd.se_tfo with se_cmd->cmd_kref of 2. This will ensure normal release operation once se_cmd->cmd_kref reaches zero and target_release_cmd_kref() is invoked, se_tmr_req will be released via existing target_free_cmd_mem() and core_tmr_release_req() code. Reported-by: Donald White Cc: Donald White Cc: Mike Christie Cc: Hannes Reinecke Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 285d5c2b85e906e986b521960fe7dc4a527f2a00 Author: Andrew Honig Date: Wed Jan 10 10:12:03 2018 -0800 KVM: x86: Add memory barrier on vmcs field lookup [ Upstream commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 ] This adds a memory barrier when performing a lookup into the vmcs_field_to_offset_table. This is related to CVE-2017-5753. Signed-off-by: Andrew Honig Reviewed-by: Jim Mattson Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit cf72e4711a79eb0a17fbdf029ad2a2ee4c932110 Author: Jia Zhang Date: Mon Jan 1 10:04:47 2018 +0800 x86/microcode/intel: Extend BDW late-loading with a revision check [ Upstream commit b94b7373317164402ff7728d10f7023127a02b60 ] Instead of blacklisting all model 79 CPUs when attempting a late microcode loading, limit that only to CPUs with microcode revisions < 0x0b000021 because only on those late loading may cause a system hang. For such processors either: a) a BIOS update which might contain a newer microcode revision or b) the early microcode loading method should be considered. Processors with revisions 0x0b000021 or higher will not experience such hangs. For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017. [ bp: Heavily massage commit message and pr_* statements. ] Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79") Signed-off-by: Jia Zhang Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Acked-by: Tony Luck Cc: x86-ml Cc: # v4.14 Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Sasha Levin commit c44d7ab86e0056f35c4e8a301240de8e1ab20fa8 Author: Eric Biggers Date: Fri Dec 29 14:30:19 2017 -0600 crypto: algapi - fix NULL dereference in crypto_remove_spawns() [ Upstream commit 9a00674213a3f00394f4e3221b88f2d21fc05789 ] syzkaller triggered a NULL pointer dereference in crypto_remove_spawns() via a program that repeatedly and concurrently requests AEADs "authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)" through AF_ALG, where the hashes are requested as "untested" (CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this causes the template to be instantiated for every request). Although AF_ALG users really shouldn't be able to request an "untested" algorithm, the NULL pointer dereference is actually caused by a longstanding race condition where crypto_remove_spawns() can encounter an instance which has had spawn(s) "grabbed" but hasn't yet been registered, resulting in ->cra_users still being NULL. We probably should properly initialize ->cra_users earlier, but that would require updating many templates individually. For now just fix the bug in a simple way that can easily be backported: make crypto_remove_spawns() treat a NULL ->cra_users list as empty. Reported-by: syzbot Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 36441e8109b4000709139960fab10f19a9cbbc78 Author: Eric Dumazet Date: Wed Jan 10 03:45:49 2018 -0800 ipv6: fix possible mem leaks in ipv6_make_skb() [ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ] ip6_setup_cork() might return an error, while memory allocations have been done and must be rolled back. Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb") Signed-off-by: Eric Dumazet Cc: Vlad Yasevich Reported-by: Mike Maloney Acked-by: Mike Maloney Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b8e7891e05e9585efd9d98ab15fa8b80507cc7ee Author: Sergei Shtylyov Date: Thu Jan 4 21:06:49 2018 +0300 sh_eth: fix SH7757 GEther initialization [ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ] Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the 'sh_eth' driver can only reset and initialize TSU of the first controller pair. Shimoda-san tried to solve that adding the 'needs_init' member to the 'struct sh_eth_plat_data', however the platform code still never sets this flag. I think that we can infer this information from the 'devno' variable (set to 'platform_device::id') and reset/init the Ether controller pair only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be removed... Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization") Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f60bb9ac70071a300aa81a32d8c629175ef7929 Author: Sergei Shtylyov Date: Wed Jan 3 20:09:49 2018 +0300 sh_eth: fix TSU resource handling [ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ] When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ad99858fa14a888b77dc2095f412e443639f953c Author: Mohamed Ghannam Date: Wed Jan 3 21:06:06 2018 +0000 RDS: null pointer dereference in rds_atomic_free_op [ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ] set rm->atomic.op_active to 0 when rds_pin_pages() fails or the user supplied address is invalid, this prevents a NULL pointer usage in rds_atomic_free_op() Signed-off-by: Mohamed Ghannam Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4b1ffce255006f1220fce0f24772b9563ed91088 Author: Mohamed Ghannam Date: Tue Jan 2 19:44:34 2018 +0000 RDS: Heap OOB write in rds_message_alloc_sgs() [ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ] When args->nr_local is 0, nr_pages gets also 0 due some size calculation via rds_rm_size(), which is later used to allocate pages for DMA, this bug produces a heap Out-Of-Bound write access to a specific memory region. Signed-off-by: Mohamed Ghannam Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c159a359147b37e5600bcff279d893db3bdb20c Author: Cong Wang Date: Tue Jan 9 13:40:41 2018 -0800 8021q: fix a memory leak for VLAN 0 device [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ] A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich Cc: Ben Hutchings Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 77b021d1d68f08bd713d4c1eb3892d4924c20a2f Author: Ani Sinha Date: Thu Dec 17 17:15:10 2015 -0800 sysrq: Fix warning in sysrq generated crash. [ Upstream commit 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b ] Commit 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") replaced spin_lock_irqsave() calls with rcu_read_lock() calls in sysrq. Since rcu_read_lock() does not disable preemption, faulthandler_disabled() in __do_page_fault() in x86/fault.c returns false. When the code later calls might_sleep() in the pagefault handler, we get the following warning: BUG: sleeping function called from invalid context at ../arch/x86/mm/fault.c:1187 in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash Preemption disabled at:[] printk+0x48/0x4a To fix this, we release the RCU read lock before we crash. Tested this patch on linux 3.18 by booting off one of our boards. Fixes: 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") Signed-off-by: Ani Sinha Reviewed-by: Rik van Riel Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 161831749a473ba34c53c749866dc0f45cbc21a1 Author: Jiri Slaby Date: Fri Nov 27 16:50:43 2015 +0100 hwrng: core - sleep interruptible in read [ Upstream commit 1ab87298cb59b649d8d648d25dc15b36ab865f5a ] hwrng kthread can be waiting via hwrng_fillfn for some data from a rng like virtio-rng: hwrng D ffff880093e17798 0 382 2 0x00000000 ... Call Trace: [] wait_for_completion_killable+0x96/0x210 [] virtio_read+0x57/0xf0 [virtio_rng] [] hwrng_fillfn+0x75/0x130 [] kthread+0xf3/0x110 And when some user program tries to read the /dev node in this state, we get: rngd D ffff880093e17798 0 762 1 0x00000004 ... Call Trace: [] mutex_lock_nested+0x15c/0x3e0 [] rng_dev_read+0x6e/0x240 [] __vfs_read+0x28/0xe0 [] vfs_read+0x83/0x130 And this is indeed unkillable. So use mutex_lock_interruptible instead of mutex_lock in rng_dev_read and exit immediatelly when interrupted. And possibly return already read data, if any (as POSIX allows). v2: use ERESTARTSYS instead of EINTR Signed-off-by: Jiri Slaby Cc: Matt Mackall Cc: Herbert Xu Cc: Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 48398e82220ab072178a1be2afb9ac255f303bf6 Author: Eric Dumazet Date: Wed Apr 19 09:59:22 2017 -0700 cx82310_eth: use skb_cow_head() to deal with cloned skbs [ Upstream commit a9e840a2081ed28c2b7caa6a9a0041c950b3c37d ] We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver") Signed-off-by: Eric Dumazet Cc: James Hughes Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4588d8b83fa1eec01257d74cdf241bd16f585924 Author: Eric Dumazet Date: Wed Apr 19 09:59:21 2017 -0700 smsc75xx: use skb_cow_head() to deal with cloned skbs [ Upstream commit b7c6d2675899cfff0180412c63fc9cbd5bacdb4d ] We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Signed-off-by: Eric Dumazet Cc: James Hughes Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 543fb72909618d718d2b32a1904ac9c13dcf23b9 Author: Eric Dumazet Date: Wed Apr 19 09:59:23 2017 -0700 sr9700: use skb_cow_head() to deal with cloned skbs [ Upstream commit d532c1082f68176363ed766d09bf187616e282fe ] We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Signed-off-by: Eric Dumazet Cc: James Hughes Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ad914ce56e7bdc918c12264e809a64504a410547 Author: hayeswang Date: Thu Jan 7 17:51:11 2016 +0800 r8152: use test_and_clear_bit [ Upstream commit 216a8349d3a0dd1bc2afbcc821e374c8f929bd62 ] Replace test_bit() followed by clear_bit() with test_and_clear_bit(). Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7eec5aab8831dacb8bb3def193773b1a4f12d61f Author: Oliver Neukum Date: Tue Oct 27 09:51:34 2015 -0200 [media] usbvision fix overflow of interfaces array [ Upstream commit 588afcc1c0e45358159090d95bf7b246fb67565f ] This fixes the crash reported in: http://seclists.org/bugtraq/2015/Oct/35 The interface number needs a sanity check. Signed-off-by: Oliver Neukum Cc: Vladis Dronov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bebc259e4c0b6983083ca3fb28103ae273313dca Author: Jianyu Zhan Date: Mon Mar 7 09:32:24 2016 +0800 futex: Replace barrier() in unqueue_me() with READ_ONCE() [ Upstream commit 29b75eb2d56a714190a93d7be4525e617591077a ] Commit e91467ecd1ef ("bug in futex unqueue_me") introduced a barrier() in unqueue_me() to prevent the compiler from rereading the lock pointer which might change after a check for NULL. Replace the barrier() with a READ_ONCE() for the following reasons: 1) READ_ONCE() is a weaker form of barrier() that affects only the specific load operation, while barrier() is a general compiler level memory barrier. READ_ONCE() was not available at the time when the barrier was added. 2) Aside of that READ_ONCE() is descriptive and self explainatory while a barrier without comment is not clear to the casual reader. No functional change. [ tglx: Massaged changelog ] Signed-off-by: Jianyu Zhan Acked-by: Christian Borntraeger Acked-by: Darren Hart Cc: dave@stgolabs.net Cc: peterz@infradead.org Cc: linux@rasmusvillemoes.dk Cc: akpm@linux-foundation.org Cc: fengguang.wu@intel.com Cc: bigeasy@linutronix.de Link: http://lkml.kernel.org/r/1457314344-5685-1-git-send-email-nasa4836@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 5ca9119924b247dad338ef7f40883d4019f2cb3e Author: Jeff Layton Date: Fri Jan 8 07:30:43 2016 -0500 locks: don't check for race with close when setting OFD lock [ Upstream commit 0752ba807b04ccd69cb4bc8bbf829a80ee208a3c ] We don't clean out OFD locks on close(), so there's no need to check for a race with them here. They'll get cleaned out at the same time that flock locks are. Signed-off-by: Jeff Layton Acked-by: "J. Bruce Fields" Signed-off-by: Sasha Levin commit 47e9e29fee362d231c7581a1c25431b4e2c5d107 Author: Andrey Ryabinin Date: Tue Mar 15 14:55:27 2016 -0700 mm/page-writeback: fix dirty_ratelimit calculation [ Upstream commit d59b1087a98e402ed9a7cc577f4da435f9a555f5 ] Calculation of dirty_ratelimit sometimes is not correct. E.g. initial values of dirty_ratelimit == INIT_BW and step == 0, lead to the following result: UBSAN: Undefined behaviour in ../mm/page-writeback.c:1286:7 shift exponent 25600 is too large for 64-bit type 'long unsigned int' The fix is straightforward - make step 0 if the shift exponent is too big. Signed-off-by: Andrey Ryabinin Cc: Wu Fengguang Cc: Tejun Heo Cc: Andy Shevchenko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ff295e461f2faae7a520ac3dcc501ef693bd87d3 Author: Takashi Iwai Date: Thu Jan 4 17:38:54 2018 +0100 ALSA: aloop: Fix racy hw constraints adjustment [ Upstream commit 898dfe4687f460ba337a01c11549f87269a13fa2 ] The aloop driver tries to update the hw constraints of the connected target on the cable of the opened PCM substream. This is done by adding the extra hw constraints rules referring to the substream runtime->hw fields, while the other substream may update the runtime hw of another side on the fly. This is, however, racy and may result in the inconsistent values when both PCM streams perform the prepare concurrently. One of the reason is that it overwrites the other's runtime->hw field; which is not only racy but also broken when it's called before the open of another side finishes. And, since the reference to runtime->hw isn't protected, the concurrent write may give the partial value update and become inconsistent. This patch is an attempt to fix and clean up: - The prepare doesn't change the runtime->hw of other side any longer, but only update the cable->hw that is referred commonly. - The extra rules refer to the loopback_pcm object instead of the runtime->hw. The actual hw is deduced from cable->hw. - The extra rules take the cable_lock to protect against the race. Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 86cef8bad441671676079bbda0fdd66ff0316359 Author: Takashi Iwai Date: Fri Jan 5 16:15:33 2018 +0100 ALSA: aloop: Fix inconsistent format due to incomplete rule [ Upstream commit b088b53e20c7d09b5ab84c5688e609f478e5c417 ] The extra hw constraint rule for the formats the aloop driver introduced has a slight flaw, where it doesn't return a positive value when the mask got changed. It came from the fact that it's basically a copy&paste from snd_hw_constraint_mask64(). The original code is supposed to be a single-shot and it modifies the mask bits only once and never after, while what we need for aloop is the dynamic hw rule that limits the mask bits. This difference results in the inconsistent state, as the hw_refine doesn't apply the dependencies fully. The worse and surprisingly result is that it causes a crash in OSS emulation when multiple full-duplex reads/writes are performed concurrently (I leave why it triggers Oops to readers as a homework). For fixing this, replace a few open-codes with the standard snd_mask_*() macros. Reported-by: syzbot+3902b5220e8ca27889ca@syzkaller.appspotmail.com Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b893a6309e7f19bb8a5d91d12bdc10368585fd0f Author: Takashi Iwai Date: Fri Jan 5 16:09:47 2018 +0100 ALSA: aloop: Release cable upon open error path [ Upstream commit 9685347aa0a5c2869058ca6ab79fd8e93084a67f ] The aloop runtime object and its assignment in the cable are left even when opening a substream fails. This doesn't mean any memory leak, but it still keeps the invalid pointer that may be referred by the another side of the cable spontaneously, which is a potential Oops cause. Clean up the cable assignment and the empty cable upon the error path properly. Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 88e649cefa6ade1418b69c519156756310bfae8a Author: Takashi Iwai Date: Mon Jan 8 14:03:53 2018 +0100 ALSA: pcm: Allow aborting mutex lock at OSS read/write loops [ Upstream commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c ] PCM OSS read/write loops keep taking the mutex lock for the whole read/write, and this might take very long when the exceptionally high amount of data is given. Also, since it invokes with mutex_lock(), the concurrent read/write becomes unbreakable. This patch tries to address these issues by replacing mutex_lock() with mutex_lock_interruptible(), and also splits / re-takes the lock at each read/write period chunk, so that it can switch the context more finely if requested. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d8f605888a2dc72bfcb2f30b2412f0bf1e2e1c05 Author: Takashi Iwai Date: Mon Jan 8 13:58:31 2018 +0100 ALSA: pcm: Abort properly at pending signal in OSS read/write loops [ Upstream commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b ] The loops for read and write in PCM OSS emulation have no proper check of pending signals, and they keep processing even after user tries to break. This results in a very long delay, often seen as RCU stall when a huge unprocessed bytes remain queued. The bug could be easily triggered by syzkaller. As a simple workaround, this patch adds the proper check of pending signals and aborts the loop appropriately. Reported-by: syzbot+993cb4cfcbbff3947c21@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3f30e73b418526585d99309fd02b5b56307cb83d Author: Takashi Iwai Date: Thu Jan 4 16:39:27 2018 +0100 ALSA: pcm: Add missing error checks in OSS emulation plugin builder [ Upstream commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d ] In the OSS emulation plugin builder where the frame size is parsed in the plugin chain, some places miss the possible errors returned from the plugin src_ or dst_frames callback. This patch papers over such places. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c20d4fa859ff7bce464c0b126c64886424986a0a Author: Takashi Iwai Date: Mon Jan 1 09:50:50 2018 +0100 ALSA: pcm: Remove incorrect snd_BUG_ON() usages [ Upstream commit fe08f34d066f4404934a509b6806db1a4f700c86 ] syzkaller triggered kernel warnings through PCM OSS emulation at closing a stream: WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635 snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635 Call Trace: .... snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457 snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969 snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128 snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638 snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431 __fput+0x327/0x7e0 fs/file_table.c:210 .... This happens while it tries to open and set up the aloop device concurrently. The warning above (invoked from snd_BUG_ON() macro) is to detect the unexpected logical error where snd_pcm_hw_refine() call shouldn't fail. The theory is true for the case where the hw_params config rules are static. But for an aloop device, the hw_params rule condition does vary dynamically depending on the connected target; when another device is opened and changes the parameters, the device connected in another side is also affected, and it caused the error from snd_pcm_hw_refine(). That is, the simplest "solution" for this is to remove the incorrect assumption of static rules, and treat such an error as a normal error path. As there are a couple of other places using snd_BUG_ON() incorrectly, this patch removes these spurious snd_BUG_ON() calls. Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c35dc4aea3f8624442699e448a12ee300bf40e4b Author: Jim Mattson Date: Wed Jan 3 14:31:38 2018 -0800 kvm: vmx: Scrub hardware GPRs at VM-exit [ Upstream commit 0cb5b30698fdc8f6b4646012e3acb4ddce430788 ] Guest GPR values are live in the hardware GPRs at VM-exit. Do not leave any guest values in hardware GPRs after the guest GPR values are saved to the vcpu_vmx structure. This is a partial mitigation for CVE 2017-5715 and CVE 2017-5753. Specifically, it defeats the Project Zero PoC for CVE 2017-5715. Suggested-by: Eric Northup Signed-off-by: Jim Mattson Reviewed-by: Eric Northup Reviewed-by: Benjamin Serebrin Reviewed-by: Andrew Honig [Paolo: Add AMD bits, Signed-off-by: Tom Lendacky ] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 6ec6823b12c375acc987ea75c33a587a18f15eb1 Author: Maciej W. Rozycki Date: Mon Dec 11 22:56:54 2017 +0000 MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses [ Upstream commit c8c5a3a24d395b14447a9a89d61586a913840a3b ] Complement commit c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout") and also reject outsized PTRACE_SETREGSET requests to the NT_PRFPREG regset, like with the NT_PRSTATUS regset. Signed-off-by: Maciej W. Rozycki Fixes: c23b3d1a5311 ("MIPS: ptrace: Change GP regset to use correct core dump register layout") Cc: James Hogan Cc: Paul Burton Cc: Alex Smith Cc: Dave Martin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v3.17+ Patchwork: https://patchwork.linux-mips.org/patch/17930/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit df70c82b54c15769f0528633dc27c34482a34ddd Author: Maciej W. Rozycki Date: Mon Dec 11 22:55:40 2017 +0000 MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET [ Upstream commit 006501e039eec411842bb3150c41358867d320c2 ] Complement commit d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") and like with the PTRACE_GETREGSET ptrace(2) request also apply a BUILD_BUG_ON check for the size of the `elf_fpreg_t' type in the PTRACE_SETREGSET request handler. Signed-off-by: Maciej W. Rozycki Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") Cc: James Hogan Cc: Paul Burton Cc: Alex Smith Cc: Dave Martin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v4.11+ Patchwork: https://patchwork.linux-mips.org/patch/17929/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit ad37c2694d7e3e6f1051cab70e49efc06179eb9f Author: Maciej W. Rozycki Date: Mon Dec 11 22:54:33 2017 +0000 MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA [ Upstream commit be07a6a1188372b6d19a3307ec33211fc9c9439d ] Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") public API regression, then activated by commit 1db1af84d6df ("MIPS: Basic MSA context switching support"), that caused the FCSR register not to be read or written for CONFIG_CPU_HAS_MSA kernel configurations (regardless of actual presence or absence of the MSA feature in a given processor) with ptrace(2) PTRACE_GETREGSET and PTRACE_SETREGSET requests nor recorded in core dumps. This is because with !CONFIG_CPU_HAS_MSA configurations the whole of `elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA configurations array elements are copied individually, and then only the leading 32 FGR slots while the remaining slot is ignored. Correct the code then such that only FGR slots are copied in the respective !MSA and MSA helpers an then the FCSR slot is handled separately in common code. Use `ptrace_setfcr31' to update the FCSR too, so that the read-only mask is respected. Retrieving a correct value of FCSR is important in debugging not only for the human to be able to get the right interpretation of the situation, but for correct operation of GDB as well. This is because the condition code bits in FSCR are used by GDB to determine the location to place a breakpoint at when single-stepping through an FPU branch instruction. If such a breakpoint is placed incorrectly (i.e. with the condition reversed), then it will be missed, likely causing the debuggee to run away from the control of GDB and consequently breaking the process of investigation. Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2) request which is unaffected, so the regression only really hits with post-mortem debug sessions using a core dump file, in which case execution, and consequently single-stepping through branches is not possible. Of course core files created by buggy kernels out there will have the value of FCSR recorded clobbered, but such core files cannot be corrected and the person using them simply will have to be aware that the value of FCSR retrieved is not reliable. Which also means we can likely get away without defining a replacement API which would ensure a correct value of FSCR to be retrieved, or none at all. This is based on previous work by Alex Smith, extensively rewritten. Signed-off-by: Alex Smith Signed-off-by: James Hogan Signed-off-by: Maciej W. Rozycki Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: Paul Burton Cc: Dave Martin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17928/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit e69b81f071f892185319bf1557d14c29a5a61537 Author: Maciej W. Rozycki Date: Mon Dec 11 22:53:14 2017 +0000 MIPS: Consistently handle buffer counter with PTRACE_SETREGSET [ Upstream commit 80b3ffce0196ea50068885d085ff981e4b8396f4 ] Update commit d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") bug and consistently consume all data supplied to `fpr_set_msa' with the ptrace(2) PTRACE_SETREGSET request, such that a zero data buffer counter is returned where insufficient data has been given to fill a whole number of FP general registers. In reality this is not going to happen, as the caller is supposed to only supply data covering a whole number of registers and it is verified in `ptrace_regset' and again asserted in `fpr_set', however structuring code such that the presence of trailing partial FP general register data causes `fpr_set_msa' to return with a non-zero data buffer counter makes it appear that this trailing data will be used if there are subsequent writes made to FP registers, which is going to be the case with the FCSR once the missing write to that register has been fixed. Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: Paul Burton Cc: Alex Smith Cc: Dave Martin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v4.11+ Patchwork: https://patchwork.linux-mips.org/patch/17927/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 5193a5240ed608b09af61932d09bf7c0dbd57a48 Author: Maciej W. Rozycki Date: Mon Dec 11 22:52:15 2017 +0000 MIPS: Guard against any partial write attempt with PTRACE_SETREGSET [ Upstream commit dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 ] Complement commit d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") and ensure that no partial register write attempt is made with PTRACE_SETREGSET, as we do not preinitialize any temporaries used to hold incoming register data and consequently random data could be written. It is the responsibility of the caller, such as `ptrace_regset', to arrange for writes to span whole registers only, so here we only assert that it has indeed happened. Signed-off-by: Maciej W. Rozycki Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: James Hogan Cc: Paul Burton Cc: Alex Smith Cc: Dave Martin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17926/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 5dcfbb026021c68e04dc3705a5f2bbfffbdaa877 Author: Maciej W. Rozycki Date: Mon Dec 11 22:51:35 2017 +0000 MIPS: Factor out NT_PRFPREG regset access helpers [ Upstream commit a03fe72572c12e98f4173f8a535f32468e48b6ec ] In preparation to fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") FCSR access regression factor out NT_PRFPREG regset access helpers for the non-MSA and the MSA variants respectively, to avoid having to deal with excessive indentation in the actual fix. No functional change, however use `target->thread.fpu.fpr[0]' rather than `target->thread.fpu.fpr[i]' for FGR holding type size determination as there's no `i' variable to refer to anymore, and for the factored out `i' variable declaration use `unsigned int' rather than `unsigned' as its type, following the common style. Signed-off-by: Maciej W. Rozycki Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: James Hogan Cc: Paul Burton Cc: Alex Smith Cc: Dave Martin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17925/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 887b8412d48e956a8b4b833336e9d86260f17455 Author: Maciej W. Rozycki Date: Mon Nov 27 09:33:03 2017 +0000 MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task [ Upstream commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 ] Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has not been enabled, despite that an executable requesting the mode requested via ELF file annotation would not be allowed to run in the first place, or for n64 and n64 ABI tasks which do not have non-default modes defined at all. Add suitable checks to `mips_set_process_fp_mode' and bail out if an invalid mode change has been requested for the ABI in effect, even if the FPU hardware or emulation would otherwise allow it. Always succeed however without taking any further action if the mode requested is the same as one already in effect, regardless of whether any mode change, should it be requested, would actually be allowed for the task concerned. Signed-off-by: Maciej W. Rozycki Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Reviewed-by: Paul Burton Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/17800/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit f736ef5869eb459a4d54140989959bfc42d55d04 Author: Bart Van Assche Date: Wed Jan 3 13:39:15 2018 -0800 IB/srpt: Disable RDMA access by the initiator [ Upstream commit bec40c26041de61162f7be9d2ce548c756ce0f65 ] With the SRP protocol all RDMA operations are initiated by the target. Since no RDMA operations are initiated by the initiator, do not grant the initiator permission to submit RDMA reads or writes to the target. Signed-off-by: Bart Van Assche Cc: Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6aa975f1b5a15881670160d96d65537a20b012f4 Author: Wolfgang Grandegger Date: Wed Dec 13 19:52:23 2017 +0100 can: gs_usb: fix return value of the "set_bittiming" callback [ Upstream commit d5b42e6607661b198d8b26a0c30969605b1bf5c7 ] The "set_bittiming" callback treats a positive return value as error! For that reason "can_changelink()" will quit silently after setting the bittiming values without processing ctrlmode, restart-ms, etc. Signed-off-by: Wolfgang Grandegger Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit bec1dbb0f0a93d5eb9d6b2741ead4156408d8150 Author: Wanpeng Li Date: Thu Dec 14 17:40:50 2017 -0800 KVM: Fix stack-out-of-bounds read in write_mmio [ Upstream commit e39d200fa5bf5b94a0948db0dae44c1b73b84a56 ] Reported by syzkaller: BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm] Read of size 8 at addr ffff8803259df7f8 by task syz-executor/32298 CPU: 6 PID: 32298 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #18 Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 02/16/2016 Call Trace: dump_stack+0xab/0xe1 print_address_description+0x6b/0x290 kasan_report+0x28a/0x370 write_mmio+0x11e/0x270 [kvm] emulator_read_write_onepage+0x311/0x600 [kvm] emulator_read_write+0xef/0x240 [kvm] emulator_fix_hypercall+0x105/0x150 [kvm] em_hypercall+0x2b/0x80 [kvm] x86_emulate_insn+0x2b1/0x1640 [kvm] x86_emulate_instruction+0x39a/0xb90 [kvm] handle_exception+0x1b4/0x4d0 [kvm_intel] vcpu_enter_guest+0x15a0/0x2640 [kvm] kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm] kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall) to the guest memory, however, write_mmio tracepoint always prints 8 bytes through *(u64 *)val since kvm splits the mmio access into 8 bytes. This leaks 5 bytes from the kernel stack (CVE-2017-17741). This patch fixes it by just accessing the bytes which we operate on. Before patch: syz-executor-5567 [007] .... 51370.561696: kvm_mmio: mmio write len 3 gpa 0x10 val 0x1ffff10077c1010f After patch: syz-executor-13416 [002] .... 51302.299573: kvm_mmio: mmio write len 3 gpa 0x10 val 0xc1010f Reported-by: Dmitry Vyukov Reviewed-by: Darren Kenny Reviewed-by: Marc Zyngier Tested-by: Marc Zyngier Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Marc Zyngier Cc: Christoffer Dall Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 16b726043452d7b624c6ef8118d9ac17f8001dfa Author: Suren Baghdasaryan Date: Wed Dec 6 09:27:30 2017 -0800 dm bufio: fix shrinker scans when (nr_to_scan < retain_target) [ Upstream commit fbc7c07ec23c040179384a1f16b62b6030eb6bdd ] When system is under memory pressure it is observed that dm bufio shrinker often reclaims only one buffer per scan. This change fixes the following two issues in dm bufio shrinker that cause this behavior: 1. ((nr_to_scan - freed) <= retain_target) condition is used to terminate slab scan process. This assumes that nr_to_scan is equal to the LRU size, which might not be correct because do_shrink_slab() in vmscan.c calculates nr_to_scan using multiple inputs. As a result when nr_to_scan is less than retain_target (64) the scan will terminate after the first iteration, effectively reclaiming one buffer per scan and making scans very inefficient. This hurts vmscan performance especially because mutex is acquired/released every time dm_bufio_shrink_scan() is called. New implementation uses ((LRU size - freed) <= retain_target) condition for scan termination. LRU size can be safely determined inside __scan() because this function is called after dm_bufio_lock(). 2. do_shrink_slab() uses value returned by dm_bufio_shrink_count() to determine number of freeable objects in the slab. However dm_bufio always retains retain_target buffers in its LRU and will terminate a scan when this mark is reached. Therefore returning the entire LRU size from dm_bufio_shrink_count() is misleading because that does not represent the number of freeable objects that slab will reclaim during a scan. Returning (LRU size - retain_target) better represents the number of freeable objects in the slab. This way do_shrink_slab() returns 0 when (LRU size < retain_target) and vmscan will not try to scan this shrinker avoiding scans that will not reclaim any memory. Test: tested using Android device running /system/extras/alloc-stress that generates memory pressure and causes intensive shrinker scans Signed-off-by: Suren Baghdasaryan Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 389f2ddb67a9748333f9b092be74f0cc4339cf93 Author: Alexey Dobriyan Date: Fri Oct 7 17:02:14 2016 -0700 proc: much faster /proc/vmstat [ Upstream commit 68ba0326b4e14988f9e0c24a6e12a85cf2acd1ca ] Every current KDE system has process named ksysguardd polling files below once in several seconds: $ strace -e trace=open -p $(pidof ksysguardd) Process 1812 attached open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8 open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8 open("/proc/net/dev", O_RDONLY) = 8 open("/proc/net/wireless", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/stat", O_RDONLY) = 8 open("/proc/vmstat", O_RDONLY) = 8 Hell knows what it is doing but speed up reading /proc/vmstat by 33%! Benchmark is open+read+close 1.000.000 times. BEFORE $ perf stat -r 10 taskset -c 3 ./proc-vmstat Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs): 13146.768464 task-clock (msec) # 0.960 CPUs utilized ( +- 0.60% ) 15 context-switches # 0.001 K/sec ( +- 1.41% ) 1 cpu-migrations # 0.000 K/sec ( +- 11.11% ) 104 page-faults # 0.008 K/sec ( +- 0.57% ) 45,489,799,349 cycles # 3.460 GHz ( +- 0.03% ) 9,970,175,743 stalled-cycles-frontend # 21.92% frontend cycles idle ( +- 0.10% ) 2,800,298,015 stalled-cycles-backend # 6.16% backend cycles idle ( +- 0.32% ) 79,241,190,850 instructions # 1.74 insn per cycle # 0.13 stalled cycles per insn ( +- 0.00% ) 17,616,096,146 branches # 1339.956 M/sec ( +- 0.00% ) 176,106,232 branch-misses # 1.00% of all branches ( +- 0.18% ) 13.691078109 seconds time elapsed ( +- 0.03% ) ^^^^^^^^^^^^ AFTER $ perf stat -r 10 taskset -c 3 ./proc-vmstat Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs): 8688.353749 task-clock (msec) # 0.950 CPUs utilized ( +- 1.25% ) 10 context-switches # 0.001 K/sec ( +- 2.13% ) 1 cpu-migrations # 0.000 K/sec 104 page-faults # 0.012 K/sec ( +- 0.56% ) 30,384,010,730 cycles # 3.497 GHz ( +- 0.07% ) 12,296,259,407 stalled-cycles-frontend # 40.47% frontend cycles idle ( +- 0.13% ) 3,370,668,651 stalled-cycles-backend # 11.09% backend cycles idle ( +- 0.69% ) 28,969,052,879 instructions # 0.95 insn per cycle # 0.42 stalled cycles per insn ( +- 0.01% ) 6,308,245,891 branches # 726.058 M/sec ( +- 0.00% ) 214,685,502 branch-misses # 3.40% of all branches ( +- 0.26% ) 9.146081052 seconds time elapsed ( +- 0.07% ) ^^^^^^^^^^^ vsnprintf() is slow because: 1. format_decode() is busy looking for format specifier: 2 branches per character (not in this case, but in others) 2. approximately million branches while parsing format mini language and everywhere 3. just look at what string() does /proc/vmstat is good case because most of its content are strings Link: http://lkml.kernel.org/r/20160806125455.GA1187@p183.telecom.by Signed-off-by: Alexey Dobriyan Cc: Joe Perches Cc: Andi Kleen Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b193849242f888e3be10d8817158790d0e9a53bd Author: Libor Pechacek Date: Wed Apr 13 11:06:12 2016 +0930 module: Issue warnings when tainting kernel [ Upstream commit 3205c36cf7d96024626f92d65f560035df1abcb2 ] While most of the locations where a kernel taint bit is set are accompanied with a warning message, there are two which set their bits silently. If the tainting module gets unloaded later on, it is almost impossible to tell what was the reason for setting the flag. Signed-off-by: Libor Pechacek Signed-off-by: Rusty Russell Signed-off-by: Sasha Levin commit 488428b52bcdb3c2cb5a9fafce4fee9327093b83 Author: Miroslav Benes Date: Thu Nov 26 13:18:06 2015 +1030 module: keep percpu symbols in module's symtab [ Upstream commit e0224418516b4d8a6c2160574bac18447c354ef0 ] Currently, percpu symbols from .data..percpu ELF section of a module are not copied over and stored in final symtab array of struct module. Consequently such symbol cannot be returned via kallsyms API (for example kallsyms_lookup_name). This can be especially confusing when the percpu symbol is exported. Only its __ksymtab et al. are present in its symtab. The culprit is in layout_and_allocate() function where SHF_ALLOC flag is dropped for .data..percpu section. There is in fact no need to copy the section to final struct module, because kernel module loader allocates extra percpu section by itself. Unfortunately only symbols from SHF_ALLOC sections are copied due to a check in is_core_symbol(). The patch changes is_core_symbol() function to copy over also percpu symbols (their st_shndx points to .data..percpu ELF section). We do it only if CONFIG_KALLSYMS_ALL is set to be consistent with the rest of the function (ELF section is SHF_ALLOC but !SHF_EXECINSTR). Finally elf_type() returns type 'a' for a percpu symbol because its address is absolute. Signed-off-by: Miroslav Benes Signed-off-by: Rusty Russell Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a7a86dc39ea6850697ca6ca62d9c14489b8e1153 Author: Michal Marek Date: Wed Dec 9 15:08:21 2015 +0100 genksyms: Handle string literals with spaces in reference files [ Upstream commit a78f70e8d65e88b9f631d073f68cb26dcd746298 ] The reference files use spaces to separate tokens, however, we must preserve spaces inside string literals. Currently the only case in the tree is struct edac_raw_error_desc in : $ KBUILD_SYMTYPES=1 make -s drivers/edac/amd64_edac.symtypes $ mv drivers/edac/amd64_edac.{symtypes,symref} $ KBUILD_SYMTYPES=1 make -s drivers/edac/amd64_edac.symtypes drivers/edac/amd64_edac.c:527: warning: amd64_get_dram_hole_info: modversion changed because of changes in struct edac_raw_error_desc Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit 39bffdca1de3532b7679d2014bf9f9b0acd04956 Author: Thomas Gleixner Date: Thu Jan 4 22:19:04 2018 +0100 x86/tlb: Drop the _GPL from the cpu_tlbstate export [ Upstream commit 1e5476815fd7f98b888e01a0f9522b63085f96c9 ] The recent changes for PTI touch cpu_tlbstate from various tlb_flush inlines. cpu_tlbstate is exported as GPL symbol, so this causes a regression when building out of tree drivers for certain graphics cards. Aside of that the export was wrong since it was introduced as it should have been EXPORT_PER_CPU_SYMBOL_GPL(). Use the correct PER_CPU export and drop the _GPL to restore the previous state which allows users to utilize the cards they payed for. As always I'm really thrilled to make this kind of change to support the #friends (or however the hot hashtag of today is spelled) from that closet sauce graphics corp. Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4") Fixes: 6fd166aae78c ("x86/mm: Use/Fix PCID to optimize user/kernel switches") Reported-by: Kees Cook Signed-off-by: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Cc: Andy Lutomirski Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f2afeefd89eac225425638ea2b2337eba31f0ca6 Author: Helge Deller Date: Tue Jan 2 20:36:44 2018 +0100 parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel [ Upstream commit 88776c0e70be0290f8357019d844aae15edaa967 ] Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures about "Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9." Those opcodes evaluate to the ldcw() assembly instruction which requires (on 32bit) an alignment of 16 bytes to ensure atomicity. As it turns out, qemu is correct and in our assembly code in entry.S and pacache.S we don't pay attention to the required alignment. This patch fixes the problem by aligning the lock offset in assembly code in the same manner as we do in our C-code. Signed-off-by: Helge Deller Cc: # v4.0+ Signed-off-by: Sasha Levin commit d3ba9fb5e83f3687fd719884a9654b5ecb449ea9 Author: Tom Lendacky Date: Thu Nov 30 16:46:40 2017 -0600 x86/microcode/AMD: Add support for fam17h microcode loading [ Upstream commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf ] The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 2ce9928f13f85ce7730f45534db8eeb38287b293 Author: Aaron Ma Date: Sat Nov 25 16:48:41 2017 -0800 Input: elantech - add new icbody type 15 [ Upstream commit 10d900303f1c3a821eb0bef4e7b7ece16768fba4 ] The touchpad of Lenovo Thinkpad L480 reports it's version as 15. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 63ecbdb7deb90d2f746cf10b6c66778c3ad1d4ac Author: Oleg Nesterov Date: Fri Nov 17 15:30:08 2017 -0800 kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in complete_signal() [ Upstream commit 426915796ccaf9c2bd9bb06dc5702225957bc2e5 ] complete_signal() checks SIGNAL_UNKILLABLE before it starts to destroy the thread group, today this is wrong in many ways. If nothing else, fatal_signal_pending() should always imply that the whole thread group (except ->group_exit_task if it is not NULL) is killed, this check breaks the rule. After the previous changes we can rely on sig_task_ignored(); sig_fatal(sig) && SIGNAL_UNKILLABLE can only be true if we actually want to kill this task and sig == SIGKILL OR it is traced and debugger can intercept the signal. This should hopefully fix the problem reported by Dmitry. This test-case static int init(void *arg) { for (;;) pause(); } int main(void) { char stack[16 * 1024]; for (;;) { int pid = clone(init, stack + sizeof(stack)/2, CLONE_NEWPID | SIGCHLD, NULL); assert(pid > 0); assert(ptrace(PTRACE_ATTACH, pid, 0, 0) == 0); assert(waitpid(-1, NULL, WSTOPPED) == pid); assert(ptrace(PTRACE_DETACH, pid, 0, SIGSTOP) == 0); assert(syscall(__NR_tkill, pid, SIGKILL) == 0); assert(pid == wait(NULL)); } } triggers the WARN_ON_ONCE(!(task->jobctl & JOBCTL_STOP_PENDING)) in task_participate_group_stop(). do_signal_stop()->signal_group_exit() checks SIGNAL_GROUP_EXIT and return false, but task_set_jobctl_pending() checks fatal_signal_pending() and does not set JOBCTL_STOP_PENDING. And his should fix the minor security problem reported by Kyle, SECCOMP_RET_TRACE can miss fatal_signal_pending() the same way if the task is the root of a pid namespace. Link: http://lkml.kernel.org/r/20171103184246.GD21036@redhat.com Signed-off-by: Oleg Nesterov Reported-by: Dmitry Vyukov Reported-by: Kyle Huey Reviewed-by: Kees Cook Tested-by: Kyle Huey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4cf13a3c65aa86297a56894f3d6a4638d3b123c5 Author: Oleg Nesterov Date: Fri Nov 17 15:30:04 2017 -0800 kernel/signal.c: protect the SIGNAL_UNKILLABLE tasks from !sig_kernel_only() signals [ Upstream commit ac25385089f673560867eb5179228a44ade0cfc1 ] Change sig_task_ignored() to drop the SIG_DFL && !sig_kernel_only() signals even if force == T. This simplifies the next change and this matches the same check in get_signal() which will drop these signals anyway. Link: http://lkml.kernel.org/r/20171103184227.GC21036@redhat.com Signed-off-by: Oleg Nesterov Tested-by: Kyle Huey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d9f95f1f51bd9dc66e293628c9c4b91c260c32c3 Author: Oleg Nesterov Date: Fri Nov 17 15:30:01 2017 -0800 kernel/signal.c: protect the traced SIGNAL_UNKILLABLE tasks from SIGKILL [ Upstream commit 628c1bcba204052d19b686b5bac149a644cdb72e ] The comment in sig_ignored() says "Tracers may want to know about even ignored signals" but SIGKILL can not be reported to debugger and it is just wrong to return 0 in this case: SIGKILL should only kill the SIGNAL_UNKILLABLE task if it comes from the parent ns. Change sig_ignored() to ignore ->ptrace if sig == SIGKILL and rely on sig_task_ignored(). SISGTOP coming from within the namespace is not really right too but at least debugger can intercept it, and we can't drop it here because this will break "gdb -p 1": ptrace_attach() won't work. Perhaps we will add another ->ptrace check later, we will see. Link: http://lkml.kernel.org/r/20171103184206.GB21036@redhat.com Signed-off-by: Oleg Nesterov Tested-by: Kyle Huey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c1026402b6f55e5a8717e0041df8f276414dca5c Author: Thiago Rafael Becker Date: Thu Dec 14 15:33:12 2017 -0800 kernel: make groups_sort calling a responsibility group_info allocators [ Upstream commit bdcf0a423ea1c40bbb40e7ee483b50fc8aa3d758 ] In testing, we found that nfsd threads may call set_groups in parallel for the same entry cached in auth.unix.gid, racing in the call of groups_sort, corrupting the groups for that entry and leading to permission denials for the client. This patch: - Make groups_sort globally visible. - Move the call to groups_sort to the modifiers of group_info - Remove the call to groups_sort from set_groups Link: http://lkml.kernel.org/r/20171211151420.18655-1-thiago.becker@gmail.com Signed-off-by: Thiago Rafael Becker Reviewed-by: Matthew Wilcox Reviewed-by: NeilBrown Acked-by: "J. Bruce Fields" Cc: Al Viro Cc: Martin Schwidefsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 47fd9ca937d0cef8c51ea4571c6febf6eb767095 Author: David Howells Date: Tue Jan 2 10:02:19 2018 +0000 fscache: Fix the default for fscache_maybe_release_page() [ Upstream commit 98801506552593c9b8ac11021b0cdad12cab4f6b ] Fix the default for fscache_maybe_release_page() for when the cookie isn't valid or the page isn't cached. It mustn't return false as that indicates the page cannot yet be freed. The problem with the default is that if, say, there's no cache, but a network filesystem's pages are using up almost all the available memory, a system can OOM because the filesystem ->releasepage() op will not allow them to be released as fscache_maybe_release_page() incorrectly prevents it. This can be tested by writing a sequence of 512MiB files to an AFS mount. It does not affect NFS or CIFS because both of those wrap the call in a check of PG_fscache and it shouldn't bother Ceph as that only has PG_private set whilst writeback is in progress. This might be an issue for 9P, however. Note that the pages aren't entirely stuck. Removing a file or unmounting will clear things because that uses ->invalidatepage() instead. Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions") Reported-by: Marc Dionne Signed-off-by: David Howells Reviewed-by: Jeff Layton Acked-by: Al Viro Tested-by: Marc Dionne cc: stable@vger.kernel.org # 2.6.32+ Signed-off-by: Sasha Levin commit d8782748f4ef127cfeb4341679e1c45f1232d50d Author: Jan Engelhardt Date: Tue Dec 19 19:09:07 2017 +0100 crypto: n2 - cure use after free [ Upstream commit 203f45003a3d03eea8fa28d74cfc74c354416fdb ] queue_cache_init is first called for the Control Word Queue (n2_crypto_probe). At that time, queue_cache[0] is NULL and a new kmem_cache will be allocated. If the subsequent n2_register_algs call fails, the kmem_cache will be released in queue_cache_destroy, but queue_cache_init[0] is not set back to NULL. So when the Module Arithmetic Unit gets probed next (n2_mau_probe), queue_cache_init will not allocate a kmem_cache again, but leave it as its bogus value, causing a BUG() to trigger when queue_cache[0] is eventually passed to kmem_cache_zalloc: n2_crypto: Found N2CP at /virtual-devices@100/n2cp@7 n2_crypto: Registered NCS HVAPI version 2.0 called queue_cache_init n2_crypto: md5 alg registration failed n2cp f028687c: /virtual-devices@100/n2cp@7: Unable to register algorithms. called queue_cache_destroy n2cp: probe of f028687c failed with error -22 n2_crypto: Found NCP at /virtual-devices@100/ncp@6 n2_crypto: Registered NCS HVAPI version 2.0 called queue_cache_init kernel BUG at mm/slab.c:2993! Call Trace: [0000000000604488] kmem_cache_alloc+0x1a8/0x1e0 (inlined) kmem_cache_zalloc (inlined) new_queue (inlined) spu_queue_setup (inlined) handle_exec_unit [0000000010c61eb4] spu_mdesc_scan+0x1f4/0x460 [n2_crypto] [0000000010c62b80] n2_mau_probe+0x100/0x220 [n2_crypto] [000000000084b174] platform_drv_probe+0x34/0xc0 Cc: Signed-off-by: Jan Engelhardt Acked-by: David S. Miller Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6860bfb9c48399c2efe2719e2e6586dbbfbec666 Author: Oleg Nesterov Date: Thu Jan 4 16:17:49 2018 -0800 kernel/acct.c: fix the acct->needcheck check in check_free_space() [ Upstream commit 4d9570158b6260f449e317a5f9ed030c2504a615 ] As Tsukada explains, the time_is_before_jiffies(acct->needcheck) check is very wrong, we need time_is_after_jiffies() to make sys_acct() work. Ignoring the overflows, the code should "goto out" if needcheck > jiffies, while currently it checks "needcheck < jiffies" and thus in the likely case check_free_space() does nothing until jiffies overflow. In particular this means that sys_acct() is simply broken, acct_on() sets acct->needcheck = jiffies and expects that check_free_space() should set acct->active = 1 after the free-space check, but this won't happen if jiffies increments in between. This was broken by commit 32dc73086015 ("get rid of timer in kern/acct.c") in 2011, then another (correct) commit 795a2f22a8ea ("acct() should honour the limits from the very beginning") made the problem more visible. Link: http://lkml.kernel.org/r/20171213133940.GA6554@redhat.com Fixes: 32dc73086015 ("get rid of timer in kern/acct.c") Reported-by: TSUKADA Koutaro Suggested-by: TSUKADA Koutaro Signed-off-by: Oleg Nesterov Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b0cef1cbf122de433a8682c9017d32e36b3652cf Author: Thomas Gleixner Date: Mon Dec 4 15:07:30 2017 +0100 x86/paravirt: Dont patch flush_tlb_single [ Upstream commit a035795499ca1c2bd1928808d1a156eda1420383 ] native_flush_tlb_single() will be changed with the upcoming PAGE_TABLE_ISOLATION feature. This requires to have more code in there than INVLPG. Remove the paravirt patching for it. Signed-off-by: Thomas Gleixner Reviewed-by: Josh Poimboeuf Reviewed-by: Juergen Gross Acked-by: Peter Zijlstra Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Dave Hansen Cc: David Laight Cc: Denys Vlasenko Cc: Eduardo Valentin Cc: Greg KH Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Rik van Riel Cc: Will Deacon Cc: aliguori@amazon.com Cc: daniel.gruss@iaik.tugraz.at Cc: hughd@google.com Cc: keescook@google.com Cc: linux-mm@kvack.org Cc: michael.schwarz@iaik.tugraz.at Cc: moritz.lipp@iaik.tugraz.at Cc: richard.fellner@student.tugraz.at Link: https://lkml.kernel.org/r/20171204150606.828111617@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit ae33f60790ef03efd8c8f634e948b92fa38b208f Author: Tom Lendacky Date: Mon Jul 17 16:10:33 2017 -0500 x86/boot: Add early cmdline parsing for options with arguments [ Upstream commit e505371dd83963caae1a37ead9524e8d997341be ] Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found. Signed-off-by: Tom Lendacky Reviewed-by: Thomas Gleixner Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Brijesh Singh Cc: Dave Young Cc: Dmitry Vyukov Cc: Jonathan Corbet Cc: Konrad Rzeszutek Wilk Cc: Larry Woodman Cc: Linus Torvalds Cc: Matt Fleming Cc: Michael S. Tsirkin Cc: Paolo Bonzini Cc: Peter Zijlstra Cc: Radim Krčmář Cc: Rik van Riel Cc: Toshimitsu Kani Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/36b5f97492a9745dce27682305f990fc20e5cf8a.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9820d89b1a266ac573dae8fa46e4aa43f277a302 Author: Linus Torvalds Date: Wed Dec 20 17:57:06 2017 -0800 n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD) [ Upstream commit 966031f340185eddd05affcf72b740549f056348 ] We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty: Add EXTPROC support for LINEMODE") and the intent was to allow it to override some (all?) ICANON behavior. Quoting from that original commit message: There is a new bit in the termios local flag word, EXTPROC. When this bit is set, several aspects of the terminal driver are disabled. Input line editing, character echo, and mapping of signals are all disabled. This allows the telnetd to turn off these functions when in linemode, but still keep track of what state the user wants the terminal to be in. but the problem turns out that "several aspects of the terminal driver are disabled" is a bit ambiguous, and you can really confuse the n_tty layer by setting EXTPROC and then causing some of the ICANON invariants to no longer be maintained. This fixes at least one such case (TIOCINQ) becoming unhappy because of the confusion over whether ICANON really means ICANON when EXTPROC is set. This basically makes TIOCINQ match the case of read: if EXTPROC is set, we ignore ICANON. Also, make sure to reset the ICANON state ie EXTPROC changes, not just if ICANON changes. Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE") Reported-by: Tetsuo Handa Reported-by: syzkaller Cc: Jiri Slaby Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 43b8a35b4c36e4269b0039aec41e68f3c0d113de Author: Thomas Gleixner Date: Sat Dec 30 22:13:53 2017 +0100 x86/smpboot: Remove stale TLB flush invocations [ Upstream commit 322f8b8b340c824aef891342b0f5795d15e11562 ] smpboot_setup_warm_reset_vector() and smpboot_restore_warm_reset_vector() invoke local_flush_tlb() for no obvious reason. Digging in history revealed that the original code in the 2.1 era added those because the code manipulated a swapper_pg_dir pagetable entry. The pagetable manipulation was removed long ago in the 2.3 timeframe, but the TLB flush invocations stayed around forever. Remove them along with the pointless pr_debug()s which come from the same 2.1 change. Reported-by: Dominik Brodowski Signed-off-by: Thomas Gleixner Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Linus Torvalds Cc: Linus Torvalds Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20171230211829.586548655@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit b1aaa04a36d02100b010e547e7fc9571291fa2d5 Author: Daniel Thompson Date: Thu Dec 21 15:06:15 2017 +0200 usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201 [ Upstream commit da99706689481717998d1d48edd389f339eea979 ] When plugging in a USB webcam I see the following message: xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? handle_tx_event: 913 callbacks suppressed All is quiet again with this patch (and I've done a fair but of soak testing with the camera since). Cc: Signed-off-by: Daniel Thompson Acked-by: Ard Biesheuvel Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4f02d26872c30cea013f4bccc5f83c82a7da9eeb Author: Oliver Neukum Date: Tue Dec 12 16:11:30 2017 +0100 usb: add RESET_RESUME for ELSA MicroLink 56K [ Upstream commit b9096d9f15c142574ebebe8fbb137012bb9d99c2 ] This modem needs this quirk to operate. It produces timeouts when resumed without reset. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c5ca720db96a7a617d8480be1858577d018aa2f2 Author: Dmitry Fleytman Dmitry Fleytman Date: Tue Dec 19 06:02:04 2017 +0200 usb: Add device quirk for Logitech HD Pro Webcam C925e [ Upstream commit 7f038d256c723dd390d2fca942919573995f4cfd ] Commit e0429362ab15 ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams. There is one more model that has the same issue - C925e, so applying the same quirk as well. See aforementioned commit message for detailed explanation of the problem. Signed-off-by: Dmitry Fleytman Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6f969f908284b8a6035c4efe03a05ee93d62e55a Author: Daniele Palmas Date: Thu Dec 14 16:54:45 2017 +0100 USB: serial: option: add support for Telit ME910 PID 0x1101 [ Upstream commit 08933099e6404f588f81c2050bfec7313e06eeaf ] This patch adds support for PID 0x1101 of Telit ME910. Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 02a8689e8ae3eb7000ab1c19ae46375f2833ef2c Author: Shuah Khan Date: Mon Dec 18 17:24:22 2017 -0700 usbip: vhci: stop printing kernel pointer addresses in messages [ Upstream commit 8272d099d05f7ab2776cf56a2ab9f9443be18907 ] Remove and/or change debug, info. and error messages to not print kernel pointer addresses. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf46047fd5deb872cef0ccce3ca0941cdf67b52c Author: Shuah Khan Date: Mon Dec 18 17:23:37 2017 -0700 usbip: stub: stop printing kernel pointer addresses in messages [ Upstream commit 248a22044366f588d46754c54dfe29ffe4f8b4df ] Remove and/or change debug, info. and error messages to not print kernel pointer addresses. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b12f0b16ce3f2463253bb3029bdbd5358bbdf317 Author: Juan Zea Date: Fri Dec 15 10:21:20 2017 +0100 usbip: fix usbip bind writing random string after command in match_busid [ Upstream commit 544c4605acc5ae4afe7dd5914147947db182f2fb ] usbip bind writes commands followed by random string when writing to match_busid attribute in sysfs, caused by using full variable size instead of string length. Signed-off-by: Juan Zea Acked-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0649d3d3df7804674c63cb88392c6ee9892aa32f Author: Willem de Bruijn Date: Wed Dec 13 14:41:06 2017 -0500 sock: free skb in skb_complete_tx_timestamp on error [ Upstream commit 35b99dffc3f710cafceee6c8c6ac6a98eb2cb4bf ] skb_complete_tx_timestamp must ingest the skb it is passed. Call kfree_skb if the skb cannot be enqueued. Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl") Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()") Reported-by: Richard Cochran Signed-off-by: Willem de Bruijn Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c29c748974efc6ce305549517719dcb8f6568c4d Author: Ido Schimmel Date: Wed Dec 20 19:34:19 2017 +0200 ipv4: Fix use-after-free when flushing FIB tables [ Upstream commit b4681c2829e24943aadd1a7bb3a30d41d0a20050 ] Since commit 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse") the local table uses the same trie allocated for the main table when custom rules are not in use. When a net namespace is dismantled, the main table is flushed and freed (via an RCU callback) before the local table. In case the callback is invoked before the local table is iterated, a use-after-free can occur. Fix this by iterating over the FIB tables in reverse order, so that the main table is always freed after the local table. v3: Reworded comment according to Alex's suggestion. v2: Add a comment to make the fix more explicit per Dave's and Alex's feedback. Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse") Signed-off-by: Ido Schimmel Reported-by: Fengguang Wu Acked-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0f59b15b520329ff09e29d94168b8e80385f3e02 Author: Tonghao Zhang Date: Fri Dec 22 10:15:20 2017 -0800 sctp: Replace use of sockets_allocated with specified macro. [ Upstream commit 8cb38a602478e9f806571f6920b0a3298aabf042 ] The patch(180d8cd942ce) replaces all uses of struct sock fields' memory_pressure, memory_allocated, sockets_allocated, and sysctl_mem to accessor macros. But the sockets_allocated field of sctp sock is not replaced at all. Then replace it now for unifying the code. Fixes: 180d8cd942ce ("foundations of per-cgroup memory pressure controlling.") Cc: Glauber Costa Signed-off-by: Tonghao Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f72b65e6f18beef3351365e2e7b63421eaca20bd Author: Tobias Jordan Date: Wed Dec 6 15:23:23 2017 +0100 net: mvmdio: disable/unprepare clocks in EPROBE_DEFER case [ Upstream commit 589bf32f09852041fbd3b7ce1a9e703f95c230ba ] add appropriate calls to clk_disable_unprepare() by jumping to out_mdio in case orion_mdio_probe() returns -EPROBE_DEFER. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 3d604da1e954 ("net: mvmdio: get and enable optional clock") Signed-off-by: Tobias Jordan Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f831729f355f5a9289d10adff138ebf87c1907c2 Author: Brian King Date: Fri Dec 15 15:21:50 2017 -0600 tg3: Fix rx hang on MTU change with 5717/5719 [ Upstream commit 748a240c589824e9121befb1cba5341c319885bc ] This fixes a hang issue seen when changing the MTU size from 1500 MTU to 9000 MTU on both 5717 and 5719 chips. In discussion with Broadcom, they've indicated that these chipsets have the same phy as the 57766 chipset, so the same workarounds apply. This has been tested by IBM on both Power 8 and Power 9 systems as well as by Broadcom on x86 hardware and has been confirmed to resolve the hang issue. Signed-off-by: Brian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3022c1de3c14fbd5df9a23bbacf5a6710cf309e8 Author: Christoph Paasch Date: Mon Dec 11 00:05:46 2017 -0800 tcp md5sig: Use skb's saddr when replying to an incoming segment [ Upstream commit 30791ac41927ebd3e75486f9504b6d2280463bf0 ] The MD5-key that belongs to a connection is identified by the peer's IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying to an incoming segment from tcp_check_req() that failed the seq-number checks. Thus, to find the correct key, we need to use the skb's saddr and not the daddr. This bug seems to have been there since quite a while, but probably got unnoticed because the consequences are not catastrophic. We will call tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer, thus the connection doesn't really fail. Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().") Signed-off-by: Christoph Paasch Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57410ee5803657e9372c0304d07669a5af0fbd31 Author: Sebastian Sjoholm Date: Mon Dec 11 21:51:14 2017 +0100 net: qmi_wwan: add Sierra EM7565 1199:9091 [ Upstream commit aceef61ee56898cfa7b6960fb60b9326c3860441 ] Sierra Wireless EM7565 is an Qualcomm MDM9x50 based M.2 modem. The USB id is added to qmi_wwan.c to allow QMI communication with the EM7565. Signed-off-by: Sebastian Sjoholm Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e85c6629ac5fbef352ced9925d264965ebacdf20 Author: Kevin Cernekee Date: Wed Dec 6 12:12:27 2017 -0800 netlink: Add netns check on taps [ Upstream commit 93c647643b48f0131f02e45da3bd367d80443291 ] Currently, a nlmon link inside a child namespace can observe systemwide netlink activity. Filter the traffic so that nlmon can only sniff netlink messages from its own netns. Test case: vpnns -- bash -c "ip link add nlmon0 type nlmon; \ ip link set nlmon0 up; \ tcpdump -i nlmon0 -q -w /tmp/nlmon.pcap -U" & sudo ip xfrm state add src 10.1.1.1 dst 10.1.1.2 proto esp \ spi 0x1 mode transport \ auth sha1 0x6162633132330000000000000000000000000000 \ enc aes 0x00000000000000000000000000000000 grep --binary abc123 /tmp/nlmon.pcap Signed-off-by: Kevin Cernekee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b47dcd8e39410db6cead3d50d943d895a90d6bab Author: Kevin Cernekee Date: Mon Dec 11 11:13:45 2017 -0800 net: igmp: Use correct source address on IGMPv3 reports [ Upstream commit a46182b00290839fa3fa159d54fd3237bd8669f0 ] Closing a multicast socket after the final IPv4 address is deleted from an interface can generate a membership report that uses the source IP from a different interface. The following test script, run from an isolated netns, reproduces the issue: #!/bin/bash ip link add dummy0 type dummy ip link add dummy1 type dummy ip link set dummy0 up ip link set dummy1 up ip addr add 10.1.1.1/24 dev dummy0 ip addr add 192.168.99.99/24 dev dummy1 tcpdump -U -i dummy0 & socat EXEC:"sleep 2" \ UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 & sleep 1 ip addr del 10.1.1.1/24 dev dummy0 sleep 5 kill %tcpdump RFC 3376 specifies that the report must be sent with a valid IP source address from the destination subnet, or from address 0.0.0.0. Add an extra check to make sure this is the case. Signed-off-by: Kevin Cernekee Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eae1a08cc2a3fe5cd5d4be5c484931dfcf744a6e Author: Eric Dumazet Date: Mon Dec 11 07:03:38 2017 -0800 ipv6: mcast: better catch silly mtu values [ Upstream commit b9b312a7a451e9c098921856e7cfbc201120e1a7 ] syzkaller reported crashes in IPv6 stack [1] Xin Long found that lo MTU was set to silly values. IPv6 stack reacts to changes to small MTU, by disabling itself under RTNL. But there is a window where threads not using RTNL can see a wrong device mtu. This can lead to surprises, in mld code where it is assumed the mtu is suitable. Fix this by reading device mtu once and checking IPv6 minimal MTU. [1] skbuff: skb_over_panic: text:0000000010b86b8d len:196 put:20 head:000000003b477e60 data:000000000e85441e tail:0xd4 end:0xc0 dev:lo ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100 RSP: 0018:ffff8801db307508 EFLAGS: 00010286 RAX: 0000000000000082 RBX: ffff8801c517e840 RCX: 0000000000000000 RDX: 0000000000000082 RSI: 1ffff1003b660e61 RDI: ffffed003b660e95 RBP: ffff8801db307570 R08: 1ffff1003b660e23 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff85bd4020 R13: ffffffff84754ed2 R14: 0000000000000014 R15: ffff8801c4e26540 FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000463610 CR3: 00000001c6698000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_over_panic net/core/skbuff.c:109 [inline] skb_put+0x181/0x1c0 net/core/skbuff.c:1694 add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695 add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817 mld_send_cr net/ipv6/mcast.c:1903 [inline] mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448 call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320 expire_timers kernel/time/timer.c:1357 [inline] __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660 run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686 __do_softirq+0x29d/0xbb2 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1d3/0x210 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:540 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920 Signed-off-by: Eric Dumazet Reported-by: syzbot Tested-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 545e2cd839fab854dee2d567fd5a7d53893a9c93 Author: Eric Dumazet Date: Mon Dec 11 07:17:39 2017 -0800 ipv4: igmp: guard against silly MTU values [ Upstream commit b5476022bbada3764609368f03329ca287528dc8 ] IPv4 stack reacts to changes to small MTU, by disabling itself under RTNL. But there is a window where threads not using RTNL can see a wrong device mtu. This can lead to surprises, in igmp code where it is assumed the mtu is suitable. Fix this by reading device mtu once and checking IPv4 minimal MTU. This patch adds missing IPV4_MIN_MTU define, to not abuse ETH_MIN_MTU anymore. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 49c74e3181f472eed405345bd4534e53e440ea1b Author: Linus Torvalds Date: Fri Dec 29 17:34:43 2017 -0800 kbuild: add '-fno-stack-check' to kernel build options [ Upstream commit 3ce120b16cc548472f80cf8644f90eda958cf1b6 ] It appears that hardened gentoo enables "-fstack-check" by default for gcc. That doesn't work _at_all_ for the kernel, because the kernel stack doesn't act like a user stack at all: it's much smaller, and it doesn't auto-expand on use. So the extra "probe one page below the stack" code generated by -fstack-check just breaks the kernel in horrible ways, causing infinite double faults etc. [ I have to say, that the particular code gcc generates looks very stupid even for user space where it works, but that's a separate issue. ] Reported-and-tested-by: Alexander Tsoy Reported-and-tested-by: Toralf Förster Cc: stable@kernel.org Cc: Dave Hansen Cc: Jiri Kosina Cc: Andy Lutomirski Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c4d0c959edce5d01b895dd7619cfb837afdd3d50 Author: Andy Lutomirski Date: Sun Oct 8 21:53:05 2017 -0700 x86/mm/64: Fix reboot interaction with CR4.PCIDE [ Upstream commit 924c6b900cfdf376b07bccfd80e62b21914f8a5a ] Trying to reboot via real mode fails with PCID on: long mode cannot be exited while CR4.PCIDE is set. (No, I have no idea why, but the SDM and actual CPUs are in agreement here.) The result is a GPF and a hang instead of a reboot. I didn't catch this in testing because neither my computer nor my VM reboots this way. I can trigger it with reboot=bios, though. Fixes: 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems") Reported-and-tested-by: Steven Rostedt (VMware) Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Cc: Borislav Petkov Link: https://lkml.kernel.org/r/f1e7d965998018450a7a70c2823873686a8b21c0.1507524746.git.luto@kernel.org Signed-off-by: Sasha Levin commit a2e3d685b98a5971eb5e9de768c89b27b23393bf Author: Andy Lutomirski Date: Thu Jun 29 08:53:21 2017 -0700 x86/mm: Enable CR4.PCIDE on supported systems [ Upstream commit 660da7c9228f685b2ebe664f9fd69aaddcc420b5 ] We can use PCID if the CPU has PCID and PGE and we're not on Xen. By itself, this has no effect. A followup patch will start using PCID. Signed-off-by: Andy Lutomirski Reviewed-by: Nadav Amit Reviewed-by: Boris Ostrovsky Reviewed-by: Thomas Gleixner Cc: Andrew Morton Cc: Arjan van de Ven Cc: Borislav Petkov Cc: Dave Hansen Cc: Juergen Gross Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Rik van Riel Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/6327ecd907b32f79d5aa0d466f04503bbec5df88.1498751203.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 7dc504865e3c1951d659fd9430b19e3d66a4acaa Author: Andy Lutomirski Date: Thu Jun 29 08:53:20 2017 -0700 x86/mm: Add the 'nopcid' boot option to turn off PCID [ Upstream commit 0790c9aad84901ca1bdc14746175549c8b5da215 ] The parameter is only present on x86_64 systems to save a few bytes, as PCID is always disabled on x86_32. Signed-off-by: Andy Lutomirski Reviewed-by: Nadav Amit Reviewed-by: Borislav Petkov Reviewed-by: Thomas Gleixner Cc: Andrew Morton Cc: Arjan van de Ven Cc: Borislav Petkov Cc: Dave Hansen Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Rik van Riel Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/8bbb2e65bcd249a5f18bfb8128b4689f08ac2b60.1498751203.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 3c44d4cab8a2056a235263e3972eaba162986c38 Author: Andy Lutomirski Date: Thu Jun 29 08:53:19 2017 -0700 x86/mm: Disable PCID on 32-bit kernels [ Upstream commit cba4671af7550e008f7a7835f06df0763825bf3e ] 32-bit kernels on new hardware will see PCID in CPUID, but PCID can only be used in 64-bit mode. Rather than making all PCID code conditional, just disable the feature on 32-bit builds. Signed-off-by: Andy Lutomirski Reviewed-by: Nadav Amit Reviewed-by: Borislav Petkov Reviewed-by: Thomas Gleixner Cc: Andrew Morton Cc: Arjan van de Ven Cc: Borislav Petkov Cc: Dave Hansen Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Rik van Riel Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/2e391769192a4d31b808410c383c6bf0734bc6ea.1498751203.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit aeb05f442b4264d335c1b7d1528f72b18a22141d Author: Andy Lutomirski Date: Sat Apr 22 00:01:21 2017 -0700 x86/mm: Make flush_tlb_mm_range() more predictable [ Upstream commit ce27374fabf553153c3f53efcaa9bfab9216bd8c ] I'm about to rewrite the function almost completely, but first I want to get a functional change out of the way. Currently, if flush_tlb_mm_range() does not flush the local TLB at all, it will never do individual page flushes on remote CPUs. This seems to be an accident, and preserving it will be awkward. Let's change it first so that any regressions in the rewrite will be easier to bisect and so that the rewrite can attempt to change no visible behavior at all. The fix is simple: we can simply avoid short-circuiting the calculation of base_pages_to_flush. As a side effect, this also eliminates a potential corner case: if tlb_single_page_flush_ceiling == TLB_FLUSH_ALL, flush_tlb_mm_range() could have ended up flushing the entire address space one page at a time. Signed-off-by: Andy Lutomirski Acked-by: Dave Hansen Cc: Andrew Morton Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Michal Hocko Cc: Nadav Amit Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/4b29b771d9975aad7154c314534fec235618175a.1492844372.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit fb8ec05ef123ae4a0c35ff67410f2a68760f4b5f Author: Andy Lutomirski Date: Sat Apr 22 00:01:20 2017 -0700 x86/mm: Remove flush_tlb() and flush_tlb_current_task() [ Upstream commit 29961b59a51f8c6838a26a45e871a7ed6771809b ] I was trying to figure out what how flush_tlb_current_task() would possibly work correctly if current->mm != current->active_mm, but I realized I could spare myself the effort: it has no callers except the unused flush_tlb() macro. Signed-off-by: Andy Lutomirski Cc: Andrew Morton Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Michal Hocko Cc: Nadav Amit Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/e52d64c11690f85e9f1d69d7b48cc2269cd2e94b.1492844372.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit cfc9e6b27a47878b7cbd054226671c94219436be Author: Andy Lutomirski Date: Sat Apr 22 00:01:19 2017 -0700 x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly() [ Upstream commit 9ccee2373f0658f234727700e619df097ba57023 ] mark_screen_rdonly() is the last remaining caller of flush_tlb(). flush_tlb_mm_range() is potentially faster and isn't obsolete. Compile-tested only because I don't know whether software that uses this mechanism even exists. Signed-off-by: Andy Lutomirski Cc: Andrew Morton Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Michal Hocko Cc: Nadav Amit Cc: Peter Zijlstra Cc: Rik van Riel Cc: Sasha Levin Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/791a644076fc3577ba7f7b7cafd643cc089baa7d.1492844372.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 7af49778d76969becec62d97dd2fb12acb916a5c Author: Johan Hovold Date: Mon Nov 13 12:12:56 2017 +0100 ASoC: twl4030: fix child-node lookup [ Upstream commit 15f8c5f2415bfac73f33a14bcd83422bcbfb5298 ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent codec node was also prematurely freed, while the child node was leaked. Fixes: 2d6d649a2e0f ("ASoC: twl4030: Support for DT booted kernel") Signed-off-by: Johan Hovold Signed-off-by: Mark Brown Cc: stable Signed-off-by: Sasha Levin commit 4478dc587a15f53c3c0708436b23cd004108191f Author: Steve Wise Date: Mon Dec 18 13:10:00 2017 -0800 iw_cxgb4: Only validate the MSN for successful completions [ Upstream commit f55688c45442bc863f40ad678c638785b26cdce6 ] If the RECV CQE is in error, ignore the MSN check. This was causing recvs that were flushed into the sw cq to be completed with the wrong status (BAD_MSN instead of FLUSHED). Cc: stable@vger.kernel.org Signed-off-by: Steve Wise Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ec4111b025712d06021f4cbd1eec2927bab45128 Author: Steven Rostedt (VMware) Date: Fri Dec 22 20:32:35 2017 -0500 ring-buffer: Mask out the info bits when returning buffer page length [ Upstream commit 45d8b80c2ac5d21cd1e2954431fb676bc2b1e099 ] Two info bits were added to the "commit" part of the ring buffer data page when returned to be consumed. This was to inform the user space readers that events have been missed, and that the count may be stored at the end of the page. What wasn't handled, was the splice code that actually called a function to return the length of the data in order to zero out the rest of the page before sending it up to user space. These data bits were returned with the length making the value negative, and that negative value was not checked. It was compared to PAGE_SIZE, and only used if the size was less than PAGE_SIZE. Luckily PAGE_SIZE is unsigned long which made the compare an unsigned compare, meaning the negative size value did not end up causing a large portion of memory to be randomly zeroed out. Cc: stable@vger.kernel.org Fixes: 66a8cb95ed040 ("ring-buffer: Add place holder recording of dropped events") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 793283786b9f8a47040bf855c947b804d69eed81 Author: Jing Xia Date: Tue Dec 26 15:12:53 2017 +0800 tracing: Fix crash when it fails to alloc ring buffer [ Upstream commit 24f2aaf952ee0b59f31c3a18b8b36c9e3d3c2cf5 ] Double free of the ring buffer happens when it fails to alloc new ring buffer instance for max_buffer if TRACER_MAX_TRACE is configured. The root cause is that the pointer is not set to NULL after the buffer is freed in allocate_trace_buffers(), and the freeing of the ring buffer is invoked again later if the pointer is not equal to Null, as: instance_mkdir() |-allocate_trace_buffers() |-allocate_trace_buffer(tr, &tr->trace_buffer...) |-allocate_trace_buffer(tr, &tr->max_buffer...) // allocate fail(-ENOMEM),first free // and the buffer pointer is not set to null |-ring_buffer_free(tr->trace_buffer.buffer) // out_free_tr |-free_trace_buffers() |-free_trace_buffer(&tr->trace_buffer); //if trace_buffer is not null, free again |-ring_buffer_free(buf->buffer) |-rb_free_cpu_buffer(buffer->buffers[cpu]) // ring_buffer_per_cpu is null, and // crash in ring_buffer_per_cpu->pages Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com Cc: stable@vger.kernel.org Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code") Signed-off-by: Jing Xia Signed-off-by: Chunyan Zhang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit ca8476b2170d7500609f1fc6945a03e80eb58f6c Author: Steven Rostedt (VMware) Date: Tue Dec 26 20:07:34 2017 -0500 tracing: Fix possible double free on failure of allocating trace buffer [ Upstream commit 4397f04575c44e1440ec2e49b6302785c95fd2f8 ] Jing Xia and Chunyan Zhang reported that on failing to allocate part of the tracing buffer, memory is freed, but the pointers that point to them are not initialized back to NULL, and later paths may try to free the freed memory again. Jing and Chunyan fixed one of the locations that does this, but missed a spot. Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com Cc: stable@vger.kernel.org Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code") Reported-by: Jing Xia Reported-by: Chunyan Zhang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 6cca8cd145ecb720a113aad7fc17786d89c00de1 Author: Steven Rostedt (VMware) Date: Fri Dec 22 20:38:57 2017 -0500 tracing: Remove extra zeroing out of the ring buffer page [ Upstream commit 6b7e633fe9c24682df550e5311f47fb524701586 ] The ring_buffer_read_page() takes care of zeroing out any extra data in the page that it returns. There's no need to zero it out again from the consumer. It was removed from one consumer of this function, but read_buffers_splice_read() did not remove it, and worse, it contained a nasty bug because of it. Cc: stable@vger.kernel.org Fixes: 2711ca237a084 ("ring-buffer: Move zeroing out excess in page to ring buffer code") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 6d95be3ad026446d3144d2739bf285f0a177f3e2 Author: Yelena Krivosheev Date: Tue Dec 19 17:59:45 2017 +0100 net: mvneta: clear interface link status on port disable [ Upstream commit 4423c18e466afdfb02a36ee8b9f901d144b3c607 ] When port connect to PHY in polling mode (with poll interval 1 sec), port and phy link status must be synchronize in order don't loss link change event. [gregory.clement@free-electrons.com: add fixes tag] Cc: Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by: Yelena Krivosheev Tested-by: Dmitri Epshtein Signed-off-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ac2e0b11933e886affd5400d5f141251f5a0d43f Author: Ravi Bangoria Date: Tue Dec 12 17:59:15 2017 +0530 powerpc/perf: Dereference BHRB entries safely [ Upstream commit f41d84dddc66b164ac16acf3f584c276146f1c48 ] It's theoretically possible that branch instructions recorded in BHRB (Branch History Rolling Buffer) entries have already been unmapped before they are processed by the kernel. Hence, trying to dereference such memory location will result in a crash. eg: Unable to handle kernel paging request for data at address 0xd000000019c41764 Faulting instruction address: 0xc000000000084a14 NIP [c000000000084a14] branch_target+0x4/0x70 LR [c0000000000eb828] record_and_restart+0x568/0x5c0 Call Trace: [c0000000000eb3b4] record_and_restart+0xf4/0x5c0 (unreliable) [c0000000000ec378] perf_event_interrupt+0x298/0x460 [c000000000027964] performance_monitor_exception+0x54/0x70 [c000000000009ba4] performance_monitor_common+0x114/0x120 Fix it by deferefencing the addresses safely. Fixes: 691231846ceb ("powerpc/perf: Fix setting of "to" addresses for BHRB") Cc: stable@vger.kernel.org # v3.10+ Suggested-by: Naveen N. Rao Signed-off-by: Ravi Bangoria Reviewed-by: Naveen N. Rao [mpe: Use probe_kernel_read() which is clearer, tweak change log] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 2f687a846f5caaebd6c221aed1d7e5c68d8cabfa Author: Wanpeng Li Date: Thu Dec 7 00:30:08 2017 -0800 KVM: X86: Fix load RFLAGS w/o the fixed bit [ Upstream commit d73235d17ba63b53dc0e1051dbc10a1f1be91b71 ] *** Guest State *** CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871 CR3 = 0x00000000fffbc000 RSP = 0x0000000000000000 RIP = 0x0000000000000000 RFLAGS=0x00000000 DR7 = 0x0000000000000400 ^^^^^^^^^^ The failed vmentry is triggered by the following testcase when ept=Y: #include #include #include #include #include #include #include long r[5]; int main() { r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_regs regs = { .rflags = 0, }; ioctl(r[4], KVM_SET_REGS, ®s); ioctl(r[4], KVM_RUN, 0); } X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1 of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails. This patch fixes it by oring X86_EFLAGS_FIXED during ioctl. Cc: stable@vger.kernel.org Suggested-by: Jim Mattson Reviewed-by: David Hildenbrand Reviewed-by: Quan Xu Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Jim Mattson Cc: stable@vger.kernel.org Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 66f544844cbc6d4050e70a3d4d947dc46daa2a3f Author: Helge Deller Date: Tue Dec 12 21:52:26 2017 +0100 parisc: Hide Diva-built-in serial aux and graphics card [ Upstream commit bcf3f1752a622f1372d3252d0fea8855d89812e7 ] Diva GSP card has built-in serial AUX port and ATI graphic card which simply don't work and which both don't have external connectors. User Guides even mention that those devices shouldn't be used. So, prevent that Linux drivers try to enable those devices. Signed-off-by: Helge Deller Cc: # v3.0+ Signed-off-by: Sasha Levin commit 77ebefd06490ae38a300d1e4082ffee01baddac0 Author: Rafael J. Wysocki Date: Fri Dec 15 03:07:18 2017 +0100 PCI / PM: Force devices to D0 in pci_pm_thaw_noirq() [ Upstream commit 5839ee7389e893a31e4e3c9cf17b50d14103c902 ] It is incorrect to call pci_restore_state() for devices in low-power states (D1-D3), as that involves the restoration of MSI setup which requires MMIO to be operational and that is only the case in D0. However, pci_pm_thaw_noirq() may do that if the driver's "freeze" callbacks put the device into a low-power state, so fix it by making it force devices into D0 via pci_set_power_state() instead of trying to "update" their power state which is pointless. Fixes: e60514bd4485 (PCI/PM: Restore the status of PCI devices across hibernation) Cc: 4.13+ # 4.13+ Reported-by: Thomas Gleixner Reported-by: Maarten Lankhorst Tested-by: Thomas Gleixner Tested-by: Maarten Lankhorst Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit e70b66ca7f3ddf2f42abcc7fc46893568cf8a9d7 Author: Takashi Iwai Date: Mon Dec 18 23:36:57 2017 +0100 ALSA: usb-audio: Fix the missing ctl name suffix at parsing SU [ Upstream commit 5a15f289ee87eaf33f13f08a4909ec99d837ec5f ] The commit 89b89d121ffc ("ALSA: usb-audio: Add check return value for usb_string()") added the check of the return value from snd_usb_copy_string_desc(), which is correct per se, but it introduced a regression. In the original code, either the "Clock Source", "Playback Source" or "Capture Source" suffix is added after the terminal string, while the commit changed it to add the suffix only when get_term_name() is failing. It ended up with an incorrect ctl name like "PCM" instead of "PCM Capture Source". Also, even the original code has a similar bug: when the ctl name is generated from snd_usb_copy_string_desc() for the given iSelector, it also doesn't put the suffix. This patch addresses these issues: the suffix is added always when no static mapping is found. Also the patch tries to put more comments and cleans up the if/else block for better readability in order to avoid the same pitfall again. Fixes: 89b89d121ffc ("ALSA: usb-audio: Add check return value for usb_string()") Reported-and-tested-by: Mauro Santos Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6a3221d40abc10d3920f08daf11f9d6fa4b9b45e Author: Takashi Iwai Date: Thu Dec 14 16:44:12 2017 +0100 ALSA: rawmidi: Avoid racy info ioctl via ctl device [ Upstream commit c1cfd9025cc394fd137a01159d74335c5ac978ce ] The rawmidi also allows to obtaining the information via ioctl of ctl API. It means that user can issue an ioctl to the rawmidi device even when it's being removed as long as the control device is present. Although the code has some protection via the global register_mutex, its range is limited to the search of the corresponding rawmidi object, and the mutex is already unlocked at accessing the rawmidi object. This may lead to a use-after-free. For avoiding it, this patch widens the application of register_mutex to the whole snd_rawmidi_info_select() function. We have another mutex per rawmidi object, but this operation isn't very hot path, so it shouldn't matter from the performance POV. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7f1614254bea842bbd03f5952601d8362ba5c8ff Author: Johan Hovold Date: Sat Nov 11 16:38:44 2017 +0100 mfd: twl6040: Fix child-node lookup [ Upstream commit 85e9b13cbb130a3209f21bd7933933399c389ffe ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent node was prematurely freed, while the child node was leaked. Note that the CONFIG_OF compile guard can be removed as of_get_child_by_name() provides a !CONFIG_OF implementation which always fails. Cc: stable # 3.5 Fixes: 37e13cecaa14 ("mfd: Add support for Device Tree to twl6040") Fixes: ca2cad6ae38e ("mfd: Fix twl6040 build failure") Signed-off-by: Johan Hovold Acked-by: Peter Ujfalusi Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d250b8b8b0bc8672d36372f2ddeb07c3b46aca1c Author: Johan Hovold Date: Sat Nov 11 16:38:43 2017 +0100 mfd: twl4030-audio: Fix sibling-node lookup [ Upstream commit 0a423772de2f3d7b00899987884f62f63ae00dcb ] A helper purported to look up a child node based on its name was using the wrong of-helper and ended up prematurely freeing the parent of-node while leaking any matching node. To make things worse, any matching node would not even necessarily be a child node as the whole device tree was searched depth-first starting at the parent. Fixes: 019a7e6b7b31 ("mfd: twl4030-audio: Add DT support") Cc: stable # 3.7 Signed-off-by: Johan Hovold Acked-by: Peter Ujfalusi Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0bb230736d781864253e43fe4f9e9f0f09327661 Author: Sebastian Andrzej Siewior Date: Thu Nov 30 13:39:27 2017 +0100 crypto: mcryptd - protect the per-CPU queue with a lock [ Upstream commit 9abffc6f2efe46c3564c04312e52e07622d40e51 ] mcryptd_enqueue_request() grabs the per-CPU queue struct and protects access to it with disabled preemption. Then it schedules a worker on the same CPU. The worker in mcryptd_queue_worker() guards access to the same per-CPU variable with disabled preemption. If we take CPU-hotplug into account then it is possible that between queue_work_on() and the actual invocation of the worker the CPU goes down and the worker will be scheduled on _another_ CPU. And here the preempt_disable() protection does not work anymore. The easiest thing is to add a spin_lock() to guard access to the list. Another detail: mcryptd_queue_worker() is not processing more than MCRYPTD_BATCH invocation in a row. If there are still items left, then it will invoke queue_work() to proceed with more later. *I* would suggest to simply drop that check because it does not use a system workqueue and the workqueue is already marked as "CPU_INTENSIVE". And if preemption is required then the scheduler should do it. However if queue_work() is used then the work item is marked as CPU unbound. That means it will try to run on the local CPU but it may run on another CPU as well. Especially with CONFIG_DEBUG_WQ_FORCE_RR_CPU=y. Again, the preempt_disable() won't work here but lock which was introduced will help. In order to keep work-item on the local CPU (and avoid RR) I changed it to queue_work_on(). Cc: stable@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0385dc03f8c07064746016aef114753b44bac808 Author: Takashi Iwai Date: Thu Dec 14 13:31:16 2017 +0100 ACPI: APEI / ERST: Fix missing error handling in erst_reader() [ Upstream commit bb82e0b4a7e96494f0c1004ce50cec3d7b5fb3d1 ] The commit f6f828513290 ("pstore: pass allocated memory region back to caller") changed the check of the return value from erst_read() in erst_reader() in the following way: if (len == -ENOENT) goto skip; - else if (len < 0) { - rc = -1; + else if (len < sizeof(*rcd)) { + rc = -EIO; goto out; This introduced another bug: since the comparison with sizeof() is cast to unsigned, a negative len value doesn't hit any longer. As a result, when an error is returned from erst_read(), the code falls through, and it may eventually lead to some weird thing like memory corruption. This patch adds the negative error value check more explicitly for addressing the issue. Fixes: f6f828513290 (pstore: pass allocated memory region back to caller) Cc: All applicable Tested-by: Jerry Tang Signed-off-by: Takashi Iwai Acked-by: Kees Cook Reviewed-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 20b6d249613c401942b6d3c6ba71addff30fc28a Author: Sudip Mukherjee Date: Tue Oct 3 16:14:15 2017 -0700 alpha: fix build failures [ Upstream commit 8ee912dab95f1483156b6e994004bfcc3158d798 ] The build of alpha allmodconfig is giving error: arch/alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm': arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'; did you mean 'init_thread_info'? [-Werror=implicit-function-declaration] The file 'mmu_context.h' needed an extra header file. Link: http://lkml.kernel.org/r/1505668810-7497-1-git-send-email-sudipm.mukherjee@gmail.com Signed-off-by: Sudip Mukherjee Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit bdf3d83795f2d59fc1cb1aa8629fe0d3ce95bc56 Author: Alexandre Belloni Date: Thu Sep 28 13:53:27 2017 +0200 rtc: set the alarm to the next expiring timer [ Upstream commit 74717b28cb32e1ad3c1042cafd76b264c8c0f68d ] If there is any non expired timer in the queue, the RTC alarm is never set. This is an issue when adding a timer that expires before the next non expired timer. Ensure the RTC alarm is set in that case. Fixes: 2b2f5ff00f63 ("rtc: interface: ignore expired timers when enqueuing new timers") Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit dc6b94472bd11777cd420dc1e5d9d8558ebca1ce Author: Hoang Tran Date: Wed Sep 27 18:30:58 2017 +0200 tcp: fix under-evaluated ssthresh in TCP Vegas [ Upstream commit cf5d74b85ef40c202c76d90959db4d850f301b95 ] With the commit 76174004a0f19785 (tcp: do not slow start when cwnd equals ssthresh), the comparison to the reduced cwnd in tcp_vegas_ssthresh() would under-evaluate the ssthresh. Signed-off-by: Hoang Tran Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1d964c27ee4f2944727a11de0307c4cea116da81 Author: Jacob Keller Date: Mon Oct 2 07:17:50 2017 -0700 fm10k: ensure we process SM mbx when processing VF mbx [ Upstream commit 17a91809942ca32c70026d2d5ba3348a2c4fdf8f ] When we process VF mailboxes, the driver is likely going to also queue up messages to the switch manager. This process merely queues up the FIFO, but doesn't actually begin the transmission process. Because we hold the mailbox lock during this VF processing, the PF<->SM mailbox is not getting processed at this time. Ensure that we actually process the PF<->SM mailbox in between each PF<->VF mailbox. This should ensure prompt transmission of the messages queued up after each VF message is received and handled. Signed-off-by: Jacob Keller Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 5a2d15efcac13f59a2595f9cf5c538946919bda9 Author: Dick Kennedy Date: Fri Sep 29 17:34:32 2017 -0700 scsi: lpfc: PLOGI failures during NPIV testing [ Upstream commit e8bcf0ae4c0346fdc78ebefe0eefcaa6a6622d38 ] Local Reject/Invalid RPI errors seen during discovery. Temporary RPI cleanup was occurring regardless of SLI rev. It's only necessary on SLI-4. Adjust the test for whether cleanup is necessary. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9731874d3e85fa53ad851e657313585af6d3a625 Author: Dick Kennedy Date: Fri Sep 29 17:34:42 2017 -0700 scsi: lpfc: Fix secure firmware updates [ Upstream commit 184fc2b9a8bcbda9c14d0a1e7fbecfc028c7702e ] Firmware update fails with: status x17 add_status x56 on the final write If multiple DMA buffers are used for the download, some firmware revs have difficulty with signatures and crcs split across the dma buffer boundaries. Resolve by making all writes be a single 4k page in length. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 38a7d46c65efd240a87c34e414ab6f53f7a62e00 Author: Gabriele Paoloni Date: Thu Sep 28 15:33:05 2017 +0100 PCI/AER: Report non-fatal errors only to the affected endpoint [ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ] Previously, if an non-fatal error was reported by an endpoint, we called report_error_detected() for the endpoint, every sibling on the bus, and their descendents. If any of them did not implement the .error_detected() method, do_recovery() failed, leaving all these devices unrecovered. For example, the system described in the bugzilla below has two devices: 0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected() 0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected() When a device such as 74:02.0 reported a non-fatal error, do_recovery() failed because 74:03.0 lacked an .error_detected() method. But per PCIe r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and does not affect 74:03.0: Non-fatal errors are uncorrectable errors which cause a particular transaction to be unreliable but the Link is otherwise fully functional. Isolating Non-fatal from Fatal errors provides Requester/Receiver logic in a device or system management software the opportunity to recover from the error without resetting the components on the Link and disturbing other transactions in progress. Devices not associated with the transaction in error are not impacted by the error. Report non-fatal errors only to the endpoint that reported them. We really want to check for AER_NONFATAL here, but the current code structure doesn't allow that. Looking for pci_channel_io_normal is the best we can do now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055 Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver") Signed-off-by: Gabriele Paoloni Signed-off-by: Dongdong Liu [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 3fdc0db300e59252ea67febc2478a5badbe33594 Author: Emil Tantilov Date: Mon Sep 11 14:21:31 2017 -0700 ixgbe: fix use of uninitialized padding [ Upstream commit dcfd6b839c998bc9838e2a47f44f37afbdf3099c ] This patch is resolving Coverity hits where padding in a structure could be used uninitialized. - Initialize fwd_cmd.pad/2 before ixgbe_calculate_checksum() - Initialize buffer.pad2/3 before ixgbe_hic_unlocked() Signed-off-by: Emil Tantilov Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit daabd9e87abb6b3b52a2276d7245160c5d651bd8 Author: Christophe JAILLET Date: Sun Aug 27 08:39:51 2017 +0200 igb: check memory allocation failure [ Upstream commit 18eb86362a52f0af933cc0fd5e37027317eb2d1c ] Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function. This avoids NULL pointers dereference. Signed-off-by: Christophe JAILLET Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 6afe6627430ac3c1cf24f82d2a8f6f158242fd70 Author: Stuart Hayes Date: Wed Oct 4 10:57:52 2017 -0500 PCI: Create SR-IOV virtfn/physfn links before attaching driver [ Upstream commit 27d6162944b9b34c32cd5841acd21786637ee743 ] When creating virtual functions, create the "virtfn%u" and "physfn" links in sysfs *before* attaching the driver instead of after. When we attach the driver to the new virtual network interface first, there is a race when the driver attaches to the new sends out an "add" udev event, and the network interface naming software (biosdevname or systemd, for example) tries to look at these links. Signed-off-by: Stuart Hayes Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit d5fd666d32bab415644391359d528a985b8b06e8 Author: Varun Prakash Date: Wed Oct 11 19:33:07 2017 +0530 scsi: cxgb4i: fix Tx skb leak [ Upstream commit 9b3a081fb62158b50bcc90522ca2423017544367 ] In case of connection reset Tx skb queue can have some skbs which are not transmitted so purge Tx skb queue in release_offload_resources() to avoid skb leak. Signed-off-by: Varun Prakash Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 67d39ee351dd8a4ac6c8e5b913ef36d68a7f82c4 Author: David Daney Date: Fri Sep 8 10:10:31 2017 +0200 PCI: Avoid bus reset if bridge itself is broken [ Upstream commit 357027786f3523d26f42391aa4c075b8495e5d28 ] When checking to see if a PCI bus can safely be reset, we previously checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET flag set. Children marked with that flag are known not to behave well after a bus reset. Some PCIe root port bridges also do not behave well after a bus reset, sometimes causing the devices behind the bridge to become unusable. Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device to allow these bridges to be flagged, and prevent their secondary buses from being reset. Signed-off-by: David Daney [jglauber@cavium.com: fixed typo] Signed-off-by: Jan Glauber Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Williamson Signed-off-by: Sasha Levin commit acb26053a3012be2f7e6d28b102d00d6c69796c0 Author: Dan Murphy Date: Tue Oct 10 12:42:56 2017 -0500 net: phy: at803x: Change error to EINVAL for invalid MAC [ Upstream commit fc7556877d1748ac00958822a0a3bba1d4bd9e0d ] Change the return error code to EINVAL if the MAC address is not valid in the set_wol function. Signed-off-by: Dan Murphy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 04a78279f426fea00daac9bbc4bfa0b113385c7a Author: Christian Lamparter Date: Wed Oct 4 01:00:08 2017 +0200 crypto: crypto4xx - increase context and scatter ring buffer elements [ Upstream commit 778f81d6cdb7d25360f082ac0384d5103f04eca5 ] If crypto4xx is used in conjunction with dm-crypt, the available ring buffer elements are not enough to handle the load properly. On an aes-cbc-essiv:sha256 encrypted swap partition the read performance is abyssal: (tested with hdparm -t) /dev/mapper/swap_crypt: Timing buffered disk reads: 14 MB in 3.68 seconds = 3.81 MB/sec The patch increases both PPC4XX_NUM_SD and PPC4XX_NUM_PD to 256. This improves the performance considerably: /dev/mapper/swap_crypt: Timing buffered disk reads: 104 MB in 3.03 seconds = 34.31 MB/sec Furthermore, PPC4XX_LAST_SD, PPC4XX_LAST_GD and PPC4XX_LAST_PD can be easily calculated from their respective PPC4XX_NUM_* constant. Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2623fa5eee6941479cc63ce401c5de505b586c8c Author: Derek Basehore Date: Tue Aug 29 13:34:34 2017 -0700 backlight: pwm_bl: Fix overflow condition [ Upstream commit 5d0c49acebc9488e37db95f1d4a55644e545ffe7 ] This fixes an overflow condition that can happen with high max brightness and period values in compute_duty_cycle. This fixes it by using a 64 bit variable for computing the duty cycle. Signed-off-by: Derek Basehore Acked-by: Thierry Reding Reviewed-by: Brian Norris Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit a51071939027a1b0eb15cdad7d5b30c7dbe86657 Author: Vaidyanathan Srinivasan Date: Thu Mar 23 20:52:46 2017 +0530 cpuidle: powernv: Pass correct drv->cpumask for registration [ Upstream commit 293d264f13cbde328d5477f49e3103edbc1dc191 ] drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). On PowerNV platform cpu_present could be less than cpu_possible in cases where firmware detects the cpu, but it is not available to the OS. When CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence we skip creating cpu_device. This breaks cpuidle on powernv where register_cpu() is not called for cpus in cpu_possible_mask that cannot be hot-added at runtime. Trying cpuidle_register_device() on cpu without cpu_device will cause crash like this: cpu 0xf: Vector: 380 (Data SLB Access) at [c000000ff1503490] pc: c00000000022c8bc: string+0x34/0x60 lr: c00000000022ed78: vsnprintf+0x284/0x42c sp: c000000ff1503710 msr: 9000000000009033 dar: 6000000060000000 current = 0xc000000ff1480000 paca = 0xc00000000fe82d00 softe: 0 irq_happened: 0x01 pid = 1, comm = swapper/8 Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4 (Buildroot 2017.02-00004-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017 enter ? for help [link register ] c00000000022ed78 vsnprintf+0x284/0x42c [c000000ff1503710] c00000000022ebb8 vsnprintf+0xc4/0x42c (unreliable) [c000000ff1503800] c00000000022ef40 vscnprintf+0x20/0x44 [c000000ff1503830] c0000000000ab61c vprintk_emit+0x94/0x2cc [c000000ff15038a0] c0000000000acc9c vprintk_func+0x60/0x74 [c000000ff15038c0] c000000000619694 printk+0x38/0x4c [c000000ff15038e0] c000000000224950 kobject_get+0x40/0x60 [c000000ff1503950] c00000000022507c kobject_add_internal+0x60/0x2c4 [c000000ff15039e0] c000000000225350 kobject_init_and_add+0x70/0x78 [c000000ff1503a60] c00000000053c288 cpuidle_add_sysfs+0x9c/0xe0 [c000000ff1503ae0] c00000000053aeac cpuidle_register_device+0xd4/0x12c [c000000ff1503b30] c00000000053b108 cpuidle_register+0x98/0xcc [c000000ff1503bc0] c00000000085eaf0 powernv_processor_idle_init+0x140/0x1e0 [c000000ff1503c60] c00000000000cd60 do_one_initcall+0xc0/0x15c [c000000ff1503d20] c000000000833e84 kernel_init_freeable+0x1a0/0x25c [c000000ff1503dc0] c00000000000d478 kernel_init+0x24/0x12c [c000000ff1503e30] c00000000000b564 ret_from_kernel_thread+0x5c/0x78 This patch fixes the bug by passing correct cpumask from powernv-cpuidle driver. Signed-off-by: Vaidyanathan Srinivasan Reviewed-by: Gautham R. Shenoy Acked-by: Michael Ellerman [ rjw: Comment massage ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0b759f9c7687cd19f75bd79acf8c29ad65d06666 Author: Russell King Date: Wed Mar 29 17:12:47 2017 +0100 ARM: dma-mapping: disallow dma_get_sgtable() for non-kernel managed memory [ Upstream commit 916a008b4b8ecc02fbd035cfb133773dba1ff3d7 ] dma_get_sgtable() tries to create a scatterlist table containing valid struct page pointers for the coherent memory allocation passed in to it. However, memory can be declared via dma_declare_coherent_memory(), or via other reservation schemes which means that coherent memory is not guaranteed to be backed by struct pages. In such cases, the resulting scatterlist table contains pointers to invalid pages, which causes kernel oops later. This patch adds detection of such memory, and refuses to create a scatterlist table for such memory. Reported-by: Shuah Khan Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 854897ef3b44d6de21da3fa41b456311d0ab02d1 Author: Adam Wallis Date: Tue Mar 28 15:55:28 2017 +0300 xhci: plat: Register shutdown for xhci_plat [ Upstream commit b07c12517f2aed0add8ce18146bb426b14099392 ] Shutdown should be called for xhci_plat devices especially for situations where kexec might be used by stopping DMA transactions. Signed-off-by: Adam Wallis Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fa503badc1166602e9918128da7cc3b9c63781c9 Author: Arnd Bergmann Date: Tue Mar 28 12:11:07 2017 +0200 isdn: kcapi: avoid uninitialized data [ Upstream commit af109a2cf6a9a6271fa420ae2d64d72d86c92b7d ] gcc-7 points out that the AVMB1_ADDCARD ioctl results in an unintialized value ending up in the cardnr parameter: drivers/isdn/capi/kcapi.c: In function 'old_capi_manufacturer': drivers/isdn/capi/kcapi.c:1042:24: error: 'cdef.cardnr' may be used uninitialized in this function [-Werror=maybe-uninitialized] cparams.cardnr = cdef.cardnr; This has been broken since before the start of the git history, so either the value is not used for anything important, or the ioctl command doesn't get called in practice. Setting the cardnr to zero avoids the warning and makes sure we have consistent behavior. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4914194da460c820f4b363dab31414011eec586f Author: Reizer, Eyal Date: Sun Mar 26 08:53:10 2017 +0000 ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend [ Upstream commit 9bcf53f34a2c1cebc45cc12e273dcd5f51fbc099 ] mmc2 used for wl12xx was missing the keep-power-in suspend parameter. As a result the board couldn't reach suspend state. Signed-off-by: Eyal Reizer Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 041d9c3d1fce2213c68c21596eed818484e9cca3 Author: Gao Feng Date: Sat Mar 25 18:24:36 2017 +0800 netfilter: nf_nat_snmp: Fix panic when snmp_trap_helper fails to register [ Upstream commit 75c689dca98851d65ef5a27e5ce26b625b68751c ] In the commit 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack snmp helper"), the snmp_helper is replaced by nf_nat_snmp_hook. So the snmp_helper is never registered. But it still tries to unregister the snmp_helper, it could cause the panic. Now remove the useless snmp_helper and the unregister call in the error handler. Fixes: 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack snmp helper") Signed-off-by: Gao Feng Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7cd8b556862e50265fa442a4af560e9b1cedfffa Author: Liping Zhang Date: Sat Mar 25 12:09:15 2017 +0800 netfilter: nfnl_cthelper: fix a race when walk the nf_ct_helper_hash table [ Upstream commit 83d90219a5df8d950855ce73229a97b63605c317 ] The nf_ct_helper_hash table is protected by nf_ct_helper_mutex, while nfct_helper operation is protected by nfnl_lock(NFNL_SUBSYS_CTHELPER). So it's possible that one CPU is walking the nf_ct_helper_hash for cthelper add/get/del, another cpu is doing nf_conntrack_helpers_unregister at the same time. This is dangrous, and may cause use after free error. Note, delete operation will flush all cthelpers added via nfnetlink, so using rcu to do protect is not easy. Now introduce a dummy list to record all the cthelpers added via nfnetlink, then we can walk the dummy list instead of walking the nf_ct_helper_hash. Also, keep nfnl_cthelper_dump_table unchanged, it may be invoked without nfnl_lock(NFNL_SUBSYS_CTHELPER) held. Signed-off-by: Liping Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e251811fc7208771ba6c44389b20ac2cd0fa8a0f Author: Alexey Khoroshilov Date: Sat Mar 25 01:48:08 2017 +0300 irda: vlsi_ir: fix check for DMA mapping errors [ Upstream commit 6ac3b77a6ffff7513ff86b684aa256ea01c0e5b5 ] vlsi_alloc_ring() checks for DMA mapping errors by comparing returned address with zero, while pci_dma_mapping_error() should be used. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c6e388f9fc5ced59567e3a1d086bb15909e74ef Author: Alexander Duyck Date: Fri Mar 24 15:01:42 2017 -0700 i40e: Do not enable NAPI on q_vectors that have no rings [ Upstream commit 13a8cd191a2b470cfd435b3b57dbd21aa65ff78c ] When testing the epoll w/ busy poll code I found that I could get into a state where the i40e driver had q_vectors w/ active NAPI that had no rings. This was resulting in a divide by zero error. To correct it I am updating the driver code so that we only support NAPI on q_vectors that have 1 or more rings allocated to them. Signed-off-by: Alexander Duyck Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3add6681f77928fce2f5c49cd971cd04832ad36a Author: Alexander Duyck Date: Fri Mar 24 09:38:03 2017 -0700 net: Do not allow negative values for busy_read and busy_poll sysctl interfaces [ Upstream commit 95f255211396958c718aef8c45e3923b5211ea7b ] This change basically codifies what I think was already the limitations on the busy_poll and busy_read sysctl interfaces. We weren't checking the lower bounds and as such could input negative values. The behavior when that was used was dependent on the architecture. In order to prevent any issues with that I am just disabling support for values less than 0 since this way we don't have to worry about any odd behaviors. By limiting the sysctl values this way it also makes it consistent with how we handle the SO_BUSY_POLL socket option since the value appears to be reported as a signed integer value and negative values are rejected. Signed-off-by: Alexander Duyck Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit da5d6969f055c82f78c3a0c45555856e0179fda0 Author: Arnd Bergmann Date: Thu Mar 23 17:07:26 2017 +0100 bna: avoid writing uninitialized data into hw registers [ Upstream commit a5af83925363eb85d467933e3d6ec5a87001eb7c ] The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable writing undefined values into the hardware registers: drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function 'bfa_iocpf_sm_disabling_entry': arch/arm/include/asm/io.h:109:22: error: '*((void *)&disable_req+4)' is used uninitialized in this function [-Werror=uninitialized] arch/arm/include/asm/io.h:109:22: error: '*((void *)&disable_req+8)' is used uninitialized in this function [-Werror=uninitialized] The two functions look like they should do the same thing, but only one of them initializes the time stamp and clscode field. The fact that we only get a warning for one of the two functions seems to be arbitrary, based on the inlining decisions in the compiler. To address this, I'm making both functions do the same thing: - set the clscode from the ioc structure in both - set the time stamp from ktime_get_real_seconds (which also avoids the signed-integer overflow in 2038 and extends the well-defined behavior until 2106). - zero-fill the reserved field Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6b349f69d2471c53c8dd17bc91f190c3aa329319 Author: Julian Wiedmann Date: Thu Mar 23 14:55:09 2017 +0100 s390/qeth: no ETH header for outbound AF_IUCV [ Upstream commit acd9776b5c45ef02d1a210969a6fcc058afb76e3 ] With AF_IUCV traffic, the skb passed to hard_start_xmit() has a 14 byte slot at skb->data, intended for an ETH header. qeth_l3_fill_af_iucv_hdr() fills this ETH header... and then immediately moves it to the skb's headroom, where it disappears and is never seen again. But it's still possible for us to return NETDEV_TX_BUSY after the skb has been modified. Since we didn't get a private copy of the skb, the next time the skb is delivered to hard_start_xmit() it no longer has the expected layout (we moved the ETH header to the headroom, so skb->data now starts at the IUCV_TRANS header). So when qeth_l3_fill_af_iucv_hdr() does another round of rebuilding, the resulting qeth header ends up all wrong. On transmission, the buffer is then rejected by the HiperSockets device with SBALF15 = x'04'. When this error is passed back to af_iucv as TX_NOTIFY_UNREACHABLE, it tears down the offending socket. As the ETH header for AF_IUCV serves no purpose, just align the code to what we do for IP traffic on L3 HiperSockets: keep the ETH header at skb->data, and pass down data_offset = ETH_HLEN to qeth_fill_buffer(). When mapping the payload into the SBAL elements, the ETH header is then stripped off. This avoids the skb manipulations in qeth_l3_fill_af_iucv_hdr(), and any buffer re-entering hard_start_xmit() after NETDEV_TX_BUSY is now processed properly. Signed-off-by: Julian Wiedmann Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d8f0d6382e9f48b2d2cf3a7b4ed335aba495e1aa Author: Peter Stein Date: Fri Feb 17 00:00:50 2017 -0800 HID: xinmo: fix for out of range for THT 2P arcade controller. [ Upstream commit 9257821c5a1dc57ef3a37f7cbcebaf548395c964 ] There is a new clone of the XIN MO arcade controller which has same issue with out of range like the original. This fix will solve the issue where 2 directions on the joystick are not recognized by the new THT 2P arcade controller with device ID 0x75e1. In details the new device ID is added the hid-id list and the hid-xinmo source code. Signed-off-by: Peter Stein Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1856bb9ead3e8dbc298066d512ae199ba680b02d Author: Arnd Bergmann Date: Thu Mar 23 16:03:11 2017 +0100 hwmon: (asus_atk0110) fix uninitialized data access [ Upstream commit a2125d02443e9a4e68bcfd9f8004fa23239e8329 ] The latest gcc-7 snapshot adds a warning to point out that when atk_read_value_old or atk_read_value_new fails, we copy uninitialized data into sensor->cached_value: drivers/hwmon/asus_atk0110.c: In function 'atk_input_show': drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized] Adding an error check avoids this. All versions of the driver are affected. Fixes: 2c03d07ad54d ("hwmon: Add Asus ATK0110 support") Signed-off-by: Arnd Bergmann Reviewed-by: Luca Tettamanti Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 318bd1b52921ef05e57542528c60e2bd254a4f3f Author: Rob Herring Date: Tue Mar 21 21:03:01 2017 -0500 ARM: dts: ti: fix PCI bus dtc warnings [ Upstream commit 7d79f6098d82f8c09914d7799bc96891ad9c3baf ] dtc recently added PCI bus checks. Fix these warnings. Signed-off-by: Rob Herring Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: linux-omap@vger.kernel.org Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 6d2893b3cc1a7ffeb751e502f0679ca1e1e630de Author: Wanpeng Li Date: Mon Mar 20 21:18:55 2017 -0700 KVM: x86: correct async page present tracepoint [ Upstream commit 24dccf83a121b8a4ad5c2ad383a8184ef6c266ee ] After async pf setup successfully, there is a broadcast wakeup w/ special token 0xffffffff which tells vCPU that it should wake up all processes waiting for APFs though there is no real process waiting at the moment. The async page present tracepoint print prematurely and fails to catch the special token setup. This patch fixes it by moving the async page present tracepoint after the special token setup. Before patch: qemu-system-x86-8499 [006] ...1 5973.473292: kvm_async_pf_ready: token 0x0 gva 0x0 After patch: qemu-system-x86-8499 [006] ...1 5973.473292: kvm_async_pf_ready: token 0xffffffff gva 0x0 Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit db449f1b212c9a88915f3fc17e1e00ce3b45350a Author: Dick Kennedy Date: Thu Mar 23 08:47:18 2017 -0400 scsi: lpfc: Fix PT2PT PRLI reject [ Upstream commit a71e3cdcfce4880a4578915e110e3eaed1659765 ] lpfc cannot establish connection with targets that send PRLI in P2P configurations. If lpfc rejects a PRLI that is sent from a target the target will not resend and will reject the PRLI send from the initiator. [mkp: applied by hand] Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 50b4c3dc6e2f8626f5ddd0d8243eebac109c8104 Author: Patrice Chotard Date: Thu Mar 16 18:26:02 2017 +0100 pinctrl: st: add irq_request/release_resources callbacks [ Upstream commit e855fa9a65c40788b5069abb0d094537daa22e05 ] When using GPIO as IRQ source, the GPIO must be configured in INPUT. Callbacks dedicated for this was missing in pinctrl-st driver. This fix the following kernel error when trying to lock a gpio as IRQ: [ 7.521095] gpio gpiochip7: (PIO11): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 7.526018] gpio gpiochip7: (PIO11): unable to lock HW IRQ 6 for IRQ [ 7.529405] genirq: Failed to request resources for 0-0053 (irq 81) on irqchip GPIO Signed-off-by: Patrice Chotard Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1f2c53451463e8f8d9c4a93d21d16678d553bd57 Author: Jeffy Chen Date: Tue Mar 21 15:07:10 2017 +0800 netfilter: nfnl_cthelper: Fix memory leak [ Upstream commit f83bf8da1135ca635aac8f062cad3f001fcf3a26 ] We have memory leaks of nf_conntrack_helper & expect_policy. Signed-off-by: Jeffy Chen Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c8213392ceb9e241422e21cd96dfe4f11866bc03 Author: Pablo Neira Ayuso Date: Tue Mar 21 13:32:37 2017 +0100 netfilter: nfnl_cthelper: fix runtime expectation policy updates [ Upstream commit 2c422257550f123049552b39f7af6e3428a60f43 ] We only allow runtime updates of expectation policies for timeout and maximum number of expectations, otherwise reject the update. Signed-off-by: Pablo Neira Ayuso Acked-by: Liping Zhang Signed-off-by: Sasha Levin commit 1f1bea75a62ff482b21db4a79b8cb7238357cee5 Author: Gustavo A. R. Silva Date: Fri Mar 10 15:39:32 2017 -0600 usb: gadget: udc: remove pointer dereference after free [ Upstream commit 1f459262b0e1649a1e5ad12fa4c66eb76c2220ce ] Remove pointer dereference after free. Addresses-Coverity-ID: 1091173 Acked-by: Michal Nazarewicz Signed-off-by: Gustavo A. R. Silva Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit fd8990244ab4934e69ce3a21b8104a972679e8af Author: Roger Quadros Date: Wed Mar 8 16:05:44 2017 +0200 usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed [ Upstream commit 16bb05d98c904a4f6c5ce7e2d992299f794acbf2 ] As per USB3.0 Specification "Table 9-20. Standard Endpoint Descriptor", for interrupt and isochronous endpoints, wMaxPacketSize must be set to 1024 if the endpoint defines bMaxBurst to be greater than zero. Reviewed-by: Laurent Pinchart Signed-off-by: Roger Quadros Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 67c6ec71c210b49607ec912ac71185fddbc5421b Author: Tony Lindgren Date: Sun Mar 19 09:19:57 2017 -0700 net: qmi_wwan: Add USB IDs for MDM6600 modem on Motorola Droid 4 [ Upstream commit 4071898bf0f4d79ff353db327af2a15123272548 ] This gets qmicli working with the MDM6600 modem. Cc: Bjørn Mork Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Tony Lindgren Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6ab6422075dc0facc1984481ae4328798c73d35 Author: Herbert Xu Date: Tue Mar 14 18:25:57 2017 +0800 crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex [ Upstream commit 8a0f5ccfb33b0b8b51de65b7b3bf342ba10b4fb6 ] On Tue, Mar 14, 2017 at 10:44:10AM +0100, Dmitry Vyukov wrote: > > Yes, please. > Disregarding some reports is not a good way long term. Please try this patch. ---8<--- Subject: netlink: Annotate nlk cb_mutex by protocol Currently all occurences of nlk->cb_mutex are annotated by lockdep as a single class. This causes a false lcokdep cycle involving genl and crypto_user. This patch fixes it by dividing cb_mutex into individual classes based on the netlink protocol. As genl and crypto_user do not use the same netlink protocol this breaks the false dependency loop. Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29570ae1c5f5d32c07a233f3e3b4746f3ce867f1 Author: hayeswang Date: Tue Mar 14 14:15:20 2017 +0800 r8152: fix the list rx_done may be used without initialization [ Upstream commit 98d068ab52b4b11d403995ed14154660797e7136 ] The list rx_done would be initialized when the linking on occurs. Therefore, if a napi is scheduled without any linking on before, the following kernel panic would happen. BUG: unable to handle kernel NULL pointer dereference at 000000000000008 IP: [] r8152_poll+0xe1e/0x1210 [r8152] PGD 0 Oops: 0002 [#1] SMP Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c53319e1a308d0f373f0908c7d32454e5e003caa Author: Vaidyanathan Srinivasan Date: Sun Mar 19 00:51:59 2017 +0530 cpuidle: Validate cpu_dev in cpuidle_add_sysfs() [ Upstream commit ad0a45fd9c14feebd000b6e84189d0edff265170 ] If a given cpu is not in cpu_present and cpu hotplug is disabled, arch can skip setting up the cpu_dev. Arch cpuidle driver should pass correct cpu mask for registration, but failing to do so by the driver causes error to propagate and crash like this: [ 30.076045] Unable to handle kernel paging request for data at address 0x00000048 [ 30.076100] Faulting instruction address: 0xc0000000007b2f30 cpu 0x4d: Vector: 300 (Data Access) at [c000003feb18b670] pc: c0000000007b2f30: kobject_get+0x20/0x70 lr: c0000000007b3c94: kobject_add_internal+0x54/0x3f0 sp: c000003feb18b8f0 msr: 9000000000009033 dar: 48 dsisr: 40000000 current = 0xc000003fd2ed8300 paca = 0xc00000000fbab500 softe: 0 irq_happened: 0x01 pid = 1, comm = swapper/0 Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017 enter ? for help [c000003feb18b960] c0000000007b3c94 kobject_add_internal+0x54/0x3f0 [c000003feb18b9f0] c0000000007b43a4 kobject_init_and_add+0x64/0xa0 [c000003feb18ba70] c000000000e284f4 cpuidle_add_sysfs+0xb4/0x130 [c000003feb18baf0] c000000000e26038 cpuidle_register_device+0x118/0x1c0 [c000003feb18bb30] c000000000e26c48 cpuidle_register+0x78/0x120 [c000003feb18bbc0] c00000000168fd9c powernv_processor_idle_init+0x110/0x1c4 [c000003feb18bc40] c00000000000cff8 do_one_initcall+0x68/0x1d0 [c000003feb18bd00] c0000000016242f4 kernel_init_freeable+0x280/0x360 [c000003feb18bdc0] c00000000000d864 kernel_init+0x24/0x160 [c000003feb18be30] c00000000000b4e8 ret_from_kernel_thread+0x5c/0x74 Validating cpu_dev fixes the crash and reports correct error message like: [ 30.163506] Failed to register cpuidle device for cpu136 [ 30.173329] Registration of powernv driver failed. Signed-off-by: Vaidyanathan Srinivasan [ rjw: Comment massage ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b34eea0b4243e875539126a414f9c68cf7ea2a06 Author: Jon Medhurst Date: Thu Mar 2 13:04:09 2017 +0000 arm: kprobes: Align stack to 8-bytes in test code [ Upstream commit 974310d047f3c7788a51d10c8d255eebdb1fa857 ] kprobes test cases need to have a stack that is aligned to an 8-byte boundary because they call other functions (and the ARM ABI mandates that alignment) and because test cases include 64-bit accesses to the stack. Unfortunately, GCC doesn't ensure this alignment for inline assembler and for the code in question seems to always misalign it by pushing just the LR register onto the stack. We therefore need to explicitly perform stack alignment at the start of each test case. Without this fix, some test cases will generate alignment faults on systems where alignment is enforced. Even if the kernel is configured to handle these faults in software, triggering them is ugly. It also exposes limitations in the fault handling code which doesn't cope with writes to the stack. E.g. when handling this instruction strd r6, [sp, #-64]! the fault handling code will write to a stack location below the SP value at the point the fault occurred, which coincides with where the exception handler has pushed the saved register context. This results in corruption of those registers. Signed-off-by: Jon Medhurst Signed-off-by: Sasha Levin commit 66a633b70a2aa9bb64939b823ce14845160243b5 Author: Masami Hiramatsu Date: Tue Feb 14 00:05:59 2017 +0900 arm: kprobes: Fix the return address of multiple kretprobes [ Upstream commit 06553175f585b52509c7df37d6f4a50aacb7b211 ] This is arm port of commit 737480a0d525 ("kprobes/x86: Fix the return address of multiple kretprobes"). Fix the return address of subsequent kretprobes when multiple kretprobes are set on the same function. For example: # cd /sys/kernel/debug/tracing # echo "r:event1 sys_symlink" > kprobe_events # echo "r:event2 sys_symlink" >> kprobe_events # echo 1 > events/kprobes/enable # ln -s /tmp/foo /tmp/bar (without this patch) # cat trace | grep -v ^# ln-82 [000] dn.2 68.446525: event1: (kretprobe_trampoline+0x0/0x18 <- SyS_symlink) ln-82 [000] dn.2 68.447831: event2: (ret_fast_syscall+0x0/0x1c <- SyS_symlink) (with this patch) # cat trace | grep -v ^# ln-81 [000] dn.1 39.463469: event1: (ret_fast_syscall+0x0/0x1c <- SyS_symlink) ln-81 [000] dn.1 39.464701: event2: (ret_fast_syscall+0x0/0x1c <- SyS_symlink) Signed-off-by: Masami Hiramatsu Cc: KUMANO Syuhei Signed-off-by: Jon Medhurst Signed-off-by: Sasha Levin commit d6ef0887c806022f475341917e2ed92a0abc8191 Author: Jaroslav Kysela Date: Thu Mar 9 13:29:13 2017 +0100 ALSA: hda - add support for docking station for HP 820 G2 [ Upstream commit 04d5466a976b096364a39a63ac264c1b3a5f8fa1 ] This tested patch adds missing initialization for Line-In/Out PINs for the docking station for HP 820 G2. Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ef63329efb82a835310fff244c0c0d054eda875f Author: Aaron Lu Date: Thu Aug 11 15:44:30 2016 +0800 x86/irq: Do not substract irq_tlb_count from irq_call_count [ Upstream commit 82ba4faca1bffad429f15c90c980ffd010366c25 ] Since commit: 52aec3308db8 ("x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR") the TLB remote shootdown is done through call function vector. That commit didn't take care of irq_tlb_count, which a later commit: fd0f5869724f ("x86: Distinguish TLB shootdown interrupts from other functions call interrupts") ... tried to fix. The fix assumes every increase of irq_tlb_count has a corresponding increase of irq_call_count. So the irq_call_count is always bigger than irq_tlb_count and we could substract irq_tlb_count from irq_call_count. Unfortunately this is not true for the smp_call_function_single() case. The IPI is only sent if the target CPU's call_single_queue is empty when adding a csd into it in generic_exec_single. That means if two threads are both adding flush tlb csds to the same CPU's call_single_queue, only one IPI is sent. In other words, the irq_call_count is incremented by 1 but irq_tlb_count is incremented by 2. Over time, irq_tlb_count will be bigger than irq_call_count and the substract will produce a very large irq_call_count value due to overflow. Considering that: 1) it's not worth to send more IPIs for the sake of accurate counting of irq_call_count in generic_exec_single(); 2) it's not easy to tell if the call function interrupt is for TLB shootdown in __smp_call_function_single_interrupt(). Not to exclude TLB shootdown from call function count seems to be the simplest fix and this patch just does that. This bug was found by LKP's cyclic performance regression tracking recently with the vm-scalability test suite. I have bisected to commit: 3dec0ba0be6a ("mm/rmap: share the i_mmap_rwsem") This commit didn't do anything wrong but revealed the irq_call_count problem. IIUC, the commit makes rwc->remap_one in rmap_walk_file concurrent with multiple threads. When remap_one is try_to_unmap_one(), then multiple threads could queue flush TLB to the same CPU but only one IPI will be sent. Since the commit was added in Linux v3.19, the counting problem only shows up from v3.19 onwards. Signed-off-by: Aaron Lu Cc: Alex Shi Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Davidlohr Bueso Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Huang Ying Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tomoki Sekiyama Link: http://lkml.kernel.org/r/20160811074430.GA18163@aaronlu.sh.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 18781a03faa86987ef7f568697b847009d11d7d7 Author: Andy Lutomirski Date: Fri Jun 9 11:49:15 2017 -0700 sched/core: Idle_task_exit() shouldn't use switch_mm_irqs_off() [ Upstream commit 252d2a4117bc181b287eeddf848863788da733ae ] idle_task_exit() can be called with IRQs on x86 on and therefore should use switch_mm(), not switch_mm_irqs_off(). This doesn't seem to cause any problems right now, but it will confuse my upcoming TLB flush changes. Nonetheless, I think it should be backported because it's trivial. There won't be any meaningful performance impact because idle_task_exit() is only used when offlining a CPU. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: stable@vger.kernel.org Fixes: f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler") Link: http://lkml.kernel.org/r/ca3d1a9fa93a0b49f5a8ff729eda3640fb6abdf9.1497034141.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 36098eefd358009c4b98a807d6e1627ee95c2178 Author: Steven Rostedt Date: Fri May 13 15:30:13 2016 +0200 ARM: Hide finish_arch_post_lock_switch() from modules [ Upstream commit ef0491ea17f8019821c7e9c8e801184ecf17f85a ] The introduction of switch_mm_irqs_off() brought back an old bug regarding the use of preempt_enable_no_resched: As part of: 62b94a08da1b ("sched/preempt: Take away preempt_enable_no_resched() from modules") the definition of preempt_enable_no_resched() is only available in built-in code, not in loadable modules, so we can't generally use it from header files. However, the ARM version of finish_arch_post_lock_switch() calls preempt_enable_no_resched() and is defined as a static inline function in asm/mmu_context.h. This in turn means we cannot include asm/mmu_context.h from modules. With today's tip tree, asm/mmu_context.h gets included from linux/mmu_context.h, which is normally the exact pattern one would expect, but unfortunately, linux/mmu_context.h can be included from the vhost driver that is a loadable module, now causing this compile time error with modular configs: In file included from ../include/linux/mmu_context.h:4:0, from ../drivers/vhost/vhost.c:18: ../arch/arm/include/asm/mmu_context.h: In function 'finish_arch_post_lock_switch': ../arch/arm/include/asm/mmu_context.h:88:3: error: implicit declaration of function 'preempt_enable_no_resched' [-Werror=implicit-function-declaration] preempt_enable_no_resched(); Andy already tried to fix the bug by including linux/preempt.h from asm/mmu_context.h, but that didn't help. Arnd suggested reordering the header files, which wasn't popular, so let's use this workaround instead: The finish_arch_post_lock_switch() definition is now also hidden inside of #ifdef MODULE, so we don't see anything referencing preempt_enable_no_resched() from a header file. I've built a few hundred randconfig kernels with this, and did not see any new problems. Tested-by: Guenter Roeck Signed-off-by: Steven Rostedt Signed-off-by: Arnd Bergmann Acked-by: Russell King Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Russell King - ARM Linux Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: linux-arm-kernel@lists.infradead.org Fixes: f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler") Link: http://lkml.kernel.org/r/1463146234-161304-1-git-send-email-arnd@arndb.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 7319a5dc17e4c69a4f49498960e75030c508fdc8 Author: Andy Lutomirski Date: Tue Apr 26 09:39:07 2016 -0700 x86/mm: Build arch/x86/mm/tlb.c even on !SMP [ Upstream commit e1074888c326038340a1ada9129d679e661f2ea6 ] Currently all of the functions that live in tlb.c are inlined on !SMP builds. One can debate whether this is a good idea (in many respects the code in tlb.c is better than the inlined UP code). Regardless, I want to add code that needs to be built on UP and SMP kernels and relates to tlb flushing, so arrange for tlb.c to be compiled unconditionally. Signed-off-by: Andy Lutomirski Reviewed-by: Borislav Petkov Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/f0d778f0d828fc46e5d1946bca80f0aaf9abf032.1461688545.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit cc4e5849950c63c77b092a9549d2570f4ed9e4ad Author: Andy Lutomirski Date: Tue Apr 26 09:39:06 2016 -0700 sched/core: Add switch_mm_irqs_off() and use it in the scheduler [ Upstream commit f98db6013c557c216da5038d9c52045be55cd039 ] By default, this is the same thing as switch_mm(). x86 will override it as an optimization. Signed-off-by: Andy Lutomirski Reviewed-by: Borislav Petkov Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/df401df47bdd6be3e389c6f1e3f5310d70e81b2c.1461688545.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e813d3c61c99b44808746d18735e25bb62949550 Author: Ingo Molnar Date: Thu Apr 28 11:39:12 2016 +0200 mm/mmu_context, sched/core: Fix mmu_context.h assumption [ Upstream commit 8efd755ac2fe262d4c8d5c9bbe054bb67dae93da ] Some architectures (such as Alpha) rely on include/linux/sched.h definitions in their mmu_context.h files. So include sched.h before mmu_context.h. Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: linux-kernel@vger.kernel.org Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 0eb501a10bd064365b3ec59a4e99ff8e6ccceb25 Author: Andy Lutomirski Date: Fri Jan 29 11:42:59 2016 -0800 x86/mm: If INVPCID is available, use it to flush global mappings [ Upstream commit d8bced79af1db6734f66b42064cc773cada2ce99 ] On my Skylake laptop, INVPCID function 2 (flush absolutely everything) takes about 376ns, whereas saving flags, twiddling CR4.PGE to flush global mappings, and restoring flags takes about 539ns. Signed-off-by: Andy Lutomirski Reviewed-by: Borislav Petkov Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/ed0ef62581c0ea9c99b9bf6df726015e96d44743.1454096309.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 263b63f7b0cf438cf8f28758c42007838bb7ba16 Author: Andy Lutomirski Date: Fri Jan 29 11:42:58 2016 -0800 x86/mm: Add a 'noinvpcid' boot option to turn off INVPCID [ Upstream commit d12a72b844a49d4162f24cefdab30bed3f86730e ] This adds a chicken bit to turn off INVPCID in case something goes wrong. It's an early_param() because we do TLB flushes before we parse __setup() parameters. Signed-off-by: Andy Lutomirski Reviewed-by: Borislav Petkov Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/f586317ed1bc2b87aee652267e515b90051af385.1454096309.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 71a141983686398c9515650ee8dc70094884669d Author: Borislav Petkov Date: Wed Feb 10 15:51:16 2016 +0100 x86/mm: Fix INVPCID asm constraint [ Upstream commit e2c7698cd61f11d4077fdb28148b2d31b82ac848 ] So we want to specify the dependency on both @pcid and @addr so that the compiler doesn't reorder accesses to them *before* the TLB flush. But for that to work, we need to express this properly in the inline asm and deref the whole desc array, not the pointer to it. See clwb() for an example. This fixes the build error on 32-bit: arch/x86/include/asm/tlbflush.h: In function ‘__invpcid’: arch/x86/include/asm/tlbflush.h:26:18: error: memory input 0 is not directly addressable which gcc4.7 caught but 5.x didn't. Which is strange. :-\ Signed-off-by: Borislav Petkov Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Michael Matz Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-mm@kvack.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 2581761f08260641a52ab6bc9e0c9f9ea20d74b8 Author: Andy Lutomirski Date: Fri Jan 29 11:42:57 2016 -0800 x86/mm: Add INVPCID helpers [ Upstream commit 060a402a1ddb551455ee410de2eadd3349f2801b ] This adds helpers for each of the four currently-specified INVPCID modes. Signed-off-by: Andy Lutomirski Reviewed-by: Borislav Petkov Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/8a62b23ad686888cee01da134c91409e22064db9.1454096309.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit c458204474b740d85ec2de31469caa0708ec8bba Author: Steve Capper Date: Mon Dec 4 14:13:05 2017 +0000 arm64: Initialise high_memory global variable earlier [ Upstream commit f24e5834a2c3f6c5f814a417f858226f0a010ade ] The high_memory global variable is used by cma_declare_contiguous(.) before it is defined. We don't notice this as we compute __pa(high_memory - 1), and it looks like we're processing a VA from the direct linear map. This problem becomes apparent when we flip the kernel virtual address space and the linear map is moved to the bottom of the kernel VA space. This patch moves the initialisation of high_memory before it used. Cc: Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary") Signed-off-by: Steve Capper Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 53ae24c6bb7b039ccbabd9c6c1f214bfb2c1e812 Author: Marc Zyngier Date: Thu Nov 16 17:58:21 2017 +0000 arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one [ Upstream commit 5553b142be11e794ebc0805950b2e8313f93d718 ] VTTBR_BADDR_MASK is used to sanity check the size and alignment of the VTTBR address. It seems to currently be off by one, thereby only allowing up to 39-bit addresses (instead of 40-bit) and also insufficiently checking the alignment. This patch fixes it. This patch is the 32bit pendent of Kristina's arm64 fix, and she deserves the actual kudos for pinpointing that one. Fixes: f7ed45be3ba52 ("KVM: ARM: World-switch implementation") Cc: # 3.9 Reported-by: Kristina Martsenko Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin commit a85494935ff0e3d35d90d58edc897ac2d93003bc Author: Al Viro Date: Sat Sep 23 15:51:23 2017 -0400 more bio_map_user_iov() leak fixes [ Upstream commit 2b04e8f6bbb196cab4b232af0f8d48ff2c7a8058 ] we need to take care of failure exit as well - pages already in bio should be dropped by analogue of bio_unmap_pages(), since their refcounts had been bumped only once per reference in bio. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 3710f0fbb10a7c1d1f5a439dd88af23fb4c3ac67 Author: Leif Liddy Date: Sat Jul 8 20:55:32 2017 +0200 Bluetooth: btusb: fix QCA Rome suspend/resume [ Upstream commit fd865802c66bc451dc515ed89360f84376ce1a56 ] There's been numerous reported instances where BTUSB_QCA_ROME bluetooth controllers stop functioning upon resume from suspend. These devices seem to be losing power during suspend. Patch will detect a status change on resume and perform a reset. Signed-off-by: Leif Liddy Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin