linux-kernel - Re: NFS hang + umount -f: better behaviour requested.

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]

Date:	Fri, 24 Aug 2007 11:53:17 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Ric Wheeler <ric@....com>
Cc:	John Stoffel <john@...ffel.org>,
	Peter Staubach <staubach@...hat.com>,
	Robin Lee Powell <rlpowell@...italkingdom.org>,
	linux-kernel@...r.kernel.org
Subject: Re: NFS hang + umount -f: better behaviour requested.

On Fri, Aug 24, 2007 at 11:09:14AM -0400, Ric Wheeler wrote:
> J. Bruce Fields wrote:
>> The NFS server alone can't prevent the problems Peter Staubach refers
>> to.  Their frequency also depends on the network and the way you're
>> using the filesystem.  (A sufficiently paranoid application accessing
>> the filesystem could function correctly despite the problems caused by
>> soft mounts, but the degree of paranoia required probably isn't common.)
>>   
> Would it be sufficient to insure that that application always issues an 
> fsync() before closing any recently written/updated file? Is there some 
> other subtle paranoid techniques that should be used?

NFS already syncs on close (and on unlock), so you should just need to
check the return values from any writes, fsyncs, closes, etc. (and
realize that an error there may mean some or all of the previous writes
to this file descriptor failed).  And operations like mkdir have the
same problem--a timeout leaves you not knowing whether the directory was
created, because you don't know whether the operation reached the server
or not.

I assume the problems with executables that Peter Staubach refers to are
due to reads on mmap'd files timing out.

I don't use soft mounts myself and haven't had to debug user problems
with them, so my understanding of it all is purely theoretical--others
will have a better idea when and how these kinds of failures actually
manifest themselves in practice.

--b.
-
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/