summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2009-09-14 14:06:53 -0400
committerSteve Dickson <steved@redhat.com>2009-09-14 14:06:53 -0400
commitb25c022e58c53cedfd6bd9592f082364d002821b (patch)
tree015071d2fa6b2ad6c3e7fee6915eba5804db5cc8 /tools
parent74badf6f30f7aea95e9d784244488084dbadcb55 (diff)
downloadnfs-utils-b25c022e58c53cedfd6bd9592f082364d002821b.tar.gz
nfs-utils-b25c022e58c53cedfd6bd9592f082364d002821b.tar.xz
nfs-utils-b25c022e58c53cedfd6bd9592f082364d002821b.zip
idmapd: rearm event handler after error in nfsdcb()
A couple of years ago, Bruce committed a patch to make knfsd send unsigned uid's and gid's to idmapd, rather than signed values. Part of that earlier discussion is here: http://linux-nfs.org/pipermail/nfsv4/2007-December/007321.html While this fixed the immediate problem, it doesn't appear that anything was ever done to make idmapd continue working when it gets a bogus upcall. idmapd uses libevent for its main event handling loop. When idmapd gets an upcall from knfsd it will service the request and then rearm the event by calling event_add on the event structure again. When it hits an error though, it returns in most cases w/o rearming the event. That prevents idmapd from servicing any further requests from knfsd. I've made another change too. If an error is encountered while reading the channel file, this patch has it close and reopen the file prior to rearming the event. I've not been able to test this patch directly, but I have tested a backport of it to earlier idmapd code and verified that it did prevent idmapd from hanging when it got a badly formatted upcall from knfsd. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions