linux-kernel - Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 18 Dec 2006 20:07:47 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	Miles Lane <miles.lane@...il.com>
CC:	Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()

Miles Lane wrote:
> On 12/18/06, Jiri Slaby <jirislaby@...il.com> wrote:
>> Miles Lane wrote:
>> > Sorry, I am not finding who maintains highmem.  Please forward.
>> >
>> > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
>> > [<c0103c25>] dump_trace+0x68/0x1d2
>> > [<c0103da7>] show_trace_log_lvl+0x18/0x2c
>> > [<c0104410>] show_trace+0xf/0x11
>> > [<c010449b>] dump_stack+0x12/0x14
>> > [<c01144d9>] kmap_atomic+0x6f/0x1ca
>> > [<f930e25d>] ntfs_end_buffer_async_read+0x25d/0x2ca [ntfs]
>> > [<c017c294>] end_bio_bh_io_sync+0x2c/0x37
>> > [<c017dc29>] bio_endio+0x5a/0x62
>> > [<c01c8412>] __end_that_request_first+0x145/0x3ab
>> > [<c0237695>] ide_end_request+0x80/0xd8
>> > [<c023e3f0>] ide_dma_intr+0x55/0x9a
>> > [<c02388dc>] ide_intr+0x182/0x1f2
>> > [<c0140775>] handle_IRQ_event+0x1a/0x3f
>> > [<c0141baa>] handle_edge_irq+0xc6/0x11c
>> > [<c0105416>] do_IRQ+0x57/0x71
>> > [<c010366b>] common_interrupt+0x23/0x28
>> > [<f8826ee4>] acpi_processor_idle+0x1cc/0x36c [processor]
>> > [<c010132b>] cpu_idle+0x3e/0x6c
>> > [<c03f06d9>] start_kernel+0x2fa/0x2fe
>> > =======================
>>
>> Reported yet, you might see it here:
>> http://lkml.org/lkml/2006/12/15/222
> 
> It is certainly very similar, and probably has the same root cause.
> Though, the trace isn't an exact match.   So, who should look into
> this?

The trace needn't be the same. The problem was, that kmap_atomic didn't know
KM_BIO_SRC_IRQ which is called (twice) from ntfs_end_buffer_async_read. It
doesn't matter who called this ntfs function and why.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
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/