Messages in this thread | | | Date | Wed, 27 Jun 2012 10:10:44 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Attaching a process to cgroups |
| |
On Wed, Jun 27, 2012 at 09:23:31AM +0200, Mike Galbraith wrote: > On Tue, 2012-06-26 at 11:06 -0700, Paul E. McKenney wrote: > > On Thu, Jun 21, 2012 at 10:23:02AM +0200, Mike Galbraith wrote: > > > On Thu, 2012-06-21 at 11:54 +0400, Alexey Vlasov wrote: > > > > On Wed, Jun 20, 2012 at 02:28:18PM +0200, Mike Galbraith wrote: > > > > > > > > > > kernel/cgroup.c::cgroup_attach_task() > > > > > { > > > > > ... > > > > > synchronize_rcu(); > > > > > ... > > > > > } > > > > > > > > So nothing can be done here? (I mean if only I knew how to fix it I > > > > wouldn't ask about it ;) > > > > > > Sure, kill the obnoxious thing, it's sitting right in the middle of the > > > userspace interface. > > > > > > I banged on it a while back (wrt explosive android patches), extracted > > > RCU from the userspace interface. It seemed to work great, much faster, > > > couldn't make it explode. I wouldn't bet anything I wasn't willing to > > > immediately part with that the result was really really safe though ;-) > > > > Or replace it with synchronize_rcu_expedited(). You can "get lucky" > > for quite some time removing synchronize_rcu() calls! > > s/remove/replace, but yup. A company that wanted to use the android > patches plus my tinkering showed a fix they needed on top to close a > race discovered in their testing. So yeah, even when all seems fine, > extracting synchronize_rcu() may expose evils you couldn't encounter > before, and didn't happen to encounter afterward.
I really did mean "remove". Removing a synchronize_rcu() does result in a race, but often an extremely low-probability race. So you can remove a synchronize_rcu() and get lucky for a long time, but sooner or later, something will explode.
Thanx, Paul
| |