lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1789b0d7-edc1-8c66-602b-2ca66de7a2be@huawei.com>
Date:   Sun, 6 Mar 2022 16:50:13 +0800
From:   "chenxiaosong (A)" <chenxiaosong2@...wei.com>
To:     Trond Myklebust <trondmy@...merspace.com>,
        "anna@...nel.org" <anna@...nel.org>,
        "smayhew@...hat.com" <smayhew@...hat.com>
CC:     "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "liuyongqiang13@...wei.com" <liuyongqiang13@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "yi.zhang@...wei.com" <yi.zhang@...wei.com>,
        "zhangxiaoxu5@...wei.com" <zhangxiaoxu5@...wei.com>
Subject: Re: [PATCH -next 2/2] nfs: nfs_file_write() check writeback errors
 correctly

filemap_sample_wb_err() -> errseq_sample() initialise errseq_t variable 
`since`, the caller of this function will checks for an error using 
filemap_check_wb_err(since) -> errseq_check().

filemap_sample_wb_err's purpose is just sampling consumed (seen) 
writeback error to initialise errseq_t variable. I understand that 
filemap_sample_wb_err()/filemap_check_wb_err() cannot detect the new 
error between filemap_sample_wb_err() and filemap_check_wb_err().

It would be better using file->f_mapping->wb_err instead of 
filemap_sample_wb_err() in nfs_file_write() to sample wb_err at that 
time point.

In do_dentry_open(), we just sample consumed(seen) writeback error. It 
is necessary to consume the writeback error before close() over.

There is some cases that writeback error have not been consumed(seen) 
after close() file over, I think it is unexpected behavior, is this a 
bug? It is worth noting that fsync() will not be called after close() in 
nfs.

在 2022/3/6 1:12, Trond Myklebust 写道:
> Hmm... Why isn't this considered a bug with filemap_sample_wb_err()? If
> what you say is true, then do_dentry_open() could be picking up
> existing errors from the filesystem and from the inode and propagating
> them to random processes.
> 
> It basically means everyone who cares about correctness of the error
> return values needs to do a fsync() immediately after open() in order
> to sync up the value in file->f_wb_err.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ