lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1184185957.6471.2.camel@localhost>
Date:	Wed, 11 Jul 2007 22:32:36 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Theodore Tso <tytso@....edu>, Paul Mackerras <paulus@...ba.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org,
	Amit Arora <aarora@...ibm.com>, Andi Kleen <ak@...e.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Luck, Tony" <tony.luck@...el.com>,
	Mark Fasheh <mark.fasheh@...cle.com>,
	linux-arch@...r.kernel.org
Subject: Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

On Wed, 2007-07-11 at 20:47 +0200, Heiko Carstens wrote:
> > There were a number of folks who preferred having int fd first, and I
> > *thought* Amit had gotten agreement from either Martin or Heiko that
> > it was ok to do this as an exception, even though it was extra work
> > for that arch.  But if not, we can try going back the second
> > alternative, or even the 6 32-bits args (off_high, off_low, len_high,
> > len_low) approach, but I think that drew even more fire. 
> 
> The second approach would work for all architectures..  but some people
> didn't like (no technical reason) not having fd as first argument.

For s390 we would have liked the second approach with the two int's as
last arguments since it would avoid the wrapper in the kernel. It does
not avoid the wrapper in user space since the call uses 6 register on 31
bit. So the fallocate call need special treatement in glibc so I don't
mind that it needs another wrapper in the kernel.

> Just go ahead with the current approach. s390 seems to be the only
> architecture which suffers from this and I wouldn't like to start this
> discussion again.

Yes, don't worry about s390 for fallocate, the patch that had been in
-mm only had an incorrect system call number. The wrapper is fine.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ