All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "James Hilliard" <james.hilliard1@gmail.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Christian Marangi" <ansuelsmth@gmail.com>,
	"Sricharan R" <quic_srichara@quicinc.com>,
	"Md Sadre Alam" <quic_mdalam@quicinc.com>,
	"Boris Brezillon" <bbrezillon@kernel.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/3] mtd: rawnand: qcom: parse boot partitions before registering MTD
Date: Sun, 08 Nov 2026 21:24:03 +0000	[thread overview]
Message-ID: <sashiko-outbox-204074@kernel.org> (raw)
In-Reply-To: <20261108-submit-qcom-nand-child-probe-errors-v1-v1-1-509f30a9e14d@gmail.com>

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] mtd: rawnand: qcom: unlocked bam_txn reallocation in
  qcom_nand_attach_chip() [1]
--

commit aecfb39160da37f68bc9b557fcfe8446b871939e
Author: James Hilliard <james.hilliard1@gmail.com>

mtd: rawnand: qcom: parse boot partitions before registering MTD

This commit parses boot partitions in qcom_nand_host_init_and_register()
before calling mtd_device_parse_register() so that parsing errors do not
call nand_cleanup() on an already registered MTD device.

> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> index 2d98f79b492d6..f240d1effa043 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -2052,16 +2052,16 @@ static int qcom_nand_host_init_and_register(struct qcom_nand_controller *nandc,
>  	if (ret)
>  		return ret;
>  
> -	ret = mtd_device_parse_register(mtd, probes, NULL, NULL, 0);
> -	if (ret)
> -		goto err;
> -
>  	if (nandc->props->use_codeword_fixup) {
>  		ret = qcom_nand_host_parse_boot_partitions(nandc, host, dn);
>  		if (ret)
>  			goto err;
>  	}
>  
> +	ret = mtd_device_parse_register(mtd, probes, NULL, NULL, 0);
> +	if (ret)
> +		goto err;

[Severity: Medium]
This problem wasn't introduced by this patch, but can qcom_nand_attach_chip()
free and reallocate nandc->bam_txn [1] while an earlier chip is already
registered and servicing I/O?

qcom_probe_nand_devices() calls qcom_nand_host_init_and_register() for each
child node in turn.  Once the first chip is registered, MTD operations on it
take nandc->controller.lock and use the controller-wide nandc->bam_txn, while
probing a second chip runs qcom_nand_attach_chip() without holding
nandc->controller.lock:

drivers/mtd/nand/raw/qcom_nandc.c:qcom_nand_attach_chip() {
	...
	if (nandc->props->supports_bam)
		qcom_free_bam_transaction(nandc);

	nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage,
				     cwperpage);

	/* Now allocate the BAM transaction based on updated max_cwperpage */
	if (nandc->props->supports_bam) {
		nandc->bam_txn = qcom_alloc_bam_transaction(nandc);
		if (!nandc->bam_txn) {
			dev_err(nandc->dev,
				"failed to allocate bam transaction\n");
			return -ENOMEM;
		}
	}
	...
}

This allows the second chip's scan to free nandc->bam_txn underneath an
in-flight operation on the first chip:

CPU0                                    CPU1
qcom_probe_nand_devices()
  qcom_nand_host_init_and_register()
    mtd_device_parse_register() [chip 0]
                                        nand_read_oob() [chip 0]
                                          nand_get_device()
                                          qcom_nandc_read_page()
                                            ...
  qcom_nand_host_init_and_register() [chip 1]
    nand_scan()
      ...
        qcom_nand_attach_chip()
          qcom_free_bam_transaction()
                                            qcom_clear_bam_transaction()
                                              <-- use-after-free
          qcom_alloc_bam_transaction()

Also, if qcom_alloc_bam_transaction() fails for the second chip,
nandc->bam_txn is left NULL while the first chip remains registered, causing
subsequent operations on the first chip to hit a NULL pointer dereference.

[1] https://sashiko.dev/#/bug/linux-f5ec08db-a039-4be6-ba66-945cfc6d14f5

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261108-submit-qcom-nand-child-probe-errors-v1-v1-0-509f30a9e14d@gmail.com?part=1

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

  reply	other threads:[~2026-11-08 21:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 21:16 [PATCH 0/3] mtd: rawnand: qcom: unwind failed child initialization James Hilliard
2026-11-08 21:16 ` James Hilliard
2026-11-08 21:16 ` [PATCH 1/3] mtd: rawnand: qcom: parse boot partitions before registering MTD James Hilliard
2026-11-08 21:16   ` James Hilliard
2026-11-08 21:24   ` sashiko-bot [this message]
2026-11-08 21:16 ` [PATCH 2/3] mtd: rawnand: qcom: retain the BAM transaction if replacement fails James Hilliard
2026-11-08 21:16   ` James Hilliard
2026-11-08 21:16 ` [PATCH 3/3] mtd: rawnand: qcom: unwind registered chips on child probe failure James Hilliard
2026-11-08 21:16   ` James Hilliard

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-204074@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ansuelsmth@gmail.com \
    --cc=bbrezillon@kernel.org \
    --cc=james.hilliard1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mani@kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=quic_mdalam@quicinc.com \
    --cc=quic_srichara@quicinc.com \
    --cc=richard@nod.at \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vigneshr@ti.com \
    /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.