Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3482999ybk; Tue, 19 May 2020 05:56:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwsnvgcKQLRP9BBZ/xZ3bWBYbXAw2aFgAYlS3Hwehuldqtc+e0mBcp3tbiA1GGYX+EWYFF/ X-Received: by 2002:a05:6402:417:: with SMTP id q23mr18684304edv.139.1589892969531; Tue, 19 May 2020 05:56:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589892969; cv=none; d=google.com; s=arc-20160816; b=xzgr3wchEfpbvjcAGOCzllpQfS37VvJrYu5j0DkA3mkKnI0SJyu3WH8GLnq5ZPkwKQ Mipn20ymO/zEamRfeUH7eXPoi8nkcIH8o/EiGEs8tgB14eI4mKojnYtO4q04DfxmcTs4 lCjUDcJRb5E8oflK6uauPZqA5iJZf+U7Abpw+GETKkBn8zqhUBoM6WVUvy/xaEzDOrKf NVAVzmXhRgd3Ptrbw54zgCI/A35HLWpbX9qmXdFyNjQpQ51mazgBGss3B0efwIQnCX4u wUY/DLO26nMYDk3oDJ97HVBZLzw01Y7P72EiXECk9iy/o8evgtj4eNoJiOtxE6DwR0y7 C51g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=G+3IDjSQe5T10VvQiPvHkruTfhZCDaHQP43VPDmYK54=; b=kO/hziRYuzKPP26oNaUwY4o/HmEBjWO3zzQEHrLb7s7DX6PB/dhFH5TWQLhSneK6Tq k+axW8fqKbBuRyJs9sVTAwzOYX6lsbrjYhL3g1UTT2sXUXuBpCx3M8EnBTGDQzhLZiTk 62TnZwGRWaP8CmLN3eEXudh8Mgdtqhkt8HCqBV1BcCcypsReAhP9kHXUUCaCIOe28H1K +4yfFWdXTrkUnqHmlgfMMUvv98BMY2sIqgNK0lJUThEhI8AXyvf3yPFC2AuLTtaKO7ND 3XRdgiJ/CWLcOA0QzPOhvIDmD+8vA20lcSfONGJ9E1dzG7UpRCBoxPX4ERB2aEF9HukG +brw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="g7s/gYo8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w23si97382eju.658.2020.05.19.05.55.45; Tue, 19 May 2020 05:56:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="g7s/gYo8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728725AbgESMyU (ORCPT + 99 others); Tue, 19 May 2020 08:54:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726169AbgESMyT (ORCPT ); Tue, 19 May 2020 08:54:19 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABEDEC08C5C0 for ; Tue, 19 May 2020 05:54:19 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id x13so6493465pfn.11 for ; Tue, 19 May 2020 05:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=G+3IDjSQe5T10VvQiPvHkruTfhZCDaHQP43VPDmYK54=; b=g7s/gYo884AOa/REioKbv6xPC+XS8JEcyTOZyZEftWHVNi/AZkMMQsZCrSmVvTpnrY bMRpbEGj1TuqSCh8GzKZKNV2c8wazABvcuQUMy7/gne30Botlu0xqkZWtMfZnocLBrAL 5fHnoBkjUSpCsvv4ff5Lyilg4RosPraY7un+SosIxJugMcYwUxvuShZD52/PUEA7ckre SDQBDX0gJ4eV4NOkL9xRDvonfqT2qH72tVBPA4oqOYpNQY7R0o72PIvznWWOmjOj/FE3 SsXorFaRT57g8d11sap/nnAvuVo/FxRunltRAhhi5NchyGxxAMaiPu9d4zBPLyuY1kNX il2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=G+3IDjSQe5T10VvQiPvHkruTfhZCDaHQP43VPDmYK54=; b=VnV5/UnBXB5w0gqPiLvc+/1UFIFqfUm1IEhvsyDKs6ERYgYpmz1MH/JEkOgchy6l1w nCLiM+hENnPZ/e6Gn2eOkU5yId9xA8Iy1Z9QpIGg3hJ0frsIQp4mORtnzSHv+uHz5rSs v3pQZaKWOEHQJeGA4PdGZmNJaJhUjegzzouZvpiqn/AocYBvRmCsRsVX+xs07MSmQVzk rThuj/HTlEBPhnJwiSm2BOnSVX39I1kM942jlgw6IqklTw4lHNDOy/OsGuW/lbiK85KV vOiEV11BqNLyQuaMuK5ewrtZIZ3ZhKK6SWvPrsERvvp5KvizOsaXaywZIomD/rFufwHV SQIQ== X-Gm-Message-State: AOAM533/i6AkChKROkdsT44pbctEuZeJ/reaTFHa+l4NeeQNujy6UJWN aM6VZS1NP7MH26g5Kc4BXR8xMEpE3Fw= X-Received: by 2002:a63:7d58:: with SMTP id m24mr17701283pgn.81.1589892858921; Tue, 19 May 2020 05:54:18 -0700 (PDT) Received: from google.com ([2620:15c:2cd:202:2523:d194:de3b:636f]) by smtp.gmail.com with ESMTPSA id q7sm9932171pgs.13.2020.05.19.05.54.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2020 05:54:17 -0700 (PDT) Date: Tue, 19 May 2020 05:54:15 -0700 From: Michel Lespinasse To: Vlastimil Babka Cc: Andrew Morton , linux-mm , LKML , Peter Zijlstra , Laurent Dufour , Matthew Wilcox , Liam Howlett , Jerome Glisse , Davidlohr Bueso , David Rientjes , Hugh Dickins , Ying Han , Jason Gunthorpe , Daniel Jordan Subject: Re: [PATCH v5 06/10] mmap locking API: convert nested write lock sites Message-ID: <20200519125415.GA189720@google.com> References: <20200422001422.232330-1-walken@google.com> <20200422001422.232330-7-walken@google.com> <6a23fcce-181b-01ad-4a83-ea24d07ac724@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a23fcce-181b-01ad-4a83-ea24d07ac724@suse.cz> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 18, 2020 at 12:32:03PM +0200, Vlastimil Babka wrote: > On 4/22/20 2:14 AM, Michel Lespinasse wrote: > > Add API for nested write locks and convert the few call sites doing that. > > > > Signed-off-by: Michel Lespinasse > > Reviewed-by: Daniel Jordan > > Reviewed-by: Vlastimil Babka > > Perhaps we could even move SINGLE_DEPTH_NESTING into the wrapper? It's unlikely > there will be a new user with a different subclass? I think I'll leave it in the API for now. I don't foresee new uses being added as long as we stick to coarse mmap locking, but if extending the api to support range locking it'd become more likely that we'd want to lock multiple ranges for mremap... -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.