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] [day] [month] [year] [list]
Message-Id: <1186780802.6642.78.camel@heimdal.trondhjem.org>
Date:	Fri, 10 Aug 2007 17:20:02 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Vladimir Volovich <vvv@....ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: nfs - duplicate directory entries

On Sat, 2007-08-11 at 01:05 +0400, Vladimir Volovich wrote:
> "TM" == Trond Myklebust writes:
> 
>  >> i.e. the current directory contains sub-directory 112920 twice,
>  >> sub-directory 112921 twice, etc. - and the inode numbers are the
>  >> same.
> 
>  TM> That can happen if the NFS server doesn't send unique cookies.
> 
> i have 2 questions:
> 
> 1) how to debug this, to confirm that this is caused by NFS server not
>    sending unique cookies? (to try to report to the "vendor" of the
>    NFS server)

You would have to use something like 'wireshark' or 'ethereal' to look
at the actual cookies returned by the server in reply to client READDIR
requests.

> 2) does it make sence to try to gracefully work-around this problem on
>    the linux side? or would it significantly complicate things?

Assuming that it is indeed the non-unique cookie problem:

Firstly, it is my policy never to fix NFS server bugs inside the NFS
client.

Secondly, it is in any case impossible to work around this sort of thing
reliably. The cookie is used by the client in the case where you have a
large directory that requires several READDIR rpc calls. It acts in much
the same way telldir()/seekdir() does: the server supplies the cookie in
a previous READDIR call, then upon the next call to READDIR, the client
uses the cookie to tells the server to first seekdir() to the location
that was last read, and then to resume from there.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ