Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 4 Feb 2022 14:41:33 -0800
From:   Michel Lespinasse <michel@lespinasse.org>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Michel Lespinasse <michel@lespinasse.org>,
        Linux-MM <linux-mm@kvack.org>, linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, kernel-team@fb.com,
        Laurent Dufour <ldufour@linux.ibm.com>,
        Jerome Glisse <jglisse@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Michal Hocko <mhocko@suse.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Liam Howlett <liam.howlett@oracle.com>,
        Rik van Riel <riel@surriel.com>,
        Paul McKenney <paulmck@kernel.org>,
        Song Liu <songliubraving@fb.com>,
        Suren Baghdasaryan <surenb@google.com>,
        Minchan Kim <minchan@google.com>,
        Joel Fernandes <joelaf@google.com>,
        David Rientjes <rientjes@google.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH v2 12/35] mm: separate mmap locked assertion from find_vma
Message-ID: <20220204224133.GA1559@lespinasse.org>
References: <20220128131006.67712-1-michel@lespinasse.org>
 <20220128131006.67712-13-michel@lespinasse.org>
 <Yff152H3FFVdQBfy@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yff152H3FFVdQBfy@casper.infradead.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Mon, Jan 31, 2022 at 02:44:55PM +0000, Matthew Wilcox wrote:
> On Fri, Jan 28, 2022 at 05:09:43AM -0800, Michel Lespinasse wrote:
> > This adds a new __find_vma() function, which implements find_vma minus
> > the mmap_assert_locked() assertion.
> > 
> > find_vma() is then implemented as an inline wrapper around __find_vma().
> 
> You might like to take inspiration from the maple tree patches
> where we assert that either the RCU lock is held or the mmap_lock
> is held.

I've been considering it, but I'm not sure we want to go that way:
it's not sufficient for the caller to have an RCU read lock,
they also need to do the proper mmap_seq_read_check() after
dereferencing the vma... So I think having this different set of
expectations for the two cases warrants using a different name
to keep things more explicit.

--
Michel "walken" Lespinasse