<div dir="ltr">Just to explain my previous mail even better--<br><br><br>1. If I need to protect my driver from itself, it can add its own locking.<br>
<br>2. If the problem is that dcache_lock is used to protect critical variables from other parts of the kernel, I have two options-<br>a) I will need to restructure my code to avoid the issue<br>b) I need to find other suitable locking.<br>
<div><font face="arial, sans-serif"><br><br>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-</font></div>
<div><a href="https://github.com/HeisSpiter/hepunion/blob/master/fs/hepunion/helpers.c#L373" target="_blank">https://github.com/HeisSpiter/hepunion/blob/master/fs/hepunion/helpers.c#L373</a><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><br></div><div>From what I could make out from our driver code is that -<br></div><div>hepunion_permission and hepunion_getattr are called by the VFS(or kernel) and both receive its parameters from VFS only-<br>
<br>a)<span>static</span> <span>int</span> <span>hepunion_getattr</span><span>(</span><span>struct</span> <span>vfsmount</span> <span>*</span><span>mnt</span><span>,</span> <span>struct</span> <span>dentry</span> <span>*</span><span>dentry</span><span>,</span> <span>struct</span> <span>kstat</span> <span>*</span><span>kstbuf</span><span>)</span> <br>
<br>b)<span>static</span> <span>int</span> <span>hepunion_permission</span><span>(</span><span>struct</span> <span>inode</span> <span>*</span><span>inode</span><span>,</span> <span>int</span> <span>mask</span><span>)</span> <br>
<br></div><div>Now if you look at the function definition, you would find that both of them use <br></div><div>get_relative_path-<br><br></div><a href="https://github.com/HeisSpiter/hepunion/blob/8ce91306a302afe797af09b0831d312ad87e495a/fs/hepunion/helpers.c#L446" target="_blank">https://github.com/HeisSpiter/hepunion/blob/8ce91306a302afe797af09b0831d312ad87e495a/fs/hepunion/helpers.c#L446</a><br>
<div><br>and pass either inode or dentry respectively.<br><br></div><div>Inside this function either<br><pre><div><pre>a)get_full_path_d(dentry, real_path);//called if dentry is sent<br><br>b)get_full_path_i(inode, real_path);//called if inode is sent<br>
</pre></div><div><span></span></div></pre> Now inside get_full_path_i ultimately get_full_path_d gets called ultimately.<br><br></div><div>Now inside get_full_path_d only, we implement our dcache_lock to calculate the path.<br>
<br></div><div>Conclusion- So I conclude that in our code "dcache_lock is used to protect critical variables from other parts of the kernel,"<br></div><div><br>What critical variable?<br></div><div>See I have registered my driver functions to respective system calls through which VFS calls them. <br>
<br>Now when I do mount, the following system calls gets generated-<br></div><div>1. mount(get_sb in the new kernel) - which calls hepunion_read_super and the super block gets assigned<br></div><div>2.permission---mapped to hepunion_permission<br>
</div><div>3.getattr------mapped to hepunion_getattr<br></div><div><br></div><br><div class="im"><div>Now when I do a ls <br></div><div>hepunion_permission again gets called and this time the VM gets hanged<br></div></div>
SO NOW DIFFERENT PARAMETRS ARE BEING PASSED TO
THE FUNCTION
THIS TIME AND THIS MAYBE CAUSING THE HANG<div>
<br></div><div>so maybe for "ls" VFS sent different parameters to hepunion_permission() in "ls "<br></div><div>command that it did during mount.<br></div><div><br>Regards,<br></div>Saket Sinha<br></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 12:35 AM, Saket Sinha <span dir="ltr"><<a href="mailto:saket.sinha89@gmail.com" target="_blank">saket.sinha89@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div class="im"><div>>>Can you explain the code paths that are causing an issue with dcache_lock gone?<br>
</div><div><br></div></div><div>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 <a href="https://github.com/HeisSpiter/hepunion/" target="_blank">https://github.com/HeisSpiter/hepunion/</a>.<br>
</div><div><br></div><div><br></div>See I am working on a type of Union file System which has two branches -<br></div>1. Read Only- have individual mount point<br></div>2.Read Write-also have individual mount point<br><br>
</div>Now they coexist in a merged mount point.<br>
<br></div>so when such a mount command gets issued in my driver(HEPunion FS)-<div>mount -t Hepunion -o /tmp/rw_path=RW:/tmp/ro_path=RO none /tmp/merged</div><div><br></div><div>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</div>
<div><br></div><div>1.In this mount command following three main steps happen for each branch one after the other<br></div><div><br></div><div>Step1-hepunion_read_super which involves</div><div><br></div><div>a)get_branches: </div>
<div> MNT_POINT1=RW</div><div> MNT_POINT2=RO </div><div><br></div><div>b)make_path: RW, make_path:<span style="white-space:pre-wrap"> </span>RO</div><div><br></div><div>Step2-hepunion_permission which involves</div>
<div><br></div><div> a) get_relative_path: </div><div> </div><div> b) get_file_attr:</div><div><br></div><div><br></div><div>Step3- hepunion_getattr which involves</div><div> </div><div>a) get_relative_path: </div>
<div><br></div><div> b) get_file_attr: </div><div><br><div>So my mount is successful</div><div><br></div><div>2. But when I navigate to mount point and do a "ls" ....THE KERNEL CRASHES</div><div>The last few messages I collect from crash utility is the call to hepunion_permission which again involves the above two steps-</div>
<div><br></div><div><div>a) get_relative_path:-----<b>This is where my kernel crashes </b></div><div> </div><div>b) get_file_attr:- I do not reach here</div></div><div><br></div><div><br></div><div><b>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" . </b></div>
<div><br></div><div class="gmail_extra">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.<div>
<div class="h5"><br>
<br><div class="gmail_quote">On Tue, Sep 3, 2013 at 3:40 AM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
> Since lot of things have changed from 2.6.18 to 3.8 and I have taken a lot<br>
> of care to replace the old kernel APIs with the newer ones but then too<br>
> there have been certain things I haven't been able to replace and<br>
> dcache_lock is one of them.<br>
><br>
> Due to the absence of dcache_lock, I have not been able to properly lock<br>
> stuff and writing/reading data that are being changed that maybe one of the<br>
> reasons for instability.<br>
<br>
</div>There's nothing stopping your driver from adding its own locking to<br>
protect itself from itself. If the problem is that you used to use<br>
dcache_lock to protect your critical variables from other parts of the<br>
kernel, you'll need to restructure your code to avoid the issue, or find<br>
other suitable locking.<br>
<br>
Can you explain the code paths that are causing an issue with dcache_lock gone?<br>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>