[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com>
Date: Thu, 12 May 2022 14:51:31 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"H . J . Lu" <hjl.tools@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 00/10] Linear Address Masking enabling
On 5/12/22 12:39, Thomas Gleixner wrote:
>> It's OK for a debugging build that runs on one kind of hardware. But,
>> if we want LAM-using binaries to be portable, we have to do something
>> different.
>>
>> One of the stated reasons for adding LAM hardware is that folks want to
>> use sanitizers outside of debugging environments. To me, that means
>> that LAM is something that the same binary might run with or without.
> On/off yes, but is there an actual use case where such a mechanism would
> at start time dynamically chose the number of bits?
I'd love to hear from folks doing the userspace side of this. Will
userspace be saying: "Give me all the bits you can!". Or, will it
really just be looking for 6 bits only, and it doesn't care whether it
gets 6 or 15, it will use only 6?
Do the sanitizers have more overhead with more bits? Or *less* overhead
because they can store more metadata in the pointers?
Will anyone care about the difference about potentially missing 1/64
issues with U57 versus 1/32768 with U48?
Powered by blists - more mailing lists