Re: [PATCH v5 03/38] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 25, 2020 at 7:09 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Wed, Mar 25, 2020 at 07:03:32PM +0100, Alexander Potapenko wrote:
> > > I would suggest using bits in the section labelled:
> > >
> > >         /* Unserialized, strictly 'current' */
> >
> > The main problem is that |current| is unavailable in the interrupt
> > context, so we'll also need to:
> >  - disable interrupts when preparing for a KMSAN internal memory
> > allocation - sounds costly, huh?
> >  - store the context flag in a per-cpu variable in the case |current|
> > is unavailable.
>
> It's not /unavailable/ ... it's whatever task happens to be running at
> the time the interrupt is triggered.  You can borrow its task_struct.

That didn't come to my mind, interesting!

> You'll have to save off the current value of the flag before setting it,
> just like memalloc_nofs_save() does.
> But this does rather call into question whether Michal's advice to use
> task_struct is good advice to begin with.  For memalloc_nofs/noio,
> it works well this way because allocations in interrupt context are
> inherently at a more restrictive context than task level.  It's not clear
> to me what this kmsan GFP flag is being used for, and whether allocations
> that happen in interrupt context should inherit the kmsan setting.

The idea behind this flag is as follows.
KMSAN must allocate metadata pages for every allocation performed by
alloc_pages().
Metadata allocations are also done via alloc_pages(), and for those no
further metadata needs to be allocated.
Thus the GFP flag is used to prevent the recursion in alloc_pages().

It is theoretically possible that a less restrictive allocation
(without __GFP_NO_KMSAN_SHADOW) happens in an interrupt on top of a
task performing a more restrictive allocation (with
__GFP_NO_KMSAN_SHADOW).

> I will have to read these patches more carefully to determine that;
> I was really just responding to the "where can I find some free bits"
> part of the question.

Thanks for clarification.

-- 
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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux