Linux-mtd Archive on 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>
Cc: linux-mtd@lists.infradead.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Yuqiang Sun" <izaiahsun@gmail.com>,
	"Amit Kumar Mahapatra" <amit.kumar-mahapatra@amd.com>,
	"Luca Ceresoli" <luca.ceresoli@bootlin.com>,
	"Bernhard Frauendienst" <kernel@nospam.obeliks.de>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	"Kees Cook" <kees@kernel.org>
Subject: Re: [PATCH v3 04/58] mtd: retain virtual concatenations across component removal
Date: Thu, 12 Nov 2026 03:09:04 +0000	[thread overview]
Message-ID: <sashiko-outbox-210241@kernel.org> (raw)
In-Reply-To: <20261111-submit-rawnand-retained-handle-lifetime-v1-v3-4-ce537999741d@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mtd: mtdconcat: mtd_concat_create() checks subdev ooblayout
  instead of master
--

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

mtd: retain virtual concatenations across component removal

This commit reworks virtual MTD concatenation lifetime management, using
reference counting for staged partition components and SRCU to synchronize
forwarding operations during disconnect and teardown.

Link: https://lore.kernel.org/r/20261103143953.69642-1-izaiahsun@gmail.com/
Link: https://lore.kernel.org/r/sashiko-outbox-195551@kernel.org/

> diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
> index c97167d51fe2d..cce3e2fcafc84 100644
> --- a/drivers/mtd/mtdconcat.c
> +++ b/drivers/mtd/mtdconcat.c
[ ... ]
> @@ -738,7 +822,8 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
>  
>  	}
>  
> -	mtd_set_ooblayout(&concat->mtd, subdev[0]->ooblayout);
> +	if (subdev[0]->ooblayout)
> +		mtd_set_ooblayout(&concat->mtd, &concat_ooblayout_ops);

[Severity: Medium]
Should this check mtd_get_master(subdev[0])->ooblayout instead of
subdev[0]->ooblayout?

allocate_partition() does not copy ooblayout onto child partition mtd_info
structs; mtd_ooblayout_ecc() and mtd_ooblayout_free() look it up on
mtd_get_master(mtd).  When mtd_concat_create() is called with partition
subdevices (as mtd_virt_concat_register() always does), subdev[0]->ooblayout
is NULL, so concat_ooblayout_ops is never installed and OOB layout queries on
the concatenated device fail with -ENOTSUPP.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-submit-rawnand-retained-handle-lifetime-v1-v3-0-ce537999741d@gmail.com?part=4

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

  reply	other threads:[~2026-11-12  3:09 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12  1:27 [PATCH v3 00/58] mtd: rawnand: retain chip and controller state across removal James Hilliard
2026-11-12  1:27 ` [PATCH v3 01/58] nvmem: disconnect provider callbacks before unregister returns James Hilliard
2026-11-12  2:00   ` sashiko-bot
2026-11-12  1:27 ` [PATCH v3 02/58] mtd: acquire an MTD handle from a referenced class device James Hilliard
2026-11-12  1:27 ` [PATCH v3 03/58] mtd: separate class devices from retained backing objects James Hilliard
2026-11-12  2:48   ` sashiko-bot
2026-11-12  1:27 ` [PATCH v3 04/58] mtd: retain virtual concatenations across component removal James Hilliard
2026-11-12  3:09   ` sashiko-bot [this message]
2026-11-12  1:27 ` [PATCH v3 05/58] mtd: rawnand: separate hardware disconnection from cleanup James Hilliard
2026-11-12  1:27 ` [PATCH v3 06/58] mtd: rawnand: share retained chip and controller ownership James Hilliard
2026-11-12  1:27 ` [PATCH v3 07/58] mtd: rawnand: sunxi: retain chip state until the final MTD put James Hilliard
2026-11-12  1:27 ` [PATCH v3 08/58] mtd: rawnand: plat_nand: retain open-handle state on removal James Hilliard
2026-11-12  1:27 ` [PATCH v3 09/58] mtd: rawnand: gpio: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 10/58] mtd: rawnand: stm32_fmc2: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 11/58] mtd: rawnand: denali: retain chips across controller removal James Hilliard
2026-11-12  1:27 ` [PATCH v3 12/58] mtd: rawnand: arasan: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 13/58] mtd: rawnand: mxic: retain open-handle state on removal James Hilliard
2026-11-12  1:27 ` [PATCH v3 14/58] mtd: rawnand: intel: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 15/58] mtd: rawnand: tegra: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 16/58] mtd: rawnand: mtk: retain chips across controller removal James Hilliard
2026-11-12  1:27 ` [PATCH v3 17/58] mtd: rawnand: rockchip: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 18/58] mtd: rawnand: atmel: " James Hilliard
2026-11-12  1:27 ` [PATCH v3 19/58] mtd: rawnand: orion: retain open-handle state on removal James Hilliard
2026-11-12  1:27 ` [PATCH v3 20/58] mtd: rawnand: socrates: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 21/58] mtd: rawnand: fsl_upm: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 22/58] mtd: rawnand: pasemi: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 23/58] mtd: rawnand: ams-delta: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 24/58] mtd: rawnand: xway: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 25/58] mtd: rawnand: hisi504: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 26/58] mtd: rawnand: vf610: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 27/58] mtd: rawnand: technologic: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 28/58] mtd: rawnand: loongson: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 29/58] mtd: rawnand: ma35d1: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 30/58] mtd: rawnand: pl35x: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 31/58] mtd: rawnand: mxc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 32/58] mtd: rawnand: fsmc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 33/58] mtd: rawnand: gpmi: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 34/58] mtd: rawnand: omap2: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 35/58] mtd: rawnand: marvell: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 36/58] mtd: rawnand: renesas: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 37/58] mtd: rawnand: meson: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 38/58] mtd: rawnand: cadence: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 39/58] mtd: rawnand: qcom: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 40/58] mtd: rawnand: cafe: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 41/58] mtd: rawnand: brcmnand: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 42/58] mtd: rawnand: au1550nd: retain chip state across removal James Hilliard
2026-11-12  1:28 ` [PATCH v3 43/58] mtd: rawnand: sharpsl: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 44/58] mtd: rawnand: davinci: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 45/58] mtd: rawnand: sh_flctl: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 46/58] mtd: rawnand: lpc32xx_slc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 47/58] mtd: rawnand: lpc32xx_mlc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 48/58] mtd: rawnand: ndfc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 49/58] mtd: rawnand: txx9ndfmc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 50/58] mtd: rawnand: ingenic: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 51/58] mtd: rawnand: mpc5121: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 52/58] mtd: rawnand: bcm47xxnflash: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 53/58] mtd: rawnand: fsl_elbc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 54/58] mtd: rawnand: fsl_ifc: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 55/58] mtd: rawnand: r852: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 56/58] mtd: rawnand: nandsim: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 57/58] mtd: rawnand: cs553x: " James Hilliard
2026-11-12  1:28 ` [PATCH v3 58/58] mtd: rawnand: diskonchip: " 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-210241@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=amit.kumar-mahapatra@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=izaiahsun@gmail.com \
    --cc=james.hilliard1@gmail.com \
    --cc=kees@kernel.org \
    --cc=kernel@nospam.obeliks.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=miquel.raynal@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox