On Fri, Jan 15, 2016 at 07:57:03PM +0300, Kirill Tkhai wrote: > Port commit be958bdc96f18bc1356177bbb79d46ea0c037b96 from mainstream. > > Some of the sched bitfieds (notably sched_reset_on_fork) can be set > on other than current, this can cause the r-m-w to race with other > updates. > > Since all the sched bits are serialized by scheduler locks, pull them > in a separate word. > > Reported-by: Tejun Heo <[email protected]> > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > Cc: Dmitry Vyukov <[email protected]> > Cc: Linus Torvalds <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Sasha Levin <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: Dmitry Vyukov <[email protected]> > Cc: Linus Torvalds <[email protected]> > Cc: Peter Zijlstra <[email protected]> > > Really the below 4 bits are protected by different locks: > > unsigned sched_reset_on_fork:1; rq pi > unsigned sched_contributes_to_load:1; pi > unsigned sched_interruptible_sleep:1; pi > unsigned woken_while_running:1; rq > > But we may say, all of them are protected by rq lock, > because sched_contributes_to_load and sched_interruptible_sleep > are modified in try_to_wake_up(), when task is not on rq, > so nobody can modify sched_reset_on_fork and woken_while_running > this moment. > > Thus we won't use one more bitfield and save a memory of one word. > > Signed-off-by: Kirill Tkhai <[email protected]>
Reviewed-by: Vladimir Davydov <[email protected]> _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
