linux-kernel - Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20

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: <20080908190212.GF28123@merfinllc.com>
Date:	Mon, 8 Sep 2008 12:02:12 -0700
From:	Aaron Straus <aaron@...finllc.com>
To:	Chuck Lever <chuck.lever@...cle.com>
Cc:	Neil Brown <neilb@...e.de>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	LKML Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20

Hi,

On Sep 05 03:56 PM, Chuck Lever wrote:
> Comparing a wire trace with strace output, starting with the writing  
> client, might also be illuminating.  We prefer wireshark as it uses  
> good default trace settings, parses the wire bytes and displays them  
> coherently, and allows you to sort the frames in various useful ways.

OK in addition to the bisection I've collected trace data for the good
(commit 4d770ccf4257b23a7ca2a85de1b1c22657b581d8) and bad (commit
e261f51f25b98c213e0b3d7f2109b117d714f69d) cases.

Attached is a file called trace.tar.bz2 inside you'll find 4 files, for
the two sessions:

  bad-wireshark
  bad-strace

  good-wireshark
  good-strace

>From a quick glance the difference seems to be the bad case does an
UNSTABLE NFS WRITE call.  I don't really know what that means or what
its semantics are... but that bad commit does seem to introduce this
regression.

Anything else I can provide?

Thanks!

					=a=


-- 
===================
Aaron Straus
aaron@...finllc.com

Download attachment "trace.tar.bz2" of type "application/octet-stream" (13979 bytes)