public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: ext2 errors w/2.5.x
Date: Mon, 17 Jun 2002 21:15:46 -0700	[thread overview]
Message-ID: <3D0EB3F2.C128F97C@zip.com.au> (raw)
In-Reply-To: 20020618032544.GM22427@clusterfs.com

Andreas Dilger wrote:
> 
> On Jun 17, 2002  19:56 -0700, David S. Miller wrote:
> > I started seeing these occaisionally on my SMP boxes about a month or
> > two ago, is anyone else seeing something similar?
> >
> > EXT2-fs error (device sd(8,17)): ext2_find_entry: zero-length directory entry
> >
> > Upon reboot e2fsck is forced to run (since the partition is marked as
> > having errors by the kernel) and no problems are discovered.
> >
> > Any clues?
> 
> This would appear to be from accessing a buffer (page) which has not yet
> been read from disk.  Otherwise you would have an error from e2fsck also.
> Andrew has been mucking the most in this area...
> 

Not that, I hope.  Possibly it's the interaction between
block_write_full_pages's memset outside i_size, truncate and lookup.
It took me a ridiculous amount of time to get that "correct", so
it's a suspicion point.   Or possibly locking between lookup and
truncate (rmdir) and/or creat.

Dave, I assume this is with 8k pages and 4k blocks?

Is it repeatable enough to conduct a little experiment?  Like, lock the page
in ext2_find_entry?

--- linux-2.5.22/fs/ext2/dir.c	Wed May 29 11:42:43 2002
+++ 25/fs/ext2/dir.c	Mon Jun 17 20:50:48 2002
@@ -348,6 +348,7 @@ struct ext2_dir_entry_2 * ext2_find_entr
 		char *kaddr;
 		page = ext2_get_page(dir, n);
 		if (!IS_ERR(page)) {
+			lock_page(page);
 			kaddr = page_address(page);
 			de = (ext2_dirent *) kaddr;
 			kaddr += ext2_last_byte(dir, n) - reclen;
@@ -355,6 +356,7 @@ struct ext2_dir_entry_2 * ext2_find_entr
 				if (de->rec_len == 0) {
 					ext2_error(dir->i_sb, __FUNCTION__,
 						"zero-length directory entry");
+					unlock_page(page);
 					ext2_put_page(page);
 					goto out;
 				}
@@ -367,10 +369,12 @@ struct ext2_dir_entry_2 * ext2_find_entr
 		if (++n >= npages)
 			n = 0;
 	} while (n != start);
+	unlock_page(page);
 out:
 	return NULL;
 
 found:
+	unlock_page(page);
 	*res_page = page;
 	ei->i_dir_start_lookup = n;
 	return de;


-

  reply	other threads:[~2002-06-18  4:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-18  2:56 ext2 errors w/2.5.x David S. Miller
2002-06-18  3:25 ` Andreas Dilger
2002-06-18  4:15   ` Andrew Morton [this message]
2002-06-18  4:17     ` David S. Miller

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=3D0EB3F2.C128F97C@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=adilger@clusterfs.com \
    --cc=davem@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox