On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> On Tue, Sep 4, 2018 at 7:09 PM Jeff Layton wrote:
> >
> > On Tue, 2018-09-04 at 16:58 +0800, Trol wrote:
> > > On Tue, Sep 4, 2018 at 3:53 PM Rogier Wolff
> > > wrote:
> > >
> > > ...
> >
or a tunable that does a kernel panic if writebacks fail
and the errors are never fetched via fsync, and we run out of memory. I
don't think that is something most users would want though.
Another thought: maybe we could OOM kill any process that has the file
open and then toss out the page data in that situation?
I'm wide open to (good) ideas here.
--
Jeff Layton
or a tunable that does a kernel panic if writebacks fail
and the errors are never fetched via fsync, and we run out of memory. I
don't think that is something most users would want though.
Another thought: maybe we could OOM kill any process that has the file
open and then toss out the page data in that situation?
I'm wide open to (good) ideas here.
--
Jeff Layton
ck some data from the cache and that fails,
what should happen to the dirty pages?
Unfortunately, there are no good answers given the write/fsync/read
model for I/O. I tend to think that in the long run we may need new
interfaces to handle this better.
--
Jeff Layton
ck some data from the cache and that fails,
what should happen to the dirty pages?
Unfortunately, there are no good answers given the write/fsync/read
model for I/O. I tend to think that in the long run we may need new
interfaces to handle this better.
--
Jeff Layton
go to
copy_process, then just return -EAGAIN.
Cc: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/exec.c | 14 --
fs/file.c | 1 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 21 ++---
4 files changed, 28 insertions(+), 9
go to
copy_process, then just return -EAGAIN.
Cc: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/exec.c | 14 --
fs/file.c | 1 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 21 ++---
4 files changed, 28 insertions(+), 9
to track an "in_exec" flag that will
need to be handled in conjunction with the thread counter.
Reported-by: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/file.c | 17 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 17 ++--
o
some of this with atomic ops if the basic approach turns out to be
reasonable.
Comments and suggestions welcome.
Jeff Layton (3):
exec: separate thread_count for files_struct
exec: delay clone(CLONE_FILES) if task associated with current
files_struct is exec'ing
exec: do unshare_files after de_threa
to track an "in_exec" flag that will
need to be handled in conjunction with the thread counter.
Reported-by: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/file.c | 17 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 17 ++--
o
some of this with atomic ops if the basic approach turns out to be
reasonable.
Comments and suggestions welcome.
Jeff Layton (3):
exec: separate thread_count for files_struct
exec: delay clone(CLONE_FILES) if task associated with current
files_struct is exec'ing
exec: do unshare_files after de_threa
by: Daniel P. Berrangé
Signed-off-by: Jeff Layton
---
fs/exec.c | 11 ++-
include/linux/binfmts.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index ca25f805ebad..e32bd1a33660 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1262,
by: Daniel P. Berrangé
Signed-off-by: Jeff Layton
---
fs/exec.c | 11 ++-
include/linux/binfmts.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index ca25f805ebad..e32bd1a33660 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1262,
On Mon, 2018-08-27 at 13:47 -0400, Jeff Layton wrote:
> POSIX mandates that open fds and their associated file locks should be
> preserved across an execve. This works, unless the process is
> multithreaded at the time that execve is called.
>
> In that case, we'll e
On Mon, 2018-08-27 at 13:47 -0400, Jeff Layton wrote:
> POSIX mandates that open fds and their associated file locks should be
> preserved across an execve. This works, unless the process is
> multithreaded at the time that execve is called.
>
> In that case, we'll e
to track an "in_exec" flag that will
need to be handled in conjunction with the thread counter.
Reported-by: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/file.c | 17 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 17 ++--
by: Daniel P. Berrangé
Signed-off-by: Jeff Layton
---
fs/exec.c | 19 +--
include/linux/binfmts.h | 1 +
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index ca25f805ebad..a45b0cae5817 100644
--- a/fs/exec.c
+++ b/fs/exec.c
probe. That may make this idea
non-viable.
I'm also not terribly thrilled with the way this sprinkles the
files_struct->file_lock all over the place. It may be possible to do
some of this with atomic ops if the basic approach turns out to be
reasonable.
Comments and suggestions welcome.
J
to track an "in_exec" flag that will
need to be handled in conjunction with the thread counter.
Reported-by: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/file.c | 17 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 17 ++--
by: Daniel P. Berrangé
Signed-off-by: Jeff Layton
---
fs/exec.c | 19 +--
include/linux/binfmts.h | 1 +
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index ca25f805ebad..a45b0cae5817 100644
--- a/fs/exec.c
+++ b/fs/exec.c
probe. That may make this idea
non-viable.
I'm also not terribly thrilled with the way this sprinkles the
files_struct->file_lock all over the place. It may be possible to do
some of this with atomic ops if the basic approach turns out to be
reasonable.
Comments and suggestions welcome.
J
go to
copy_process, then just return -EAGAIN.
Cc: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/exec.c | 14 --
fs/file.c | 1 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 21 ++---
4 files changed, 28 insertions(+), 9
go to
copy_process, then just return -EAGAIN.
Cc: Eric W. Biederman
Signed-off-by: Jeff Layton
---
fs/exec.c | 14 --
fs/file.c | 1 +
include/linux/fdtable.h | 1 +
kernel/fork.c | 21 ++---
4 files changed, 28 insertions(+), 9
On Tue, 2018-08-21 at 15:11 +1000, NeilBrown wrote:
> On Thu, Aug 16 2018, NeilBrown wrote:
>
> > On Wed, Aug 15 2018, Jeff Layton wrote:
> >
> > > On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
> > > > Hi,
On Tue, 2018-08-21 at 15:11 +1000, NeilBrown wrote:
> On Thu, Aug 16 2018, NeilBrown wrote:
>
> > On Wed, Aug 15 2018, Jeff Layton wrote:
> >
> > > On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
> > > > Hi,
fl_blocked list is being handled properly with all
of them. It only transplants the blocked locks to a new lock when there
are surviving locks on the list, and that may not be the case when the
whole file is being unlocked.
--
Jeff Layton
fl_blocked list is being handled properly with all
of them. It only transplants the blocked locks to a new lock when there
are surviving locks on the list, and that may not be the case when the
whole file is being unlocked.
--
Jeff Layton
elated to that
> commit.
>
> Best regards,
> Krzysztof
Thanks Krzysztof,
I or Neil will see if this is reproducible and see about coming up with
a fix. For now, I'll take this out of -next.
Thanks,
--
Jeff Layton
elated to that
> commit.
>
> Best regards,
> Krzysztof
Thanks Krzysztof,
I or Neil will see if this is reproducible and see about coming up with
a fix. For now, I'll take this out of -next.
Thanks,
--
Jeff Layton
ange all *_conflict() functions to return bool.
> > fs/locks: create a tree of dependent requests.
> >
> >
> > fs/cifs/file.c |2 -
> > fs/locks.c | 156
> > ++-
> > include/linux/fs.h |7 +-
> > include/trace/events/filelock.h | 16 ++--
> > 4 files changed, 119 insertions(+), 62 deletions(-)
> >
> > --
> > Signature
--
Jeff Layton
ange all *_conflict() functions to return bool.
> > fs/locks: create a tree of dependent requests.
> >
> >
> > fs/cifs/file.c |2 -
> > fs/locks.c | 156
> > ++-
> > include/linux/fs.h |7 +-
> > include/trace/events/filelock.h | 16 ++--
> > 4 files changed, 119 insertions(+), 62 deletions(-)
> >
> > --
> > Signature
--
Jeff Layton
the
process that set the lock has exited, and a new tracepoint for the
flock() codepath. Also threw in mailmap entries for my addresses and a
comment cleanup.
Jeff Layton (3):
locks: add tracepoint in flock codepath
the
process that set the lock has exited, and a new tracepoint for the
flock() codepath. Also threw in mailmap entries for my addresses and a
comment cleanup.
Jeff Layton (3):
locks: add tracepoint in flock codepath
On Sat, 2018-08-11 at 08:21 -0400, J. Bruce Fields wrote:
> On Sat, Aug 11, 2018 at 07:51:13AM -0400, Jeff Layton wrote:
> > On Thu, 2018-08-09 at 20:29 -0400, J. Bruce Fields wrote:
> > > On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> > > > On Thu, Aug
On Sat, 2018-08-11 at 08:21 -0400, J. Bruce Fields wrote:
> On Sat, Aug 11, 2018 at 07:51:13AM -0400, Jeff Layton wrote:
> > On Thu, 2018-08-09 at 20:29 -0400, J. Bruce Fields wrote:
> > > On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> > > > On Thu, Aug
d lock is released, as they would all be in a long chain of
waiters.
If you keep all the locks in a single list, you'll either have to:
a) wake up all the waiters on the list when the lock comes free: no lock
is held at that point so none of them will conflict.
...or...
b) keep track of what waiters have already been awoken, and compare any
further candidate for waking against the current set of held locks and
any lock requests by waiters that you just woke.
b seems more expensive as you have to walk over a larger set of locks
on every change.
--
Jeff Layton
d lock is released, as they would all be in a long chain of
waiters.
If you keep all the locks in a single list, you'll either have to:
a) wake up all the waiters on the list when the lock comes free: no lock
is held at that point so none of them will conflict.
...or...
b) keep track of what waiters have already been awoken, and compare any
further candidate for waking against the current set of held locks and
any lock requests by waiters that you just woke.
b seems more expensive as you have to walk over a larger set of locks
on every change.
--
Jeff Layton
's information we
> need (the owners of the waiting locks in the tree) that we can't
> determine just from looking at the root of the tree.
>
> I'm not sure what to do about that.
>
Is this still a problem in the v2 set?
wake_non_conflicts walks the whole tree of requests that were blocked on
it, so a. After task 2 discovers the conflict, it should wake any of its
children that don't conflict. So in that last step, task 3 would be
awoken before task 2 goes back to sleep.
--
Jeff Layton
's information we
> need (the owners of the waiting locks in the tree) that we can't
> determine just from looking at the root of the tree.
>
> I'm not sure what to do about that.
>
Is this still a problem in the v2 set?
wake_non_conflicts walks the whole tree of requests that were blocked on
it, so a. After task 2 discovers the conflict, it should wake any of its
children that don't conflict. So in that last step, task 3 would be
awoken before task 2 goes back to sleep.
--
Jeff Layton
On Thu, 2018-08-09 at 09:00 -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 06:50:06PM -0400, Jeff Layton wrote:
> > That seems like a legit problem.
> >
> > One possible fix might be to have the waiter on (1,2) walk down the
> > entire subtree and wake up
On Thu, 2018-08-09 at 09:00 -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 06:50:06PM -0400, Jeff Layton wrote:
> > That seems like a legit problem.
> >
> > One possible fix might be to have the waiter on (1,2) walk down the
> > entire subtree and wake up
;
> - __locks_insert_block(fl, request);
> + __locks_insert_block(fl, request,
> + posix_locks_conflict);
> }
> spin_unlock(_lock_lock);
> goto out;
> @@ -1581,7 +1638,7 @@ int __break_lease(struct inode *inode, unsigned int
> mode, unsigned int type)
> break_time -= jiffies;
> if (break_time == 0)
> break_time++;
> - locks_insert_block(fl, new_fl);
> + locks_insert_block(fl, new_fl, leases_conflict);
> trace_break_lease_block(inode, new_fl);
> spin_unlock(>flc_lock);
> percpu_up_read_preempt_enable(_rwsem);
>
>
--
Jeff Layton
;
> - __locks_insert_block(fl, request);
> + __locks_insert_block(fl, request,
> + posix_locks_conflict);
> }
> spin_unlock(_lock_lock);
> goto out;
> @@ -1581,7 +1638,7 @@ int __break_lease(struct inode *inode, unsigned int
> mode, unsigned int type)
> break_time -= jiffies;
> if (break_time == 0)
> break_time++;
> - locks_insert_block(fl, new_fl);
> + locks_insert_block(fl, new_fl, leases_conflict);
> trace_break_lease_block(inode, new_fl);
> spin_unlock(>flc_lock);
> percpu_up_read_preempt_enable(_rwsem);
>
>
--
Jeff Layton
return locks_conflict(caller_fl, sys_fl);
> }
>
> void
> @@ -1435,12 +1468,13 @@ static void time_out_leases(struct inode *inode,
> struct list_head *dispose)
> }
> }
>
> -static bool leases_conflict(struct file_lock *lease, struct file_lock
> *breaker)
> +static enum conflict leases_conflict(struct file_lock *lease,
> + struct file_lock *breaker)
> {
> if ((breaker->fl_flags & FL_LAYOUT) != (lease->fl_flags & FL_LAYOUT))
> - return false;
> + return FL_NO_CONFLICT;
> if ((breaker->fl_flags & FL_DELEG) && (lease->fl_flags & FL_LEASE))
> - return false;
> + return FL_NO_CONFLICT;
> return locks_conflict(breaker, lease);
> }
>
>
>
--
Jeff Layton
return locks_conflict(caller_fl, sys_fl);
> }
>
> void
> @@ -1435,12 +1468,13 @@ static void time_out_leases(struct inode *inode,
> struct list_head *dispose)
> }
> }
>
> -static bool leases_conflict(struct file_lock *lease, struct file_lock
> *breaker)
> +static enum conflict leases_conflict(struct file_lock *lease,
> + struct file_lock *breaker)
> {
> if ((breaker->fl_flags & FL_LAYOUT) != (lease->fl_flags & FL_LAYOUT))
> - return false;
> + return FL_NO_CONFLICT;
> if ((breaker->fl_flags & FL_DELEG) && (lease->fl_flags & FL_LEASE))
> - return false;
> + return FL_NO_CONFLICT;
> return locks_conflict(breaker, lease);
> }
>
>
>
--
Jeff Layton
That seems like a legit problem.
One possible fix might be to have the waiter on (1,2) walk down the
entire subtree and wake up any waiter that is waiting on a lock that
doesn't conflict with the lock on which it's waiting.
So, before the task waiting on 1,2 goes back to sleep to wait on 2,2, it
could walk down its entire fl_blocked subtree and wake up anything
waiting on a lock that doesn't conflict with (2,2).
That's potentially an expensive operation, but:
a) the task is going back to sleep anyway, so letting it do a little
extra work before that should be no big deal
b) it's probably still cheaper than waking up the whole herd
--
Jeff Layton
That seems like a legit problem.
One possible fix might be to have the waiter on (1,2) walk down the
entire subtree and wake up any waiter that is waiting on a lock that
doesn't conflict with the lock on which it's waiting.
So, before the task waiting on 1,2 goes back to sleep to wait on 2,2, it
could walk down its entire fl_blocked subtree and wake up anything
waiting on a lock that doesn't conflict with (2,2).
That's potentially an expensive operation, but:
a) the task is going back to sleep anyway, so letting it do a little
extra work before that should be no big deal
b) it's probably still cheaper than waking up the whole herd
--
Jeff Layton
62 deletions(-)
>
Nice work! I looked over this and I think it looks good.
I made an attempt to fix this issue several years ago, but my method
sucked as it ended up penalizing the unlocking task too much. This is
much cleaner and should scale well overall, I think.
I'll put this in -next soon and we can aim for merge in v4.20.
Thanks,
--
Jeff Layton
62 deletions(-)
>
Nice work! I looked over this and I think it looks good.
I made an attempt to fix this issue several years ago, but my method
sucked as it ended up penalizing the unlocking task too much. This is
much cleaner and should scale well overall, I think.
I'll put this in -next soon and we can aim for merge in v4.20.
Thanks,
--
Jeff Layton
ield(fl_owner_t, fl_owner)
> __field(unsigned int, fl_flags)
> __field(unsigned char, fl_type)
> @@ -134,7 +134,7 @@ DECLARE_EVENT_CLASS(filelock_lease,
> __entry->fl = fl ? fl : NULL;
> __entry->s_dev = inode->i_sb->s_dev;
> __entry->i_ino = inode->i_ino;
> - __entry->fl_next = fl ? fl->fl_next : NULL;
> + __entry->fl_blocker = fl ? fl->fl_blocker : NULL;
> __entry->fl_owner = fl ? fl->fl_owner : NULL;
> __entry->fl_flags = fl ? fl->fl_flags : 0;
> __entry->fl_type = fl ? fl->fl_type : 0;
> @@ -142,9 +142,9 @@ DECLARE_EVENT_CLASS(filelock_lease,
> __entry->fl_downgrade_time = fl ? fl->fl_downgrade_time : 0;
> ),
>
> - TP_printk("fl=0x%p dev=0x%x:0x%x ino=0x%lx fl_next=0x%p fl_owner=0x%p
> fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> + TP_printk("fl=0x%p dev=0x%x:0x%x ino=0x%lx fl_blocker=0x%p
> fl_owner=0x%p fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> __entry->fl, MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> - __entry->i_ino, __entry->fl_next, __entry->fl_owner,
> + __entry->i_ino, __entry->fl_blocker, __entry->fl_owner,
> show_fl_flags(__entry->fl_flags),
> show_fl_type(__entry->fl_type),
> __entry->fl_break_time, __entry->fl_downgrade_time)
>
>
--
Jeff Layton
ield(fl_owner_t, fl_owner)
> __field(unsigned int, fl_flags)
> __field(unsigned char, fl_type)
> @@ -134,7 +134,7 @@ DECLARE_EVENT_CLASS(filelock_lease,
> __entry->fl = fl ? fl : NULL;
> __entry->s_dev = inode->i_sb->s_dev;
> __entry->i_ino = inode->i_ino;
> - __entry->fl_next = fl ? fl->fl_next : NULL;
> + __entry->fl_blocker = fl ? fl->fl_blocker : NULL;
> __entry->fl_owner = fl ? fl->fl_owner : NULL;
> __entry->fl_flags = fl ? fl->fl_flags : 0;
> __entry->fl_type = fl ? fl->fl_type : 0;
> @@ -142,9 +142,9 @@ DECLARE_EVENT_CLASS(filelock_lease,
> __entry->fl_downgrade_time = fl ? fl->fl_downgrade_time : 0;
> ),
>
> - TP_printk("fl=0x%p dev=0x%x:0x%x ino=0x%lx fl_next=0x%p fl_owner=0x%p
> fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> + TP_printk("fl=0x%p dev=0x%x:0x%x ino=0x%lx fl_blocker=0x%p
> fl_owner=0x%p fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> __entry->fl, MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> - __entry->i_ino, __entry->fl_next, __entry->fl_owner,
> + __entry->i_ino, __entry->fl_blocker, __entry->fl_owner,
> show_fl_flags(__entry->fl_flags),
> show_fl_type(__entry->fl_type),
> __entry->fl_break_time, __entry->fl_downgrade_time)
>
>
--
Jeff Layton
Signed-off-by: Jeff Layton
---
fs/locks.c | 1 +
include/trace/events/filelock.h | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/locks.c b/fs/locks.c
index e533623e2e99..6138a9bcd924 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -990,6 +990,7
Signed-off-by: Jeff Layton
---
fs/locks.c | 1 +
include/trace/events/filelock.h | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/locks.c b/fs/locks.c
index e533623e2e99..6138a9bcd924 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -990,6 +990,7
From: Jeff Layton
Keep a per-sb errseq_t that tracks whether there have been any writeback
errors on this superblock. When an error is recorded for an inode via
mapping_set_error, record it in s_wb_err as well.
Cc: Andres Freund
Cc: Matthew Wilcox
Signed-off-by: Jeff Layton
---
include
From: Jeff Layton
Keep a per-sb errseq_t that tracks whether there have been any writeback
errors on this superblock. When an error is recorded for an inode via
mapping_set_error, record it in s_wb_err as well.
Cc: Andres Freund
Cc: Matthew Wilcox
Signed-off-by: Jeff Layton
---
include
From: Jeff Layton
Add support for error_state struct to test-fsinfo sample program.
Signed-off-by: Jeff Layton
---
samples/statx/test-fsinfo.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/samples/statx/test-fsinfo.c b/samples/statx/test-fsinfo.c
index 9e9fa62a3b9f
From: Jeff Layton
Add support for error_state struct to test-fsinfo sample program.
Signed-off-by: Jeff Layton
---
samples/statx/test-fsinfo.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/samples/statx/test-fsinfo.c b/samples/statx/test-fsinfo.c
index 9e9fa62a3b9f
From: Jeff Layton
Add a new "error_state" struct to fsinfo, and teach the kernel to fill
that out from sb->s_wb_info. There are two fields:
wb_error_last: the most recently recorded errno for the filesystem
wb_error_cookie: this value will change vs. the previ
to roll a testcase for this.
Al, if this looks ok, could you pull this into the branch where you
have David's fsinfo patches queued up?
Thanks,
Jeff
Jeff Layton (4):
vfs: track per-sb writeback errors
errseq: add a new errseq_scrape function
vfs: allow fsinfo to fetch the current state
to roll a testcase for this.
Al, if this looks ok, could you pull this into the branch where you
have David's fsinfo patches queued up?
Thanks,
Jeff
Jeff Layton (4):
vfs: track per-sb writeback errors
errseq: add a new errseq_scrape function
vfs: allow fsinfo to fetch the current state
From: Jeff Layton
Add a new "error_state" struct to fsinfo, and teach the kernel to fill
that out from sb->s_wb_info. There are two fields:
wb_error_last: the most recently recorded errno for the filesystem
wb_error_cookie: this value will change vs. the previ
From: Jeff Layton
To grab the current value of an errseq_t, mark it as seen and then
return the value with the seen bit masked off.
Signed-off-by: Jeff Layton
---
include/linux/errseq.h | 1 +
lib/errseq.c | 33 +++--
2 files changed, 32 insertions(+), 2
From: Jeff Layton
To grab the current value of an errseq_t, mark it as seen and then
return the value with the seen bit masked off.
Signed-off-by: Jeff Layton
---
include/linux/errseq.h | 1 +
lib/errseq.c | 33 +++--
2 files changed, 32 insertions(+), 2
ded in commit
d67fd44f697d to address performance issues when there are a lot of locks
held by tasks in other namespaces.
Will allowing this code to show these again cause a problem there?
--
Jeff Layton
ded in commit
d67fd44f697d to address performance issues when there are a lot of locks
held by tasks in other namespaces.
Will allowing this code to show these again cause a problem there?
--
Jeff Layton
> return 0;
> }
>
> Konstantin Khorenko (2):
> fs/lock: skip lock owner pid translation in case we are in init_pid_ns
> fs/lock: show locks taken by processes from another pidns
>
> fs/locks.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
These look fine to me. I'll plan to pick them up for v4.19 unless anyone
has objections.
Thanks!
--
Jeff Layton
> return 0;
> }
>
> Konstantin Khorenko (2):
> fs/lock: skip lock owner pid translation in case we are in init_pid_ns
> fs/lock: show locks taken by processes from another pidns
>
> fs/locks.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
These look fine to me. I'll plan to pick them up for v4.19 unless anyone
has objections.
Thanks!
--
Jeff Layton
From: Jeff Layton
When syncing out a block device (a'la __sync_blockdev), any error
encountered will only be recorded in the bd_inode's mapping. When the
blockdev contains a filesystem however, we'd like to also record the
error in the super_block that's stored there.
Make
From: Jeff Layton
When syncing out a block device (a'la __sync_blockdev), any error
encountered will only be recorded in the bd_inode's mapping. When the
blockdev contains a filesystem however, we'd like to also record the
error in the super_block that's stored there.
Make
From: Jeff Layton
This is a reworked (and more modest) version of the syncfs rework that I
posted recently. Given that we have a new fsinfo syscall being
introduced, we may as well use it to report writeback errors on a per
superblock basis. This allows us to provide the info that the PostgreSQL
From: Jeff Layton
This is a reworked (and more modest) version of the syncfs rework that I
posted recently. Given that we have a new fsinfo syscall being
introduced, we may as well use it to report writeback errors on a per
superblock basis. This allows us to provide the info that the PostgreSQL
From: Jeff Layton
To grab the current value of an errseq_t, mark it as seen and then
return the value with the seen bit masked off.
Signed-off-by: Jeff Layton
---
include/linux/errseq.h | 1 +
lib/errseq.c | 33 +++--
2 files changed, 32 insertions(+), 2
From: Jeff Layton
To grab the current value of an errseq_t, mark it as seen and then
return the value with the seen bit masked off.
Signed-off-by: Jeff Layton
---
include/linux/errseq.h | 1 +
lib/errseq.c | 33 +++--
2 files changed, 32 insertions(+), 2
From: Jeff Layton
Keep a per-sb errseq_t that tracks whether there have been any writeback
errors on this superblock. When an error is recorded for an inode via
mapping_set_error, record it in s_wb_err as well.
Cc: Andres Freund
Cc: Matthew Wilcox
Signed-off-by: Jeff Layton
---
include
From: Jeff Layton
Keep a per-sb errseq_t that tracks whether there have been any writeback
errors on this superblock. When an error is recorded for an inode via
mapping_set_error, record it in s_wb_err as well.
Cc: Andres Freund
Cc: Matthew Wilcox
Signed-off-by: Jeff Layton
---
include
From: Jeff Layton
Add a new "error_state" struct to fsinfo, and teach the kernel to fill
that out from sb->s_wb_info. There are two fields:
wb_error_last: the most recently recorded errno for the filesystem
wb_error_cookie: this value will change vs. the previ
From: Jeff Layton
Add a new "error_state" struct to fsinfo, and teach the kernel to fill
that out from sb->s_wb_info. There are two fields:
wb_error_last: the most recently recorded errno for the filesystem
wb_error_cookie: this value will change vs. the previ
From: Jeff Layton
Add support for error_state struct to test-fsinfo sample program.
Signed-off-by: Jeff Layton
---
samples/statx/test-fsinfo.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/samples/statx/test-fsinfo.c b/samples/statx/test-fsinfo.c
index 9d70c422da11
From: Jeff Layton
Add support for error_state struct to test-fsinfo sample program.
Signed-off-by: Jeff Layton
---
samples/statx/test-fsinfo.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/samples/statx/test-fsinfo.c b/samples/statx/test-fsinfo.c
index 9d70c422da11
and interrupt-context
kill_fasync()
fs/fcntl.c | 15 +++
include/linux/fs.h | 2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
--
Jeff Layton
and interrupt-context
kill_fasync()
fs/fcntl.c | 15 +++
include/linux/fs.h | 2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
--
Jeff Layton
On Thu, 2018-05-31 at 07:29 -0400, Jeff Layton wrote:
> From: Jeff Layton
>
> v2: don't modify sync_fs op prototype, handle errors at vfs layer
>
> The syncfs system call returns an int error code, but in general it does
> not return errors when an inode fails writeback. It wi
On Thu, 2018-05-31 at 07:29 -0400, Jeff Layton wrote:
> From: Jeff Layton
>
> v2: don't modify sync_fs op prototype, handle errors at vfs layer
>
> The syncfs system call returns an int error code, but in general it does
> not return errors when an inode fails writeback. It wi
From: Jeff Layton
Add a test for new syncfs error reporting behavior. When an inode fails
to be written back, ensure that we report an error to a subsequent call
to syncfs().
Because we don't want to grow struct file in order to support this, we
only do this if the file was opened with O_PATH
From: Jeff Layton
Add a test for new syncfs error reporting behavior. When an inode fails
to be written back, ensure that we report an error to a subsequent call
to syncfs().
Because we don't want to grow struct file in order to support this, we
only do this if the file was opened with O_PATH
From: Jeff Layton
Currently, we always call __sync_blockdev after sync_fs, though very
few filesystems actually need it these days.
Note that many older filesystems still rely on flushing out the bd_inode
cache to ensure that it's safely written to the backing store, so when
sync_fs
From: Jeff Layton
Currently, we always call __sync_blockdev after sync_fs, though very
few filesystems actually need it these days.
Note that many older filesystems still rely on flushing out the bd_inode
cache to ensure that it's safely written to the backing store, so when
sync_fs
From: Jeff Layton
When syncing out a block device (a'la __sync_blockdev), any error
encountered will only be recorded in the bd_inode's mapping. When the
blockdev contains a filesystem however, we'd like to also record the
error in the super_block that's stored there.
Make
From: Jeff Layton
When syncing out a block device (a'la __sync_blockdev), any error
encountered will only be recorded in the bd_inode's mapping. When the
blockdev contains a filesystem however, we'd like to also record the
error in the super_block that's stored there.
Make
From: Jeff Layton
The postgres developers recently mentioned that they'd like a way to
tell whether there have been any writeback errors on a given filesystem
without having to forcibly sync out all buffered writes.
Now that we have a per-sb errseq_t that tracks whether any inode
From: Jeff Layton
The postgres developers recently mentioned that they'd like a way to
tell whether there have been any writeback errors on a given filesystem
without having to forcibly sync out all buffered writes.
Now that we have a per-sb errseq_t that tracks whether any inode
From: Jeff Layton
Allow sync_filesystem and __sync_filesystem to take an errseq_t pointer
for the purposes of error reporting. For now, everything passes in NULL
and the field is ignored, but a later patch will change that.
Signed-off-by: Jeff Layton
---
drivers/staging/ncpfs/inode.c | 2
From: Jeff Layton
Allow sync_filesystem and __sync_filesystem to take an errseq_t pointer
for the purposes of error reporting. For now, everything passes in NULL
and the field is ignored, but a later patch will change that.
Signed-off-by: Jeff Layton
---
drivers/staging/ncpfs/inode.c | 2
From: Jeff Layton
Usually we suggest that applications call fsync when they want to
ensure that all data written to the file has made it to the backing
store, but that can be inefficient when there are a lot of open
files.
Calling syncfs on the filesystem can be more efficient in some
From: Jeff Layton
Usually we suggest that applications call fsync when they want to
ensure that all data written to the file has made it to the backing
store, but that can be inefficient when there are a lot of open
files.
Calling syncfs on the filesystem can be more efficient in some
From: Jeff Layton
v2: don't modify sync_fs op prototype, handle errors at vfs layer
The syncfs system call returns an int error code, but in general it does
not return errors when an inode fails writeback. It will return an error
if __sync_blockdev fails, but that's not useful on non-block
From: Jeff Layton
v2: don't modify sync_fs op prototype, handle errors at vfs layer
The syncfs system call returns an int error code, but in general it does
not return errors when an inode fails writeback. It will return an error
if __sync_blockdev fails, but that's not useful on non-block
On Tue, 2018-05-22 at 09:01 +1000, Dave Chinner wrote:
> On Fri, May 18, 2018 at 08:34:12AM -0400, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Signed-off-by: Jeff Layton <jlay...@redhat.com>
> > ---
> > fs/xfs/xfs_super.c |
On Tue, 2018-05-22 at 09:01 +1000, Dave Chinner wrote:
> On Fri, May 18, 2018 at 08:34:12AM -0400, Jeff Layton wrote:
> > From: Jeff Layton
> >
> > Signed-off-by: Jeff Layton
> > ---
> > fs/xfs/xfs_super.c | 9 -
> > 1 file changed, 8 insertion
/
> > +static inline int call_sync_fs(struct super_block *sb, int wait)
> > +{
> > + if (sb->s_op->sync_fs)
> > + return sb->s_op->sync_fs(sb, wait);
> > + return __sync_blockdev(sb->s_bdev, wait);
> > +}
>
> The proper name for
401 - 500 of 4603 matches
Mail list logo
