linux-ext4 - Re: i_mutex questions

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]

Date:	Wed, 14 Sep 2011 09:29:28 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"Ted Ts'o" <tytso@....edu>, Lukas Czerner <lczerner@...hat.com>
Subject: Re: i_mutex questions

On Wed, Sep 14, 2011 at 2:33 AM, Allison Henderson
<achender@...ux.vnet.ibm.com> wrote:
> Hi All,
>
> I have been trying to find a way to synchronize punch hole with read and
> write operations with out the use of i_mutex.  The concern is that after
> punch hole has released the pages inside the hole, another process may remap
> the page to a block before punch has taken i_data_sem.  I think putting
> i_mutex around the punch hole operation would fix this, but since we are
> trying to avoid further improper use of i_mutex, I am trying to avoid that
> solution.
>
> I cannot use i_data_sem to protect the pages because it seems most of the
> code has already established a locking order of pages first, then
> i_data_sem.  So moving i_data_sem up tends to cause a lot of dead locks.
>  I'm thinking that there probably needs to be a another mutex involved some
> where, but I wasnt sure if some one is already working on the idea of
> introducing a replacement for i_mutex.  So I just wanted to know if there
> are any plans already in motion for this, or if any one else could suggest
> some ideas for the punch hole issue.  Thx all!

HI,

Lukas sent out a patch ([PATCH] ext4: Make reads/writes atomic with
i_rwlock semaphore) which collected some feedbacks suggesting using
extent lock instead of a read-write semaphore.  If there is extent
lock implementation in ext4, then fallocate can use it, maybe
dioread-nolock can use it as well, e.g. locking a range and unlocking
the range until the extent is converted from unwritten to init.

Yongqiang.


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



-- 
Best Wishes
Yongqiang Yang
--
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