On Wed, Mar 25, 2020 at 7:38 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>
> 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?
KMSAN allocates its metadata lazily*, so if any code does
alloc_pages() from IRQ context, we need to call alloc_pages two more
times for shadow/origin pages.
We also unwind the stack on every creation/copy of an uninitialized
value. Those stacks are stored in the stack depot, which may also
allocate new pages to store stacks.
> Anyway, if you cannot go with the task_struct then a per-cpu value
> should work, right?
Yes, I will try that.
* - as mentioned in the cover letter, a lot of problems could've been
solved if we pre-allocate the metadata pages at boot time so that for
every two contiguous physical pages their metadata pages are also
contiguous.
I haven't come up with a good idea about how to implement that.
Suggestions are very welcome.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
