From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE416C433E0 for ; Thu, 11 Feb 2021 14:26:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6303464E14 for ; Thu, 11 Feb 2021 14:26:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6303464E14 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C51466B00F8; Thu, 11 Feb 2021 09:26:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C00F86B00F9; Thu, 11 Feb 2021 09:26:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3FFD6B00FA; Thu, 11 Feb 2021 09:26:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id A1CF96B00F8 for ; Thu, 11 Feb 2021 09:26:41 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6FAE71EE6 for ; Thu, 11 Feb 2021 14:26:41 +0000 (UTC) X-FDA: 77806213002.15.34800DC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 9A84A90009D6 for ; Thu, 11 Feb 2021 14:26:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sj97A1FDFENPqakt33g1HE1eopZz9zZrknGdche1pZw=; b=UI6wmsC6f1Q37cjg5BZyBtHJK1 NgBK1KBg3ulPKm84h15eY0H938wnq0Ps9/n1u9LO7MNAuB8dO2cSNpEsRRGDMnSFSVqPjkNQNPkxQ 0s3dUvDykwFUiS1JgCJvm9e83li1rD3un+G12IdJuH2TPjsskW09hILEgrzLpZez7Nyo+r+e2IkD5 xlwul7xkjZAaGtyb8wdEeFwtQaxMKvgVHg3kXLgpz+OWYfTLS4C0Z1po7Fu92QncBpomMIfF2bUjB vVua5Xbw/7u3/EQ/EuCk1PZMqColbfywnDrrRYdO1PmfjzL9XrUbQJX3nWlH7RtmE70CjbeveXerQ XvSyGqLA==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lACvO-00ALJC-39; Thu, 11 Feb 2021 14:26:31 +0000 Date: Thu, 11 Feb 2021 14:26:30 +0000 From: Matthew Wilcox To: Michal Hocko Cc: Jan Kara , Dmitry Vyukov , syzbot , Jan Kara , linux-ext4@vger.kernel.org, LKML , syzkaller-bugs , Theodore Ts'o , Linux-MM Subject: Re: possible deadlock in start_this_handle (2) Message-ID: <20210211142630.GK308988@casper.infradead.org> References: <000000000000563a0205bafb7970@google.com> <20210211104947.GL19070@quack2.suse.cz> <20210211121020.GO19070@quack2.suse.cz> <20210211125717.GH308988@casper.infradead.org> <20210211132533.GI308988@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 3px9gczp8e6zc1dxtu8s4hrwm75wftaw X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9A84A90009D6 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613053598-500786 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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".