Re: [NFS] rpc.mountd crashes when extensively using netgroups

On Thu, Aug 02, 2007 at 11:32:55AM -0400, Jeff Layton wrote:
On Tue, 31 Jul 2007 10:48:24 -0400
"J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
That's an interesting problem. Thanks for the report!

I don't believe that long comma-delimited string actually has any
meaning to the kernel--as far as the kernel is concerned, it's just an
opaque object that will be passed back to mountd later (along with a
path name) to get export options.

So I suppose that string could be replaced by a hash, or maybe even just
by the ip address of the particular host--the disadvantage to the latter
being that it would require the kernel to keep a separate export for
each client address.

I started having a look at this today. The original patches that I
proposed to clean up the rmtab a few months ago also eliminated this
comma-delimited string. Neil had valid objections to it at the time,
but if we switched to using the IP address as a cache key like Bruce
describes then doing that becomes more reasonable.

The only downside I see is the one Bruce points out -- the size of
the kernel export cache would increase. I don't have a feel for whether
this is a show stopper, however.

Yeah, there might be some risk of solving that problem at the expense of
people with tons of clients all matching *.example.com. The actual
export objects are actually pretty small--68 bytes, last I checked?
You'd also need two upcalls to mountd per client (for ip address and
export, as opposed to just ip address). I don't know what other costs
there might be.

What about the idea of hashing the comma-delimited list and passing
that? You'd want hash large enough to be collision-free--might as well
use some cryptographic hash, I guess, though it may be mild overkill.
Is there any reason why that wouldn't work?

Could you remind me what problems you were trying to fix with your rmtab
cleanup?

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

Relevant Pages

  • Re: [NFS] rpc.mountd crashes when extensively using netgroups
    ... I don't believe that long comma-delimited string actually has any ... meaning to the kernel--as far as the kernel is concerned, ... each client address. ... Hashing would certainly work. ...
    (Linux-Kernel)
  • Re: problems with latest smbfs changes on 2.4.34 and security backports
    ... something different on my samba server or similar, ... the client is an IBM NetworkStation 1000 (a PowerPC ... seems a security problem and I don't think is desirable, ... It is possible that you booted a wrong kernel during one of your tests. ...
    (Linux-Kernel)
  • Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9
    ... Thanks to Chuck's help i finally decided to proceed to a git bisect and found the bad patch. ... What isn't quite clear to me is whether this commit causes your user- space server to start failing suddenly, or it causes the client to start sending the special non-standard time stamps in the SETATTR request. ... it would be helpful if you could run this test with a constant kernel version on one side while varying it on the other. ...
    (Linux-Kernel)
  • Re: Debian replicator boot disk problem
    ... I can connect from an other client in the LAN 192.16.0.12 pretty good. ... How could the server write this in its syslog, ... the mount request. ... to keep the kernel image small, and have trouble determining what to include ...
    (comp.os.linux.misc)
  • "CIFS VFS: server not responding" with some client/server combinations
    ... As it might be kernel related and others ... A Samba server running Debian Etch with latest updates. ... I don't know what's different with Etch on the client, ...
    (Linux-Kernel)