Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed 19-05-21 08:36:37, Dave Chinner wrote: > On Fri, May 14, 2021 at 09:17:30AM -0700, Darrick J. Wong wrote: > > On Fri, May 14, 2021 at 09:19:45AM +1000, Dave Chinner wrote: > > > On Thu, May 13, 2021 at 11:52:52AM -0700, Darrick J. Wong wrote: > > > > On Thu, May 13, 2021 at 07:44:59PM +0200,

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Fri, May 14, 2021 at 09:17:30AM -0700, Darrick J. Wong wrote: > On Fri, May 14, 2021 at 09:19:45AM +1000, Dave Chinner wrote: > > On Thu, May 13, 2021 at 11:52:52AM -0700, Darrick J. Wong wrote: > > > On Thu, May 13, 2021 at 07:44:59PM +0200, Jan Kara wrote: > > > > On Wed 12-05-21 08:23:45, Dar

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Fri 14-05-21 09:17:30, Darrick J. Wong wrote: > On Fri, May 14, 2021 at 09:19:45AM +1000, Dave Chinner wrote: > > We've been down this path before more than a decade ago when the > > powers that be decreed that inode locking order is to be "by > > structure address" rather than inode number, bec

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Fri, May 14, 2021 at 09:19:45AM +1000, Dave Chinner wrote: > On Thu, May 13, 2021 at 11:52:52AM -0700, Darrick J. Wong wrote: > > On Thu, May 13, 2021 at 07:44:59PM +0200, Jan Kara wrote: > > > On Wed 12-05-21 08:23:45, Darrick J. Wong wrote: > > > > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Thu 13-05-21 20:38:47, Matthew Wilcox wrote: > On Thu, May 13, 2021 at 09:01:14PM +0200, Jan Kara wrote: > > On Wed 12-05-21 15:40:21, Matthew Wilcox wrote: > > > Remind me (or, rather, add to the documentation) why we have to hold the > > > invalidate_lock during the call to readpage / readahea

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Thu, May 13, 2021 at 11:52:52AM -0700, Darrick J. Wong wrote: > On Thu, May 13, 2021 at 07:44:59PM +0200, Jan Kara wrote: > > On Wed 12-05-21 08:23:45, Darrick J. Wong wrote: > > > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > > > > +->fallocate implementation must be really carefu

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Thu, May 13, 2021 at 09:01:14PM +0200, Jan Kara wrote: > On Wed 12-05-21 15:40:21, Matthew Wilcox wrote: > > Remind me (or, rather, add to the documentation) why we have to hold the > > invalidate_lock during the call to readpage / readahead, and we don't just > > hold it around the call to add_

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed 12-05-21 15:40:21, Matthew Wilcox wrote: > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > > Currently, serializing operations such as page fault, read, or readahead > > against hole punching is rather difficult. The basic race scheme is > > like: > > > > fallocate(FALLOC_FL_PUN

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Thu, May 13, 2021 at 07:44:59PM +0200, Jan Kara wrote: > On Wed 12-05-21 08:23:45, Darrick J. Wong wrote: > > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > > > +->fallocate implementation must be really careful to maintain page cache > > > +consistency when punching holes or perfor

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed 12-05-21 15:20:44, Matthew Wilcox wrote: > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > > > diff --git a/mm/truncate.c b/mm/truncate.c > > index 57a618c4a0d6..93bde2741e0e 100644 > > --- a/mm/truncate.c > > +++ b/mm/truncate.c > > @@ -415,7 +415,7 @@ EXPORT_SYMBOL(truncate_in

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed 12-05-21 08:23:45, Darrick J. Wong wrote: > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > > +->fallocate implementation must be really careful to maintain page cache > > +consistency when punching holes or performing other operations that > > invalidate > > +page cache content

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > Currently, serializing operations such as page fault, read, or readahead > against hole punching is rather difficult. The basic race scheme is > like: > > fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / .. > truncat

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > Currently, serializing operations such as page fault, read, or readahead > against hole punching is rather difficult. The basic race scheme is > like: > > fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / .. > truncat

Re: [f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote: > diff --git a/mm/truncate.c b/mm/truncate.c > index 57a618c4a0d6..93bde2741e0e 100644 > --- a/mm/truncate.c > +++ b/mm/truncate.c > @@ -415,7 +415,7 @@ EXPORT_SYMBOL(truncate_inode_pages_range); > * @mapping: mapping to truncate > * @l

[f2fs-dev] [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock

Currently, serializing operations such as page fault, read, or readahead against hole punching is rather difficult. The basic race scheme is like: fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / .. truncate_inode_pages_range()