Messages in this thread | | | Date | Thu, 28 Aug 2008 10:36:20 +0200 | From | Jens Axboe <> | Subject | Re: 2.6.27-rc4: lots of 'in_atomic():1, irqs_disabled():0' with software-raid1 |
| |
On Thu, Aug 28 2008, Neil Brown wrote: > On Thursday August 28, jens.axboe@oracle.com wrote: > > On Thu, Aug 28 2008, Andrew Morton wrote: > > > > > > Cant sleep inside rcu_read_lock(), with CONFIG_PREEMPT_RCU=n, at least. > > > > > > Dunno if it's legal if CONFIG_PREEMPT_RCU=y. Hopefully not - that > > > would be insane. But I've failed to keep up with rcu goings-on > > > recently. > > > > Doh right, we of course can't block inside a RCU section. Then > > bitmap.c:write_sb_page() wants fixing: > > > > rcu_read_lock(); > > rdev_for_each_rcu(...) > > md_super_write(...) > > bio_alloc(GFP_NOIO, 1); > > > > Neil? > > > Yes...... > > And not only can't I call bio_alloc inside the rcu_read_lock, I also > cannot call submit_bio, as that can do a mempool alloc for a request > structure.
Right, it's not the only broken part there.
> I can get around that by putting the bios on the ->biolist that > md_super_wait will resubmit requests from. But I still need to > allocate those bios. > Maybe I can count how many there need to be, then allocate them and > make a list, then pass them down into md_super_write. > It's a bit ugly but it should work. > > I think I'll have to think about it a bit more.
That was my initial thought as well, but the problem there is that you cannot prealloc > 1 bio without matching it with a submit_bio() as well, or you'd violate the bio_alloc() restriction on having the previous in flight before allocating a new one.
-- Jens Axboe
| |