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: <4FA345DA4F4AE44899BD2B03EEEC2FA909236BB5@SACEXCMBX04-PRD.hq.netapp.com>
Date:	Mon, 15 Oct 2012 04:27:35 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Chen Gang <gang.chen@...anux.com>
CC:	Jeff Layton <jlayton@...hat.com>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Bug fix] nfs-client: fix nfs_inode_attrs_need_update for async
 read_done comes during truncating to smaller size

On Mon, 2012-10-15 at 10:12 +0800, Chen Gang wrote:
> Hello Trond Myklebust, Jeff Layton:
> 
> 1) Root Cause:
>    A) begin truncate to smaller, after async read finish starting.
>    B) async read done come, after truncate operation change inode size.
>    C) in nfs_inode_attrs_need_update, nfs_size_need_update return true.
>       i)   the bigger size is the original old size of client itself.
>       ii)  the smaller size is the current true size.
>       iii) nfs_inode_attrs_need_update not consider this situation.
> 
> 2) Fix nfs_size_need_update:
>    A) delete it:
>       i)   it is for performance, not necessary (not for correctness).
>       ii)  if it was necessary, it should use "!=" instead of '>'.
>       iii) it is the simplest way to fix this bug (maybe not best way).
>    B) consider this situation in it:
>       i)   it is the best way.
>       ii)  it is a little complex (need think of)
>       iii) sorry for I do not know how to fix it (at least now).
>    C) not touch it:
>       i)   correct another place (such as nfs_update_inode)
>       ii)  it is a bad idea (at least, I think it is)
>       iii) we need keep the source code as clearer as possible.
> 
> 3) Test Result:
>    A) it is one client and one server separately, under 3.6-rc5 x86_32.
>    B) use one process (fsx-linux) test (only one user mode thread).
>    C) only use read, truncate, llseek, fstat operation for one file.
> 
>    Before delete nfs_size_need_update, it causes issue.
>    After delete nfs_size_need_update, it is ok.

nfs_size_need_update is not about performance. It is a heuristic that is
entirely about ensuring correctness when faced with the fact that most
Linux filesystems are utterly incapable of reporting with modifications
that occur within < 1 second intervals because their mtime/ctime is
limited to 1 second resolutions.

Now, what are the conditions of your test setup? The above bug report is
meaningless unless it includes a description of what is being exported
by the server (including a proper listing of the contents
of /etc/exports and /proc/mounts). It should also include a description
of the NFS client mount options (see /proc/mounts on the client).

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ