[PATCH v2] integrity: track mtime in addition to i_version for assessment

2017-07-07 Thread Jeff Layton
From: Jeff Layton The IMA assessment code tries to use the i_version counter to detect when changes to a file have occurred. Many filesystems don't increment it properly (or at all) so detecting changes with that is not always reliable. That check should be gated on IS_I_VERSION, as you

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

2017-07-07 Thread Jeff Layton
option that defaults to "off" for now, and then we could plan to just drop it in a couple of years. Vendors that thought they might need it could enable it and speak up with their use case if they wanted to keep it in for future releases. Most likely though, no-one will care. -- Jeff Layton

Re: [PATCH] integrity: track ctime in addition to i_version for assessment

2017-07-06 Thread Jeff Layton
On Thu, 2017-07-06 at 17:00 -0400, Mimi Zohar wrote: > Hi Jeff, > > On Thu, 2017-07-06 at 12:23 -0400, Jeff Layton wrote: > > From: Jeff Layton > > > > The IMA assessment code tries to use the i_version counter to detect > > when changes to a file have occurred.

[PATCH] integrity: track ctime in addition to i_version for assessment

2017-07-06 Thread Jeff Layton
From: Jeff Layton The IMA assessment code tries to use the i_version counter to detect when changes to a file have occurred. Many filesystems don't increment it properly (or at all) so detecting changes with that is not always reliable. That check should really be gated on IS_I_VERSION.

[PATCH] integrity: get rid of unneeded initializations in integrity_iint_cache entries

2017-07-06 Thread Jeff Layton
From: Jeff Layton The init_once routine memsets the whole object to 0, and then explicitly sets some of the fields to 0 again. Just remove the explicit initializations. Signed-off-by: Jeff Layton --- security/integrity/iint.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/security

[GIT PULL] writeback error handling fixes (pile #2)

2017-07-06 Thread Jeff Layton
2 +- 24 files changed, 572 insertions(+), 64 deletions(-) create mode 100644 include/linux/errseq.h create mode 100644 lib/errseq.c -- Jeff Layton signature.asc Description: This is a digitally signed message part

[GIT PULL] writeback error handling fixes (pile #1)

2017-07-06 Thread Jeff Layton
On Thu, 2017-07-06 at 06:51 -0400, Jeff Layton wrote: > The following changes since commit c86daad2c25bfd4a33d48b7691afaa96d9c5ab46: > > Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2017-05-26 16:45:13 > -0700) >

writeback error handling fixes (pile #1)

2017-07-06 Thread Jeff Layton
Dave Kleikamp (1): JFS: do not ignore return code from write_one_page() Jeff Layton (3): mm: drop "wait" parameter from write_one_page() mm: clean up error handling in write_one_page fs: remove call_fsync helper function fs/exofs/dir.c| 2 +- fs

Re: [GIT PULL] file locking and writeback error handling patches for v4.13

2017-07-05 Thread Jeff Layton
On Wed, 2017-07-05 at 11:10 -0700, Linus Torvalds wrote: > On Mon, Jul 3, 2017 at 6:58 AM, Jeff Layton wrote: > > > > File locking and writeback error handling patches for v4.13 > > Yeah, I won't be pulling this. > > It's a random collection of pat

[GIT PULL] file locking and writeback error handling patches for v4.13

2017-07-03 Thread Jeff Layton
imit in compat_fcntl64 Dave Kleikamp (1): JFS: do not ignore return code from write_one_page() Jeff Layton (21): fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found mm: drop "wait" parameter from write_one_page() mm: fix mapping_set_error call i

Re: linux-next: manual merge of the kspp tree with the file-locks tree

2017-07-03 Thread Jeff Layton
that 2 > > is OK */ > > > > struct file_handle { > > __u32 handle_bytes; > > Thanks. I think this is fairly trivial conflict -- Kees is adding the __randomize_layout attribute here, and I'm just adding a field to each of these structs. The main catch is that both of these branches have a fair number of preparatory patches before the above changes occur, so pulling one into the other is not trivial. Would it be best to just send the PRs to Linus and have him fix this up in the final merge? -- Jeff Layton

Re: linux-next: manual merge of the block tree with the file-locks tree

2017-06-28 Thread Jeff Layton
_err to the end of the struct. I have some later patches that add a second 32-bit errseq_t field to struct file for tracking metadata writeback errors. That would make them adjacent to one another which at least looks a little cleaner. Cheers, -- Jeff Layton

Re: [PATCH 3/3] staging/lustre, 9p, ceph, cifs, dlm: negate remote pids for F_GETLK

2017-06-27 Thread Jeff Layton
> fl->fl_type = (op->info.ex) ? F_WRLCK : F_RDLCK; > fl->fl_flags = FL_POSIX; > - fl->fl_pid = op->info.pid; > + fl->fl_pid = -op->info.pid; > fl->fl_start = op->info.start; > fl->fl_end = op->info.end; > rv = 0; I think this is probably a reasonable thing to do, given that we also report OFD locks today with an l_pid of -1. The pid on any sort of distributed fs is pretty meaningless anyway. I think this all looks good. I'll plan to merge it for -next in a bit and do some testing with it. Thanks! -- Jeff Layton

Re: [PATCH][mm-next] mm: clean up build warning with unused variable ret2

2017-06-21 Thread Jeff Layton
t2; > + int ret = 0; > struct writeback_control wbc = { > .sync_mode = WB_SYNC_ALL, > .nr_to_write = 1, Thanks. I just squashed the same fix into the original patch this morning after seeing the mail from Stephen. Tomorrow's linux-next pull should pick up the corrected version. -- Jeff Layton

Re: [PATCH 2/2] fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks

2017-06-20 Thread Jeff Layton
On Tue, 2017-06-20 at 15:39 -0400, Benjamin Coddington wrote: > On 20 Jun 2017, at 15:32, Jeff Layton wrote: > > > On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote: > > > On 20 Jun 2017, at 13:06, Jeff Layton wrote: > > > > > > > > Now th

Re: [PATCH 2/2] fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks

2017-06-20 Thread Jeff Layton
On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote: > On 20 Jun 2017, at 13:06, Jeff Layton wrote: > > > > Now that I think about it a bit more, I don't think we really need a > > flag here. > > > > Just have the ->lock operation set the fl_pid

Re: [PATCH 2/2] fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks

2017-06-20 Thread Jeff Layton
On Tue, 2017-06-20 at 12:09 -0400, Benjamin Coddington wrote: > On 20 Jun 2017, at 10:03, Benjamin Coddington wrote: > > > On 19 Jun 2017, at 13:32, Jeff Layton wrote: > > > > > On Mon, 2017-06-19 at 09:24 -0400, Benjamin Coddington wrote: > > > > @@ -20

Re: [PATCH 2/2] fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks

2017-06-19 Thread Jeff Layton
b/include/linux/fs.h > index aa4affb38c39..179496a9719d 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -908,6 +908,7 @@ static inline struct file *get_file(struct file *f) > #define FL_UNLOCK_PENDING512 /* Lease is being broken */ > #define FL_OFDLCK1024/* lock is "owned" by struct file */ > #define FL_LAYOUT2048/* outstanding pNFS layout */ > +#define FL_PID_PRIV 4096/* F_GETLK should report fl_pid */ > > #define FL_CLOSE_POSIX (FL_POSIX | FL_CLOSE) > > @@ -984,7 +985,6 @@ struct file_lock { > unsigned char fl_type; > unsigned int fl_pid; > int fl_link_cpu;/* what cpu's list is this on? */ > - struct pid *fl_nspid; > wait_queue_head_t fl_wait; > struct file *fl_file; > loff_t fl_start; -- Jeff Layton

Re: attempting to format brd device results in OOM kills

2017-06-18 Thread Jeff Layton
On Sun, 2017-06-18 at 16:27 -0600, Jens Axboe wrote: > On 06/18/2017 04:21 PM, Jens Axboe wrote: > > On 06/18/2017 10:30 AM, Jeff Layton wrote: > > > I've run across a regression from v4.11. If I boot a v4.12-rc1 or later > > > kernel, make a large brd device and tr

Re: [PATCH 08/27] VFS: Introduce the structs and doc for a filesystem context [ver #5]

2017-06-17 Thread Jeff Layton
> > David That's a pity... I tend to like little prefixes on fields too. Trying to find all occurrences of a symbol called "flags" in cscope is a losing exercise. Do you have a reference to the discussion so I can understand the rationale there? Thanks, -- Jeff Layton

[PATCH] fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found

2017-06-14 Thread Jeff Layton
he case where userland passed in an argument of 0. For anything else, we want to return ESRCH if it doesn't refer to a valid pid. The relevant POSIX spec page is here: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html Cc: Jiri Slaby Cc: zhong jiang Signed-off-by: Je

Re: [PATCH v3 2/2] fs/fcntl: f_setown, avoid undefined behaviour

2017-06-13 Thread Jeff Layton
rocess group identifier. > > [v2] returns an error, v1 used to fail silently > [v3] implement proper check for the bad value INT_MIN > > Signed-off-by: Jiri Slaby > Cc: Jeff Layton > Cc: "J. Bruce Fields" > Cc: Alexander Viro > Cc: linux-fsde...@vger.kernel.org

Re: [PATCH v2 2/2] fs/fcntl: f_setown, avoid undefined behaviour

2017-06-13 Thread Jeff Layton
On Tue, 2017-06-13 at 13:10 +0200, Jiri Slaby wrote: > On 06/13/2017, 12:11 PM, Jeff Layton wrote: > > On Tue, 2017-06-13 at 11:22 +0200, Jiri Slaby wrote: > > > fcntl(0, F_SETOWN, 0x8000) triggers: > > > UBSAN: Undefined behaviour in fs/fcntl.c:118:7 > > &g

Re: [PATCH v2 2/2] fs/fcntl: f_setown, avoid undefined behaviour

2017-06-13 Thread Jeff Layton
rocess group identifier. > > [v2] returns an error, v1 used to fail silently > > Signed-off-by: Jiri Slaby > Cc: Jeff Layton > Cc: "J. Bruce Fields" > Cc: Alexander Viro > Cc: linux-fsde...@vger.kernel.org > --- > fs/fcntl.c | 4 > 1 file changed

Re: [PATCH v2 1/2] fs/fcntl: f_setown, allow returning error

2017-06-13 Thread Jeff Layton
On Tue, 2017-06-13 at 11:22 +0200, Jiri Slaby wrote: > Allow f_setown to return an error value. We will fail in the next patch > with EINVAL for bad input to f_setown, so tile the path for the later > patch. > > Signed-off-by: Jiri Slaby > Cc: Jeff Layton > Cc: &q

Re: [PATCH] VFS: Differentiate mount flags (MS_*) from internal superblock flags

2017-06-09 Thread Jeff Layton
unt() API flags from the internal implementation. That allows us to make changes to the internal flag representation in the future without affecting the external API. Acked-by: Jeff Layton

Re: [xfstests PATCH v3 5/5] btrfs: allow it to use $SCRATCH_LOGDEV

2017-06-08 Thread Jeff Layton
On Tue, 2017-06-06 at 17:19 +0800, Eryu Guan wrote: > On Wed, May 31, 2017 at 09:08:20AM -0400, Jeff Layton wrote: > > With btrfs, we can't really put the log on a separate device. What we > > can do however is mirror the metadata across two devices and make the > > data

Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks

2017-06-07 Thread Jeff Layton
n >* the lock if we are called from locks_show, or if we are > diff --git a/include/linux/fs.h b/include/linux/fs.h > index b013fac515f7..179496a9719d 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -908,6 +908,7 @@ static inline struct file *get_file(struct file *f) > #define FL_UNLOCK_PENDING512 /* Lease is being broken */ > #define FL_OFDLCK1024/* lock is "owned" by struct file */ > #define FL_LAYOUT2048/* outstanding pNFS layout */ > +#define FL_PID_PRIV 4096/* F_GETLK should report fl_pid */ > > #define FL_CLOSE_POSIX (FL_POSIX | FL_CLOSE) > -- Jeff Layton

Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks

2017-06-07 Thread Jeff Layton
a/include/linux/fs.h b/include/linux/fs.h > index b013fac515f7..179496a9719d 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -908,6 +908,7 @@ static inline struct file *get_file(struct file *f) > #define FL_UNLOCK_PENDING512 /* Lease is being broken */ > #define FL_OFDLCK1024/* lock is "owned" by struct file */ > #define FL_LAYOUT2048/* outstanding pNFS layout */ > +#define FL_PID_PRIV 4096/* F_GETLK should report fl_pid */ > > #define FL_CLOSE_POSIX (FL_POSIX | FL_CLOSE) > -- Jeff Layton

Re: [PATCH 2/3] fs/locks: Remove fl_nspid

2017-06-06 Thread Jeff Layton
On Tue, 2017-06-06 at 14:57 -0400, Benjamin Coddington wrote: > On 6 Jun 2017, at 14:25, Jeff Layton wrote: > > > On Tue, 2017-06-06 at 14:00 -0400, Jeff Layton wrote: > > > On Tue, 2017-06-06 at 13:19 -0400, Benjamin Coddington wrote: > > > > Since commit c69899

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

2017-06-06 Thread Jeff Layton
On Tue, 2017-06-06 at 10:17 -0700, Darrick J. Wong wrote: > On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > > On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > > > > On Wed, May 31,

Re: [PATCH 2/3] fs/locks: Remove fl_nspid

2017-06-06 Thread Jeff Layton
On Tue, 2017-06-06 at 14:00 -0400, Jeff Layton wrote: > On Tue, 2017-06-06 at 13:19 -0400, Benjamin Coddington wrote: > > Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be > > atomic with the stateid update", NFSv4 has been inserting locks in rpciod

Re: [PATCH 2/3] fs/locks: Remove fl_nspid

2017-06-06 Thread Jeff Layton
p;& !pid_nr_ns(fl->fl_nspid, proc_pidns)) > + if (locks_translate_pid(fl->fl_pid, proc_pidns) == 0) > return 0; > > lock_get_status(f, fl, iter->li_pos, ""); > diff --git a/include/linux/fs.h b/include/linux/fs.h > index aa4affb38c39..b013fac515f7 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -984,7 +984,6 @@ struct file_lock { > unsigned char fl_type; > unsigned int fl_pid; > int fl_link_cpu;/* what cpu's list is this on? */ > - struct pid *fl_nspid; > wait_queue_head_t fl_wait; > struct file *fl_file; > loff_t fl_start; -- Jeff Layton

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

2017-06-06 Thread Jeff Layton
On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote: > > I'm working on a set of kernel patches to change how writeback errors > > are handled and reported in the kernel. Instead of reporting a > > writeba

Re: [PATCH v5 08/17] dax: set errors in mapping when writeback fails

2017-06-05 Thread Jeff Layton
On Mon, 2017-06-05 at 19:01 -0600, Ross Zwisler wrote: > On Wed, May 31, 2017 at 08:45:31AM -0400, Jeff Layton wrote: > > Jan's description for this patch is much better than mine, so I'm > > quoting it verbatim here: > > > > -8<---

Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

2017-06-02 Thread Jeff Layton
> > > "Affect" in what sense? > > Operate on at all - view/read/write/search etc. > > At a high level I'm glad you're looking at the "service fd" model instead of > upcalls - I do think it'll get us to a better place. The main thing I'm > getting > at first though is making sure we're not introducing new security issues, and > that the > new proposed API makes sense for some of the important userspace use cases. > I think I'd rather see a new capability flag for this (CAP_REGISTER_UPCALL_HANDLER or somesuch). Then you could assign that to containers that you trust to register a sane handler. CAP_SYS_ADMIN could include that capability, of course. -- Jeff Layton

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

2017-06-02 Thread Jeff Layton
On Thu, 2017-06-01 at 23:25 -0600, Ross Zwisler wrote: > On Wed, May 31, 2017 at 08:45:23AM -0400, Jeff Layton wrote: > > v5: don't retrofit old API over the new infrastructure > > add fstype flag to indicate how wb errors are tracked within that fs > > add more f

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

2017-05-31 Thread Jeff Layton
On Wed, 2017-05-31 at 14:37 -0700, Andrew Morton wrote: > On Wed, 31 May 2017 17:31:49 -0400 Jeff Layton wrote: > > > On Wed, 2017-05-31 at 13:27 -0700, Andrew Morton wrote: > > > On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote: > > > > > > >

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

2017-05-31 Thread Jeff Layton
On Wed, 2017-05-31 at 13:27 -0700, Andrew Morton wrote: > On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote: > > > This is v5 of the patchset to improve how we're tracking and reporting > > errors that occur during pagecache writeback. > > I'm curious to

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

2017-05-31 Thread Jeff Layton
On Wed, 2017-05-31 at 11:59 -0700, Eduardo Valentin wrote: > Hello, > > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote: > > I'm working on a set of kernel patches to change how writeback errors > > are handled and reported in the kernel. Instead of reportin

[xfstests PATCH v3 2/5] ext4: allow ext4 to use $SCRATCH_LOGDEV

2017-05-31 Thread Jeff Layton
o the same thing when _scratch_mkfs is called. Signed-off-by: Jeff Layton Reviewed-by: Darrick J. Wong --- common/rc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/rc b/common/rc index 743df427c047..391d36f373cd 100644 --- a/common/rc +++ b/common/rc @@ -676,6 +

[xfstests PATCH v3 3/5] generic: test writeback error handling on dmerror devices

2017-05-31 Thread Jeff Layton
Ensure that we get an error back on all fds when a block device is open by multiple writers and writeback fails. Signed-off-by: Jeff Layton --- tests/generic/998 | 64 +++ tests/generic/998.out | 2 ++ tests/generic/group | 1 + 3 files

[xfstests PATCH v3 1/5] generic: add a writeback error handling test

2017-05-31 Thread Jeff Layton
s all it can do, but we can fill it out with other commands as necessary. Signed-off-by: Jeff Layton --- common/dmerror | 13 ++-- doc/auxiliary-programs.txt | 8 +++ src/Makefile | 2 +- src/fsync-err.c| 161 + te

[xfstests PATCH v3 0/5] add a test for reporting writeback errors across all fds on fsync

2017-05-31 Thread Jeff Layton
descriptions when there is an error on fsync, not just the first one to race in. Note that this set contains a patch to emulate $SCRATCH_LOGDEV on btrfs, but the kernel patches for that are not quite ready yet. The test did pass on btrfs in an earlier incarnation of the set, however. Jeff Layton (5

[xfstests PATCH v3 5/5] btrfs: allow it to use $SCRATCH_LOGDEV

2017-05-31 Thread Jeff Layton
t the current incarnation of btrfs has a fixed 64k stripe width. If that ever changes or becomes settable, we may need to adjust the amount of data that the test program writes. Signed-off-by: Jeff Layton --- common/rc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/rc b/common/rc

[xfstests PATCH v3 4/5] ext3: allow it to put journal on a separate device when doing scratch_mkfs

2017-05-31 Thread Jeff Layton
Signed-off-by: Jeff Layton --- common/rc | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/common/rc b/common/rc index 391d36f373cd..83765aacfb06 100644 --- a/common/rc +++ b/common/rc @@ -832,7 +832,16 @@ _scratch_mkfs() mkfs_cmd="$MKFS_BTRFS

[PATCH v5 02/17] fs: new infrastructure for writeback error handling and reporting

2017-05-31 Thread Jeff Layton
will change the existing code to use this new infrastructure. Signed-off-by: Jeff Layton Reviewed-by: Jan Kara --- drivers/dax/device.c | 1 + fs/block_dev.c | 1 + fs/file_table.c | 1 + fs/open.c| 3 +++ include/linux/fs.h | 53 ++

[PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

2017-05-31 Thread Jeff Layton
ut any bugs that might be lurking here. I also have a couple of xfstests for this as well that I'll re-post soon. Jeff Layton (17): lib: add errseq_t type and infrastructure for handling it fs: new infrastructure for writeback error handling and reporting mm: tracepoints for writeback

[PATCH v5 01/17] lib: add errseq_t type and infrastructure for handling it

2017-05-31 Thread Jeff Layton
nce it was last bumped. Later patches will build on this infrastructure to change how writeback errors are tracked in the kernel. Signed-off-by: Jeff Layton Reviewed-by: NeilBrown --- include/linux/errseq.h | 19 + lib/Makefile | 2 +- lib/errseq.c

[PATCH v5 04/17] fs: add a new fstype flag to indicate how writeback errors are tracked

2017-05-31 Thread Jeff Layton
errseq_t based error tracking. Signed-off-by: Jeff Layton --- include/linux/fs.h | 1 + include/linux/pagemap.h | 32 ++-- mm/filemap.c| 7 +++ 3 files changed, 34 insertions(+), 6 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h i

[PATCH v5 05/17] Documentation: flesh out the section in vfs.txt on storing and reporting writeback errors

2017-05-31 Thread Jeff Layton
Signed-off-by: Jeff Layton --- Documentation/filesystems/vfs.txt | 50 --- 1 file changed, 47 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index f42b90687d40..c3efdd833a3d 100644 --- a/Doc

[PATCH v5 08/17] dax: set errors in mapping when writeback fails

2017-05-31 Thread Jeff Layton
currently cleared in the older code when writeback initiation fails, only when we discover an error after waiting on writeback to complete, so we only want to do this with errseq_t based error handling to prevent seeing duplicate errors on fsync. Signed-off-by: Jeff Layton Reviewed-by:

[PATCH v5 03/17] mm: tracepoints for writeback error events

2017-05-31 Thread Jeff Layton
To enable that, make __errseq_set return the value that it was set to we exit the loop. Take heed that that value is not suitable as a later "since" value, as it will not have been marked seen. Signed-off-by: Jeff Layton --- include/linux/errseq.h | 2 +- include/

[PATCH v5 10/17] block: add sync_blockdev_since and sync_filesystem_since

2017-05-31 Thread Jeff Layton
New variants of sync_filesystem and sync_blockdev. Signed-off-by: Jeff Layton --- fs/block_dev.c | 15 +++ fs/internal.h | 8 fs/sync.c | 45 + include/linux/fs.h | 13 - 4 files changed, 80

[PATCH v5 06/17] fs: adapt sync_file_range to new reporting infrastructure

2017-05-31 Thread Jeff Layton
Since it returns errors in a way similar to fsync, have it use the same method for returning previously-reported writeback errors. Signed-off-by: Jeff Layton --- fs/sync.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/fs/sync.c b/fs/sync.c index

[PATCH v5 14/17] ext4: convert to errseq_t based error tracking

2017-05-31 Thread Jeff Layton
racked on a per-device level, this does mean that we'll end up reporting an error on all open file descriptors when there is a metadata writeback failure. Signed-off-by: Jeff Layton --- fs/ext4/dir.c | 8 ++-- fs/ext4/ext4.h| 8 fs/ext4/extents.c | 24 ++-

[PATCH v5 15/17] fs: add a write_one_page_since

2017-05-31 Thread Jeff Layton
Allow filesystems to pass in an errseq_t for a since value. Signed-off-by: Jeff Layton --- include/linux/mm.h | 2 ++ mm/page-writeback.c | 53 + 2 files changed, 43 insertions(+), 12 deletions(-) diff --git a/include/linux/mm.h b/include

[PATCH v5 12/17] fs: allow __generic_file_fsync to support both flavors of error reporting

2017-05-31 Thread Jeff Layton
For now, we add a FS_WB_ERRSEQ check to know how to handle it. Signed-off-by: Jeff Layton --- fs/libfs.c | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/fs/libfs.c b/fs/libfs.c index 1dec90819366..2ae58a252718 100644 --- a/fs/libfs.c +++ b/fs

[PATCH v5 13/17] jbd2: conditionally handle errors using errseq_t based on FS_WB_ERRSEQ flag

2017-05-31 Thread Jeff Layton
ince value to sync_blockdev_since. Signed-off-by: Jeff Layton --- fs/jbd2/commit.c | 29 +++-- fs/jbd2/recovery.c| 5 +++-- fs/jbd2/transaction.c | 1 + include/linux/jbd2.h | 3 +++ 4 files changed, 26 insertions(+), 12 deletions(-) diff --git a/fs/jbd2/commit.c b/fs/

[PATCH v5 11/17] fs: add f_md_wb_err field to struct file for tracking metadata errors

2017-05-31 Thread Jeff Layton
Some filesystems (particularly local ones) keep a different mapping for metadata writeback. Add a second errseq_t to struct file for tracking metadata writeback errors. Also add a new function for checking a mapping of the caller's choosing vs. the f_md_wb_err value. Signed-off-by: Jeff L

[PATCH v5 16/17] ext2: convert to errseq_t based writeback error tracking

2017-05-31 Thread Jeff Layton
s the error on the device inode on every call. Signed-off-by: Jeff Layton --- fs/ext2/dir.c | 8 fs/ext2/file.c | 29 +++-- fs/ext2/super.c | 2 +- 3 files changed, 32 insertions(+), 7 deletions(-) diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c index e270969

[PATCH v5 07/17] mm: add filemap_fdatawait_range_since and filemap_write_and_wait_range_since

2017-05-31 Thread Jeff Layton
Add new filemap_*wait* variants that take a "since" value and return an error if one occurred since that sample point. Signed-off-by: Jeff Layton --- include/linux/fs.h | 9 mm/filemap.c | 67 ++ 2 files changed, 76

[PATCH v5 17/17] fs: convert ext2 to use write_one_page_since

2017-05-31 Thread Jeff Layton
Sample the wb_err before changing the directory, so that we can catch errors that occur since that point. Signed-off-by: Jeff Layton --- fs/ext2/dir.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c index 6e476c9929f8

[PATCH v5 09/17] block: convert to errseq_t based writeback error tracking

2017-05-31 Thread Jeff Layton
Fairly straightforward conversion. In fsync, just use the file->f_wb_err value as a "since" value. At the end, call filemap_report_wb_err to advance the cursor in it. Signed-off-by: Jeff Layton --- fs/block_dev.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-)

Re: linux-next: build warning after merge of the akpm-current tree

2017-05-26 Thread Jeff Layton
These call sites were updated for the droppping of the argument, but > not for the addition of __must_check :-( > (cc'ing Dave...) Yeah, that's a known issue. When Willy reviewed the patch originally he asked me to add a __must_check there so that JFS would pick up some warnings for this. JFS really ought to check the return code there and do something sane with it. Dave? -- Jeff Layton

[PATCH] buffer: set errors in mapping at the time that the error occurs

2017-05-25 Thread Jeff Layton
that it's first detected. Signed-off-by: Jeff Layton Reviewed-by: Jan Kara --- fs/buffer.c | 20 +--- fs/gfs2/lops.c | 2 +- include/linux/buffer_head.h | 1 + 3 files changed, 15 insertions(+), 8 deletions(-) diff --git a/fs/buffer.c b/fs/buff

Re: [RFC][PATCH 0/9] Make containers kernel objects

2017-05-23 Thread Jeff Layton
aemons." But, that ignores the fact that handling long-running daemons for infrequently used upcalls is actually quite painful to manage in practice. -- Jeff Layton

Re: [RFC][PATCH 0/9] Make containers kernel objects

2017-05-23 Thread Jeff Layton
On Tue, 2017-05-23 at 07:54 -0500, Eric W. Biederman wrote: > Jeff Layton writes: > > > On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote: > > > David Howells writes: > > > > > > > Here are a set of patches to define a container object for

Re: [RFC][PATCH 0/9] Make containers kernel objects

2017-05-22 Thread Jeff Layton
> A huge advantage of my alternative (other than not being a bit-rot > magnet) is that it should drop into existing container infrastructure > without problems. The rule for container implementors is simple to use > security key infrastructure you need to have created a pid namespace in > your user namespace. > > Eric -- Jeff Layton

Re: [RFC][PATCH 0/9] Make containers kernel objects

2017-05-22 Thread Jeff Layton
On Mon, 2017-05-22 at 12:21 -0700, James Bottomley wrote: > On Mon, 2017-05-22 at 14:34 -0400, Jeff Layton wrote: > > On Mon, 2017-05-22 at 09:53 -0700, James Bottomley wrote: > > > [Added missing cc to containers list] > > > On Mon, 2017-05-22 at 17:22 +0100, David Howe

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

2017-05-22 Thread Jeff Layton
On Mon, 2017-05-22 at 19:53 +0200, Jan Kara wrote: > On Mon 22-05-17 09:53:21, Jeff Layton wrote: > > On Mon, 2017-05-22 at 15:38 +0200, Jan Kara wrote: > > > On Fri 19-05-17 15:20:52, Jeff Layton wrote: > > > > On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote: >

Re: [RFC][PATCH 0/9] Make containers kernel objects

2017-05-22 Thread Jeff Layton
espace and the upcall being configured by the mount namespace. > > All mount namespaces have an owning user namespace, so the data > relations are already there in the kernel, is the problem simply > finding them? > > > These patches are built on top of the mount context patchset so that > > namespaces can be properly propagated over submounts/automounts. > > I'll stop here ... you get the idea that I think this is imposing a set > of restrictions that will come back to bite us later. If this is just > for the sake of figuring out how to get keyring upcalls to work, then > I'm sure we can come up with something. > -- Jeff Layton

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

2017-05-22 Thread Jeff Layton
On Mon, 2017-05-22 at 15:38 +0200, Jan Kara wrote: > On Fri 19-05-17 15:20:52, Jeff Layton wrote: > > On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote: > > > On Tue 09-05-17 11:49:18, Jeff Layton wrote: > > > > Now that we have a better way to store and report er

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

2017-05-19 Thread Jeff Layton
On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:18, Jeff Layton wrote: > > Now that we have a better way to store and report errors that occur > > during writeback, we need to convert the existing codebase to use it. We > > could just adapt all of th

Re: linux-next: build failure after merge of the file-locks tree

2017-05-17 Thread Jeff Layton
On Wed, 2017-05-17 at 11:48 +1000, Stephen Rothwell wrote: > Hi Jeff, > > On Tue, 16 May 2017 21:10:03 -0400 Jeff Layton > wrote: > > > > I think this patch will probably fix it, but I don't have a 32-bit host > > set up to build on just now. I'll go

Re: linux-next: build failure after merge of the file-locks tree

2017-05-16 Thread Jeff Layton
next fetch). --8<-- [PATCH] SQUASH: define argp properly in 32-bit fcntl64 syscall handler ...and use the right file pointer. Signed-off-by: Jeff Layton --- fs/fcntl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/fcntl.c b/fs/fcntl.

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

2017-05-15 Thread Jeff Layton
On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:18, Jeff Layton wrote: > > Now that we have a better way to store and report errors that occur > > during writeback, we need to convert the existing codebase to use it. We > > could just adapt all of th

Re: [PATCH 21/36] fs: locks: Fix some troubles at kernel-doc comments

2017-05-12 Thread Jeff Layton
t; + * - %LOCK_EX -- an exclusive lock. > + * - %LOCK_UN -- remove an existing lock. > + * - %LOCK_MAND -- a 'mandatory' flock. > + * This exists to emulate Windows Share Modes. > * > * %LOCK_MAND can be combined with %LOCK_READ or %LOCK_WRITE to allow other > * processes read and write access respectively. LGTM. Do you need me or Bruce to pick this one up? Reviewed-by: Jeff Layton

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

2017-05-12 Thread Jeff Layton
); > *p++ = 0; > } else if (IS_I_VERSION(inode)) { > - p = xdr_encode_hyper(p, inode->i_version); > + p = xdr_encode_hyper(p, nfsd4_change_attribute(inode)); > } else { > *p++ = cpu_to_be32(stat->ctime.tv_sec); > *p++ = cpu_to_be32(stat->ctime.tv_nsec); Sorry I've been MIA on this discussion. I've had a very busy spring... This looks reasonable to me (modulo Jan's comment about casting tv_sec to u64). To be clear, I think this is mostly orthogonal to the changes that I was originally proposing, right? I think we can still benefit from only bumping and storing i_version values after they've been queried. -- Jeff Layton

Re: [PATCH 07/14] Implement fsopen() to prepare for a mount

2017-05-11 Thread Jeff Layton
like the text based configuration better. It also has another advantage: It's easy to strace the program and see what it's doing. With an opaque blob, we'd need to teach strace how to format the thing to be able to view it. -- Jeff Layton

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

2017-05-10 Thread Jeff Layton
On Wed, 2017-05-10 at 07:18 -0700, Matthew Wilcox wrote: > On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote: > > +++ b/lib/errseq.c > > @@ -0,0 +1,199 @@ > > +#include > > +#include > > +#include > > +#include > > + > > +/* >

Re: [PATCH 3/9] VFS: Introduce a mount context

2017-05-10 Thread Jeff Layton
On Wed, 2017-05-10 at 15:30 +0200, Miklos Szeredi wrote: > On Wed, May 10, 2017 at 3:20 PM, Jeff Layton wrote: > > On Wed, 2017-05-10 at 09:05 +0100, David Howells wrote: > > > Miklos Szeredi wrote: > > > > > > > Possible rule of thumb: u

Re: [PATCH 3/9] VFS: Introduce a mount context

2017-05-10 Thread Jeff Layton
On Wed, 2017-05-10 at 14:31 +0100, David Howells wrote: > Jeff Layton wrote: > > > One idea might be to always kfree it on syscall entry > > You can't do that otherwise there's no way to retrieve the strings. > > True...you'd have to exempt the sys

Re: [PATCH 3/9] VFS: Introduce a mount context

2017-05-10 Thread Jeff Layton
might mitigate the problem assuming that not everything is erroring out. Then you could always do some trivial syscall to clear it manually. There's also the problem of how these should be formatted. Is English ok everywhere? Do we need a facility to allow translating these things? -- Jeff Layton

Re: [PATCH v4 14/27] fs: new infrastructure for writeback error handling and reporting

2017-05-10 Thread Jeff Layton
On Wed, 2017-05-10 at 13:48 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:17, Jeff Layton wrote: > > Most filesystems currently use mapping_set_error and > > filemap_check_errors for setting and reporting/clearing writeback errors > > at the mapping level. filemap_check

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

2017-05-10 Thread Jeff Layton
On Wed, 2017-05-10 at 13:34 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:16, Jeff Layton wrote: > > An errseq_t is a way of recording errors in one place, and allowing any > > number of "subscribers" to tell whether an error has been set again > > since a previous

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

2017-05-10 Thread Jeff Layton
On Wed, 2017-05-10 at 08:03 +1000, NeilBrown wrote: > On Tue, May 09 2017, Jeff Layton wrote: > > > An errseq_t is a way of recording errors in one place, and allowing any > > number of "subscribers" to tell whether an error has been set again > > since a previo

Re: [PATCH 3/9] VFS: Introduce a mount context

2017-05-09 Thread Jeff Layton
ou: Should the MNT_* flags be passed to fsmount(), perhaps in > > MS_* form? > > MS_* flags are a mess. I don't think they should be used for any new > functionality. MNT_* flags are much better, but there are some > internal flags there as well. > > I think the struct file model is better, where we have the external > O_* flags and the internal FMODE_* flags. > > Thanks, > Miklos > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jeff Layton

Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

2017-05-09 Thread Jeff Layton
t; What is it you're trying to do? Just read back the state of the new mount? > > ...read back the state of the new mount, because for example mount > options can be modified by FS driver. It would be also nice to have > API to get state of arbitrary mount without parsing mountinfo (the > file is huge on some systems). > -- Jeff Layton

Re: [PATCH v4 25/27] Documentation: flesh out the section in vfs.txt on storing and reporting writeback errors

2017-05-09 Thread Jeff Layton
On Tue, 2017-05-09 at 11:49 -0400, Jeff Layton wrote: > I waxed a little loquacious here, but I figured that more detail was > better, and writeback error handling is so hard to get right. > > Cc: Jan Kara > Signed-off-by: Jeff Layton > --- > Documentation/fil

[xfstests PATCH v2 1/3] generic: add a writeback error handling test

2017-05-09 Thread Jeff Layton
s all it can do, but we can fill it out with other commands as necessary. Signed-off-by: Jeff Layton --- common/dmerror| 13 +++-- src/Makefile | 2 +- src/fsync-err.c | 138 ++ tests/generic/999 | 75 +++

[xfstests PATCH v2 2/3] ext4: allow ext4 to use $SCRATCH_LOGDEV

2017-05-09 Thread Jeff Layton
o the same thing when _scratch_mkfs is called. Signed-off-by: Jeff Layton --- common/rc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/rc b/common/rc index 257b1903359d..8b815d9c8c33 100644 --- a/common/rc +++ b/common/rc @@ -675,6 +675,9 @@ _scratch_mkfs_ext4() loca

[xfstests PATCH v2 3/3] btrfs: allow it to use $SCRATCH_LOGDEV

2017-05-09 Thread Jeff Layton
With btrfs, we can't really put the log on a separate device. What we can do however is mirror the metadata across two devices and put the data on a single device. When we turn on dmerror then the metadata can fall back to using the other mirror while the data errors out. Signed-off-by:

[xfstests PATCH v2 0/3] xfstest for updated writeback error handling

2017-05-09 Thread Jeff Layton
patch series in place, ext4 and xfs now pass. btrfs still clears the error after the first fsync, so it seems like it still needs a bit of work. Jeff Layton (3): generic: add a writeback error handling test ext4: allow ext4 to use $SCRATCH_LOGDEV btrfs: allow it to use $SCRATCH_LOGDEV

[PATCH v4 02/27] mm: drop "wait" parameter from write_one_page

2017-05-09 Thread Jeff Layton
an error here in some fashion. Signed-off-by: Jeff Layton Reviewed-by: Ross Zwisler Reviewed-by: Jan Kara Reviewed-by: Matthew Wilcox Reviewed-by: Christoph Hellwig --- fs/exofs/dir.c| 2 +- fs/ext2/dir.c | 2 +- fs/jfs/jfs_metapage.c | 4 ++-- fs/minix/dir.c| 2

[PATCH v4 00/27] fs: introduce new writeback error reporting and convert existing API as a wrapper around it

2017-05-09 Thread Jeff Layton
any subsystem maintainers want to pick those up, then please do. After that, I'd like to get the larger changes into linux-next with an aim for merge in v4.13 or v4.14 (depending on how testing goes). Feedback is of course welcome. Jeff Layton (27): fs: remove unneeded forward definition of mm_s

[PATCH v4 03/27] mm: fix mapping_set_error call in me_pagecache_dirty

2017-05-09 Thread Jeff Layton
The error code should be negative. Since this ends up in the default case anyway, this is harmless, but it's less confusing to negate it. Also, later patches will require a negative error code here. Signed-off-by: Jeff Layton Reviewed-by: Ross Zwisler Reviewed-by: Jan Kara Reviewed-by: Ma

[PATCH v4 07/27] orangefs: don't call filemap_write_and_wait from fsync

2017-05-09 Thread Jeff Layton
Orangefs doesn't do buffered writes yet, so there's no point in initiating and waiting for writeback. Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig Acked-by: Mike Marshall --- fs/orangefs/file.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/f

[PATCH v4 09/27] nilfs2: set the mapping error when calling SetPageError on writeback

2017-05-09 Thread Jeff Layton
or in the address space. Ensure that this is set in nilfs2. Acked-by: Ryusuke Konishi Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig --- fs/nilfs2/segment.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index febed1217b3f..612d4b4

[PATCH v4 06/27] fs: check for writeback errors after syncing out buffers in generic_file_fsync

2017-05-09 Thread Jeff Layton
errors properly as well. With that, we don't need to twiddle it in ext2. Suggested-by: Jan Kara Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara --- fs/ext2/file.c | 2 +- fs/libfs.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git

<    3   4   5   6   7   8   9   10   11   12   >