Re: [CHECKER] 37 stack variables >= 1K in 2.4.17

From: Alexander Viro (
Date: Thu Jun 13 2002 - 19:25:50 EST

On Thu, 13 Jun 2002, Dawson Engler wrote:

> > It has to be known to checker. Explicitly, since
> > a) automatically deducing it is not realistic
> > b) cutting off the stuff behind that loop will cut off a _lot_ of
> > things - both in filesystems and in VFS (and in block layer, while we are
> > at it).
> We're all about jamming system specific information into the checking
> extensions. It's usually just a few if statements. So to be clear: we
> can simply assume that the loop
> link_path_walk
> ->do_follow_link
> ->foofs_follow_link
> ->vfs_follow_link
> ->link_path_walk
> can happen exactly 5 times?

static inline int do_follow_link(struct dentry *dentry, struct nameidata *nd)
        int err;
        if (current->link_count >= 5)
                goto loop;
        err = dentry->d_inode->i_op->follow_link(dentry, nd);
        return err;
        return -ELOOP;

->link_count is modified only by the code above.

INIT_TASK has zero link_count.

new task inherits ->link_count of parent at the moment of do_fork()

It means that:
        * at any moment ->link_count is between 0 and 5
        * at any moment the call chain contains at most 6 instances of
        * if there are 6 such instances then the last of them is either the
last element of chain or it is followed by path_release().

        BTW, it shows a potential subtle problem - if we ever call do_fork()
while resolving a symlink (the only way that can happen is kernel_thread()
being called in process of symlink resolution) we will get a kernel thread
with limit for nested symlinks lower than 5. Proposed fix (both 2.4 and 2.5):

ed kernel/fork.c <<EOF
        p->link_count = 0;


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:30 EST