On Wed 25-03-20 19:30:09, Alexander Potapenko wrote: > 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(). Kmemleak used the same approach IIRC. It turned out to be unusable in a presence of any higher GFP_NOWAIT memory pressure. Anyway talk to Catalin Marinas about problems he had to go through to address them. -- Michal Hocko SUSE Labs
