On Sun, 28 Jan 2007 11:25:42 +0100 Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Andrew Morton napsal(a): > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/ > > I'm still seeing this during bootup: > BUG: at /home/l/latest/xxx/arch/i386/mm/highmem.c:52 kmap_atomic() > [<c0104ffb>] show_trace_log_lvl+0x1a/0x30 > [<c01056b5>] show_trace+0x12/0x14 > [<c010573c>] dump_stack+0x16/0x18 > [<c011b24f>] kmap_atomic+0x16c/0x20e > [<c01b279e>] ntfs_end_buffer_async_read+0x18e/0x2ed > [<c0183352>] end_bio_bh_io_sync+0x26/0x3f > [<c0184dd4>] bio_endio+0x37/0x62 > [<c01cda43>] __end_that_request_first+0x224/0x444 > [<c01cdc6b>] end_that_request_chunk+0x8/0xa > [<c024507d>] scsi_end_request+0x1f/0xc7 > [<c02451e6>] scsi_io_completion+0x7b/0x33a > [<c024aa5d>] sd_rw_intr+0x23/0x1ab > [<c02415ed>] scsi_finish_command+0x42/0x47 > [<c0245a38>] scsi_softirq_done+0x64/0xcf > [<c01cf9e6>] blk_done_softirq+0x54/0x62 > [<c0127bc5>] __do_softirq+0x75/0xde > [<c0127c69>] do_softirq+0x3b/0x3d > [<c0127ee6>] irq_exit+0x3b/0x3d > [<c0106804>] do_IRQ+0x51/0x8d > [<c0104a5f>] common_interrupt+0x23/0x28 > [<c010241a>] cpu_idle+0x80/0xc3 > [<c010140d>] rest_init+0x23/0x36 > [<c045ea59>] start_kernel+0x3a5/0x43c > [<00000000>] 0x0 > ======================= > > I.e. KM_BIO_SRC_IRQ through softirq path. > argh. ntfs_end_buffer_async_read() doesn't know whether it will be called from hardirq or from softirq context: it depends upon the underlying driver. In this case, if the CPU running ntfs_end_buffer_async_read() is interrupted by IO completion against a different disk controller and that completion handler uses KM_BIO_SRC_IRQ (as it is allowed to do), it will trash ntfs_end_buffer_async_read()'s atomic kmap and unpleasing things will ensue. I guess a suitable fix here is to protect that kmap with local_irq_save/restore. I wonder where else we have that bug? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
