Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: Serious locking bug in Linux NFS | Date | 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/
| |