From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756551AbYIIPlS (ORCPT ); Tue, 9 Sep 2008 11:41:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754342AbYIIPlC (ORCPT ); Tue, 9 Sep 2008 11:41:02 -0400 Received: from mtagate3.uk.ibm.com ([195.212.29.136]:47207 "EHLO mtagate3.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753223AbYIIPlA (ORCPT ); Tue, 9 Sep 2008 11:41:00 -0400 Message-ID: <48C69906.5070703@fr.ibm.com> Date: Tue, 09 Sep 2008 17:40:54 +0200 From: Cedric Le Goater User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: "Serge E. Hallyn" CC: "Eric W. Biederman" , Andrew Morton , Trond Myklebust , Chuck Lever , Linux Kernel Mailing List , Linux Containers , linux-nfs@vger.kernel.org Subject: Re: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared References: <48C52B29.4020204@fr.ibm.com> <20080909124311.GA10053@us.ibm.com> <20080909152952.GA21207@us.ibm.com> In-Reply-To: <20080909152952.GA21207@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> "Serge E. Hallyn" 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.