(2012/05/17 18:52), Glauber Costa wrote: > On 05/17/2012 09:37 AM, Andrew Morton wrote: >>>> If that happens, locking in static_key_slow_inc will prevent any damage. >>>> My previous version had explicit code to prevent that, but we were >>>> pointed out that this is already part of the static_key expectations, so >>>> that was dropped. >> This makes no sense. If two threads run that code concurrently, >> key->enabled gets incremented twice. Nobody anywhere has a record that >> this happened so it cannot be undone. key->enabled is now in an >> unknown state. > > Kame, Tejun, > > Andrew is right. It seems we will need that mutex after all. Just this > is not a race, and neither something that should belong in the > static_branch interface. > Hmm....how about having res_counter_xchg_limit(res, &old_limit, new_limit); if (!cg_proto->updated && old_limit == RESOURCE_MAX) ....update labels... Then, no mutex overhead maybe and activated will be updated only once. Ah, but please fix in a way you like. Above is an example. Thanks, -Kame (*) I'm sorry I won't be able to read e-mails, tomorrow. -- 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>