From: Al Viro <viro@zeniv.linux.org.uk>
To: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>, Song Liu <songliubraving@fb.com>
Subject: Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
Date: Fri, 8 Jan 2021 06:47:20 +0000 [thread overview]
Message-ID: <20210108064720.GO3579531@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+icZUWZePRQ6h8TLekp3EMNvLG22o4stV7OaGVCnm9VeX6d=w@mail.gmail.com>
On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote:
> On Fri, Jan 8, 2021 at 6:30 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> > > it down to the below patch. Debugging this issue, turns out that the boot
> > > stalled when a task is waiting on a pipe being released. As we no longer
> > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> > > task goes idle without running the task_work. This prevents ->release()
> > > from being called on the pipe, which another boot task is waiting on.
> > >
> > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> > > goes idle.
> > >
> > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> > > Reported-by: Song Liu <songliubraving@fb.com>
> > > Signed-off-by: Jens Axboe <axboe@kernel.dk>
> > >
> > > ---
> > >
> > > The other alternative here is obviously to re-instate the:
> > >
> > > if (unlikely(current->task_works))
> > > task_work_run();
> > >
> > > in get_signal() that we had before this change. Might be safer in case
> > > there are other cases that need to ensure the work is run in a timely
> > > fashion, though I do think it's cleaner to long term to correctly mark
> > > task_work with the needed notification type. Comments welcome...
> >
> > Interesting... I think I've missed the discussion of that thing; could
> > you forward the relevant thread my way or give an archive link to it?
>
> See [1].
>
> - Sedat -
>
> [1] https://marc.info/?t=160987156600001&r=1&w=2
Thanks; will check tomorrow.
next prev parent reply other threads:[~2021-01-08 6:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-05 18:29 [PATCH] fs: process fput task_work with TWA_SIGNAL Jens Axboe
2021-01-07 22:17 ` Doug Anderson
2021-01-08 3:52 ` Jens Axboe
2021-01-08 6:20 ` Sedat Dilek
2021-01-08 5:26 ` Al Viro
2021-01-08 6:21 ` Sedat Dilek
2021-01-08 6:47 ` Al Viro [this message]
2021-01-08 6:52 ` Al Viro
2021-01-08 6:46 ` Al Viro
2021-01-08 15:13 ` Jens Axboe
2021-01-08 15:58 ` Al Viro
2021-01-08 16:10 ` Jens Axboe
2021-01-08 16:26 ` Jens Axboe
2021-01-08 18:05 ` Al Viro
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=20210108064720.GO3579531@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=sedat.dilek@gmail.com \
--cc=songliubraving@fb.com \
/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.