[Tux3] Deferred namespace operations, Split up ext2_new_inode

[OGAWA Hirofumi]

Daniel Phillips <phillips at phunq.net> writes:

> This diff against my previous patch splits ext2_new_inode into front end 
> and back end parts in preparation for deferring the back end part.  The 
> front end just initializes the in-memory inode as with ramfs and leaves 
> the inode number unassigned.  The back end goes fishing around in inode 
> allocation maps to find a suitable free inode and assigns the inode 
> number to the in-memory inode.  Right now, the front end part just 
> calls the back end, so not much has changed yet.

I've tried to list the users of ->i_ino. ->inum issue should have same
issue with deferred inode number. Well, FWIW, the result is:

1) printk()
In some places, kernel users ->i_ino for printk()

2) /proc/locks, /proc/<pid>/{maps,smaps}
Those show the ->i_ino

3) pipefs - pipefs_dname()
It uses ->i_ino as part of filename. This may not matter?

4) fs/nfsd/export.c:exp_hash()
This uses ->i_ino. Since it may be for hash key, so it's ok?

5) audit (CONFIG_AUDIT)
audit (CONFIG_AUDIT) uses ->i_ino to check if it is interesting inode.

6) selinux
Current tree seems _not_ to use ino, however, variant may use?

7) NFS ->get_name()
default handler uses ->i_ino to get the name of inode. We have to
provide own ->get_name() handler.

Thanks.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3