linux-kernel - Re: [PATCHSET v2] ->follow_link() without dropping from RCU mode

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: <CA+55aFwEyd72jgm6rzTB0P9qQ1URpANyEyrb3c5b4g982BJvqg@mail.gmail.com>
Date:	Wed, 9 Dec 2015 09:24:32 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Neil Brown <neilb@...e.com>
Subject: Re: [PATCHSET v2] ->follow_link() without dropping from RCU mode

On Tue, Dec 8, 2015 at 9:32 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Any help with review and testing would be welcome.  FWIW, it seems to survive
> the beating here.

It looks ok to me, but I *hate* that "cookie" thing we have. And I
don't actually see any reason for it.

Every single user except for a couple seem to just put the resulting
symlink address into the cookie (and then put_link() will kfree it or
put_page() it). And the calling convention would be *so* much clearer
if we just made things be

   char *get_link(dentry, inode);
   put_link(dentry, inode, char *);

and get rid of that cookie entirely.

The only users of the cookie seem to be

 - we currently use it for the page pointer vs the page data address.

   That's because of the HIGHMEM crap that you removed. Without
highmem, the page data address specifies the page fine without any
cookie.

 - overlayfs, which uses it to create a temporary data storage.

   Why? Mainly because it wants to hide the cookie in there. D'oh!

 - proc, which uses it to save the proc_dir_entry

   Why? The reason seems to be that we don't call put_link() with the
dentry that get_link got, so it can't look it up the sane way.

In other words, as far as I can tell, the cookie is just garbage now.

But maybe I missed something.

Other than that, I like the series. And I realize that technically the
"cookie removal" would be a separate thing, but since you're changing
the calling convention from "follow_link()" to "get_link()" in this
series, I _really_ think that as part of that calling convention
change we should just get rid of the cookie, rather than have
*another* calling convention change later.

Hmm?

                       Linus
--
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/