Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

OK, now I got it, thanks for the explanation. Then the point is to avoid set_page_dirty between file_write_and_wait_range and fsync_node_pages, so we can lock before file_write_and_wait_range and unlock after fsync_node_pages, and lock before set_page_dirty and unlock after set_page_dirty.

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

OK, now I got it, thanks for the explanation. Then the point is to avoid set_page_dirty between file_write_and_wait_range and fsync_node_pages, so we can lock before file_write_and_wait_range and unlock after fsync_node_pages, and lock before set_page_dirty and unlock after set_page_dirty.

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/5 17:37, Yunlong Song wrote: > >> OK, details as I explained before: >> >> atomic_commitGC >> - file_write_and_wait_range >> - move_data_block >> - f2fs_submit_page_write >>

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/5 17:37, Yunlong Song wrote: > >> OK, details as I explained before: >> >> atomic_commitGC >> - file_write_and_wait_range >> - move_data_block >> - f2fs_submit_page_write >>

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

OK, details as I explained before: atomic_commit GC - file_write_and_wait_range - move_data_block - f2fs_submit_page_write -

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

OK, details as I explained before: atomic_commit GC - file_write_and_wait_range - move_data_block - f2fs_submit_page_write -

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/5 14:40, Yunlong Song wrote: > Is it necessary to make atomic commit fail? What's the problem of this > patch (no lock at all and does not make atomic fail)? These two patches > aims to provide ability to gc old blocks of opened atomic file, with no > affection to original atomic commit

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/5 14:40, Yunlong Song wrote: > Is it necessary to make atomic commit fail? What's the problem of this > patch (no lock at all and does not make atomic fail)? These two patches > aims to provide ability to gc old blocks of opened atomic file, with no > affection to original atomic commit

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

Is it necessary to make atomic commit fail? What's the problem of this patch (no lock at all and does not make atomic fail)? These two patches aims to provide ability to gc old blocks of opened atomic file, with no affection to original atomic commit and no mix with inmem pages. On 2018/2/5

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

Is it necessary to make atomic commit fail? What's the problem of this patch (no lock at all and does not make atomic fail)? These two patches aims to provide ability to gc old blocks of opened atomic file, with no affection to original atomic commit and no mix with inmem pages. On 2018/2/5

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/5 10:53, Yunlong Song wrote: > Is it necessary to add a lock here? What's the problem of this patch (no > lock at all)? Anyway, the problem is expected to be fixed asap, since > attackers can easily write an app with only atomic start and no atomic > commit, which will cause f2fs run

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/5 10:53, Yunlong Song wrote: > Is it necessary to add a lock here? What's the problem of this patch (no > lock at all)? Anyway, the problem is expected to be fixed asap, since > attackers can easily write an app with only atomic start and no atomic > commit, which will cause f2fs run

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

Is it necessary to add a lock here? What's the problem of this patch (no lock at all)? Anyway, the problem is expected to be fixed asap, since attackers can easily write an app with only atomic start and no atomic commit, which will cause f2fs run into loop gc if the disk layout is much

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

Is it necessary to add a lock here? What's the problem of this patch (no lock at all)? Anyway, the problem is expected to be fixed asap, since attackers can easily write an app with only atomic start and no atomic commit, which will cause f2fs run into loop gc if the disk layout is much

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/3 10:47, Yunlong Song wrote: > If inode has already started to atomic commit, then set_page_dirty will > not mix the gc pages with the inmem atomic pages, so the page can be > gced safely. Let's avoid Ccing fs mailing list if the patch didn't change vfs common codes. As you know, the

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

On 2018/2/3 10:47, Yunlong Song wrote: > If inode has already started to atomic commit, then set_page_dirty will > not mix the gc pages with the inmem atomic pages, so the page can be > gced safely. Let's avoid Ccing fs mailing list if the patch didn't change vfs common codes. As you know, the

[PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

If inode has already started to atomic commit, then set_page_dirty will not mix the gc pages with the inmem atomic pages, so the page can be gced safely. Signed-off-by: Yunlong Song --- fs/f2fs/data.c | 5 ++--- fs/f2fs/gc.c | 6 -- 2 files changed, 6

[PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

If inode has already started to atomic commit, then set_page_dirty will not mix the gc pages with the inmem atomic pages, so the page can be gced safely. Signed-off-by: Yunlong Song --- fs/f2fs/data.c | 5 ++--- fs/f2fs/gc.c | 6 -- 2 files changed, 6 insertions(+), 5 deletions(-) diff