- Aug 06, 2021
-
-
Desmond Cheong Zhi Xi authored
There is a lock hierarchy of major_names_lock --> mtd_table_mutex. One existing chain is as follows: 1. major_names_lock --> loop_ctl_mutex (when blk_request_module calls loop_probe) 2. loop_ctl_mutex --> bdev->bd_mutex (when loop_control_ioctl calls loop_remove, which then calls del_gendisk) 3. bdev->bd_mutex --> mtd_table_mutex (when blkdev_get_by_dev calls __blkdev_get, which then calls blktrans_open) Since unregister_blkdev grabs the major_names_lock, we need to call it outside the critical section for mtd_table_mutex, otherwise we invert the lock hierarchy. Reported-by:
Hillf Danton <hdanton@sina.com> Signed-off-by:
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210717100719.728829-1-desmondcheongzx@gmail.com
-
Colin Ian King authored
The allocation for cmd is not being kfree'd on the return leading to a memory leak. Fix this by kfree'ing it. Addresses-Coverity: ("Resource leak") Fixes: 88d12502 ("mtd: devices: add support for microchip 48l640 EERAM") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Heiko Schocher <hs@denx.de> Signed-off-by:
-
- Jul 15, 2021
-
-
Andreas Persson authored
Erasing an AMD linear flash card (AM29F016D) crashes after the first sector has been erased. Likewise, writing to it crashes after two bytes have been written. The reason is a missing check for a null pointer - the cmdset_priv field is not set for this type of card. Fixes: 4844ef80 ("mtd: cfi_cmdset_0002: Add support for polling status register") Signed-off-by:
Andreas Persson <andreasp56@outlook.com> Signed-off-by:
-
Michael Walle authored
There are flash drivers which registers the OTP callbacks although the flash doesn't support OTP regions and return -ENODATA for these callbacks if there is no OTP. If this happens, the probe of the whole flash will fail. Fix it by handling the ENODATA return code and skip the OTP region nvmem setup. Fixes: 4b361cfa ("mtd: core: add OTP nvmem provider support") Reported-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Michael Walle <michael@walle.cc> Tested-by:
-
Dan Carpenter authored
Smatch complains that zero length read/writes will lead to an uninitalized return value. I don't know if that's possible, but it's nicer to return a zero literal anyway so let's do that. Fixes: 88d12502 ("mtd: devices: add support for microchip 48l640 EERAM") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
-
Desmond Cheong Zhi Xi authored
Syzbot reported a circular locking dependency: https://syzkaller.appspot.com/bug?id=7bd106c28e846d1023d4ca915718b1a0905444cb This happens because of the following lock dependencies: 1. loop_ctl_mutex -> bdev->bd_mutex (when loop_control_ioctl calls loop_remove, which then calls del_gendisk; this also happens in loop_exit which eventually calls loop_remove) 2. bdev->bd_mutex -> mtd_table_mutex (when blkdev_get_by_dev calls __blkdev_get, which then calls blktrans_open) 3. mtd_table_mutex -> major_names_lock (when register_mtd_blktrans calls __register_blkdev) 4. major_names_lock -> loop_ctl_mutex (when blk_request_module calls loop_probe) Hence there's an overall dependency of: loop_ctl_mutex ----------> bdev->bd_mutex ^ | | | | v major_names_lock <--------- mtd_table_mutex We can break this circular dependency by holding mtd_table_mutex only for the required critical section in register_mtd_blktrans. This avoids the mtd_table_mutex -> major_names_lock dependency. Reported-and-tested-by:
<syzbot+6a8a0d93c91e8fbf2e80@syzkaller.appspotmail.com> Co-developed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Dan Carpenter authored
Check for whether of_property_count_elems_of_size() returns a negative error code. Fixes: 13b89768 ("mtd: rawnand: Add support for secure regions in NAND memory") Signed-off-by:
Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
-
Zhihao Cheng authored
Since commit b35fd742("block: check queue's limits.discard_granularity in __blkdev_issue_discard()") checks rq.limits.discard_granularity in __blkdev_issue_discard(), we may get following warnings on formatted ftl: WARNING: CPU: 2 PID: 7313 at block/blk-lib.c:51 __blkdev_issue_discard+0x2a7/0x390 Reproducer: 1. ftl_format /dev/mtd0 2. modprobe ftl 3. mkfs.vfat /dev/ftla 4. mount -odiscard /dev/ftla temp 5. dd if=/dev/zero of=temp/tst bs=1M count=10 oflag=direct 6. dd if=/dev/zero of=temp/tst bs=1M count=10 oflag=direct Fix it by initializing rq.limits.discard_granularity if device supports discard operation. Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by:
-
- Jul 10, 2021
-
-
Alexandre Belloni authored
arch/arm/mach-ixp4xx/include/mach/platform.h now gets included indirectly and defines REG_OFFSET. Rename the register and bit definition to something specific to the driver. Fixes: 7fd70c65 ("ARM: irqstat: Get rid of duplicated declaration") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210710211431.1393589-1-alexandre.belloni@bootlin.com
-
Mian Yousaf Kaukab authored
commit 03623b4b ("rtc: pcf2127: add tamper detection support") added support for timestamp interrupts. However they are not being handled in the irq handler. If a timestamp interrupt occurs it results in kernel disabling the interrupt and displaying the call trace: [ 121.145580] irq 78: nobody cared (try booting with the "irqpoll" option) ... [ 121.238087] [<00000000c4d69393>] irq_default_primary_handler threaded [<000000000a90d25b>] pcf2127_rtc_irq [rtc_pcf2127] [ 121.248971] Disabling IRQ #78 Handle timestamp interrupts in pcf2127_rtc_irq(). Save time stamp before clearing TSF1 and TSF2 flags so that it can't be overwritten. Set a flag to mark if the timestamp is valid and only report to sysfs if the flag is set. To mimic the hardware behavior, don’t save another timestamp until the first one has been read by the userspace. However, if the alarm irq is not configured, keep the old way of handling timestamp interrupt in the timestamp0 sysfs calls. Signed-off-by:
Mian Yousaf Kaukab <ykaukab@suse.de> Reviewed-by:
Bruno Thomsen <bruno.thomsen@gmail.com> Tested-by:
-
Nobuhiro Iwamatsu authored
The offset variable is checked by at91_rtc_readalarm(), but this check is unnecessary because the previous check knew that the value of this variable was not 0. This removes that unnecessary offset variable checks. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
s5m_check_peding_alarm_interrupt() in s5m_rtc_read_alarm() gets the return value, but doesn't use it. This modifies using the s5m_check_peding_alarm_interrupt()"s return value as the s5m_rtc_read_alarm()'s return value. Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
- Jul 09, 2021
-
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Nobuhiro Iwamatsu authored
For C files, use the C99 format (//). Signed-off-by:
-
Nobuhiro Iwamatsu authored
For C files, use the C99 format (//). Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang7@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Bjorn Helgaas authored
This reverts commit 65db0405. Guenter reported that after 65db0405, the ppc:sam460ex qemu emulation no longer boots from nvme: nvme nvme0: Device not ready; aborting initialisation, CSTS=0x0 nvme nvme0: Removing after probe failure status: -19 Link: https://lore.kernel.org/r/20210709231529.GA3270116@roeck-us.net Reported-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Fabio Estevam authored
After updating the datasheet URL, the PCF85063A datasheet revision has changed. Adjust it accordingly. Reported-by:
Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by:
-
Marc Zyngier authored
Since d4a45c68 ("irqdomain: Protect the linear revmap with RCU"), any irqdomain lookup requires the RCU read lock to be held. This assumes that the architecture code will be structured such as irq_enter() will be called *before* the interrupt is looked up in the irq domain. However, this isn't the case for MIPS, and a number of drivers are structured to do it the other way around when handling an interrupt in their root irqchip (secondary irqchips are OK by construction). This results in a RCU splat on a lockdep-enabled kernel when the kernel takes an interrupt from idle, as reported by Guenter Roeck. Note that this could have fired previously if any driver had used tree-based irqdomain, which always had the RCU requirement. To solve this, provide a MIPS-specific helper (do_domain_IRQ()) as the pendent of do_IRQ() that will do thing in the right order (and maybe save some cycles in the process). Ideally, MIPS would be moved over to using handle_domain_irq(), but that's much more ambitious. Reported-by:
Marc Zyngier <maz@kernel.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20210705172352.GA56304@roeck-us.net Link: https://lore.kernel.org/r/20210706110647.3979002-1-maz@kernel.org
-
- Jul 08, 2021
-
-
Harald Freudenberger authored
Rework of the ap_dqap() inline function with the dqap inline assembler invocation and the caller code in ap_queue.c to be able to handle replies which exceed the receive buffer size. ap_dqap() now provides two additional parameters to handle together with the caller the case where a reply in the firmware queue entry exceeds the given message buffer size. It depends on the caller how to exactly handle this. The behavior implemented now by ap_sm_recv() in ap_queue.c is to simple purge this entry from the firmware queue and let the caller 'receive' a -EMSGSIZE for the request without delivering any reply data - not even a truncated reply message. However, the reworked ap_dqap() could now get invoked in a way that the message is received in multiple parts and the caller assembles the parts into one reply message. Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Suggested-by:
Juergen Christ <jchrist@linux.ibm.com> Reviewed-by:
Vasily Gorbik <gor@linux.ibm.com>
-
David Hildenbrand authored
Let's handle unplug in Big Block Mode similar to Sub Block Mode -- prioritize memory blocks onlined to ZONE_MOVABLE. We won't care further about big blocks with mixed zones, as it's rather a corner case that won't matter in practice. Signed-off-by:
David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20210602185720.31821-8-david@redhat.com Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
David Hildenbrand authored
Let's simplify high-level big block selection when unplugging in Big Block Mode. Combine handling of offline and online blocks. We can get rid of virtio_mem_bbm_bb_is_offline() and simply use virtio_mem_bbm_offline_remove_and_unplug_bb(), as that already tolerates offline parts. We can race with concurrent onlining/offlining either way, so we don;t have to be super correct by failing if an offline big block we'd like to unplug just got (partially) onlined. Signed-off-by:
-
David Hildenbrand authored
Until now, memory provided by a single virtio-mem device was usually either onlined completely to ZONE_MOVABLE (online_movable) or to ZONE_NORMAL (online_kernel); however, that will change in the future. There are two reasons why we want to track to which zone a memory blocks belongs to and prioritize ZONE_MOVABLE blocks: 1) Memory managed by ZONE_MOVABLE can more likely get unplugged, therefore, resulting in a faster memory hotunplug process. Further, we can more reliably unplug and remove complete memory blocks, removing metadata allocated for the whole memory block. 2) We want to avoid corner cases where unplugging with the current scheme (highest to lowest address) could result in accidential zone imbalances, whereby we remove too much ZONE_NORMAL memory for ZONE_MOVABLE memory of the same device. Let's track the zone via memory block states and try unplug from ZONE_MOVABLE first. Rename VIRTIO_MEM_SBM_MB_ONLINE* to VIRTIO_MEM_SBM_MB_KERNEL* to avoid even longer state names. In commit 27f85279 ("virtio-mem: don't special-case ZONE_MOVABLE"), we removed slightly similar tracking for fully plugged memory blocks to support unplugging from ZONE_MOVABLE at all -- as we didn't allow partially plugged memory blocks in ZONE_MOVABLE before that. That commit already mentioned "In the future, we might want to remember the zone again and use the information when (un)plugging memory." Signed-off-by:
-
David Hildenbrand authored
Let's simplify by introducing a new virtio_mem_sbm_unplug_any_sb(), similar to virtio_mem_sbm_plug_any_sb(), to simplify high-level memory block selection when unplugging in Sub Block Mode. Rename existing virtio_mem_sbm_unplug_any_sb() to virtio_mem_sbm_unplug_any_sb_raw(). The only change is that we now temporarily unlock the hotplug mutex around cond_resched() when processing offline memory blocks, which doesn't make a real difference as we already have to temporarily unlock in virtio_mem_sbm_unplug_any_sb_offline() when removing a memory block. Signed-off-by:
-
David Hildenbrand authored
Let's simplify high-level memory block selection when plugging in Sub Block Mode. No need for two separate loops when selecting memory blocks for plugging memory. Avoid passing the "online" state by simply obtaining the state in virtio_mem_sbm_plug_any_sb(). Signed-off-by:
-
David Hildenbrand authored
Let's use page_zonenum() instead of zone_idx(page_zone()). Signed-off-by:
-
David Hildenbrand authored
We are reading a Big Block Mode value while in Sub Block Mode when initializing. Fortunately, vm->bbm.bb_size maps to some counter in the vm->sbm.mb_count array, which is 0 at that point in time. No harm done; still, this was unintended and is not future-proof. Fixes: 4ba50cd3 ("virtio-mem: Big Block Mode (BBM) memory hotplug") Signed-off-by:
-
Eli Cohen authored
Clear the available index as part of the initialization process to clear and values that might be left from previous usage of the device. For example, if the device was previously used by vhost_vdpa and now probed by vhost_vdpa, you want to start with indices. Fixes: c043b4a8 ("virtio: introduce a vDPA based transport") Signed-off-by:
Eli Cohen <elic@nvidia.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20210602021536.39525-5-jasowang@redhat.com Signed-off-by:
-
Jason Wang authored
We used to fail the set_vq_state() since it was not supported yet by the virtio spec. But if the bus tries to set the state which is equal to the device initial state after reset, we can let it go. This is a must for virtio_vdpa() to set vq state during probe which is required for some vDPA parents. Signed-off-by:
-
Jason Wang authored
This patch introduce a helper to get driver/guest features from the device. Signed-off-by:
-
Jason Wang authored
This patch extends the vdpa_vq_state to support packed virtqueue state which is basically the device/driver ring wrap counters and the avail and used index. This will be used for the virito-vdpa support for the packed virtqueue and the future vhost/vhost-vdpa support for the packed virtqueue. Signed-off-by:
-
Jason Wang authored
For split virtqueue, we used to depend on the address, length and flags stored in the descriptor ring for DMA unmapping. This is unsafe for the case since the device can manipulate the behavior of virtio driver, IOMMU drivers and swiotlb. For safety, maintain the DMA address, DMA length, descriptor flags and next filed of the non indirect descriptors in vring_desc_state_extra when DMA API is used for virtio as we did for packed virtqueue and use those metadata for performing DMA operations. Indirect descriptors should be safe since they are using streaming mappings. With this the descriptor ring is write only form the view of the driver. This slight increase the footprint of the drive but it's not noticed through pktgen (64B) test and netperf test in the case of virtio-net. Signed-off-by:
-
Jason Wang authored
Using error label for unwind in __vring_new_virtqueue. This is useful for future refacotring. Signed-off-by:
-
Jason Wang authored
This patch introduces a helper for storing descriptor in the descriptor table for split virtqueue. Signed-off-by:
-
Jason Wang authored
We should not depend on the DMA address, length and flag of descriptor table since they could be wrote with arbitrary value by the device. So this patch switches to use the stored one in desc_extra. Note that the indirect descriptors are fine since they are read-only streaming mappings. Signed-off-by:
-
