All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Oleg Drokin <green@namesys.com>
Cc: linux-kernel@vger.kernel.org, eazgwmir@umail.furryterror.org,
	viro@math.psu.edu, nikita@namesys.com
Subject: Re: [2.4] VFS locking problem during concurrent link/unlink
Date: 16 Jan 2003 11:02:08 -0500	[thread overview]
Message-ID: <1042732927.31100.2205.camel@tiny.suse.com> (raw)
In-Reply-To: <20030116184352.A32192@namesys.com>

On Thu, 2003-01-16 at 10:43, Oleg Drokin wrote:
> Hello!
> 
> On Thu, Jan 16, 2003 at 10:39:41AM -0500, Chris Mason wrote:
> > >    Debugging reiserfs problem that can be demonstrated with script created by
> > >    Zygo Blaxell, I started to wonder if the problem presented is indeed reiserfs
> > >    fault and not VFS.
> > >    Though the Zygo claims script only produces problems on reiserfs, I am trying
> > >    it now myself on ext2 (which will take some time).
> > > 
> > >    Debugging shows that reiserfs_link is sometimes called for inodes whose
> > >    i_nlink is zero (and all corresponding data is deleted already).
> > >    So my current guess of what's going on is this:
> > No, this is a reiserfs bug, since we schedule after doing link checks in
> > reiserfs_link and reiserfs_unlink.  I sent a patch to reiserfs dev a
> > while ago, I'll pull it out of the suse kernel and rediff against
> > 2.4.20.
> 
> Yes we do.
> But on the other hand I've put a check at the beginning of reiserfs_link
> and I am still seeing these links on inodes with i_nlink == 0.

That's because we don't inc the link count in reiserfs_link before we
schedule.  The bug works a little like this:

link count at 1
reiserfs_link: make new directory entry for link, schedule()
reiserfs_unlink: dec link count to zero, remove file stat data
reiserfs_link: inc link count, return thinking the stat data is still
there

All of which leads to expanding chaos as we process this link pointing
to nowhere but still have a valid in ram inode pointing to it.

-chris



  reply	other threads:[~2003-01-16 15:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-16 11:00 [2.4] VFS locking problem during concurrent link/unlink Oleg Drokin
2003-01-16 15:39 ` Chris Mason
2003-01-16 15:43   ` Oleg Drokin
2003-01-16 16:02     ` Chris Mason [this message]
2003-01-16 16:06       ` Nikita Danilov
2003-01-16 16:22         ` Chris Mason
2003-01-16 17:03           ` Oleg Drokin
2003-01-16 17:20             ` Oleg Drokin
2003-01-16 16:07       ` Oleg Drokin

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=1042732927.31100.2205.camel@tiny.suse.com \
    --to=mason@suse.com \
    --cc=eazgwmir@umail.furryterror.org \
    --cc=green@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikita@namesys.com \
    --cc=viro@math.psu.edu \
    /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.