On Tue 11-01-22 09:12:08, Linus Torvalds wrote:
> On Mon, Jan 10, 2022 at 10:19 AM Jan Kara <jack@xxxxxxx> wrote:
> >
> > A task can end up indefinitely sleeping in do_select() ->
> > poll_schedule_timeout() when the following race happens:
> > {...]
>
> Ok, I decided to just take this as-is right now, and get it in early
> in the merge window, and see if anybody hollers.
>
> I don't think the stable people will try to apply it until after the
> merge window closes anyway, but it's worth pointing out that this
> change (commit 68514dacf271: "select: Fix indefinitely sleeping task
> in poll_schedule_timeout()" in my tree now) is very much a change of
> behavior, and we may have to revert it if it causes any issues.
>
> The most likely issue it would cause is that some program uses
> select() with an fd mask with extra garbage in it, and stale fd bits
> that pointed to closed file descriptors used to just be ignored. Now
> they'll cause select() to return immediately with those bits set.
That's not quite true. max_select_fd() called from do_select() will bail
with -EBADF if any set contains a bit that is not in
current->files->open_fds. So what you describe will already end with -EBADF
from select(2) regardless of my patch. But yes, if fd becomes invalid while
select(2) is already running, then the patch changes behavior. OTOH
applications messing with file table from another thread while select is
running should be much rarer.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
