From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755348AbbDUPMI (ORCPT ); Tue, 21 Apr 2015 11:12:08 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:65276 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753058AbbDUPME (ORCPT ); Tue, 21 Apr 2015 11:12:04 -0400 Message-ID: <553668C1.8030707@nod.at> Date: Tue, 21 Apr 2015 17:12:01 +0200 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christoph Hellwig , Al Viro CC: Linus Torvalds , NeilBrown , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC][PATCHSET] non-recursive link_path_walk() and reducing stack footprint References: <20150420181222.GK889@ZenIV.linux.org.uk> <20150421144959.GR889@ZenIV.linux.org.uk> <20150421150408.GA29838@infradead.org> In-Reply-To: <20150421150408.GA29838@infradead.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 21.04.2015 um 17:04 schrieb Christoph Hellwig: > On Tue, Apr 21, 2015 at 03:49:59PM +0100, Al Viro wrote: >> On Mon, Apr 20, 2015 at 07:12:22PM +0100, Al Viro wrote: >> >>> Patches 2/24..6/24 are from Neil's RCU follow_link patchset; the >>> rest of his patchset is, of course, derailed by the massage done here, >>> but AFAICS we should be able to port it on top of this one with reasonably >>> little PITA. >> >> BTW, looking at the ->put_link() instances in the tree, after this series >> all but one of them ignore *everything* other than cookie. The only exception >> is hppfs; it wants dentry (and its inode as well): >> >> static void hppfs_put_link(struct dentry *dentry, void *cookie) >> { >> struct dentry *proc_dentry = HPPFS_I(d_inode(dentry))->proc_dentry; >> >> if (d_inode(proc_dentry)->i_op->put_link) >> d_inode(proc_dentry)->i_op->put_link(proc_dentry, cookie); >> } > > The hppfs code looks totally bogus in general. Richard, do you know if > anyone still uses that part of UML? I'm pretty sure we can kill it. I had the plan to rip it out during this merge window along with other broken UML stuff but I was too late to ask on the UML mailinglist if someone is using it (which I really doubt). So, let's kill it with v4.2. Or we move it into drivers/staging and hope that someone else is fixing it for us? ...just kidding. ;-) Thanks, //richard