The other places that do a list_del on d_alias follow with a d_free
shortly, and the dentry can't be used or rereferenced in between, so the
cleanup isn't needed.
> I fact I wonder whether we should not get rid of the alias list
> completely, as it's not actually _used_ for anything any more (well, it's
> used by romfs/inode.c, but the only reason for that is that romfs symbolic
> links are kind of broken (it's confused about directories and symbolic
> links). That together with a strange interface (we give "follow_link" the
> inode rather than the dentry) makes for the romfs problems.
>
> The alias list was useful back when inodes were first-class citizens, and
> lots of places had inode information but no dentry information. These days
> everything that needs a dentry pointer should have the dentry pointer
> anyway, without needing to get it through an inode.
Well, I was thinking of using the alias list to fix (maybe re-hack is a
better term) the nfs sillyrename code. By summing the dentry d_counts
on the alias list I could find how many users an inode has. But maybe
there's another way, and this by itself isn't much justification for
keeping the alias list.
Regards,
Bill