[PATCH 1/2] mtd: rawnand: nandsim: use a NOFS scope for cache file I/O

[Tal Zussman]

On 10/14/26 11:36 PM, sashiko-bot at kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] mtd: nandsim: IO reclaim self-deadlock due to memalloc_nofs_save()
> --
> 
> commit 6c4530163aa059b5f98e17ba82a9c2b06c3f48bb
> Author: Tal Zussman <tz2294 at columbia.edu>
> 
> mtd: rawnand: nandsim: use a NOFS scope for cache file I/O
> 
> This commit replaces memalloc_noreclaim_save() with memalloc_nofs_save() to
> prevent allocations during nandsim cache file operations from recursing into
> filesystem reclaim.
> 
>> diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
>> index fe968037f75a2..4559df2cfa3cc 100644
>> --- a/drivers/mtd/nand/raw/nandsim.c
>> +++ b/drivers/mtd/nand/raw/nandsim.c
> [ ... ]
>> @@ -1342,14 +1342,14 @@ static ssize_t ns_read_file(struct nandsim *ns, struct file *file, void *buf,
>>  {
>>  	ssize_t tx;
>>  	int err;
>> -	unsigned int noreclaim_flag;
>> +	unsigned int nofs_flag;
>>  
>>  	err = ns_get_pages(ns, file, count, pos);
>>  	if (err)
>>  		return err;
>> -	noreclaim_flag = memalloc_noreclaim_save();
>> +	nofs_flag = memalloc_nofs_save();
>>  	tx = kernel_read(file, buf, count, &pos);
>> -	memalloc_noreclaim_restore(noreclaim_flag);
> 
> [Severity: High]
> Can this cause an IO reclaim self-deadlock?
> 
> Nandsim executes MTD operations while holding the NAND subsystem device
> lock (chip->lock). While memalloc_nofs_save() strips the filesystem reclaim
> flags, it leaves direct IO reclaim enabled.
> 
> If memory allocations within kernel_read() trigger direct reclaim, the
> shrinker might attempt to write out dirty pages belonging to this same
> device (for example, if used as a swap device or via mtdblock).
> 
> Writing out these pages would route through the block layer back to the MTD
> layer, which will attempt to acquire chip->lock again, resulting in a
> self-deadlock.
> 
> Should this use memalloc_noio_save() instead to safely prevent reclaim
> from issuing any block IO while the MTD lock is held?
> 
>>  	ns_put_pages(ns);
>>  	return tx;
>>  }
>> @@ -1359,14 +1359,14 @@ static ssize_t ns_write_file(struct nandsim *ns, struct file *file, void *buf,
>>  {
>>  	ssize_t tx;
>>  	int err;
>> -	unsigned int noreclaim_flag;
>> +	unsigned int nofs_flag;
>>  
>>  	err = ns_get_pages(ns, file, count, pos);
>>  	if (err)
>>  		return err;
>> -	noreclaim_flag = memalloc_noreclaim_save();
>> +	nofs_flag = memalloc_nofs_save();
>>  	tx = kernel_write(file, buf, count, &pos);
>> -	memalloc_noreclaim_restore(noreclaim_flag);
> 
> [Severity: High]
> Does kernel_write() face the same IO reclaim self-deadlock risk here?
> 
> Allocations within kernel_write() could also trigger direct IO reclaim
> while the chip lock is held. Using memalloc_noio_save() would protect this
> path as well.
> 
>>  	ns_put_pages(ns);
>>  	return tx;
>>  }
> 
Both of these seem mostly accurate. I'll switch it over for v2.