On Thu, May 12, 2022 at 2:51 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > 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? The only LAM usage I know so far is LAM_U57 in HWASAN. An application can ask for LAM_U48 or LAM_U57. But the decision should be made by application. When an application asks for LAM_U57, I expect it will store tags in upper 6 bits, even if the kernel enables LAM_U48. -- H.J.
