On Tue, 2024-06-18 at 16:38 +0200, Alexander Potapenko wrote: > On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich <i...@linux.ibm.com> > wrote: > > > > Even though the KMSAN warnings generated by memchr_inv() are > > suppressed > > by metadata_access_enable(), its return value may still be > > poisoned. > > > > The reason is that the last iteration of memchr_inv() returns > > `*start != value ? start : NULL`, where *start is poisoned. Because > > of > > this, somewhat counterintuitively, the shadow value computed by > > visitSelectInst() is equal to `(uintptr_t)start`. > > > > The intention behind guarding memchr_inv() behind > > metadata_access_enable() is to touch poisoned metadata without > > triggering KMSAN, so unpoison its return value. > > What do you think about applying __no_kmsan_checks to these functions > instead?
Ok, will do. The __no_kmsan_checks approach is already taken by "mm: kfence: Disable KMSAN when checking the canary", so we might as well be consistent in how we fix these issues.
