linux-ext4 - Re: [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due to a deadlock

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:	Thu, 05 May 2011 17:01:09 +0300
From:	Surbhi Palande <surbhi.palande@...onical.com>
To:	Jan Kara <jack@...e.cz>
CC:	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
	Ted Ts'o <tytso@....edu>,
	Masayoshi MIZUMA <m.mizuma@...fujitsu.com>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	sandeen@...hat.com
Subject: Re: [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due
 to a deadlock

On 05/05/2011 02:18 PM, Jan Kara wrote:
> On Thu 05-05-11 09:06:29, Surbhi Palande wrote:
>> On 05/05/2011 01:48 AM, Jan Kara wrote:
>>> On Thu 05-05-11 00:34:51, Surbhi Palande wrote:
>>>> On 05/04/2011 10:19 PM, Jan Kara wrote:
>>>>> On Wed 04-05-11 15:09:37, Surbhi Palande wrote:
>>>>>> On 05/03/2011 06:19 PM, Jan Kara wrote:
>>>>>>> On Tue 03-05-11 14:01:50, Surbhi Palande wrote:
>>>>>>>> What happens in the case as follows:
>>>>>>>>
>>>>>>>> Task 1: Mmapped writes
>>>>>>>> t1)ext4_page_mkwrite()
>>>>>>>>    t2) ext4_write_begin() (FS is thawed so we proceed)
>>>>>>>>    t3) ext4_write_end() (journal is stopped now)
>>>>>>>> -----Pre-empted-----
>>>>>>>>
>>>>>>>>
>>>>>>>> Task 2: Freeze Task
>>>>>>>> t4) freezes the super block...
>>>>>>>> ...(continues)....
>>>>>>>> tn) the page cache is clean and the F.S is frozen. Freeze has
>>>>>>>> completed execution.
>>>>>>>>
>>>>>>>> Task 1: Mmapped writes
>>>>>>>> tn+1) ext4_page_mkwrite() returns 0.
>>>>>>>> tn+2) __do_fault() gets control, code gets executed.
>>>>>>>> tn+3) _do_fault() marks the page dirty if the intent is to write to
>>>>>>>> a file based page which faulted.
>>>>>>>>
>>>>>>>> So you end up dirtying the page cache when the F.S is frozen? No?
>>>>>>>    You are right ext4_page_mkrite() as currently implemented has problems.
>>>>>>> You have to return the page locked (and check for frozen fs with page lock
>>>>>>> held) to avoid races.
>>>>>>>
>>>>>>> If you check for frozen fs with page lock held, you are guaranteed that
>>>>>>> freezing code must wait for the page to get unlocked before proceeding. And
>>>>>>> before the page is unlocked, it is marked dirty by the pagefault code which
>>>>>>> makes freezing code write the page and writeprotect it again. So everything
>>>>>>> will be safe.
>>>>>> For the locked page to be a part of the freeze initiated sync,
>>>>>> should its owner inode not be dirtied? The page fault handler
>>>>>> dirties the page, but who ensures that the inode is dirtied at this
>>>>>> point?
>>>> Well, I mean it as follows:
>>>>
>>>> Doesn't the writeback code (invoked via sync_filesystem(sb)) write
>>>> all the dirty pages of all the _dirty_ inodes of a superblock?
>>>>
>>>> So in the window from the point where ext4_page_mkwrite returns to
>>>> __do_fault() _till_ you mark the inode dirty (in
>>>> __mark_inode_dirty()), you can have a race with freeze i.e if freeze
>>>> happens meanwhile, then the sync initiated by freeze will not
>>>> consider this locked page as the owner inode is _clean_ (or not
>>>> dirtied yet) at that point?
>>>    Ah, I see. That's actually a good point! Thanks for persistence. So we
>>> should also dirty the page before checking for frozen fs.
>>
>> Should we not also dirty the inode? IMHO, marking an inode will be
>> racy as well!
>    Marking the page dirty marks the inode dirty as well as I've explained in my
> previous emails. So I'm missing what you are concerned about...

Yes you are right! There is no other concern - setting the page dirty 
will be racy.

Warm Regards,
Surbhi.
--
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