Re: [PATCH v7 00/10] of: teach overlay code to keep /aliases in sync

[Rob Herring <robh@kernel.org>]

On Mon, Aug 31, 2026 at 06:29:18PM -0700, Abdurrahman Hussain wrote:
> /aliases entries added by a device-tree overlay are stored in the live
> tree but never enter the global aliases_lookup list that of_alias_scan()
> builds at boot. As a result, of_alias_get_id() returns -ENODEV for
> aliases declared inside overlays, and any driver that relies on
> alias-based numbering (i2c-xiic, spi, tty, mmc, ...) silently loses its
> pinned id and falls back to auto-assignment.
> 
> The gap has been public since 2015 [1] and reproduces trivially: apply
> an overlay that declares e.g. `i2c99 = &foo;`, ask
> of_alias_get_id(foo, "i2c") -> -ENODEV.
> 
> The core fix (patch 2) is a reconfig notifier that mirrors /aliases
> property changes into aliases_lookup. Patch 1 prepares the alias path
> lookup for /aliases becoming dynamic. Patches 3, 8 and 9 are the
> overlay-code changes the use case needs; patches 4-7 fix pre-existing
> bugs on paths the series exercises. Patch 10 adds a
> unittest.
> 
> Prior art
> ---------
> 
> Geert Uytterhoeven posted a 3-patch RFC in June 2015 [1] with the same
> alias-tracking design shape. Grant Likely reviewed positively; merge
> was gated on missing unittests and an object-lifetime concern the
> author self-flagged, and the series was never reposted as non-RFC. Ten
> years later, drivers/of/overlay.c still contains zero references to
> aliases, of_alias_scan, or aliases_lookup.

There was another posting in 2024 of Geert's patches and AFAICT my
comment there[1] still applies. To repeat, what happens if the alias 
number already got used because the subsystems can pick any of the 
numbers without an alias. The only way I see to solve that is make 
possible alias numbers and dynamic numbers non-overlapping or only allow 
alias names that are not present in the base DT to be used/honored in 
overlays.


> Series contents
> ---------------
> Patch 1 makes of_find_node_opts_by_path() hold a reference on
> of_aliases across the alias walk (the walk itself stays lock-free, as
> does the pointer load: of_aliases always holds a reference on the
> node it points to) and validates alias values before dereferencing
> them.
> 
> Patch 2 adds a reconfig notifier that mirrors /aliases property
> changes into aliases_lookup. It also refactors of_alias_scan()'s
> per-property body into a helper of_alias_create() shared by the
> boot-time scan and the runtime notifier. A one-bit `owned` flag on
> struct alias_prop distinguishes kmalloc'd (overlay-time) entries
> (kstrdup'd alias name, of_node_get'd target) from memblock-backed
> (boot-time) ones so the remove path can't kfree the wrong storage.
> The notifier keys off structural properties of the target node
> (name + root-parent) rather than the of_aliases global, so overlays
> that create /aliases from scratch on a system without a boot-time
> aliases node are covered too. All aliases_lookup readers and writers
> serialize on a dedicated aliases_mutex.
> 
> Patch 3 fixes find_target() so an overlay applied with a non-NULL
> target base can still reach the DT root via target-path="/foo". The
> current code unconditionally concatenates base + target-path via
> "%pOF%s", so target-path="/aliases" resolves to "<base>/aliases" and
> target-path="/" produces "<base>/" (never a valid node). After this
> patch, an empty target-path continues to mean "the target base
> itself" — preserving the shape used by drivers/misc/lan966x_pci.c,
> the only in-tree caller of of_overlay_fdt_apply() that passes a
> non-NULL base — while any non-empty target-path is looked up
> absolutely.
> 
> Patch 4 fixes a pre-existing double-free in add_changeset_property():
> a property freed on the of_changeset_add_property() error path stayed
> linked in the target node's deadprops list and was freed again at
> node release.
> 
> Patch 5 fixes a pre-existing NULL dereference in
> of_overlay_fdt_apply()'s idr_alloc() error path (negative id stored,
> list_del() on an uninitialized list head) by only treating a positive
> id as registered in free_overlay_changeset().
> 
> Patch 6 fixes a pre-existing reference leak in
> init_overlay_changeset(): on a mid-loop failure, the target and
> overlay references of the fragments initialized so far were never
> dropped because ovcs->count was still 0 when free_overlay_changeset()
> ran its cleanup loop.
> 
> Patch 7 fixes pre-existing "//" result paths from
> dup_and_fixup_symbol_prop() when a fragment targets the root node.

Fixes should come first in a series. Then I can apply them if ready even 
if the feature patches are not ready.

Rob

[1] https://lore.kernel.org/all/CAL_Jsq+72Q6LyOj1va_qcyCVkSRwqGNvBFfB9NNOgYXasAFYJQ@mail.gmail.com/