Hi,
Since the current kernel cannot be compiled with NFS client and without
lockd, it is not possible to register a user space NLM server
Without colliding with the kernel service registered in
.../fs/lockd/lockd.c.
This simple patch gives the ability to provide NLM_PROGRAM from outside:
--- linux-2.6.20/include/linux/lockd/nlm.h 2007-02-04
20:44:54.000000000 +0200
+++ linux-2.6.20_patched/include/linux/lockd/nlm.h 2007-05-10
12:21:40.799004000 +0300
@@ -30,7 +30,9 @@
#endif
};
+#ifndef
#define NLM_PROGRAM 100021
+#endif
#define NLMPROC_NULL 0
#define NLMPROC_TEST 1
Menny
On Thursday May 10, [email protected] wrote:
> Hi,
>
> Since the current kernel cannot be compiled with NFS client and without
> lockd, it is not possible to register a user space NLM server
> Without colliding with the kernel service registered in
> .../fs/lockd/lockd.c.
This doesn't make any sense to me at all.
You can certainly have the NFS client compiled and even running
without lockd running (if you mount with "-o nolock") and in that case
you are free you register your owner user-space NLM server (though I'm
not sure what good it would do you).
And if you want to mount an NFS filesystem without "-o nolock", then
you really need the kernel lockd running, or locking will not work.
Can you explain what you are trying to do - I'm curious.
>
> +#ifndef
> #define NLM_PROGRAM 100021
> +#endif
Uhm... Do you mean
+#ifndef NLM_PROGRAM
?? Still not sure how that helps.
NeilBrown
Hi,
We have a our own userland NFSD and NLM service running that implement
all the NLM/NFS functionality.
We do not want to modify the way the client does his mounts.
M.
-----Original Message-----
From: Neil Brown [mailto:[email protected]]
Sent: Thursday, May 10, 2007 12:03 PM
To: Menny Hamburger
Cc: [email protected]
Subject: Re: [PATCH] NLM program ID for user space NLM server
On Thursday May 10, [email protected] wrote:
> Hi,
>
> Since the current kernel cannot be compiled with NFS client and
> without lockd, it is not possible to register a user space NLM server
> Without colliding with the kernel service registered in
> .../fs/lockd/lockd.c.
This doesn't make any sense to me at all.
You can certainly have the NFS client compiled and even running without
lockd running (if you mount with "-o nolock") and in that case you are
free you register your owner user-space NLM server (though I'm not sure
what good it would do you).
And if you want to mount an NFS filesystem without "-o nolock", then you
really need the kernel lockd running, or locking will not work.
Can you explain what you are trying to do - I'm curious.
>
> +#ifndef
> #define NLM_PROGRAM 100021
> +#endif
Uhm... Do you mean
+#ifndef NLM_PROGRAM
?? Still not sure how that helps.
NeilBrown
On Thu, 2007-05-10 at 13:59 +0300, Menny Hamburger wrote:
> Hi,
>
> We have a our own userland NFSD and NLM service running that implement
> all the NLM/NFS functionality.
> We do not want to modify the way the client does his mounts.
>
> M.
The client needs to have lockd running (as service 100021) in order to
allow the NSM daemon to notify it of server reboots.
Trond
The idea in the change was to be able to override NLM_PROGRAM with
another definition (from our slightly customized build system), so that
the kernel never tries to register port 100021.
We understand that if all mounts are with 'nolock' this wouldn't happen,
and indeed, we configured our mounts that way, but we want to protect
ourself from some innocent mounter that doesn't know/care about NLM,
doesn't use 'nolock' and could cause the kernel to take away our port.
This of course happened in real life.
If such patch would be accepted, it could save some time to anyone who
tries to run user mode NLM server, but it's pretty esoteric, so maybe
this discussion is enough to document the issue.
-----Original Message-----
From: Trond Myklebust [mailto:[email protected]]
Sent: Thursday, May 10, 2007 3:39 PM
To: Menny Hamburger
Cc: Neil Brown; [email protected]
Subject: RE: [PATCH] NLM program ID for user space NLM server
On Thu, 2007-05-10 at 13:59 +0300, Menny Hamburger wrote:
> Hi,
>
> We have a our own userland NFSD and NLM service running that implement
> all the NLM/NFS functionality.
> We do not want to modify the way the client does his mounts.
>
> M.
The client needs to have lockd running (as service 100021) in order to
allow the NSM daemon to notify it of server reboots.
Trond
On Thu, 2007-05-10 at 18:30 +0300, Menny Hamburger wrote:
> The idea in the change was to be able to override NLM_PROGRAM with
> another definition (from our slightly customized build system), so that
> the kernel never tries to register port 100021.
I repeat: The kernel _NEEDS_ to register RPC service 100021 on the
client so that rpc.statd can find it and notify it of server reboots.
Trond
Yes, but in our case we don't care. This is a dedicated server where we
don't see any usage for NLM client. We just want to prevent the kernel
from taking the port in case of some accidental NFS mount that ommitted
'nolock'.
-----Original Message-----
From: Trond Myklebust [mailto:[email protected]]
Sent: Thursday, May 10, 2007 6:27 PM
To: Menny Hamburger
Cc: Neil Brown; [email protected]
Subject: RE: [PATCH] NLM program ID for user space NLM server
On Thu, 2007-05-10 at 18:30 +0300, Menny Hamburger wrote:
> The idea in the change was to be able to override NLM_PROGRAM with
> another definition (from our slightly customized build system), so
> that the kernel never tries to register port 100021.
I repeat: The kernel _NEEDS_ to register RPC service 100021 on the
client so that rpc.statd can find it and notify it of server reboots.
Trond
On Thu, 2007-05-10 at 19:45 +0300, Menny Hamburger wrote:
> Yes, but in our case we don't care. This is a dedicated server where we
> don't see any usage for NLM client. We just want to prevent the kernel
> from taking the port in case of some accidental NFS mount that ommitted
> 'nolock'.
Which is _wrong_. If you omit the 'nolock' mount option, then the client
_does_ use NLM locking, and so will need the RPC downcall.
If you don't need NLM locking, and want to make sure nobody else can
enable it, then you can triviall 'fix' this on your server by patching
it to force the nolock mount option. This isn't a patch that we
particularly want to see in mainline, though.
Trond
Well,
That maybe a better idea then what we do - we'll try it.
Thnx,
Menny
-----Original Message-----
From: Trond Myklebust [mailto:[email protected]]
Sent: Thursday, May 10, 2007 7:04 PM
To: Menny Hamburger
Cc: Neil Brown; [email protected]
Subject: RE: [PATCH] NLM program ID for user space NLM server
On Thu, 2007-05-10 at 19:45 +0300, Menny Hamburger wrote:
> Yes, but in our case we don't care. This is a dedicated server where
> we don't see any usage for NLM client. We just want to prevent the
> kernel from taking the port in case of some accidental NFS mount that
> ommitted 'nolock'.
Which is _wrong_. If you omit the 'nolock' mount option, then the client
_does_ use NLM locking, and so will need the RPC downcall.
If you don't need NLM locking, and want to make sure nobody else can
enable it, then you can triviall 'fix' this on your server by patching
it to force the nolock mount option. This isn't a patch that we
particularly want to see in mainline, though.
Trond