[RFC,2/3] ARM64: ILP32: use __fsword_t in generic/bits/statfs.h

Message ID 1426674611-26427-3-git-send-email-bamvor.zhangjian@huawei.com
State New, archived
Headers

Commit Message

Zhang Jian(Bamvor) March 18, 2015, 10:30 a.m. UTC
  From: Yang Yingliang <yangyingliang@huawei.com>

Use __fsword_t to make size of struct statfs equal in userspace and kernel.

Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
 sysdeps/unix/sysv/linux/generic/bits/statfs.h | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)
  

Comments

H.J. Lu March 18, 2015, 12:04 p.m. UTC | #1
On Wed, Mar 18, 2015 at 3:30 AM, Zhang Jian(Bamvor)
<bamvor.zhangjian@huawei.com> wrote:
> From: Yang Yingliang <yangyingliang@huawei.com>
>
> Use __fsword_t to make size of struct statfs equal in userspace and kernel.
>

Can you try

https://sourceware.org/ml/libc-alpha/2015-03/msg00591.html
  
Chris Metcalf March 19, 2015, 4:40 p.m. UTC | #2
On 03/18/2015 06:30 AM, Zhang Jian(Bamvor) wrote:
> From: Yang Yingliang<yangyingliang@huawei.com>
>
> Use __fsword_t to make size of struct statfs equal in userspace and kernel.
>
> Signed-off-by: Yang Yingliang<yangyingliang@huawei.com>
> ---
>   sysdeps/unix/sysv/linux/generic/bits/statfs.h | 24 ++++++++++++------------
>   1 file changed, 12 insertions(+), 12 deletions(-)

I don't object to this patch as a cleanup (to match the types used in 
the base Linux statfs.h), but can you tell me why this makes a 
difference to you?  On what asm-generic platform does __SWORD_TYPE != 
__fsword_t ?  My earlier analysis a few minutes ago suggested that was 
true only for alpha and x32, neither of which use the linux/generic code 
in glibc.
  
Pinski, Andrew March 19, 2015, 4:49 p.m. UTC | #3
> On Mar 19, 2015, at 9:40 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> 
>> On 03/18/2015 06:30 AM, Zhang Jian(Bamvor) wrote:
>> From: Yang Yingliang<yangyingliang@huawei.com>
>> 
>> Use __fsword_t to make size of struct statfs equal in userspace and kernel.
>> 
>> Signed-off-by: Yang Yingliang<yangyingliang@huawei.com>
>> ---
>>  sysdeps/unix/sysv/linux/generic/bits/statfs.h | 24 ++++++++++++------------
>>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> I don't object to this patch as a cleanup (to match the types used in the base Linux statfs.h), but can you tell me why this makes a difference to you?  On what asm-generic platform does __SWORD_TYPE != __fsword_t ?  My earlier analysis a few minutes ago suggested that was true only for alpha and x32, neither of which use the linux/generic code in glibc.

Aarch64:ILP32 will use linux/generic and will have SWORD_TYPE != __fsword_t just like x32. Basically this patch set goes on top of my already submitted patch set. 

Thanks,
Andrew

> 
> -- 
> Chris Metcalf, EZChip Semiconductor
> http://www.ezchip.com
>
  
Chris Metcalf March 19, 2015, 4:59 p.m. UTC | #4
On 03/19/2015 12:49 PM, Pinski, Andrew wrote:
>> On Mar 19, 2015, at 9:40 AM, Chris Metcalf<cmetcalf@ezchip.com>  wrote:
>> >
>>> >>On 03/18/2015 06:30 AM, Zhang Jian(Bamvor) wrote:
>>> >>From: Yang Yingliang<yangyingliang@huawei.com>
>>> >>
>>> >>Use __fsword_t to make size of struct statfs equal in userspace and kernel.
>>> >>
>>> >>Signed-off-by: Yang Yingliang<yangyingliang@huawei.com>
>>> >>---
>>> >>  sysdeps/unix/sysv/linux/generic/bits/statfs.h | 24 ++++++++++++------------
>>> >>  1 file changed, 12 insertions(+), 12 deletions(-)
>> >
>> >I don't object to this patch as a cleanup (to match the types used in the base Linux statfs.h), but can you tell me why this makes a difference to you?  On what asm-generic platform does __SWORD_TYPE != __fsword_t ?  My earlier analysis a few minutes ago suggested that was true only for alpha and x32, neither of which use the linux/generic code in glibc.
> Aarch64:ILP32 will use linux/generic and will have SWORD_TYPE != __fsword_t just like x32. Basically this patch set goes on top of my already submitted patch set.

OK, thanks.  But presumably this won't work right, because if you don't 
set __USE_FILE_OFFSET64, and __WORDSIZE == 32, you'll end up injecting 
padding fields that don't belong, via the __field64 macro?

This is basically the issue I just raised in the parallel thread with HJ.
  

Patch

diff --git a/sysdeps/unix/sysv/linux/generic/bits/statfs.h b/sysdeps/unix/sysv/linux/generic/bits/statfs.h
index e2f8c6a..ec06d30 100644
--- a/sysdeps/unix/sysv/linux/generic/bits/statfs.h
+++ b/sysdeps/unix/sysv/linux/generic/bits/statfs.h
@@ -48,18 +48,18 @@ 
 
 struct statfs
   {
-    __SWORD_TYPE f_type;
-    __SWORD_TYPE f_bsize;
+    __fsword_t f_type;
+    __fsword_t f_bsize;
     __field64(__fsblkcnt_t, __fsblkcnt64_t, f_blocks);
     __field64(__fsblkcnt_t, __fsblkcnt64_t, f_bfree);
     __field64(__fsblkcnt_t, __fsblkcnt64_t, f_bavail);
     __field64(__fsfilcnt_t, __fsfilcnt64_t, f_files);
     __field64(__fsfilcnt_t, __fsfilcnt64_t, f_ffree);
     __fsid_t f_fsid;
-    __SWORD_TYPE f_namelen;
-    __SWORD_TYPE f_frsize;
-    __SWORD_TYPE f_flags;
-    __SWORD_TYPE f_spare[4];
+    __fsword_t f_namelen;
+    __fsword_t f_frsize;
+    __fsword_t f_flags;
+    __fsword_t f_spare[4];
   };
 
 #undef __field64
@@ -67,18 +67,18 @@  struct statfs
 #ifdef __USE_LARGEFILE64
 struct statfs64
   {
-    __SWORD_TYPE f_type;
-    __SWORD_TYPE f_bsize;
+    __fsword_t f_type;
+    __fsword_t f_bsize;
     __fsblkcnt64_t f_blocks;
     __fsblkcnt64_t f_bfree;
     __fsblkcnt64_t f_bavail;
     __fsfilcnt64_t f_files;
     __fsfilcnt64_t f_ffree;
     __fsid_t f_fsid;
-    __SWORD_TYPE f_namelen;
-    __SWORD_TYPE f_frsize;
-    __SWORD_TYPE f_flags;
-    __SWORD_TYPE f_spare[4];
+    __fsword_t f_namelen;
+    __fsword_t f_frsize;
+    __fsword_t f_flags;
+    __fsword_t f_spare[4];
   };
 #endif