aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-08-15usb: chipidea: imx: fix EPROBE_DEFER support during driver probeAndré Draszik1-7/+12
If driver probe needs to be deferred, e.g. because ci_hdrc_add_device() isn't ready yet, this driver currently misbehaves badly: a) success is still reported to the driver core (meaning a 2nd probe attempt will never be done), leaving the driver in a dysfunctional state and the hardware unusable b) driver remove / shutdown OOPSes: [ 206.786916] Unable to handle kernel paging request at virtual address fffffdff [ 206.794148] pgd = 880b9f82 [ 206.796890] [fffffdff] *pgd=abf5e861, *pte=00000000, *ppte=00000000 [ 206.803179] Internal error: Oops: 37 [#1] PREEMPT SMP ARM [ 206.808581] Modules linked in: wl18xx evbug [ 206.813308] CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 4.19.35+gf345c93b4195 #1 [ 206.821053] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 206.826813] PC is at ci_hdrc_remove_device+0x4/0x20 [ 206.831699] LR is at ci_hdrc_imx_remove+0x20/0xe8 [ 206.836407] pc : [<805cd4b0>] lr : [<805d62cc>] psr: 20000013 [ 206.842678] sp : a806be40 ip : 00000001 fp : 80adbd3c [ 206.847906] r10: 80b1b794 r9 : 80d5dfe0 r8 : a8192c44 [ 206.853136] r7 : 80db93a0 r6 : a8192c10 r5 : a8192c00 r4 : a93a4a00 [ 206.859668] r3 : 00000000 r2 : a8192ce4 r1 : ffffffff r0 : fffffdfb [ 206.866201] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 206.873341] Control: 10c5387d Table: a9e0c06a DAC: 00000051 [ 206.879092] Process systemd-shutdow (pid: 1, stack limit = 0xb271353c) [ 206.885624] Stack: (0xa806be40 to 0xa806c000) [ 206.889992] be40: a93a4a00 805d62cc a8192c1c a8170e10 a8192c10 8049a490 80d04d08 00000000 [ 206.898179] be60: 00000000 80d0da2c fee1dead 00000000 a806a000 00000058 00000000 80148b08 [ 206.906366] be80: 01234567 80148d8c a9858600 00000000 00000000 00000000 00000000 80d04d08 [ 206.914553] bea0: 00000000 00000000 a82741e0 a9858600 00000024 00000002 a9858608 00000005 [ 206.922740] bec0: 0000001e 8022c058 00000000 00000000 a806bf14 a9858600 00000000 a806befc [ 206.930927] bee0: a806bf78 00000000 7ee12c30 8022c18c a806bef8 a806befc 00000000 00000001 [ 206.939115] bf00: 00000000 00000024 a806bf14 00000005 7ee13b34 7ee12c68 00000004 7ee13f20 [ 206.947302] bf20: 00000010 7ee12c7c 00000005 7ee12d04 0000000a 76e7dc00 00000001 80d0f140 [ 206.955490] bf40: ab637880 a974de40 60000013 80d0f140 ab6378a0 80d04d08 a8080470 a9858600 [ 206.963677] bf60: a9858600 00000000 00000000 8022c24c 00000000 80144310 00000000 00000000 [ 206.971864] bf80: 80101204 80d04d08 00000000 80d04d08 00000000 00000000 00000003 00000058 [ 206.980051] bfa0: 80101204 80101000 00000000 00000000 fee1dead 28121969 01234567 00000000 [ 206.988237] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000 [ 206.996425] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 60000030 fee1dead 00000000 00000000 [ 207.004622] [<805cd4b0>] (ci_hdrc_remove_device) from [<805d62cc>] (ci_hdrc_imx_remove+0x20/0xe8) [ 207.013509] [<805d62cc>] (ci_hdrc_imx_remove) from [<8049a490>] (device_shutdown+0x16c/0x218) [ 207.022050] [<8049a490>] (device_shutdown) from [<80148b08>] (kernel_restart+0xc/0x50) [ 207.029980] [<80148b08>] (kernel_restart) from [<80148d8c>] (sys_reboot+0xf4/0x1f0) [ 207.037648] [<80148d8c>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54) [ 207.045308] Exception stack(0xa806bfa8 to 0xa806bff0) [ 207.050368] bfa0: 00000000 00000000 fee1dead 28121969 01234567 00000000 [ 207.058554] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000 [ 207.066737] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 [ 207.071799] Code: ebffffa8 e3a00000 e8bd8010 e92d4010 (e5904004) [ 207.078021] ---[ end trace be47424e3fd46e9f ]--- [ 207.082647] Kernel panic - not syncing: Fatal exception [ 207.087894] ---[ end Kernel panic - not syncing: Fatal exception ]--- c) the error path in combination with driver removal causes imbalanced calls to the clk_*() and pm_()* APIs a) happens because the original intended return value is overwritten (with 0) by the return code of regulator_disable() in ci_hdrc_imx_probe()'s error path b) happens because ci_pdev is -EPROBE_DEFER, which causes ci_hdrc_remove_device() to OOPS Fix a) by being more careful in ci_hdrc_imx_probe()'s error path and not overwriting the real error code Fix b) by calling the respective cleanup functions during remove only when needed (when ci_pdev != NULL, i.e. when everything was initialised correctly). This also has the side effect of not causing imbalanced clk_*() and pm_*() API calls as part of the error code path. Fixes: 7c8e8909417e ("usb: chipidea: imx: add HSIC support") Signed-off-by: André Draszik <git@andred.net> Cc: stable <stable@vger.kernel.org> CC: Peter Chen <Peter.Chen@nxp.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Pengutronix Kernel Team <kernel@pengutronix.de> CC: Fabio Estevam <festevam@gmail.com> CC: NXP Linux Team <linux-imx@nxp.com> CC: linux-usb@vger.kernel.org CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20190810150758.17694-1-git@andred.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: host: fotg2: restart hcd after port resetHans Ulli Kroll1-0/+4
On the Gemini SoC the FOTG2 stalls after port reset so restart the HCD after each port reset. Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190810150458.817-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15USB: CDC: fix sanity checks in CDC union parserOliver Neukum1-2/+2
A few checks checked for the size of the pointer to a structure instead of the structure itself. Copy & paste issue presumably. Fixes: e4c6fb7794982 ("usbnet: move the CDC parser into USB core") Cc: stable <stable@vger.kernel.org> Reported-by: syzbot+45a53506b65321c1fe91@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20190813093541.18889-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: cdc-acm: make sure a refcount is taken early enoughOliver Neukum1-5/+7
destroy() will decrement the refcount on the interface, so that it needs to be taken so early that it never undercounts. Fixes: 7fb57a019f94e ("USB: cdc-acm: Fix potential deadlock (lockdep warning)") Cc: stable <stable@vger.kernel.org> Reported-and-tested-by: syzbot+1b2449b7b5dc240d107a@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20190808142119.7998-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-12USB: core: Fix races in character device registration and deregistraionAlan Stern1-5/+5
The syzbot fuzzer has found two (!) races in the USB character device registration and deregistration routines. This patch fixes the races. The first race results from the fact that usb_deregister_dev() sets usb_minors[intf->minor] to NULL before calling device_destroy() on the class device. This leaves a window during which another thread can allocate the same minor number but will encounter a duplicate name error when it tries to register its own class device. A typical error message in the system log would look like: sysfs: cannot create duplicate filename '/class/usbmisc/ldusb0' The patch fixes this race by destroying the class device first. The second race is in usb_register_dev(). When that routine runs, it first allocates a minor number, then drops minor_rwsem, and then creates the class device. If the device creation fails, the minor number is deallocated and the whole routine returns an error. But during the time while minor_rwsem was dropped, there is a window in which the minor number is allocated and so another thread can successfully open the device file. Typically this results in use-after-free errors or invalid accesses when the other thread closes its open file reference, because the kernel then tries to release resources that were already deallocated when usb_register_dev() failed. The patch fixes this race by keeping minor_rwsem locked throughout the entire routine. Reported-and-tested-by: syzbot+30cf45ebfe0b0c4847a1@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908121607590.1659-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-12usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_altBenjamin Herrenschmidt1-10/+18
If fsg_disable() and fsg_set_alt() are called too closely to each other (for example due to a quick reset/reconnect), what can happen is that fsg_set_alt sets common->new_fsg from an interrupt while handle_exception is trying to process the config change caused by fsg_disable(): fsg_disable() ... handle_exception() sets state back to FSG_STATE_NORMAL hasn't yet called do_set_interface() or is inside it. ---> interrupt fsg_set_alt sets common->new_fsg queues a new FSG_STATE_CONFIG_CHANGE <--- Now, the first handle_exception can "see" the updated new_fsg, treats it as if it was a fsg_set_alt() response, call usb_composite_setup_continue() etc... But then, the thread sees the second FSG_STATE_CONFIG_CHANGE, and goes back down the same path, wipes and reattaches a now active fsg, and .. calls usb_composite_setup_continue() which at this point is wrong. Not only we get a backtrace, but I suspect the second set_interface wrecks some state causing the host to get upset in my case. This fixes it by replacing "new_fsg" by a "state argument" (same principle) which is set in the same lock section as the state update, and retrieved similarly. That way, there is never any discrepancy between the dequeued state and the observed value of it. We keep the ability to have the latest reconfig operation take precedence, but we guarantee that once "dequeued" the argument (new_fsg) will not be clobbered by any new event. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-08-12usb: gadget: composite: Clear "suspended" on reset/disconnectBenjamin Herrenschmidt1-0/+1
In some cases, one can get out of suspend with a reset or a disconnect followed by a reconnect. Previously we would leave a stale suspended flag set. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-08-12usb: gadget: udc: renesas_usb3: Fix sysfs interface of "role"Yoshihiro Shimoda1-2/+3
Since the role_store() uses strncmp(), it's possible to refer out-of-memory if the sysfs data size is smaller than strlen("host"). This patch fixes it by using sysfs_streq() instead of strncmp(). Fixes: cc995c9ec118 ("usb: gadget: udc: renesas_usb3: add support for usb role swap") Cc: <stable@vger.kernel.org> # v4.12+ Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-08-11Linux 5.3-rc4Linus Torvalds1-1/+1
2019-08-10Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clangJoe Perches2-2/+2
A compilation -Wimplicit-fallthrough warning was enabled by commit a035d552a93b ("Makefile: Globally enable fall-through warning") Even though clang 10.0.0 does not currently support this warning without a patch, clang currently does not support a value for this option. Link: https://bugs.llvm.org/show_bug.cgi?id=39382 The gcc default for this warning is 3 so removing the =3 has no effect for gcc and enables the warning for patched versions of clang. Also remove the =3 from an existing use in a parisc Makefile: arch/parisc/math-emu/Makefile Signed-off-by: Joe Perches <joe@perches.com> Reviewed-and-tested-by: Nathan Chancellor <natechancellor@gmail.com> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-08-09ARM: ep93xx: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
Mark switch cases where we are expecting to fall through. Fix the following warnings (Building: arm-ep93xx_defconfig arm): arch/arm/mach-ep93xx/crunch.c: In function 'crunch_do': arch/arm/mach-ep93xx/crunch.c:46:3: warning: this statement may fall through [-Wimplicit-fallthrough=] memset(crunch_state, 0, sizeof(*crunch_state)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/mach-ep93xx/crunch.c:53:2: note: here case THREAD_NOTIFY_EXIT: ^~~~ Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09scsi: fas216: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+8
Mark switch cases where we are expecting to fall through. Fix the following warnings (Building: rpc_defconfig arm): drivers/scsi/arm/fas216.c: In function ‘fas216_disconnect_intr’: drivers/scsi/arm/fas216.c:913:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (fas216_get_last_msg(info, info->scsi.msgin_fifo) == ABORT) { ^ drivers/scsi/arm/fas216.c:919:2: note: here default: /* huh? */ ^~~~~~~ drivers/scsi/arm/fas216.c: In function ‘fas216_kick’: drivers/scsi/arm/fas216.c:1959:3: warning: this statement may fall through [-Wimplicit-fallthrough=] fas216_allocate_tag(info, SCpnt); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/arm/fas216.c:1960:2: note: here case TYPE_OTHER: ^~~~ drivers/scsi/arm/fas216.c: In function ‘fas216_busservice_intr’: drivers/scsi/arm/fas216.c:1413:3: warning: this statement may fall through [-Wimplicit-fallthrough=] fas216_stoptransfer(info); ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/arm/fas216.c:1414:2: note: here case STATE(STAT_STATUS, PHASE_SELSTEPS):/* Sel w/ steps -> Status */ ^~~~ drivers/scsi/arm/fas216.c:1424:3: warning: this statement may fall through [-Wimplicit-fallthrough=] fas216_stoptransfer(info); ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/arm/fas216.c:1425:2: note: here case STATE(STAT_MESGIN, PHASE_COMMAND): /* Command -> Message In */ ^~~~ drivers/scsi/arm/fas216.c: In function ‘fas216_funcdone_intr’: drivers/scsi/arm/fas216.c:1573:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if ((stat & STAT_BUSMASK) == STAT_MESGIN) { ^ drivers/scsi/arm/fas216.c:1579:2: note: here default: ^~~~~~~ drivers/scsi/arm/fas216.c: In function ‘fas216_handlesync’: drivers/scsi/arm/fas216.c:605:20: warning: this statement may fall through [-Wimplicit-fallthrough=] info->scsi.phase = PHASE_MSGOUT_EXPECT; ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ drivers/scsi/arm/fas216.c:607:2: note: here case async: ^~~~ Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09pcmcia: db1xxx_ss: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+4
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings (Building: db1xxx_defconfig mips): drivers/pcmcia/db1xxx_ss.c:257:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/pcmcia/db1xxx_ss.c:269:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09video: fbdev: omapfb_main: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+8
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: omap1_defconfig arm): drivers/watchdog/wdt285.c:170:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/watchdog/ar7_wdt.c:237:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:449:23: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1549:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1547:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1545:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1543:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1540:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1538:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1535:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09watchdog: riowd: Mark expected switch fall-throughGustavo A. R. Silva1-1/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings (Building: sparc64): drivers/watchdog/riowd.c: In function ‘riowd_ioctl’: drivers/watchdog/riowd.c:136:3: warning: this statement may fall through [-Wimplicit-fallthrough=] riowd_writereg(p, riowd_timeout, WDTO_INDEX); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/watchdog/riowd.c:139:2: note: here case WDIOC_GETTIMEOUT: ^~~~ Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09s390/net: Mark expected switch fall-throughsGustavo A. R. Silva3-1/+5
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings (Building: s390): drivers/s390/net/ctcm_fsms.c: In function ‘ctcmpc_chx_attnbusy’: drivers/s390/net/ctcm_fsms.c:1703:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (grp->changed_side == 1) { ^ drivers/s390/net/ctcm_fsms.c:1707:2: note: here case MPCG_STATE_XID0IOWAIX: ^~~~ drivers/s390/net/ctcm_mpc.c: In function ‘ctc_mpc_alloc_channel’: drivers/s390/net/ctcm_mpc.c:358:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (callback) ^ drivers/s390/net/ctcm_mpc.c:360:2: note: here case MPCG_STATE_XID0IOWAIT: ^~~~ drivers/s390/net/ctcm_mpc.c: In function ‘mpc_action_timeout’: drivers/s390/net/ctcm_mpc.c:1469:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if ((fsm_getstate(rch->fsm) == CH_XID0_PENDING) && ^ drivers/s390/net/ctcm_mpc.c:1472:2: note: here default: ^~~~~~~ drivers/s390/net/ctcm_mpc.c: In function ‘mpc_send_qllc_discontact’: drivers/s390/net/ctcm_mpc.c:2087:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (grp->estconnfunc) { ^ drivers/s390/net/ctcm_mpc.c:2092:2: note: here case MPCG_STATE_FLOWC: ^~~~ drivers/s390/net/qeth_l2_main.c: In function ‘qeth_l2_process_inbound_buffer’: drivers/s390/net/qeth_l2_main.c:328:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (IS_OSN(card)) { ^ drivers/s390/net/qeth_l2_main.c:337:3: note: here default: ^~~~~~~ Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09crypto: ux500/crypt: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+6
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: arm): drivers/crypto/ux500/cryp/cryp.c: In function ‘cryp_save_device_context’: drivers/crypto/ux500/cryp/cryp.c:316:16: warning: this statement may fall through [-Wimplicit-fallthrough=] ctx->key_4_r = readl_relaxed(&src_reg->key_4_r); drivers/crypto/ux500/cryp/cryp.c:318:2: note: here case CRYP_KEY_SIZE_192: ^~~~ drivers/crypto/ux500/cryp/cryp.c:320:16: warning: this statement may fall through [-Wimplicit-fallthrough=] ctx->key_3_r = readl_relaxed(&src_reg->key_3_r); drivers/crypto/ux500/cryp/cryp.c:322:2: note: here case CRYP_KEY_SIZE_128: ^~~~ drivers/crypto/ux500/cryp/cryp.c:324:16: warning: this statement may fall through [-Wimplicit-fallthrough=] ctx->key_2_r = readl_relaxed(&src_reg->key_2_r); drivers/crypto/ux500/cryp/cryp.c:326:2: note: here default: ^~~~~~~ In file included from ./include/linux/io.h:13:0, from drivers/crypto/ux500/cryp/cryp_p.h:14, from drivers/crypto/ux500/cryp/cryp.c:15: drivers/crypto/ux500/cryp/cryp.c: In function ‘cryp_restore_device_context’: ./arch/arm/include/asm/io.h:92:22: warning: this statement may fall through [-Wimplicit-fallthrough=] #define __raw_writel __raw_writel ^ ./arch/arm/include/asm/io.h:299:29: note: in expansion of macro ‘__raw_writel’ #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c) ^~~~~~~~~~~~ drivers/crypto/ux500/cryp/cryp.c:363:3: note: in expansion of macro ‘writel_relaxed’ writel_relaxed(ctx->key_4_r, &reg->key_4_r); ^~~~~~~~~~~~~~ drivers/crypto/ux500/cryp/cryp.c:365:2: note: here case CRYP_KEY_SIZE_192: ^~~~ In file included from ./include/linux/io.h:13:0, from drivers/crypto/ux500/cryp/cryp_p.h:14, from drivers/crypto/ux500/cryp/cryp.c:15: ./arch/arm/include/asm/io.h:92:22: warning: this statement may fall through [-Wimplicit-fallthrough=] #define __raw_writel __raw_writel ^ ./arch/arm/include/asm/io.h:299:29: note: in expansion of macro ‘__raw_writel’ #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c) ^~~~~~~~~~~~ drivers/crypto/ux500/cryp/cryp.c:367:3: note: in expansion of macro ‘writel_relaxed’ writel_relaxed(ctx->key_3_r, &reg->key_3_r); ^~~~~~~~~~~~~~ drivers/crypto/ux500/cryp/cryp.c:369:2: note: here case CRYP_KEY_SIZE_128: ^~~~ In file included from ./include/linux/io.h:13:0, from drivers/crypto/ux500/cryp/cryp_p.h:14, from drivers/crypto/ux500/cryp/cryp.c:15: ./arch/arm/include/asm/io.h:92:22: warning: this statement may fall through [-Wimplicit-fallthrough=] #define __raw_writel __raw_writel ^ ./arch/arm/include/asm/io.h:299:29: note: in expansion of macro ‘__raw_writel’ #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c) ^~~~~~~~~~~~ drivers/crypto/ux500/cryp/cryp.c:371:3: note: in expansion of macro ‘writel_relaxed’ writel_relaxed(ctx->key_2_r, &reg->key_2_r); ^~~~~~~~~~~~~~ drivers/crypto/ux500/cryp/cryp.c:373:2: note: here default: ^~~~~~~ Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09watchdog: wdt977: Mark expected switch fall-throughGustavo A. R. Silva1-1/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: arm): drivers/watchdog/wdt977.c: In function ‘wdt977_ioctl’: LD [M] drivers/media/platform/vicodec/vicodec.o drivers/watchdog/wdt977.c:400:3: warning: this statement may fall through [-Wimplicit-fallthrough=] wdt977_keepalive(); ^~~~~~~~~~~~~~~~~~ drivers/watchdog/wdt977.c:403:2: note: here case WDIOC_GETTIMEOUT: ^~~~ Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09watchdog: scx200_wdt: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: i386): drivers/watchdog/scx200_wdt.c: In function ‘scx200_wdt_ioctl’: drivers/watchdog/scx200_wdt.c:188:3: warning: this statement may fall through [-Wimplicit-fallthrough=] scx200_wdt_ping(); ^~~~~~~~~~~~~~~~~ drivers/watchdog/scx200_wdt.c:189:2: note: here case WDIOC_GETTIMEOUT: ^~~~ Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09watchdog: Mark expected switch fall-throughsGustavo A. R. Silva4-2/+4
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/watchdog/ar7_wdt.c: warning: this statement may fall through [-Wimplicit-fallthrough=]: => 237:3 drivers/watchdog/pcwd.c: warning: this statement may fall through [-Wimplicit-fallthrough=]: => 653:3 drivers/watchdog/sb_wdog.c: warning: this statement may fall through [-Wimplicit-fallthrough=]: => 204:3 drivers/watchdog/wdt.c: warning: this statement may fall through [-Wimplicit-fallthrough=]: => 391:3 Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09ARM: signal: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following warning: arch/arm/kernel/signal.c: In function 'do_signal': arch/arm/kernel/signal.c:598:12: warning: this statement may fall through [-Wimplicit-fallthrough=] restart -= 2; ~~~~~~~~^~~~ arch/arm/kernel/signal.c:599:3: note: here case -ERESTARTNOHAND: ^~~~ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09mfd: omap-usb-host: Mark expected switch fall-throughsGustavo A. R. Silva1-2/+2
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/mfd/omap-usb-host.c: In function 'usbhs_runtime_resume': drivers/mfd/omap-usb-host.c:303:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!IS_ERR(omap->hsic480m_clk[i])) { ^ drivers/mfd/omap-usb-host.c:313:3: note: here case OMAP_EHCI_PORT_MODE_TLL: ^~~~ drivers/mfd/omap-usb-host.c: In function 'usbhs_runtime_suspend': drivers/mfd/omap-usb-host.c:345:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!IS_ERR(omap->hsic480m_clk[i])) ^ drivers/mfd/omap-usb-host.c:349:3: note: here case OMAP_EHCI_PORT_MODE_TLL: ^~~~ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09mfd: db8500-prcmu: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+2
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/mfd/db8500-prcmu.c: In function 'dsiclk_rate': drivers/mfd/db8500-prcmu.c:1592:7: warning: this statement may fall through [-Wimplicit-fallthrough=] div *= 2; ~~~~^~~~ drivers/mfd/db8500-prcmu.c:1593:2: note: here case PRCM_DSI_PLLOUT_SEL_PHI_2: ^~~~ drivers/mfd/db8500-prcmu.c:1594:7: warning: this statement may fall through [-Wimplicit-fallthrough=] div *= 2; ~~~~^~~~ drivers/mfd/db8500-prcmu.c:1595:2: note: here case PRCM_DSI_PLLOUT_SEL_PHI: ^~~~ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09ARM: OMAP: dma: Mark expected switch fall-throughsGustavo A. R. Silva1-9/+5
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings: arch/arm/plat-omap/dma.c: In function 'omap_set_dma_src_burst_mode': arch/arm/plat-omap/dma.c:384:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (dma_omap2plus()) { ^ arch/arm/plat-omap/dma.c:393:2: note: here case OMAP_DMA_DATA_BURST_16: ^~~~ arch/arm/plat-omap/dma.c:394:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (dma_omap2plus()) { ^ arch/arm/plat-omap/dma.c:402:2: note: here default: ^~~~~~~ arch/arm/plat-omap/dma.c: In function 'omap_set_dma_dest_burst_mode': arch/arm/plat-omap/dma.c:473:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (dma_omap2plus()) { ^ arch/arm/plat-omap/dma.c:481:2: note: here default: ^~~~~~~ Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09ARM: alignment: Mark expected switch fall-throughsGustavo A. R. Silva1-1/+3
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings: arch/arm/mm/alignment.c: In function 'thumb2arm': arch/arm/mm/alignment.c:688:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if ((tinstr & (3 << 9)) == 0x0400) { ^ arch/arm/mm/alignment.c:700:2: note: here default: ^~~~~~~ arch/arm/mm/alignment.c: In function 'do_alignment_t32_to_handler': arch/arm/mm/alignment.c:753:15: warning: this statement may fall through [-Wimplicit-fallthrough=] poffset->un = (tinst2 & 0xff) << 2; ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ arch/arm/mm/alignment.c:754:2: note: here case 0xe940: ^~~~ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09ARM: tegra: Mark expected switch fall-throughGustavo A. R. Silva1-1/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following warning: arch/arm/mach-tegra/reset.c: In function 'tegra_cpu_reset_handler_enable': arch/arm/mach-tegra/reset.c:72:3: warning: this statement may fall through [-Wimplicit-fallthrough=] tegra_cpu_reset_handler_set(reset_address); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/mach-tegra/reset.c:74:2: note: here case 0: ^~~~ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09ARM/hw_breakpoint: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+5
Mark switch cases where we are expecting to fall through. This patch fixes the following warnings: arch/arm/kernel/hw_breakpoint.c: In function 'hw_breakpoint_arch_parse': arch/arm/kernel/hw_breakpoint.c:609:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2) ^ arch/arm/kernel/hw_breakpoint.c:611:2: note: here case 3: ^~~~ arch/arm/kernel/hw_breakpoint.c:613:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1) ^ arch/arm/kernel/hw_breakpoint.c:615:2: note: here default: ^~~~~~~ arch/arm/kernel/hw_breakpoint.c: In function 'arch_build_bp_info': arch/arm/kernel/hw_breakpoint.c:544:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if ((hw->ctrl.type != ARM_BREAKPOINT_EXECUTE) ^ arch/arm/kernel/hw_breakpoint.c:547:2: note: here default: ^~~~~~~ In file included from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/preempt.h:11, from include/linux/hardirq.h:5, from arch/arm/kernel/hw_breakpoint.c:16: arch/arm/kernel/hw_breakpoint.c: In function 'hw_breakpoint_pending': include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ include/asm-generic/bug.h:136:2: note: in expansion of macro 'unlikely' unlikely(__ret_warn_on); \ ^~~~~~~~ arch/arm/kernel/hw_breakpoint.c:863:3: note: in expansion of macro 'WARN' WARN(1, "Asynchronous watchpoint exception taken. Debugging results may be unreliable\n"); ^~~~ arch/arm/kernel/hw_breakpoint.c:864:2: note: here case ARM_ENTRY_SYNC_WATCHPOINT: ^~~~ arch/arm/kernel/hw_breakpoint.c: In function 'core_has_os_save_restore': arch/arm/kernel/hw_breakpoint.c:910:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (oslsr & ARM_OSLSR_OSLM0) ^ arch/arm/kernel/hw_breakpoint.c:912:2: note: here default: ^~~~~~~ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-08-09mm/memremap: Fix reuse of pgmap instances with internal referencesDan Williams1-0/+6
Currently, attempts to shutdown and re-enable a device-dax instance trigger: Missing reference count teardown definition WARNING: CPU: 37 PID: 1608 at mm/memremap.c:211 devm_memremap_pages+0x234/0x850 [..] RIP: 0010:devm_memremap_pages+0x234/0x850 [..] Call Trace: dev_dax_probe+0x66/0x190 [device_dax] really_probe+0xef/0x390 driver_probe_device+0xb4/0x100 device_driver_attach+0x4f/0x60 Given that the setup path initializes pgmap->ref, arrange for it to be also torn down so devm_memremap_pages() is ready to be called again and not be mistaken for the 3rd-party per-cpu-ref case. Fixes: 24917f6b1041 ("memremap: provide an optional internal refcount in struct dev_pagemap") Reported-by: Fan Du <fan.du@intel.com> Tested-by: Vishal Verma <vishal.l.verma@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/156530042781.2068700.8733813683117819799.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2019-08-09drm/i915: Remove redundant user_access_end() from __copy_from_user() error pathJosh Poimboeuf1-11/+9
Objtool reports: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x36: redundant UACCESS disable __copy_from_user() already does both STAC and CLAC, so the user_access_end() in its error path adds an extra unnecessary CLAC. Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault exception case") Reported-by: Thomas Gleixner <tglx@linutronix.de> Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://github.com/ClangBuiltLinux/linux/issues/617 Link: https://lkml.kernel.org/r/51a4155c5bc2ca847a9cbe85c1c11918bb193141.1564086017.git.jpoimboe@redhat.com
2019-08-10kbuild: show hint if subdir-y/m is used to visit module MakefileMasahiro Yamada2-1/+8
Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), a module is no longer built in the following pattern: [Makefile] subdir-y := some-module [some-module/Makefile] obj-m := some-module.o You cannot write Makefile this way in upstream because modules.order is not correctly generated. subdir-y is used to descend to a sub-directory that builds tools, device trees, etc. For external modules, the modules order does not matter. So, the Makefile above was known to work. I believe the Makefile should be re-written as follows: [Makefile] obj-m := some-module/ [some-module/Makefile] obj-m := some-module.o However, people will have no idea if their Makefile suddenly stops working. In fact, I received questions from multiple people. Show a warning for a while if obj-m is specified in a Makefile visited by subdir-y or subdir-m. I touched the %/ rule to avoid false-positive warnings for the single target. Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Tom Stonecypher <thomas.edwardx.stonecypher@intel.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
2019-08-10kbuild: generate modules.order only in directories visited by obj-y/mMasahiro Yamada1-1/+2
The modules.order files in directories visited by the chain of obj-y or obj-m are merged to the upper-level ones, and become parts of the top-level modules.order. On the other hand, there is no need to generate modules.order in directories visited by subdir-y or subdir-m since they would become orphan anyway. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-10kbuild: fix false-positive need-builtin calculationMasahiro Yamada1-1/+2
The current implementation of need-builtin is false-positive, for example, in the following Makefile: obj-m := foo/ obj-y := foo/bar/ ..., where foo/built-in.a is not required. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-10kbuild: revive single target %.koMasahiro Yamada2-4/+13
I removed the single target %.ko in commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") because the modpost stage does not work reliably. For instance, the module dependency, modversion, etc. do not work if we lack symbol information from the other modules. Yet, some people still want to build only one module in their interest, and it may be still useful if it is used within those limitations. Fixes: ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") Reported-by: Don Brace <don.brace@microsemi.com> Reported-by: Arend Van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-09gfs2: gfs2_walk_metadata fixAndreas Gruenbacher1-63/+101
It turns out that the current version of gfs2_metadata_walker suffers from multiple problems that can cause gfs2_hole_size to report an incorrect size. This will confuse fiemap as well as lseek with the SEEK_DATA flag. Fix that by changing gfs2_hole_walker to compute the metapath to the first data block after the hole (if any), and compute the hole size based on that. Fixes xfstest generic/490. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Bob Peterson <rpeterso@redhat.com> Cc: stable@vger.kernel.org # v4.18+