On Thu, Aug 01, 2019 at 08:36:47AM -0700, Dave Hansen wrote: > On 8/1/19 5:48 AM, Andrey Konovalov wrote: > > On Thu, Aug 1, 2019 at 2:11 PM Kevin Brodsky <kevin.brodsky@xxxxxxx> wrote: > >> On 31/07/2019 17:50, Dave Hansen wrote: > >>> On 7/23/19 10:58 AM, Andrey Konovalov wrote: > >>>> The mmap and mremap (only new_addr) syscalls do not currently accept > >>>> tagged addresses. Architectures may interpret the tag as a background > >>>> colour for the corresponding vma. > >>> > >>> What the heck is a "background colour"? :) > >> > >> Good point, this is some jargon that we started using for MTE, the idea being that > >> the kernel could set a tag value (specified during mmap()) as "background colour" for > >> anonymous pages allocated in that range. > >> > >> Anyway, this patch series is not about MTE. Andrey, for v20 (if any), I think it's > >> best to drop this last sentence to avoid any confusion. Indeed, the part with the "background colour" and even the "currently" adverb should be dropped. Also, if we merge the patches via different trees anyway, I don't think there is a need for Andrey to integrate them with his series. We can pick them up directly in the arm64 tree (once the review finished). > OK, but what does that mean for tagged addresses getting passed to > mmap/mremap? That sentence read to me like "architectures might allow > tags for ...something...". So do we accept tagged addresses into those > syscalls? If mmap() does not return a tagged address, the reasoning is that it should not accept one as an address hint (with or without MAP_FIXED). Note that these docs should only describe the top-byte-ignore ABI while leaving the memory tagging for a future patchset. In that future patchset, we may want to update the mmap() ABI to allow, only in conjunction with PROT_MTE, a tagged pointer as an address argument. In such case mmap() will return a tagged address and the pages pre-coloured (on fault) with the tag requested by the user. As I said, that's to be discussed later in the year. -- Catalin
