[lkml]   [2012]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 08/17] blkcg: shoot down blkio_groups on elevator switch

On Mon, Jan 23, 2012 at 10:36:48AM -0500, Vivek Goyal wrote:
> IIUC, above is racy w.r.t cgroup removal and elevator switch. Assume that
> elevator swtich is taking place and we have queue lock held and we try to
> clear the groups on the queue. Parallely somebody is trying to delete a
> cgroup and has been partially successful in doing so by taking off the
> group from blkcg list (blkiocg_destroy()).
> Now clear_queue() will complete with one or more groups possibly still
> left on cfqd list because of cgroup deletion race and that can cause
> problmes.

Yeah, the fun of smart-ass locking. Ultimately, the locking will be
the same locking scheme as ioc's will be used - ie. any modifications
take both locks and there's no limbo state. Things are so tightly
entangled and I'm finding it very challenging to sequence patches in
the exact order. I'll see if I can re-sequence locking update before
this but I might just as well declare that there's transitional race
condition in the patch.

There are also a couple other issues that I found yesterday while
updating further patches.

* blkio_list_lock has locking order reversal. This isn't difficult to

* root_group too gets shot down across elv switch. It needs to be
reinitialized afterwards. This one too turns out to be pretty
tricky to sequence right.

It probably isn't too easy to see the direction at this point, so...

* There will be single blkg per cgroup-request_queue pair regardless
of the number of policies. Each blkg carries common part and opaque
data part for each policy and is managed by blkcg core layer.

* Set of enabled policies will become per-queue property.



 \ /
  Last update: 2012-01-23 16:53    [W:0.041 / U:50.732 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site