2.4.19-rc1 broke OSF binaries on alpha

2.4.19-rc1 broke OSF binaries on alpha

[Ivan Kokshaysky]

Hi Marcelo, Alan,

IIRC, the problem is that BSD and OSF readv/writev(2) manuals
explicitly talked of 32 bit iov_len, thus allowing the application
to pass junk in an upper half of the 64 bit word.
This change broke widely used netscape and acrobat reader,
please revert it until we have a better solution:

<alan@lxorguk.ukuu.org.uk> (02/06/06 1.537.2.37)
	[PATCH] PATCH; make readv/writev SuS compliant

Ivan.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Marcelo Tosatti]

Ivan,

I just backed it on my BK repository.

Please test now.


On Fri, 28 Jun 2002, Ivan Kokshaysky wrote:

> Hi Marcelo, Alan,
>
> IIRC, the problem is that BSD and OSF readv/writev(2) manuals
> explicitly talked of 32 bit iov_len, thus allowing the application
> to pass junk in an upper half of the 64 bit word.
> This change broke widely used netscape and acrobat reader,
> please revert it until we have a better solution:
>
> <alan@lxorguk.ukuu.org.uk> (02/06/06 1.537.2.37)
> 	[PATCH] PATCH; make readv/writev SuS compliant
>
> Ivan.
>

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Alan Cox]

> I just backed it on my BK repository.

Please back it back in. The bug is the Alpha port. Alpha needs its own OSF
readv/writev entry point which masks the top bits.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Ivan Kokshaysky]

On Sat, Jun 29, 2002 at 03:28:50AM +0100, Alan Cox wrote:
> Please back it back in. The bug is the Alpha port. Alpha needs its own OSF
> readv/writev entry point which masks the top bits.

Ouch. The new entry point just because of this?!
Marcelo, if you're going to back in that patch, please apply
the following on the top of it.

Ivan.

--- linux/fs/read_write.c.ac	Fri Jun 28 11:52:59 2002
+++ linux/fs/read_write.c	Sun Jun 30 03:21:52 2002
@@ -260,7 +260,15 @@ static ssize_t do_readv_writev(int type,
 	ret = -EINVAL;
 	for (i = 0 ; i < count ; i++) {
 		ssize_t tmp = tot_len;
+#ifdef	__alpha__
+		/* Current versions of Tru64 unix are SuS compliant.
+		   Unfortunately, we have to use the binaries (namely
+		   Netscape and Acrobat Reader) compiled vs. older
+		   versions of OSF/1, where iov_len was a 32 bit integer. */
+		ssize_t len = (int) iov[i].iov_len;
+#else
 		ssize_t len = (ssize_t) iov[i].iov_len;
+#endif
 		if (len < 0)	/* size_t not fitting an ssize_t .. */
 			goto out;
 		tot_len += len;

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

Hi Ivan, Alan, Marcelo,

On Sun, Jun 30, 2002 at 03:50:58AM +0400, Ivan Kokshaysky wrote:
> On Sat, Jun 29, 2002 at 03:28:50AM +0100, Alan Cox wrote:
> > Please back it back in. The bug is the Alpha port. Alpha needs its own OSF
> > readv/writev entry point which masks the top bits.
> 
> Ouch. The new entry point just because of this?!
> Marcelo, if you're going to back in that patch, please apply
> the following on the top of it.

This patch indeed makes acroread & netscape work again on my alpha. Nice
spotting.
Don't we know about the type of binary? (Like personality ...)
So we could use something like
   ssize_t len
 #ifdef __alpha__
   if (current->personality == DEC_OSF_OLD)
     len = (int) iov[i].iov_len;
   else
     len = (ssize_t) iov[i].iov_len;
 #else
   len = (ssize_t) iov[i].iov_len;
 #endif

Not really beautiful, but working for all cases.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Jeff Garzik]

Kurt Garloff wrote:
> Hi Ivan, Alan, Marcelo,
> 
> On Sun, Jun 30, 2002 at 03:50:58AM +0400, Ivan Kokshaysky wrote:
> 
>>On Sat, Jun 29, 2002 at 03:28:50AM +0100, Alan Cox wrote:
>>
>>>Please back it back in. The bug is the Alpha port. Alpha needs its own OSF
>>>readv/writev entry point which masks the top bits.
>>
>>Ouch. The new entry point just because of this?!
>>Marcelo, if you're going to back in that patch, please apply
>>the following on the top of it.
> 
> 
> This patch indeed makes acroread & netscape work again on my alpha. Nice
> spotting.
> Don't we know about the type of binary? (Like personality ...)
> So we could use something like
>    ssize_t len
>  #ifdef __alpha__
>    if (current->personality == DEC_OSF_OLD)
>      len = (int) iov[i].iov_len;
>    else
>      len = (ssize_t) iov[i].iov_len;
>  #else
>    len = (ssize_t) iov[i].iov_len;
>  #endif
> 
> Not really beautiful, but working for all cases.


That's a good point.

FWIW we have Mozilla 1.0.x working just fine on Alpha, so I don't mind 
second-classing, or making optional, OSF/1 binary support.

It _should_ be possible to correctly support SuSv3 and OSF/1 binaries 
simultaneously.

	Jeff

Re: 2.4.19-rc1 broke OSF binaries on alpha

[jlnance]

On Sun, Jun 30, 2002 at 03:50:58AM +0400, Ivan Kokshaysky wrote:
> +#ifdef	__alpha__
> +		/* Current versions of Tru64 unix are SuS compliant.
> +		   Unfortunately, we have to use the binaries (namely
> +		   Netscape and Acrobat Reader) compiled vs. older
> +		   versions of OSF/1, where iov_len was a 32 bit integer. */
> +		ssize_t len = (int) iov[i].iov_len;
> +#else

So how does Tru64 handle this?  It must have some way of knowing whether to
mask the high bits or not.  If the comment above is correct then this patch
breaks new Tru64 binaries.

Jim

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Ivan Kokshaysky]

On Mon, Jul 01, 2002 at 09:03:53AM -0400, jlnance@intrex.net wrote:
> So how does Tru64 handle this?  It must have some way of knowing whether to
> mask the high bits or not.

No idea. Not sure if it handles this at all. Maybe you
just have to recompile.

> If the comment above is correct then this patch
> breaks new Tru64 binaries.

Last time I checked Tru64 v5.0 and above binaries didn't worked
under Linux for other reasons (missing libraries or something like that).

Ivan.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Måns Rullgård]

Ivan Kokshaysky <ink@jurassic.park.msu.ru> writes:

> On Mon, Jul 01, 2002 at 09:03:53AM -0400, jlnance@intrex.net wrote:
> > So how does Tru64 handle this?  It must have some way of knowing whether to
> > mask the high bits or not.
> 
> No idea. Not sure if it handles this at all. Maybe you
> just have to recompile.
> 
> > If the comment above is correct then this patch
> > breaks new Tru64 binaries.
> 
> Last time I checked Tru64 v5.0 and above binaries didn't worked
> under Linux for other reasons (missing libraries or something like that).

Using the libraries from the tru64 5.0 install CD works fine for
running programs on that CD. There does seem to be some problems with
different library versions, though. Matlab 5 would not run with libc
from the tru64 5.0 CD. I had to get some other ones. With the right
libraries Matlab runs fine with both 2.4.19-rc1 and earlier.

-- 
Måns Rullgård
mru@users.sf.net

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Ivan Kokshaysky]

On Mon, Jul 01, 2002 at 09:40:48PM +0200, MЕns RullgЕrd wrote:
> Using the libraries from the tru64 5.0 install CD works fine for
> running programs on that CD. There does seem to be some problems with
> different library versions, though. Matlab 5 would not run with libc
> from the tru64 5.0 CD. I had to get some other ones. With the right
> libraries Matlab runs fine with both 2.4.19-rc1 and earlier.

Unfortunately the libraries _officially_ available for linux are
from v4. If HP would release something more up to date, the alpha
iov_len hack would go away.
It looks like in the Tru64 v5 readv/writev compatibility issues
are solved on the libc level. Default (SuS compliant) functions
are _Ereadv/_Ewritev, and readv/writev are just wrappers (clearing
top 32 bits of iov_len) for old binaries.

Ivan.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Richard Henderson]

On Tue, Jul 02, 2002 at 07:05:44PM +0400, Ivan Kokshaysky wrote:
> Unfortunately the libraries _officially_ available for linux are
> from v4. If HP would release something more up to date, the alpha
> iov_len hack would go away.

Do we have any way of recognizing v4 vs v5 binaries?  I don't think
we do.  I'd be willing to call any ECOFF binary an OSF binary, and
ignore the fact that Linux used them in the distant past.

The minimum correct solution is to add a PER_OSF4 to personality.h
and put an osf_readv and osf_writev that, if PER_OSF4, read and frob
the data into kernel buffers and pass that on to the regular syscalls.


r~

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Ivan Kokshaysky]

On Tue, Jul 02, 2002 at 04:13:22PM -0700, Richard Henderson wrote:
> Do we have any way of recognizing v4 vs v5 binaries?  I don't think
> we do.

Indeed. I've specially looked for this yesterday, and it seems that             
we don't.                                                                       

> I'd be willing to call any ECOFF binary an OSF binary, and
> ignore the fact that Linux used them in the distant past.

Totally acceptable, I think.

> The minimum correct solution is to add a PER_OSF4 to personality.h
> and put an osf_readv and osf_writev that, if PER_OSF4, read and frob
> the data into kernel buffers and pass that on to the regular syscalls.

It would be excellent.

Ivan.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Alan Cox]

> IIRC, the problem is that BSD and OSF readv/writev(2) manuals
> explicitly talked of 32 bit iov_len, thus allowing the application
> to pass junk in an upper half of the 64 bit word.
> This change broke widely used netscape and acrobat reader,
> please revert it until we have a better solution:

Please fix the Alpha port. The behaviour fixed is _required_ by SuS.
Make your own alpha syscall that handles this crap.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Ivan Kokshaysky]

On Sat, Jun 29, 2002 at 03:26:18AM +0100, Alan Cox wrote:
> Please fix the Alpha port. The behaviour fixed is _required_ by SuS.

No objections, but
a) it wasn't a bugfix (just a compliance crap)
b) it seriously broke the alpha port right before the new
   kernel release.

> Make your own alpha syscall that handles this crap.

I'd be happy to see that patch included in 2.4.20-pre1.

Ivan.

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Marcelo Tosatti]

On Sun, 30 Jun 2002, Ivan Kokshaysky wrote:

> On Sat, Jun 29, 2002 at 03:26:18AM +0100, Alan Cox wrote:
> > Please fix the Alpha port. The behaviour fixed is _required_ by SuS.
>
> No objections, but
> a) it wasn't a bugfix (just a compliance crap)
> b) it seriously broke the alpha port right before the new
>    kernel release.
>
> > Make your own alpha syscall that handles this crap.
>
> I'd be happy to see that patch included in 2.4.20-pre1.

Actually I asked Richard Henderson at OLS if he could do the alpha syscall
do the stuff for -rc2.

I really don't like that "#ifdef alpha" stuff in generic code.

Richard? :)

Re: 2.4.19-rc1 broke OSF binaries on alpha

[Chris Adams]

Once upon a time, Ivan Kokshaysky  <ink@jurassic.park.msu.ru> said:
>IIRC, the problem is that BSD and OSF readv/writev(2) manuals
>explicitly talked of 32 bit iov_len, thus allowing the application
>to pass junk in an upper half of the 64 bit word.
>This change broke widely used netscape and acrobat reader,
>please revert it until we have a better solution:

The Tru64 4.0G and 5.1A man pages say that if the sum of the iov_len
values is negative or overflows a 32 bit integer that EINVAL will be
returned, but I think this is only for the backwards compatible
interface where iov_len was defined as int.  It is now defined as size_t
and the rest of the man page never says anything about a 32 bit iov_len
and the upper half being ignored.
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.