On Wed 25-03-20 18:40:29, Alexander Potapenko wrote: > On Wed, Mar 25, 2020 at 6:26 PM Alexander Potapenko <glider@xxxxxxxxxx> wrote: > > > > On Wed, Mar 25, 2020 at 5:19 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > On Wed 25-03-20 17:12:14, glider@xxxxxxxxxx wrote: > > > > This flag is to be used by KMSAN runtime to mark that newly created > > > > memory pages don't need KMSAN metadata backing them. > > > > > > I really dislike an idea of the gfp flag. If you need some form of > > > exclusion for kmsan allocations then follow the pattern of memalloc_no{fs,io}_{save,restore} > > > History tells us that single usecase gfp flags are too tempting to abuse > > > and using incorrectly. > > > > Great idea, will do! > > Guess PF_ flags isn't a scarce resource? > > Actually, no, we are out of bits in current->flags already. > I could introduce a separate flag into struct task, but that won't > work in interrupt contexts - how do you solve that problem for FS/IO > allocations? NOFS/NOIO is not a problem for IRQ context because we never do reclaim from that context. I was also not aware that there are users from the IRQ context. I thought this would be an internal KMSAN stuff. What would be the IRQ context you call this from? Anyway, if you cannot go with the task_struct then a per-cpu value should work, right? -- Michal Hocko SUSE Labs