linux-kernel - WARN_ON_ONCE() in mark_buffer_dirty() being triggered during ext2 umount of an 'errored' block device

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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTinqnX30+oNYMAmcWiSssqQTOq+s4Gnb8fUWdKSa@mail.gmail.com>
Date:	Sun, 16 Jan 2011 19:55:31 +0200
From:	Dan Aloni <dan@...ni.org>
To:	linux-kernel@...r.kernel.org
Subject: WARN_ON_ONCE() in mark_buffer_dirty() being triggered during ext2
 umount of an 'errored' block device

Hello,

With a block device driver that I've implemented, I noticed that if
the block device is in an error state (i.e. all requests return
immediately with an error), and I invoke umount on an ext2 file system
mount on that block device, I get an unexpected kernel stack dump.

The relevant bits of the stack dump show that umount indirectly calls
mark_buffer_dirty(), and then the WARN_ON_ONCE(!buffer_uptodate(bh))
in mark_buffer_dirty() is triggered. I've seen this behavior with ext2
but did not test other file systems.

Now, I suspect this problem has something to do with
end_buffer_async_write() calling clear_buffer_uptodate(bh) but I'm no
VFS expert. The kernel is based on 2.6.32.12 but the code I'm talking
about seems to apply to latest as well.

Or - is it possible that I've mis-implemented the block device driver?

Thanks,
- Dan
--
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/