linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Jan Kara <jack@suse.cz>, Dmitry Vyukov <dvyukov@google.com>,
	syzbot <syzbot+bfdded10ab7dcd7507ae@syzkaller.appspotmail.com>,
	Jan Kara <jack@suse.com>,
	linux-ext4@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Theodore Ts'o <tytso@mit.edu>, Linux-MM <linux-mm@kvack.org>
Subject: Re: possible deadlock in start_this_handle (2)
Date: Thu, 11 Feb 2021 14:26:30 +0000	[thread overview]
Message-ID: <20210211142630.GK308988@casper.infradead.org> (raw)
In-Reply-To: <YCU9OR7SfRpwl4+4@dhcp22.suse.cz>

On Thu, Feb 11, 2021 at 03:20:41PM +0100, Michal Hocko wrote:
> On Thu 11-02-21 13:25:33, Matthew Wilcox wrote:
> > On Thu, Feb 11, 2021 at 02:07:03PM +0100, Michal Hocko wrote:
> > > On Thu 11-02-21 12:57:17, Matthew Wilcox wrote:
> > > > > current->flags should be always manipulated from the user context. But
> > > > > who knows maybe there is a bug and some interrupt handler is calling it.
> > > > > This should be easy to catch no?
> > > > 
> > > > Why would it matter if it were?
> > > 
> > > I was thinking about a clobbered state because updates to ->flags are
> > > not atomic because this shouldn't ever be updated concurrently. So maybe
> > > a racing interrupt could corrupt the flags state?
> > 
> > I don't think that's possible.  Same-CPU races between interrupt and
> > process context are simpler because the CPU always observes its own writes
> > in order and the interrupt handler completes "between" two instructions.
> 
> I have to confess I haven't really thought the scenario through. My idea
> was to simply add a simple check for an irq context into ->flags setting
> routine because this should never be done in the first place. Not only
> for scope gfp flags but any other PF_ flags IIRC.

That's not automatically clear to me.  There are plenty of places
where an interrupt borrows the context of the task that it happens to
have interrupted.  Specifically, interrupts should be using GFP_ATOMIC
anyway, so this doesn't really make a lot of sense, but I don't think
it's necessarily wrong for an interrupt to call a function that says
"Definitely don't make GFP_FS allocations between these two points".


  reply	other threads:[~2021-02-11 14:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000000000000563a0205bafb7970@google.com>
2021-02-11 10:49 ` possible deadlock in start_this_handle (2) Jan Kara
2021-02-11 10:55   ` Michal Hocko
2021-02-11 11:22   ` Dmitry Vyukov
2021-02-11 11:28     ` Dmitry Vyukov
2021-02-11 12:10       ` Jan Kara
2021-02-11 12:34         ` Michal Hocko
2021-02-11 12:57           ` Matthew Wilcox
2021-02-11 13:07             ` Michal Hocko
2021-02-11 13:25               ` Matthew Wilcox
2021-02-11 14:20                 ` Michal Hocko
2021-02-11 14:26                   ` Matthew Wilcox [this message]
2021-02-11 16:41                     ` Michal Hocko
2021-02-12 11:18                       ` Tetsuo Handa
2021-02-12 12:22                         ` Matthew Wilcox
2021-02-12 12:30                           ` Michal Hocko
2021-02-12 12:58                             ` Tetsuo Handa
2021-02-12 13:12                               ` Michal Hocko
2021-02-12 13:34                                 ` Tetsuo Handa
2021-02-12 15:43                               ` Michal Hocko
2021-02-13 10:58                                 ` Dmitry Vyukov
2021-02-11 13:18             ` Dmitry Vyukov
2021-02-11 11:46     ` Jan Kara
2021-02-13 14:26   ` Tetsuo Handa
2021-02-15 12:45     ` Jan Kara
2021-02-15 14:06       ` Tetsuo Handa
2021-02-15 14:29         ` Jan Kara
2021-02-19 10:15           ` Tetsuo Handa
2021-02-19 17:22             ` harshad shirwadkar
2021-03-20 10:02           ` Tetsuo Handa

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=20210211142630.GK308988@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=dvyukov@google.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=syzbot+bfdded10ab7dcd7507ae@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tytso@mit.edu \
    /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).