kernel/linux.git/drivers/mtd/mtdblock.c, branch v7.1-rc5

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

mtdblock: make warning messages ratelimited

2023-07-27T15:16:14+00:00

When exercising various dev interfaces with stress-ng the mtdblock drivers can be (ab)used to generate a lot of warning messages. Make these rate limited to reduce the kernel log from being spammed with the same messages. Signed-off-by: Colin Ian King Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230719103354.2829366-1-colin.i.king@gmail.com

mtd: block: use a simple bool to track open for write

2023-06-12T14:04:04+00:00

Instead of propagating the fmode_t, just use a bool to track if a mtd block device was opened for writing. Signed-off-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Acked-by: Christian Brauner Acked-by: Richard Weinberger Link: https://lore.kernel.org/r/20230608110258.189493-23-hch@lst.de Signed-off-by: Jens Axboe

mtdblock: tolerate corrected bit-flips

2023-04-03T15:57:59+00:00

mtd_read() may return -EUCLEAN in case of corrected bit-flips.This particular condition should not be treated like an error. Signed-off-by: Bang Li Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: # v3.7 Acked-by: Richard Weinberger Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230328163012.4264-1-libang.linuxer@gmail.com

mtdblock: warn if opened on NAND

2022-04-25T08:43:12+00:00

Warning on every translated mtd partition results in excessive log noise if this driver is loaded: nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 nand: Macronix MX30LF1G18AC nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits read_bbt: found bbt at block 1023 10 fixed-partitions partitions found on MTD device mt7621-nand Creating 10 MTD partitions on "mt7621-nand": 0x000000000000-0x000000080000 : "Bootloader" mtdblock: MTD device 'Bootloader' is NAND, please consider using UBI block devices instead. 0x000000080000-0x000000100000 : "Config" mtdblock: MTD device 'Config' is NAND, please consider using UBI block devices instead. 0x000000100000-0x000000140000 : "Factory" mtdblock: MTD device 'Factory' is NAND, please consider using UBI block devices instead. 0x000000140000-0x000002000000 : "Kernel" mtdblock: MTD device 'Kernel' is NAND, please consider using UBI block devices instead. 0x000000540000-0x000002000000 : "ubi" mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead. 0x000002140000-0x000004000000 : "Kernel2" mtdblock: MTD device 'Kernel2' is NAND, please consider using UBI block devices instead. 0x000004000000-0x000004100000 : "wwan" mtdblock: MTD device 'wwan' is NAND, please consider using UBI block devices instead. 0x000004100000-0x000005100000 : "data" mtdblock: MTD device 'data' is NAND, please consider using UBI block devices instead. 0x000005100000-0x000005200000 : "rom-d" mtdblock: MTD device 'rom-d' is NAND, please consider using UBI block devices instead. 0x000005200000-0x000005280000 : "reserve" mtdblock: MTD device 'reserve' is NAND, please consider using UBI block devices instead. mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21 This is more likely to annoy than to help users of embedded distros where this driver is enabled by default. Making the blockdevs available does not imply that they are in use, and warning about bootloader partitions or other devices which obviously never will be mounted is more confusing than helpful. Move the warning to open(), where it will be of more use - actually warning anyone who mounts a file system on NAND using mtdblock. Fixes: e07403a8c6be ("mtdblock: Warn if added for a NAND device") Signed-off-by: Bjørn Mork Reviewed-by: Ezequiel Garcia Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220328161108.87757-1-bjorn@mork.no

mtdblock: Warn if added for a NAND device

2021-08-17T16:41:59+00:00

There is a surprisingly large number of tutorials that suggest using mtdblock to mount SquashFS filesystems on flash devices, including NAND devices. This approach is suboptimal than using UBI. If the flash device is NAND, this is specially true, due to wear leveling, bit-flips and badblocks. In this case UBI is strongly preferred, so be nice to users and print a warning suggesting to consider UBI block, if mtdblock is added for a NAND device. Signed-off-by: Ezequiel Garcia Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210801234509.18774-8-ezequiel@collabora.com

mtd: mtdblock: Use module_mtd_blktrans to register driver

2021-03-11T08:37:48+00:00

Removing some boilerplate by using module_mtd_blktrans instead of calling register and unregister in the otherwise empty init/exit functions. Signed-off-by: Dejin Zheng Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210213164600.409061-5-zhengdejin5@gmail.com

mtd: clear cache_state to avoid writing to bad blocks repeatedly

2020-06-05T08:16:14+00:00

The function call process is as follows: mtd_blktrans_work() while (1) do_blktrans_request() mtdblock_writesect() do_cached_write() write_cached_data() /*if cache_state is STATE_DIRTY*/ erase_write() write_cached_data() returns failure without modifying cache_state and cache_offset. So when do_cached_write() is called again, write_cached_data() will be called again to perform erase_write() on the same cache_offset. But if this cache_offset points to a bad block, erase_write() will always return -EIO. Writing to this mtdblk is equivalent to losing the current data, and repeatedly writing to the bad block. Repeatedly writing a bad block has no real benefits, but brings some negative effects: 1 Lost subsequent data 2 Loss of flash device life 3 erase_write() bad blocks are very time-consuming. For example: the function do_erase_oneblock() in chips/cfi_cmdset_0020.c or chips/cfi_cmdset_0002.c may take more than 20 seconds to return Therefore, when erase_write() returns -EIO in write_cached_data(), clear cache_state to avoid writing to bad blocks repeatedly. Signed-off-by: Xiaoming Ni Reviewed-by: Miquel Raynal Signed-off-by: Richard Weinberger

mtd: Fix issue where write_cached_data() fails but write() still returns success

2020-03-24T22:02:30+00:00

The following sequence is problematic: mtdblock_flush() -->write_cached_data() --->erase_write() mtdblock: erase of region [0x40000, 0x20000] on "xxx" failed Problem is: mtdblock_flush() always returns 0. Indeed, even if write_cached_data() fails and data is not written to the device, syscall_write() still returns success. Avoid this situation by actually returning the error coming out of write_cached_data(). Signed-off-by: Xiaoming Ni Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/1584674111-101462-1-git-send-email-nixiaoming@huawei.com