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
| ||
|
Date: Wed, 25 Jul 2007 05:52:05 +0530 From: "Satyam Sharma" <satyam.sharma@...il.com> To: "Jens Axboe" <jens.axboe@...cle.com> Cc: wharms@....de, LKML <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...k.pl>, "pm list" <linux-pm@...ts.linux-foundation.org> Subject: Re: crash with 2.6.22.1 crash:ll_rw_blk.c blk_remove_plug() On 7/23/07, Jens Axboe <jens.axboe@...cle.com> wrote: > On Sun, Jul 22 2007, Satyam Sharma wrote: > > Hi Walter, > > > > Thanks for reporting this. > > > > On 7/22/07, walter harms <wharms@....de> wrote: > >> hello all, > >> on my asus notebook tm620 there is a crash with 2.6.22 and 2.6.21 > > > > Did this happen when you were resuming from a suspend-to-ram/disk? > > [ I ask because I see swsusp in the trace below, linux-pm added to Cc: ] > > > >> .... > >> Using IPI Shortcut mode > >> WARNING: at block/ll_rw_blk.c:1575 blk_remove_plug() > >> [<c01ac87e>] blk_remove_plug+0x36/0x5a > >> [<c01ac8b6>] __generic_unplug_device+0x14/0x1f > >> [<c01ad587>] __make_request+0x39b/0x49c > >> [<c01abc8c>] generic_make_request+0x228/0x255 > >> [<c01adb54>] submit_bio+0xa5/0xac > >> [<c013e233>] mempool_alloc+0x37/0xae > >> [<c01314dc>] submit+0xc2/0x11d > >> [<c0131585>] bio_read_page+0x24/0x27 > >> [<c013188b>] swsusp_check+0x4f/0xaf > >> [<c012f6c2>] software_resume+0x5f/0x108 > >> [<c037867e>] kernel_init+0xb0/0x212 > >> [<c0103a16>] ret_from_fork+0x6/0x1c > >> [<c03785ce>] kernel_init+0x0/0x212 > >> [<c03785ce>] kernel_init+0x0/0x212 > >> [<c010465b>] kernel_thread_helper+0x7/0x10 > >> ======================= > > > > Surprising, that's a WARN_ON(!irqs_disabled()) but IRQs are disabled > > alright on that codepath. OTOH, __make_request() is heavily goto-driven, > > uses the non-save/restore variants of spin_lock_irq, and does not even > > balance locks / unlocks for some error paths ... gaah. > > __make_request() must be called from process context, hence > spin_lock_irq() is perfectly already and the fastest way to go. And of > course the locking is balanced! So please save your 'gaah's for code > you actually took the time to try and understand. You're right, I didn't really look at that code for long (it even explicitly comments about what's going with the locking in there!) sorry about that. [ Off-topic: BTW does every call to __make_request() end up in blk_remove_plug()? Since you're explicitly making the assumption that it *must* be called from process context (and hence the use of the non-save/restore variants), you could consider putting a WARN_ON(irqs_disabled()) over there, and perhaps a WARN_ON (!spin_is_locked(queue_lock)) in blk_remove_plug() instead, and other such similar functions that currently have the !irqs_disabled check. This way you'd effectively cover _both_ the assertions, and in appropriate places -- just a suggestion. ] > But it does look like unbalanced irq disable/enable calls. I'd guess in > the suspend/resume path. Obviously something more esoteric, since this > is the first such report for 2.6.22, so like some not-very-used driver > for instance. Now that I do look at the codepath, it does seem surprising irqs were not disabled there. There are a bunch of calls to _other_ functions between the spin_lock_irq and the blk_remove_plug via __generic_unplug_device that would also have complained about !irqs_disabled. Walter, does this happen reproducibly? Satyam - 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/
Powered by blists - more mailing lists