summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-29arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEPWill Deacon1-2/+2
[ Upstream commit 5afc78551bf5d53279036e0bf63314e35631d79f ] Rather than open-code test_tsk_thread_flag() at each callsite, simply replace the couple of offenders with calls to test_tsk_thread_flag() directly. Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29usb: gadget: udc: gr_udc: fix memleak on error handling path in gr_ep_init()Evgeny Novikov1-2/+5
[ Upstream commit c8f8529e2c4141afa2ebb487ad48e8a6ec3e8c99 ] gr_ep_init() does not assign the allocated request anywhere if allocation of memory for the buffer fails. This is a memory leak fixed by the given patch. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Signed-off-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29Input: synaptics - enable InterTouch for ThinkPad X1E 1st genIlya Katsnelson1-0/+1
[ Upstream commit dcb00fc799dc03fd320e123e4c81b3278c763ea5 ] Tested on my own laptop, touchpad feels slightly more responsive with this on, though it might just be placebo. Signed-off-by: Ilya Katsnelson <me@0upti.me> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20200703143457.132373-1-me@0upti.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29dmaengine: ioat setting ioat timeout as module parameterLeonid Ravich2-2/+12
[ Upstream commit 87730ccbddcb48478b1b88e88b14e73424130764 ] DMA transaction time to completion is a function of PCI bandwidth, transaction size and a queue depth. So hard coded value for timeouts might be wrong for some scenarios. Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20200701184816.29138-1-leonid.ravich@dell.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29hwmon: (aspeed-pwm-tacho) Avoid possible buffer overflowEvgeny Novikov1-0/+2
[ Upstream commit bc4071aafcf4d0535ee423b69167696d6c03207d ] aspeed_create_fan() reads a pwm_port value using of_property_read_u32(). If pwm_port will be more than ARRAY_SIZE(pwm_port_params), there will be a buffer overflow in aspeed_create_pwm_port()->aspeed_set_pwm_port_enable(). The patch fixes the potential buffer overflow. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Link: https://lore.kernel.org/r/20200703111518.9644-1-novikov@ispras.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29regmap: dev_get_regmap_match(): fix string comparisonMarc Kleine-Budde1-1/+1
[ Upstream commit e84861fec32dee8a2e62bbaa52cded6b05a2a456 ] This function is used by dev_get_regmap() to retrieve a regmap for the specified device. If the device has more than one regmap, the name parameter can be used to specify one. The code here uses a pointer comparison to check for equal strings. This however will probably always fail, as the regmap->name is allocated via kstrdup_const() from the regmap's config->name. Fix this by using strcmp() instead. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29spi: mediatek: use correct SPI_CFG2_REG MACROleilk.liu1-7/+8
[ Upstream commit 44b37eb79e16a56cb30ba55b2da452396b941e7a ] this patch use correct SPI_CFG2_REG offset. Signed-off-by: leilk.liu <leilk.liu@mediatek.com> Link: https://lore.kernel.org/r/20200701090020.7935-1-leilk.liu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29Input: add `SW_MACHINE_COVER`Merlijn Wajer2-2/+3
[ Upstream commit c463bb2a8f8d7d97aa414bf7714fc77e9d3b10df ] This event code represents the state of a removable cover of a device. Value 0 means that the cover is open or removed, value 1 means that the cover is closed. Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Merlijn Wajer <merlijn@wizzup.org> Link: https://lore.kernel.org/r/20200612125402.18393-2-merlijn@wizzup.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29dmaengine: tegra210-adma: Fix runtime PM imbalance on errorDinghao Liu1-1/+4
[ Upstream commit 5b78fac4b1ba731cf4177fdbc1e3a4661521bcd0 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200624064626.19855-1-dinghao.liu@zju.edu.cn Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29HID: apple: Disable Fn-key key-re-mapping on clone keyboardsHans de Goede1-0/+18
[ Upstream commit a5d81646fa294eed57786a9310b06ca48902adf8 ] The Maxxter KB-BT-001 Bluetooth keyboard, which looks somewhat like the Apple Wireless Keyboard, is using the vendor and product IDs (05AC:0239) of the Apple Wireless Keyboard (2009 ANSI version) <sigh>. But its F1 - F10 keys are marked as sending F1 - F10, not the special functions hid-apple.c maps them too; and since its descriptors do not contain the HID_UP_CUSTOM | 0x0003 usage apple-hid looks for for the Fn-key, apple_setup_input() never gets called, so F1 - F6 are mapped to key-codes which have not been set in the keybit array causing them to not send any events at all. The lack of a usage code matching the Fn key in the clone is actually useful as this allows solving this problem in a generic way. This commits adds a fn_found flag and it adds a input_configured callback which checks if this flag is set once all usages have been mapped. If it is not set, then assume this is a clone and clear the quirks bitmap so that the hid-apple code does not add any special handling to this keyboard. This fixes F1 - F6 not sending anything at all and F7 - F12 sending the wrong codes on the Maxxter KB-BT-001 Bluetooth keyboard and on similar clones. Cc: Joao Moreno <mail@joaomoreno.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor overrideFederico Ricchiuto1-0/+8
[ Upstream commit 43e666acb79f3d355dd89bf20f4d25d3b15da13e ] The Mediacom FlexBook edge13 uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. Signed-off-by: Federico Ricchiuto <fed.ricchiuto@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29scripts/decode_stacktrace: strip basepath from all pathsPi-Hsun Shih1-2/+2
[ Upstream commit d178770d8d21489abf5bafefcbb6d5243b482e9a ] Currently the basepath is removed only from the beginning of the string. When the symbol is inlined and there's multiple line outputs of addr2line, only the first line would have basepath removed. Change to remove the basepath prefix from all lines. Fixes: 31013836a71e ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex") Co-developed-by: Shik Chen <shik@chromium.org> Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Shik Chen <shik@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Cc: Sasha Levin <sashal@kernel.org> Cc: Nicolas Boichat <drinkcat@chromium.org> Cc: Jiri Slaby <jslaby@suse.cz> Link: http://lkml.kernel.org/r/20200720082709.252805-1-pihsun@chromium.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29serial: exar: Fix GPIO configuration for Sealevel cards based on XR17V35XMatthew Howell1-1/+11
[ Upstream commit 5fdbe136ae19ab751daaa4d08d9a42f3e30d17f9 ] Sealevel XR17V35X based devices are inoperable on kernel versions 4.11 and above due to a change in the GPIO preconfiguration introduced in commit 7dea8165f1d. This patch fixes this by preconfiguring the GPIO on Sealevel cards to the value (0x00) used prior to commit 7dea8165f1d With GPIOs preconfigured as per commit 7dea8165f1d all ports on Sealevel XR17V35X based devices become stuck in high impedance mode, regardless of dip-switch or software configuration. This causes the device to become effectively unusable. This patch (in various forms) has been distributed to our customers and no issues related to it have been reported. Fixes: 7dea8165f1d6 ("serial: exar: Preconfigure xr17v35x MPIOs as output") Signed-off-by: Matthew Howell <matthew.howell@sealevel.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2007221605270.13247@tstest-VirtualBox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29bonding: check return value of register_netdevice() in bond_newlink()Cong Wang1-2/+1
[ Upstream commit c75d1d5248c0c97996051809ad0e9f154ba5d76e ] Very similar to commit 544f287b8495 ("bonding: check error value of register_netdevice() immediately"), we should immediately check the return value of register_netdevice() before doing anything else. Fixes: 005db31d5f5f ("bonding: set carrier off for devices created through netlink") Reported-and-tested-by: syzbot+bbc3a11c4da63c1b74d6@syzkaller.appspotmail.com Cc: Beniamino Galvani <bgalvani@redhat.com> Cc: Taehee Yoo <ap420073@gmail.com> Cc: Jay Vosburgh <j.vosburgh@gmail.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29i2c: rcar: always clear ICSAR to avoid side effectsWolfram Sang1-0/+3
[ Upstream commit eb01597158ffb1853a7a7fc2c57d4c844640f75e ] On R-Car Gen2, we get a timeout when reading from the address set in ICSAR, even though the slave interface is disabled. Clearing it fixes this situation. Note that Gen3 is not affected. To reproduce: bind and undbind an I2C slave on some bus, run 'i2cdetect' on that bus. Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29ipvs: fix the connection sync failed in some casesguodeqing1-4/+8
[ Upstream commit 8210e344ccb798c672ab237b1a4f241bda08909b ] The sync_thread_backup only checks sk_receive_queue is empty or not, there is a situation which cannot sync the connection entries when sk_receive_queue is empty and sk_rmem_alloc is larger than sk_rcvbuf, the sync packets are dropped in __udp_enqueue_schedule_skb, this is because the packets in reader_queue is not read, so the rmem is not reclaimed. Here I add the check of whether the reader_queue of the udp sock is empty or not to solve this problem. Fixes: 2276f58ac589 ("udp: use a separate rx queue for packet reception") Reported-by: zhouxudong <zhouxudong8@huawei.com> Signed-off-by: guodeqing <geffrey.guo@huawei.com> Acked-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29mlxsw: destroy workqueue when trap_register in mlxsw_emad_initLiu Jian1-1/+2
[ Upstream commit 5dbaeb87f2b309936be0aeae00cbc9e7f20ab296 ] When mlxsw_core_trap_register fails in mlxsw_emad_init, destroy_workqueue() shouled be called to destroy mlxsw_core->emad_wq. Fixes: d965465b60ba ("mlxsw: core: Fix possible deadlock") Signed-off-by: Liu Jian <liujian56@huawei.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29bonding: check error value of register_netdevice() immediatelyTaehee Yoo1-3/+7
[ Upstream commit 544f287b84959203367cd29e16e772717612fab4 ] If register_netdevice() is failed, net_device should not be used because variables are uninitialized or freed. So, the routine should be stopped immediately. But, bond_create() doesn't check return value of register_netdevice() immediately. That will result in a panic because of using uninitialized or freed memory. Test commands: modprobe netdev-notifier-error-inject echo -22 > /sys/kernel/debug/notifier-error-inject/netdev/\ actions/NETDEV_REGISTER/error modprobe bonding max_bonds=3 Splat looks like: [ 375.028492][ T193] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC PTI [ 375.033207][ T193] CPU: 2 PID: 193 Comm: kworker/2:2 Not tainted 5.8.0-rc4+ #645 [ 375.036068][ T193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 375.039673][ T193] Workqueue: events linkwatch_event [ 375.041557][ T193] RIP: 0010:dev_activate+0x4a/0x340 [ 375.043381][ T193] Code: 40 a8 04 0f 85 db 00 00 00 8b 83 08 04 00 00 85 c0 0f 84 0d 01 00 00 31 d2 89 d0 48 8d 04 40 48 c1 e0 07 48 03 83 00 04 00 00 <48> 8b 48 10 f6 41 10 01 75 08 f0 80 a1 a0 01 00 00 fd 48 89 48 08 [ 375.050267][ T193] RSP: 0018:ffff9f8facfcfdd8 EFLAGS: 00010202 [ 375.052410][ T193] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9f8fae6ea000 RCX: 0000000000000006 [ 375.055178][ T193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f8fae6ea000 [ 375.057762][ T193] RBP: ffff9f8fae6ea000 R08: 0000000000000000 R09: 0000000000000000 [ 375.059810][ T193] R10: 0000000000000001 R11: 0000000000000000 R12: ffff9f8facfcfe08 [ 375.061892][ T193] R13: ffffffff883587e0 R14: 0000000000000000 R15: ffff9f8fae6ea580 [ 375.063931][ T193] FS: 0000000000000000(0000) GS:ffff9f8fbae00000(0000) knlGS:0000000000000000 [ 375.066239][ T193] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 375.067841][ T193] CR2: 00007f2f542167a0 CR3: 000000012cee6002 CR4: 00000000003606e0 [ 375.069657][ T193] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 375.071471][ T193] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 375.073269][ T193] Call Trace: [ 375.074005][ T193] linkwatch_do_dev+0x4d/0x50 [ 375.075052][ T193] __linkwatch_run_queue+0x10b/0x200 [ 375.076244][ T193] linkwatch_event+0x21/0x30 [ 375.077274][ T193] process_one_work+0x252/0x600 [ 375.078379][ T193] ? process_one_work+0x600/0x600 [ 375.079518][ T193] worker_thread+0x3c/0x380 [ 375.080534][ T193] ? process_one_work+0x600/0x600 [ 375.081668][ T193] kthread+0x139/0x150 [ 375.082567][ T193] ? kthread_park+0x90/0x90 [ 375.083567][ T193] ret_from_fork+0x22/0x30 Fixes: e826eafa65c6 ("bonding: Call netif_carrier_off after register_netdevice") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29net: smc91x: Fix possible memory leak in smc_drv_probe()Wang Hai1-2/+2
[ Upstream commit bca9749b1aa23d964d3ab930938af66dbf887f15 ] If try_toggle_control_gpio() failed in smc_drv_probe(), free_netdev(ndev) should be called to free the ndev created earlier. Otherwise, a memleak will occur. Fixes: 7d2911c43815 ("net: smc91x: Fix gpios for device tree based booting") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29drm: sun4i: hdmi: Fix inverted HPD resultChen-Yu Tsai1-1/+1
[ Upstream commit baa1841eb797eadce6c907bdaed7cd6f01815404 ] When the extra HPD polling in sun4i_hdmi was removed, the result of HPD was accidentally inverted. Fix this by inverting the check. Fixes: bda8eaa6dee7 ("drm: sun4i: hdmi: Remove extra HPD polling") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200711011030.21997-1-wens@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29net: dp83640: fix SIOCSHWTSTAMP to update the struct with actual configurationSergey Organov1-0/+4
[ Upstream commit 473309fb8372365ad211f425bca760af800e10a7 ] From Documentation/networking/timestamping.txt: A driver which supports hardware time stamping shall update the struct with the actual, possibly more permissive configuration. Do update the struct passed when we upscale the requested time stamping mode. Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.") Signed-off-by: Sergey Organov <sorganov@gmail.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29ax88172a: fix ax88172a_unbind() failuresGeorge Kennedy1-0/+1
[ Upstream commit c28d9a285668c799eeae2f7f93e929a6028a4d6d ] If ax88172a_unbind() fails, make sure that the return code is less than zero so that cleanup is done properly and avoid UAF. Fixes: a9a51bd727d1 ("ax88172a: fix information leak on short answers") Signed-off-by: George Kennedy <george.kennedy@oracle.com> Reported-by: syzbot+4cd84f527bf4a10fc9c1@syzkaller.appspotmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29hippi: Fix a size used in a 'pci_free_consistent()' in an error handling pathChristophe JAILLET1-1/+1
[ Upstream commit 3195c4706b00106aa82c73acd28340fa8fc2bfc1 ] The size used when calling 'pci_alloc_consistent()' and 'pci_free_consistent()' should match. Fix it and have it consistent with the corresponding call in 'rr_close()'. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29bnxt_en: Fix race when modifying pause settings.Vasundhara Volam1-1/+4
[ Upstream commit 163e9ef63641a02de4c95cd921577265c52e1ce2 ] The driver was modified to not rely on rtnl lock to protect link settings about 2 years ago. The pause setting was missed when making that change. Fix it by acquiring link_lock mutex before calling bnxt_hwrm_set_pause(). Fixes: e2dc9b6e38fa ("bnxt_en: Don't use rtnl lock to protect link change logic in workqueue.") Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29btrfs: fix page leaks after failure to lock page for delallocRobbie Ko1-1/+2
commit 5909ca110b29aa16b23b52b8de8d3bb1035fd738 upstream. When locking pages for delalloc, we check if it's dirty and mapping still matches. If it does not match, we need to return -EAGAIN and release all pages. Only the current page was put though, iterate over all the remaining pages too. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Robbie Ko <robbieko@synology.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29btrfs: fix mount failure caused by race with umountBoris Burkov1-0/+8
commit 48cfa61b58a1fee0bc49eef04f8ccf31493b7cdd upstream. It is possible to cause a btrfs mount to fail by racing it with a slow umount. The crux of the sequence is generic_shutdown_super not yet calling sop->put_super before btrfs_mount_root calls btrfs_open_devices. If that occurs, btrfs_open_devices will decide the opened counter is non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to 0. From here, mount will call sget which will result in grab_super trying to take the super block umount semaphore. That semaphore will be held by the slow umount, so mount will block. Before up-ing the semaphore, umount will delete the super block, resulting in mount's sget reliably allocating a new one, which causes the mount path to dutifully fill it out, and increment total_rw_bytes a second time, which causes the mount to fail, as we see double the expected bytes. Here is the sequence laid out in greater detail: CPU0 CPU1 down_write sb->s_umount btrfs_kill_super kill_anon_super(sb) generic_shutdown_super(sb); shrink_dcache_for_umount(sb); sync_filesystem(sb); evict_inodes(sb); // SLOW btrfs_mount_root btrfs_scan_one_device fs_devices = device->fs_devices fs_info->fs_devices = fs_devices // fs_devices-opened makes this a no-op btrfs_open_devices(fs_devices, mode, fs_type) s = sget(fs_type, test, set, flags, fs_info); find sb in s_instances grab_super(sb); down_write(&s->s_umount); // blocks sop->put_super(sb) // sb->fs_devices->opened == 2; no-op spin_lock(&sb_lock); hlist_del_init(&sb->s_instances); spin_unlock(&sb_lock); up_write(&sb->s_umount); return 0; retry lookup don't find sb in s_instances (deleted by CPU0) s = alloc_super return s; btrfs_fill_super(s, fs_devices, data) open_ctree // fs_devices total_rw_bytes improperly set! btrfs_read_chunk_tree read_one_dev // increment total_rw_bytes again!! super_total_bytes < fs_devices->total_rw_bytes // ERROR!!! To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree before the calls to read_one_dev, while holding the sb umount semaphore and the uuid mutex. To reproduce, it is sufficient to dirty a decent number of inodes, then quickly umount and mount. for i in $(seq 0 500) do dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1 done umount /mnt/foo& mount /mnt/foo does the trick for me. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29btrfs: fix double free on ulist after backref resolution failureFilipe Manana1-0/+1
commit 580c079b5766ac706f56eec5c79aee4bf929fef6 upstream. At btrfs_find_all_roots_safe() we allocate a ulist and set the **roots argument to point to it. However if later we fail due to an error returned by find_parent_nodes(), we free that ulist but leave a dangling pointer in the **roots argument. Upon receiving the error, a caller of this function can attempt to free the same ulist again, resulting in an invalid memory access. One such scenario is during qgroup accounting: btrfs_qgroup_account_extents() --> calls btrfs_find_all_roots() passes &new_roots (a stack allocated pointer) to btrfs_find_all_roots() --> btrfs_find_all_roots() just calls btrfs_find_all_roots_safe() passing &new_roots to it --> allocates ulist and assigns its address to **roots (which points to new_roots from btrfs_qgroup_account_extents()) --> find_parent_nodes() returns an error, so we free the ulist and leave **roots pointing to it after returning --> btrfs_qgroup_account_extents() sees btrfs_find_all_roots() returned an error and jumps to the label 'cleanup', which just tries to free again the same ulist Stack trace example: ------------[ cut here ]------------ BTRFS: tree first key check failed WARNING: CPU: 1 PID: 1763215 at fs/btrfs/disk-io.c:422 btrfs_verify_level_key+0xe0/0x180 [btrfs] Modules linked in: dm_snapshot dm_thin_pool (...) CPU: 1 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:btrfs_verify_level_key+0xe0/0x180 [btrfs] Code: 28 5b 5d (...) RSP: 0018:ffffb89b473779a0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff90397759bf08 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000027 RDI: 00000000ffffffff RBP: ffff9039a419c000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: ffffb89b43301000 R12: 000000000000005e R13: ffffb89b47377a2e R14: ffffb89b473779af R15: 0000000000000000 FS: 00007fc47e1e1000(0000) GS:ffff9039ac200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc47e1df000 CR3: 00000003d9e4e001 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: read_block_for_search+0xf6/0x350 [btrfs] btrfs_next_old_leaf+0x242/0x650 [btrfs] resolve_indirect_refs+0x7cf/0x9e0 [btrfs] find_parent_nodes+0x4ea/0x12c0 [btrfs] btrfs_find_all_roots_safe+0xbf/0x130 [btrfs] btrfs_qgroup_account_extents+0x9d/0x390 [btrfs] btrfs_commit_transaction+0x4f7/0xb20 [btrfs] btrfs_sync_file+0x3d4/0x4d0 [btrfs] do_fsync+0x38/0x70 __x64_sys_fdatasync+0x13/0x20 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc47e2d72e3 Code: Bad RIP value. RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3 RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003 RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8 R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50 irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffffffffb8eb5e85>] copy_process+0x755/0x1eb0 softirqs last enabled at (0): [<ffffffffb8eb5e85>] copy_process+0x755/0x1eb0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 8639237550317b48 ]--- BTRFS error (device sdc): tree first key mismatch detected, bytenr=62324736 parent_transid=94 key expected=(262,108,1351680) has=(259,108,1921024) general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ulist_release+0x14/0x60 [btrfs] Code: c7 07 00 (...) RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282 RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840 RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840 R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840 FS: 00007fc47e1e1000(0000) GS:ffff9039ac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8c1c0a51c8 CR3: 00000003d9e4e004 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ulist_free+0x13/0x20 [btrfs] btrfs_qgroup_account_extents+0xf3/0x390 [btrfs] btrfs_commit_transaction+0x4f7/0xb20 [btrfs] btrfs_sync_file+0x3d4/0x4d0 [btrfs] do_fsync+0x38/0x70 __x64_sys_fdatasync+0x13/0x20 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc47e2d72e3 Code: Bad RIP value. RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3 RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003 RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8 R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50 Modules linked in: dm_snapshot dm_thin_pool (...) ---[ end trace 8639237550317b49 ]--- RIP: 0010:ulist_release+0x14/0x60 [btrfs] Code: c7 07 00 (...) RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282 RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840 RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840 R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840 FS: 00007fc47e1e1000(0000) GS:ffff9039ad200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6a776f7d40 CR3: 00000003d9e4e002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fix this by making btrfs_find_all_roots_safe() set *roots to NULL after it frees the ulist. Fixes: 8da6d5815c592b ("Btrfs: added btrfs_find_all_roots()") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29ASoC: rt5670: Correct RT5670_LDO_SEL_MASKHans de Goede1-1/+1
commit 5cacc6f5764e94fa753b2c1f5f7f1f3f74286e82 upstream. The RT5670_PWR_ANLG1 register has 3 bits to select the LDO voltage, so the correct mask is 0x7 not 0x3. Because of this wrong mask we were programming the ldo bits to a setting of binary 001 (0x05 & 0x03) instead of binary 101 when moving to SND_SOC_BIAS_PREPARE. According to the datasheet 001 is a reserved value, so no idea what it did, since the driver was working fine before I guess we got lucky and it does something which is ok. Fixes: 5e8351de740d ("ASoC: add RT5670 CODEC driver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200628155231.71089-3-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29ALSA: info: Drop WARN_ON() from buffer NULL sanity checkTakashi Iwai1-1/+3
commit 60379ba08532eca861e933b389526a4dc89e0c42 upstream. snd_info_get_line() has a sanity check of NULL buffer -- both buffer itself being NULL and buffer->buffer being NULL. Basically both checks are valid and necessary, but the problem is that it's with snd_BUG_ON() macro that triggers WARN_ON(). The latter condition (NULL buffer->buffer) can be met arbitrarily by user since the buffer is allocated at the first write, so it means that user can trigger WARN_ON() at will. This patch addresses it by simply moving buffer->buffer NULL check out of snd_BUG_ON() so that spurious WARNING is no longer triggered. Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to fix ↵Oleg Nesterov1-1/+1
GDB regression commit fe5ed7ab99c656bd2f5b79b49df0e9ebf2cead8a upstream. If a tracee is uprobed and it hits int3 inserted by debugger, handle_swbp() does send_sig(SIGTRAP, current, 0) which means si_code == SI_USER. This used to work when this code was written, but then GDB started to validate si_code and now it simply can't use breakpoints if the tracee has an active uprobe: # cat test.c void unused_func(void) { } int main(void) { return 0; } # gcc -g test.c -o test # perf probe -x ./test -a unused_func # perf record -e probe_test:unused_func gdb ./test -ex run GNU gdb (GDB) 10.0.50.20200714-git ... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff7ddf909 in dl_main () from /lib64/ld-linux-x86-64.so.2 (gdb) The tracee hits the internal breakpoint inserted by GDB to monitor shared library events but GDB misinterprets this SIGTRAP and reports a signal. Change handle_swbp() to use force_sig(SIGTRAP), this matches do_int3_user() and fixes the problem. This is the minimal fix for -stable, arch/x86/kernel/uprobes.c is equally wrong; it should use send_sigtrap(TRAP_TRACE) instead of send_sig(SIGTRAP), but this doesn't confuse GDB and needs another x86-specific patch. Reported-by: Aaron Merey <amerey@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200723154420.GA32043@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29IB/umem: fix reference count leak in ib_umem_odp_get()Yang Yingliang1-1/+2
Add missing mmput() on error path to avoid ref-count leak. This problem is introduced by 79bb5b7ee177 ("RDMA/umem: Fix missing mmap_sem in get umem ODP call") and resolved by f27a0d50a4bc ("RDMA/umem: Use umem->owning_mm inside ODP"). So, it's only needed in stable-4.14 and stable-4.19. Fixes: 79bb5b7ee177 ("RDMA/umem: Fix missing mmap_sem in get umem ODP call") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not oursVladimir Oltean1-1/+3
commit d41f36a6464a85c06ad920703d878e4491d2c023 upstream. The DSPI interrupt can be shared between two controllers at least on the LX2160A. In that case, the driver for one controller might misbehave and consume the other's interrupt. Fix this by actually checking if any of the bits in the status register have been asserted. Fixes: 13aed2392741 ("spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20190822212450.21420-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE not waiting for direct IO ↵Olga Kornievskaia2-10/+4
compeletion") commit 65caafd0d2145d1dd02072c4ced540624daeab40 upstream. Reverting commit d03727b248d0 "NFSv4 fix CLOSE not waiting for direct IO compeletion". This patch made it so that fput() by calling inode_dio_done() in nfs_file_release() would wait uninterruptably for any outstanding directIO to the file (but that wait on IO should be killable). The problem the patch was also trying to address was REMOVE returning ERR_ACCESS because the file is still opened, is supposed to be resolved by server returning ERR_FILE_OPEN and not ERR_ACCESS. Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29irqdomain/treewide: Keep firmware node unconditionally allocatedThomas Gleixner7-17/+25
[ Upstream commit e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb ] Quite some non OF/ACPI users of irqdomains allocate firmware nodes of type IRQCHIP_FWNODE_NAMED or IRQCHIP_FWNODE_NAMED_ID and free them right after creating the irqdomain. The only purpose of these FW nodes is to convey name information. When this was introduced the core code did not store the pointer to the node in the irqdomain. A recent change stored the firmware node pointer in irqdomain for other reasons and missed to notice that the usage sites which do the alloc_fwnode/create_domain/free_fwnode sequence are broken by this. Storing a dangling pointer is dangerous itself, but in case that the domain is destroyed later on this leads to a double free. Remove the freeing of the firmware node after creating the irqdomain from all affected call sites to cure this. Fixes: 711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode") Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/873661qakd.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeoutBen Skeggs2-4/+4
[ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29net: sky2: initialize return of gm_phy_readTom Rix1-1/+1
[ Upstream commit 28b18e4eb515af7c6661c3995c6e3c34412c2874 ] clang static analysis flags this garbage return drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return v; ^~~~~~~~ static inline u16 gm_phy_read( ... { u16 v; __gm_phy_read(hw, port, reg, &v); return v; } __gm_phy_read can return without setting v. So handle similar to skge.c's gm_phy_read, initialize v. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29drivers/net/wan/lapbether: Fixed the value of hard_header_lenXie He1-1/+8
[ Upstream commit 9dc829a135fb5927f1519de11286e2bbb79f5b66 ] When this driver transmits data, first this driver will remove a pseudo header of 1 byte, then the lapb module will prepend the LAPB header of 2 or 3 bytes, then this driver will prepend a length field of 2 bytes, then the underlying Ethernet device will prepend its own header. So, the header length required should be: -1 + 3 + 2 + "the header length needed by the underlying device". This patch fixes kernel panic when this driver is used with AF_PACKET SOCK_DGRAM sockets. Signed-off-by: Xie He <xie.he.0141@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29xtensa: update *pos in cpuinfo_op.nextMax Filippov1-1/+2
[ Upstream commit 0d5ab144429e8bd80889b856a44d56ab4a5cd59b ] Increment *pos in the cpuinfo_op.next to fix the following warning triggered by cat /proc/cpuinfo: seq_file: buggy .next function c_next did not update position index Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29xtensa: fix __sync_fetch_and_{and,or}_4 declarationsMax Filippov1-2/+2
[ Upstream commit 73f9941306d5ce030f3ffc7db425c7b2a798cf8e ] Building xtensa kernel with gcc-10 produces the following warnings: arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types for built-in function ‘__sync_fetch_and_and_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types for built-in function ‘__sync_fetch_and_or_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] Fix declarations of these functions to avoid the warning. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29scsi: scsi_transport_spi: Fix function pointer checkTom Rix1-1/+1
[ Upstream commit 5aee52c44d9170591df65fafa1cd408acc1225ce ] clang static analysis flags several null function pointer problems. drivers/scsi/scsi_transport_spi.c:374:1: warning: Called function pointer is null (null dereference) [core.CallAndMessage] spi_transport_max_attr(offset, "%d\n"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewing the store_spi_store_max macro if (i->f->set_##field) return -EINVAL; should be if (!i->f->set_##field) return -EINVAL; Link: https://lore.kernel.org/r/20200627133242.21618-1-trix@redhat.com Reviewed-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29mac80211: allow rx of mesh eapol frames with default rx keyMarkus Theil1-0/+26
[ Upstream commit 0b467b63870d9c05c81456aa9bfee894ab2db3b6 ] Without this patch, eapol frames cannot be received in mesh mode, when 802.1X should be used. Initially only a MGTK is defined, which is found and set as rx->key, when there are no other keys set. ieee80211_drop_unencrypted would then drop these eapol frames, as they are data frames without encryption and there exists some rx->key. Fix this by differentiating between mesh eapol frames and other data frames with existing rx->key. Allow mesh mesh eapol frames only if they are for our vif address. With this patch in-place, ieee80211_rx_h_mesh_fwding continues after the ieee80211_drop_unencrypted check and notices, that these eapol frames have to be delivered locally, as they should. Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20200625104214.50319-1-markus.theil@tu-ilmenau.de [small code cleanups] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29pinctrl: amd: fix npins for uart0 in kerncz_groupsJacky Hu1-1/+1
[ Upstream commit 69339d083dfb7786b0e0b3fc19eaddcf11fabdfb ] uart0_pins is defined as: static const unsigned uart0_pins[] = {135, 136, 137, 138, 139}; which npins is wronly specified as 9 later { .name = "uart0", .pins = uart0_pins, .npins = 9, }, npins should be 5 instead of 9 according to the definition. Signed-off-by: Jacky Hu <hengqing.hu@gmail.com> Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29gpio: arizona: put pm_runtime in case of failureNavid Emamdoost1-1/+5
[ Upstream commit 861254d826499944cb4d9b5a15f5a794a6b99a69 ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count if pm_runtime_put is not called in error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200605030052.78235-1-navid.emamdoost@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-29gpio: arizona: handle pm_runtime_get_sync failure caseNavid Emamdoost1-0/+1
[ Upstream commit e6f390a834b56583e6fc0949822644ce92fbb107 ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count. Call pm_runtime_put if pm_runtime_get_sync fails. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200605025207.65719-1-navid.emamdoost@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-22Linux 4.14.189v4.14.189Greg Kroah-Hartman1-1/+1
2020-07-22rxrpc: Fix trace stringDavid Howells1-1/+1
commit aadf9dcef9d4cd68c73a4ab934f93319c4becc47 upstream. The trace symbol printer (__print_symbolic()) ignores symbols that map to an empty string and prints the hex value instead. Fix the symbol for rxrpc_cong_no_change to " -" instead of "" to avoid this. Fixes: b54a134a7de4 ("rxrpc: Fix handling of enums-to-string translation in tracing") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22libceph: don't omit recovery_deletes in target_copy()Ilya Dryomov1-0/+1
commit 2f3fead62144002557f322c2a7c15e1255df0653 upstream. Currently target_copy() is used only for sending linger pings, so this doesn't come up, but generally omitting recovery_deletes can result in unneeded resends (force_resend in calc_target()). Fixes: ae78dd8139ce ("libceph: make RECOVERY_DELETES feature create a new interval") Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22x86/cpu: Move x86_cache_bits settingsSuraj Jitindar Singh1-1/+1
This patch is to fix the backport of the upstream patch: cc51e5428ea5 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ When this was backported to the 4.9 and 4.14 stable branches the line + c->x86_cache_bits = c->x86_phys_bits; was applied in the wrong place, being added to the identify_cpu_without_cpuid() function instead of the get_cpu_cap() function which it was correctly applied to in the 4.4 backport. This means that x86_cache_bits is not set correctly resulting in the following warning due to the cache bits being left uninitalised (zero). WARNING: CPU: 0 PID: 7566 at arch/x86/kvm/mmu.c:284 kvm_mmu_set_mmio_spte_mask+0x4e/0x60 [kvm Modules linked in: kvm_intel(+) kvm irqbypass ipv6 crc_ccitt binfmt_misc evdev lpc_ich mfd_core ioatdma pcc_cpufreq dca ena acpi_power_meter hwmon acpi_pad button ext4 crc16 mbcache jbd2 fscrypto nvme nvme_core dm_mirror dm_region_hash dm_log dm_mod dax Hardware name: Amazon EC2 i3.metal/Not Specified, BIOS 1.0 10/16/2017 task: ffff88ff77704c00 task.stack: ffffc9000edac000 RIP: 0010:kvm_mmu_set_mmio_spte_mask+0x4e/0x60 [kvm RSP: 0018:ffffc9000edafc60 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffff45 RDX: 000000000000002e RSI: 0008000000000001 RDI: 0008000000000001 RBP: ffffffffa036f000 R08: ffffffffffffff80 R09: ffffe8ffffccb3c0 R10: 0000000000000038 R11: 0000000000000000 R12: 0000000000005b80 R13: ffffffffa0370e40 R14: 0000000000000001 R15: ffff88bf7c0927e0 FS: 00007fa316f24740(0000) GS:ffff88bf7f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa316ea0000 CR3: 0000003f7e986004 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kvm_mmu_module_init+0x166/0x230 [kvm kvm_arch_init+0x5d/0x150 [kvm kvm_init+0x1c/0x2d0 [kvm ? hardware_setup+0x4a6/0x4a6 [kvm_intel vmx_init+0x23/0x6aa [kvm_intel ? hardware_setup+0x4a6/0x4a6 [kvm_intel do_one_initcall+0x3e/0x15d do_init_module+0x5b/0x1e5 load_module+0x19e6/0x1dc0 ? SYSC_init_module+0x13b/0x170 SYSC_init_module+0x13b/0x170 do_syscall_64+0x67/0x110 entry_SYSCALL_64_after_hwframe+0x41/0xa6 RIP: 0033:0x7fa316828f3a RSP: 002b:00007ffc9d65c1f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af RAX: ffffffffffffffda RBX: 00007fa316b08849 RCX: 00007fa316828f3a RDX: 00007fa316b08849 RSI: 0000000000071328 RDI: 00007fa316e37000 RBP: 0000000000b47e80 R08: 0000000000000003 R09: 0000000000000000 R10: 00007fa316822dba R11: 0000000000000246 R12: 0000000000b46340 R13: 0000000000b464c0 R14: 0000000000000000 R15: 0000000000040000 Code: e9 65 06 00 75 25 48 b8 00 00 00 00 00 00 00 40 48 09 c6 48 09 c7 48 89 35 f8 65 06 00 48 89 3d f9 65 06 00 c3 0f 0b 0f 0b eb d2 <0f> 0b eb d7 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 Fixes: 4.9.x ef3d45c95764 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ Fixes: 4.14.x ec4034835eaf x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ Cc: stable@vger.kernel.org # 4.9.x-4.14.x Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com> Reviewed-by: Samuel Mendoza-Jonas <samjonas@amazon.com> Reviewed-by: Frank van der Linden <fllinden@amazon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22sched/fair: handle case of task_h_load() returning 0Vincent Guittot1-1/+9
commit 01cfcde9c26d8555f0e6e9aea9d6049f87683998 upstream. task_h_load() can return 0 in some situations like running stress-ng mmapfork, which forks thousands of threads, in a sched group on a 224 cores system. The load balance doesn't handle this correctly because env->imbalance never decreases and it will stop pulling tasks only after reaching loop_max, which can be equal to the number of running tasks of the cfs. Make sure that imbalance will be decreased by at least 1. misfit task is the other feature that doesn't handle correctly such situation although it's probably more difficult to face the problem because of the smaller number of CPUs and running tasks on heterogenous system. We can't simply ensure that task_h_load() returns at least one because it would imply to handle underflow in other places. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: <stable@vger.kernel.org> # v4.4+ Link: https://lkml.kernel.org/r/20200710152426.16981-1-vincent.guittot@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22arm64: ptrace: Override SPSR.SS when single-stepping is enabledWill Deacon3-6/+20
commit 3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream. Luis reports that, when reverse debugging with GDB, single-step does not function as expected on arm64: | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP | request by GDB won't execute the underlying instruction. As a consequence, | the PC doesn't move, but we return a SIGTRAP just like we would for a | regular successful PTRACE_SINGLESTEP request. The underlying problem is that when the CPU register state is restored as part of a reverse step, the SPSR.SS bit is cleared and so the hardware single-step state can transition to the "active-pending" state, causing an unexpected step exception to be taken immediately if a step operation is attempted. In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate accessible by the GPR regset, but it's a bit late for that now. Instead, simply prevent userspace from configuring the bit to a value which is inconsistent with the TIF_SINGLESTEP state for the task being traced. Cc: <stable@vger.kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Keno Fischer <keno@juliacomputing.com> Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org Reported-by: Luis Machado <luis.machado@linaro.org> Tested-by: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-08 16:29:48 +0300