Re: [PATCH v5 1/9] of: hold a reference on of_aliases during alias path resolution

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

On Tue Jul 22, 2026 at 8:35 PM PDT, sashiko-bot wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but is the description of the
> lock-free walk accurate?
>
> If a concurrent writer (e.g., overlay application) removes a property while
> for_each_property_of_node() is iterating over it, won't the reader's next
> access of pp->next follow the pointer into the deadprops list?

Right, the commit message misstates the mechanism.
__of_remove_property() repoints prop->next at the deadprops head, so
a racing walker can be diverted into deadprops and miss live
properties. What it cannot do is step into freed memory while it
holds the node reference: dead properties are only freed at node
release. So the conclusion stands (the walk is memory-safe without
the lock) but the failure mode is a stale view, the same as every
other lock-free property walk in the tree. I'll fix the wording in
the next revision.

> [Severity: High]
> This is a pre-existing issue, but does calling __of_find_node_by_full_path()
> while holding devtree_lock further down in this function risk a
> sleep-in-atomic bug?

Known, and tracked in the cover letter's open items. It affects every
OF iterator that puts nodes under devtree_lock and needs a series of
its own.

Thanks,
Abdurrahman