Re: [PATCH v4 1/6] of: resolve alias-prefixed paths under devtree_lock

["Abdurrahman Hussain" <abdurrahman@nexthop.ai>]

On Wed Jul 22, 2026 at 12:30 AM PDT, Krzysztof Kozlowski wrote:
> > While here, validate the value's shape before handing it to
> > of_find_node_by_path(): /aliases contents can now come from overlays
>
> Can it?

Not at this point in the series -- patches 2-5 are what make /aliases
writable at runtime. The message got ahead of the series; I'll reword
it to stand alone.

> All this looks like AI written.

The tooling is disclosed in the Assisted-by trailer. I'll cut the
prose down in the reroll.

> > +		raw_spin_lock_irqsave(&devtree_lock, flags);
>
> Since when do we lock looping over for_each_property_of_node()?
>
> Do I understand correctly your proposal: you want to add
> raw_spin_lock_irqsave() over every piece of code having for_each_XXX
> OF-loop?

No. You're right that the walk doesn't need the lock: removed
properties move to the node's deadprops list and keep their ->next, so
a walker holding a node reference never steps into freed memory.
That's why every other for_each_XXX user is fine lock-free, and I
shouldn't have pulled the loop under the lock.

What does need pairing is the of_aliases pointer load. Patch 2 adds a
reconfig notifier that clears of_aliases and drops the reference it
holds when the node is detached -- overlays can create and destroy
/aliases from that point on. A reader that loads the bare pointer
without taking its own reference under the same lock can have the
node (and its deadprops) freed under it mid-walk.

I'll reroll with the lock narrowed to the pointer load plus
of_node_get(), and the property walk lock-free as everywhere else.

Thanks,
Abdurrahman