Dcache_lock replacement

[Saket Sinha]

>>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/20130904/4124a4f5/attachment.html