- 06 Jan, 2021 1 commit
-
-
Kevin Vigor authored
commit 93decc56 upstream. In __make_request() a new r10bio is allocated and passed to raid10_read_request(). The read_slot member of the bio is not initialized, and the raid10_read_request() uses it to index an array. This leads to occasional panics. Fix by initializing the field to invalid value and checking for valid value in raid10_read_request(). Cc: stable@vger.kernel.org Signed-off-by:
Kevin Vigor <kvigor@gmail.com> Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 30 Dec, 2020 39 commits
-
-
Greg Kroah-Hartman authored
Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Pavel Machek (CIP) <pavel@denx.de> Link: https://lore.kernel.org/r/20201228124919.745526410@linuxfoundation.org Signed-off-by:
-
Arnd Bergmann authored
commit eca6ba20 upstream. The only reference to the mlxplat_mlxcpld_psu[] array got removed, so there is now a warning from clang: drivers/platform/x86/mlx-platform.c:322:30: error: variable 'mlxplat_mlxcpld_psu' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] static struct i2c_board_info mlxplat_mlxcpld_psu[] = { Remove the array as well and adapt the ARRAY_SIZE() call accordingly. Fixes: 912b3415 ("platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20201203223105.1195709-1-arnd@kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Jubin Zhong authored
commit 4684709b upstream. If kobject_init_and_add() fails, pci_slot_release() is called to delete slot->list from parent->slots. But slot->list hasn't been initialized yet, so we dereference a NULL pointer: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197 task: ffffeb398a45ef10 task.stack: ffffeb398a470000 PC is at __list_del_entry_valid+0x5c/0xb0 LR is at pci_slot_release+0x84/0xe4 ... __list_del_entry_valid+0x5c/0xb0 pci_slot_release+0x84/0xe4 kobject_put+0x184/0x1c4 pci_create_slot+0x17c/0x1b4 __pci_hp_initialize+0x68/0xa4 pciehp_probe+0x1a4/0x2fc pcie_port_probe_service+0x58/0x84 driver_probe_device+0x320/0x470 Initialize slot->list before calling kobject_init_and_add() to avoid this. Fixes: 8a94644b ("PCI: Fix pci_create_slot() reference count leak") Link: https://lore.kernel.org/r/1606876422-117457-1-git-send-email-zhongjubin@huawei.com Signed-off-by:
Jubin Zhong <zhongjubin@huawei.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v5.9+ Signed-off-by:
-
Carlos Garnacho authored
commit fe600099 upstream. This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE that works as it would be expected, both when detaching the keyboard and when folding it behind the tablet body. It used to work until the introduction of the allow list at commit 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual Buttons device announces the EV_SW features again. Fixes: 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") Cc: stable@vger.kernel.org Signed-off-by:
Carlos Garnacho <carlosg@gnome.org> Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.org Signed-off-by:
-
Dan Williams authored
commit 2dd2a174 upstream. A recent change to ndctl to attempt to reconfigure namespaces in place uncovered a label accounting problem in block-window-type namespaces. The ndctl "create.sh" test is able to trigger this signature: WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm] [..] RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm] [..] Call Trace: uuid_store+0x21b/0x2f0 [libnvdimm] kernfs_fop_write+0xcf/0x1c0 vfs_write+0xcc/0x380 ksys_write+0x68/0xe0 When allocated capacity for a namespace is renamed (new UUID) the labels with the old UUID need to be deleted. The ndctl behavior to always destroy namespaces on reconfiguration hid this problem. The immediate impact of this bug is limited since block-window-type namespaces only seem to exist in the specification and not in any shipping products. However, the label handling code is being reused for other technologies like CXL region labels, so there is a benefit to making sure both vertical labels sets (block-window) and horizontal label sets (pmem) have a functional reference implementation in libnvdimm. Fixes: c4703ce1 ("libnvdimm/namespace: Fix label tracking error") Cc: <stable@vger.kernel.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Ira Weiny <ira.weiny@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
SeongJae Park authored
commit 9996bd49 upstream. 'xenbus_backend' watches 'state' of devices, which is writable by guests. Hence, if guests intensively updates it, dom0 will have lots of pending events that exhausting memory of dom0. In other words, guests can trigger dom0 memory pressure. This is known as XSA-349. However, the watch callback of it, 'frontend_changed()', reads only 'state', so doesn't need to have the pending events. To avoid the problem, this commit disallows pending watch messages for 'xenbus_backend' using the 'will_handle()' watch callback. This is part of XSA-349 Cc: stable@vger.kernel.org Signed-off-by:
SeongJae Park <sjpark@amazon.de> Reported-by:
Michael Kurth <mku@amazon.de> Reported-by:
Pawel Wieczorkiewicz <wipawel@amazon.de> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
SeongJae Park authored
commit 3dc86ca6 upstream. This commit adds a counter of pending messages for each watch in the struct. It is used to skip unnecessary pending messages lookup in 'unregister_xenbus_watch()'. It could also be used in 'will_handle' callback. This is part of XSA-349 Cc: stable@vger.kernel.org Signed-off-by:
-
SeongJae Park authored
commit be987200 upstream. This commit adds support of the 'will_handle' watch callback for 'xen_bus_type' users. This is part of XSA-349 Cc: stable@vger.kernel.org Signed-off-by:
-
SeongJae Park authored
commit 2e85d32b upstream. Some code does not directly make 'xenbus_watch' object and call 'register_xenbus_watch()' but use 'xenbus_watch_path()' instead. This commit adds support of 'will_handle' callback in the 'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'. This is part of XSA-349 Cc: stable@vger.kernel.org Signed-off-by:
-
SeongJae Park authored
commit fed1755b upstream. If handling logics of watch events are slower than the events enqueue logic and the events can be created from the guests, the guests could trigger memory pressure by intensively inducing the events, because it will create a huge number of pending events that exhausting the memory. Fortunately, some watch events could be ignored, depending on its handler callback. For example, if the callback has interest in only one single path, the watch wouldn't want multiple pending events. Or, some watches could ignore events to same path. To let such watches to volutarily help avoiding the memory pressure situation, this commit introduces new watch callback, 'will_handle'. If it is not NULL, it will be called for each new event just before enqueuing it. Then, if the callback returns false, the event will be discarded. No watch is using the callback for now, though. This is part of XSA-349 Cc: stable@vger.kernel.org Signed-off-by:
-
Pawel Wieczorkiewicz authored
commit 1c728719 upstream. When xen_blkif_disconnect() is called, the kernel thread behind the block interface is stopped by calling kthread_stop(ring->xenblkd). The ring->xenblkd thread pointer being non-NULL determines if the thread has been already stopped. Normally, the thread's function xen_blkif_schedule() sets the ring->xenblkd to NULL, when the thread's main loop ends. However, when the thread has not been started yet (i.e. wake_up_process() has not been called on it), the xen_blkif_schedule() function would not be called yet. In such case the kthread_stop() call returns -EINTR and the ring->xenblkd remains dangling. When this happens, any consecutive call to xen_blkif_disconnect (for example in frontend_changed() callback) leads to a kernel crash in kthread_stop() (e.g. NULL pointer dereference in exit_creds()). This is XSA-350. Cc: <stable@vger.kernel.org> # 4.12 Fixes: a24fa22c ("xen/blkback: don't use xen_blkif_get() in xen-blkback kthread") Reported-by:
Olivier Benjamin <oliben@amazon.com> Reported-by:
Julien Grall <jgrall@amazon.com> Reviewed-by:
-
Terry Zhou authored
commit 6f37689c upstream. There is an error in the current code that the XTAL MODE pin was set to NB MPP1_31 which should be NB MPP1_9. The latch register of NB MPP1_9 has different offset of 0x8. Signed-off-by:
Terry Zhou <bjzhou@marvell.com> [pali: Fix pin name in commit message] Signed-off-by:
Pali Rohár <pali@kernel.org> Fixes: 7ea82504 ("clk: mvebu: Add the xtal clock for Armada 3700 SoC") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201106100039.11385-1-pali@kernel.org Reviewed-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Yangtao Li authored
commit a1158e36 upstream. It is found on many allwinner soc that there is a low probability that the interrupt status cannot be read in sunxi_pinctrl_irq_handler. This will cause the interrupt status of a gpio bank to always be active on gic, preventing gic from responding to other spi interrupts correctly. So we should call the chained_irq_* each time enter sunxi_pinctrl_irq_handler(). Signed-off-by:
Yangtao Li <frank@allwinnertech.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/85263ce8b058e80cea25c6ad6383eb256ce96cc8.1604988979.git.frank@allwinnertech.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Zhao Heming authored
commit bca5b065 upstream. md-cluster uses MD_CLUSTER_SEND_LOCK to make node can exclusively send msg. During sending msg, node can concurrently receive msg from another node. When node does resync job, grab token_lockres:EX may trigger a deadlock: ``` nodeA nodeB -------------------- -------------------- a. send METADATA_UPDATED held token_lockres:EX b. md_do_sync resync_info_update send RESYNCING + set MD_CLUSTER_SEND_LOCK + wait for holding token_lockres:EX c. mdadm /dev/md0 --remove /dev/sdg + held reconfig_mutex + send REMOVE + wait_event(MD_CLUSTER_SEND_LOCK) d. recv_daemon //METADATA_UPDATED from A process_metadata_update + (mddev_trylock(mddev) || MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD) //this time, both return false forever ``` Explaination: a. A send METADATA_UPDATED This will block another node to send msg b. B does sync jobs, which will send RESYNCING at intervals. This will be block for holding token_lockres:EX lock. c. B do "mdadm --remove", which will send REMOVE. This will be blocked by step <b>: MD_CLUSTER_SEND_LOCK is 1. d. B recv METADATA_UPDATED msg, which send from A in step <a>. This will be blocked by step <c>: holding mddev lock, it makes wait_event can't hold mddev lock. (btw, MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD keep ZERO in this scenario.) There is a similar deadlock in commit 0ba95977 ("md-cluster: use sync way to handle METADATA_UPDATED msg") In that commit, step c is "update sb". This patch step c is "mdadm --remove". For fixing this issue, we can refer the solution of function: metadata_update_start. Which does the same grab lock_token action. lock_comm can use the same steps to avoid deadlock. By moving MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD from lock_token to lock_comm. It enlarge a little bit window of MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD, but it is safe & can break deadlock. Repro steps (I only triggered 3 times with hundreds tests): two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB. ``` ssh root@node2 "mdadm -S --scan" mdadm -S --scan for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \ count=20; done mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh \ --bitmap-chunk=1M ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh" sleep 5 mkfs.xfs /dev/md0 mdadm --manage --add /dev/md0 /dev/sdi mdadm --wait /dev/md0 mdadm --grow --raid-devices=3 /dev/md0 mdadm /dev/md0 --fail /dev/sdg mdadm /dev/md0 --remove /dev/sdg mdadm --grow --raid-devices=2 /dev/md0 ``` test script will hung when executing "mdadm --remove". ``` # dump stacks by "echo t > /proc/sysrq-trigger" md0_cluster_rec D 0 5329 2 0x80004000 Call Trace: __schedule+0x1f6/0x560 ? _cond_resched+0x2d/0x40 ? schedule+0x4a/0xb0 ? process_metadata_update.isra.0+0xdb/0x140 [md_cluster] ? wait_woken+0x80/0x80 ? process_recvd_msg+0x113/0x1d0 [md_cluster] ? recv_daemon+0x9e/0x120 [md_cluster] ? md_thread+0x94/0x160 [md_mod] ? wait_woken+0x80/0x80 ? md_congested+0x30/0x30 [md_mod] ? kthread+0x115/0x140 ? __kthread_bind_mask+0x60/0x60 ? ret_from_fork+0x1f/0x40 mdadm D 0 5423 1 0x00004004 Call Trace: __schedule+0x1f6/0x560 ? __schedule+0x1fe/0x560 ? schedule+0x4a/0xb0 ? lock_comm.isra.0+0x7b/0xb0 [md_cluster] ? wait_woken+0x80/0x80 ? remove_disk+0x4f/0x90 [md_cluster] ? hot_remove_disk+0xb1/0x1b0 [md_mod] ? md_ioctl+0x50c/0xba0 [md_mod] ? wait_woken+0x80/0x80 ? blkdev_ioctl+0xa2/0x2a0 ? block_ioctl+0x39/0x40 ? ksys_ioctl+0x82/0xc0 ? __x64_sys_ioctl+0x16/0x20 ? do_syscall_64+0x5f/0x150 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 md0_resync D 0 5425 2 0x80004000 Call Trace: __schedule+0x1f6/0x560 ? schedule+0x4a/0xb0 ? dlm_lock_sync+0xa1/0xd0 [md_cluster] ? wait_woken+0x80/0x80 ? lock_token+0x2d/0x90 [md_cluster] ? resync_info_update+0x95/0x100 [md_cluster] ? raid1_sync_request+0x7d3/0xa40 [raid1] ? md_do_sync.cold+0x737/0xc8f [md_mod] ? md_thread+0x94/0x160 [md_mod] ? md_congested+0x30/0x30 [md_mod] ? kthread+0x115/0x140 ? __kthread_bind_mask+0x60/0x60 ? ret_from_fork+0x1f/0x40 ``` At last, thanks for Xiao's solution. Cc: stable@vger.kernel.org Signed-off-by:
Zhao Heming <heming.zhao@suse.com> Suggested-by:
Xiao Ni <xni@redhat.com> Reviewed-by:
-
Zhao Heming authored
commit a8da01f7 upstream. Reshape request should be blocked with ongoing resync job. In cluster env, a node can start resync job even if the resync cmd isn't executed on it, e.g., user executes "mdadm --grow" on node A, sometimes node B will start resync job. However, current update_raid_disks() only check local recovery status, which is incomplete. As a result, we see user will execute "mdadm --grow" successfully on local, while the remote node deny to do reshape job when it doing resync job. The inconsistent handling cause array enter unexpected status. If user doesn't observe this issue and continue executing mdadm cmd, the array doesn't work at last. Fix this issue by blocking reshape request. When node executes "--grow" and detects ongoing resync, it should stop and report error to user. The following script reproduces the issue with ~100% probability. (two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB) ``` # on node1, node2 is the remote node. ssh root@node2 "mdadm -S --scan" mdadm -S --scan for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \ count=20; done mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh" sleep 5 mdadm --manage --add /dev/md0 /dev/sdi mdadm --wait /dev/md0 mdadm --grow --raid-devices=3 /dev/md0 mdadm /dev/md0 --fail /dev/sdg mdadm /dev/md0 --remove /dev/sdg mdadm --grow --raid-devices=2 /dev/md0 ``` Cc: stable@vger.kernel.org Signed-off-by:
-
Jonathan Cameron authored
commit dc7de42d upstream. The comment implies this device has 3 sensor types, but it only has an accelerometer and a gyroscope (both 3D). As such the buffer does not need to be as long as stated. Note I've separated this from the following patch which fixes the alignment for passing to iio_push_to_buffers_with_timestamp() as they are different issues even if they affect the same line of code. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org Signed-off-by:
-
Jonathan Cameron authored
commit 198cf32f upstream. Whilst this is another case of the issue Lars reported with an array of elements of smaller than 8 bytes being passed to iio_push_to_buffers_with_timestamp(), the solution here is a bit different from the other cases and relies on __aligned working on the stack (true since 4.6?) This one is unusual. We have to do an explicit memset() each time as we are reading 3 bytes into a potential 4 byte channel which may sometimes be a 2 byte channel depending on what is enabled. As such, moving the buffer to the heap in the iio_priv structure doesn't save us much. We can't use a nice explicit structure on the stack either as the data channels have different storage sizes and are all separately controlled. Fixes: cc26ad45 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver") Reported-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
-
Jonathan Cameron authored
commit d837a996 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() This data is allocated with kzalloc() so no data can leak apart from previous readings. A local unsigned int variable is used for the regmap call so it is clear there is no potential issue with writing into the padding of the structure. Fixes: 3025c868 ("iio: light: add support for UVIS25 sensor") Reported-by:
Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org Signed-off-by:
-
Jonathan Cameron authored
commit a6181721 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device. The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile. >From personal communications with Mikko: We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles. Fixes: e12ffd24 ("iio: light: rpr0521 triggered buffer") Signed-off-by:
-
Qinglang Miao authored
commit 560c6b91 upstream. Fix the missing clk_disable_unprepare() of info->pclk before return from rockchip_saradc_resume in the error handling case when fails to prepare and enable info->clk. Suggested-by:
Robin Murphy <robin.murphy@arm.com> Fixes: 44d6f2ef ("iio: adc: add driver for Rockchip saradc") Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com Signed-off-by:
-
Nuno Sá authored
commit 19ef7b70 upstream. When updating the buffer demux, we will skip a scan element from the device in the case `in_ind != out_ind` and we enter the while loop. in_ind should only be refreshed with `find_next_bit()` in the end of the loop. Note, to cause problems we need a situation where we are skippig over an element (channel not enabled) that happens to not have the same size as the next element. Whilst this is a possible situation we haven't actually identified any cases in mainline where it happens as most drivers have consistent channel storage sizes with the exception of the timestamp which is the last element and hence never skipped over. Fixes: 5ada4ea9 ("staging:iio: add demux optionally to path from device to buffer") Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20201112144323.28887-1-nuno.sa@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by:
-
James Smart authored
commit e5785d3e upstream. Commit 9816ef6e ("scsi: lpfc: Use after free in lpfc_rq_buf_free()") was made to correct a use after free condition in lpfc_rq_buf_free(). Unfortunately, a subsequent patch cut on a tree without the fix inadvertently reverted the fix. Put the fix back: Move the freeing of the rqb_entry to after the print function that references it. Link: https://lore.kernel.org/r/20201020202719.54726-4-james.smart@broadcom.com Fixes: 411de511 ("scsi: lpfc: Fix RQ empty firmware trap") Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Smart authored
commit 62e3a931 upstream. The following calltrace was seen: BUG: sleeping function called from invalid context at mm/slab.h:494 ... Call Trace: dump_stack+0x9a/0xf0 ___might_sleep.cold.63+0x13d/0x178 slab_pre_alloc_hook+0x6a/0x90 kmem_cache_alloc_trace+0x3a/0x2d0 lpfc_sli4_nvmet_alloc+0x4c/0x280 [lpfc] lpfc_post_rq_buffer+0x2e7/0xa60 [lpfc] lpfc_sli4_hba_setup+0x6b4c/0xa4b0 [lpfc] lpfc_pci_probe_one_s4.isra.15+0x14f8/0x2280 [lpfc] lpfc_pci_probe_one+0x260/0x2880 [lpfc] local_pci_probe+0xd4/0x180 work_for_cpu_fn+0x51/0xa0 process_one_work+0x8f0/0x17b0 worker_thread+0x536/0xb50 kthread+0x30c/0x3d0 ret_from_fork+0x3a/0x50 A prior patch introduced a spin_lock_irqsave(hbalock) in the lpfc_post_rq_buffer() routine. Call trace is seen as the hbalock is held with interrupts disabled during a GFP_KERNEL allocation in lpfc_sli4_nvmet_alloc(). Fix by reordering locking so that hbalock not held when calling sli4_nvmet_alloc() (aka rqb_buf_list()). Link: https://lore.kernel.org/r/20201020202719.54726-2-james.smart@broadcom.com Fixes: 411de511 ("scsi: lpfc: Fix RQ empty firmware trap") Cc: <stable@vger.kernel.org> # v4.17+ Co-developed-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
Praveenkumar I authored
commit bc368602 upstream. After each codeword NAND_FLASH_STATUS is read for possible operational failures. But there is no DMA sync for CPU operation before reading it and this leads to incorrect or older copy of DMA buffer in reg_read_buf. This patch adds the DMA sync on reg_read_buf for CPU before reading it. Fixes: 5bc36b2b ("mtd: rawnand: qcom: check for operation errors in case of raw read") Cc: stable@vger.kernel.org Signed-off-by:
Praveenkumar I <ipkumar@codeaurora.org> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1602230872-25616-1-git-send-email-ipkumar@codeaurora.org Signed-off-by:
-
Sven Eckelmann authored
commit 639a8243 upstream. Some devices (especially QCA ones) are already using hardcoded partition names with colons in it. The OpenMesh A62 for example provides following mtd relevant information via cmdline: root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait The change to split only on the last colon between mtd-id and partitions will cause newpart to see following string for the first partition: KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) Such a partition list cannot be parsed and thus the device fails to boot. Avoid this behavior by making sure that the start of the first part-name ("(") will also be the last byte the mtd-id split algorithm is using for its colon search. Fixes: eb13fa02 ("mtd: parser: cmdline: Support MTD names containing one or more colons") Cc: stable@vger.kernel.org Cc: Ron Minnich <rminnich@google.com> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
Miquel Raynal authored
commit 868cbe2a upstream. So far OOB have never been used in SPI-NAND, add the missing memcpy to make it work properly. Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by:
-
Evan Green authored
commit fc3e62e2 upstream. smp2p_update_bits() should disable interrupts when it acquires its spinlock. This is important because without the _irqsave, a priority inversion can occur. This function is called both with interrupts enabled in qcom_q6v5_request_stop(), and with interrupts disabled in ipa_smp2p_panic_notifier(). IRQ handling of spinlocks should be consistent to avoid the panic notifier deadlocking because it's sitting on the thread that's already got the lock via _request_stop(). Found via lockdep. Cc: stable@vger.kernel.org Fixes: 50e99641 ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point") Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20200929133040.RESEND.1.Ideabf6dcdfc577cf39ce3d95b0e4aa1ac8b38f0c@changeid Signed-off-by:
-
Qinglang Miao authored
commit 702b15cb upstream. Fix the missing clk_disable_unprepare() before return from mt7621_spi_probe in the error handling case. Fixes: cbd66c62 ("spi: mt7621: Move SPI driver out of staging") Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Lukas Wunner authored
commit 5ef76dac upstream. If the calls to devm_platform_ioremap_resource(), irq_of_parse_and_map() or devm_request_irq() fail on probe of the ST SSC4 SPI driver, the runtime PM disable depth is incremented even though it was not decremented before. Fix it. Fixes: cd050abe ("spi: st-ssc4: add missed pm_runtime_disable") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.5+ Cc: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/fbe8768c30dc829e2d77eabe7be062ca22f84024.1604874488.git.lukas@wunner.de Signed-off-by:
-
Lukas Wunner authored
commit 5b8c8846 upstream. If the call to devm_gpiod_get_optional() fails on probe of the NXP SC18IS602/603 SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: f9900801 ("spi: sc18is602: Add reset control via gpio pin.") Signed-off-by:
-
Lukas Wunner authored
commit a4729c35 upstream. If the calls to devm_clk_get(), devm_spi_register_master() or clk_prepare_enable() fail on probe of the Mikrotik RB4xx SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: 05aec357 ("spi: Add SPI driver for Mikrotik RB4xx series boards") Signed-off-by:
-
Lukas Wunner authored
commit c575e911 upstream. If the calls to devm_request_irq() or devm_spi_register_master() fail on probe of the PIC32 SPI driver, the DMA channels requested by pic32_spi_dma_prep() are erroneously not released. Plug the leak. Fixes: 1bcb9f8c ("spi: spi-pic32: Add PIC32 SPI master driver") Signed-off-by:
-
Lukas Wunner authored
commit 373afef3 upstream. davinci_spi_remove() accesses the driver's private data after it's been freed with spi_master_put(). Fix by moving the spi_master_put() to the end of the function. Fixes: fe5fd254 ("spi: davinci: Use dma_request_chan() for requesting DMA channel") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: <stable@vger.kernel.org> # v4.7+ Link: https://lore.kernel.org/r/412f7eb1cf8990e0a3a2153f4c577298deab623e.1607286887.git.lukas@wunner.de Signed-off-by:
-
Lukas Wunner authored
commit e77df3ec upstream. spi_sh_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: 680c1305 ("spi/spi_sh: use spi_unregister_master instead of spi_master_put in remove path") Signed-off-by:
-
Zwane Mwaikambo authored
commit 73b62cdb upstream. I observed this when unplugging a DP monitor whilst a computer is asleep and then waking it up. This left DP chardev nodes still being present on the filesystem and accessing these device nodes caused an oops because drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened. This can also be reproduced by creating a device node with mknod(1) and issuing an open(2) [166164.933198] BUG: kernel NULL pointer dereference, address: 0000000000000018 [166164.933202] #PF: supervisor read access in kernel mode [166164.933204] #PF: error_code(0x0000) - not-present page [166164.933205] PGD 0 P4D 0 [166164.933208] Oops: 0000 [#1] PREEMPT SMP NOPTI [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: G W 5.8.0-rc6+ #1 [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W (1.11 ) 04/21/2020 [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70 [drm_kms_helper] [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7 c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6 <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1 [166164.933236] RSP: 0018:ffffb7d7c41cbbf0 EFLAGS: 00010246 [166164.933237] RAX: 0000000000000000 RBX: ffff8a90001fe900 RCX: 0000000000000000 [166164.933238] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffffc0a40180 [166164.933239] RBP: ffffb7d7c41cbbf8 R08: 0000000000000000 R09: ffff8a93e157d6d0 [166164.933240] R10: 0000000000000000 R11: ffffffffc0a40188 R12: 0000000000000003 [166164.933241] R13: ffff8a9402200e80 R14: ffff8a90001fe900 R15: 0000000000000000 [166164.933244] FS: 00007f7fb041eb00(0000) GS:ffff8a9411500000(0000) knlGS:0000000000000000 [166164.933245] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [166164.933246] CR2: 0000000000000018 CR3: 00000000352c2003 CR4: 00000000003606e0 [166164.933247] Call Trace: [166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper] [166164.933278] chrdev_open+0xa7/0x1c0 [166164.933282] ? cdev_put.part.0+0x20/0x20 [166164.933287] do_dentry_open+0x161/0x3c0 [166164.933291] vfs_open+0x2d/0x30 [166164.933297] path_openat+0xb27/0x10e0 [166164.933306] ? atime_needs_update+0x73/0xd0 [166164.933309] do_filp_open+0x91/0x100 [166164.933313] ? __alloc_fd+0xb2/0x150 [166164.933316] do_sys_openat2+0x210/0x2d0 [166164.933318] do_sys_open+0x46/0x80 [166164.933320] __x64_sys_openat+0x20/0x30 [166164.933328] do_syscall_64+0x52/0xc0 [166164.933336] entry_SYSCALL_64_after_hwframe+0x44/0xa9 (gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29 Dump of assembler code for function drm_dp_aux_dev_get_by_minor: 0x0000000000017b10 <+0>: callq 0x17b15 <drm_dp_aux_dev_get_by_minor+5> 0x0000000000017b15 <+5>: push %rbp 0x0000000000017b16 <+6>: mov %rsp,%rbp 0x0000000000017b19 <+9>: push %r12 0x0000000000017b1b <+11>: mov %edi,%r12d 0x0000000000017b1e <+14>: mov $0x0,%rdi 0x0000000000017b25 <+21>: callq 0x17b2a <drm_dp_aux_dev_get_by_minor+26> 0x0000000000017b2a <+26>: mov %r12d,%esi 0x0000000000017b2d <+29>: mov $0x0,%rdi 0x0000000000017b34 <+36>: callq 0x17b39 <drm_dp_aux_dev_get_by_minor+41> 0x0000000000017b39 <+41>: mov 0x18(%rax),%edx <========= 0x0000000000017b3c <+44>: mov %rax,%r12 0x0000000000017b3f <+47>: lea 0x18(%rax),%rdi 0x0000000000017b43 <+51>: test %edx,%edx 0x0000000000017b45 <+53>: je 0x17b7a <drm_dp_aux_dev_get_by_minor+106> 0x0000000000017b47 <+55>: lea 0x1(%rdx),%ecx 0x0000000000017b4a <+58>: mov %edx,%eax 0x0000000000017b4c <+60>: lock cmpxchg %ecx,(%rdi) 0x0000000000017b50 <+64>: jne 0x17b76 <drm_dp_aux_dev_get_by_minor+102> 0x0000000000017b52 <+66>: test %edx,%edx 0x0000000000017b54 <+68>: js 0x17b6d <drm_dp_aux_dev_get_by_minor+93> 0x0000000000017b56 <+70>: test %ecx,%ecx 0x0000000000017b58 <+72>: js 0x17b6d <drm_dp_aux_dev_get_by_minor+93> 0x0000000000017b5a <+74>: mov $0x0,%rdi 0x0000000000017b61 <+81>: callq 0x17b66 <drm_dp_aux_dev_get_by_minor+86> 0x0000000000017b66 <+86>: mov %r12,%rax 0x0000000000017b69 <+89>: pop %r12 0x0000000000017b6b <+91>: pop %rbp 0x0000000000017b6c <+92>: retq 0x0000000000017b6d <+93>: xor %esi,%esi 0x0000000000017b6f <+95>: callq 0x17b74 <drm_dp_aux_dev_get_by_minor+100> 0x0000000000017b74 <+100>: jmp 0x17b5a <drm_dp_aux_dev_get_by_minor+74> 0x0000000000017b76 <+102>: mov %eax,%edx 0x0000000000017b78 <+104>: jmp 0x17b43 <drm_dp_aux_dev_get_by_minor+51> 0x0000000000017b7a <+106>: xor %r12d,%r12d 0x0000000000017b7d <+109>: jmp 0x17b5a <drm_dp_aux_dev_get_by_minor+74> End of assembler dump. (gdb) list *drm_dp_aux_dev_get_by_minor+0x29 0x17b39 is in drm_dp_aux_dev_get_by_minor (drivers/gpu/drm/drm_dp_aux_dev.c:65). 60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index) 61 { 62 struct drm_dp_aux_dev *aux_dev = NULL; 63 64 mutex_lock(&aux_idr_mutex); 65 aux_dev = idr_find(&aux_idr, index); 66 if (!kref_get_unless_zero(&aux_dev->refcount)) 67 aux_dev = NULL; 68 mutex_unlock(&aux_idr_mutex); 69 (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount $8 = 0x18 Looking at the caller, checks on the minor are pushed down to drm_dp_aux_dev_get_by_minor() static int auxdev_open(struct inode *inode, struct file *file) { unsigned int minor = iminor(inode); struct drm_dp_aux_dev *aux_dev; aux_dev = drm_dp_aux_dev_get_by_minor(minor); <==== if (!aux_dev) return -ENODEV; file->private_data = aux_dev; return 0; } Fixes: e94cb37b ("drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.") Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by:
Zwane Mwaikambo <zwane@yosper.io> Reviewed-by:
Lyude Paul <lyude@redhat.com> [added Cc to stable] Signed-off-by:
-
Dave Kleikamp authored
commit c61b3e48 upstream. Bounds checking tools can flag a bug in dbAdjTree() for an array index out of bounds in dmt_stree. Since dmt_stree can refer to the stree in both structures dmaptree and dmapctl, use the larger array to eliminate the false positive. Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Reported-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com> Signed-off-by:
-
Zhe Li authored
commit 9afc9a8a upstream. The log of this problem is: jffs2: Error garbage collecting node at 0x***! jffs2: No space for garbage collection. Aborting GC thread This is because GC believe that it do nothing, so it abort. After going over the image of jffs2, I find a scene that can trigger this problem stably. The scene is: there is a normal dirent node at summary-area, but abnormal at corresponding not-summary-area with error name_crc. The reason that GC exit abnormally is because it find that abnormal dirent node to GC, but when it goes to function jffs2_add_fd_to_list, it cannot meet the condition listed below: if ((*prev)->nhash == new->nhash && !strcmp((*prev)->name, new->name)) So no node is marked obsolete, statistical information of erase_block do not change, which cause GC exit abnormally. The root cause of this problem is: we do not check the name_crc of the abnormal dirent node with summary is enabled. Noticed that in function jffs2_scan_dirent_node, we use function jffs2_scan_dirty_space to deal with the dirent node with error name_crc. So this patch add a checking code in function read_direntry to ensure the correctness of dirent node. If checked failed, the dirent node will be marked obsolete so GC will pass this node and this problem will be fixed. Cc: <stable@vger.kernel.org> Signed-off-by:
Zhe Li <lizhe67@huawei.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Richard Weinberger authored
commit 20f14311 upstream. Write buffers use a kmalloc()'ed buffer, they can leak up to seven bytes of kernel memory to flash if writes are not aligned. So use ubifs_pad() to fill these gaps with padding bytes. This was never a problem while scanning because the scanner logic manually aligns node lengths and skips over these gaps. Cc: <stable@vger.kernel.org> Fixes: 1e51764a ("UBIFS: add new flash file system") Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by:
-
Steve French authored
commit 7955f105 upstream. In the negotiate protocol preauth context, the server is not required to populate the salt (although it is done by most servers) so do not warn on mount. We retain the checks (warn) that the preauth context is the minimum size and that the salt does not exceed DataLength of the SMB response. Although we use the defaults in the case that the preauth context response is invalid, these checks may be useful in the future as servers add support for additional mechanisms. CC: Stable <stable@vger.kernel.org> Reviewed-by:
Shyam Prasad N <sprasad@microsoft.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
