nfsd bugfixes

nfsd bugfixes

[J. Bruce Fields]

The three following patches are small bugfixes that could go in to
2.6.23.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

nfsd bugfixes

[J. Bruce Fields]

The following two patches are nfsd bugfixes that I believe are
appropriate for 2.6.24 and 2.6.23.y.

--b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfsd bugfixes

[Neil Brown]

On Monday November 12, bfields@citi.umich.edu wrote:
> The following two patches are nfsd bugfixes that I believe are
> appropriate for 2.6.24 and 2.6.23.y.
> 
> --b.
> 

Both
  Reviewed-By: NeilBrown <neilb@suse.de>

Calling nfsd_setuser an extra time does open us up for a very tiny
possibility of an ENOMEM at an awkward time.
We could remove that entirely for NFSEXP_ALLSQUASH by allocating an
empty group_info at export time and just using a reference to that.
It would be more awkward to pre-allocate for the NFSEXP_ROOTSQUASH
case as the group_info has to be at least as big as the one in the RPC
request, and would could need a different one of each concurrent
request.... not sure if that is worth "fixing".

Thanks,
NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfsd bugfixes

[J. Bruce Fields]

On Tue, Nov 13, 2007 at 09:08:42AM +1100, Neil Brown wrote:
> On Monday November 12, bfields@citi.umich.edu wrote:
> > The following two patches are nfsd bugfixes that I believe are
> > appropriate for 2.6.24 and 2.6.23.y.
> > 
> > --b.
> > 
> 
> Both
>   Reviewed-By: NeilBrown <neilb@suse.de>

Thanks, Neil.

> Calling nfsd_setuser an extra time does open us up for a very tiny
> possibility of an ENOMEM at an awkward time.

Hm.  Could you give an example of possible consequences?

(Though note this is somewhat of a separate discussion, since this
particular patch doesn't add a call to nfsd_setuser().)

> We could remove that entirely for NFSEXP_ALLSQUASH by allocating an
> empty group_info at export time and just using a reference to that.
> It would be more awkward to pre-allocate for the NFSEXP_ROOTSQUASH
> case as the group_info has to be at least as big as the one in the RPC
> request, and would could need a different one of each concurrent
> request.... not sure if that is worth "fixing".

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfsd bugfixes

[Neil Brown]

(CC: trimmed - as Bruce says: separate discussion)

On Monday November 12, bfields@fieldses.org wrote:
> On Tue, Nov 13, 2007 at 09:08:42AM +1100, Neil Brown wrote:
> > Calling nfsd_setuser an extra time does open us up for a very tiny
> > possibility of an ENOMEM at an awkward time.
> 
> Hm.  Could you give an example of possible consequences?

Just that you could get an ENOMEM in the middle of a NFSv4 COMPOUND.
I guess that should result in NFSERR_RESOURCE and we just hope the
client is able to cope and resend the remainder of the compound.
Though looking at the code, ENOMEM becomes nfserr_dropit... does that
mean the we would drop the whole request and the client would need to
resend, possibly duplicating non-idempotent portions?

Mainly, it just feels unclean.

> 
> (Though note this is somewhat of a separate discussion, since this
> particular patch doesn't add a call to nfsd_setuser().)

Hmm, you are right, we already call nfsd_setuser in both paths, you we
just adding the check for privileged port - doh ;-)

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfsd bugfixes

[J. Bruce Fields]

On Tue, Nov 13, 2007 at 09:35:01AM +1100, Neil Brown wrote:
> 
> (CC: trimmed - as Bruce says: separate discussion)
> 
> On Monday November 12, bfields@fieldses.org wrote:
> > On Tue, Nov 13, 2007 at 09:08:42AM +1100, Neil Brown wrote:
> > > Calling nfsd_setuser an extra time does open us up for a very tiny
> > > possibility of an ENOMEM at an awkward time.
> > 
> > Hm.  Could you give an example of possible consequences?
> 
> Just that you could get an ENOMEM in the middle of a NFSv4 COMPOUND.
> I guess that should result in NFSERR_RESOURCE and we just hope the
> client is able to cope and resend the remainder of the compound.
> Though looking at the code, ENOMEM becomes nfserr_dropit... does that
> mean the we would drop the whole request and the client would need to
> resend, possibly duplicating non-idempotent portions?

Yeah, OK, that's another one for my list of compound processing problems
to worry about.  (Others:

	- a deferral for an export upcall can similarly lead to
	  incorrect behavior on nonidempotent operations; if we could
	  fix this we could also eliminate the nfs4idmap.c special case,
	  which would probably enable some other cleanup.  I've made a
	  couple half-hearted attempts to fix this but don't have
	  anything finished yet.

	- We've still got the reply cache turned off for nfsv4!  I think
	  it was originally turned off just because whoever did it
	  didn't want to figure out which compounds to cache.  That's
	  probably not hard to fix, but last I checked I didn't think
	  our reply cache actually helped much in the tcp case (the only
	  case we care about).  So that needs to be fixed first.  I've
	  done no work on this yet.

)--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

nfsd bugfixes

[J. Bruce Fields]

The for-2.6.33 branch at:

  git://linux-nfs.org/~bfields/linux.git for-2.6.33

has two new nfsd bugfixes, and one you already have*.  Please pull.

--b.

* I'd already pushed out a commit when you took it as a patch, and given
  the choice between a duplicate commit and rewinding the branch I
  figured the duplicate commit was the lesser evil.  Feel free to tell
  me I'm doing it all wrong.

Christoph Hellwig (1):
      nfsd: make sure data is on disk before calling ->fsync

J. Bruce Fields (1):
      nfsd: fix "insecure" export option

Xiaotian Feng (1):
      sunrpc: fix peername failed on closed listener

 fs/nfsd/nfsfh.c       |    2 +-
 fs/nfsd/vfs.c         |    5 +----
 net/sunrpc/svc_xprt.c |    3 ++-
 3 files changed, 4 insertions(+), 6 deletions(-)