aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/call-graph-from-sql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-07-17usb: gadget: f_uac2: fix endianness of 'struct cntrl_*_lay3'Eugeniu Rosca1-10/+10
The list [1] of commits doing endianness fixes in USB subsystem is long due to below quote from USB spec Revision 2.0 from April 27, 2000: ------------ 8.1 Byte/Bit Ordering Multiple byte fields in standard descriptors, requests, and responses are interpreted as and moved over the bus in little-endian order, i.e. LSB to MSB. ------------ This commit belongs to the same family. [1] Example of endianness fixes in USB subsystem: commit 14e1d56cbea6 ("usb: gadget: f_uac2: endianness fixes.") commit 42370b821168 ("usb: gadget: f_uac1: endianness fixes.") commit 63afd5cc7877 ("USB: chaoskey: fix Alea quirk on big-endian hosts") commit 74098c4ac782 ("usb: gadget: acm: fix endianness in notifications") commit cdd7928df0d2 ("ACM gadget: fix endianness in notifications") commit 323ece54e076 ("cdc-wdm: fix endianness bug in debug statements") commit e102609f1072 ("usb: gadget: uvc: Fix endianness mismatches") list goes on Fixes: 132fcb460839 ("usb: gadget: Add Audio Class 2.0 Driver") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: dwc2: Fix inefficient copy of unaligned buffersAntti Seppälä1-3/+9
Make sure only to copy any actual data rather than the whole buffer, when releasing the temporary buffer used for unaligned non-isochronous transfers. Taken directly from commit 0efd937e27d5e ("USB: ehci-tegra: fix inefficient copy of unaligned buffers") Tested with Lantiq xRX200 (MIPS) and RPi Model B Rev 2 (ARM) Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: dwc2: Fix DMA alignment to start at allocated boundaryAntti Seppälä1-21/+23
The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way") introduced a common way to align DMA allocations. The code in the commit aligns the struct dma_aligned_buffer but the actual DMA address pointed by data[0] gets aligned to an offset from the allocated boundary by the kmalloc_ptr and the old_xfer_buffer pointers. This is against the recommendation in Documentation/DMA-API.txt which states: Therefore, it is recommended that driver writers who don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). The effect of this is that architectures with non-coherent DMA caches may run into memory corruption or kernel crashes with Unhandled kernel unaligned accesses exceptions. Fix the alignment by positioning the DMA area in front of the allocation and use memory at the end of the area for storing the orginal transfer_buffer pointer. This may have the added benefit of increased performance as the DMA area is now fully aligned on all architectures. Tested with Lantiq xRX200 (MIPS) and RPi Model B Rev 2 (ARM). Fixes: 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way") Cc: <stable@vger.kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: dwc3: rockchip: Fix PHY documentation links.Enric Balletbo i Serra1-1/+2
Commit 34962fb8070c ("docs: Fix more broken references") replaced the broken reference to rockchip,dwc3-usb-phy.txt binding for the Qualcomm DWC3 binding (qcom-dwc3-usb-phy.txt). That's wrong, so replace that reference for the correct ones. Fixes: 34962fb8070c ("docs: Fix more broken references") Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17tools: usb: ffs-test: Fix build on big endian systemsPeter Senna Tschudin1-3/+16
The tools/usb/ffs-test.c file defines cpu_to_le16/32 by using the C library htole16/32 function calls. However, cpu_to_le16/32 are used when initializing structures, i.e in a context where a function call is not allowed. It works fine on little endian systems because htole16/32 are defined by the C library as no-ops. But on big-endian systems, they are actually doing something, which might involve calling a function, causing build failures, such as: ffs-test.c:48:25: error: initializer element is not constant #define cpu_to_le32(x) htole32(x) ^~~~~~~ ffs-test.c:128:12: note: in expansion of macro ‘cpu_to_le32’ .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2), ^~~~~~~~~~~ To solve this, we code cpu_to_le16/32 in a way that allows them to be used when initializing structures. This fix was imported from meta-openembedded/android-tools/fix-big-endian-build.patch written by Thomas Petazzoni <thomas.petazzoni@free-electrons.com>. CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: aspeed: Workaround memory ordering issueBenjamin Herrenschmidt3-3/+46
The Aspeed SoC has a memory ordering issue that (thankfully) only affects the USB gadget device. A read back is necessary after writing to memory and before letting the device DMA from it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: dwc3: gadget: remove redundant variable maxpacketColin Ian King1-3/+0
Variable maxpacket is being assigned but is never used hence it is redundant and can be removed. Cleans up clang warning: warning: variable 'maxpacket' set but not used [-Wunused-but-set-variable] Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: dwc2: avoid NULL dereferencesJohn Keeping1-3/+3
For unidirectional endpoints, the endpoint pointer will be NULL for the unused direction. Check that the endpoint is active before dereferencing this pointer. Fixes: 1b4977c793d3 ("usb: dwc2: Update dwc2_handle_incomplete_isoc_in() function") Fixes: 689efb2619b5 ("usb: dwc2: Update dwc2_handle_incomplete_isoc_out() function") Fixes: d84845522d93 ("usb: dwc2: Update GINTSTS_GOUTNAKEFF interrupt handling") Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb/phy: fix PPC64 build errors in phy-fsl-usb.cRandy Dunlap1-1/+3
Fix build errors when built for PPC64: These variables are only used on PPC32 so they don't need to be initialized for PPC64. ../drivers/usb/phy/phy-fsl-usb.c: In function 'usb_otg_start': ../drivers/usb/phy/phy-fsl-usb.c:865:3: error: '_fsl_readl' undeclared (first use in this function); did you mean 'fsl_readl'? _fsl_readl = _fsl_readl_be; ../drivers/usb/phy/phy-fsl-usb.c:865:16: error: '_fsl_readl_be' undeclared (first use in this function); did you mean 'fsl_readl'? _fsl_readl = _fsl_readl_be; ../drivers/usb/phy/phy-fsl-usb.c:866:3: error: '_fsl_writel' undeclared (first use in this function); did you mean 'fsl_writel'? _fsl_writel = _fsl_writel_be; ../drivers/usb/phy/phy-fsl-usb.c:866:17: error: '_fsl_writel_be' undeclared (first use in this function); did you mean 'fsl_writel'? _fsl_writel = _fsl_writel_be; ../drivers/usb/phy/phy-fsl-usb.c:868:16: error: '_fsl_readl_le' undeclared (first use in this function); did you mean 'fsl_readl'? _fsl_readl = _fsl_readl_le; ../drivers/usb/phy/phy-fsl-usb.c:869:17: error: '_fsl_writel_le' undeclared (first use in this function); did you mean 'fsl_writel'? _fsl_writel = _fsl_writel_le; and the sysfs "show" function return type should be ssize_t, not int: ../drivers/usb/phy/phy-fsl-usb.c:1042:49: error: initialization of 'ssize_t (*)(struct device *, struct device_attribute *, char *)' {aka 'long int (*)(struct device *, struct device_attribute *, char *)'} from incompatible pointer type 'int (*)(struct device *, struct device_attribute *, char *)' [-Werror=incompatible-pointer-types] static DEVICE_ATTR(fsl_usb2_otg_state, S_IRUGO, show_fsl_usb2_otg_state, NULL); Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: dwc2: host: do not delay retries for CONTROL IN transfersDmitry Torokhov1-2/+7
When handling split transactions we will try to delay retry after getting a NAK from the device. This works well for BULK transfers that can be polled for essentially forever. Unfortunately, on slower systems at boot time, when the kernel is busy enumerating all the devices (USB or not), we issue a bunch of control requests (reading device descriptors, etc). If we get a NAK for the IN part of the control request and delay retry for too long (because the system is busy), we may confuse the device when we finally get to reissue SSPLIT/CSPLIT IN and the device will respond with STALL. As a result we end up with failure to get device descriptor and will fail to enumerate the device: [ 3.428801] usb 2-1.2.1: new full-speed USB device number 9 using dwc2 [ 3.508576] usb 2-1.2.1: device descriptor read/8, error -32 [ 3.699150] usb 2-1.2.1: device descriptor read/8, error -32 [ 3.891653] usb 2-1.2.1: new full-speed USB device number 10 using dwc2 [ 3.968859] usb 2-1.2.1: device descriptor read/8, error -32 ... Let's not delay retries of split CONTROL IN transfers, as this allows us to reliably enumerate devices at boot time. Fixes: 38d2b5fb75c1 ("usb: dwc2: host: Don't retry NAKed transactions right away") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: u_audio: protect stream runtime fields with stream spinlockVladimir Zapolskiy1-1/+9
The change protects almost the whole body of u_audio_iso_complete() function by PCM stream lock, this is mainly sufficient to avoid a race between USB request completion and stream termination, the change prevents a possibility of invalid memory access in interrupt context by memcpy(): Unable to handle kernel paging request at virtual address 00004e80 pgd = c0004000 [00004e80] *pgd=00000000 Internal error: Oops: 817 [#1] PREEMPT SMP ARM CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G C 3.14.54+ #117 task: da180b80 ti: da192000 task.ti: da192000 PC is at memcpy+0x50/0x330 LR is at 0xcdd92b0e pc : [<c029ef30>] lr : [<cdd92b0e>] psr: 20000193 sp : da193ce4 ip : dd86ae26 fp : 0000b180 r10: daf81680 r9 : 00000000 r8 : d58a01ea r7 : 2c0b43e4 r6 : acdfb08b r5 : 01a271cf r4 : 87389377 r3 : 69469782 r2 : 00000020 r1 : daf82fe0 r0 : 00004e80 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 2b70804a DAC: 00000015 Process ksoftirqd/0 (pid: 3, stack limit = 0xda192238) Also added a check for potential !runtime condition, commonly it is done by PCM_RUNTIME_CHECK(substream) in the beginning, however this does not completely prevent from oopses in u_audio_iso_complete(), because the proper protection scheme must be implemented in PCM library functions. An example of *not fixed* oops due to substream->runtime->* dereference by snd_pcm_running(substream) from snd_pcm_period_elapsed(), where substream->runtime is gone while waiting the substream lock: Unable to handle kernel paging request at virtual address 6b6b6b6b pgd = db7e4000 [6b6b6b6b] *pgd=00000000 CPU: 0 PID: 193 Comm: klogd Tainted: G C 3.14.54+ #118 task: db5ac500 ti: db60c000 task.ti: db60c000 PC is at snd_pcm_period_elapsed+0x48/0xd8 [snd_pcm] LR is at snd_pcm_period_elapsed+0x40/0xd8 [snd_pcm] pc : [<>] lr : [<>] psr: 60000193 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 2b7e404a DAC: 00000015 Process klogd (pid: 193, stack limit = 0xdb60c238) [<>] (snd_pcm_period_elapsed [snd_pcm]) from [<>] (udc_irq+0x500/0xbbc) [<>] (udc_irq) from [<>] (ci_irq+0x280/0x304) [<>] (ci_irq) from [<>] (handle_irq_event_percpu+0xa4/0x40c) [<>] (handle_irq_event_percpu) from [<>] (handle_irq_event+0x3c/0x5c) [<>] (handle_irq_event) from [<>] (handle_fasteoi_irq+0xc4/0x110) [<>] (handle_fasteoi_irq) from [<>] (generic_handle_irq+0x20/0x30) [<>] (generic_handle_irq) from [<>] (handle_IRQ+0x80/0xc0) [<>] (handle_IRQ) from [<>] (gic_handle_irq+0x3c/0x60) [<>] (gic_handle_irq) from [<>] (__irq_svc+0x44/0x78) Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> [erosca: W/o this patch, with minimal instrumentation [1], I can consistently reproduce BUG: KASAN: use-after-free [2]] [1] Instrumentation to reproduce issue [2]: diff --git a/drivers/usb/gadget/function/u_audio.c b/drivers/usb/gadget/function/u_audio.c index a72295c953bb..bd0b308024fe 100644 --- a/drivers/usb/gadget/function/u_audio.c +++ b/drivers/usb/gadget/function/u_audio.c @@ -16,6 +16,7 @@ #include <sound/core.h> #include <sound/pcm.h> #include <sound/pcm_params.h> +#include <linux/delay.h> #include "u_audio.h" @@ -147,6 +148,8 @@ static void u_audio_iso_complete(struct usb_ep *ep, struct usb_request *req) spin_unlock_irqrestore(&prm->lock, flags); + udelay(500); //delay here to increase probability of parallel activities + /* Pack USB load in ALSA ring buffer */ pending = prm->dma_bytes - hw_ptr; [2] After applying [1], below BUG occurs on Rcar-H3-Salvator-X board: ================================================================== BUG: KASAN: use-after-free in u_audio_iso_complete+0x24c/0x520 [u_audio] Read of size 8 at addr ffff8006cafcc248 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G WC 4.14.47+ #160 Hardware name: Renesas Salvator-X board based on r8a7795 ES2.0+ (DT) Call trace: [<ffff2000080925ac>] dump_backtrace+0x0/0x364 [<ffff200008092924>] show_stack+0x14/0x1c [<ffff200008f8dbcc>] dump_stack+0x108/0x174 [<ffff2000083c71b8>] print_address_description+0x7c/0x32c [<ffff2000083c78e8>] kasan_report+0x324/0x354 [<ffff2000083c6114>] __asan_load8+0x24/0x94 [<ffff2000021d1b34>] u_audio_iso_complete+0x24c/0x520 [u_audio] [<ffff20000152fe50>] usb_gadget_giveback_request+0x480/0x4d0 [udc_core] [<ffff200001860ab8>] usbhsg_queue_done+0x100/0x130 [renesas_usbhs] [<ffff20000185f814>] usbhsf_pkt_handler+0x1a4/0x298 [renesas_usbhs] [<ffff20000185fb38>] usbhsf_irq_ready+0x128/0x178 [renesas_usbhs] [<ffff200001859cc8>] usbhs_interrupt+0x440/0x490 [renesas_usbhs] [<ffff2000081a0288>] __handle_irq_event_percpu+0x594/0xa58 [<ffff2000081a07d0>] handle_irq_event_percpu+0x84/0x12c [<ffff2000081a0928>] handle_irq_event+0xb0/0x10c [<ffff2000081a8384>] handle_fasteoi_irq+0x1e0/0x2ec [<ffff20000819e5f8>] generic_handle_irq+0x2c/0x44 [<ffff20000819f0d0>] __handle_domain_irq+0x190/0x194 [<ffff20000808177c>] gic_handle_irq+0x80/0xac Exception stack(0xffff200009e97c80 to 0xffff200009e97dc0) 7c80: 0000000000000000 0000000000000000 0000000000000003 ffff200008179298 7ca0: ffff20000ae1c180 dfff200000000000 0000000000000000 ffff2000081f9a88 7cc0: ffff200009eb5960 ffff200009e97cf0 0000000000001600 ffff0400041b064b 7ce0: 0000000000000000 0000000000000002 0000000200000001 0000000000000001 7d00: ffff20000842197c 0000ffff958c4970 0000000000000000 ffff8006da0d5b80 7d20: ffff8006d4678498 0000000000000000 000000126bde0a8b ffff8006d4678480 7d40: 0000000000000000 000000126bdbea64 ffff200008fd0000 ffff8006fffff980 7d60: 00000000495f0018 ffff200009e97dc0 ffff200008b6c4ec ffff200009e97dc0 7d80: ffff200008b6c4f0 0000000020000145 ffff8006da0d5b80 ffff8006d4678498 7da0: ffffffffffffffff ffff8006d4678498 ffff200009e97dc0 ffff200008b6c4f0 [<ffff200008084034>] el1_irq+0xb4/0x12c [<ffff200008b6c4f0>] cpuidle_enter_state+0x818/0x844 [<ffff200008b6c59c>] cpuidle_enter+0x18/0x20 [<ffff20000815f2e4>] call_cpuidle+0x98/0x9c [<ffff20000815f674>] do_idle+0x214/0x264 [<ffff20000815facc>] cpu_startup_entry+0x20/0x24 [<ffff200008fb09d8>] rest_init+0x30c/0x320 [<ffff2000095f1338>] start_kernel+0x570/0x5b0 ---<-snip->--- Fixes: 132fcb460839 ("usb: gadget: Add Audio Class 2.0 Driver") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: u_audio: remove cached period bytes valueVladimir Zapolskiy1-35/+5
Substream period size potentially can be changed in runtime, however this is not accounted in the data copying routine, the change replaces the cached value with an actual value from substream runtime. As a side effect the change also removes a potential division by zero in u_audio_iso_complete() function, if there is a race with uac_pcm_hw_free(), which sets prm->period_size to 0. Fixes: 132fcb460839 ("usb: gadget: Add Audio Class 2.0 Driver") Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: u_audio: remove caching of stream buffer parametersVladimir Zapolskiy1-17/+13
There is no necessity to copy PCM stream ring buffer area and size properties to UAC private data structure, these values can be got from substream itself. The change gives more control on substream and avoid stale caching. Fixes: 132fcb460839 ("usb: gadget: Add Audio Class 2.0 Driver") Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: u_audio: update hw_ptr in iso_complete after data copiedJoshua Frkuska1-1/+5
In u_audio_iso_complete, the runtime hw_ptr is updated before the data is actually copied over to/from the buffer/dma area. When ALSA uses this hw_ptr, the data may not actually be available to be used. This causes trash/stale audio to play/record. This patch updates the hw_ptr after the data has been copied to avoid this. Fixes: 132fcb460839 ("usb: gadget: Add Audio Class 2.0 Driver") Signed-off-by: Joshua Frkuska <joshua_frkuska@mentor.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: u_audio: fix pcm/card naming in g_audio_setup()Eugeniu Rosca1-3/+3
Fix below smatch (v0.5.0-4443-g69e9094e11c1) warnings: drivers/usb/gadget/function/u_audio.c:607 g_audio_setup() warn: strcpy() 'pcm_name' of unknown size might be too large for 'pcm->name' drivers/usb/gadget/function/u_audio.c:614 g_audio_setup() warn: strcpy() 'card_name' of unknown size might be too large for 'card->driver' drivers/usb/gadget/function/u_audio.c:615 g_audio_setup() warn: strcpy() 'card_name' of unknown size might be too large for 'card->shortname' Below commits performed a similar 's/strcpy/strlcpy/' rework: * v2.6.31 commit 8372d4980fbc ("ALSA: ctxfi - Fix PCM device naming") * v4.14 commit 003d3e70dbeb ("ALSA: ad1848: fix format string overflow warning") * v4.14 commit 6d8b04de87e1 ("ALSA: cs423x: fix format string overflow warning") Fixes: eb9fecb9e69b ("usb: gadget: f_uac2: split out audio core") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: f_uac2: fix error handling in afunc_bind (again)Eugeniu Rosca1-2/+2
If usb_ep_autoconfig() fails (i.e. returns a null endpoint descriptor), we expect afunc_bind() to fail (i.e. return a negative error code). However, due to v4.10-rc1 commit f1d3861d63a5 ("usb: gadget: f_uac2: fix error handling at afunc_bind"), afunc_bind() returns zero, telling the caller that it succeeded. This then generates NULL pointer dereference in below scenario on Rcar H3-ES20-Salvator-X target: rcar-gen3:/home/root# modprobe g_audio [ 626.521155] g_audio gadget: afunc_bind:565 Error! [ 626.526319] g_audio gadget: Linux USB Audio Gadget, version: Feb 2, 2012 [ 626.533405] g_audio gadget: g_audio ready rcar-gen3:/home/root# rcar-gen3:/home/root# modprobe -r g_audio [ 728.256707] ================================================================== [ 728.264293] BUG: KASAN: null-ptr-deref in u_audio_stop_capture+0x70/0x268 [u_audio] [ 728.272244] Read of size 8 at addr 00000000000000a0 by task modprobe/2545 [ 728.279309] [ 728.280849] CPU: 0 PID: 2545 Comm: modprobe Tainted: G WC 4.14.47+ #152 [ 728.288778] Hardware name: Renesas Salvator-X board based on r8a7795 ES2.0+ (DT) [ 728.296454] Call trace: [ 728.299151] [<ffff2000080925ac>] dump_backtrace+0x0/0x364 [ 728.304808] [<ffff200008092924>] show_stack+0x14/0x1c [ 728.310081] [<ffff200008f8d5cc>] dump_stack+0x108/0x174 [ 728.315522] [<ffff2000083c77c8>] kasan_report+0x1fc/0x354 [ 728.321134] [<ffff2000083c611c>] __asan_load8+0x24/0x94 [ 728.326600] [<ffff2000021e1618>] u_audio_stop_capture+0x70/0x268 [u_audio] [ 728.333735] [<ffff2000021f8b7c>] afunc_disable+0x44/0x60 [usb_f_uac2] [ 728.340503] [<ffff20000218177c>] usb_remove_function+0x9c/0x210 [libcomposite] [ 728.348060] [<ffff200002183320>] remove_config.isra.2+0x1d8/0x218 [libcomposite] [ 728.355788] [<ffff200002186c54>] __composite_unbind+0x104/0x1f8 [libcomposite] [ 728.363339] [<ffff200002186d58>] composite_unbind+0x10/0x18 [libcomposite] [ 728.370536] [<ffff20000152f158>] usb_gadget_remove_driver+0xc0/0x170 [udc_core] [ 728.378172] [<ffff20000153154c>] usb_gadget_unregister_driver+0x1cc/0x258 [udc_core] [ 728.386274] [<ffff200002180de8>] usb_composite_unregister+0x10/0x18 [libcomposite] [ 728.394116] [<ffff2000021d035c>] audio_driver_exit+0x14/0x28 [g_audio] [ 728.400878] [<ffff200008213ed4>] SyS_delete_module+0x288/0x32c [ 728.406935] Exception stack(0xffff8006cf6c7ec0 to 0xffff8006cf6c8000) [ 728.413624] 7ec0: 0000000006136428 0000000000000800 0000000000000000 0000ffffd706efe8 [ 728.421718] 7ee0: 0000ffffd706efe9 000000000000000a 1999999999999999 0000000000000000 [ 728.429792] 7f00: 000000000000006a 000000000042c078 0000000000000000 0000000000000005 [ 728.437870] 7f20: 0000000000000000 0000000000000000 0000000000000004 0000000000000000 [ 728.445952] 7f40: 000000000042bfc8 0000ffffbc7c8f40 0000000000000000 00000000061363c0 [ 728.454035] 7f60: 0000000006136428 0000000000000000 0000000000000000 0000000006136428 [ 728.462114] 7f80: 000000000042c000 0000ffffd7071448 000000000042c000 0000000000000000 [ 728.470190] 7fa0: 00000000061350c0 0000ffffd7070010 000000000041129c 0000ffffd7070010 [ 728.478281] 7fc0: 0000ffffbc7c8f48 0000000060000000 0000000006136428 000000000000006a [ 728.486351] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 728.494434] [<ffff200008084780>] el0_svc_naked+0x34/0x38 [ 728.499957] ================================================================== [ 728.507801] Unable to handle kernel NULL pointer dereference at virtual address 000000a0 [ 728.517742] Mem abort info: [ 728.520993] Exception class = DABT (current EL), IL = 32 bits [ 728.527375] SET = 0, FnV = 0 [ 728.530731] EA = 0, S1PTW = 0 [ 728.534361] Data abort info: [ 728.537650] ISV = 0, ISS = 0x00000006 [ 728.541863] CM = 0, WnR = 0 [ 728.545167] user pgtable: 4k pages, 48-bit VAs, pgd = ffff8006c6100000 [ 728.552156] [00000000000000a0] *pgd=0000000716a8d003 [ 728.557519] , *pud=00000007116fc003 [ 728.561259] , *pmd=0000000000000000 [ 728.564985] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 728.570815] Modules linked in: [ 728.574023] usb_f_uac2 [ 728.576560] u_audio [ 728.578827] g_audio(-) [ 728.581361] libcomposite [ 728.584071] configfs [ 728.586428] aes_ce_blk [ 728.588960] sata_rcar [ 728.591421] crypto_simd [ 728.594039] cryptd [ 728.596217] libata [ 728.598396] aes_ce_cipher [ 728.601188] crc32_ce [ 728.603542] ghash_ce [ 728.605896] gf128mul [ 728.608250] aes_arm64 [ 728.610692] scsi_mod [ 728.613046] sha2_ce [ 728.615313] xhci_plat_hcd [ 728.618106] sha256_arm64 [ 728.620811] sha1_ce [ 728.623077] renesas_usbhs [ 728.625869] xhci_hcd [ 728.628243] renesas_usb3 [ 728.630948] sha1_generic [ 728.633670] ravb_streaming(C) [ 728.636814] udc_core [ 728.639168] cpufreq_dt [ 728.641697] rcar_gen3_thermal [ 728.644840] usb_dmac [ 728.647194] pwm_rcar [ 728.649548] thermal_sys [ 728.652165] virt_dma [ 728.654519] mch_core(C) [ 728.657137] pwm_bl [ 728.659315] snd_soc_rcar [ 728.662020] snd_aloop [ 728.664462] snd_soc_generic_card [ 728.667869] snd_soc_ak4613 [ 728.670749] ipv6 [ 728.672768] autofs4 [ 728.675052] CPU: 0 PID: 2545 Comm: modprobe Tainted: G B WC 4.14.47+ #152 [ 728.682973] Hardware name: Renesas Salvator-X board based on r8a7795 ES2.0+ (DT) [ 728.690637] task: ffff8006ced38000 task.stack: ffff8006cf6c0000 [ 728.696814] PC is at u_audio_stop_capture+0x70/0x268 [u_audio] [ 728.702896] LR is at u_audio_stop_capture+0x70/0x268 [u_audio] [ 728.708964] pc : [<ffff2000021e1618>] lr : [<ffff2000021e1618>] pstate: 60000145 [ 728.716620] sp : ffff8006cf6c7a50 [ 728.720154] x29: ffff8006cf6c7a50 [ 728.723760] x28: ffff8006ced38000 [ 728.727272] x27: ffff200008fd7000 [ 728.730857] x26: ffff2000021d2340 [ 728.734361] x25: 0000000000000000 [ 728.737948] x24: ffff200009e94b08 [ 728.741452] x23: 00000000000000a0 [ 728.745052] x22: 00000000000000a8 [ 728.748558] x21: 1ffff000d9ed8f7c [ 728.752142] x20: ffff8006d671a800 [ 728.755646] x19: 0000000000000000 [ 728.759231] x18: 0000000000000000 [ 728.762736] x17: 0000ffffbc7c8f40 [ 728.766320] x16: ffff200008213c4c [ 728.769823] x15: 0000000000000000 [ 728.773408] x14: 0720072007200720 [ 728.776912] x13: 0720072007200720 [ 728.780497] x12: ffffffffffffffff [ 728.784001] x11: 0000000000000040 [ 728.787598] x10: 0000000000001600 [ 728.791103] x9 : ffff8006cf6c77a0 [ 728.794689] x8 : ffff8006ced39660 [ 728.798193] x7 : ffff20000811c738 [ 728.801794] x6 : 0000000000000000 [ 728.805299] x5 : dfff200000000000 [ 728.808885] x4 : ffff8006ced38000 [ 728.812390] x3 : ffff200008fb46e8 [ 728.815976] x2 : 0000000000000007 [ 728.819480] x1 : 3ba68643e7431500 [ 728.823066] x0 : 0000000000000000 [ 728.826574] Process modprobe (pid: 2545, stack limit = 0xffff8006cf6c0000) [ 728.833704] Call trace: [ 728.836292] Exception stack(0xffff8006cf6c7910 to 0xffff8006cf6c7a50) [ 728.842987] 7900: 0000000000000000 3ba68643e7431500 [ 728.851084] 7920: 0000000000000007 ffff200008fb46e8 ffff8006ced38000 dfff200000000000 [ 728.859173] 7940: 0000000000000000 ffff20000811c738 ffff8006ced39660 ffff8006cf6c77a0 [ 728.867248] 7960: 0000000000001600 0000000000000040 ffffffffffffffff 0720072007200720 [ 728.875323] 7980: 0720072007200720 0000000000000000 ffff200008213c4c 0000ffffbc7c8f40 [ 728.883412] 79a0: 0000000000000000 0000000000000000 ffff8006d671a800 1ffff000d9ed8f7c [ 728.891485] 79c0: 00000000000000a8 00000000000000a0 ffff200009e94b08 0000000000000000 [ 728.899561] 79e0: ffff2000021d2340 ffff200008fd7000 ffff8006ced38000 ffff8006cf6c7a50 [ 728.907636] 7a00: ffff2000021e1618 ffff8006cf6c7a50 ffff2000021e1618 0000000060000145 [ 728.915710] 7a20: 0000000000000008 0000000000000000 0000ffffffffffff 3ba68643e7431500 [ 728.923780] 7a40: ffff8006cf6c7a50 ffff2000021e1618 [ 728.928880] [<ffff2000021e1618>] u_audio_stop_capture+0x70/0x268 [u_audio] [ 728.936032] [<ffff2000021f8b7c>] afunc_disable+0x44/0x60 [usb_f_uac2] [ 728.942822] [<ffff20000218177c>] usb_remove_function+0x9c/0x210 [libcomposite] [ 728.950385] [<ffff200002183320>] remove_config.isra.2+0x1d8/0x218 [libcomposite] [ 728.958134] [<ffff200002186c54>] __composite_unbind+0x104/0x1f8 [libcomposite] [ 728.965689] [<ffff200002186d58>] composite_unbind+0x10/0x18 [libcomposite] [ 728.972882] [<ffff20000152f158>] usb_gadget_remove_driver+0xc0/0x170 [udc_core] [ 728.980522] [<ffff20000153154c>] usb_gadget_unregister_driver+0x1cc/0x258 [udc_core] [ 728.988638] [<ffff200002180de8>] usb_composite_unregister+0x10/0x18 [libcomposite] [ 728.996472] [<ffff2000021d035c>] audio_driver_exit+0x14/0x28 [g_audio] [ 729.003231] [<ffff200008213ed4>] SyS_delete_module+0x288/0x32c [ 729.009278] Exception stack(0xffff8006cf6c7ec0 to 0xffff8006cf6c8000) [ 729.015946] 7ec0: 0000000006136428 0000000000000800 0000000000000000 0000ffffd706efe8 [ 729.024022] 7ee0: 0000ffffd706efe9 000000000000000a 1999999999999999 0000000000000000 [ 729.032099] 7f00: 000000000000006a 000000000042c078 0000000000000000 0000000000000005 [ 729.040172] 7f20: 0000000000000000 0000000000000000 0000000000000004 0000000000000000 [ 729.048263] 7f40: 000000000042bfc8 0000ffffbc7c8f40 0000000000000000 00000000061363c0 [ 729.056337] 7f60: 0000000006136428 0000000000000000 0000000000000000 0000000006136428 [ 729.064411] 7f80: 000000000042c000 0000ffffd7071448 000000000042c000 0000000000000000 [ 729.072484] 7fa0: 00000000061350c0 0000ffffd7070010 000000000041129c 0000ffffd7070010 [ 729.080563] 7fc0: 0000ffffbc7c8f48 0000000060000000 0000000006136428 000000000000006a [ 729.088636] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 729.096733] [<ffff200008084780>] el0_svc_naked+0x34/0x38 [ 729.102259] Code: 9597d1b3 aa1703e0 9102a276 958792b9 (f9405275) [ 729.108617] ---[ end trace 7560c5fa3d100243 ]--- After this patch is applied, the issue is fixed: rcar-gen3:/home/root# modprobe g_audio [ 59.217127] g_audio gadget: afunc_bind:565 Error! [ 59.222329] g_audio ee020000.usb: failed to start g_audio: -19 modprobe: ERROR: could not insert 'g_audio': No such device rcar-gen3:/home/root# modprobe -r g_audio rcar-gen3:/home/root# Fixes: f1d3861d63a5 ("usb: gadget: f_uac2: fix error handling at afunc_bind") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: r8a66597: Fix a possible sleep-in-atomic-context bugs in r8a66597_queue()Jia-Ju Bai1-1/+1
The driver may sleep in an interrupt handler. The function call path (from bottom to top) in Linux-4.16.7 is: [FUNC] r8a66597_queue(GFP_KERNEL) drivers/usb/gadget/udc/r8a66597-udc.c, 1193: r8a66597_queue in get_status drivers/usb/gadget/udc/r8a66597-udc.c, 1301: get_status in setup_packet drivers/usb/gadget/udc/r8a66597-udc.c, 1381: setup_packet in irq_control_stage drivers/usb/gadget/udc/r8a66597-udc.c, 1508: irq_control_stage in r8a66597_irq (interrupt handler) To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool (DSAC-2) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: r8a66597: Fix two possible sleep-in-atomic-context bugs in init_controller()Jia-Ju Bai1-2/+2
The driver may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.16.7 are: [FUNC] msleep drivers/usb/gadget/udc/r8a66597-udc.c, 839: msleep in init_controller drivers/usb/gadget/udc/r8a66597-udc.c, 96: init_controller in r8a66597_usb_disconnect drivers/usb/gadget/udc/r8a66597-udc.c, 93: spin_lock in r8a66597_usb_disconnect [FUNC] msleep drivers/usb/gadget/udc/r8a66597-udc.c, 835: msleep in init_controller drivers/usb/gadget/udc/r8a66597-udc.c, 96: init_controller in r8a66597_usb_disconnect drivers/usb/gadget/udc/r8a66597-udc.c, 93: spin_lock in r8a66597_usb_disconnect To fix these bugs, msleep() is replaced with mdelay(). This bug is found by my static analysis tool (DSAC-2) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: Fix OS descriptors supportBenjamin Herrenschmidt1-1/+0
The current code is broken as it re-defines "req" inside the if block, then goto out of it. Thus the request that ends up being sent is not the one that was populated by the code in question. This fixes RNDIS driver autodetect by Windows 10 for me. The bug was introduced by Chris rework to remove the local queuing inside the if { } block of the redefined request. Fixes: 636ba13aec8a ("usb: gadget: composite: remove duplicated code in OS desc handling") Cc: <stable@vger.kernel.org> # v4.17 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-17usb: gadget: aspeed-vhub: Fix SETUP packets with OUT data phaseBenjamin Herrenschmidt1-1/+8
A couple of bugs in the driver are preventing SETUP packets with an OUT data phase from working properly. Interestingly those are incredibly rare (RNDIS typically uses them and thus is broken without this fix). The main problem was an incorrect register offset being applied for arming RX on EP0. The other problem relates to stalling such a packet before the data phase, in which case we don't get an ACK cycle, and get the next SETUP packet directly, so we shouldn't reject it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-07-16usb: cdc_acm: Add quirk for Castles VEGA3000Lubomir Rintel1-0/+3
The device (a POS terminal) implements CDC ACM, but has not union descriptor. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Acked-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-15Linux 4.18-rc5Linus Torvalds1-1/+1
2018-07-14reiserfs: fix buffer overflow with long warning messagesEric Biggers1-60/+81
ReiserFS prepares log messages into a 1024-byte buffer with no bounds checks. Long messages, such as the "unknown mount option" warning when userspace passes a crafted mount options string, overflow this buffer. This causes KASAN to report a global-out-of-bounds write. Fix it by truncating messages to the buffer size. Link: http://lkml.kernel.org/r/20180707203621.30922-1-ebiggers3@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+b890b3335a4d8c608963@syzkaller.appspotmail.com Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14checkpatch: fix duplicate invalid vsprintf pointer extension '%p<foo>' messagesJoe Perches1-3/+3
Multiline statements with invalid %p<foo> uses produce multiple warnings. Fix that. e.g.: $ cat t_block.c void foo(void) { MY_DEBUG(drv->foo, "%pk", foo->boo); } $ ./scripts/checkpatch.pl -f t_block.c WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #1: FILE: t_block.c:1: +void foo(void) WARNING: Invalid vsprintf pointer extension '%pk' #3: FILE: t_block.c:3: + MY_DEBUG(drv->foo, + "%pk", + foo->boo); WARNING: Invalid vsprintf pointer extension '%pk' #3: FILE: t_block.c:3: + MY_DEBUG(drv->foo, + "%pk", + foo->boo); total: 0 errors, 3 warnings, 6 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. t_block.c has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Link: http://lkml.kernel.org/r/9e8341bbe4c9877d159cb512bb701043cbfbb10b.camel@perches.com Signed-off-by: Joe Perches <joe@perches.com> Cc: "Tobin C. Harding" <me@tobin.cc> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: do not bug_on on incorrect length in __mm_populate()Michal Hocko2-19/+12
syzbot has noticed that a specially crafted library can easily hit VM_BUG_ON in __mm_populate kernel BUG at mm/gup.c:1242! invalid opcode: 0000 [#1] SMP CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 RIP: 0010:__mm_populate+0x1e2/0x1f0 Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb Call Trace: vm_brk_flags+0xc3/0x100 vm_brk+0x1f/0x30 load_elf_library+0x281/0x2e0 __ia32_sys_uselib+0x170/0x1e0 do_fast_syscall_32+0xca/0x420 entry_SYSENTER_compat+0x70/0x7f The reason is that the length of the new brk is not page aligned when we try to populate the it. There is no reason to bug on that though. do_brk_flags already aligns the length properly so the mapping is expanded as it should. All we need is to tell mm_populate about it. Besides that there is absolutely no reason to to bug_on in the first place. The worst thing that could happen is that the last page wouldn't get populated and that is far from putting system into an inconsistent state. Fix the issue by moving the length sanitization code from do_brk_flags up to vm_brk_flags. The only other caller of do_brk_flags is brk syscall entry and it makes sure to provide the proper length so t here is no need for sanitation and so we can use do_brk_flags without it. Also remove the bogus BUG_ONs. [osalvador@techadventures.net: fix up vm_brk_flags s@request@len@] Link: http://lkml.kernel.org/r/20180706090217.GI32658@dhcp22.suse.cz Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: syzbot <syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com> Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Oscar Salvador <osalvador@suse.de> Cc: Zi Yan <zi.yan@cs.rutgers.edu> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Huang, Ying" <ying.huang@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm/memblock.c: do not complain about top-down allocations for !MEMORY_HOTREMOVEMichal Hocko1-1/+2
Mike Rapoport is converting architectures from bootmem to nobootmem allocator. While doing so for m68k Geert has noticed that he gets a scary looking warning: WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 memblock_find_in_range_node+0x11c/0x1be memblock: bottom-up allocation failed, memory hotunplug may be affected Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7 Call Trace: __warn+0xa8/0xc2 kernel_pg_dir+0x0/0x1000 netdev_lower_get_next+0x2/0x22 warn_slowpath_fmt+0x2e/0x36 memblock_find_in_range_node+0x11c/0x1be memblock_find_in_range_node+0x11c/0x1be memblock_find_in_range_node+0x0/0x1be vprintk_func+0x66/0x6e memblock_virt_alloc_internal+0xd0/0x156 netdev_lower_get_next+0x2/0x22 netdev_lower_get_next+0x2/0x22 kernel_pg_dir+0x0/0x1000 memblock_virt_alloc_try_nid_nopanic+0x58/0x7a netdev_lower_get_next+0x2/0x22 kernel_pg_dir+0x0/0x1000 kernel_pg_dir+0x0/0x1000 EXPTBL+0x234/0x400 EXPTBL+0x234/0x400 alloc_node_mem_map+0x4a/0x66 netdev_lower_get_next+0x2/0x22 free_area_init_node+0xe2/0x29e EXPTBL+0x234/0x400 paging_init+0x430/0x462 kernel_pg_dir+0x0/0x1000 printk+0x0/0x1a EXPTBL+0x234/0x400 setup_arch+0x1b8/0x22c start_kernel+0x4a/0x40a _sinittext+0x344/0x9e8 The warning is basically saying that a top-down allocation can break memory hotremove because memblock allocation is not movable. But m68k doesn't even support MEMORY_HOTREMOVE so there is no point to warn about it. Make the warning conditional only to configurations that care. Link: http://lkml.kernel.org/r/20180706061750.GH32658@dhcp22.suse.cz Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Sam Creasey <sammy@sammy.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14fs, elf: make sure to page align bss in load_elf_libraryOscar Salvador1-3/+2
The current code does not make sure to page align bss before calling vm_brk(), and this can lead to a VM_BUG_ON() in __mm_populate() due to the requested lenght not being correctly aligned. Let us make sure to align it properly. Kees: only applicable to CONFIG_USELIB kernels: 32-bit and configured for libc5. Link: http://lkml.kernel.org/r/20180705145539.9627-1-osalvador@techadventures.net Signed-off-by: Oscar Salvador <osalvador@suse.de> Reported-by: syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Acked-by: Kees Cook <keescook@chromium.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14x86/purgatory: add missing FORCE to Makefile targetPhilipp Rudo1-1/+1
- Build the kernel without the fix - Add some flag to the purgatories KBUILD_CFLAGS,I used -fno-asynchronous-unwind-tables - Re-build the kernel When you look at makes output you see that sha256.o is not re-build in the last step. Also readelf -S still shows the .eh_frame section for sha256.o. With the fix sha256.o is rebuilt in the last step. Without FORCE make does not detect changes only made to the command line options. So object files might not be re-built even when they should be. Fix this by adding FORCE where it is missing. Link: http://lkml.kernel.org/r/20180704110044.29279-2-prudo@linux.ibm.com Fixes: df6f2801f511 ("kernel/kexec_file.c: move purgatories sha256 to common code") Signed-off-by: Philipp Rudo <prudo@linux.ibm.com> Acked-by: Dave Young <dyoung@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> [4.17+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14net/9p/client.c: put refcount of trans_mod in error case in parse_opts()piaojun1-1/+2
In my testing, the second mount will fail after umounting successfully. The reason is that we put refcount of trans_mod in the correct case rather than the error case in parse_opts() at last. That will cause the refcount decrease to -1, and when we try to get trans_mod again in try_module_get(), we could only increase refcount to 0 which will cause failure as follows: parse_opts v9fs_get_trans_by_name try_module_get : return NULL to caller which cause error So we should put refcount of trans_mod in error case. Link: http://lkml.kernel.org/r/5B3F39A0.2030509@huawei.com Fixes: 9421c3e64137ec ("net/9p/client.c: fix potential refcnt problem of trans module") Signed-off-by: Jun Piao <piaojun@huawei.com> Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Dominique Martinet <dominique.martinet@cea.fr> Tested-by: Dominique Martinet <dominique.martinet@cea.fr> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: allow arch to supply p??_free_tlb functionsNicholas Piggin1-0/+8
The mmu_gather APIs keep track of the invalidated address range including the span covered by invalidated page table pages. Ranges covered by page tables but not ptes (and therefore no TLBs) still need to be invalidated because some architectures (x86) can cache intermediate page table entries, and invalidate those with normal TLB invalidation instructions to be almost-backward-compatible. Architectures which don't cache intermediate page table entries, or which invalidate these caches separately from TLB invalidation, do not require TLB invalidation range expanded over page tables. Allow architectures to supply their own p??_free_tlb functions, which can avoid the __tlb_adjust_range. Link: http://lkml.kernel.org/r/20180703013131.2807-1-npiggin@gmail.com Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Nadav Amit <nadav.amit@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14autofs: fix slab out of bounds read in getname_kernel()Tomas Bortoli1-9/+13
The autofs subsystem does not check that the "path" parameter is present for all cases where it is required when it is passed in via the "param" struct. In particular it isn't checked for the AUTOFS_DEV_IOCTL_OPENMOUNT_CMD ioctl command. To solve it, modify validate_dev_ioctl(function to check that a path has been provided for ioctl commands that require it. Link: http://lkml.kernel.org/r/153060031527.26631.18306637892746301555.stgit@pluto.themaw.net Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com> Signed-off-by: Ian Kent <raven@themaw.net> Reported-by: syzbot+60c837b428dc84e83a93@syzkaller.appspotmail.com Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps*Vlastimil Babka1-1/+2
Thomas reports: "While looking around in /proc on my v4.14.52 system I noticed that all processes got a lot of "Locked" memory in /proc/*/smaps. A lot more memory than a regular user can usually lock with mlock(). Commit 493b0e9d945f (in v4.14-rc1) seems to have changed the behavior of "Locked". Before that commit the code was like this. Notice the VM_LOCKED check. (vma->vm_flags & VM_LOCKED) ? (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0); After that commit Locked is now the same as Pss: (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); This looks like a mistake." Indeed, the commit has added mss->pss_locked with the correct value that depends on VM_LOCKED, but forgot to actually use it. Fix it. Link: http://lkml.kernel.org/r/ebf6c7fb-fec3-6a26-544f-710ed193c154@suse.cz Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Daniel Colascione <dancol@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: do not drop unused pages when userfaultd is runningChristian Borntraeger1-1/+7
KVM guests on s390 can notify the host of unused pages. This can result in pte_unused callbacks to be true for KVM guest memory. If a page is unused (checked with pte_unused) we might drop this page instead of paging it. This can have side-effects on userfaultd, when the page in question was already migrated: The next access of that page will trigger a fault and a user fault instead of faulting in a new and empty zero page. As QEMU does not expect a userfault on an already migrated page this migration will fail. The most straightforward solution is to ignore the pte_unused hint if a userfault context is active for this VMA. Link: http://lkml.kernel.org/r/20180703171854.63981-1-borntraeger@de.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: zero unavailable pages before memmap initPavel Tatashin1-2/+2
We must zero struct pages for memory that is not backed by physical memory, or kernel does not have access to. Recently, there was a change which zeroed all memmap for all holes in e820. Unfortunately, it introduced a bug that is discussed here: https://www.spinics.net/lists/linux-mm/msg156764.html Linus, also saw this bug on his machine, and confirmed that reverting commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") fixes the issue. The problem is that we incorrectly zero some struct pages after they were setup. The fix is to zero unavailable struct pages prior to initializing of struct pages. A more detailed fix should come later that would avoid double zeroing cases: one in __init_single_page(), the other one in zero_resv_unavail(). Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-13rtc: fix alarm read and set offsetAlexandre Belloni1-3/+5
The offset needs to be added after reading the alarm value. It also needs to be subtracted after the now < alarm test. Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-07-13xen: setup pv irq ops vector earlierJuergen Gross2-16/+12
Setting pv_irq_ops for Xen PV domains should be done as early as possible in order to support e.g. very early printk() usage. The same applies to xen_vcpu_info_reset(0), as it is needed for the pv irq ops. Move the call of xen_setup_machphys_mapping() after initializing the pv functions as it contains a WARN_ON(), too. Remove the no longer necessary conditional in xen_init_irq_ops() from PVH V1 times to make clear this is a PV only function. Cc: <stable@vger.kernel.org> # 4.14 Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-07-12tracing: Reorder display of TGID to be after PIDJoel Fernandes (Google)2-6/+7
Currently ftrace displays data in trace output like so: _-----=> irqs-off / _----=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU TGID |||| TIMESTAMP FUNCTION | | | | |||| | | bash-1091 [000] ( 1091) d..2 28.313544: sched_switch: However Android's trace visualization tools expect a slightly different format due to an out-of-tree patch patch that was been carried for a decade, notice that the TGID and CPU fields are reversed: _-----=> irqs-off / _----=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID TGID CPU |||| TIMESTAMP FUNCTION | | | | |||| | | bash-1091 ( 1091) [002] d..2 64.965177: sched_switch: From kernel v4.13 onwards, during which TGID was introduced, tracing with systrace on all Android kernels will break (most Android kernels have been on 4.9 with Android patches, so this issues hasn't been seen yet). From v4.13 onwards things will break. The chrome browser's tracing tools also embed the systrace viewer which uses the legacy TGID format and updates to that are known to be difficult to make. Considering this, I suggest we make this change to the upstream kernel and backport it to all Android kernels. I believe this feature is merged recently enough into the upstream kernel that it shouldn't be a problem. Also logically, IMO it makes more sense to group the TGID with the TASK-PID and the CPU after these. Link: http://lkml.kernel.org/r/20180626000822.113931-1-joel@joelfernandes.org Cc: jreck@google.com Cc: tkjos@google.com Cc: stable@vger.kernel.org Fixes: 441dae8f2f29 ("tracing: Add support for display of tgid in trace output") Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-07-12i2c: recovery: if possible send STOP with recovery pulsesWolfram Sang1-1/+10
I2C clients may misunderstand recovery pulses if they can't read SDA to bail out early. In the worst case, as a write operation. To avoid that and if we can write SDA, try to send STOP to avoid the misinterpretation. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2018-07-13kbuild: suppress warnings from 'getconf LFS_*'Masahiro Yamada1-3/+3
Suppress warnings for systems that do not recognize LFS_*. getconf: no such configuration parameter `LFS_CFLAGS' getconf: no such configuration parameter `LFS_LDFLAGS' getconf: no such configuration parameter `LFS_LIBS' Fixes: d7f14c66c273 ("kbuild: Enable Large File Support for hostprogs") Reported-by: Chen Feng <puck.chen@hisilicon.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2018-07-13scripts/tags.sh: add __ro_after_initConstantine Shulyupin1-1/+1
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-13tools: build: Use HOSTLDFLAGS with fixdepLaura Abbott1-1/+1
The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS. Fix this. Signed-off-by: Laura Abbott <labbott@redhat.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-13tools: build: Fixup host c flagsLaura Abbott2-2/+2
Commit 0c3b7e42616f ("tools build: Add support for host programs format") introduced host_c_flags which referenced CHOSTFLAGS. The actual name of the variable is HOSTCFLAGS. Fix this up. Fixes: 0c3b7e42616f ("tools build: Add support for host programs format") Signed-off-by: Laura Abbott <labbott@redhat.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-13tools build: fix # escaping in .cmd files for future MakePaul Menzel1-2/+2
In 2016 GNU Make made a backwards incompatible change to the way '#' characters were handled in Makefiles when used inside functions or macros: http://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b57 Due to this change, when attempting to run `make prepare' I get a spurious make syntax error: /home/earnest/linux/tools/objtool/.fixdep.o.cmd:1: *** missing separator. Stop. When inspecting `.fixdep.o.cmd' it includes two lines which use unescaped comment characters at the top: \# cannot find fixdep (/home/earnest/linux/tools/objtool//fixdep) \# using basic dep data This is because `tools/build/Build.include' prints these '\#' characters: printf '\# cannot find fixdep (%s)\n' $(fixdep) > $(dot-target).cmd; \ printf '\# using basic dep data\n\n' >> $(dot-target).cmd; \ This completes commit 9564a8cf422d ("Kbuild: fix # escaping in .cmd files for future Make"). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: stable@vger.kernel.org Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-12ARM: dts: am3517.dtsi: Disable reference to OMAP3 OTG controllerAdam Ford1-0/+5
The AM3517 has a different OTG controller location than the OMAP3, which is included from omap3.dtsi. This results in a hwmod error. Since the AM3517 has a different OTG controller address, this patch disabes one that is isn't available. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-07-12ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary coresNishanth Menon1-0/+41
Call secure services to enable ACTLR[0] (Enable invalidates of BTB with ICIALLU) when branch hardening is enabled for kernel. On GP devices OMAP5/DRA7, there is no possibility to update secure side since "secure world" is ROM and there are no override mechanisms possible. On HS devices, appropriate PPA should do the workarounds as well. However, the configuration is only done for secondary core, since it is expected that firmware/bootloader will have enabled the required configuration for the primary boot core (note: bootloaders typically will NOT enable secondary processors, since it has no need to do so). Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-07-12xen: remove global bit from __default_kernel_pte_mask for pv guestsJuergen Gross1-0/+1
When removing the global bit from __supported_pte_mask do the same for __default_kernel_pte_mask in order to avoid the WARN_ONCE() in check_pgprot() when setting a kernel pte before having called init_mem_mapping(). Cc: <stable@vger.kernel.org> # 4.17 Reported-by: Michael Young <m.a.young@durham.ac.uk> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-07-12ALSA: hda/ca0132: Update a pci quirk device nameAlastair Bridgewater1-1/+1
The PCI subsystem in question for this quirk rule has been identified as a Gigabyte GA-Z170X-Gaming 7 motherboard. Set the device name appropriately. Signed-off-by: Alastair Bridgewater <alastair.bridgewater@gmail.com> Reviewed-by: Connor McAdams <conmanx360@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-07-12ALSA: hda/ca0132: Add Recon3Di quirk for Gigabyte G1.Sniper Z97Alastair Bridgewater1-0/+1
These motherboards have Sound Core3D and apparently "support" Recon3Di. Added to the quirk list as QUIRK_R3DI. Issue report, PCI Subsystem ID, and testing by a contributor on IRC who wished to remain anonymous. Signed-off-by: Alastair Bridgewater <alastair.bridgewater@gmail.com> Reviewed-by: Connor McAdams <conmanx360@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-07-11ARM: 8780/1: ftrace: Only set kernel memory back to read-only after bootSteven Rostedt (VMware)1-0/+9
Dynamic ftrace requires modifying the code segments that are usually set to read-only. To do this, a per arch function is called both before and after the ftrace modifications are performed. The "before" function will set kernel code text to read-write to allow for ftrace to make the modifications, and the "after" function will set the kernel code text back to "read-only" to keep the kernel code text protected. The issue happens when dynamic ftrace is tested at boot up. The test is done before the kernel code text has been set to read-only. But the "before" and "after" calls are still performed. The "after" call will change the kernel code text to read-only prematurely, and other boot code that expects this code to be read-write will fail. The solution is to add a variable that is set when the kernel code text is expected to be converted to read-only, and make the ftrace "before" and "after" calls do nothing if that variable is not yet set. This is similar to the x86 solution from commit 162396309745 ("ftrace, x86: make kernel text writable only for conversions"). Link: http://lkml.kernel.org/r/20180620212906.24b7b66e@vmware.local.home Reported-by: Stefan Agner <stefan@agner.ch> Tested-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-07-11RDMA/mlx5: Fix memory leak in mlx5_ib_create_srq() error pathKamal Heib1-6/+12
Fix memory leak in the error path of mlx5_ib_create_srq() by making sure to free the allocated srq. Fixes: c2b37f76485f ("IB/mlx5: Fix integer overflows in mlx5_ib_create_srq") Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Acked-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>