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:
<[email protected]> (02/06/06 1.537.2.37)
[PATCH] PATCH; make readv/writev SuS compliant
Ivan.
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:
>
> <[email protected]> (02/06/06 1.537.2.37)
> [PATCH] PATCH; make readv/writev SuS compliant
>
> Ivan.
>
> 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.
> 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.
Once upon a time, Ivan Kokshaysky <[email protected]> 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 <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
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.
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;
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 <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
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
On Mon, Jul 01, 2002 at 09:03:53AM -0400, [email protected] 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.
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
Ivan Kokshaysky <[email protected]> writes:
> On Mon, Jul 01, 2002 at 09:03:53AM -0400, [email protected] 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
[email protected]
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.
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? :)
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~
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.