Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: >> >>> Thanks, Cedric. Eric is probably right about the long-term fix, but >>> yeah it might take a while to properly wade through the sunrpc and nfs >>> layers to store the nodename at nfs mount time, and in the meantime this >>> fixes a real oops. >> A very esoteric oops that hasn't shown up for two years. > > But an easily reproducible one. > > It's not as though we'll stop looking for the right fix just bc we have > this "bad" fix in for a short while. > >> Please let's look at this and see what it would take to fix this >> properly. > > Of course. Cedric is looking at the best way to fix it... yes. well, my eyes are making progress in the NFS code. it will take some time :) >> What are we trying to achieve by reading utsname? > > It looks like it gets copied into the sunrpc messages so I assume it is > a part of the sunrpc spec? > > I don't want to do this, but we *could* put a conditional in utsname() > to have it return init_utsname if current->nsproxy is null... I nearly did that one but it will hide future misusage of utsname(). So I think it's better to keep it that way, and let the machine oops when we need to fix our code. C. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
