* nfsd bugfixes
@ 2010-01-06 22:44 J. Bruce Fields
0 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2010-01-06 22:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-nfs
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(-)
^ permalink raw reply [flat|nested] 12+ messages in thread* nfsd bugfixes
@ 2007-11-12 21:05 ` J. Bruce Fields
0 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-11-12 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Neil Brown, nfs, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* nfsd bugfixes
@ 2007-11-12 21:05 ` J. Bruce Fields
0 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-11-12 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: nfs, linux-kernel, Neil Brown, stable
The following two patches are nfsd bugfixes that I believe are
appropriate for 2.6.24 and 2.6.23.y.
--b.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
2007-11-12 21:05 ` J. Bruce Fields
@ 2007-11-12 22:08 ` Neil Brown
-1 siblings, 0 replies; 12+ messages in thread
From: Neil Brown @ 2007-11-12 22:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: nfs, Linus Torvalds, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
@ 2007-11-12 22:08 ` Neil Brown
0 siblings, 0 replies; 12+ messages in thread
From: Neil Brown @ 2007-11-12 22:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Linus Torvalds, nfs, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
2007-11-12 22:08 ` Neil Brown
@ 2007-11-12 22:13 ` J. Bruce Fields
-1 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-11-12 22:13 UTC (permalink / raw)
To: Neil Brown; +Cc: nfs, Linus Torvalds, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
@ 2007-11-12 22:13 ` J. Bruce Fields
0 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-11-12 22:13 UTC (permalink / raw)
To: Neil Brown; +Cc: Linus Torvalds, nfs, linux-kernel, stable
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
2007-11-12 22:13 ` J. Bruce Fields
@ 2007-11-12 22:35 ` Neil Brown
-1 siblings, 0 replies; 12+ messages in thread
From: Neil Brown @ 2007-11-12 22:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: nfs, linux-kernel
(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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
@ 2007-11-12 22:35 ` Neil Brown
0 siblings, 0 replies; 12+ messages in thread
From: Neil Brown @ 2007-11-12 22:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: nfs, linux-kernel
(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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
2007-11-12 22:35 ` Neil Brown
@ 2007-11-12 23:17 ` J. Bruce Fields
-1 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-11-12 23:17 UTC (permalink / raw)
To: Neil Brown; +Cc: nfs, linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nfsd bugfixes
@ 2007-11-12 23:17 ` J. Bruce Fields
0 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-11-12 23:17 UTC (permalink / raw)
To: Neil Brown; +Cc: nfs, linux-kernel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* nfsd bugfixes
@ 2007-07-27 21:17 J. Bruce Fields
0 siblings, 0 replies; 12+ messages in thread
From: J. Bruce Fields @ 2007-07-27 21:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: Neil Brown, nfs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-01-06 22:44 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-06 22:44 nfsd bugfixes J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2007-11-12 21:05 J. Bruce Fields
2007-11-12 21:05 ` J. Bruce Fields
2007-11-12 22:08 ` Neil Brown
2007-11-12 22:08 ` Neil Brown
2007-11-12 22:13 ` J. Bruce Fields
2007-11-12 22:13 ` J. Bruce Fields
2007-11-12 22:35 ` Neil Brown
2007-11-12 22:35 ` Neil Brown
2007-11-12 23:17 ` J. Bruce Fields
2007-11-12 23:17 ` J. Bruce Fields
2007-07-27 21:17 J. Bruce Fields
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.