Too many levels of symbolic links

Too many levels of symbolic links

[Brian D. McGrew]

Because of the way our internal filesystem is setup, I'm seeing this
error more and more.

At one time, back in the early 2.4 days, I'd made a change to the kernel
to all more links but I can't seem to find it again in 2.6.  Does anyone
know off hand where this constant is defined???

Thanks,

:b!

Brian D. McGrew { brian@visionpro.com || brian@doubledimension.com }
--
> This is a test.  This is only a test!
  Had this been an actual emergency, you would have been
  told to cancel this test and seek professional assistance!

Re: Too many levels of symbolic links

[Linda Walsh]

Brian D. McGrew wrote:
> Because of the way our internal filesystem is setup, I'm seeing this
> error more and more.
>
> At one time, back in the early 2.4 days, I'd made a change to the kernel
> to all more links but I can't seem to find it again in 2.6.  Does anyone
> know off hand where this constant is defined???
>   
----
Is this what you are looking for?

include/linux/namei.h    MAX_NESTED_LINKS = 5

(used in fs/namei.c, where comment claims MAX_NESTING is equal to 8)

Re: Too many levels of symbolic links

[H. Peter Anvin]

Followup to:  <44580CF2.7070602@tlinx.org>
By author:    Linda Walsh <lkml@tlinx.org>
In newsgroup: linux.dev.kernel
> Is this what you are looking for?
> include/linux/namei.h    MAX_NESTED_LINKS = 5
> (used in fs/namei.c, where comment claims MAX_NESTING is equal to 8)

Wonder if it would make sense to make this a sysctl...

	-hpa

[PATCH] symlink nesting level change

[Al Viro]

On Tue, May 02, 2006 at 07:57:34PM -0700, H. Peter Anvin wrote:
> Followup to:  <44580CF2.7070602@tlinx.org>
> By author:    Linda Walsh <lkml@tlinx.org>
> In newsgroup: linux.dev.kernel
> > Is this what you are looking for?
> > include/linux/namei.h    MAX_NESTED_LINKS = 5
> > (used in fs/namei.c, where comment claims MAX_NESTING is equal to 8)
> 
> Wonder if it would make sense to make this a sysctl...

No.  It's way past time to bump it to 8.  Everyone had been warned - for
months now.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
--- a/include/linux/namei.h	2006-03-31 20:08:42.000000000 -0500
+++ b/include/linux/namei.h	2006-05-02 23:06:46.000000000 -0400
@@ -11,7 +11,7 @@
 	struct file *file;
 };
 
-enum { MAX_NESTED_LINKS = 5 };
+enum { MAX_NESTED_LINKS = 8 };
 
 struct nameidata {
 	struct dentry	*dentry;

Re: [PATCH] symlink nesting level change

[Andrew Morton]

On Wed, 3 May 2006 04:08:49 +0100
Al Viro <viro@ftp.linux.org.uk> wrote:

> No.  It's way past time to bump it to 8.  Everyone had been warned - for
> months now.
> 
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ----
> --- a/include/linux/namei.h	2006-03-31 20:08:42.000000000 -0500
> +++ b/include/linux/namei.h	2006-05-02 23:06:46.000000000 -0400
> @@ -11,7 +11,7 @@
>  	struct file *file;
>  };
>  
> -enum { MAX_NESTED_LINKS = 5 };
> +enum { MAX_NESTED_LINKS = 8 };
>  
>  struct nameidata {
>  	struct dentry	*dentry;

It's a non-back-compatible change which means that people will install
2.6.18+, will set stuff up which uses more that five nested links and some
will discover that they can no longer run their software on older kernels.

It'll only hurt a very small number of people, but for those people, it
will hurt a lot.  And I can't really think of anything we can do to help
them, apart from making the new behaviour runtime-controllable, defaulting
to "off", but add a once-off printk when we hit MAX_NESTED_LINKS, pointing
them at a document which tells them how to turn on the new behaviour and
which explains the problems.  Which sucks.

But I guess as major distros are 2.6.16-based, this is a good time to make
this change.

Re: [PATCH] symlink nesting level change

[Arjan van de Ven]

> But I guess as major distros are 2.6.16-based, this is a good time to make
> this change.

several major distros already had this set to 8 anyway :

and your argument that this is a behavior break... holds for any
improvement and new driver to the kernel as well.. at some point it's
"if you use the new behavior, don't assume you can go back without
losing it"

Re: [PATCH] symlink nesting level change

[Al Viro]

On Wed, May 03, 2006 at 06:35:54PM -0700, Andrew Morton wrote:
> It's a non-back-compatible change which means that people will install
> 2.6.18+, will set stuff up which uses more that five nested links and some
> will discover that they can no longer run their software on older kernels.
> 
> It'll only hurt a very small number of people, but for those people, it
> will hurt a lot.  And I can't really think of anything we can do to help
> them, apart from making the new behaviour runtime-controllable, defaulting
> to "off", but add a once-off printk when we hit MAX_NESTED_LINKS, pointing
> them at a document which tells them how to turn on the new behaviour and
> which explains the problems.  Which sucks.

Those people keep asking to lift that limit.  So no, I don't believe that
making it runtime-controllable is the right thing to do.  Document that
we'd lifted the limit to 8 and such setups become possible since <version>.
 
> But I guess as major distros are 2.6.16-based, this is a good time to make
> this change.

FWIW, RH kernels had that for more than a year by now...

Re: [PATCH] symlink nesting level change

[Tim Pepper]

On 5/3/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 3 May 2006 04:08:49 +0100
> Al Viro <viro@ftp.linux.org.uk> wrote:
>
> > No.  It's way past time to bump it to 8.  Everyone had been warned - for
> > months now.
> >
> > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> > ----
> > --- a/include/linux/namei.h   2006-03-31 20:08:42.000000000 -0500
> > +++ b/include/linux/namei.h   2006-05-02 23:06:46.000000000 -0400
> > @@ -11,7 +11,7 @@
> >       struct file *file;
> >  };
> >
> > -enum { MAX_NESTED_LINKS = 5 };
> > +enum { MAX_NESTED_LINKS = 8 };
> >
> >  struct nameidata {
> >       struct dentry   *dentry;
>
> It's a non-back-compatible change which means that people will install
> 2.6.18+, will set stuff up which uses more that five nested links and some
> will discover that they can no longer run their software on older kernels.
>
> It'll only hurt a very small number of people, but for those people, it
> will hurt a lot.  And I can't really think of anything we can do to help
> them, apart from making the new behaviour runtime-controllable, defaulting
> to "off", but add a once-off printk when we hit MAX_NESTED_LINKS, pointing
> them at a document which tells them how to turn on the new behaviour and
> which explains the problems.  Which sucks.
>
> But I guess as major distros are 2.6.16-based, this is a good time to make
> this change.

Doesn't look like this ended up in 2.6.18-rc nor -mm.  The email
thread in May was tending towards finally bumping it.  Major distros
already have it at 8 for a long time.  Is there any reason left (aside
now from possibly waiting until 2.6.19's window?) to wait?


Tim

Re: [PATCH] symlink nesting level change

[Andrew Morton]

On Thu, 13 Jul 2006 11:35:28 -0700
"Tim Pepper" <lnxninja@us.ibm.com> wrote:

> On 5/3/06, Andrew Morton <akpm@osdl.org> wrote:
> > On Wed, 3 May 2006 04:08:49 +0100
> > Al Viro <viro@ftp.linux.org.uk> wrote:
> >
> > > No.  It's way past time to bump it to 8.  Everyone had been warned - for
> > > months now.
> > >
> > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> > > ----
> > > --- a/include/linux/namei.h   2006-03-31 20:08:42.000000000 -0500
> > > +++ b/include/linux/namei.h   2006-05-02 23:06:46.000000000 -0400
> > > @@ -11,7 +11,7 @@
> > >       struct file *file;
> > >  };
> > >
> > > -enum { MAX_NESTED_LINKS = 5 };
> > > +enum { MAX_NESTED_LINKS = 8 };
> > >
> > >  struct nameidata {
> > >       struct dentry   *dentry;
> >
> > It's a non-back-compatible change which means that people will install
> > 2.6.18+, will set stuff up which uses more that five nested links and some
> > will discover that they can no longer run their software on older kernels.
> >
> > It'll only hurt a very small number of people, but for those people, it
> > will hurt a lot.  And I can't really think of anything we can do to help
> > them, apart from making the new behaviour runtime-controllable, defaulting
> > to "off", but add a once-off printk when we hit MAX_NESTED_LINKS, pointing
> > them at a document which tells them how to turn on the new behaviour and
> > which explains the problems.  Which sucks.
> >
> > But I guess as major distros are 2.6.16-based, this is a good time to make
> > this change.
> 
> Doesn't look like this ended up in 2.6.18-rc nor -mm.  The email
> thread in May was tending towards finally bumping it.  Major distros
> already have it at 8 for a long time.  Is there any reason left (aside
> now from possibly waiting until 2.6.19's window?) to wait?

hm, thanks, it fell through a crack.  I queued it.

Given that distros are already shipping this, I guess we should do this
asap (ie: 2.6.18), to keep the various Linuxes out there in sync.

Re: Too many levels of symbolic links

[Tim Pepper]

On 5/2/06, H. Peter Anvin <hpa@zytor.com> wrote:
> By author:    Linda Walsh <lkml@tlinx.org>
> > Is this what you are looking for?
> > include/linux/namei.h    MAX_NESTED_LINKS = 5
> > (used in fs/namei.c, where comment claims MAX_NESTING is equal to 8)
>
> Wonder if it would make sense to make this a sysctl...

There might be something in somebody's pipeline around this...Early
this year Al Viro said (http://lkml.org/lkml/2006/2/12/104) he was
going to bump it post 2.6.16 back up to 8 to match the comment.

Al:  In the thread referenced above you'd said you would if there
wasn't any major complaint and it didn't seem like any surfaced.  Are
you still planning to up MAX_NESTED_LINKS?


Tim

Re: Too many levels of symbolic links

[Tim Pepper]

Nevermind..missed the subject changed follow up to this...

Tim