From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: linux-ext4@vger.kernel.org, cmm@us.ibm.com
Subject: Re: [PATCH 1/7] ext4: Introduce le32_t and le16_t
Date: Tue, 25 Sep 2007 16:21:29 +0530 [thread overview]
Message-ID: <46F8E831.1060305@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070925100101.GC6143@schatzie.adilger.int>
Andreas Dilger wrote:
> On Sep 25, 2007 14:41 +0530, Aneesh Kumar K.V wrote:
>> The patches are on top of patch queue. I haven't touched
>> the uid and gid of ext4_inode. Do you think i should
>> change that too ?
>
> You can add a Signed-off-by: Andreas Dilger <adilger@clusterfs.com>
> to those patches. As I suspected there were a number of bugs hiding
> in there. I would also change the uid and gid fields, even if we
> don't suspect any problems now.
>
the primary reason for me not looking at uid gid and file_acl fields are
a) we can mount with option nouid32 and that will look at only the low 16
bits
b) same is true with the gid fields
c) Also i_file_acl. If the creater os is HURD we look at only the low 32 bits.
That means all the pace where we access these fields we have conditional access
That makes it less error prone.
with the changes the code will some what as below
if(!(test_opt (inode->i_sb, NO_UID32))) {
- inode->i_uid |= le16_to_cpu(raw_inode->i_uid_high) << 16;
- inode->i_gid |= le16_to_cpu(raw_inode->i_gid_high) << 16;
+ inode->i_uid = ext4_get_i_uid(raw_inode);
+ inode->i_gid = ext4_get_i_gid(raw_inode);
+ } else {
+ inode->i_uid = ext4_get_i_uid_low(raw_inode);
+ inode->i_gid = ext4_get_i_gid_low(raw_inode);
}
-aneesh
next prev parent reply other threads:[~2007-09-25 10:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-25 9:03 [PATCH 1/7] ext4: Introduce le32_t and le16_t Aneesh Kumar K.V
2007-09-25 9:03 ` [PATCH 2/7] ext4: Convert bg_inode_bitmap and bg_inode_table to new type Aneesh Kumar K.V
2007-09-25 9:03 ` [PATCH 3/7] ext4: Convert s_blocks_count_hi and s_blocks_count to le32_t Aneesh Kumar K.V
2007-09-25 9:03 ` [PATCH 4/7] ext4: Convert s_r_blocks_count[_hi] s_free_blocks_count[_hi] " Aneesh Kumar K.V
2007-09-25 9:03 ` [PATCH 5/7] ext4: Convert ext4_extent.ee_start and ee_start_hi to le32_t and le16_t Aneesh Kumar K.V
2007-09-25 9:03 ` [PATCH 6/7] ext4: Convert ext4_extent_idx.ei_leaf and ei_leaf_hi " Aneesh Kumar K.V
2007-09-25 9:03 ` [PATCH 7/7] ext4: sparse fixes Aneesh Kumar K.V
2007-09-25 9:11 ` [PATCH 1/7] ext4: Introduce le32_t and le16_t Aneesh Kumar K.V
2007-09-25 10:01 ` Andreas Dilger
2007-09-25 10:51 ` Aneesh Kumar K.V [this message]
2007-09-25 13:56 ` Dave Kleikamp
2007-09-25 15:45 ` Aneesh Kumar K.V
2007-09-25 16:02 ` Dave Kleikamp
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=46F8E831.1060305@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@clusterfs.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).