On Wed 25-03-20 10:49:16, Matthew Wilcox wrote:
> 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?
I wouldn't object. The only reason for using PF_$FOO is historical. It
was XFS which started to use pf flag for NOSF AFAIR. I haven't checked
recently but xfs still used to use its own api in the past.
--
Michal Hocko
SUSE Labs
