All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Lespinasse <walken@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Laurent Dufour <ldufour@linux.ibm.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Liam Howlett <Liam.Howlett@oracle.com>,
	Jerome Glisse <jglisse@redhat.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	David Rientjes <rientjes@google.com>,
	Hugh Dickins <hughd@google.com>, Ying Han <yinghan@google.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Daniel Jordan <daniel.m.jordan@oracle.com>
Subject: Re: [PATCH v5 10/10] mmap locking API: rename mmap_sem to mmap_lock
Date: Thu, 23 Apr 2020 18:26:12 -0700	[thread overview]
Message-ID: <20200424012612.GA158937@google.com> (raw)
In-Reply-To: <20200423015917.GA13910@bombadil.infradead.org>

On Wed, Apr 22, 2020 at 06:59:17PM -0700, Matthew Wilcox wrote:
> On Wed, Apr 22, 2020 at 03:54:32PM -0700, Michel Lespinasse wrote:
> > On Tue, Apr 21, 2020 at 6:58 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Tue, Apr 21, 2020 at 05:14:22PM -0700, Michel Lespinasse wrote:
> > > > Rename the mmap_sem field to mmap_lock. Any new uses of this lock
> > >
> > > Shouldn't some of these be folded into the previous patch?
> > 
> > So, I didn't do it because previous patch only handled rwsem_is_locked
> > call sites. I leaned towards adding as few new API functions as
> > possible until we figure out exactly what is required.
> > 
> > That said, I agree it seems reasonable to split mmap_assert_locked()
> > into mmap_assert_read_locked() and mmap_assert_write_locked(), and
> > convert the lockdep asserts to use these instead.
> 
> Just add mmap_assert_write_locked() -- some of these places can be called
> with the rwsem held for either read or write; it doesn't matter which.
> Others need it held for write.  There aren't any places (that I'm aware
> of) that need to assert that it's held for read, and not held for write.
> 
> > I'm not sure we need to do it right away though; we are at least not
> > losing any test coverage with the existing version of the patchset...
> 
> It seems like a better way to remove users of the term 'mmap_sem' than
> just converting them to use the new 'mmap_lock'.

Hmmm, OK. I updated changes 09/10 and 10/10 based on this feedback. I
do not want to resend the entire series, so I am going to send just
these two changes as replies to this message and call these v5.5 :)

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

  reply	other threads:[~2020-04-24  1:26 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22  0:14 [PATCH v5 00/10] Add a new mmap locking API wrapping mmap_sem calls Michel Lespinasse
2020-04-22  0:14 ` Michel Lespinasse
2020-04-22  0:14 ` [PATCH v5 01/10] mmap locking API: initial implementation as rwsem wrappers Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18  9:28   ` Vlastimil Babka
2020-05-18 13:18   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 02/10] MMU notifier: use the new mmap locking API Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18  9:28   ` Vlastimil Babka
2020-05-18 13:19   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 03/10] DMA reservations: " Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18  9:30   ` Vlastimil Babka
2020-05-18 13:20   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 04/10] mmap locking API: use coccinelle to convert mmap_sem rwsem call sites Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18  9:36   ` Vlastimil Babka
2020-05-18 13:21   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 05/10] mmap locking API: convert mmap_sem call sites missed by coccinelle Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18  9:44   ` Vlastimil Babka
2020-05-18 13:23   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 06/10] mmap locking API: convert nested write lock sites Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18 10:32   ` Vlastimil Babka
2020-05-19 12:54     ` Michel Lespinasse
2020-05-18 13:24   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 07/10] mmap locking API: add mmap_read_trylock_non_owner() Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18 10:42   ` Vlastimil Babka
2020-04-22  0:14 ` [PATCH v5 08/10] mmap locking API: add MMAP_LOCK_INITIALIZER Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-05-18 10:45   ` Vlastimil Babka
2020-05-19 12:56     ` Michel Lespinasse
2020-05-18 13:33   ` Laurent Dufour
2020-04-22  0:14 ` [PATCH v5 09/10] mmap locking API: add mmap_assert_locked Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-04-22  2:10   ` Michel Lespinasse
2020-04-22  2:10     ` Michel Lespinasse
2020-04-22  2:18     ` Matthew Wilcox
2020-04-24  1:44       ` Michel Lespinasse
2020-04-22  0:14 ` [PATCH v5 10/10] mmap locking API: rename mmap_sem to mmap_lock Michel Lespinasse
2020-04-22  0:14   ` Michel Lespinasse
2020-04-22  1:58   ` Matthew Wilcox
2020-04-22 22:54     ` Michel Lespinasse
2020-04-22 22:54       ` Michel Lespinasse
2020-04-23  1:59       ` Matthew Wilcox
2020-04-24  1:26         ` Michel Lespinasse [this message]
2020-04-24  1:38           ` [PATCH v5.5 09/10] mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked() Michel Lespinasse
2020-05-18 11:01             ` Vlastimil Babka
2020-05-19 13:06               ` Michel Lespinasse
2020-04-24  1:39           ` [PATCH v5.5 10/10] mmap locking API: rename mmap_sem to mmap_lock Michel Lespinasse
2020-05-18 11:07             ` Vlastimil Babka
2020-05-19 13:12               ` Michel Lespinasse
2020-05-18 13:45             ` Laurent Dufour
2020-05-19 13:10               ` Michel Lespinasse
2020-05-19 13:20                 ` Laurent Dufour
2020-05-19 15:32                   ` Matthew Wilcox
2020-05-19 18:14                     ` John Hubbard
2020-05-20  2:39                       ` Michel Lespinasse
2020-05-20  2:39                         ` Michel Lespinasse
2020-05-20  7:32                         ` John Hubbard
2020-05-20  8:02                           ` Michel Lespinasse
2020-05-20  8:02                             ` Michel Lespinasse
2020-05-20 12:48                         ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200424012612.GA158937@google.com \
    --to=walken@google.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.m.jordan@oracle.com \
    --cc=dave@stgolabs.net \
    --cc=hughd@google.com \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=ldufour@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yinghan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.