All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Timothy Shimmin <tes@sgi.com>
Cc: David Chinner <dgc@sgi.com>, xfs@oss.sgi.com
Subject: Re: xfs vs. lockdep
Date: Mon, 09 Oct 2006 21:21:10 -0500	[thread overview]
Message-ID: <452B0396.8060506@sandeen.net> (raw)
In-Reply-To: <C013892BDA68824F76A0474A@boing.melbourne.sgi.com>

Timothy Shimmin wrote:
>> Hence by the time we have the lock here in xfs_ireclaim we have 
>> guaranteed
>> that there are no other outstanding references and no new references
>> can occur. Therefore it should be safe to drop the lock before destroying
>> it.
>>
> Yeah, there really seems like something would be wrong if you can't
> unlock it before destroying it.

I thought so too; if anybody else might catch it post-unlock pre-free, they're 
in for a big surprise anyway :)

> I would have thought you'd need to guarantee that you are the only
> one with access to it before destroying it otherwise there'd be problems :)
> (Which as you say we do)

right.

> This one rings a bell. I seem to recall multiple places where we destroy
> without releasing the lock first.
> And I vaguely remember Nathan mentioning that this was causing grief
> for lockdep:)


Ok, cool.  Want a formal patch or you guys want to just free it up...

         /*
          * Free all memory associated with the inode.
          */
+       xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL);
         xfs_idestroy(ip);

Thanks,

-Eric

  reply	other threads:[~2006-10-10  2:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-09 17:58 xfs vs. lockdep Eric Sandeen
2006-10-09 23:36 ` Vlad Apostolov
2006-10-10  3:06   ` Eric Sandeen
2006-10-10  3:23     ` Vlad Apostolov
2006-10-10  0:47 ` David Chinner
2006-10-10  1:45   ` Timothy Shimmin
2006-10-10  2:21     ` Eric Sandeen [this message]
2006-10-10  4:55       ` Timothy Shimmin
2006-10-10  2:25   ` Eric Sandeen

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=452B0396.8060506@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=dgc@sgi.com \
    --cc=tes@sgi.com \
    --cc=xfs@oss.sgi.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.