From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] vfs: Fix, simpliy and stop using d_dname for the /proc/*/ns/* files. Date: Sat, 06 Jun 2015 14:27:24 -0500 Message-ID: <87pp58wsbn.fsf@x220.int.ebiederm.org> References: <20150515185820.GQ20468@ycc.fr> <20150520100557.GB32189@mew> <87bnhedhw5.fsf_-_@x220.int.ebiederm.org> <20150520232325.GA7232@ZenIV.linux.org.uk> <20150603205128.GN22078@ycc.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Al Viro , Omar Sandoval , linux-fsdevel@vger.kernel.org To: Ivan Delalande Return-path: Received: from out03.mta.xmission.com ([166.70.13.233]:55935 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752518AbbFFTcd convert rfc822-to-8bit (ORCPT ); Sat, 6 Jun 2015 15:32:33 -0400 In-Reply-To: <20150603205128.GN22078@ycc.fr> (Ivan Delalande's message of "Wed, 3 Jun 2015 22:51:28 +0200") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Ivan Delalande writes: > On Thu, May 21, 2015 at 12:23:25AM +0100, Al Viro wrote: >> On Wed, May 20, 2015 at 05:05:30PM -0500, Eric W. Biederman wrote: >> > - dentry =3D d_alloc_pseudo(mnt->mnt_sb, &qname); >> > + dentry =3D d_alloc_name(mnt->mnt_root, name); >> > if (!dentry) { >> > iput(inode); >> > mntput(mnt); >> > return ERR_PTR(-ENOMEM); >> > } >> > - d_instantiate(dentry, inode); >> > + d_add(dentry, inode); >>=20 >> Careful - that might have non-trivial effects. Namely, you are maki= ng >> the root dentry of that sucker a contention point and adding to hash >> pollution... It's probably not going to cause visible problems, but >> it's worth profiling just to be sure. >>=20 >> Besides, you are violating a bunch of rules here - several hashed >> children of the same directory with the same name all at once... >> not nice. > > Hey Eric, did you have any thought about Al=E2=80=99s concerns? Massive difference in perspective for the most part. It did cause me t= o step back and really look at what that code is doing and why. =46or the immediate problem the issue is that the WARN_ON is warning ab= out something nothing in the kernel has done for 5 years and in practice as you have seen is actually wrong. So deleting the warning message appears the best way to handle the situation you are seeing. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html