All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tal Zussman" <tz2294@columbia.edu>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/2] mtd: rawnand: nandsim: use a NOFS scope for cache file I/O
Date: Thu, 15 Oct 2026 03:36:28 +0000	[thread overview]
Message-ID: <sashiko-outbox-172202@kernel.org> (raw)
In-Reply-To: <20261014-nandsim-nofs-v1-1-47e49f37e387@columbia.edu>

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@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;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-nandsim-nofs-v1-0-47e49f37e387@columbia.edu?part=1

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-10-15  3:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  3:24 [PATCH 0/2] mtd: rawnand: nandsim: stop pre-populating the cache file's page cache Tal Zussman
2026-10-15  3:24 ` [PATCH 1/2] mtd: rawnand: nandsim: use a NOFS scope for cache file I/O Tal Zussman
2026-10-15  3:36   ` sashiko-bot [this message]
2026-10-15 15:08     ` Tal Zussman
2026-10-15  3:24 ` [PATCH 2/2] mtd: rawnand: nandsim: stop pre-populating the cache file's page cache Tal Zussman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-172202@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tz2294@columbia.edu \
    --cc=vigneshr@ti.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.