linux-kernel - Re: [PATCH v4 4/9] binder: remove struct binder_lru

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zz7LjZcjg0wdJVc3@google.com>
Date: Thu, 21 Nov 2024 05:56:29 +0000
From: Carlos Llamas <cmllamas@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Christian Brauner <brauner@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	linux-kernel@...r.kernel.org, kernel-team@...roid.com,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>
Subject: Re: [PATCH v4 4/9] binder: remove struct binder_lru_page

On Wed, Nov 20, 2024 at 02:45:21AM +0000, Matthew Wilcox wrote:
> On Tue, Nov 19, 2024 at 08:16:07PM +0000, Carlos Llamas wrote:
> > If you are planning to keep page->private, I think we can just hang our
> > binder items in there. Something like...
> > 
> > 	struct binder_page_items *bp;
> > 	struct page *p;
> > 
> > 	bp = kzalloc(sizeof(*bp), GFP_KERNEL);
> > 	bp->alloc = alloc;
> > 	INIT_LIST_HEAD(&bp->lru);
> > 	bp->index = index;
> > 
> > 	p = alloc_page(...);
> > 	p->private = (unsigned long)bp;
> > 
> > This would be absolutely fine in binder. Is this what you had in mind
> > for current users of page->lru?
> 
> Something like that, yes.  Although you wouldn't even need to use
> page->private for it; you'd be able to use page->memdesc directly,
> and then not be in the way of shrinking to 8 bytes.

We can manually manage in binder the page bits you need to offload. No
problems there. It seems this would require an extra pointer to tie the
two pieces together but this should be compensated with other pages in
the system (I guess).

>From my end, it doesn't really matter if page->lru and others are within
struct page or offloaded, as long as I can avoid duplication. The total
amount of wasted memory here is significant for us.

But like I said, I'll be happy to switch binder to any replacement that
is provided in the future. I won't be in the way!

Thanks
--
Carlos Llamas