From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH][RFC] %pd - for printing dentry name Date: Tue, 2 Feb 2010 16:43:41 +0000 Message-ID: <20100202164341.GG12882@ZenIV.linux.org.uk> References: <20100201222511.GA12882@ZenIV.linux.org.uk> <20100201231847.GC12882@ZenIV.linux.org.uk> <20100202065341.GF6292@linux.vnet.ibm.com> <20100202070908.GF12882@ZenIV.linux.org.uk> <20100202133230.GF1331@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Paul E. McKenney" , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Matthew Wilcox Return-path: Content-Disposition: inline In-Reply-To: <20100202133230.GF1331@parisc-linux.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Feb 02, 2010 at 06:32:31AM -0700, Matthew Wilcox wrote: > How about doing this: > > struct qstr { > - const unsigned char *name; > + const unsigned char name[0]; > } > > struct dentry { > - struct qstr d_name; > + struct qstr *d_name; > - unsigned char d_iname[DNAME_INLINE_LEN_MIN]; /* small names */ > + union { > + struct qstr d_iname; > + char pad[DNAME_INLINE_LEN_MIN]; > + }; > } > > Doesn't increase the size of struct dentry, and puts the hash and len > with the name. Increases long name allocations by 8 bytes each. > > I think reusing the d_iname is OK. As long as we always limit the > number of characters printed to the 'len' element, we should never get > an overrun. At worst, we get a mixture of the previous name and the > next name ... and that's a significant canary in itself. You are creating an extra deref in normal case. Inline names are common. Putting len and hash with the name probably not a win - most of the time you don't look at actual characters and rely on mismatches in other components to skip the candidate during search.