From: Ira Weiny <ira.weiny@intel.com> To: Jan Kara <jack@suse.cz> Cc: Michal Hocko <mhocko@suse.com>, Theodore Ts'o <tytso@mit.edu>, linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org, John Hubbard <jhubbard@nvidia.com>, Dave Chinner <david@fromorbit.com>, linux-kernel@vger.kernel.org, Matthew Wilcox <willy@infradead.org>, linux-xfs@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, linux-ext4@vger.kernel.org Subject: Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Date: Wed, 14 Aug 2019 11:08:49 -0700 [thread overview] Message-ID: <20190814180848.GB31490@iweiny-DESK2.sc.intel.com> (raw) In-Reply-To: <20190814101714.GA26273@quack2.suse.cz> On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: > Hello! > > On Fri 09-08-19 15:58:14, ira.weiny@intel.com wrote: > > Pre-requisites > > ============== > > Based on mmotm tree. > > > > Based on the feedback from LSFmm, the LWN article, the RFC series since > > then, and a ton of scenarios I've worked in my mind and/or tested...[1] > > > > Solution summary > > ================ > > > > The real issue is that there is no use case for a user to have RDMA pinn'ed > > memory which is then truncated. So really any solution we present which: > > > > A) Prevents file system corruption or data leaks > > ...and... > > B) Informs the user that they did something wrong > > > > Should be an acceptable solution. > > > > Because this is slightly new behavior. And because this is going to be > > specific to DAX (because of the lack of a page cache) we have made the user > > "opt in" to this behavior. > > > > The following patches implement the following solution. > > > > 0) Registrations to Device DAX char devs are not affected > > > > 1) The user has to opt in to allowing page pins on a file with an exclusive > > layout lease. Both exclusive and layout lease flags are user visible now. > > > > 2) page pins will fail if the lease is not active when the file back page is > > encountered. > > > > 3) Any truncate or hole punch operation on a pinned DAX page will fail. > > So I didn't fully grok the patch set yet but by "pinned DAX page" do you > mean a page which has corresponding file_pin covering it? Or do you mean a > page which has pincount increased? If the first then I'd rephrase this to > be less ambiguous, if the second then I think it is wrong. I mean the second. but by "fail" I mean hang. Right now the "normal" page pincount processing will hang the truncate. Given the discussion with John H we can make this a bit better if we use something like FOLL_PIN and the page count bias to indicate this type of pin. Then I could fail the truncate outright. but that is not done yet. so... I used the word "fail" to be a bit more vague as the final implementation may return ETXTBUSY or hang as noted. > > > 4) The user has the option of holding the lease or releasing it. If they > > release it no other pin calls will work on the file. > > Last time we spoke the plan was that the lease is kept while the pages are > pinned (and an attempt to release the lease would block until the pages are > unpinned). That also makes it clear that the *lease* is what is making > truncate and hole punch fail with ETXTBUSY and the file_pin structure is > just an implementation detail how the existence is efficiently tracked (and > what keeps the backing file for the pages open so that the lease does not > get auto-destroyed). Why did you change this? closing the file _and_ unmaping it will cause the lease to be released regardless of if we allow this or not. As we discussed preventing the close seemed intractable. I thought about failing the munmap but that seemed wrong as well. But more importantly AFAIK RDMA can pass its memory pins to other processes via FD passing... This means that one could pin this memory, pass it to another process and exit. The file lease on the pin'ed file is lost. The file lease is just a key to get the memory pin. Once unlocked the procfs tracking keeps track of where that pin goes and which processes need to be killed to get rid of it. > > > 5) Closing the file is ok. > > > > 6) Unmapping the file is ok > > > > 7) Pins against the files are tracked back to an owning file or an owning mm > > depending on the internal subsystem needs. With RDMA there is an owning > > file which is related to the pined file. > > > > 8) Only RDMA is currently supported > > If you currently only need "owning file" variant in your patch set, then > I'd just implement that and leave "owning mm" variant for later if it > proves to be necessary. The things are complex enough as is... I can do that... I was trying to get io_uring working as well with the owning_mm but I should save that for later. > > > 9) Truncation of pages which are not actively pinned nor covered by a lease > > will succeed. > > Otherwise I like the design. Thanks, Ira > > Honza > > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com> To: Jan Kara <jack@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org>, Jason Gunthorpe <jgg@ziepe.ca>, Dan Williams <dan.j.williams@intel.com>, Matthew Wilcox <willy@infradead.org>, Theodore Ts'o <tytso@mit.edu>, John Hubbard <jhubbard@nvidia.com>, Michal Hocko <mhocko@suse.com>, Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Date: Wed, 14 Aug 2019 11:08:49 -0700 [thread overview] Message-ID: <20190814180848.GB31490@iweiny-DESK2.sc.intel.com> (raw) In-Reply-To: <20190814101714.GA26273@quack2.suse.cz> On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: > Hello! > > On Fri 09-08-19 15:58:14, ira.weiny@intel.com wrote: > > Pre-requisites > > ============== > > Based on mmotm tree. > > > > Based on the feedback from LSFmm, the LWN article, the RFC series since > > then, and a ton of scenarios I've worked in my mind and/or tested...[1] > > > > Solution summary > > ================ > > > > The real issue is that there is no use case for a user to have RDMA pinn'ed > > memory which is then truncated. So really any solution we present which: > > > > A) Prevents file system corruption or data leaks > > ...and... > > B) Informs the user that they did something wrong > > > > Should be an acceptable solution. > > > > Because this is slightly new behavior. And because this is going to be > > specific to DAX (because of the lack of a page cache) we have made the user > > "opt in" to this behavior. > > > > The following patches implement the following solution. > > > > 0) Registrations to Device DAX char devs are not affected > > > > 1) The user has to opt in to allowing page pins on a file with an exclusive > > layout lease. Both exclusive and layout lease flags are user visible now. > > > > 2) page pins will fail if the lease is not active when the file back page is > > encountered. > > > > 3) Any truncate or hole punch operation on a pinned DAX page will fail. > > So I didn't fully grok the patch set yet but by "pinned DAX page" do you > mean a page which has corresponding file_pin covering it? Or do you mean a > page which has pincount increased? If the first then I'd rephrase this to > be less ambiguous, if the second then I think it is wrong. I mean the second. but by "fail" I mean hang. Right now the "normal" page pincount processing will hang the truncate. Given the discussion with John H we can make this a bit better if we use something like FOLL_PIN and the page count bias to indicate this type of pin. Then I could fail the truncate outright. but that is not done yet. so... I used the word "fail" to be a bit more vague as the final implementation may return ETXTBUSY or hang as noted. > > > 4) The user has the option of holding the lease or releasing it. If they > > release it no other pin calls will work on the file. > > Last time we spoke the plan was that the lease is kept while the pages are > pinned (and an attempt to release the lease would block until the pages are > unpinned). That also makes it clear that the *lease* is what is making > truncate and hole punch fail with ETXTBUSY and the file_pin structure is > just an implementation detail how the existence is efficiently tracked (and > what keeps the backing file for the pages open so that the lease does not > get auto-destroyed). Why did you change this? closing the file _and_ unmaping it will cause the lease to be released regardless of if we allow this or not. As we discussed preventing the close seemed intractable. I thought about failing the munmap but that seemed wrong as well. But more importantly AFAIK RDMA can pass its memory pins to other processes via FD passing... This means that one could pin this memory, pass it to another process and exit. The file lease on the pin'ed file is lost. The file lease is just a key to get the memory pin. Once unlocked the procfs tracking keeps track of where that pin goes and which processes need to be killed to get rid of it. > > > 5) Closing the file is ok. > > > > 6) Unmapping the file is ok > > > > 7) Pins against the files are tracked back to an owning file or an owning mm > > depending on the internal subsystem needs. With RDMA there is an owning > > file which is related to the pined file. > > > > 8) Only RDMA is currently supported > > If you currently only need "owning file" variant in your patch set, then > I'd just implement that and leave "owning mm" variant for later if it > proves to be necessary. The things are complex enough as is... I can do that... I was trying to get io_uring working as well with the owning_mm but I should save that for later. > > > 9) Truncation of pages which are not actively pinned nor covered by a lease > > will succeed. > > Otherwise I like the design. Thanks, Ira > > Honza > > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR
next prev parent reply other threads:[~2019-08-14 18:10 UTC|newest] Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-09 22:58 [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 01/19] fs/locks: Export F_LAYOUT lease to user space ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 23:52 ` Dave Chinner 2019-08-09 23:52 ` Dave Chinner 2019-08-12 17:36 ` Ira Weiny 2019-08-12 17:36 ` Ira Weiny 2019-08-14 8:05 ` Dave Chinner 2019-08-14 8:05 ` Dave Chinner 2019-08-14 11:21 ` Jeff Layton 2019-08-14 11:21 ` Jeff Layton 2019-08-14 11:21 ` Jeff Layton 2019-08-14 11:38 ` Dave Chinner 2019-08-14 11:38 ` Dave Chinner 2019-08-09 22:58 ` [RFC PATCH v2 02/19] fs/locks: Add Exclusive flag to user Layout lease ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-14 14:15 ` Jeff Layton 2019-08-14 14:15 ` Jeff Layton 2019-08-14 14:15 ` Jeff Layton 2019-08-14 21:56 ` Dave Chinner 2019-08-26 10:41 ` Jeff Layton 2019-08-26 10:41 ` Jeff Layton 2019-08-26 10:41 ` Jeff Layton 2019-08-29 23:34 ` Ira Weiny 2019-08-29 23:34 ` Ira Weiny 2019-09-04 12:52 ` Jeff Layton 2019-09-04 12:52 ` Jeff Layton 2019-09-04 23:12 ` John Hubbard 2019-09-04 23:12 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 03/19] mm/gup: Pass flags down to __gup_device_huge* calls ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 04/19] mm/gup: Ensure F_LAYOUT lease is held prior to GUP'ing pages ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 05/19] fs/ext4: Teach ext4 to break layout leases ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 06/19] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-23 15:18 ` Vivek Goyal 2019-08-23 15:18 ` Vivek Goyal 2019-08-29 18:52 ` Ira Weiny 2019-08-29 18:52 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 07/19] fs/xfs: Teach xfs to use new dax_layout_busy_page() ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 23:30 ` Dave Chinner 2019-08-09 23:30 ` Dave Chinner 2019-08-12 18:05 ` Ira Weiny 2019-08-12 18:05 ` Ira Weiny 2019-08-14 8:04 ` Dave Chinner 2019-08-09 22:58 ` [RFC PATCH v2 08/19] fs/xfs: Fail truncate if page lease can't be broken ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 23:22 ` Dave Chinner 2019-08-09 23:22 ` Dave Chinner 2019-08-12 18:08 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 09/19] mm/gup: Introduce vaddr_pin structure ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 10/19] mm/gup: Pass a NULL vaddr_pin through GUP fast ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-10 0:06 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 11/19] mm/gup: Pass follow_page_context further down the call stack ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:18 ` John Hubbard 2019-08-10 0:18 ` John Hubbard 2019-08-10 0:18 ` John Hubbard 2019-08-12 19:01 ` Ira Weiny 2019-08-12 19:01 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 12/19] mm/gup: Prep put_user_pages() to take an vaddr_pin struct ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:30 ` John Hubbard 2019-08-10 0:30 ` John Hubbard 2019-08-10 0:30 ` John Hubbard 2019-08-12 20:46 ` Ira Weiny 2019-08-09 22:58 ` [RFC PATCH v2 13/19] {mm,file}: Add file_pins objects ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 14/19] fs/locks: Associate file pins while performing GUP ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 15/19] mm/gup: Introduce vaddr_pin_pages() ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-10 0:09 ` John Hubbard 2019-08-10 0:09 ` John Hubbard 2019-08-10 0:09 ` John Hubbard 2019-08-12 21:00 ` Ira Weiny 2019-08-12 21:00 ` Ira Weiny 2019-08-12 21:20 ` John Hubbard 2019-08-12 21:20 ` John Hubbard 2019-08-12 21:20 ` John Hubbard 2019-08-11 23:07 ` John Hubbard 2019-08-11 23:07 ` John Hubbard 2019-08-11 23:07 ` John Hubbard 2019-08-12 21:01 ` Ira Weiny 2019-08-12 12:28 ` Jason Gunthorpe 2019-08-12 21:48 ` Ira Weiny 2019-08-12 21:48 ` Ira Weiny 2019-08-13 11:47 ` Jason Gunthorpe 2019-08-13 17:46 ` Ira Weiny 2019-08-13 17:46 ` Ira Weiny 2019-08-13 17:56 ` John Hubbard 2019-08-13 17:56 ` John Hubbard 2019-08-13 17:56 ` John Hubbard 2019-08-09 22:58 ` [RFC PATCH v2 16/19] RDMA/uverbs: Add back pointer to system file object ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-12 13:00 ` Jason Gunthorpe 2019-08-12 17:28 ` Ira Weiny 2019-08-12 17:56 ` Jason Gunthorpe 2019-08-12 21:15 ` Ira Weiny 2019-08-12 21:15 ` Ira Weiny 2019-08-13 11:48 ` Jason Gunthorpe 2019-08-13 17:41 ` Ira Weiny 2019-08-13 17:41 ` Ira Weiny 2019-08-13 18:00 ` Jason Gunthorpe 2019-08-13 20:38 ` Ira Weiny 2019-08-13 20:38 ` Ira Weiny 2019-08-14 12:23 ` Jason Gunthorpe 2019-08-14 17:50 ` Ira Weiny 2019-08-14 18:15 ` Jason Gunthorpe 2019-09-04 22:25 ` Ira Weiny 2019-09-11 8:19 ` Jason Gunthorpe 2019-08-09 22:58 ` [RFC PATCH v2 17/19] RDMA/umem: Convert to vaddr_[pin|unpin]* operations ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 18/19] {mm,procfs}: Add display file_pins proc ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-09 22:58 ` [RFC PATCH v2 19/19] mm/gup: Remove FOLL_LONGTERM DAX exclusion ira.weiny 2019-08-09 22:58 ` ira.weiny 2019-08-14 10:17 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Jan Kara 2019-08-14 18:08 ` Ira Weiny [this message] 2019-08-14 18:08 ` Ira Weiny 2019-08-15 13:05 ` Jan Kara 2019-08-16 19:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-16 19:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-16 23:20 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-16 23:20 ` Ira Weiny 2019-08-19 6:36 ` Jan Kara 2019-08-19 6:36 ` Jan Kara 2019-08-17 2:26 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-17 2:26 ` Dave Chinner 2019-08-19 6:34 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Jan Kara 2019-08-19 6:34 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Jan Kara 2019-08-19 9:24 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-19 9:24 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-19 12:38 ` Jason Gunthorpe 2019-08-19 21:53 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-19 21:53 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-20 1:12 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-20 1:12 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-20 11:55 ` Jason Gunthorpe 2019-08-21 18:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 18:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-21 18:13 ` Jason Gunthorpe 2019-08-21 18:22 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-21 18:22 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-21 18:57 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 18:57 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-21 19:06 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 19:06 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-21 19:48 ` Jason Gunthorpe 2019-08-21 20:44 ` Ira Weiny 2019-08-21 23:49 ` Jason Gunthorpe 2019-08-23 3:23 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-23 3:23 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-23 12:04 ` Jason Gunthorpe 2019-08-24 0:11 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-24 0:11 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-24 5:08 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-24 5:08 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-26 5:55 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-26 5:55 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-29 2:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-29 2:02 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-29 3:27 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-29 3:27 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-29 16:16 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-29 16:16 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-09-02 22:26 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-09-02 22:26 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-09-04 16:54 ` Ira Weiny 2019-08-25 19:39 ` Jason Gunthorpe 2019-08-24 4:49 ` Ira Weiny 2019-08-24 4:49 ` Ira Weiny 2019-08-25 19:40 ` Jason Gunthorpe 2019-08-23 0:59 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-23 0:59 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-23 17:15 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-23 17:15 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny 2019-08-24 0:18 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-24 0:18 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-20 0:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-20 0:05 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-20 1:20 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Dave Chinner 2019-08-20 1:20 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Dave Chinner 2019-08-20 3:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-20 3:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-20 3:36 ` Dave Chinner 2019-08-21 18:43 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) John Hubbard 2019-08-21 18:43 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) John Hubbard 2019-08-21 19:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -) Ira Weiny 2019-08-21 19:09 ` [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) Ira Weiny
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190814180848.GB31490@iweiny-DESK2.sc.intel.com \ --to=ira.weiny@intel.com \ --cc=akpm@linux-foundation.org \ --cc=david@fromorbit.com \ --cc=jack@suse.cz \ --cc=jgg@ziepe.ca \ --cc=jhubbard@nvidia.com \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=mhocko@suse.com \ --cc=tytso@mit.edu \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.