[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZWmOU4qayU7hZVQt@google.com>
Date: Fri, 1 Dec 2023 07:42:11 +0000
From: Carlos Llamas <cmllamas@...gle.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Arve Hjønnevåg <arve@...roid.com>,
Christian Brauner <brauner@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Joel Fernandes <joel@...lfernandes.org>,
kernel-team@...roid.com, linux-kernel@...r.kernel.org,
Martijn Coenen <maco@...roid.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Todd Kjos <tkjos@...roid.com>
Subject: Re: [PATCH 20/21] binder: reverse locking order in shrinker callback
On Tue, Nov 07, 2023 at 09:08:46AM +0000, Alice Ryhl wrote:
> Carlos Llamas <cmllamas@...gle.com> writes:
> This reverses the order so that __free_page is called before
> zap_page_range_single. Is that okay?
It is not OK. Userspace would still have access to the page between
__free_page() and zap_page() calls. This is bad, so thanks for catching
this.
> Another option would be to do something along these lines:
>
> page_to_free = page->page_ptr;
> page->page_ptr = NULL;
>
> [snip]
>
> mmap_read_unlock(mm);
> mmput_async(mm);
> __free_page(page_to_free);
>
> This way you wouldn't reverse the order. Also, you reduce the amount of
> time you spend holding the mmap read lock, since the page is freed
> without holding the lock.
>
Thanks, I've added this approach to v2.
--
Carlos Llamas
Powered by blists - more mailing lists