All of lore.kernel.org
 help / color / mirror / Atom feed
From: wengang wang <wen.gang.wang@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/1] OCFS2: add spin lock when accessing inode->i_nlink.
Date: Tue, 23 Sep 2008 15:42:35 +0800	[thread overview]
Message-ID: <48D89DEB.70607@oracle.com> (raw)
In-Reply-To: <48D86122.1040209@oracle.com>

Hi,

Tao Ma wrote:
> Hi wengang,
>
> wengang wang wrote:
>> Sunil and Srini,
>>
>> Yes, it's protected by the inode_lock. and thanks for your detail.
>> well, I found a fragment of code in ocfs2_meta_lock_update(),
>>
>> #ifdef OCFS2_DELETE_INODE_WORKAROUND
>>         /* We might as well check this here - since the inode is now
>>          * locked, an up to date view will indicate whether this was
>>          * never actually orphaned -- i_nlink should be zero for an
>>          * orphaned inode. */
>>         spin_lock(&oi->ip_lock);
>>         if (inode->i_nlink &&
>>             oi->ip_flags & OCFS2_INODE_MAYBE_ORPHANED) {
>>                 mlog(0, "Inode %"MLFu64": clearing maybe_orphaned 
>> flag\n",
>>                      oi->ip_blkno);
>>                 oi->ip_flags &= ~OCFS2_INODE_MAYBE_ORPHANED;
>>         }
>>         spin_unlock(&oi->ip_lock);
>> #endif
>>
>> the i_nlink and OCFS2_INODE_MAYBE_ORPHANED flag are checked with the 
>> protection of ip_lock.
>> If ip_lock is needed here, I think it's need as well in my patch.
>>   
> ip_lock here is used to protect the set of ip_flags.
>
my concern is that the two function runs as following in timer order.
process A running in ocfs2_drop_inode() and B running in 
ocfs2_meta_lock_update()

A        if (oi->ip_flags & OCFS2_INODE_MAYBE_ORPHANED) {
C(omment): now inode->i_nlink is not 0.
B        if (inode->i_nlink && oi->ip_flags & OCFS2_INODE_MAYBE_ORPHANED) {
B                mlog(0, "Inode %"MLFu64": clearing maybe_orphaned 
flag\n", oi->ip_blkno);
B                oi->ip_flags &= ~OCFS2_INODE_MAYBE_ORPHANED;
B        }
A                mlog(0, "Inode was orphaned on another node, clearing 
nlink.\n");
A                inode->i_nlink = 0;
A        }

thus, as a result,
1) OCFS2_INODE_MAYBE_ORPHANED is cleared but inode->i_nlink is 0. 
but result we wanted is
2) OCFS2_INODE_MAYBE_ORPHANED is set and i_nlink is 0  or
3) OCFS2_INODE_MAYBE_ORPHANED is cleared and i_nlink is not 0.

well, seems 1) won't happen.
when ocfs2_drop_inode() is running, the inode is with 0 ref count and 
with inode_lock's protect. so other process can't get any ref on this 
inode and so won't run ocfs2_meta_lock_update() on this inode.
so the original code is no problem.
but if it's not in ocfs2_drop_inode(), it's not a good code.

thanks,
wengang.
> Regards,
> Tao
>

      reply	other threads:[~2008-09-23  7:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-22  9:15 [Ocfs2-devel] [PATCH 1/1] OCFS2: add spin lock when accessing inode->i_nlink wangang wang
2008-09-22 21:18 ` Sunil Mushran
2008-09-23  2:16   ` wengang wang
2008-09-23  3:23     ` Tao Ma
2008-09-23  7:42       ` wengang wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48D89DEB.70607@oracle.com \
    --to=wen.gang.wang@oracle.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.