Dcache_lock replacement

Saket Sinha saket.sinha89 at gmail.com
Thu Sep 5 04:46:46 EDT 2013

Just to explain my previous mail even better--

1. If I need to protect my driver from itself, it can add its own locking.

2.  If the problem is that dcache_lock is used to protect critical
variables from other parts of the kernel, I have two options-
a) I will need to restructure my code to avoid the issue
b) I need to find other suitable locking.

I specifically list down the link to my kernel driver below where this
dcache-lock is present in 2.6.18 kernel and is absent in 3.8 kernel-

>From what I could make out from our driver code is that -
hepunion_permission and hepunion_getattr are called by the VFS(or kernel)
and  both receive its parameters from VFS only-

a)static int hepunion_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *kstbuf)

b)static int hepunion_permission(struct inode *inode, int mask)

Now if you look at the function definition, you would find that both of
them use


and pass either inode or dentry respectively.

Inside this function either

a)get_full_path_d(dentry, real_path);//called if dentry is sent

b)get_full_path_i(inode, real_path);//called if inode is sent

Now inside get_full_path_i ultimately get_full_path_d gets called

Now inside get_full_path_d only, we implement our dcache_lock  to calculate
the path.

Conclusion- So I conclude that in our code "dcache_lock is used to protect
critical variables from other parts of the kernel,"

What critical variable?
See I have registered my driver functions to respective system calls
through which VFS calls them.

Now when I do mount, the following system calls gets generated-
1. mount(get_sb in the new kernel) - which calls hepunion_read_super and
the super block gets assigned
2.permission---mapped to hepunion_permission
3.getattr------mapped to hepunion_getattr

Now when I do a ls
hepunion_permission again gets called and this time the VM gets hanged

so maybe for "ls" VFS sent different parameters to hepunion_permission() in
"ls "
command that it did during mount.

Saket Sinha

On Wed, Sep 4, 2013 at 12:35 AM, Saket Sinha <saket.sinha89 at gmail.com>wrote:

> >>Can you explain the code paths that are causing an issue with
> dcache_lock gone?
> I would try to explain whatever I can to the best of my ability but if
> further insight is needed, the code can be reffered at
> https://github.com/HeisSpiter/hepunion/.
> See I am working on a type of Union file System which has two branches -
> 1. Read Only- have individual mount point
> 2.Read Write-also have individual mount point
> Now they coexist in a merged mount point.
> so when such a mount command gets issued in my driver(HEPunion FS)-
> mount -t Hepunion -o /tmp/rw_path=RW:/tmp/ro_path=RO none /tmp/merged
> Here /tmp/rw-path is the Read Write branch mount point, /tmp/ro_path is
> the Read Only branch mount point and merged point of the two branches are
> /tmp/merged
> 1.In this mount command following three main steps happen for each branch
> one after the other
> Step1-hepunion_read_super which involves
> a)get_branches:
>             MNT_POINT1=RW
>             MNT_POINT2=RO
> b)make_path: RW, make_path: RO
> Step2-hepunion_permission which involves
>  a) get_relative_path:
>  b) get_file_attr:
> Step3- hepunion_getattr which involves
> a) get_relative_path:
>  b) get_file_attr:
> So my mount is successful
> 2. But when I navigate to mount point and do a "ls" ....THE KERNEL CRASHES
> The last few messages I collect from crash utility is the call to
> hepunion_permission  which again involves the above two steps-
> a) get_relative_path:-----*This is where my kernel crashes  *
> b) get_file_attr:- I do not reach here
> *Now what I fail to understand that when a previous call to
> "hepunion_permission" was successful in "mount" command why it now fails at
> "ls" . *
> P.S.- All the above discussed calls are based on the dmesg and the syslogs
> and may not be properly visualized by just looking at the driver code. If
> the the entire kernel log is needed for various steps, I can also provide
> that.
> On Tue, Sep 3, 2013 at 3:40 AM, <Valdis.Kletnieks at vt.edu> wrote:
>> > Since lot of things have changed from 2.6.18 to 3.8 and I have taken a
>> lot
>> > of care to replace the old kernel APIs with the newer ones but then too
>> > there have been certain things I haven't been able to replace and
>> > dcache_lock is one of them.
>> >
>> > Due to the absence of dcache_lock, I have not been able to properly lock
>> > stuff and writing/reading data that are being changed that maybe one of
>> the
>> > reasons for instability.
>> There's nothing stopping your driver from adding its own locking to
>> protect itself from itself.  If the problem is that you used to use
>> dcache_lock to protect your critical variables from other parts of the
>> kernel, you'll need to restructure your code to avoid the issue, or find
>> other suitable locking.
>> Can you explain the code paths that are causing an issue with dcache_lock
>> gone?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130905/dacd99cd/attachment.html 

More information about the Kernelnewbies mailing list