On Thu 11-02-21 13:25:33, Matthew Wilcox wrote: > On Thu, Feb 11, 2021 at 02:07:03PM +0100, Michal Hocko wrote: > > On Thu 11-02-21 12:57:17, Matthew Wilcox wrote: > > > > current->flags should be always manipulated from the user context. But > > > > who knows maybe there is a bug and some interrupt handler is calling it. > > > > This should be easy to catch no? > > > > > > Why would it matter if it were? > > > > I was thinking about a clobbered state because updates to ->flags are > > not atomic because this shouldn't ever be updated concurrently. So maybe > > a racing interrupt could corrupt the flags state? > > I don't think that's possible. Same-CPU races between interrupt and > process context are simpler because the CPU always observes its own writes > in order and the interrupt handler completes "between" two instructions. I have to confess I haven't really thought the scenario through. My idea was to simply add a simple check for an irq context into ->flags setting routine because this should never be done in the first place. Not only for scope gfp flags but any other PF_ flags IIRC. -- Michal Hocko SUSE Labs
