> > If you want to try - by all means, go ahead,
> > I'll be glad to see the current situation improved.
> OK, let me attempt something in the style as sketched earlier today.
> There are two stages: Step One is changing follow_link in all
> filesystems to not call vfs_follow_link but to return immediately
> so that the caller can call vfs_follow_link and release resources.
> Somewhat boring work. The patch is below.
> I do not doubt that you'll find all typos, so I did not try
> to compile and test.
> Yes, so the question was how to communicate between filesystem
> and namei.c about what resources have to be freed.
> I considered (i) calling the filesystem with a preallocated page,
> (ii) requiring a page, (iii) requiring page or kmalloc,
> (iv) letting the filesystem supply a callback.
> Since I am lazy and (iii) was easiest, I did (iii).
> That is also reasonable: in almost all cases it really is a page,
> and a flag can signal otherwise.
> The communication between filesystems and namei.c uses
> char **link and page **page and two bits in nd->flags.
> The filesystem gets char **link and page **page.
> Its job is to fill *link with the string, but in case
> it did the complete follow_link itself (as happens under /proc)
> it sets the DONE flag.
> Now namei.c will release page when it is nonzero, and will free
> link when the filesystem tells that that is needed in the KFREE flag.
> What is wrong? You will tell me, but what I disliked while doing
> this was the name prepare_follow_link. Too long. A second time
> I might pick get_link or so.
> The result of Step One is that the loop no longer touches all
> filesystems but lives entirely in namei.c. So, the second patch,
> that only changes namei.c can change the recursion into iteration.
> Maybe tomorrow or the day after.
Obvious breakage: nd->flags can be clobbered by __vfs_follow_link(), so
your do_follow_link() and friends are broken.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/