Re: [PATCH] Fix blktrace setup 32-bit ioctl on 64-bit kernels

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jens Axboe <jens.axboe@...>
Cc: <linux-kernel@...>, <abhishekrai@...>, Linus Torvalds <torvalds@...>
Date: Tuesday, October 2, 2007 - 4:15 am

On Tuesday 02 October 2007, Jens Axboe wrote:

actually, I would guess that it is currently working on s390, sparc64,
powerpc, parisc and mips, but your patch breaks it :(.


I'd prefer to not add anything to fs/compat_ioctl.c at all, but always
handle these in the places where the native version is handled.

In your case, I'd either mark BLKTRACESETUP32 as COMPATIBLE_IOCTL() and
handle it from inside of blk_trace_ioctl(), or handle it in
compat_blkdev_ioctl.


Errm, no. Everyone makes that mistake once, so you're in good company,
but the packed attribute makes this incorrect on every architecture
except x86_64 and ia64, because only i386 has no padding before the u64
and after the last member.

We now have the compat_u64 type that behaves like the 32 bit user space
version of an unsigned long long. If you use that to define 
compat_blk_user_trace_setup, you don't need the attribute.


The naming convention these days is to use a 'compat_' prefix, not a '32'
postfix.


Most of these fields are read-only for the kernel, so you should only need
the first copy_to_user. I think you should split the blk_trace_setup function
to have the common code take a struct blk_user_trace_setup kernel pointer,
and one or two versions that just do the copy_{to,from}_user.

	Arnd <><
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] Fix blktrace setup 32-bit ioctl on 64-bit kernels, Arnd Bergmann, (Tue Oct 2, 4:15 am)