From: tytso@mit.edu
To: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Cc: adilger@sun.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH][BUG][TAKE2] ext4: unify each meaning of the offset in ext4_check_dir_entry calling from some functions.
Date: Tue, 2 Mar 2010 00:22:57 -0500 [thread overview]
Message-ID: <20100302052257.GE6077@thunk.org> (raw)
In-Reply-To: <20100203161348.0bf98d58.toshi.okajima@jp.fujitsu.com>
On Wed, Feb 03, 2010 at 04:13:48PM +0900, Toshiyuki Okajima wrote:
> From: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
>
> "offset" of the error message of ext4_check_dir_entry() might change the
> meaning by the caller. There are 2 meanings:
> - "File offset"
> called by:
> ext4_readdir, htree_dirblock_to_tree, search_dirblock, ext4_dx_find_entry,
> empty_dir
> - "Buffer offset"
> called by:
> add_dirent_to_buf, ext4_delete_entry
>
> The best way to solve this problem is to change the meaning of
> "Buffer offset" into "File offset" but it is not easy.
It would be desirable for this to be made consistent, but a physical
block number plus the buffer offset is actually much less useful for
someone trying to find the bad directory entry.
So what I've checked into the ext4 patch queue prints both the
physical block nubmer and the relative offset, as well as the
passed-in offset which in many cases is the file offset.
- Ted
commit e5a2233178ebf8b6538dc19a0dcf721d11590ea0
Author: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Date: Tue Mar 2 00:21:35 2010 -0500
ext4: make "offset" consistent in ext4_check_dir_entry()
The callers of ext4_check_dir_entry() usually pass in the "file
offset" (ext4_readdir, htree_dirblock_to_tree, search_dirblock,
ext4_dx_find_entry, empty_dir), but a few callers (add_dirent_to_buf,
ext4_delete_entry) only pass in the buffer offset.
To accomodate those last two (which would be hard to fix otherwise),
this patch changes ext4_check_dir_entry() to print the physical block
number and the relative offset as well as the passed-in offset.
Signed-off-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index 0e0bef3..29857dd 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -84,9 +84,11 @@ int ext4_check_dir_entry(const char *function, struct inode *dir,
if (error_msg != NULL)
__ext4_error(dir->i_sb, function,
- "bad entry in directory #%lu: %s - "
- "offset=%u, inode=%u, rec_len=%d, name_len=%d",
- dir->i_ino, error_msg, offset,
+ "bad entry in directory #%lu: %s - block=%llu"
+ "offset=%u(%u), inode=%u, rec_len=%d, name_len=%d",
+ dir->i_ino, error_msg,
+ (unsigned long long) bh->b_blocknr,
+ (unsigned) (offset%bh->b_size), offset,
le32_to_cpu(de->inode),
rlen, de->name_len);
return error_msg == NULL ? 1 : 0;
prev parent reply other threads:[~2010-03-02 5:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-03 7:13 [PATCH][BUG][TAKE2] ext4: unify each meaning of the offset in ext4_check_dir_entry calling from some functions Toshiyuki Okajima
2010-03-02 5:22 ` tytso [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=20100302052257.GE6077@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=toshi.okajima@jp.fujitsu.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).