On Tue, Sep 10, 2019 at 10:53:57PM +0100, Al Viro wrote:
> * we might need to grab dentry reference around dir_emit() in dcache_readdir().
> As it is, devpts makes it very easy to fuck that one up.
FWIW, that goes back to commit 8ead9dd54716 (devpts: more pty driver interface
cleanups) three years ago. Rule of the thumb: whenever you write "no actual
semantic changes" in commit message, you are summoning Murphy...
> * it might make sense to turn next_positive() into "try to walk that much,
> return a pinned dentry, drop the original one, report how much we'd walked".
> That would allow to bring ->d_lock back and short-term it might be the best
> solution. IOW,
> int next_positive(parent, from, count, dentry)
> grab ->d_lock
> walk the list, decrementing count on hashed positive ones
> if we see need_resched
> break
> if we hadn't reached the end, grab whatever we'd reached
> drop ->d_lock
> dput(*dentry)
> if need_resched
> schedule
> *dentry = whatever we'd grabbed or NULL
> return count;
>
> The callers would use that sucker in a loop - readdir would just need to
> initialize next to NULL and do
> while (next_positive(dentry, p, 1, &next), next != NULL) {
> in the loop, with dput(next) in the very end. And lseek would do
> to = NULL;
> p = &dentry->d_subdirs;
> do {
> n = next_positive(dentry, p, n, &to);
> if (!to)
> break;
> p = &to->d_child;
> } while (n);
> move_cursor(cursor, to ? p : NULL);
> dput(to);
> instead of
> to = next_positive(dentry, &dentry->d_subdirs, n);
> move_cursor(cursor, to ? &to->d_child : NULL);
>
> Longer term I would really like to get rid of ->d_lock in that thing,
> but it's much too late in this cycle for that.
