linux-ext4 - [Bug 16312] WARNING: at fs/fs-writeback.c:1127 __mark_inode

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Jul 2010 15:30:50 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 16312] WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty

https://bugzilla.kernel.org/show_bug.cgi?id=16312

Jan Kara <jack@...e.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |axboe@...nel.dk,
                   |                            |jack@...e.cz

--- Comment #3 from Jan Kara <jack@...e.cz>  2010-07-23 15:30:50 ---
I was looking into this. A trivial reproducer is:
mknod devzero c 1 5; touch devzero

Essentially, the problem is that any device inode can get dirty because of time
stamp update or similar reason but some BDIs (in this case the one backing
/dev/zero) do not expect dirty inodes. Hmm, I now have to think how to fix
this... It would be more natural if device inodes were queued for metadata
updates in the queues of "parent" filesystem. But this brings problem that
device inode would need to be in two queues - one for metadata update to the
parent filesystem and one for data writeout to the device (this is not exactly
the case of /dev/zero but if you have a device node for /dev/sdb on /dev/sda,
then this is exactly what we would need).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html