Re: Serious locking bug in Linux NFS

Michael H. Warfield (mhw@wittsend.com)
Sat, 17 Oct 1998 16:44:21 -0400 (EDT)


Ben 'The Con Man' Kahn enscribed thusly:

> Alright. I'll give my full list of problems with knfs. I loaded
> kernel 2.1.125, and applied the patch supplied with knfsd-981014. Then I
> compiled the kernel with nfs and nfs server compiled in.
:
: - problems with xtab and rmtab removed...
:

> > > 3) I got this message while starting statd:

> > > Oct 16 13:50:15 linuxserver ./statd[23846]: address mismatch: expected
> > > 240.92.123.21, got 240.92.123.21

> > Here is the relevant code:

> > if (lp->addr.s_addr != sin->sin_addr.s_addr)
> > dprintf(L_WARNING, "address mismatch: "
> > "expected %s, got %s\n",
> > inet_ntoa(lp->addr),
> > inet_ntoa(sin->sin_addr));

Whoa!!!! Time Out! This one I know...

inet_ntoa returns a pointer to a static area. Before dprintf is
called, inet_ntoa is called twice. Each time it puts the resulting string
in a static area and returns a pointer to that area. Guess what happens.
You got the same pointer twice and the last time inet_ntoa got called,
crushed the string created the first time inet_ntoa got called. So it
prints the same address twice. The "if" check reported a mismatch, it's
just your dprintf that's broken.

Basically this, you can not call inet_ntoa multiple times without
copying or saving the resulting strings. You could split the above
dprintf into two dprintf's or copy one of the strings into a temporary
buffer.

> > I don't see how it can happen besides a bad compiler/HW. It looks
> > like you may have a compiler/HW.

From "man inet_ntoa":

The inet_ntoa() function converts the Internet host
address in given in network byte order to a string in
standard numbers-and-dots notation. The string is
returned in a statically allocated buffer, which subse-
quent calls will overwrite.

> Alright... Well, maybe this is just a nameserver problem... This
> worked the time before. (I killed the process and restarted it, got the
> error, and tried again. It worked.) So this isn't a common error.
> It could be hardware I guess...

> > Here is a kernel patch. Please make sure lockd is runing on your client
> > machine. You should start "portmap" before mounting NFS.

> Okay. So lockd isn't running the clients. (which are all 2.0
> kernels for the Linux boxen) Am I to understand that the clients need to
> be running 2.1 kernels?? Is there a patch? This is fairly important.

> AND, as a final note, the SGIs are running lockd. :^) Well, most
> of them are.
> -Ben
>
> ------------------------------------ |\ _,,,--,,_ ,) ----------
> Benjamin Kahn /,`.-'`' -, ;-;;'
> (212) 924 - 2220 |,4- ) )-,_ ) /\
> ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
> Meet Linux: Forrest Gump as an operating system.

Mike

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

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