From: Mel Gorman <mgorman@xxxxxxx> Date: Thu, 10 May 2012 14:44:58 +0100 > This is needed to allow network softirq packet processing to make > use of PF_MEMALLOC. > > Currently softirq context cannot use PF_MEMALLOC due to it not being > associated with a task, and therefore not having task flags to fiddle > with - thus the gfp to alloc flag mapping ignores the task flags when > in interrupts (hard or soft) context. > > Allowing softirqs to make use of PF_MEMALLOC therefore requires some > trickery. We basically borrow the task flags from whatever process > happens to be preempted by the softirq. > > So we modify the gfp to alloc flags mapping to not exclude task flags > in softirq context, and modify the softirq code to save, clear and > restore the PF_MEMALLOC flag. > > The save and clear, ensures the preempted task's PF_MEMALLOC flag > doesn't leak into the softirq. The restore ensures a softirq's > PF_MEMALLOC flag cannot leak back into the preempted process. > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> > Signed-off-by: Mel Gorman <mgorman@xxxxxxx> We're now making changes to task->flags from both base and softirq context, but with non-atomic operations and no other kind of synchronization. As far as I can tell, this has to be racy. If this works via some magic combination of invariants, you absolutely have to document this, verbosely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>