From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 Patch] GFS2: rename causes kernel Oops
Date: Thu, 15 Jul 2010 09:18:50 +0100 [thread overview]
Message-ID: <1279181930.2466.1.camel@localhost> (raw)
In-Reply-To: <2006396543.402541279145546994.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
Hi,
That ends the long unbroken run of there being no bugs in the dir
code :( It was good spotting to track that one down and the fix looks
good to me. I've pushed it into the -nmw tree. Thanks for fixing this,
Steve.
On Wed, 2010-07-14 at 18:12 -0400, Bob Peterson wrote:
> Hi,
>
> This patch fixes a kernel Oops in the GFS2 rename code.
>
> The problem was in the way the gfs2 directory code was trying
> to re-use sentinel directory entries.
>
> In the failing case, gfs2's rename function was renaming a
> file to another name that had the same non-trivial length.
> The file being renamed happened to be the first directory
> entry on the leaf block.
>
> First, the rename code (gfs2_rename in ops_inode.c) found the
> original directory entry and decided it could do its job by
> simply replacing the directory entry with another. Therefore
> it determined correctly that no block allocations were needed.
>
> Next, the rename code deleted the old directory entry prior to
> replacing it with the new name. Therefore, the soon-to-be
> replaced directory entry was temporarily made into a directory
> entry "sentinel" or a place holder at the start of a leaf block.
>
> Lastly, it went to re-add the replacement directory entry in
> that leaf block. However, when gfs2_dirent_find_space was
> looking for space in the leaf block, it used the wrong value
> for the sentinel. That threw off its calculations so later
> it decides it can't really re-use the sentinel and therefore
> must allocate a new leaf block. But because it previously decided
> to re-use the directory entry, it didn't waste the time to
> grab a new block allocation for the inode. Therefore, the
> inode's i_alloc pointer was still NULL and it crashes trying to
> reference it.
>
> In the case of sentinel directory entries, the entire dirent is
> reused, not just the "free space" portion of it, and therefore
> the function gfs2_dirent_find_space should use the value 0
> rather than GFS2_DIRENT_SIZE(0) for the actual dirent size.
>
> Fixing this calculation enables the reproducer programs to work
> properly.
>
> Regards,
>
> Bob Peterson
> Red Hat GFS
>
> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
> --
> fs/gfs2/dir.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
> index 8295c5b..26ca336 100644
> --- a/fs/gfs2/dir.c
> +++ b/fs/gfs2/dir.c
> @@ -392,7 +392,7 @@ static int gfs2_dirent_find_space(const struct gfs2_dirent *dent,
> unsigned totlen = be16_to_cpu(dent->de_rec_len);
>
> if (gfs2_dirent_sentinel(dent))
> - actual = GFS2_DIRENT_SIZE(0);
> + actual = 0;
> if (totlen - actual >= required)
> return 1;
> return 0;
prev parent reply other threads:[~2010-07-15 8:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1762987434.402491279145496673.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-07-14 22:12 ` [Cluster-devel] [GFS2 Patch] GFS2: rename causes kernel Oops Bob Peterson
2010-07-15 8:18 ` Steven Whitehouse [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=1279181930.2466.1.camel@localhost \
--to=swhiteho@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).