Re: [uml-devel] Re: [patch 1/2] Fixup symlink function pointers for hppfs [for 2.6.13]

[Al Viro]

On Sun, Sep 18, 2005 at 02:00:35PM +0200, Blaisorblade wrote:
> Well, on this point I guess I'll need more help.

[snip]
Ugh.  What you need to do is
	* lock underlying directory (procfs one)
	* call lookup_one_len()
	* unlock
and be done with that.  And yes, ->d_revalidate() for your dentries should
call the underlying one *if* dentry is positive.  For negative ones you'll
obviously have to repeat lookup, so just return 0.

> > What the hell is going on with iget() calls, BTW? 
> 
> > Especially since all 
> > of them get the same inumber...  Looks completely broken.
> Why especially? You mean that ->lookup is not supposed to iget()? ext2 does 
> it, both for lookup and for fill_super.

Lookup is supposed to iget when there are useful inode numbers and a chance
to find something in icache.  You have neither...
 
> For the point of the same inumber...Argh... never realized how broken this 
> could be - until now. We're always reusing the *same* inode!
> 
> No idea, didn't write the code...
> 
> On using 0, in practice hostfs has been working almost perfectly (but 
> I'd underline *almost*) in the same way... I think it should be fixed but I 
> don't know how (we have an *intrusive* fix for hostfs).

Why bother them, anyway?  Just allocate a new inode upon ->lookup() and
have ->drop_inode = generic_delete_inode().

> However, since we often (not always) have the underlying procfs entry, maybe 
> we could reuse those inode numbers.

You want ->getattr() anyway, just call the underlying one or generic_fillattr()
if there's none (both for underlying inode).  That'll give you inumbers from
procfs among other things...

> Multiple lseek's giving one of the offsets is fully ok, but a corrupted offset 
> is not.
> 
> drivers/char/mem.c:memory_lseek()
>                         file->f_pos += offset;

... has
        down(&file->f_dentry->d_inode->i_sem);
in the very beginning.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/