Re: [RFC] mtd: virt-concat: define duplicate partition handling

Hi Pengpeng,

On 22/07/2026 at 12:19:25 +08, Pengpeng Hou <[email protected]> wrote:

> mtd_device_parse_register() contains compatibility handling for drivers t=
hat
> call it more than once, while its comment notes that partition parsing can
> register the same partitions again.

Is this feature really relevant? Who uses that?

> When CONFIG_MTD_PARTITIONED_MASTER is disabled and the first call finds
> partitions, the master itself is not registered before parsing. A later c=
all
> can therefore reach partition parsing again.
>
> With CONFIG_MTD_VIRT_CONCAT, each newly allocated partition whose OF node
> belongs to a virtual concatenation reaches mtd_virt_concat_add(). That
> function appends the partition based only on the OF node and increments
> num_subdev without checking whether the node was already added or whether
> the fixed subdev[] array is full.
>
> A repeated parse can therefore append the same node again. If all configu=
red
> slots were already populated, the append is out of bounds. If other membe=
rs
> are still missing, the duplicate can make num_subdev reach the configured
> count with the wrong membership.
>
> A local bounds check does not seem sufficient for a correct patch:
>
>   - concat_node_list and the concat population state are global, but node
>     creation, addition, join creation and destruction have no common
>     serialization.

But aren't these operations serialized just because of how the MTD core
is designed?

>   - mtd_virt_concat_add() returns bool. false means both "not a concat
>     member" and "not added". Returning false for a duplicate makes
>     add_mtd_partitions() register it as an ordinary partition, while retu=
rning
>     true without storing it would leak the newly allocated partition.
>   - join creation and destruction call back into MTD registration helpers=
, so
>     a driver-global mutex must have a carefully defined scope to avoid
>     recursive locking.
>
> My current view is that the fix needs both a serialization contract for t=
he
> global virtual-concat state and a tri-state add result, so the caller can
> distinguish "not a member" from a duplicate or capacity error and free the
> new partition on error.
>
> Would you prefer this serialization to live inside mtd_virt_concat, or sh=
ould
> the MTD registration layer serialize the node-create/partition-add/join
> transaction? I have not attached a patch because choosing either scope
> without agreement would encode a new lifetime and error-handling contract.

If it is specific to the virt concat layer, I would try to keep the
changes contained in the virt concat driver.

Thanks,
Miqu=C3=A8l