All of lore.kernel.org
 help / color / mirror / Atom feed
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;




      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 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.