linux-kernel - Re: [PATCH 06/11] blkcg: move refcnt to blkcg core

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]

Date:	Thu, 2 Feb 2012 14:11:14 -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 06/11] blkcg: move refcnt to blkcg core

Hello,

On Thu, Feb 02, 2012 at 05:07:14PM -0500, Vivek Goyal wrote:
> On Wed, Feb 01, 2012 at 01:19:11PM -0800, Tejun Heo wrote:
> > Currently, blkcg policy implementations manage blkg refcnt duplicating
> > mostly identical code in both policies.  This patch moves refcnt to
> > blkg and let blkcg core handle refcnt and freeing of blkgs.
> > 
> > * cfq blkgs now also get freed via RCU.
> 
> This can lead to situation where cfq root group (policy data) is still
> around (yet to be freed after rcu perioed) but cfq has gone away
> (cfq_exit_queue() followed by cfq_exit()). Does it matter? If some future
> code is accessing cfqg under rcu, it can become a problem.

If RCU is being used, the scope of access allowed under it should be
defined strictly.  It's basically adding another layer of locking and
like any other locking, if the boundary isn't clearly defined, it's
gonna cause a problem.  For blkcg, from the current usage, it's enough
to guarantee access to blkg proper including policy specific data and
under that scope, it doesn't matter whether request or cgroup goes
away.

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/