All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Duane Griffin <duaneg@dghda.com>
Cc: linux-kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [RESEND][PATCH] dir_index: error out instead of BUG on corrupt hash dir limit
Date: Mon, 10 Sep 2007 09:59:28 -0500	[thread overview]
Message-ID: <46E55BD0.30500@redhat.com> (raw)
In-Reply-To: <20070909131933.GA15229@dastardly.plus.com>

Duane Griffin wrote:
> Hi Eric,
> 
> On Fri, Aug 31, 2007 at 09:48:43PM -0500, Eric Sandeen wrote:
>> (resend, this one got lost?  Got an acked-by from Andreas
>> last go-round)
> 
> Sorry I missed this first time around. I came up with a very similar
> fix recently, following a gentoo bug report.  However there are a few
> more asserts later that you aren't currently handling. Below is an
> incremental patch on top of yours that converts them too. 

Ah, good point... I focused a bit too much on the single problem at hand
didn't I.  :)

> Note that one
> of them is in an if (0) block and maybe should be left alone -- what do
> you think?

If it's just there for debug, maybe leaving an assert is ok, to get a
dump & system state etc.  If it is converted, a printk would probably be
good so you know you're falling back, otherwise that extra checking is a
bit pointless if it's silent.

> I tested all the changed code paths, except the if (0) one, using a
> utility that appropriately corrupts ext3 images. 
> The source code is
> attached to the gentoo bug report here:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=183207
> 
> Signed-off-by: Duane Griffin <duaneg@dghda.com>

Looks good, thanks for not ignoring the other asserts.  ;-)  I wonder if
we should fix up all the new error condition printk's a bit to be more
descriptive of the problem at hand; for example, the one I sent should
maybe say:

+		ext3_warning(dir->i_sb, __FUNCTION__,
+			     "Corrupt root limit in dir inode %ld\n", dir->i_ino);

I wanted to leave the word "corrupt" in there, or at least something to
clue in the user that maybe fsck is in order...

Thanks,
-Eric

  reply	other threads:[~2007-09-10 14:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-01  2:48 [RESEND][PATCH] dir_index: error out instead of BUG on corrupt hash dir limit Eric Sandeen
2007-09-01  2:48 ` Eric Sandeen
2007-09-09 13:19 ` Duane Griffin
2007-09-10 14:59   ` Eric Sandeen [this message]
2007-09-10 22:06     ` Duane Griffin
2007-09-10 22:41       ` [PATCH V2] dir_index: error out instead of BUG on corrupt dx dirs Eric Sandeen
2007-09-11  1:35         ` Duane Griffin
2007-09-11  1:42           ` [PATCH V3] " 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=46E55BD0.30500@redhat.com \
    --to=sandeen@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=duaneg@dghda.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.