> I've noticed that in proc_put_inode, we set i_nlink = 0, so cached inodes
> don't hang around in core. This is causing a conflict with my /proc/<pid>
> variable permissions patch as this relies upon proc_write_inode being
> called with the new permissions.
Hi Chris,
I made the changes in /proc to get rid of inodes and dentries
immediately to avoid problems with stale copies of volatile information.
If your patch needs to make persistant changes to permissions, then it
would probably be better to find a way to store this with the object
being represented rather than in the temporary /proc structures.
> Are there plans to implement the FS_NO_DCACHE flag? This would probably be
> the proper way to avoid caching /proc stuff; dirty inodes caused by
> attempted changes could be sync_one()d immediately. proc_write_inode could
> then selectively act upon various changed inode fields. The other changes
> can be ignored and would be "refreshed" to the correct values on the next
> iget which would cause a new non-cached inode lookup.
In the case of /proc, where would an inode be written? The problem with
a synthetic filesystem is that the objects may not have a persistant
representation.
Regards,
Bill