David Howells | 1 Jul 01:15 2010
Picon

Re: [PATCH 0/3] Extended file stat functions [ver #2]

Andreas Dilger <adilger@...> wrote:

> For the cost of those extra bytes it would definitely save a lot of extra
> complexity in every application packing and unpacking the struct.  At a
> minimum put a 32-bit padding that is zero-filled for now.

Blech.  I'd prefer to just expand the fields to 64-bits.

Note that you can't just arbitrarily pass a raw 64-bit UID, say, back to
vfs_getattr() and expect it to be coped with.  Those stat syscalls that return
32-bit (or even 16-bit) would have to do something with it, and glibc would
have to do something with it.

I think we'd need extra request bits to ask for the longer UID/GID - at which
point the extra result data can be appended and extra capacity in the basic
part of the struct is not required.

> > so perhaps something like:
> > 
> > 	struct xstat_u128 { unsigned long long lsw, msw; };
> > 
> > however, I suspect the kernel will require a bit of reengineering to handle
> > a pgoff_t and loff_t of 128-bits.
>
> Well, not any different from having 32-bit platforms work with two 32-bit
> values for 64-bit offsets today, except that we would be doing this with two
> 64-bit values.

gcc for 32-bit platforms can handle 64-bit numbers.  gcc doesn't handle 128-bit
numbers.
(Continue reading)

H. Peter Anvin | 1 Jul 01:27 2010

Re: [PATCH 0/3] Extended file stat functions [ver #2]

On 06/30/2010 04:15 PM, David Howells wrote:
> 
> gcc for 32-bit platforms can handle 64-bit numbers.  gcc doesn't handle 128-bit
> numbers.
> 

gcc for 64-bit platforms does handle 128-bit numbers, but I don't think
it does on 32-bit platforms.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Howells | 1 Jul 01:36 2010
Picon

[PATCH] Add a pair of system calls to make extended file stats available [ver #3]

Add a pair of system calls to make extended file stats available, including
file creation time, inode version and data version where available through the
underlying filesystem.

[This depends on the previously posted pair of patches to (a) constify a number
 of syscall string and buffer arguments and (b) rearrange AFS's use of
 i_version and i_generation].

The following structures are defined for their use:

	struct xstat_parameters {
		unsigned long long	request_mask;
	};

	struct xstat_dev {
		unsigned int		major, minor;
	};

	struct xstat_time {
		unsigned long long	tv_sec, tv_nsec;
	};

	struct xstat {
		unsigned int		st_mode;
		unsigned int		st_nlink;
		unsigned int		st_uid;
		unsigned int		st_gid;
		struct xstat_dev	st_rdev;
		struct xstat_dev	st_dev;
		struct xstat_time	st_atime;
(Continue reading)

David Howells | 1 Jul 02:15 2010
Picon

Re: [PATCH 0/3] Extended file stat functions [ver #2]

H. Peter Anvin <hpa <at> 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.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Joel Becker | 1 Jul 03:12 2010
Picon

Re: [PATCH 3/3] Add a pair of system calls to make extended file stats available

On Wed, Jun 30, 2010 at 12:29:52AM +0100, David Howells wrote:
> Joel Becker <Joel.Becker@...> wrote:
> 
> > 	The less variable length stuff the better, I think.  At least,
> > for the stuff stat(2) already returns, you should have a fixed-size
> > structure.  Even if I only pass the GIVE_ME_UIDS flag, I don't want to
> > have to deal with the variable size stuff until I've actually asked for
> > esoteric things.  I'll know that the non-UIDS fields are garbage by the
> > fact that I didn't ask for them.
> 
> I was thinking of the fixed length xstat struct plus appendable extensions to
> be defined later.

	I meant this.

Joel

--

-- 

Life's Little Instruction Book #267

	"Lie on your back and look at the stars."

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@...
Phone: (650) 506-8127
Peter Pan | 1 Jul 03:56 2010
Picon

Re: [PATCH] ext2:delete misused ext2_free_blocks

On 07/01/2010 06:57 AM, Dan Carpenter wrote:
> On Wed, Jun 30, 2010 at 06:21:27PM +0800, Peter Pan wrote:
>    
>> if ext2_new_blocks returns error, no blocks need to be freed.
>>
>>      
> Hi Peter,
>
> Your patch isn't right.  The original code is OK as is.
>
> Are you seeing a kernel panic?  Perhaps we can help you fix it.
>    
Oh, I know that the original code is good now.
I didn't see a kernel panic, thank you for your guide.
> regards,
> dan carpenter
>
>    
>> Signed-off-by: Peter Pan<wppan <at> redflag-linux.com>
>> ---
>>   fs/ext2/inode.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
>> index 3675088..f858847 100644
>> --- a/fs/ext2/inode.c
>> +++ b/fs/ext2/inode.c
>>  <at>  <at>  -385,6 +385,8  <at>  <at>  static int ext2_alloc_blocks(struct inode *inode,
>>   	ext2_fsblk_t current_block = 0;
>>   	int ret = 0;
(Continue reading)

H. Peter Anvin | 1 Jul 05:20 2010

Re: [PATCH 0/3] Extended file stat functions [ver #2]

On 06/30/2010 05:15 PM, David Howells wrote:
> H. Peter Anvin <hpa@...> 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.

Andreas Dilger | 1 Jul 06:57 2010
Picon

Re: [PATCH 0/3] Extended file stat functions [ver #2]

On 2010-06-30, at 17:15, David Howells wrote:
> Andreas Dilger <adilger@...> 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 {
                :
                :
(Continue reading)

bugzilla-daemon | 1 Jul 07:04 2010

[Bug 16019] Resume from hibernate corrupts ext4

https://bugzilla.kernel.org/show_bug.cgi?id=16019

--- Comment #38 from Klaus Lichtenwalder <lichtenwalder <at> acm.org>  2010-07-01 05:04:30 ---
I don'r know whether this is related, but one in a while I have a lockup of the
X server. I can move the mouse, and switch to the tty consoles, and log in, but
for a working X I have to reboot. Yesterday I saw in dmesg:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
render error detected, EIR: 0x00000000
[drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting
302900 at 302900)

Klaus

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Arnd Bergmann | 1 Jul 10:09 2010
Picon

Re: [PATCH 0/3] Extended file stat functions [ver #2]

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

Gmane