linux-ext4 - [Bug 43260] ftruncate locks up when used with direct IO on ext4

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

Message-Id: <20120524101657.DE4DC11FD1A@bugzilla.kernel.org>
Date:	Thu, 24 May 2012 10:16:57 +0000 (UTC)
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 43260] ftruncate locks up when used with direct IO on ext4

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jack@...e.cz

--- Comment #3 from Jan Kara <jack@...e.cz>  2012-05-24 10:16:57 ---
Hum, I see. So we are holding i_mutex and waiting for dio to finish and worker
thread cannot take i_mutex to finish the extent conversion and call
inode_dio_done(). Slightly subtle is that the worker tries to be clever and if
it cannot acquire i_mutex, it requeues the work item so it does not really
deadlock the system, it just eats up CPU cycling the work over and over...

I'm uncertain how to best fix this. If we just revert 266991b13, we reintroduce
the problem of AIO DIO completion racing with truncate (so extent conversion
would happen on already freed blocks). But I'm thinking that with DIO vs
truncate protection in VFS, we probably don't need i_mutex for extent
conversion: The only think in ext4_end_io_nolock() that can possibly need
i_mutex is ext4_convert_unwritten_extents(). That function just starts a
transaction (i_mutex not needed) and calls ext4_map_blocks() which takes
i_data_sem for protection.

I'll let this brew in my head for a while and if I (or anyone else - hint,
hint) does not find a problem with this, I'll write a patch to remove the
lock...

-- 
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