[lkml]   [2015]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 16/24] link_path_walk: kill the recursion
On Mon, Apr 20, 2015 at 02:39:43PM -0700, Linus Torvalds wrote:
> On Mon, Apr 20, 2015 at 2:32 PM, Al Viro <> wrote:
> >
> > What kilobyte? It's 9*4 pointers, IOW, 288 bytes total (assuming 64bit box).
> You also said that you were going to up the recursion limit to 40.. So
> 40*3*8 bytes..

Er... That's exactly what

|| We could reduce it further (see below), but I'm not sure it's worth
|| doing - it's not much extra complexity, but we only squeeze out ~250 bytes
|| that way, with the worst-case footprints (those are triggered by rename())
|| are around 1.4Kb (instead of about twice as much in mainline). OTOH,
|| that extra complexity would've allowed us to get rid of the nesting limit
|| entirely (i.e. we get ELOOP when we encounter 40 symlinks, no matter in
|| which manner they are nested). That might be worth considering...

had been about. And yes, it is easy to implement - new nameidata flag
for "need to kfree() nd->stack",
if (unlikely(current->link_count >= MAX_NESTED_LINKS)) {
path_put_conditional(&next, nd);
return -ELOOP;
BUG_ON(nd->depth >= MAX_NESTED_LINKS);

replaced with
if (nd->depth == 2 && !(nd->flags & LOOKUP_KFREE)) {
struct saved *p = kmalloc(41 * sizeof(*p));
if (!p) {
path_put_conditional(&next, nd);
return -ENOMEM;
memcpy(p, nd->stack, 2 * sizeof(*p));
nd->stack = p;
nd->flags |= LOOKUP_KFREE;
with obvious logics for freeing that crap afterwards.

I really don't like the idea of putting it into nameidata, BTW - consider
e.g. rename(). We don't need the contents of that thing after the
link_path_walk() returns; no point duplicating it...

 \ /
  Last update: 2015-04-21 00:21    [W:0.088 / U:3.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site