public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chatterton <chatz@melbourne.sgi.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: corrupted log causes infinite loop at mount
Date: Sun, 15 Oct 2006 15:51:25 +1000	[thread overview]
Message-ID: <4531CC5D.5010705@melbourne.sgi.com> (raw)
In-Reply-To: <452FECFE.5050902@sandeen.net>

Eric,

Eric Sandeen wrote:
> While playing with some filesystem corruption testers, I ran into this.
> 
> http://sandeen.net/xfs.31.img.bz2
> 
> If you try to mount, it gets into xfs_buf_get_noaddr via log replay with
> a len of 0, and I think this causes an infinite loop in the goto:
> 
>  try_again:
>         data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL);
>         if (unlikely(data == NULL))
>                 goto fail_free_buf;
> 
>         /* check whether alignment matches.. */
>         if ((__psunsigned_t)data !=
>             ((__psunsigned_t)data & ~target->bt_smask)) {
>                 /* .. else double the size and try again */
>                 kmem_free(data, malloc_len);
>                 malloc_len <<= 1;
>                 goto try_again;
>         }
> 
> Up the callchain a bit there is an ASSERT that the size is > 0, but of
> course that doesn't help on a non-debug kernel...
> 
> haven't had time to investigate beyond that.
> 
> -Eric
> 

I assume the loop is further up the chain since kmem_alloc should return NULL
when asked to alloc 0. So then the problem also lies further up the chain in
checking for a 0 length before calling down, and/or not assuming we are out of
memory when xfs_buf_get_noaddr fails.

David

-- 
David Chatterton
XFS Engineering Manager
SGI Australia

  reply	other threads:[~2006-10-15  5:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-13 19:46 corrupted log causes infinite loop at mount Eric Sandeen
2006-10-15  5:51 ` David Chatterton [this message]
2006-10-15 14:02   ` Eric Sandeen
2006-10-18  3:47     ` 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=4531CC5D.5010705@melbourne.sgi.com \
    --to=chatz@melbourne.sgi.com \
    --cc=sandeen@sandeen.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox