Re: [PATCH] kNFSD - Allowing rpc.nfsd to setting of the port, transport and version the server will use

From: Steve Dickson (SteveD_at_redhat.com)
Date: 10/11/05

  • Next message: Ingo Molnar: "Re: 2.6.14-rc3-rt10 crashes on boot" 
    Date:	Tue, 11 Oct 2005 06:54:58 -0400
To: Neil Brown <neilb@suse.de>

    Hey Neil,

    Thanks for taking a look at this...

    Neil Brown wrote:
    > I've taken the 'version' bit, modified is so:
    > 2/ You can only change the setting when there are no active threads.
    Good point...
    >
    > New version this part patch follows. It should be completely
    > compatible with your patch. from a user-space perspective.
    cool... thanks for thinking about this...

    >
    > The 'port' bit I had trouble liking.
    > You write:
    >
    > family proto proto addr port
    >
    > to the 'ports' file.
    > 'family' and 'addr' are completely ignored.
    Well at this point they are not needed since we
    only support ipv4... and I can only assume when we do
    support other families, changing this interface will be
    the least of our problems... ;-)

    > 'port' is effectively ignored (value is stored in a variable which
    > isn't used).
    I'm not sure I understand this... nfsd_port is set and used in
    nfsd_svc()
    @@ -104,11 +152,14 @@ nfsd_svc(unsigned short port, int nrserv
                      nfsd_serv = svc_create(&nfsd_program, NFSD_BUFSIZE);
                      if (nfsd_serv == NULL)
                              goto out;
    + if (NFSCTL_UDPISSET(nfsd_portbits))
    + port = nfsd_port;
                      error = svc_makesock(nfsd_serv, IPPROTO_UDP, port);
                      if (error < 0)
                              goto failure;
      #ifdef CONFIG_NFSD_TCP
    + if (NFSCTL_TCPISSET(nfsd_portbits))
    + port = nfsd_port;
                      error = svc_makesock(nfsd_serv, IPPROTO_UDP, port);
                      if (error < 0)
                              goto failure;

    iff the nfsd_portbits are set... which is exactly the same concept
    used with the version bits... so I am a bit confused on what you want...
    >
    > That leaves 'proto' and 'proto'. One should be 'tcp' or 'notcp', the
    > other should be 'udp' or 'noudp'. Which is which? Udp comes first,
    > but it isn't at all obvious from the interface..
    Maybe being the author of these interfaces you have a better perspective
    than I, but I could say the same thing about all the interfaces under
    /proc/fs/nfsd... :-) So I do agree... its not that obvious, but I guess
    I didn't think it needed to be.. Who else do you see, other than
    rpc.nfsd, using this interface?

    > I think you should write:
    > [+-]family proto addr port
    >
    > and every field must be checked and used.
    > So while we only support ipv4, the 'family' must by 'ipv4' or an error
    > is returned.
    > '+' adds an endpoint. '-' removes it.
    Understood... And I'll assume the default of both TCP and UDP
    listening on port 2048 will stay the same when nothing
    is specified...

    >
    > The old nfssvc syscall should add 'ipv4 udp * %port' and 'ipv4 tcp *
    > %port' if they don't already exist.
    Won't this break backwards compatibility with all the 2.4 kernels?
    The beauty of seq files is that you can change the interface
    and have no effect on kABI at all... which is really a good thing
    in my world... So why do we even care about the old syscall interface?

    >
    > An alternate interface, which would be quite appealing, would be to
    > require the user-space program to create and bind a socket and then
    > communicate it to the kernel, possibly by writing a file-descriptor
    > number to a file in the nfsd filesystem.
    > 'nfsd' would check it is an appropriate type of socket, take
    > an extra reference, and use it.
    > This would probably be best done *after* the nfsd threads were
    > started, so there would need to be a way to start threads without
    > them automatically opening sockets. I'm not sure what the best
    > interface for that would be... Maybe establishing sockets before the
    > thread would be ok.
    Maybe I'm missing something here.... but I'm not quite sure how passing
    a fd to the kernel would help, other than (possibly) with error
    processing... The kernel will still need to know the port and proto so
    it can register them with the portmapper... plus permissions could
    become an problem especially with things like selinux running around..

    steved.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Ingo Molnar: "Re: 2.6.14-rc3-rt10 crashes on boot"