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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 D377EC433E0 for ; Tue, 22 Dec 2020 20:17:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F878229C6 for ; Tue, 22 Dec 2020 20:17:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727790AbgLVUQs (ORCPT ); Tue, 22 Dec 2020 15:16:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725850AbgLVUQr (ORCPT ); Tue, 22 Dec 2020 15:16:47 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F79CC0613D3; Tue, 22 Dec 2020 12:16:07 -0800 (PST) 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.