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 8FE81C433E0 for ; Thu, 11 Feb 2021 13:25:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAD6C60238 for ; Thu, 11 Feb 2021 13:25:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAD6C60238 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 4162C6B00F0; Thu, 11 Feb 2021 08:25:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 39DB76B00F1; Thu, 11 Feb 2021 08:25:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28D426B00F2; Thu, 11 Feb 2021 08:25:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 100246B00F0 for ; Thu, 11 Feb 2021 08:25:48 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D1CFA181AEF15 for ; Thu, 11 Feb 2021 13:25:47 +0000 (UTC) X-FDA: 77806059534.10.prose67_350b5f727618 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id AC8EF16A0AE for ; Thu, 11 Feb 2021 13:25:47 +0000 (UTC) X-HE-Tag: prose67_350b5f727618 X-Filterd-Recvd-Size: 3768 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Thu, 11 Feb 2021 13:25:45 +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=7Zj6jFAS+43OA9xryJ9Sq954x04SppEwar4znZPx9xs=; b=WfRimx5FHijTwPQj7TC/MRA2qw XdqVvkmsjawqktNsX27cT8MSQHul4JBuIDryEYK83ezFS3WTGXftzxVQnGs/DewS/bUNry+5y8bJA 1iGdiNZr7SyIW8PpSqBpaMEb6+vzBjTJCwPBKML1Os01dP5K6rLD68MfH+jwao3Y3uaS3iAqnB5q7 UuzYK1TlkiDAZfFLtvyxy5SZNYNX2wcJna/ix2xTcu7ncmH4O4nDE0TxpFWK/tu5aJfZo5BURfKle htvDfxOr9GmAvr0HkDzOC8Zl8+mf02HxTzmrNaQD7fqobaC3oZBWVVyBNg79IT0yL2/r1FNi8gYt3 RR8rRK9A==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lAByP-00AHMu-21; Thu, 11 Feb 2021 13:25:33 +0000 Date: Thu, 11 Feb 2021 13:25:33 +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: <20210211132533.GI308988@casper.infradead.org> References: <000000000000563a0205bafb7970@google.com> <20210211104947.GL19070@quack2.suse.cz> <20210211121020.GO19070@quack2.suse.cz> <20210211125717.GH308988@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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. eg a load-store CPU will do: load 0 from address A or 8 with result store 8 to A Two CPUs can do: CPU 0 CPU 1 load 0 from A load 0 from A or 8 with 0 or 4 with 0 store 8 to A store 4 to A and the store of 8 is lost. process interrupt load 0 from A load 0 from A or 4 with 0 store 4 to A or 8 with 0 store 8 to A so the store of 4 would be lost. but we expect the interrupt handler to restore it. so we actually have this: load 0 from A load 0 from A or 4 with 0 store 4 to A load 4 from A clear 4 from 4 store 0 to A or 8 with 0 store 8 to A If we have a leak where someone forgets to restore the nofs, that might cause this. We could check for the allocation mask bits being clear at syscall exit (scheduling with these flags set is obviously ok).