summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-03-28usb: cdc-acm: fix race during wakeup blocking TX trafficRomain Izard
When the kernel is compiled with preemption enabled, the URB completion handler can run in parallel with the work responsible for waking up the tty layer. If the URB handler sets the EVENT_TTY_WAKEUP bit during the call to tty_port_tty_wakeup() to signal that there is room for additional input, it will be cleared at the end of this call. As a result, TX traffic on the upper layer will be blocked. This can be seen with a kernel configured with CONFIG_PREEMPT, and a fast modem connected with PPP running over a USB CDC-ACM port. Use test_and_clear_bit() instead, which ensures that each wakeup requested by the URB completion code will trigger a call to tty_port_tty_wakeup(). Fixes: 1aba579f3cf5 cdc-acm: handle read pipe errors Signed-off-by: Romain Izard <romain.izard.pro@gmail.com> Cc: stable <stable@vger.kernel.org> Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-27Merge branch 'fix-btf_dedup'Alexei Starovoitov
Andrii Nakryiko says: ==================== This patch set fixes bug in btf_dedup_is_equiv() check mishandling equivalence comparison between VOID kind in candidate type graph versus anonymous non-VOID kind in canonical type graph. Patch #1 fixes bug, by comparing candidate and canonical kinds for equality, before proceeding to kind-specific checks. Patch #2 adds a test case testing this specific scenario. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-03-27selftests/bpf: add btf_dedup test for VOID equivalence checkAndrii Nakryiko
This patch adds specific test exposing bug in btf_dedup_is_equiv() when comparing candidate VOID type to a non-VOID canonical type. It's important for canonical type to be anonymous, otherwise name equality check will do the right thing and will exit early. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-03-27libbpf: fix btf_dedup equivalence check handling of different kindsAndrii Nakryiko
btf_dedup_is_equiv() used to compare btf_type->info fields, before doing kind-specific equivalence check. This comparsion implicitly verified that candidate and canonical types are of the same kind. With enum fwd resolution logic this check couldn't be done generically anymore, as for enums info contains vlen, which differs between enum fwd and fully-defined enum, so this check was subsumed by kind-specific equivalence checks. This change caused btf_dedup_is_equiv() to let through VOID vs other types check to reach switch, which was never meant to be handing VOID kind, as VOID kind is always pre-resolved to itself and is only equivalent to itself, which is checked early in btf_dedup_is_equiv(). This change adds back BTF kind equality check in place of more generic btf_type->info check, still defering further kind-specific checks to a per-kind switch. Fixes: 9768095ba97c ("btf: resolve enum fwds in btf_dedup") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-03-27x86/realmode: Don't leak the trampoline kernel addressMatteo Croce
Since commit ad67b74d2469 ("printk: hash addresses printed with %p") at boot "____ptrval____" is printed instead of the trampoline addresses: Base memory trampoline at [(____ptrval____)] 99000 size 24576 Remove the print as we don't want to leak kernel addresses and this statement is not needed anymore. Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p") Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190326203046.20787-1-mcroce@redhat.com
2019-03-27i2c: wmt: make bindings file name match the driverWolfram Sang
If we use the "i2c-" prefix for the binding documentation file name, then it should match the file name of the driver, if possible. It is possible for this driver, so rename it. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-03-27i2c: sun6i-p2wi: make bindings file name match the driverWolfram Sang
If we use the "i2c-" prefix for the binding documentation file name, then it should match the file name of the driver, if possible. It is possible for this driver, so rename it. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-03-27i2c: stu300: make bindings file name match the driverWolfram Sang
If we use the "i2c-" prefix for the binding documentation file name, then it should match the file name of the driver, if possible. It is possible for this driver, so rename it. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-03-27i2c: mt65xx: make bindings file name match the driverWolfram Sang
If we use the "i2c-" prefix for the binding documentation file name, then it should match the file name of the driver, if possible. It is possible for this driver, so rename it. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-03-27i2c: iop3xx: make bindings file name match the driverWolfram Sang
If we use the "i2c-" prefix for the binding documentation file name, then it should match the file name of the driver, if possible. It is possible for this driver, so rename it. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-03-27HID: quirks: Fix keyboard + touchpad on Lenovo Miix 630Jeffrey Hugo
Similar to commit edfc3722cfef ("HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working"), the Lenovo Miix 630 has a combo keyboard/touchpad device with vid:pid of 04F3:0400, which is shared with Elan touchpads. The combo on the Miix 630 has an ACPI id of QTEC0001, which is not claimed by the elan_i2c driver, so key on that similar to what was done for the Toshiba Click Mini. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-03-27x86/boot: Fix incorrect ifdeffery scopeBaoquan He
The declarations related to immovable memory handling are out of the BOOT_COMPRESSED_MISC_H #ifdef scope, wrap them inside. Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Chao Fan <fanc.fnst@cn.fujitsu.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190304055546.18566-1-bhe@redhat.com
2019-03-27drm/omap: hdmi4_cec: Fix CEC clock handling for PMTony Lindgren
If CONFIG_OMAP4_DSS_HDMI_CEC is enabled in .config, deeper SoC idle states are blocked because the CEC clock gets always enabled on init. Let's fix the issue by moving the CEC clock handling to happen later in hdmi_cec_adap_enable() as suggested by Hans Verkuil <hverkuil@xs4all.nl>. This way the CEC clock gets only enabled when needed. This can be tested by doing cec-ctl --playback to enable the CEC, and doing cec-ctl --clear to disable it. Let's also fix the typo for "divider" in the comments while at it. Fixes: 8d7f934df8d8 ("omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support") Suggested-by: Hans Verkuil <hverkuil@xs4all.nl> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326151438.32414-1-tony@atomide.com
2019-03-27drm/omap: fix typoMatteo Croce
Fix spelling mistake: "lenght" -> "length" Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107130934.9997-1-mcroce@redhat.com
2019-03-27gpio: mockup: fix debugfs readBartosz Golaszewski
The debugfs read callback must advance ppos or users using read() on the file descriptor will never get the EOL. This wasn't spotted before as I was using busybox cat for testing which uses sendfile() internally and only noticed it now when switched to cat from coreutils. Fixes: 2a9e27408e12 ("gpio: mockup: rework debugfs interface") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-03-27Revert "gpio: use new gpio_set_config() helper in more places"Andrew Jeffery
gpio-aspeed implements support for PIN_CONFIG_INPUT_DEBOUNCE. As of v5.1-rc1 we're seeing the following when booting a Romulus BMC kernel: > [ 21.373137] ------------[ cut here ]------------ > [ 21.374545] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpio-aspeed.c:834 unregister_allocated_timer+0x38/0x94 > [ 21.376181] No timer allocated to offset 74 > [ 21.377672] CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-rc1-dirty #6 > [ 21.378800] Hardware name: Generic DT based system > [ 21.379965] Backtrace: > [ 21.381024] [<80107d44>] (dump_backtrace) from [<80107f78>] (show_stack+0x20/0x24) > [ 21.382713] r7:8038b720 r6:00000009 r5:00000000 r4:87897c64 > [ 21.383815] [<80107f58>] (show_stack) from [<80656398>] (dump_stack+0x20/0x28) > [ 21.385042] [<80656378>] (dump_stack) from [<80115f1c>] (__warn.part.3+0xb4/0xdc) > [ 21.386253] [<80115e68>] (__warn.part.3) from [<80115fb0>] (warn_slowpath_fmt+0x6c/0x90) > [ 21.387471] r6:00000342 r5:807f8758 r4:80a07008 > [ 21.388278] [<80115f48>] (warn_slowpath_fmt) from [<8038b720>] (unregister_allocated_timer+0x38/0x94) > [ 21.389809] r3:0000004a r2:807f8774 > [ 21.390526] r7:00000000 r6:0000000a r5:60000153 r4:0000004a > [ 21.391601] [<8038b6e8>] (unregister_allocated_timer) from [<8038baac>] (aspeed_gpio_set_config+0x330/0x48c) > [ 21.393248] [<8038b77c>] (aspeed_gpio_set_config) from [<803840b0>] (gpiod_set_debounce+0xe8/0x114) > [ 21.394745] r10:82ee2248 r9:00000000 r8:87b63a00 r7:00001388 r6:87947320 r5:80729310 > [ 21.396030] r4:879f64a0 > [ 21.396499] [<80383fc8>] (gpiod_set_debounce) from [<804b4350>] (gpio_keys_probe+0x69c/0x8e0) > [ 21.397715] r7:845d94b8 r6:00000001 r5:00000000 r4:87b63a1c > [ 21.398618] [<804b3cb4>] (gpio_keys_probe) from [<8040eeec>] (platform_dev_probe+0x44/0x80) > [ 21.399834] r10:00000003 r9:80a3a8b0 r8:00000000 r7:00000000 r6:80a7f9dc r5:80a3a8b0 > [ 21.401163] r4:8796bc10 > [ 21.401634] [<8040eea8>] (platform_drv_probe) from [<8040d0d4>] (really_probe+0x208/0x3dc) > [ 21.402786] r5:80a7f8d0 r4:8796bc10 > [ 21.403547] [<8040cecc>] (really_probe) from [<8040d7a4>] (driver_probe_device+0x130/0x170) > [ 21.404744] r10:0000007b r9:8093683c r8:00000000 r7:80a07008 r6:80a3a8b0 r5:8796bc10 > [ 21.405854] r4:80a3a8b0 > [ 21.406324] [<8040d674>] (driver_probe_device) from [<8040da8c>] (device_driver_attach+0x68/0x70) > [ 21.407568] r9:8093683c r8:00000000 r7:80a07008 r6:80a3a8b0 r5:00000000 r4:8796bc10 > [ 21.408877] [<8040da24>] (device_driver_attach) from [<8040db14>] (__driver_attach+0x80/0x150) > [ 21.410327] r7:80a07008 r6:8796bc10 r5:00000001 r4:80a3a8b0 > [ 21.411294] [<8040da94>] (__driver_attach) from [<8040b20c>] (bus_for_each_dev+0x80/0xc4) > [ 21.412641] r7:80a07008 r6:8040da94 r5:80a3a8b0 r4:87966f30 > [ 21.413580] [<8040b18c>] (bus_for_each_dev) from [<8040dc0c>] (driver_attach+0x28/0x30) > [ 21.414943] r7:00000000 r6:87b411e0 r5:80a33fc8 r4:80a3a8b0 > [ 21.415927] [<8040dbe4>] (driver_attach) from [<8040bbf0>] (bus_add_driver+0x14c/0x200) > [ 21.417289] [<8040baa4>] (bus_add_driver) from [<8040e2b4>] (driver_register+0x84/0x118) > [ 21.418652] r7:80a60ae0 r6:809226b8 r5:80a07008 r4:80a3a8b0 > [ 21.419652] [<8040e230>] (driver_register) from [<8040fc28>] (__platform_driver_register+0x3c/0x50) > [ 21.421193] r5:80a07008 r4:809525f8 > [ 21.421990] [<8040fbec>] (__platform_driver_register) from [<809226d8>] (gpio_keys_init+0x20/0x28) > [ 21.423447] [<809226b8>] (gpio_keys_init) from [<8090128c>] (do_one_initcall+0x80/0x180) > [ 21.424886] [<8090120c>] (do_one_initcall) from [<80901538>] (kernel_init_freeable+0x1ac/0x26c) > [ 21.426354] r8:80a60ae0 r7:80a60ae0 r6:8093685c r5:00000008 r4:809525f8 > [ 21.427579] [<8090138c>] (kernel_init_freeable) from [<8066d9a0>] (kernel_init+0x18/0x11c) > [ 21.428819] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8066d988 > [ 21.429947] r4:00000000 > [ 21.430415] [<8066d988>] (kernel_init) from [<801010e8>] (ret_from_fork+0x14/0x2c) > [ 21.431666] Exception stack(0x87897fb0 to 0x87897ff8) > [ 21.432877] 7fa0: 00000000 00000000 00000000 00000000 > [ 21.434446] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 21.436052] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 > [ 21.437308] r5:8066d988 r4:00000000 > [ 21.438102] ---[ end trace d7d7ac3a80567d0e ]--- We only hit unregister_allocated_timer() if the argument to aspeed_gpio_set_config() is 0, but we can't be calling through gpiod_set_debounce() from gpio_keys_probe() unless the gpio-keys button has a non-zero debounce interval. Commit 6581eaf0e890 ("gpio: use new gpio_set_config() helper in more places") spreads the use of gpio_set_config() to the debounce and transitory state configuration paths. The implementation of gpio_set_config() is: > static int gpio_set_config(struct gpio_chip *gc, unsigned offset, > enum pin_config_param mode) > { > unsigned long config = { PIN_CONF_PACKED(mode, 0) }; > > return gc->set_config ? gc->set_config(gc, offset, config) : -ENOTSUPP; > } Here it packs its own config value with a fixed argument of 0; this is incorrect behaviour for implementing the debounce and transitory functions, and the debounce and transitory gpio_set_config() call-sites now have an undetected type mismatch as they both already pack their own config parameter (i.e. what gets passed is not an `enum pin_config_param`). Indeed this can be seen in the small diff for 6581eaf0e890: > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index de595fa31a1a..1f239aac43df 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -2725,7 +2725,7 @@ int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce) > } > > config = pinconf_to_config_packed(PIN_CONFIG_INPUT_DEBOUNCE, debounce); > - return chip->set_config(chip, gpio_chip_hwgpio(desc), config); > + return gpio_set_config(chip, gpio_chip_hwgpio(desc), config); > } > EXPORT_SYMBOL_GPL(gpiod_set_debounce); > > @@ -2762,7 +2762,7 @@ int gpiod_set_transitory(struct gpio_desc *desc, bool transitory) > packed = pinconf_to_config_packed(PIN_CONFIG_PERSIST_STATE, > !transitory); > gpio = gpio_chip_hwgpio(desc); > - rc = chip->set_config(chip, gpio, packed); > + rc = gpio_set_config(chip, gpio, packed); > if (rc == -ENOTSUPP) { > dev_dbg(&desc->gdev->dev, "Persistence not supported for GPIO %d\n", > gpio); Revert commit 6581eaf0e890 ("gpio: use new gpio_set_config() helper in more places") to restore correct behaviour for gpiod_set_debounce() and gpiod_set_transitory(). Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-03-27drm/i915/selftests: Fix an IS_ERR() vs NULL checkDan Carpenter
The live_context() function returns error pointers. It never returns NULL. Fixes: 9c1477e83e62 ("drm/i915/selftests: Exercise adding requests to a full GGTT") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190326050843.GA20038@kadam (cherry picked from commit 602cbe8efc523ba56e1f41e8f74c7aa835672593) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-03-26RISC-V: Always compile mm/init.c with cmodel=medany and notraceAnup Patel
The Linux RISC-V 32bit kernel is broken after we moved setup_vm() from kernel/setup.c to mm/init.c because Linux RISC-V 32bit kernel by default uses cmodel=medlow which results in a non-position-independent setup_vm(). This patch fixes Linux RISC-V 32bit kernel booting by: 1. Forcing cmodel=medany for mm/init.c 2. Moving remaing MM-related stuff va_pa_offset, pfn_base and empty_zero_page from kernel/setup.c to mm/init.c Further, the setup_vm() cannot handle GCC instrumentation for FTRACE so we disable it for mm/init.c by not using "-pg" compiler flag. Fixes: 6f1e9e946f0b ("RISC-V: Move setup_vm() to mm/init.c") Suggested-by: Christoph Hellwig <hch@lst.de> Suggested-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-26riscv: fix accessing 8-byte variable from RV32Alan Kao
A memory save operation to 8-byte variable in RV32 is divided into two sw instructions in the put_user macro. The current fixup returns execution flow to the second sw instead of the one after it. This patch fixes this fixup code according to the load access part. Signed-off-by: Alan Kao<alankao@andestech.com> Cc: Greentime Hu <greentime@andestech.com> Cc: Vincent Chen <deanbo422@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-26HID: input: add mapping for "Toggle Display" keyDmitry Torokhov
According to HUT 1.12 usage 0xb5 from the generic desktop page is reserved for switching between external and internal display, so let's add the mapping. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26HID: input: add mapping for "Full Screen" keyDmitry Torokhov
According to HUT 1.12 usage 0x232 from the consumer page is reserved for switching application between full screen and windowed mode, so let's add the mapping. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26HID: input: add mapping for keyboard Brightness Up/Down/Toggle keysDmitry Torokhov
According to HUTRR73 usages 0x79, 0x7a and 0x7c from the consumer page correspond to Brightness Up/Down/Toggle keys, so let's add the mappings. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26HID: input: add mapping for Expose/Overview keyDmitry Torokhov
According to HUTRR77 usage 0x29f from the consumer page is reserved for the Desktop application to present all running user’s application windows. Linux defines KEY_SCALE to request Compiz Scale (Expose) mode, so let's add the mapping. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26HID: input: fix mapping of aspect ratio keyDmitry Torokhov
According to HUTRR37 usage 0x6d from the consumer usage page corresponds to action that selects the next available supported aspect ratio option on a device which outputs or displays video. However KEY_ZOOM means activate "Full Screen" mode, KEY_ASPECT_RATIO should be used instead. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26[media] doc-rst: switch to new names for Full Screen/Aspect keysDmitry Torokhov
We defined better names for keys to activate full screen mode or change aspect ratio (while keeping the existing keycodes to avoid breaking userspace), so let's use them in the document. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26Input: document meanings of KEY_SCREEN and KEY_ZOOMDmitry Torokhov
It is hard to say what KEY_SCREEN and KEY_ZOOM mean, but historically DVB folks have used them to indicate switch to full screen mode. Later, they converged on using KEY_ZOOM to switch into full screen mode and KEY)SCREEN to control aspect ratio (see Documentation/media/uapi/rc/rc-tables.rst). Let's commit to these uses, and define: - KEY_FULL_SCREEN (and make KEY_ZOOM its alias) - KEY_ASPECT_RATIO (and make KEY_SCREEN its alias) Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-26Input: elan_i2c - add hardware ID for multiple Lenovo laptopsKT Liao
There are many Lenovo laptops which need elan_i2c support, this patch adds relevant IDs to the Elan driver so that touchpads are recognized. Signed-off-by: KT Liao <kt.liao@emc.com.tw> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-03-27powerpc/pseries/energy: Use OF accessor functions to read ibm,drc-indexesGautham R. Shenoy
In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent, we currently use of_read_property() to obtain the pointer to the array corresponding to the property "ibm,drc-indexes". The elements of this array are of type __be32, but are accessed without any conversion to the OS-endianness, which is buggy on a Little Endian OS. Fix this by using of_property_read_u32_index() accessor function to safely read the elements of the array. Fixes: e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU indexes") Cc: stable@vger.kernel.org # v4.16+ Reported-by: Pavithra R. Prakash <pavrampu@in.ibm.com> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> [mpe: Make the WARN_ON a WARN_ON_ONCE so it's not retriggerable] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-03-26fm10k: Fix a potential NULL pointer dereferenceYue Haibing
Syzkaller report this: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 4378 Comm: syz-executor.0 Tainted: G C 5.0.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:__lock_acquire+0x95b/0x3200 kernel/locking/lockdep.c:3573 Code: 00 0f 85 28 1e 00 00 48 81 c4 08 01 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 24 00 00 49 81 7d 00 e0 de 03 a6 41 bc 00 00 RSP: 0018:ffff8881e3c07a40 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000080 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8881e3c07d98 R11: ffff8881c7f21f80 R12: 0000000000000001 R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 FS: 00007fce2252e700(0000) GS:ffff8881f2400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffc7eb0228 CR3: 00000001e5bea002 CR4: 00000000007606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: lock_acquire+0xff/0x2c0 kernel/locking/lockdep.c:4211 __mutex_lock_common kernel/locking/mutex.c:925 [inline] __mutex_lock+0xdf/0x1050 kernel/locking/mutex.c:1072 drain_workqueue+0x24/0x3f0 kernel/workqueue.c:2934 destroy_workqueue+0x23/0x630 kernel/workqueue.c:4319 __do_sys_delete_module kernel/module.c:1018 [inline] __se_sys_delete_module kernel/module.c:961 [inline] __x64_sys_delete_module+0x30c/0x480 kernel/module.c:961 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fce2252dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fce2252e6bc R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff If alloc_workqueue fails, it should return -ENOMEM, otherwise may trigger this NULL pointer dereference while unloading drivers. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 0a38c17a21a0 ("fm10k: Remove create_workqueue") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-03-26i40e: fix WoL support checkStefan Assmann
The current check for WoL on i40e is broken. Code comment says only magic packet is supported, so only check for that. Fixes: 540a152da762 (i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE) Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-03-26ixgbe: fix mdio bus registrationIvan Vecera
The ixgbe ignores errors returned from mdiobus_register() and leaves adapter->mii_bus non-NULL and MDIO bus state as MDIOBUS_ALLOCATED. This triggers a BUG from mdiobus_unregister() during ixgbe_remove() call. Fixes: 8fa10ef01260 ("ixgbe: register a mdiobus") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-03-26igb: Fix WARN_ONCE on runtime suspendArvind Sankar
The runtime_suspend device callbacks are not supposed to save configuration state or change the power state. Commit fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") changed the driver to not save configuration state during runtime suspend, however the driver callback still put the device into a low-power state. This causes a warning in the pci pm core and results in pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend. Fix this by not changing the power state either, leaving that to pci pm core, and make the same change for suspend callback as well. Also move a couple of defines into the appropriate header file instead of inline in the .c file. Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") Signed-off-by: Arvind Sankar <niveditas98@gmail.com> Reviewed-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-03-26i40e: fix i40e_ptp_adjtime when given a negative deltaJacob Keller
Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26) claims to be cleaning up references to 32-bit timespecs. The actual contents of the commit make no sense, as it converts a call to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the change was documented in the commit message, and (b) timespec64_add_ns supported negative numbers. timespec64_add_ns doesn't work with signed deltas, because the implementation is based around iter_div_u64_rem. This change resulted in a regression where i40e_ptp_adjtime would interpret small negative adjustments as large positive additions, resulting in incorrect behavior. This commit doesn't appear to fix anything, is not well explained, and introduces a bug, so lets just revert it. Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-03-26torture: Suppress false-positive CONFIG_INITRAMFS_SOURCE complaintPaul E. McKenney
The scripting must supply the CONFIG_INITRAMFS_SOURCE Kconfig option so that kbuild can find the desired initrd, but the configcheck.sh script gets confused by this option because it takes a string instead of the expected y/n/m. This causes checkconfig.sh to complain about CONFIG_INITRAMFS_SOURCE in the torture-test output (though not in the summary). As more people use rcutorture, the resulting confusion is an increasing concern. This commit therefore suppresses this false-positive warning by filtering CONFIG_INITRAMFS_SOURCE from within the checkconfig.sh script. Reported-by: Joel Fernandes <joel@joelfernandes.org> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26locktorture: NULL cxt.lwsa and cxt.lrsa to allow bad-arg detectionPaul E. McKenney
Currently, lock_torture_cleanup() uses the values of cxt.lwsa and cxt.lrsa to detect bad parameters that prevented locktorture from initializing, let alone running. In this case, lock_torture_cleanup() does no cleanup aside from invoking torture_cleanup_begin() and torture_cleanup_end(), as required to permit future torture tests to run. However, this heuristic fails if the run with bad parameters was preceded by a previous run that actually ran: In this case, both cxt.lwsa and cxt.lrsa will remain non-zero, which means that the current lock_torture_cleanup() invocation will be unable to detect the fact that it should skip cleanup, which can result in charming outcomes such as double frees. This commit therefore NULLs out both cxt.lwsa and cxt.lrsa at the end of any run that actually ran. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Josh Triplett <josh@joshtriplett.org>
2019-03-26rcuperf: Fix cleanup path for invalid perf_type stringsPaul E. McKenney
If the specified rcuperf.perf_type is not in the rcu_perf_init() function's perf_ops[] array, rcuperf prints some console messages and then invokes rcu_perf_cleanup() to set state so that a future torture test can run. However, rcu_perf_cleanup() also attempts to end the test that didn't actually start, and in doing so relies on the value of cur_ops, a value that is not particularly relevant in this case. This can result in confusing output or even follow-on failures due to attempts to use facilities that have not been properly initialized. This commit therefore sets the value of cur_ops to NULL in this case and inserts a check near the beginning of rcu_perf_cleanup(), thus avoiding relying on an irrelevant cur_ops value. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcutorture: Fix cleanup path for invalid torture_type stringsPaul E. McKenney
If the specified rcutorture.torture_type is not in the rcu_torture_init() function's torture_ops[] array, rcutorture prints some console messages and then invokes rcu_torture_cleanup() to set state so that a future torture test can run. However, rcu_torture_cleanup() also attempts to end the test that didn't actually start, and in doing so relies on the value of cur_ops, a value that is not particularly relevant in this case. This can result in confusing output or even follow-on failures due to attempts to use facilities that have not been properly initialized. This commit therefore sets the value of cur_ops to NULL in this case and inserts a check near the beginning of rcu_torture_cleanup(), thus avoiding relying on an irrelevant cur_ops value. Reported-by: kernel test robot <rong.a.chen@intel.com> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcutorture: Fix expected forward progress duration in OOM notifierNeeraj Upadhyay
The rcutorture_oom_notify() function has a misplaced close parenthesis that results in increasingly long delays in rcu_fwd_progress_check()'s checking for various RCU forward-progress problems. This commit therefore puts the parenthesis in the right place. Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcutorture: Remove ->ext_irq_conflict fieldPaul E. McKenney
Back when there was a separate RCU-bh flavor, the ->ext_irq_conflict field was used to prevent executing local_bh_enable() while interrupts were disabled. However, there is no longer an RCU-bh flavor, so this commit removes the no-longer-needed ->ext_irq_conflict field. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcutorture: Make rcutorture_extend_mask() comment match the codePaul E. McKenney
The code actually rarely uses more than one type of RCU read-side protection, as is actually desired given that we need some reasonable probability of preempting RCU read-side critical sections, which cannot happen with multiple types of protection. This comment therefore adjusts the comment. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26tools/.../rcutorture: Convert to SPDX license identifierPaul E. McKenney
Replace the license boiler plate with a SPDX license identifier. While in the area, update an email address and add copyright notices. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26torture: Don't try to offline the last CPUPaul E. McKenney
If there is only one online CPU, it doesn't make sense to try to offline it, as any such attempt is guaranteed to fail. This commit therefore check for this condition and refuses to attempt the nonsensical. Reported-by: Su Yue <suy.fnst@cn.fujitsu.com> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> Tested-By: Su Yue <suy.fnst@cn.fujitsu.com>
2019-03-26rcu: Fix nohz status in stall warningNeeraj Upadhyay
The Documentation/RCU/stallwarn.txt file says that stall warnings print "D" if dyntick-idle processing is enabled, but the code in print_cpu_stall_fast_no_hz() prints "." instead. This commit therefore reverses the sense of the test to make the code match the documentation. Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Move forward-progress checkers into tree_stall.hPaul E. McKenney
This commit further consolidates stall-warning functionality by moving forward-progress checkers into kernel/rcu/tree_stall.h, updating a comment or two while in the area. More specifically, this commit moves show_rcu_gp_kthreads(), rcu_check_gp_start_stall(), rcu_fwd_progress_check(), sysrq_rcu, sysrq_show_rcu(), sysrq_rcudump_op, and rcu_sysrq_init() from kernel/rcu/tree.c to kernel/rcu/tree_stall.h. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Move irq-disabled stall-warning checking to tree_stall.hPaul E. McKenney
The rcu_iw_handler() function's sole purpose in life is to indicate whether a stalled CPU had interrupts disabled, so it belongs in kernel/rcu/tree_stall.h. This commit therefore makes that move, clarifying its header comment while in the area. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Organize functions in tree_stall.hPaul E. McKenney
This commit does only code movement, removal of now-unneeded forward declarations, and addition of comments. It organizes the functions that implement RCU CPU stall warnings for normal grace periods into three categories: 1. Control of RCU CPU stall warnings, including computing timeouts. 2. Interaction of stall warnings with grace periods. 3. Actual printing of the RCU CPU stall-warning messages. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Move FAST_NO_HZ stall-warning code to tree_stall.hPaul E. McKenney
This commit further consolidates the stall-warning code by moving print_cpu_stall_info() and its helper functions along with zero_cpu_stall_ticks() to kernel/rcu/tree_stall.h. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Inline RCU stall-warning info helper functionsPaul E. McKenney
The print_cpu_stall_info_begin() and print_cpu_stall_info_end() print a single character each onto the console, and are a holdover from a time when RCU CPU stall warning messages could be abbreviated using a long-gone Kconfig option. This commit therefore adds these single characters to already-printed strings in the calling functions, and then eliminates both print_cpu_stall_info_begin() and print_cpu_stall_info_end(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Move rcu_print_task_exp_stall() to tree_exp.hPaul E. McKenney
Because expedited CPU stall warnings are contained within the kernel/rcu/tree_exp.h file, rcu_print_task_exp_stall() should live there too. This commit carries out the required code motion. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
2019-03-26rcu: Inline RCU task stall-warning helper functionsPaul E. McKenney
The rcu_print_detail_task_stall(), rcu_print_task_stall_begin(), and rcu_print_task_stall_end() functions were defined to allow long-gone Kconfig options to provide an abbreviated RCU CPU stall warning printout. This commit saves a few lines of code by inlining them into their sole callers. While in the area, a useless call of rcu_print_detail_task_stall_rnp() on the root rcu_node structure was eliminated. If there is only one rcu_node structure, its tasks get printed twice, but if there are more, the root rcu_node structure is guaranteed to have an empty list of blocked tasks, hence the uselessness. (Long ago, root rcu_node structures with non-empty ->blkd_tasks lists could happen, but no longer.) Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
generated by cgit (git 2.34.1) at 2025-09-22 04:39:26 +0000