On Wed, Oct 10, 2018 at 04:09:25PM +0200, Andrey Konovalov wrote: > On Wed, Oct 3, 2018 at 7:32 PM, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > On Tue, Oct 02, 2018 at 03:12:42PM +0200, Andrey Konovalov wrote: [...] > > Also, how is user space supposed to know that it can now pass tagged > > pointers into the kernel? An ABI change (or relaxation), needs to be > > advertised by the kernel, usually via a new HWCAP bit (e.g. HWCAP_TBI). > > Once we have a HWCAP bit in place, we need to be pretty clear about > > which syscalls can and cannot cope with tagged pointers. The "as of now" > > implies potential further relaxation which, again, would need to be > > advertised to user in some (additional) way. > > How exactly should I do that? Something like this [1]? Or is it only > for hardware specific things and for this patchset I need to do > something else? > > [1] https://github.com/torvalds/linux/commit/7206dc93a58fb76421c4411eefa3c003337bcb2d Thinking some more on this, we should probably keep the HWCAP_* bits for actual hardware features. Maybe someone else has a better idea (the linux-abi list?). An option would be to make use of AT_FLAGS auxv (currently 0) in Linux. I've seen some MIPS patches in the past but nothing upstream. Yet another option would be for the user to probe on some innocuous syscall currently returning -EFAULT on tagged pointer arguments but I don't particularly like this. > >> - - pointer arguments to system calls, including pointers in structures > >> - passed to system calls, > >> + - pointer arguments (including pointers in structures), which don't > >> + describe virtual memory ranges, passed to system calls > > > > I think we need to be more precise here... > > In what way? In the way of being explicit about which syscalls support tagged pointers, unless we find a good reason to support tagged pointers on all syscalls and avoid any lists. -- Catalin
