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 0A14EC433DB for ; Tue, 22 Dec 2020 20:16:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ECCA9229C5 for ; Tue, 22 Dec 2020 20:16:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECCA9229C5 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 3836B6B009D; Tue, 22 Dec 2020 15:16:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 335346B009E; Tue, 22 Dec 2020 15:16:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 271568D0003; Tue, 22 Dec 2020 15:16:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 10E216B009D for ; Tue, 22 Dec 2020 15:16:08 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B8F20181AEF30 for ; Tue, 22 Dec 2020 20:16:07 +0000 (UTC) X-FDA: 77622024774.29.toy47_4a0896927462 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 93362180868DC for ; Tue, 22 Dec 2020 20:16:07 +0000 (UTC) X-HE-Tag: toy47_4a0896927462 X-Filterd-Recvd-Size: 3784 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 20:16:05 +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=Eb4oYoqAZRfDz+/ydpDOyvDen++mgZRQ1xf6qRXS0jM=; b=Kihezujl/NgUHtFjqSIBp8508s psorRppd6ox/i/CY4WCRNyeLoeD57xRUpTBde984iYXHEW1IxLx/H7a+kbfXZH2dEJGBMz66om6Po hVa523arlguvIchso5pVuVWOKfffwBthl4KDEeAMBnA/TnLCa96oDvgYur1Kc/5leh366YtOIdxlU flB5B4SVpg5sN80NPoDn75QhtxTgbaPrGXPj+wHLnGwuZ1opwVBYcWtfmftnPMDowDOtB2bKZRgeJ pkPpyqCsTR3dYQYTG6bD4CZH/VLVhLb4Ma/hnZtbTUmSc5vEuxEUK5BCYhnPmU0FBHmKrbLcWQDz/ /AzjaH/g==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kro4X-0002uj-Ti; Tue, 22 Dec 2020 20:15:54 +0000 Date: Tue, 22 Dec 2020 20:15:53 +0000 From: Matthew Wilcox To: Andrea Arcangeli Cc: Andy Lutomirski , Linus Torvalds , Peter Xu , Nadav Amit , Yu Zhao , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Will Deacon , Peter Zijlstra , Kent Overstreet Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: <20201222201553.GM874@casper.infradead.org> References: <9E301C7C-882A-4E0F-8D6D-1170E792065A@gmail.com> <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> <20201221223041.GL6640@xz-x1> 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 Tue, Dec 22, 2020 at 02:31:52PM -0500, Andrea Arcangeli wrote: > My previous suggestion to use a mutex to serialize > userfaultfd_writeprotect with a mutex will still work, but we can run > as many wrprotect and un-wrprotect as we want in parallel, as long as > they're not simultaneous, we can do much better than a mutex. > > Ideally we would need a new two_group_semaphore, where each group can > run as many parallel instances as it wants, but no instance of one > group can run in parallel with any instance of the other group. AFIK > such a kind of lock doesn't exist right now. Kent and I worked on one for a bit, and we called it a red-black mutex. If team red had the lock, more members of team red could join in. If team black had the lock, more members of team black could join in. I forget what our rule was around fairness (if team red has the lock, and somebody from team black is waiting, can another member of team red take the lock, or must they block?) It was to solve the direct-IO vs buffered-IO problem (you can have as many direct-IO readers/writers at once or you can have as many buffered-IO readers/writers at once, but exclude a mix of direct and buffered I/O). In the end, we decided it didn't work all that well.