linux-kernel - Re: [PATCH 01/12] blkcg: obtaining blkg should be enclosed inside rcu_read

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: <20120119100729.GA2649@redhat.com>
Date:	Thu, 19 Jan 2012 05:07:29 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/12] blkcg: obtaining blkg should be enclosed inside
 rcu_read_lock()

On Wed, Jan 18, 2012 at 05:11:19PM -0800, Tejun Heo wrote:
> When looking up or creating blkg's, both blk-throttle and cfq-iosched
> drops rcu_read_lock() right after lookup is complete.  This isn't
> safe.  Refcnt isn't incremented at that point and rcu lock is the only
> thing holding the blkg.  It shouldn't be dropped until after refcnt is
> incremented by the caller.

Hi Tejun,

throtl_get_tg() and cfq_get_cfqg() are called with queue lock held and
tg and cfqg are protected by queue lock as they can not go away as long
as queue lock is held.

If the group is already created, then caller accesses it under queue
lock and does not pass the pointer around. In case of throttling, caller
can use it under rcu also just to do update of stats (when there are
no rules).

I had used rcu read lock to access blkcg pointer here. That's why when
we are done with accessing blkcg, we drop rcu read lock and return back
to caller with group pointer, which is aready holding either a queue
lock or rcu read lock to protect returned group pointer.

So if we are protecting blkcg using rcu, then it should make sense to
take that lock inside throtl_get_tg() and cfq_get_cfqg() respectively and
it should not be left to the caller?

Thanks
Vivek
--
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/