On Sat, 5 Aug 2023 at 11:47, Linus Torvalds torvalds@linux-foundation.org wrote:
Yes. Except I hate having two of those iterate functions. We should have gotten rid of them absolutely years ago.
You shamed me into fixing that.
Ok, final build test done and extensive 'git grep' to make sure I didn't miss anything.
Here's two patches to finally get rid of the old legacy '->iterate()' case entirely from the file ops structure.
Yes, some filesystems then still get the inode lock in write mode, but now it's the filesystem itself that wraps its own iterator, rather than cause pain for the callers.
So no more "Do you have an ->iterate() _or_ ->iterate_shared() function?" and associated "I need to do locking differently" nastiness. Only odd filesystems that never got the memo on "don't use .iterate".
I looked at some of the filesystems I added the wrapper to, and they looked like maybe they would be perfectly happy to just iterate with the lock held shared. But this really was meant to be a completely mindless conversion with no semantic changes.
Adding some filesystem maintainers where that second patch adds the wrapper use. It would be lovely if in another seven years we could get rid of that wrapper too ;)
The patches are entirely untested, but they do build cleanly for me, and look very straightforward. The wrapper function is trivial, and is mostly comments.
Anybody?
Linus