<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I see. Thanks a lot for the explanation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Tao<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Lai Siyao [mailto:laisiyao@whamcloud.com] <br><b>Sent:</b> Thursday, January 12, 2012 4:53 PM<br><b>To:</b> Peng, Tao<br><b>Cc:</b> Lustre-discuss@lists.lustre.org<br><b>Subject:</b> Re: [Lustre-discuss] question about dcache revalidate<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>No, to add a dentry to hash client needs holding LOOKUP lock, but lustre client unhash (see ll_unhash_aliases()) doesn't really remove dentry from hash, but set LUSTRE_DCACHE_INVALID flag. So in the race you mentioned, another process may add the dentry but later the lock is canceled soon, so at the time of revalidate, it needs to do a real lookup.<o:p></o:p></p><div><p class=MsoNormal>On Wed, Jan 11, 2012 at 10:06 PM, <<a href="mailto:tao.peng@emc.com">tao.peng@emc.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal>Hi,<br><br>I was reading dcache.c and following comments in ll_revalidate_it() seem confusing. Does it mean llite can hash a positive dentry to dcache without taking inode LOOKUP lock?<br><br>589 /*<br>590 * This part is here to combat evil-evil race in real_lookup on 2.6<br>591 * kernels. The race details are: We enter do_lookup() looking for some<br>592 * name, there is nothing in dcache for this name yet and d_lookup()<br>593 * returns NULL. We proceed to real_lookup(), and while we do this,<br>594 * another process does open on the same file we looking up (most simple<br>595 * reproducer), open succeeds and the dentry is added. Now back to<br>596 * us. In real_lookup() we do d_lookup() again and suddenly find the<br>597 * dentry, so we call d_revalidate on it, but there is no lock, so<br>598 * without this code we would return 0, but unpatched real_lookup just<br>599 * returns -ENOENT in such a case instead of retrying the lookup. Once<br>600 * this is dealt with in real_lookup(), all of this ugly mess can go and<br>601 * we can just check locks in ->d_revalidate without doing any RPCs<br>602 * ever.<br>603 */<br><br>Best Regards,<br>Tao<br><br><br>_______________________________________________<br>Lustre-discuss mailing list<br><a href="mailto:Lustre-discuss@lists.lustre.org">Lustre-discuss@lists.lustre.org</a><br><a href="http://lists.lustre.org/mailman/listinfo/lustre-discuss" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>