From: Marko Kreen <marko@l-t.ee>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH] ext2 cpu<->le32 thinkos? (-test10)
Date: Wed, 8 Nov 2000 19:02:02 +0200 [thread overview]
Message-ID: <20001108190201.A4637@l-t.ee> (raw)
Reading ext2 code I found some inconsistencies
in endianess handling, could anyone comment
on this?
Also there is a unnecessary RDONLY check.
I understand that it happens to work anyway
but they confuse understanding.
Or am I missing something?
--
marko
diff -urNX /home/marko/misc/diff-exclude fs/ext2.orig/ialloc.c fs/ext2/ialloc.c
--- fs/ext2.orig/ialloc.c Fri Oct 6 22:49:00 2000
+++ fs/ext2/ialloc.c Wed Nov 8 10:09:23 2000
@@ -399,11 +399,6 @@
ext2_error (sb, "ext2_new_inode",
"Free inodes count corrupted in group %d",
i);
- if (sb->s_flags & MS_RDONLY) {
- unlock_super (sb);
- iput (inode);
- return NULL;
- }
gdp->bg_free_inodes_count = 0;
mark_buffer_dirty(bh2);
}
diff -urNX /home/marko/misc/diff-exclude fs/ext2.orig/namei.c fs/ext2/namei.c
--- fs/ext2.orig/namei.c Wed Nov 1 20:31:30 2000
+++ fs/ext2/namei.c Wed Nov 8 13:46:20 2000
@@ -242,7 +242,7 @@
de = (struct ext2_dir_entry_2 *) bh->b_data;
de->inode = 0;
- de->rec_len = le16_to_cpu(sb->s_blocksize);
+ de->rec_len = cpu_to_le16(sb->s_blocksize);
dir->i_size = offset + sb->s_blocksize;
dir->u.ext2_i.i_flags &= ~EXT2_BTREE_FL;
mark_inode_dirty(dir);
@@ -750,7 +750,7 @@
if (retval)
goto end_rename;
} else {
- new_de->inode = le32_to_cpu(old_inode->i_ino);
+ new_de->inode = cpu_to_le32(old_inode->i_ino);
if (EXT2_HAS_INCOMPAT_FEATURE(new_dir->i_sb,
EXT2_FEATURE_INCOMPAT_FILETYPE))
new_de->file_type = old_de->file_type;
@@ -785,7 +785,7 @@
old_dir->u.ext2_i.i_flags &= ~EXT2_BTREE_FL;
mark_inode_dirty(old_dir);
if (dir_bh) {
- PARENT_INO(dir_bh->b_data) = le32_to_cpu(new_dir->i_ino);
+ PARENT_INO(dir_bh->b_data) = cpu_to_le32(new_dir->i_ino);
mark_buffer_dirty(dir_bh);
old_dir->i_nlink--;
mark_inode_dirty(old_dir);
diff -urNX /home/marko/misc/diff-exclude fs/ext2.orig/super.c fs/ext2/super.c
--- fs/ext2.orig/super.c Fri Oct 6 22:49:00 2000
+++ fs/ext2/super.c Wed Nov 8 10:08:22 2000
@@ -101,7 +101,7 @@
int i;
if (!(sb->s_flags & MS_RDONLY)) {
- sb->u.ext2_sb.s_es->s_state = le16_to_cpu(sb->u.ext2_sb.s_mount_state);
+ sb->u.ext2_sb.s_es->s_state = cpu_to_le16(sb->u.ext2_sb.s_mount_state);
mark_buffer_dirty(sb->u.ext2_sb.s_sbh);
}
db_count = sb->u.ext2_sb.s_db_per_group;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2000-11-08 16:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-08 17:02 Marko Kreen [this message]
2000-11-08 17:55 ` Andreas Dilger
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=20001108190201.A4637@l-t.ee \
--to=marko@l-t.ee \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®