linux-ext4 - Re: [PATCH 0/3] Rewrite ext4_page

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:	Wed, 11 May 2011 13:15:36 +0300
From:	"Amir G." <amir73il@...rs.sourceforge.net>
To:	Jan Kara <jack@...e.cz>
Cc:	Ted Tso <tytso@....edu>, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/3] Rewrite ext4_page_mkwrite, fix fs freezing

On Wed, May 11, 2011 at 12:43 PM, Jan Kara <jack@...e.cz> wrote:
>  Hi Amir,
>
> On Wed 11-05-11 10:33:17, Amir G. wrote:
>> Can you provide a bit of a wider scope review of how this related to the
>> work on stable pages.
>  It is related in the sense that Darrick had to return locked page from
> ext4_page_mkwrite() to avoid races and the result (although working) is
> really like scratching your left ear with your right hand (not sure if
> English has this idiom ;). So with my patches, what Darrick needs to do is
> simply achieved by updating block_page_mkwrite() (__block_page_mkwrite() in
> fact).
>
>> For example, when to the pages get unlocked?
>  That's handled by mm code in mm/memory.c. You can read do_wp_page() but
> it's not a light reading ;)

This is why I asked for the cheat sheet ;-)

>
>> If the pages supposed to be stable during writeback, how is this related
>> to returning locked pages from page_mkwrite?
>  Returning locked page is needed to avoid races with page writeback - for
> stable pages we want to do wait_on_page_writeback() to be sure that there's
> no IO happening while we make the page writeable for user. But once we
> release page lock, writepage can come and start the writeback. The basic
> scheme of the race we want to avoid is:
>  do_wp_page()
>    ext4_page_mkwrite()
>      wait_on_page_writeback()
>      unlock_page()
>                                        clear_page_dirty_for_io()
>                                          page_mkclean()
>                                        writepage()
>    maybe_mkwrite()
>
> Because this results in writeable page under writeback... We have to make
> sure page_mkclean() happens *after* maybe_mkwrite() from do_wp_page() in
> this scenario.
>
>> Is the page going to stay locked until writeback?
>  No, until the page fault is finished.
>
>> Do I understand correctly that a page will be marked read-only after
>> writeback completes, so page_mkwrite will be called again on next write?
>  Page is marked read-only before writeback is started in
> clear_page_dirty_for_io().

OK. that makes sense. I wasn't sure my move-on-write hook,
which is called from ext4_page_mkwrite() is going to be called on every
writeback.
The use case is:
data = mmap(file);
data[0] = 1;
take snapshot 1;
data[0] = 2;
take snapshot 2;
data[0] = 3;
...

That use case doesn't specify when writeback of first page of file happens
and I don't care which version of data[0] is seen by the snapshots, as long
as the snapshot view is internally consistent (it doesn't change over time or
after reboot).

So if ext4_page_mkwrite() is called after every writeback and the page is stable
during writeback, snapshots should be OK.

>
>                                                                Honza
> --
> Jan Kara <jack@...e.cz>
> SUSE Labs, CR
>
--
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