| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In the error handling path `out_acc` of `ubi_resize_volume()`,
when `pebs < 0`, it indicates that the volume table record failed to
update when the volume was shrunk. In this case, the number of `ubi->avail_pebs`
and `ubi->rsvd_pebs` should be restored to their previous values to prevent
the UBI layer from reporting an incorrect number of available PEBs.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
When using the ioctl interface to resize a UBI volume, `ubi_resize_volume`
resizes the EBA table first but does not change `vol->reserved_pebs` in
the same atomic context, which may cause concurrent access to the EBA table.
For example, when a user shrinks UBI volume A by calling `ubi_resize_volume`,
while another thread is writing to volume B and triggering wear-leveling,
which may call `ubi_write_fastmap`, under these circumstances, KASAN may
report a slab-out-of-bounds error in `ubi_eba_get_ldesc+0xfb/0x130`.
This patch fixes race conditions in `ubi_resize_volume` and
`ubi_update_fastmap` to avoid out-of-bounds reads of `eba_tbl`. First,
it ensures that updates to `eba_tbl` and `reserved_pebs` are protected
by `vol->volumes_lock`. Second, it implements a rollback mechanism in case
of resize failure. It is also worth mentioning that for volume shrinkage
failures, since part of the volume has already been shrunk and unmapped,
there is no need to recover `{rsvd/avail}_pebs`.
==================================================================
BUG: KASAN: slab-out-of-bounds in ubi_eba_get_ldesc+0xfb/0x130 [ubi]
Read of size 4 at addr ffff88800f43f570 by task kworker/u16:0/7
CPU: 0 PID: 7 Comm: kworker/u16:0 Not tainted 5.16.0-rc7 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: writeback wb_workfn (flush-ubifs_0_0)
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x66
print_address_description.constprop.0+0x41/0x60
kasan_report.cold+0x83/0xdf
ubi_eba_get_ldesc+0xfb/0x130 [ubi]
ubi_update_fastmap.cold+0x60f/0xc7d [ubi]
ubi_wl_get_peb+0x25b/0x4f0 [ubi]
try_write_vid_and_data+0x9a/0x4d0 [ubi]
ubi_eba_write_leb+0x7e4/0x17d0 [ubi]
ubi_leb_map+0x1a0/0x2c0 [ubi]
ubifs_leb_map+0x139/0x270 [ubifs]
ubifs_add_bud_to_log+0xb40/0xf30 [ubifs]
make_reservation+0x86e/0xb00 [ubifs]
ubifs_jnl_write_data+0x430/0x9d0 [ubifs]
do_writepage+0x1d1/0x550 [ubifs]
ubifs_writepage+0x37c/0x670 [ubifs]
__writepage+0x67/0x170
write_cache_pages+0x259/0xa90
do_writepages+0x277/0x5d0
__writeback_single_inode+0xb8/0x850
writeback_sb_inodes+0x4b3/0xb20
__writeback_inodes_wb+0xc1/0x220
wb_writeback+0x59f/0x740
wb_workfn+0x6d0/0xca0
process_one_work+0x711/0xfc0
worker_thread+0x95/0xd00
kthread+0x3a6/0x490
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 711:
kasan_save_stack+0x1e/0x50
__kasan_kmalloc+0x81/0xa0
ubi_eba_create_table+0x88/0x1a0 [ubi]
ubi_resize_volume.cold+0x175/0xae7 [ubi]
ubi_cdev_ioctl+0x57f/0x1a60 [ubi]
__x64_sys_ioctl+0x13a/0x1c0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Last potentially related work creation:
kasan_save_stack+0x1e/0x50
__kasan_record_aux_stack+0xb7/0xc0
call_rcu+0xd6/0x1000
blk_stat_free_callback+0x28/0x30
blk_release_queue+0x8a/0x2e0
kobject_put+0x186/0x4c0
scsi_device_dev_release_usercontext+0x620/0xbd0
execute_in_process_context+0x2f/0x120
device_release+0xa4/0x240
kobject_put+0x186/0x4c0
put_device+0x20/0x30
__scsi_remove_device+0x1c3/0x300
scsi_probe_and_add_lun+0x2140/0x2eb0
__scsi_scan_target+0x1f2/0xbb0
scsi_scan_channel+0x11b/0x1a0
scsi_scan_host_selected+0x24c/0x310
do_scsi_scan_host+0x1e0/0x250
do_scan_async+0x45/0x490
async_run_entry_fn+0xa2/0x530
process_one_work+0x711/0xfc0
worker_thread+0x95/0xd00
kthread+0x3a6/0x490
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88800f43f500
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 112 bytes inside of
128-byte region [ffff88800f43f500, ffff88800f43f580)
The buggy address belongs to the page:
page:ffffea00003d0f00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xf43c
head:ffffea00003d0f00 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 001fffff80010200 ffffea000046ba08 ffffea0000457208 ffff88810004d1c0
raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88800f43f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800f43f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88800f43f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc
^
ffff88800f43f580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800f43f600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
The following steps can used to reproduce:
Process 1: write and trigger ubi wear-leveling
ubimkvol /dev/ubi0 -s 5000MiB -N v1
ubimkvol /dev/ubi0 -s 2000MiB -N v2
ubimkvol /dev/ubi0 -s 10MiB -N v3
mount -t ubifs /dev/ubi0_0 /mnt/ubifs
while true;
do
filename=/mnt/ubifs/$((RANDOM))
dd if=/dev/random of=${filename} bs=1M count=$((RANDOM % 1000))
rm -rf ${filename}
sync /mnt/ubifs/
done
Process 2: do random resize
struct ubi_rsvol_req req;
req.vol_id = 1;
req.bytes = (rand() % 50) * 512KB;
ioctl(fd, UBI_IOCRSVOL, &req);
V3:
- Fix the commit message error.
V2:
- Add volumes_lock in ubi_eba_copy_leb() to avoid race caused by
updating eba_tbl.
V1:
- Rebase the patch on the latest mainline.
Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
Now that the calculation of fastmap size in ubi_calc_fm_size() is
incorrect since it miss each user volume's ubi_fm_eba structure and the
Internal UBI volume info. Let's correct the calculation.
Cc: stable@vger.kernel.org
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
If the LEB size is smaller than a volume table record we cannot
have volumes.
In this case abort attaching.
Cc: Chenyuan Yang <cy54@illinois.edu>
Cc: stable@vger.kernel.org
Fixes: 801c135ce73d ("UBI: Unsorted Block Images")
Reported-by: Chenyuan Yang <cy54@illinois.edu>
Closes: https://lore.kernel.org/linux-mtd/1433EB7A-FC89-47D6-8F47-23BE41B263B3@illinois.edu/
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
|
|
Link: https://lore.kernel.org/r/20240123-vfs-bdev-file-v2-14-adbd023e19cc@kernel.org
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
Pass the few limits ubiblock imposes directly to blk_mq_alloc_disk
instead of setting them one at a time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240215070300.2200308-15-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Pass the few limits mtd_blkdevs imposes directly to blk_mq_alloc_disk
instead of setting them one at a time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20240215070300.2200308-14-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Pass a queue_limits to blk_mq_alloc_disk and apply it if non-NULL. This
will allow allocating queues with valid queue limits instead of setting
the values one at a time later.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20240213073425.1621680-11-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/38bf50b391c117621e406fa8cd00c4daef78615c.1707324794.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The check in nand_base.c, nand_scan_tail() : has the following code:
(ecc->steps * ecc->size != mtd->writesize) which fails for some NAND chips.
Remove ECC entries in this driver which are not integral multiplications,
and adjust the number of chunks for entries which fails the above
calculation so it will calculate correctly (this was previously done
automatically before the check and was removed in a later commit).
Fixes: 68c18dae6888 ("mtd: rawnand: marvell: add missing layouts")
Cc: stable@vger.kernel.org
Signed-off-by: Elad Nachman <enachman@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
According to the datasheets, the ESMT chips in question will return a 5
byte long identification code where the last 3 bytes are the JEDEC
continuation codes (7Fh). Although, I would have expected 4 continuation
codes as Powerchip Semiconductor (C8h, corresponding to the parameter
page data) is located in bank 5 of the JEDEC database.
By matching the full 5 bytes we can avoid clashes with GigaDevice NAND
flashes.
This fix allows the MT7688-based GARDENA smart Gateway to boot again.
Fixes: aa08bf187f32 ("mtd: spinand: esmt: add support for F50D2G41KA")
Signed-off-by: Ezra Buehler <ezra.buehler@husqvarnagroup.com>
Reviewed-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
Tested-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-3-ezra@easyb.ch
|
|
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/b7ee7d1b-49a2-41d8-9c8f-3674f1aecc43@web.de
|
|
Replace eight space characters by one tab.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/4045abdd-fb88-4c1f-a947-cdb3d4e59aa6@web.de
|
|
The kfree() function was called in one case by
the ssfdcr_add_mtd() function during error handling
even if the passed data structure member contained a null pointer.
This issue was detected by using the Coccinelle software.
Thus use another label.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/56d92e42-db9e-4767-bcb1-9686bdf34a03@web.de
|
|
If during probe fsl_lbc_ctrl_dev is NULL that might just be because the
fsl_lbc driver didn't bind yet. So return -EPROBE_DEFER in this case to
make the driver core retry probing later.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240115141245.3415035-2-u.kleine-koenig@pengutronix.de
|
|
Add support for W25N04KV.
W25N04KV has 8-bit on-die ECC.
Signed-off-by: Zhi-Jun You <hujy652@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240107144120.532-1-hujy652@gmail.com
|
|
Under normal conditions, the loop goes over all child partitions, and
'breaks' when the relevant partition is found. In this case we get a
reference to the partition node without ever releasing it. Indeed, right
after the mtd_check_of_node() function returns, we call of_node_get()
again over this very same node. It is probably safer to keep the
counters even in this helper and call of_node_put() before break-ing.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/r/202312250546.ISzglvM2-lkp@intel.com/
Cc: Christian Marangi <ansuelsmth@gmail.com>
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240104081446.126540-1-miquel.raynal@bootlin.com
|
|
Some GigaDevice ecc_get_status functions use on-stack buffer for
spi_mem_op causes spi_mem_check_op failing, fix the issue by using
spinand scratchbuf.
Fixes: c40c7a990a46 ("mtd: spinand: Add support for GigaDevice GD5F1GQ4UExxG")
Signed-off-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231108150701.593912-1-han.xu@nxp.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs
Pull UBI and UBIFS updates from Richard Weinberger:
"UBI:
- Use in-tree fault injection framework and add new injection types
- Fix for a memory leak in the block driver
UBIFS:
- kernel-doc fixes
- Various minor fixes"
* tag 'ubifs-for-linus-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs:
ubi: block: fix memleak in ubiblock_create()
ubifs: fix kernel-doc warnings
mtd: Add several functions to the fail_function list
ubi: Reserve sufficient buffer length for the input mask
ubi: Add six fault injection type for testing
ubi: Split io_failures into write_failure and erase_failure
ubi: Use the fault injection framework to enhance the fault injection capability
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
ubifs: Check @c->dirty_[n|p]n_cnt and @c->nroot state under @c->lp_mutex
ubifs: describe function parameters
ubifs: auth.c: fix kernel-doc function prototype warning
ubifs: use crypto_shash_tfm_digest() in ubifs_hmac_wkm()
|
|
Pull block updates from Jens Axboe:
"Pretty quiet round this time around. This contains:
- NVMe updates via Keith:
- nvme fabrics spec updates (Guixin, Max)
- nvme target udpates (Guixin, Evan)
- nvme attribute refactoring (Daniel)
- nvme-fc numa fix (Keith)
- MD updates via Song:
- Fix/Cleanup RCU usage from conf->disks[i].rdev (Yu Kuai)
- Fix raid5 hang issue (Junxiao Bi)
- Add Yu Kuai as Reviewer of the md subsystem
- Remove deprecated flavors (Song Liu)
- raid1 read error check support (Li Nan)
- Better handle events off-by-1 case (Alex Lyakas)
- Efficiency improvements for passthrough (Kundan)
- Support for mapping integrity data directly (Keith)
- Zoned write fix (Damien)
- rnbd fixes (Kees, Santosh, Supriti)
- Default to a sane discard size granularity (Christoph)
- Make the default max transfer size naming less confusing
(Christoph)
- Remove support for deprecated host aware zoned model (Christoph)
- Misc fixes (me, Li, Matthew, Min, Ming, Randy, liyouhong, Daniel,
Bart, Christoph)"
* tag 'for-6.8/block-2024-01-08' of git://git.kernel.dk/linux: (78 commits)
block: Treat sequential write preferred zone type as invalid
block: remove disk_clear_zoned
sd: remove the !ZBC && blk_queue_is_zoned case in sd_read_block_characteristics
drivers/block/xen-blkback/common.h: Fix spelling typo in comment
blk-cgroup: fix rcu lockdep warning in blkg_lookup()
blk-cgroup: don't use removal safe list iterators
block: floor the discard granularity to the physical block size
mtd_blkdevs: use the default discard granularity
bcache: use the default discard granularity
zram: use the default discard granularity
null_blk: use the default discard granularity
nbd: use the default discard granularity
ubd: use the default discard granularity
block: default the discard granularity to sector size
bcache: discard_granularity should not be smaller than a sector
block: remove two comments in bio_split_discard
block: rename and document BLK_DEF_MAX_SECTORS
loop: don't abuse BLK_DEF_MAX_SECTORS
aoe: don't abuse BLK_DEF_MAX_SECTORS
null_blk: don't cap max_hw_sectors to BLK_DEF_MAX_SECTORS
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd updates from Miquel Raynal:
"MTD:
- Apart from preventing the mtdblk to run on top of ftl or ubiblk
(which may cause security issues and has no meaning anyway), there
are a few misc fixes.
Raw NAND:
- Two meaningful changes this time. The conversion of the brcmnand
driver to the ->exec_op() API, this series brought additional
changes to the core in order to help controller drivers to handle
themselves the WP pin during destructive operations when relevant.
- There is also a series bringing important fixes to the sequential
read feature.
- As always, there is as well a whole bunch of miscellaneous W=1
fixes, together with a few runtime fixes (double free, timeout
value, OOB layout, missing register initialization) and the usual
load of remove callbacks turned into void (which led to switch the
txx9ndfmc driver to use module_platform_driver()).
SPI NOR:
- SPI NOR comes with die erase support for multi die flashes, with
new octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an
updated documentation about what the contributors shall consider
when proposing flash additions or updates.
- Michael Walle stepped out from the reviewer role to maintainer"
* tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (39 commits)
mtd: rawnand: Clarify conditions to enable continuous reads
mtd: rawnand: Prevent sequential reads with on-die ECC engines
mtd: rawnand: Fix core interference with sequential reads
mtd: rawnand: Prevent crossing LUN boundaries during sequential reads
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
dt-bindings: mtd: partitions: u-boot: Fix typo
mtd: rawnand: s3c2410: fix Excess struct member description kernel-doc warnings
MAINTAINERS: change my mail to the kernel.org one
mtd: spi-nor: sfdp: get the 1-1-8 and 1-8-8 protocol from SFDP
mtd: spi-nor: drop superfluous debug prints
mtd: spi-nor: sysfs: hide the flash name if not set
mtd: spi-nor: mark the flash name as obsolete
mtd: spi-nor: print flash ID instead of name
mtd: maps: vmu-flash: Fix the (mtd core) switch to ref counters
mtd: ssfdc: Remove an unused variable
mtd: rawnand: diskonchip: fix a potential double free in doc_probe
mtd: rawnand: rockchip: Add missing title to a kernel doc comment
mtd: rawnand: rockchip: Rename a structure
mtd: rawnand: pl353: Fix kernel doc
mtd: spi-nor: micron-st: Add support for mt25qu01g
...
|
|
If idr_alloc() fails, dev->gd will be put after goto out_cleanup_disk in
ubiblock_create(), but dev->gd has not been assigned yet at this time, and
'gd' will not be put anymore. Fix it by putting 'gd' directly.
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
add mtd_read(), mtd_write(), mtd_erase(), mtd_block_markbad() to
fail_function list for testing purpose
- Specify the function to inject the fault
echo mtd_read > /sys/kernel/debug/fail_function/inject
- Specifies the return value of the function to inject the fault
printf %#x -12 > /sys/kernel/debug/fail_function/mtd_read/retval
- Specify other fault injection configuration parameters.
echo -1 > /sys/kernel/debug/fail_function/times
echo 100 > /sys/kernel/debug/fail_function/probability
echo 15 > /sys/kernel/debug/fail_function/space
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
Because the mask received by the emulate_failures interface
is a 32-bit unsigned integer, ensure that there is sufficient
buffer length to receive and display this value.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This commit adds six fault injection type for testing to cover the
abnormal path of the UBI driver.
Inject the following faults when the UBI reads the LEB:
+----------------------------+-----------------------------------+
| Interface name | emulate behavior |
+----------------------------+-----------------------------------+
| emulate_eccerr | ECC error |
+----------------------------+-----------------------------------+
| emulate_read_failure | read failure |
|----------------------------+-----------------------------------+
| emulate_io_ff | read content as all FF |
|----------------------------+-----------------------------------+
| emulate_io_ff_bitflips | content FF with MTD err reported |
+----------------------------+-----------------------------------+
| emulate_bad_hdr | bad leb header |
|----------------------------+-----------------------------------+
| emulate_bad_hdr_ebadmsg | bad header with ECC err |
+----------------------------+-----------------------------------+
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
The emulate_io_failures debugfs entry controls both write
failure and erase failure. This patch split io_failures
to write_failure and erase_failure.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
To make debug parameters configurable at run time, use the
fault injection framework to reconstruct the debugfs interface,
and retain the legacy fault injection interface.
Now, the file emulate_failures and fault_attr files control whether
to enable fault emmulation.
The file emulate_failures receives a mask that controls type and
process of fault injection. Generally, for ease of use, you can
directly enter a mask with all 1s.
echo 0xffff > /sys/kernel/debug/ubi/ubi0/emulate_failures
And you need to configure other fault-injection capabilities for
testing purpose:
echo 100 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/probability
echo 15 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/space
echo 2 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/verbose
echo -1 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/times
The CONFIG_MTD_UBI_FAULT_INJECTION to enable the Fault Injection is
added to kconfig.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
The discard granularity now defaults to a single sector, so don't set
that value explicitly.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Richard Weinberger <richard@nod.at>
Link: https://lore.kernel.org/r/20231228075545.362768-10-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
* Raw NAND
The most meaningful change being the conversion of the brcmnand driver
to the ->exec_op() API, this series brought additional changes to the
core in order to help controller drivers to handle themselves the WP pin
during destructive operations when relevant.
As always, there is as well a whole bunch of miscellaneous W=1 fixes,
together with a few runtime fixes (double free, timeout value, OOB
layout, missing register initialization) and the usual load of remove
callbacks turned into void (which led to switch the txx9ndfmc driver to
use module_platform_driver()).
|
|
SPI NOR comes with die erase support for multi die flashes, with new
octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an updated
documentation about what the contributors shall consider when proposing
flash additions or updates. Michael Walle stepped out from the reviewer
role to maintainer.
|
|
The current logic is probably fine but is a bit convoluted. Plus, we
don't want partial pages to be part of the sequential operation just in
case the core would optimize the page read with a subpage read (which
would break the sequence). This may happen on the first and last page
only, so if the start offset or the end offset is not aligned with a
page boundary, better avoid them to prevent any risk.
Cc: stable@vger.kernel.org
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-5-miquel.raynal@bootlin.com
|
|
Some devices support sequential reads when using the on-die ECC engines,
some others do not. It is a bit hard to know which ones will break other
than experimentally, so in order to avoid such a difficult and painful
task, let's just pretend all devices should avoid using this
optimization when configured like this.
Cc: stable@vger.kernel.org
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-4-miquel.raynal@bootlin.com
|
|
A couple of reports pointed at some strange failures happening a bit
randomly since the introduction of sequential page reads support. After
investigation it turned out the most likely reason for these issues was
the fact that sometimes a (longer) read might happen, starting at the
same page that was read previously. This is optimized by the raw NAND
core, by not sending the READ_PAGE command to the NAND device and just
reading out the data in a local cache. When this page is also flagged as
being the starting point for a sequential read, it means the page right
next will be accessed without the right instructions. The NAND chip will
be confused and will not output correct data. In order to avoid such
situation from happening anymore, we can however handle this case with a
bit of additional logic, to postpone the initialization of the read
sequence by one page.
Reported-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Closes: https://lore.kernel.org/linux-mtd/CAP1tNvS=NVAm-vfvYWbc3k9Cx9YxMc2uZZkmXk8h1NhGX877Zg@mail.gmail.com/
Reported-by: Måns Rullgård <mans@mansr.com>
Closes: https://lore.kernel.org/linux-mtd/yw1xfs6j4k6q.fsf@mansr.com/
Reported-by: Martin Hundebøll <martin@geanix.com>
Closes: https://lore.kernel.org/linux-mtd/9d0c42fcde79bfedfe5b05d6a4e9fdef71d3dd52.camel@geanix.com/
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-3-miquel.raynal@bootlin.com
|
|
The ONFI specification states that devices do not need to support
sequential reads across LUN boundaries. In order to prevent such event
from happening and possibly failing, let's introduce the concept of
"pause" in the sequential read to handle these cases. The first/last
pages remain the same but any time we cross a LUN boundary we will end
and restart (if relevant) the sequential read operation.
Cc: stable@vger.kernel.org
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-2-miquel.raynal@bootlin.com
|
|
If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
‘gluebi->desc’ in gluebi_read().
ubi_gluebi_init
ubi_register_volume_notifier
ubi_enumerate_volumes
ubi_notify_all
gluebi_notify nb->notifier_call()
gluebi_create
mtd_device_register
mtd_device_parse_register
add_mtd_device
blktrans_notify_add not->add()
ftl_add_mtd tr->add_mtd()
scan_header
mtd_read
mtd_read_oob
mtd_read_oob_std
gluebi_read mtd->read()
gluebi->desc - NULL
Detailed reproduction information available at the Link [1],
In the normal case, obtain gluebi->desc in the gluebi_get_device(),
and access gluebi->desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.
The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.
Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1]
Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@nod.at/ [2]
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@huawei.com
|
|
Delete 2 lines to prevent warnings from scripts/kernel-doc:
s3c2410.c:117: warning: Excess struct member 'mtd' description in 's3c2410_nand_mtd'
s3c2410.c:168: warning: Excess struct member 'freq_transition' description in 's3c2410_nand_info'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312150611.EZBAQYqf-lkp@intel.com/
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: linux-mtd@lists.infradead.org
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231216044146.18645-1-rdunlap@infradead.org
|
|
BFPT 17th DWORD contains the information about 1-1-8 and 1-8-8.
Parse BFPT DWORD[17] instruction to determine whether flash
supports 1-1-8 and 1-8-8, and set its dummy cycles accordingly.
Validated only the 1-1-8 read using a macronix flash with
Xilinx board zynq-picozed.
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20231219102103.92738-2-jaimeliao.tw@gmail.com
[ta: update commit message, get rid of extra dereference]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
The mtd data shall be obtained with the mtd ioctls or with
new debugfs entries if one cares. Drop the debug prints.
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-5-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
The flash name is not reliable as we saw flash ID collisions.
Hide the flash name if not set.
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Reviewed-by: Michael Walle <michael@walle.cc>
[ta: update commit subject and description and the sysfs description]
Link: https://lore.kernel.org/r/20231215082138.16063-4-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
The flash name is unreliable as we saw flash ID collisions. Mark the
name as obsolete.
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-3-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
We saw flash ID collisions which make the flash name unreliable. Print
the manufacturer and device ID instead of the flash name.
Lower the print to dev_dbg to stop polluting the kernel log.
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
While switching to ref counters for track mtd devices use, the vmu-flash
driver was forgotten. The reason for reading the ref counter seems
debatable, but let's just fix the build for now.
Fixes: 19bfa9ebebb5 ("mtd: use refcount to prevent corruption")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312022315.79twVRZw-lkp@intel.com/
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231205075936.13831-1-miquel.raynal@bootlin.com
|
|
Since its introduction the driver was declaring a "usecount" variable,
but nobody ever used it upstream.
This was spot while grepping for usecount through mtd/ for other
reasons.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231205075431.13401-1-miquel.raynal@bootlin.com
|
|
When nand_scan() fails, it has cleaned up related resources
in its error paths. Therefore, the following nand_cleanup()
may lead to a double-free. One possible trace is:
doc_probe
|-> nand_scan
| |-> nand_scan_with_ids
| |-> nand_scan_tail
| |-> kfree(chip->data_buf) [First free]
|
|-> nand_cleanup
|-> kfree(chip->data_buf) [Double free here]
Fix this by removing nand_cleanup() on failure of
nand_scan().
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231214072946.10285-1-dinghao.liu@zju.edu.cn
|
|
All fields of the nfc_cfg structure are documented but the name, which
leads to a W=1 warning. Add a title.
Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231211150704.109138-2-miquel.raynal@bootlin.com
|
|
Robots are unhappy with the ecc_cnt_status structure because the kernel
doc says it should be called rk_ecc_cnt_status. In general, it is
considered a better practice to prefix all symbols in a file with the
same prexif, and thus it seems more relevant to rename the structure
rather than changing the kernel doc header.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312102130.geZ4dqyN-lkp@intel.com/
Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231211150704.109138-1-miquel.raynal@bootlin.com
|
|
Both the "chip" kernel doc member and description are wrong. This field
is called "chips" and describes the list of NAND chips connected to the
controller.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312102130.geZ4dqyN-lkp@intel.com/
Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231211150524.108803-1-miquel.raynal@bootlin.com
|
|
Add support for the MT25QU01G 128MB Micron Serial NOR Flash Memory
model.
Link: https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
Signed-off-by: Fabio Estevam <festevam@denx.de>
[ta: introduce die erase]
Link: https://lore.kernel.org/r/20231125123529.55686-6-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
There's no flash using it and we'd like to rely instead on SFDP data,
thus remove it.
Tested-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20231125123529.55686-5-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
Enable die erase for multi die flashes, it will speed the erase time.
Unfortunately, Micron does not provide a 4-byte opcode equivalent for
the die erase. The SFDP 4BAIT table fails to consider the die erase too,
the standard can be improved. Thus we're forced to enter in the 4 byte
address mode in order to benefit of the die erase.
Tested on n25q00. This flash defines the 4BAIT SFDP table, thus it will
use the 4BAIT opcodes for reads, page programs or erases, with the
exception that it will use the die erase command in the 4 byte address
mode.
Link: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_1gb_3v_65nm.pdf?rev=b6eba74759984f749f8c039bc5bc47b7
Link: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_l_02g_cbb_0.pdf?rev=43f7f66fc8da4d7d901b35fa51284c8f
Link: https://lore.kernel.org/r/20231125123529.55686-4-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
ZhaoLong Wang
Guo Xuenan
Zhang Yi
Richard Weinberger
Christian Brauner
Christoph Hellwig
Uwe Kleine-König
Elad Nachman
Ezra Buehler
Markus Elfring
Zhi-Jun You
Miquel Raynal
Han Xu
Linus Torvalds
Li Nan
Randy Dunlap
JaimeLiao
Tudor Ambarus
Dinghao Liu
Fabio Estevam
