linux-kernel - Re: [RFC][PATCHSET] non-recursive link_path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <553668C1.8030707@nod.at>
Date:	Tue, 21 Apr 2015 17:12:01 +0200
From:	Richard Weinberger <richard@....at>
To:	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@...IV.linux.org.uk>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	NeilBrown <neilb@...e.de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC][PATCHSET] non-recursive link_path_walk() and reducing stack
 footprint

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/