From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK (Insufficiently faking current?)
Date: Mon, 15 Feb 2021 12:07:22 -0600 [thread overview]
Message-ID: <m11rdhurvp.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <CAHk-=wiZuX-tyhR6rRxDfQOvyRkCVZjv0DCg1pHBUmzRZ_f1bQ@mail.gmail.com> (Linus Torvalds's message of "Sun, 14 Feb 2021 12:30:07 -0800")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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..
Would there be any downside of making the io-wq kernel threads be per
process instead of per user?
I can see a lower probability of a thread already existing. Are there
other downsides I am missing?
The upside would be that all of the issues of have we copied enough
should go away, as the io-wq thread would then behave like another user
space thread. To handle posix setresuid() and friends it looks like
current_cred would need to be copied but I can't think of anything else.
Right I am with Al and I don't have any idea how many special cases we
need to play whack-a-mole with.
Eric
next prev parent reply other threads:[~2021-02-15 18:08 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
2021-02-15 18:07 ` Eric W. Biederman [this message]
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=m11rdhurvp.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=axboe@kernel.dk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.