linux-kernel - Re: [PATCH 08/17] blkcg: shoot down blkio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120123154954.GC12652@google.com>
Date:	Mon, 23 Jan 2012 07:49:54 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/17] blkcg: shoot down blkio_groups on elevator switch

Hello,

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
  fix.

* 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.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/