From: Matthew Wilcox <willy@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Jason Gunthorpe" <jgg@ziepe.ca>, "Jan Kara" <jack@suse.cz>,
linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org,
"John Hubbard" <jhubbard@nvidia.com>,
"Jeff Layton" <jlayton@kernel.org>,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, "Jérôme Glisse" <jglisse@redhat.com>,
linux-fsdevel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
linux-ext4@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
Date: Thu, 13 Jun 2019 08:27:55 -0700 [thread overview]
Message-ID: <20190613152755.GI32656@bombadil.infradead.org> (raw)
In-Reply-To: <20190613002555.GH14363@dread.disaster.area>
On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote:
> e.g. Process A has an exclusive layout lease on file F. It does an
> IO to file F. The filesystem IO path checks that Process A owns the
> lease on the file and so skips straight through layout breaking
> because it owns the lease and is allowed to modify the layout. It
> then takes the inode metadata locks to allocate new space and write
> new data.
>
> Process B now tries to write to file F. The FS checks whether
> Process B owns a layout lease on file F. It doesn't, so then it
> tries to break the layout lease so the IO can proceed. The layout
> breaking code sees that process A has an exclusive layout lease
> granted, and so returns -ETXTBSY to process B - it is not allowed to
> break the lease and so the IO fails with -ETXTBSY.
This description doesn't match the behaviour that RDMA wants either.
Even if Process A has a lease on the file, an IO from Process A which
results in blocks being freed from the file is going to result in the
RDMA device being able to write to blocks which are now freed (and
potentially reallocated to another file).
_______________________________________________
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: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>
Cc: "Jason Gunthorpe" <jgg-uk2M96/98Pc@public.gmane.org>,
"Jan Kara" <jack-AlSwsSmVLrQ@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"John Hubbard" <jhubbard-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"Jeff Layton" <jlayton-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
"Jérôme Glisse" <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Theodore Ts'o" <tytso-3s7WtUTddSA@public.gmane.org>,
linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Andrew Morton"
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
Date: Thu, 13 Jun 2019 08:27:55 -0700 [thread overview]
Message-ID: <20190613152755.GI32656@bombadil.infradead.org> (raw)
In-Reply-To: <20190613002555.GH14363-pA1nmv6sEBkOM8BvhN4Z8vybgvtCy99p@public.gmane.org>
On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote:
> e.g. Process A has an exclusive layout lease on file F. It does an
> IO to file F. The filesystem IO path checks that Process A owns the
> lease on the file and so skips straight through layout breaking
> because it owns the lease and is allowed to modify the layout. It
> then takes the inode metadata locks to allocate new space and write
> new data.
>
> Process B now tries to write to file F. The FS checks whether
> Process B owns a layout lease on file F. It doesn't, so then it
> tries to break the layout lease so the IO can proceed. The layout
> breaking code sees that process A has an exclusive layout lease
> granted, and so returns -ETXTBSY to process B - it is not allowed to
> break the lease and so the IO fails with -ETXTBSY.
This description doesn't match the behaviour that RDMA wants either.
Even if Process A has a lease on the file, an IO from Process A which
results in blocks being freed from the file is going to result in the
RDMA device being able to write to blocks which are now freed (and
potentially reallocated to another file).
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Ira Weiny" <ira.weiny@intel.com>, "Jan Kara" <jack@suse.cz>,
"Dan Williams" <dan.j.williams@intel.com>,
"Theodore Ts'o" <tytso@mit.edu>,
"Jeff Layton" <jlayton@kernel.org>,
linux-xfs@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-ext4@vger.kernel.org,
linux-mm@kvack.org, "Jason Gunthorpe" <jgg@ziepe.ca>,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
Date: Thu, 13 Jun 2019 08:27:55 -0700 [thread overview]
Message-ID: <20190613152755.GI32656@bombadil.infradead.org> (raw)
In-Reply-To: <20190613002555.GH14363@dread.disaster.area>
On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote:
> e.g. Process A has an exclusive layout lease on file F. It does an
> IO to file F. The filesystem IO path checks that Process A owns the
> lease on the file and so skips straight through layout breaking
> because it owns the lease and is allowed to modify the layout. It
> then takes the inode metadata locks to allocate new space and write
> new data.
>
> Process B now tries to write to file F. The FS checks whether
> Process B owns a layout lease on file F. It doesn't, so then it
> tries to break the layout lease so the IO can proceed. The layout
> breaking code sees that process A has an exclusive layout lease
> granted, and so returns -ETXTBSY to process B - it is not allowed to
> break the lease and so the IO fails with -ETXTBSY.
This description doesn't match the behaviour that RDMA wants either.
Even if Process A has a lease on the file, an IO from Process A which
results in blocks being freed from the file is going to result in the
RDMA device being able to write to blocks which are now freed (and
potentially reallocated to another file).
next prev parent reply other threads:[~2019-06-13 15:28 UTC|newest]
Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 1:45 [PATCH RFC 00/10] RDMA/FS DAX truncate proposal ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 01/10] fs/locks: Add trace_leases_conflict ira.weiny
2019-06-09 12:52 ` Jeff Layton
2019-06-06 1:45 ` [PATCH RFC 02/10] fs/locks: Export F_LAYOUT lease to user space ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-09 13:00 ` Jeff Layton
2019-06-09 13:00 ` Jeff Layton
2019-06-11 21:38 ` Ira Weiny
2019-06-11 21:38 ` Ira Weiny
2019-06-12 9:46 ` Jan Kara
2019-06-06 1:45 ` [PATCH RFC 03/10] mm/gup: Pass flags down to __gup_device_huge* calls ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 6:18 ` Christoph Hellwig
2019-06-06 16:10 ` Ira Weiny
2019-06-06 1:45 ` [PATCH RFC 04/10] mm/gup: Ensure F_LAYOUT lease is held prior to GUP'ing pages ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 05/10] fs/ext4: Teach ext4 to break layout leases ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 06/10] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 07/10] fs/ext4: Fail truncate if pages are GUP pinned ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 10:58 ` Jan Kara
2019-06-06 10:58 ` Jan Kara
2019-06-06 16:17 ` Ira Weiny
2019-06-06 1:45 ` [PATCH RFC 08/10] fs/xfs: Teach xfs to use new dax_layout_busy_page() ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 09/10] fs/xfs: Fail truncate if pages are GUP pinned ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 10/10] mm/gup: Remove FOLL_LONGTERM DAX exclusion ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 5:52 ` [PATCH RFC 00/10] RDMA/FS DAX truncate proposal John Hubbard
2019-06-06 5:52 ` John Hubbard
2019-06-06 17:11 ` Ira Weiny
2019-06-06 17:11 ` Ira Weiny
2019-06-06 19:46 ` Jason Gunthorpe
2019-06-06 10:42 ` Jan Kara
2019-06-06 15:35 ` Dan Williams
2019-06-06 19:51 ` Jason Gunthorpe
2019-06-06 22:22 ` Ira Weiny
2019-06-07 10:36 ` Jan Kara
2019-06-07 12:17 ` Jason Gunthorpe
2019-06-07 14:52 ` Ira Weiny
2019-06-07 14:52 ` Ira Weiny
2019-06-07 15:10 ` Jason Gunthorpe
2019-06-12 10:29 ` Jan Kara
2019-06-12 10:29 ` Jan Kara
2019-06-12 11:47 ` Jason Gunthorpe
2019-06-12 12:09 ` Jan Kara
2019-06-12 12:09 ` Jan Kara
2019-06-12 18:41 ` Dan Williams
2019-06-13 7:17 ` Jan Kara
2019-06-13 7:17 ` Jan Kara
2019-06-12 19:14 ` Jason Gunthorpe
2019-06-12 22:13 ` Ira Weiny
2019-06-12 22:54 ` Dan Williams
2019-06-12 22:54 ` Dan Williams
2019-06-12 23:33 ` Ira Weiny
2019-06-12 23:33 ` Ira Weiny
2019-06-13 1:14 ` Dan Williams
2019-06-13 1:14 ` Dan Williams
2019-06-13 15:13 ` Jason Gunthorpe
2019-06-13 16:25 ` Dan Williams
2019-06-13 16:25 ` Dan Williams
2019-06-13 17:18 ` Jason Gunthorpe
2019-06-13 16:53 ` Dan Williams
2019-06-13 16:53 ` Dan Williams
2019-06-13 15:12 ` Jason Gunthorpe
2019-06-13 7:53 ` Jan Kara
2019-06-13 7:53 ` Jan Kara
2019-06-12 18:49 ` Dan Williams
2019-06-12 18:49 ` Dan Williams
2019-06-13 7:43 ` Jan Kara
2019-06-06 22:03 ` Ira Weiny
2019-06-06 22:03 ` Ira Weiny
2019-06-06 22:26 ` Ira Weiny
2019-06-06 22:28 ` Dave Chinner
2019-06-07 11:04 ` Jan Kara
2019-06-07 18:25 ` Ira Weiny
2019-06-07 18:25 ` Ira Weiny
2019-06-07 18:25 ` Ira Weiny
2019-06-07 18:50 ` Jason Gunthorpe
2019-06-08 0:10 ` Dave Chinner
2019-06-08 0:10 ` Dave Chinner
2019-06-09 1:29 ` Ira Weiny
2019-06-09 1:29 ` Ira Weiny
2019-06-09 1:29 ` Ira Weiny
2019-06-12 12:37 ` Matthew Wilcox
2019-06-12 12:37 ` Matthew Wilcox
2019-06-12 12:37 ` Matthew Wilcox
2019-06-12 23:30 ` Ira Weiny
2019-06-12 23:30 ` Ira Weiny
2019-06-12 23:30 ` Ira Weiny
2019-06-13 0:55 ` Dave Chinner
2019-06-13 0:55 ` Dave Chinner
2019-06-13 0:55 ` Dave Chinner
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-14 3:42 ` Dave Chinner
2019-06-13 0:25 ` Dave Chinner
2019-06-13 0:25 ` Dave Chinner
2019-06-13 3:23 ` Matthew Wilcox
2019-06-13 3:23 ` Matthew Wilcox
2019-06-13 3:23 ` Matthew Wilcox
2019-06-13 4:36 ` Dave Chinner
2019-06-13 4:36 ` Dave Chinner
2019-06-13 4:36 ` Dave Chinner
2019-06-13 10:47 ` Matthew Wilcox
2019-06-13 10:47 ` Matthew Wilcox
2019-06-13 10:47 ` Matthew Wilcox
2019-06-13 15:29 ` Jason Gunthorpe
2019-06-13 15:27 ` Matthew Wilcox [this message]
2019-06-13 15:27 ` Matthew Wilcox
2019-06-13 15:27 ` Matthew Wilcox
2019-06-13 21:13 ` Ira Weiny
2019-06-13 21:13 ` Ira Weiny
2019-06-13 23:45 ` Jason Gunthorpe
2019-06-14 0:00 ` Ira Weiny
2019-06-14 0:00 ` Ira Weiny
2019-06-14 2:09 ` Dave Chinner
2019-06-14 2:09 ` Dave Chinner
2019-06-14 2:09 ` Dave Chinner
2019-06-14 2:31 ` Matthew Wilcox
2019-06-14 2:31 ` Matthew Wilcox
2019-06-14 3:07 ` Dave Chinner
2019-06-14 3:07 ` Dave Chinner
2019-06-14 3:07 ` Dave Chinner
2019-06-20 14:52 ` Jan Kara
2019-06-20 14:52 ` Jan Kara
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-14 2:58 ` Dave Chinner
2019-06-14 2:58 ` Dave Chinner
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=20190613152755.GI32656@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=jlayton@kernel.org \
--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=tytso@mit.edu \
/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: link
Be 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.