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, 19 Jun 2014 16:26:40 -0400
From:	Tejun Heo <>
To:	Vivek Goyal <>
Cc:	Joe Lawrence <>,, Cgroups <>
Subject: Re: docker crashes rcuos in __blkg_release_rcu

Sorry about the late reply.

On Wed, Jun 11, 2014 at 12:32:29PM -0400, Vivek Goyal wrote:
> Tejun, any thoughts on how to solve this issue. Delaying blkg release
> in rcu context and then expecting queue to be still present is causing
> this problem.

Heh, this is hilarious.  If you look at the comment right above
__blkg_release_rcu(), it says

 * A group is RCU protected, but having an rcu lock does not mean that one
 * can access all the fields of blkg and assume these are valid.  For
 * example, don't try to follow throtl_data and request queue links.

And yet the code brazenly derefs the ->q link to access the lock there
and causes oops.  This is from 2a4fd070ee85 ("blkcg: move bulk of
blkcg_gq release operations to the RCU callback").  I stupidly didn't
realize what I was doing even while moving the comment itself.

Well, the obvious solution is making blkg ref an atomic.  I was
planning to convert it to percpu_ref anyway.  We can first convert it
to atomic_t for -stable and then to percpu_ref.  Will prep a patch.

Thanks for tracking it down!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists