From: tristan <tristan.ye@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/1] Ocfs2: Add new OCFS2_IOC_INFO ioctl for ocfs2 v7.
Date: Fri, 21 May 2010 17:07:11 +0800 [thread overview]
Message-ID: <4BF64D3F.5030705@oracle.com> (raw)
In-Reply-To: <20100520234955.GD8335@mail.oracle.com>
Joel Becker wrote:
> On Thu, May 20, 2010 at 04:26:43PM -0700, Joel Becker wrote:
>> On Wed, May 19, 2010 at 10:28:55AM +0800, Tristan Ye wrote:
>>> The reason why we need this ioctl is to offer the none-privileged
>>> end-user a possibility to get filesys info gathering.
>>>
>>> We use OCFS2_IOC_INFO to manipulate the new ioctl, userspace passes a
>>> structure to kernel containing an array of request pointers and request
>>> count, such as,
>> This patch fails to build in ia32. Have you tested it there?
>
> I'll be clearer for future reference. Anyone adding or
> modifying code that handles compat pointers needs to compile and test:
>
> 1) A 32bit user program on a 32bit OS.
> 2) A 32bit user program on a 64bit OS with CONFIG_COMPAT set.
> 3) A 64bit user program on a 64bit OS with CONFIG_COMPAT set.
> 4) A 32bit user program on a 64bit OS with CONFIG_COMPAT *not* set.
> 5) A 64bit user program on a 64bit OS with CONFIG_COMPAT *not* set.
>
> Only test (4) should return an error.
> I realize this is a lot of testing, but it only needs to be done
> once. It's only when you are actually touching CONFIG_COMPAT stuff.
That's definitely a MUST!! since I caught another bug running 32bits
application on 64bits kernel, the problem is I didn't make the
'ocfs2_info' structure 64bits aligned, which caused a failure to
recognize this ioctl from a 32bits application. Following is all that
I'm going to change against this issue:
--------------------------------------------------------------------------
struct ocfs2_info {
__u64 oi_requests; /* Array of __u64 pointers to requests */
- __u32 oi_count; /* Number of requests in info_requests */
+ __u64 oi_count; /* Number of requests in info_requests */
};
struct ocfs2_info_request {
@@ -102,34 +102,34 @@ struct ocfs2_info_request {
struct ocfs2_info_clustersize {
struct ocfs2_info_request ic_req;
- __u32 ic_clustersize;
+ __u64 ic_clustersize;
};
struct ocfs2_info_blocksize {
struct ocfs2_info_request ib_req;
- __u32 ib_blocksize;
+ __u64 ib_blocksize;
};
struct ocfs2_info_maxslots {
struct ocfs2_info_request im_req;
- __u16 im_max_slots;
+ __u64 im_max_slots;
};
struct ocfs2_info_label {
struct ocfs2_info_request il_req;
__u8 il_label[OCFS2_MAX_VOL_LABEL_LEN];
-};
+} __attribute__ ((packed));
struct ocfs2_info_uuid {
struct ocfs2_info_request iu_req;
__u8 iu_uuid_str[OCFS2_TEXT_UUID_LEN + 1];
-};
+} __attribute__ ((packed));
struct ocfs2_info_fs_features {
struct ocfs2_info_request if_req;
- __u32 if_compat_features;
- __u32 if_incompat_features;
- __u32 if_ro_compat_features;
+ __u64 if_compat_features;
+ __u64 if_incompat_features;
+ __u64 if_ro_compat_features;
};
--------------------------------------------------------------------------
Adding 'packed' attribute also solves the problem as well, that's why I
made this for ocfs2_info_label and ocfs2_info_uuid to avoid quite a
redundant expansion.
Eventually my latest patch passes all 1-5 tests(bug out at test 4) as
expected, and I'll post it soon ;-)
Tristan.
>
> Joel
>
next prev parent reply other threads:[~2010-05-21 9:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 2:28 [Ocfs2-devel] [PATCH 1/1] Ocfs2: Add new OCFS2_IOC_INFO ioctl for ocfs2 v7 Tristan Ye
2010-05-20 23:26 ` Joel Becker
2010-05-20 23:49 ` Joel Becker
2010-05-21 9:07 ` tristan [this message]
2010-05-21 10:22 ` Joel Becker
2010-05-21 1:30 ` tristan
2010-05-21 2:41 ` Joel Becker
2010-05-21 3:05 ` tristan
-- strict thread matches above, loose matches on Subject: below --
2010-05-11 7:21 [Ocfs2-devel] [PATCH 0/1] Ocfs2: o2info for kernel v7 Tristan Ye
2010-05-11 7:21 ` [Ocfs2-devel] [PATCH 1/1] Ocfs2: Add new OCFS2_IOC_INFO ioctl for ocfs2 v7 Tristan Ye
2010-05-11 20:40 ` Joel Becker
2010-05-18 23:55 ` Joel Becker
2010-05-19 3:03 ` tristan
2010-05-06 8:43 Tristan Ye
2010-05-10 20:01 ` Joel Becker
2010-05-11 2:12 ` tristan
2010-05-11 6:51 ` Joel Becker
2010-04-26 12:17 Tristan Ye
2010-04-27 20:07 ` Sunil Mushran
2010-05-06 1:05 ` Joel Becker
2010-05-06 2:09 ` tristan
2010-04-19 11:00 Tristan Ye
2010-04-19 20:16 ` Sunil Mushran
2010-04-20 2:31 ` tristan
2010-04-20 4:28 ` Sunil Mushran
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=4BF64D3F.5030705@oracle.com \
--to=tristan.ye@oracle.com \
--cc=ocfs2-devel@oss.oracle.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 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.