Thread (49 messages) 49 messages, 6 authors, 2017-05-19

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

From: Jan Kara <jack@suse.cz>
Date: 2017-05-10 13:46:36
Also in: linux-btrfs, linux-cifs, linux-ext4, linux-f2fs-devel, linux-fsdevel, linux-mm, linux-nfs, linux-xfs, lkml

On Wed 10-05-17 08:19:50, Jeff Layton wrote:
On Wed, 2017-05-10 at 13:48 +0200, Jan Kara wrote:
quoted
On Tue 09-05-17 11:49:17, Jeff Layton wrote:
quoted
diff --git a/fs/file_table.c b/fs/file_table.c
index 954d510b765a..d6138b6411ff 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -168,6 +168,7 @@ struct file *alloc_file(const struct path *path, fmode_t mode,
 	file->f_path = *path;
 	file->f_inode = path->dentry->d_inode;
 	file->f_mapping = path->dentry->d_inode->i_mapping;
+	file->f_wb_err = filemap_sample_wb_error(file->f_mapping);
Why do you sample here when you also sample in do_dentry_open()? I didn't
find any alloc_file() callers that would possibly care about writeback
errors... 

								Honza
I basically used the setting of f_mapping as a guideline as to where to
sample it for initialization. My thinking was that if f_mapping ever
ended up different then you'd probably also want f_wb_err to be
resampled anyway.
OK, makes sense.
I can drop this hunk if you think we don't need it.
I don't really care. I was just wondering whether I'm missing something...

								Honza

-- 
Jan Kara [off-list ref]
SUSE Labs, CR
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help