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: <18519.24997.34761.283298@notabene.brown>
Date:	Tue, 17 Jun 2008 17:03:01 +1000
From:	Neil Brown <neilb@...e.de>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	Chuck Lever <chucklever@...il.com>,
	Peter Staubach <staubach@...hat.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] knfsd: nfsd: Handle ERESTARTSYS from syscalls.

On Monday June 16, trond.myklebust@....uio.no wrote:
> On Mon, 2008-06-16 at 11:09 -0400, Chuck Lever wrote:
> 
> > I think an error reply is much better than no reply in nearly every
> > case.  NFS3ERR_JUKEBOX/NFS4ERR_DELAY is an interesting idea, but
> > something else again will probably be required for v4.1 with sessions.
> 
> NFS3ERR_JUKEBOX/NFS4ERR_DELAY may be inappropriate if the nfs daemon has
> already started handling the RPC call, since you may be interrupting a
> non-idempotent operation.

If the filesystem allows you to interrupt a non-idempotent operation
part way through, then the filesystem is doing something very wrong.

The observed behaviour is that multiple 32K writes are outstanding
(in different nfsd threads) when a signal is delivered to each nfsd.

OCFS2 appears to be serialising these writes.

One of the writes completes returning a length that is less than 32K.
This length is returned to the client.  A quick look at the client
code suggests that it complains with a printk, and tries to write the
remainder, which seems correct.

The other writes all complete with ERESTARTSYS.  Presumably they
haven't started at all.  If they had, you might expect a partial
return from them too.

So far, what OCFS2 is doing seems credible and doesn't leave us in an
awkward position with respect to incomplete idempotent operations.

I cannot be certain, but I'm willing to believe that OCFS2 only
returns ERESTARTSYS when the operation hasn't been performed at all
(or has been wound-back to the starting condition).

I agree that NFS3ERR_JUKEBOX is more appropriate than no reply, but I
don't think there is any reason to suspect that will not be
sufficient.

Thanks,
NeilBrown
--
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