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
