All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Llamas <cmllamas@google.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <brauner@kernel.org>,
	linux-kernel@vger.kernel.org, kernel-team@android.com,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [PATCH v5 9/9] binder: use per-vma lock in page reclaiming
Date: Tue, 26 Nov 2024 23:32:42 +0000	[thread overview]
Message-ID: <Z0ZamgSUxuuae0KP@google.com> (raw)
In-Reply-To: <CAJuCfpFZ3L-OvZEdhCipx17=A9yMFNWfuaWVN-BDrbXjce=v-w@mail.gmail.com>

On Tue, Nov 26, 2024 at 12:05:58PM -0800, Suren Baghdasaryan wrote:
> On Tue, Nov 26, 2024 at 11:11 AM Carlos Llamas <cmllamas@google.com> wrote:
> >
> > On Tue, Nov 26, 2024 at 10:46:03AM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Nov 26, 2024 at 10:45 AM Suren Baghdasaryan <surenb@google.com> wrote:
> > > >
> > > > You did add a clarifying comment I asked for in
> > > > https://lore.kernel.org/all/CAJuCfpESdY4L_sSwiCYVCX+5y1WOuAjLNPw35pEGzTSyoHFYPA@mail.gmail.com/
> > >
> > > s/did/did not
> >
> > Oh, I added the comment to patch 5/9 since it fits better there (sorry
> > that I forgot to mention this). Now the kerneldoc section reads:
> >
> > + * @mapped:             whether the vm area is mapped, each binder instance is
> > + *                      allowed a single mapping throughout its lifetime
> >
> > ... and the vma check now has the following comment:
> >
> > +       /* ensure the vma corresponds to the binder mapping */
> 
> I think the above comment does not explain the race we are trying to avoid here.
> Something like this perhaps:
> /*
>  * binder does not allow mapping of the same buffer more than once, therefore
>  * alloc->vm_start could not have changed since the buffer can't be remapped.
>  * Checking binder_alloc_is_mapped() ensures that the vma is mapped and still
>  * covers the same area.
>  */

Right, that is the message I tried to convey: (1) Each binder instance
is allowed a single mapping throughout its lifetime (no re-mapping).
(2) alloc->mapped gets cleared when this mapping is removed e.g. during
vm_ops->close(). Putting 1 and 2 together... whenever binder looks up a
vma it also checks alloc->mapped to verify its mapping is still opened
and avoid poking into some other unrelated vma.

I tried writing a concise explanation but I guess it was not enough.

Note this unusual behavior is nothing new in binder and predates this
patchset, but I agree it needs to be documented somewhere. I'll send out
a new version attempting to document this better. It's a little tricky
though, since the same vma validation pattern is in multiple places and
obviously I don't want to duplicate the paragraph everywhere.

Maybe I can inline a "binder_vma_check()" and put the explanation there.
I'll think of something.

Cheers,
Carlos Llamas

      reply	other threads:[~2024-11-26 23:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 18:40 [PATCH v5 0/9] binder: faster page installations Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 1/9] Revert "binder: switch alloc->mutex to spinlock_t" Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 2/9] binder: concurrent page installation Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 3/9] binder: select correct nid for pages in LRU Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 4/9] binder: remove struct binder_lru_page Carlos Llamas
2024-11-26 19:46   ` Matthew Wilcox
2024-11-26 22:38     ` Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 5/9] binder: replace alloc->vma with alloc->mapped Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 6/9] binder: rename alloc->buffer to vm_start Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 7/9] binder: use per-vma lock in page installation Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 8/9] binder: propagate vm_insert_page() errors Carlos Llamas
2024-11-26 18:40 ` [PATCH v5 9/9] binder: use per-vma lock in page reclaiming Carlos Llamas
2024-11-26 18:45   ` Suren Baghdasaryan
2024-11-26 18:46     ` Suren Baghdasaryan
2024-11-26 19:11       ` Carlos Llamas
2024-11-26 20:05         ` Suren Baghdasaryan
2024-11-26 23:32           ` Carlos Llamas [this message]

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=Z0ZamgSUxuuae0KP@google.com \
    --to=cmllamas@google.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=arve@android.com \
    --cc=brauner@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@joelfernandes.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=surenb@google.com \
    --cc=tkjos@android.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.