Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Russell King
On Fri, Mar 16, 2007 at 08:01:01PM +0530, Amit K. Arora wrote:
> Attached below is the patch which implements this system call. It has
> been currently implemented and tested on i386, ppc64 and x86_64
> architectures. I am facing some problems while trying to implement this
> on s390, and thus the delay. While I try to get it right on s390(x), we
> thought of posting this patch, so that we can save some time. Parallely
> we will work on getting the patch work on s390, and probably it will
> come as a separate patch.

I suggest reading the very end of arch/arm/kernel/sys_arm.c; I'd rather
avoid adding more and more hacks like that to the kernel if at all
possible.

One solution (already mentioned elsewhere) is that we start avoiding
passing 64-bit arguments and instead pass two 32-bit instead.  This
nicely avoids the alignment restrictions for 64-bit args in ABIs.

(The issue for ARM is that with anything other than the "fd, mode,
offset, len" layout we will have to deal with different ABI argument
layouts, or implement our own wrapper function as done for
sys_arm_sync_file_range.)

I think the problem comes down to "what is the argument layout which
causes the least amount of problems for the complete set of architectures."
For ARM, that's the "fd, mode, offset, len" layout.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Stephen Rothwell
On Sun, 18 Mar 2007 01:38:38 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> On Sat, 17 Mar 2007 15:30:43 +0100 Heiko Carstens <[EMAIL PROTECTED]> wrote:
> >
> > sys_sync_file_range(int fd, loff_t offset, loff_t nbytes, unsigned int 
> > flags)
> >
> > But from what I read, it's currently not possible for 32-bit powerpc to
> > wire up the already present sync_file_range system call.
>
> 32bit native is fine (as the ABI in user mode is the same as that in the

Sorry, I take that back ...

--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpxiqcmQJfN1.pgp
Description: PGP signature


Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Stephen Rothwell
On Sat, 17 Mar 2007 15:30:43 +0100 Heiko Carstens <[EMAIL PROTECTED]> wrote:
>
> sys_sync_file_range(int fd, loff_t offset, loff_t nbytes, unsigned int flags)
>
> But from what I read, it's currently not possible for 32-bit powerpc to
> wire up the already present sync_file_range system call.

32bit native is fine (as the ABI in user mode is the same as that in the
kernel).  For 32bit on a 64bit kernel you need the arch specific comapt
routine that I used in the patch I posteda little while ago,

--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgppHneRn9jnO.pgp
Description: PGP signature


Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Heiko Carstens
On Sat, Mar 17, 2007 at 05:07:06AM -0600, Matthew Wilcox wrote:
> On Sat, Mar 17, 2007 at 08:59:05PM +1100, Paul Mackerras wrote:
> > ... but wouldn't work on 32-bit powerpc. :(  We would end up with a
> > pad argument between fd and offset, giving 7 arguments in all
> > (counting the loff_t's as 2), but we only support 6.
> 
> Ditto mips and parisc.

Can't be. Or: mips supports 7 arguments and parisc doesn't pad.
Otherwise they couldn't have wired up

sys_sync_file_range(int fd, loff_t offset, loff_t nbytes, unsigned int flags)

But from what I read, it's currently not possible for 32-bit powerpc to
wire up the already present sync_file_range system call.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Matthew Wilcox
On Fri, Mar 16, 2007 at 05:17:04PM +0100, Heiko Carstens wrote:
> > +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
> 
> e.g.
> 
> asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len, int mode)
> 
> would work even on s390 ;)

How about:

asmlinkage long sys_fallocate(int fd, int mode, u32 off_low, u32 off_high,
u32 len_low, u32 len_high);

That way we all suffer equally ...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Matthew Wilcox
On Sat, Mar 17, 2007 at 08:59:05PM +1100, Paul Mackerras wrote:
> ... but wouldn't work on 32-bit powerpc. :(  We would end up with a
> pad argument between fd and offset, giving 7 arguments in all
> (counting the loff_t's as 2), but we only support 6.

Ditto mips and parisc.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: forced umount?

2007-03-17 Thread Pekka Enberg

On 3/17/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:

Thanks for the heads up; its good to see that Pekka Enberg's work has
continued.  I actually stumbled onto that line of work earlier while
searching for more info on Tigran Aivazian's forced unmount (badfs)
patches:
http://lwn.net/Articles/192632/


FYI, the revoke implementation have since been changed to follow the
badfs-style approach of the forced unmount patches. However, there are
some problems with the forced unmount patches that are now fixed in
the revoke implementation:

 - You can't use munmap() to take down shared memory mappings because the
   application can accidentally remap something completely different
to that region.
 - The ->f_light bits slow down other fget_light() users and  there's
a race between
   fcheck_files() and set_f_light().
 - The operation can live-lock if a malicious process keeps forking. The revoke
   implementation solves this by revoking in two passes: (1) take
down the descriptors
   and (2) take down the actual inodes.

  Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC][PATCH] sys_fallocate() system call

2007-03-17 Thread Paul Mackerras
Heiko Carstens writes:

> So you either rearrange the parameters or convert the loff_t's to pointers.
> 
> e.g.
> 
> asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len, int mode)
> 
> would work even on s390 ;)

... but wouldn't work on 32-bit powerpc. :(  We would end up with a
pad argument between fd and offset, giving 7 arguments in all
(counting the loff_t's as 2), but we only support 6.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html