Al Viro:
> Different ->i_mutex; you are holding one on the parent directory already.
Let me make sure. In your scenario,
- processA writes something into the union, and the unioning fs operates
the writable layer. After sb_start_write() succeeds, processA should
not block by the reason of
On Sat, Mar 23, 2013 at 11:49:11AM +0900, J. R. Okajima wrote:
>
> Al Viro:
> > The scenario, BTW, looks so:
> > process A does sb_start_write() (on your upper layer)
> > process B tries to freeze said upper layer and blocks, waiting for A to
> > finish
> > process C grabs ->i_mutex in your
Al Viro:
> The scenario, BTW, looks so:
> process A does sb_start_write() (on your upper layer)
> process B tries to freeze said upper layer and blocks, waiting for A to finish
> process C grabs ->i_mutex in your upper layer
> process C does vfs_write(), which blocks, since there's a pending
On Fri, Mar 22, 2013 at 06:11:11PM +, Al Viro wrote:
> On Sat, Mar 23, 2013 at 02:37:55AM +0900, J. R. Okajima wrote:
> >
> > David Howells:
> > > Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
> > > might operate, so it's possible that this is a false alarm.
On Sat, Mar 23, 2013 at 02:37:55AM +0900, J. R. Okajima wrote:
>
> David Howells:
> > Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
> > might operate, so it's possible that this is a false alarm. Maybe Jan Kara
> > can
> > illuminate further, so I've added him to
David Howells:
> Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
> might operate, so it's possible that this is a false alarm. Maybe Jan Kara
> can
> illuminate further, so I've added him to the cc list.
It is related to the design of UnionMount, isn't it?
UnionMount
David Howells:
Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
might operate, so it's possible that this is a false alarm. Maybe Jan Kara
can
illuminate further, so I've added him to the cc list.
It is related to the design of UnionMount, isn't it?
UnionMount is
On Sat, Mar 23, 2013 at 02:37:55AM +0900, J. R. Okajima wrote:
David Howells:
Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
might operate, so it's possible that this is a false alarm. Maybe Jan Kara
can
illuminate further, so I've added him to the cc list.
On Fri, Mar 22, 2013 at 06:11:11PM +, Al Viro wrote:
On Sat, Mar 23, 2013 at 02:37:55AM +0900, J. R. Okajima wrote:
David Howells:
Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
might operate, so it's possible that this is a false alarm. Maybe Jan
Al Viro:
The scenario, BTW, looks so:
process A does sb_start_write() (on your upper layer)
process B tries to freeze said upper layer and blocks, waiting for A to finish
process C grabs -i_mutex in your upper layer
process C does vfs_write(), which blocks, since there's a pending attempt to
On Sat, Mar 23, 2013 at 11:49:11AM +0900, J. R. Okajima wrote:
Al Viro:
The scenario, BTW, looks so:
process A does sb_start_write() (on your upper layer)
process B tries to freeze said upper layer and blocks, waiting for A to
finish
process C grabs -i_mutex in your upper layer
Al Viro:
Different -i_mutex; you are holding one on the parent directory already.
Let me make sure. In your scenario,
- processA writes something into the union, and the unioning fs operates
the writable layer. After sb_start_write() succeeds, processA should
not block by the reason of
On Wed 20-03-13 21:48:13, Al Viro wrote:
> On Wed, Mar 20, 2013 at 08:52:22PM +0100, Jan Kara wrote:
> > > do_bio_filebacked(), with some ugliness between that and callsite. Note,
> > > BTW, that we have a pair of possible vfs_fsync() calls in there; how do
> > > those
> > > interact with
On Wed, Mar 20, 2013 at 08:52:22PM +0100, Jan Kara wrote:
> > do_bio_filebacked(), with some ugliness between that and callsite. Note,
> > BTW, that we have a pair of possible vfs_fsync() calls in there; how do
> > those
> > interact with freeze?
> Freezing code takes care that all dirty data
On Wed 20-03-13 02:33:08, Al Viro wrote:
> On Tue, Mar 19, 2013 at 10:10:32PM +, Al Viro wrote:
>
> > OK, it's going to be an interesting series - aforementioned tentative patch
> > was badly incomplete ;-/
>
> The interesting question is how far do we want to lift that. ->aio_write()
>
Al Viro wrote:
> fs/cachefiles/rdwr.c:967: ret = file->f_op->write(
>
> cachefiles_write_page(); no fucking idea what locks might be held by caller
> and potentially that's a rather nasty source of PITA
The caller of cachefiles_write_page() (ie. fscache_write_op()) holds
On Tue, Mar 19, 2013 at 10:24 PM, Al Viro wrote:
> it still might make sense to implement
> something as a layer, but some parts of that sucker may be better off as
> fs primitives. Hell, we could, in theory, implement xattrs as a layer;
> just look at how reiserfs had done them. We could do
On Tue, Mar 19, 2013 at 10:24 PM, Al Viro v...@zeniv.linux.org.uk wrote:
it still might make sense to implement
something as a layer, but some parts of that sucker may be better off as
fs primitives. Hell, we could, in theory, implement xattrs as a layer;
just look at how reiserfs had done
Al Viro v...@zeniv.linux.org.uk wrote:
fs/cachefiles/rdwr.c:967: ret = file-f_op-write(
cachefiles_write_page(); no fucking idea what locks might be held by caller
and potentially that's a rather nasty source of PITA
The caller of cachefiles_write_page() (ie.
On Wed 20-03-13 02:33:08, Al Viro wrote:
On Tue, Mar 19, 2013 at 10:10:32PM +, Al Viro wrote:
OK, it's going to be an interesting series - aforementioned tentative patch
was badly incomplete ;-/
The interesting question is how far do we want to lift that. -aio_write()
part is
On Wed, Mar 20, 2013 at 08:52:22PM +0100, Jan Kara wrote:
do_bio_filebacked(), with some ugliness between that and callsite. Note,
BTW, that we have a pair of possible vfs_fsync() calls in there; how do
those
interact with freeze?
Freezing code takes care that all dirty data is synced
On Wed 20-03-13 21:48:13, Al Viro wrote:
On Wed, Mar 20, 2013 at 08:52:22PM +0100, Jan Kara wrote:
do_bio_filebacked(), with some ugliness between that and callsite. Note,
BTW, that we have a pair of possible vfs_fsync() calls in there; how do
those
interact with freeze?
On Tue, Mar 19, 2013 at 10:10:32PM +, Al Viro wrote:
> OK, it's going to be an interesting series - aforementioned tentative patch
> was badly incomplete ;-/
The interesting question is how far do we want to lift that. ->aio_write()
part is trivial - see vfs.git#experimental; the trouble
On Tue, Mar 19, 2013 at 09:38:31PM +, Al Viro wrote:
> On Tue, Mar 19, 2013 at 09:25:43PM +0100, Jan Kara wrote:
> > > BTW, having sb_start_write() buried in individual ->splice_write() is
> > > asking for trouble; could you describe the rules for that? E.g. where
> > > does it nest wrt
On Tue, Mar 19, 2013 at 09:25:43PM +0100, Jan Kara wrote:
> > BTW, having sb_start_write() buried in individual ->splice_write() is
> > asking for trouble; could you describe the rules for that? E.g. where
> > does it nest wrt filesystem-private locks? XFS iolock, for example...
> Generally,
On Tue, Mar 19, 2013 at 07:32:42PM +0100, Miklos Szeredi wrote:
> > * victim is negative => create a whiteout
> > * victim is a directory, parent opaque => rmdir
> > * victim is a non-directory, parent opaque => unlink
> > * victim is positive, parent _not_ opaque
On Mon 18-03-13 23:01:03, Al Viro wrote:
> On Mon, Mar 18, 2013 at 09:53:34PM +, Al Viro wrote:
> > On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
> > > IMO the deadlock is real. In freeze_super() we wait for all writers to
> > > the filesystem to finish while blocking beginning
On Mon 18-03-13 21:53:34, Al Viro wrote:
> On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
> > IMO the deadlock is real. In freeze_super() we wait for all writers to
> > the filesystem to finish while blocking beginning of any further writes. So
> > we have a deadlock scenario like:
>
On Tue, Mar 19, 2013 at 6:03 PM, Al Viro wrote:
> On Tue, Mar 19, 2013 at 11:29:41AM +0100, Miklos Szeredi wrote:
>
>> Copy up is a once-in-a-lifetime event for an object. Optimizing it is
>> way down in the list of things to do. I'd drop splice in a jiffy if
>> it's in the way.
>
> What makes
On Tue, Mar 19, 2013 at 11:29:41AM +0100, Miklos Szeredi wrote:
> Copy up is a once-in-a-lifetime event for an object. Optimizing it is
> way down in the list of things to do. I'd drop splice in a jiffy if
> it's in the way.
What makes you think that write is any better? Same deadlock there -
On Tue, Mar 19, 2013 at 12:04 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> > BTW, I wonder what's the right locking for that sucker; overlayfs is
>> > probably too heavy - we are talking about copying a file from one fs to
>> > another, which can obviously take quite a while, so holding
Miklos Szeredi wrote:
> > BTW, I wonder what's the right locking for that sucker; overlayfs is
> > probably too heavy - we are talking about copying a file from one fs to
> > another, which can obviously take quite a while, so holding ->i_mutex on
> > _parent_ all along is asking for very
On Tue, Mar 19, 2013 at 2:38 AM, Al Viro wrote:
> On Mon, Mar 18, 2013 at 11:01:03PM +, Al Viro wrote:
>
>> I'm looking at the existing callers and I really wonder if we ought to
>> push sb_start_write() from ->splice_write()/->aio_write()/etc. into the
>> callers.
>>
>> Something like
Al Viro:
> BTW, I wonder what's the right locking for that sucker; overlayfs is probably
> too heavy - we are talking about copying a file from one fs to another, which
> can obviously take quite a while, so holding ->i_mutex on _parent_ all along
> is asking for very serious contention. OTOH,
Al Viro:
BTW, I wonder what's the right locking for that sucker; overlayfs is probably
too heavy - we are talking about copying a file from one fs to another, which
can obviously take quite a while, so holding -i_mutex on _parent_ all along
is asking for very serious contention. OTOH,
On Tue, Mar 19, 2013 at 2:38 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Mar 18, 2013 at 11:01:03PM +, Al Viro wrote:
I'm looking at the existing callers and I really wonder if we ought to
push sb_start_write() from -splice_write()/-aio_write()/etc. into the
callers.
Something
Miklos Szeredi mik...@szeredi.hu wrote:
BTW, I wonder what's the right locking for that sucker; overlayfs is
probably too heavy - we are talking about copying a file from one fs to
another, which can obviously take quite a while, so holding -i_mutex on
_parent_ all along is asking for
On Tue, Mar 19, 2013 at 12:04 PM, David Howells dhowe...@redhat.com wrote:
Miklos Szeredi mik...@szeredi.hu wrote:
BTW, I wonder what's the right locking for that sucker; overlayfs is
probably too heavy - we are talking about copying a file from one fs to
another, which can obviously take
On Tue, Mar 19, 2013 at 11:29:41AM +0100, Miklos Szeredi wrote:
Copy up is a once-in-a-lifetime event for an object. Optimizing it is
way down in the list of things to do. I'd drop splice in a jiffy if
it's in the way.
What makes you think that write is any better? Same deadlock there -
On Tue, Mar 19, 2013 at 6:03 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Mar 19, 2013 at 11:29:41AM +0100, Miklos Szeredi wrote:
Copy up is a once-in-a-lifetime event for an object. Optimizing it is
way down in the list of things to do. I'd drop splice in a jiffy if
it's in the way.
On Mon 18-03-13 21:53:34, Al Viro wrote:
On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
IMO the deadlock is real. In freeze_super() we wait for all writers to
the filesystem to finish while blocking beginning of any further writes. So
we have a deadlock scenario like:
On Mon 18-03-13 23:01:03, Al Viro wrote:
On Mon, Mar 18, 2013 at 09:53:34PM +, Al Viro wrote:
On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
IMO the deadlock is real. In freeze_super() we wait for all writers to
the filesystem to finish while blocking beginning of any
On Tue, Mar 19, 2013 at 07:32:42PM +0100, Miklos Szeredi wrote:
* victim is negative = create a whiteout
* victim is a directory, parent opaque = rmdir
* victim is a non-directory, parent opaque = unlink
* victim is positive, parent _not_ opaque = replace
On Tue, Mar 19, 2013 at 09:25:43PM +0100, Jan Kara wrote:
BTW, having sb_start_write() buried in individual -splice_write() is
asking for trouble; could you describe the rules for that? E.g. where
does it nest wrt filesystem-private locks? XFS iolock, for example...
Generally, the
On Tue, Mar 19, 2013 at 09:38:31PM +, Al Viro wrote:
On Tue, Mar 19, 2013 at 09:25:43PM +0100, Jan Kara wrote:
BTW, having sb_start_write() buried in individual -splice_write() is
asking for trouble; could you describe the rules for that? E.g. where
does it nest wrt
On Tue, Mar 19, 2013 at 10:10:32PM +, Al Viro wrote:
OK, it's going to be an interesting series - aforementioned tentative patch
was badly incomplete ;-/
The interesting question is how far do we want to lift that. -aio_write()
part is trivial - see vfs.git#experimental; the trouble
On Mon, Mar 18, 2013 at 11:01:03PM +, Al Viro wrote:
> I'm looking at the existing callers and I really wonder if we ought to
> push sb_start_write() from ->splice_write()/->aio_write()/etc. into the
> callers.
>
> Something like file_start_write()/file_end_write(), with check for file
>
On Mon, Mar 18, 2013 at 09:53:34PM +, Al Viro wrote:
> On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
> > IMO the deadlock is real. In freeze_super() we wait for all writers to
> > the filesystem to finish while blocking beginning of any further writes. So
> > we have a deadlock
On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
> IMO the deadlock is real. In freeze_super() we wait for all writers to
> the filesystem to finish while blocking beginning of any further writes. So
> we have a deadlock scenario like:
>
> THREAD1 THREAD2
On Sun 17-03-13 13:06:59, David Howells wrote:
> Miklos Szeredi wrote:
>
> > Export do_splice_direct() to modules. Needed by overlay filesystem.
>
> Apparently you cannot call this from any function that is holding an i_mutex
> if the target of the splice uses generic_file_splice_write().
>
>
On Sun 17-03-13 13:06:59, David Howells wrote:
Miklos Szeredi mik...@szeredi.hu wrote:
Export do_splice_direct() to modules. Needed by overlay filesystem.
Apparently you cannot call this from any function that is holding an i_mutex
if the target of the splice uses
On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
IMO the deadlock is real. In freeze_super() we wait for all writers to
the filesystem to finish while blocking beginning of any further writes. So
we have a deadlock scenario like:
THREAD1 THREAD2
On Mon, Mar 18, 2013 at 09:53:34PM +, Al Viro wrote:
On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote:
IMO the deadlock is real. In freeze_super() we wait for all writers to
the filesystem to finish while blocking beginning of any further writes. So
we have a deadlock scenario
On Mon, Mar 18, 2013 at 11:01:03PM +, Al Viro wrote:
I'm looking at the existing callers and I really wonder if we ought to
push sb_start_write() from -splice_write()/-aio_write()/etc. into the
callers.
Something like file_start_write()/file_end_write(), with check for file
being
On Sun, Mar 17, 2013 at 01:06:59PM +, David Howells wrote:
> Miklos Szeredi wrote:
>
> > Export do_splice_direct() to modules. Needed by overlay filesystem.
>
> Apparently you cannot call this from any function that is holding an i_mutex
> if the target of the splice uses
Miklos Szeredi wrote:
> Export do_splice_direct() to modules. Needed by overlay filesystem.
Apparently you cannot call this from any function that is holding an i_mutex
if the target of the splice uses generic_file_splice_write().
The problem is a potential deadlock situation:
We have places
Miklos Szeredi mik...@szeredi.hu wrote:
Export do_splice_direct() to modules. Needed by overlay filesystem.
Apparently you cannot call this from any function that is holding an i_mutex
if the target of the splice uses generic_file_splice_write().
The problem is a potential deadlock situation:
On Sun, Mar 17, 2013 at 01:06:59PM +, David Howells wrote:
Miklos Szeredi mik...@szeredi.hu wrote:
Export do_splice_direct() to modules. Needed by overlay filesystem.
Apparently you cannot call this from any function that is holding an i_mutex
if the target of the splice uses
On Wed, 13 Mar 2013 15:16:26 +0100 Miklos Szeredi wrote:
> From: Miklos Szeredi
>
> Export do_splice_direct() to modules. Needed by overlay filesystem.
>
> Signed-off-by: Miklos Szeredi
> ---
> fs/splice.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/splice.c
From: Miklos Szeredi
Export do_splice_direct() to modules. Needed by overlay filesystem.
Signed-off-by: Miklos Szeredi
---
fs/splice.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/splice.c b/fs/splice.c
index 718bd00..0e8f44a 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1308,6
On Wed, 13 Mar 2013 15:16:26 +0100 Miklos Szeredi mik...@szeredi.hu wrote:
From: Miklos Szeredi mszer...@suse.cz
Export do_splice_direct() to modules. Needed by overlay filesystem.
Signed-off-by: Miklos Szeredi mszer...@suse.cz
---
fs/splice.c |1 +
1 file changed, 1 insertion(+)
From: Miklos Szeredi mszer...@suse.cz
Export do_splice_direct() to modules. Needed by overlay filesystem.
Signed-off-by: Miklos Szeredi mszer...@suse.cz
---
fs/splice.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/splice.c b/fs/splice.c
index 718bd00..0e8f44a 100644
---
62 matches
Mail list logo
