From: H. Peter Anvin on
On 06/30/2010 05:15 PM, David Howells wrote:
> H. Peter Anvin <hpa(a)zytor.com> wrote:
>
>> gcc for 64-bit platforms does handle 128-bit numbers, but I don't think
>> it does on 32-bit platforms.
>
> How do you specify them? If I say "long long long" gcc moans that it can't
> support it on x86_64.
>

__int128

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andreas Dilger on
On 2010-06-30, at 17:15, David Howells wrote:
> Andreas Dilger <adilger(a)dilger.ca> wrote:
>>> Passing -1 (or ULONGLONG_MAX) to get everything would be reasonable.
>>
>> NOOOO. That is exactly what we _don't_ want, since it makes it impossible
>> for the kernel to actually understand which fields the application is ready
>> to handle. If the application always uses XSTAT_QUERY_ALL, instead of "-1",
>> then the kernel can easily tell which fields are present in the userspace
>> structure, and what it should avoid touching.
>>
>> If applications start using "-1" to mean "all fields", then it will work so
>> long as the kernel and userspace agree on the size of struct xstat, but as
>> soon as the kernel understands some new field, but userspace does not, the
>> application will segfault or clobber random memory because the kernel thinks
>> it is asking for XSTAT_QUERY_NEXT_NEW_FIELD|... when it really isn't asking
>> for that at all.
>
> As long as the field bits allocated in order and the extra results are tacked
> on in bit number order, will it actually be a problem? Userspace must know how to deal with all the bits up to the last one it knows about; anything beyond that is irrelevant.

The patch you sent seems to get this right, but just for completeness, I'll answer in this thread. Using the new struct as an example:

#define XSTAT_REQUEST_GEN 0x00001000ULL
#define XSTAT_REQUEST_DATA_VERSION 0x00002000ULL

struct xstat {
:
:
unsigned long long st_data_version;
unsigned long long st_result_mask;
unsigned long long st_extra_results[0];
}

An app "today" would allocate a struct xstat that ends at st_result_mask, and "today's" kernel will not know anything about flags beyond *_DATA_VERSION. Even if today's app incorrectly uses request_mask = ~0ULL nothing will break until the kernel code changes.

If a future kernel gets a new static field at st_extra_results (say unsigned long long st_ino_high) with a new flag XSTAT_REQUEST_INO_HIGH 0x000040000ULL the kernel will think that the old app is requesting this field, and will fill in the 64-bit field at st_extra_results[1] (which the old app didn't allocate space for, nor does it understand) and may get a segfault, or stack smashing, or random heap corruption.

> What would you have me do? Return an error if a request is made that the
> kernel doesn't support? That's bad too. This can be handled simply by
> clearing the result bit for any unsupported field.

I agree the desirable behaviour is if an app correctly sets request_mask at most to XSTAT_REQUEST__ALL_STATS 0x00003fffULL (or whatever it is at the time the app is compiled that matches the current struct xstat), and if the kernel understands e.g. XSTAT_REQUEST_INO_HIGH or not is irrelevant since the kernel will not touch fields that are not requested. Likewise, if the application is compiled with a newer/larger XSTAT_REQUEST__ALL_STATS mask than what the kernel understands, the kernel will ignore the flags it doesn't understand.


Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on
On Thursday 01 July 2010 06:57:07 Andreas Dilger wrote:
> If a future kernel gets a new static field at st_extra_results (say
> unsigned long long st_ino_high) with a new flag XSTAT_REQUEST_INO_HIGH
> 0x000040000ULL the kernel will think that the old app is requesting
> this field, and will fill in the 64-bit field at st_extra_results[1]
> (which the old app didn't allocate space for, nor does it understand)
> and may get a segfault, or stack smashing, or random heap corruption.

That depends on whether the struct contains a 'buflen' field or not
(it may be part of the struct, as a syscall argument, or in a second struct).
I argue that it should not contain a buflen field and that users should
consequently not set bits that they don't know about to prevent the
scenario you describe.

If the buflen stays in, it will prevent the stack smashing part,
but add extra complexity in the interface, which can cause other
problems.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Brad Boyer on
On Wed, Jun 30, 2010 at 02:16:56AM +0100, David Howells wrote:
> struct xstat {
> unsigned int struct_version;
> #define XSTAT_STRUCT_VERSION 0
> unsigned int st_mode;
> unsigned int st_nlink;
> unsigned int st_uid;
> unsigned int st_gid;
> unsigned int st_blksize;
> struct xstat_dev st_rdev;
> struct xstat_dev st_dev;
> unsigned long long st_ino;
> unsigned long long st_size;
> struct xstat_time st_atime;
> struct xstat_time st_mtime;
> struct xstat_time st_ctime;
> struct xstat_time st_btime;
> unsigned long long st_blocks;
> unsigned long long st_gen;
> unsigned long long st_data_version;
> unsigned long long query_flags;
> #define XSTAT_QUERY_SIZE 0x00000001ULL
> #define XSTAT_QUERY_NLINK 0x00000002ULL
> #define XSTAT_QUERY_AMC_TIMES 0x00000004ULL
> #define XSTAT_QUERY_CREATION_TIME 0x00000008ULL
> #define XSTAT_QUERY_BLOCKS 0x00000010ULL
> #define XSTAT_QUERY_INODE_GENERATION 0x00000020ULL
> #define XSTAT_QUERY_DATA_VERSION 0x00000040ULL
> #define XSTAT_QUERY__ORDINARY_SET 0x00000017ULL
> #define XSTAT_QUERY__GET_ANYWAY 0x0000007fULL
> #define XSTAT_QUERY__DEFINED_SET 0x0000007fULL
> unsigned long long extra_results[0];
> };

Would it be worthwhile to have a field for which security features are
enabled for a file? Maybe with bits for if the file has ACLs (and which
type if the richacl code goes in) or for the selinux labels or other
similar types of data? The current version of ls I have does a huge
pile of getxattr calls along with all the lstat64 calls.

Brad Boyer
flar(a)allandria.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/