On 2 Aug 2000, A. Ott wrote:
> >From a dentry I need to find its parent dentry. As long as no mount point
> is touched, no problem (dentry->d_parent). The mount point issue used to
> be easily solved with a simple ->d_covers in between. Unfortunately,
> d_covers has been silently removed in 2.4.0-test1.
You are asking for meaningless object. Filesystem may be mounted from many
> So now my problem is the following:
> - I have a dentry, which is the root dentry of a filesystem.
> - I want to access the (first) mount point dentry and go on to its parent
IOW, you want meaningless behaviour. Fine.
> I have already experimented for hours with the list
> dentry->d_sb->s_mounts, struggling with vfsmounts, list_entries and such.
> My idea was to use
> tmp_mnt =
> list_entry(&(dentry->d_sb->s_mounts.next), struct vfsmount, mnt_list);
> new_dentry = tmp_mnt->mnt_mountpoint;
> but that does not work, the new_dentry value is bogus.
Care to show the actual code? Showing what are your really trying to do
may actually help. If it's permission() hacking I'm thinking about - the
right answer is very different from what you are trying.
> I would appreciate any help. I already found a short doc about the now
> used list management in linux-kernel, which at least gave me some
> understanding and took me where I am now.
> BTW: WHY do such fundamental changes in kernel mechanisms (lookup_dentry
> -> path_walk, dentries -> nameidata with vfsmounts, sb->s_mounts with
> undocumented lists of these new vfsmount structs) take place in the last
> steps prior to a new stable series? I'd have liked to support 2.4.0 with
> RSBAC as soon as it comes out, but I don't see that happen now.
Because the old mechanisms were broken by several things, inclusion of
devfs being one of them.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:10 EST