From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK (Insufficiently faking current?)
Date: Sun, 14 Feb 2021 21:24:33 +0000 [thread overview]
Message-ID: <YCmVETSedjnaxz7g@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <CAHk-=wiZuX-tyhR6rRxDfQOvyRkCVZjv0DCg1pHBUmzRZ_f1bQ@mail.gmail.com>
On Sun, Feb 14, 2021 at 12:30:07PM -0800, Linus Torvalds wrote:
> On Sun, Feb 14, 2021 at 8:38 AM Jens Axboe <axboe@kernel.dk> wrote:
> >
> > > Similarly it looks like opening of "/dev/tty" fails to
> > > return the tty of the caller but instead fails because
> > > io-wq threads don't have a tty.
> >
> > I've got a patch queued up for 5.12 that clears ->fs and ->files for the
> > thread if not explicitly inherited, and I'm working on similarly
> > proactively catching these cases that could potentially be problematic.
>
> Well, the /dev/tty case still needs fixing somehow.
>
> Opening /dev/tty actually depends on current->signal, and if it is
> NULL it will fall back on the first VT console instead (I think).
>
> I wonder if it should do the same thing /proc/self does..
I still think that entire "offload pathname resolution to helper
threads" thing is bollocks. ->fs, ->files and ->signal is still nowhere
near enough - look at /proc/net, for example. Or netns-sensitive parts
of sysfs, for that matter... And that's not going into really weird crap
where opener is very special and assumed to be doing all IO.
next prev parent reply other threads:[~2021-02-14 21:25 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-14 19:13 [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK Jens Axboe
2020-12-14 19:13 ` [PATCH 1/4] fs: make unlazy_walk() error handling consistent Jens Axboe
2020-12-14 19:13 ` [PATCH 2/4] fs: add support for LOOKUP_NONBLOCK Jens Axboe
2020-12-15 12:24 ` Matthew Wilcox
2020-12-15 15:29 ` Jens Axboe
2020-12-15 15:33 ` Matthew Wilcox
2020-12-15 15:37 ` Jens Axboe
2020-12-15 16:08 ` Jens Axboe
2020-12-15 16:14 ` Jens Axboe
2020-12-15 18:29 ` Linus Torvalds
2020-12-15 18:44 ` Jens Axboe
2020-12-15 18:47 ` Linus Torvalds
2020-12-15 19:03 ` Jens Axboe
2020-12-15 19:32 ` Linus Torvalds
2020-12-15 19:38 ` Jens Axboe
2020-12-16 2:36 ` Al Viro
2020-12-16 3:30 ` Jens Axboe
2020-12-16 2:43 ` Al Viro
2020-12-16 3:32 ` Jens Axboe
2020-12-14 19:13 ` [PATCH 3/4] fs: expose LOOKUP_NONBLOCK through openat2() RESOLVE_NONBLOCK Jens Axboe
2020-12-15 22:25 ` Dave Chinner
2020-12-15 22:31 ` Linus Torvalds
2020-12-15 23:25 ` Jens Axboe
2020-12-16 2:37 ` Al Viro
2020-12-16 3:39 ` Linus Torvalds
2020-12-14 19:13 ` [PATCH 4/4] io_uring: enable LOOKUP_NONBLOCK path resolution for filename lookups Jens Axboe
2020-12-15 3:06 ` [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK Linus Torvalds
2020-12-15 3:18 ` Jens Axboe
2020-12-15 6:11 ` Al Viro
2020-12-15 15:29 ` Jens Axboe
2021-01-04 5:31 ` Al Viro
2021-01-04 14:43 ` Jens Axboe
2021-01-04 16:54 ` Al Viro
2021-01-04 17:03 ` Jens Axboe
[not found] ` <m1lfbrwrgq.fsf@fess.ebiederm.org>
2021-02-14 16:38 ` [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK (Insufficiently faking current?) Jens Axboe
2021-02-14 20:30 ` Linus Torvalds
2021-02-14 21:24 ` Al Viro [this message]
2021-02-15 18:07 ` Eric W. Biederman
2021-02-15 18:24 ` Jens Axboe
2021-02-15 21:09 ` Jens Axboe
2021-02-15 22:41 ` Eric W. Biederman
2021-02-16 2:41 ` Jens Axboe
2021-02-17 1:18 ` Jens Axboe
2021-02-17 1:26 ` Jens Axboe
2021-02-17 3:11 ` Jens Axboe
2021-02-15 17:56 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YCmVETSedjnaxz7g@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).