Messages in this thread | | | Date | Mon, 6 Jun 2011 00:51:10 +0200 | From | Jens Axboe <> | Subject | Re: Mysterious CFQ crash and RCU |
| |
On 2011-06-05 12:38, Paul Bolle wrote: > On Sun, 2011-06-05 at 10:39 +0200, Paul Bolle wrote: >> 0) I'd guess not, as the last thing I tried before simply ripping >> io_context.ioc_data out, was: >> >> spin_lock_irqsave(&ioc->lock, flags); >> rcu_read_lock(); >> ioc_data = rcu_dereference(ioc->ioc_data); >> rcu_read_unlock(); >> if (ioc_data == cic) >> rcu_assign_pointer(ioc->ioc_data, NULL); >> spin_unlock_irqrestore(&ioc->lock, flags);
You don't need to nest a rcu_read_lock/unlock() inside that write lock.
> 0) Strike that. It does seem to fix it. I must have done something silly > while doing yet another test of this stuff (perhaps by forgetting to > remove an old, crashing version of the cfq_iosched module before > installing a new version and switching back to cfq).
Good, I thought it should!
> 1) Jens, I suggest I'll send in a small series of patches, along these > lines: > - cleanup: make two functions static in block/cfq-iosched.c > - cleanup: rename io_context.cic_list -> io_context.cic_hlist > rename io_context.ioc_data -> io_context.last_cic > change io_context.last_cic from void* to cfq_io_context* > rename cfq_io_context.cic_list -> cfq_io_context.cic_node > - cleanup: rename *ret -> *ioc in two functions > - locking: make sure io_context.last_cic is accessed under > io_context.lock and using the required RCU voodoo > > 2) Any objections beforehand?
I've already applied the fix I sent to you, since it was definitely a bug. So please send anything around that. Was out today, so not pushed out until now and just now catching up on the email.
And thanks a ton for being persistent and doing a ton of work trying to figure out what was wrong. Fixing is the easy part, illuminating where the problem is or may be is the hard part!
-- Jens Axboe
| |