On Wed, Mar 25, 2020 at 06:40:29PM +0100, 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?
I would suggest using bits in the section labelled:
/* Unserialized, strictly 'current' */
since this doesn't need to be accessed from any other task. Michal,
can we move PF_MEMALLOC_NOIO and NOFS to that area too?
