[Linux-ia64] ia32 subsystem in 2.5.67

[Linux-ia64] ia32 subsystem in 2.5.67

[David Mosberger]

It looks like dynamic x86 binaries have a problem once again (or
still).  If I try to run any shared x86 binaries, I get:

	$ ls.x86
	ls.x86: error while loading shared libraries: librt.so.1: cannot map zero-fill pages: Error 14

Would someone take a look?

	--david

Re: [Linux-ia64] ia32 subsystem in 2.5.67

[Arun Sharma]

David Mosberger <davidm@napali.hpl.hp.com> writes:

Hi David,

> It looks like dynamic x86 binaries have a problem once again (or
> still).  If I try to run any shared x86 binaries, I get:
> 
> 	$ ls.x86
> 	ls.x86: error while loading shared libraries: librt.so.1: cannot map zero-fill pages: Error 14
> 
> Would someone take a look?

We saw this behavior with 2.5.59 also. The attached work around should
take care of the problem temporarily. Last time this happened, IA-32
programs were doing mmaps, whose size was one page bigger than the
size of the underlying file (even after rounding up the file size).

I never got a chance to figure out why glibc was doing mmaps with the
"wrong" size. Also, I failed to reproduce the problem with a more
recent (RH 8.0) glibc.

Which version of IA-32 glibc were you using ?

        -Arun

--- linux-2.5.59/arch/ia64/ia32/sys_ia32.c-	Wed Apr 16 13:39:59 2003
+++ linux-2.5.59/arch/ia64/ia32/sys_ia32.c	Wed Apr 16 13:40:15 2003
@@ -245,8 +245,7 @@
 		return -ENOMEM;
 
 	if (old_prot)
-		if (copy_from_user(page, (void *) PAGE_START(start), PAGE_SIZE))
-			return -EFAULT;
+		copy_from_user(page, (void *) PAGE_START(start), PAGE_SIZE);
 
 	down_write(&current->mm->mmap_sem);
 	{

Re: [Linux-ia64] ia32 subsystem in 2.5.67

[David Mosberger]

>>>>> On 16 Apr 2003 14:09:38 -0700, Arun Sharma <arun.sharma@intel.com> said:

  Arun> David Mosberger <davidm@napali.hpl.hp.com> writes:
  Arun> Hi David,

  >> It looks like dynamic x86 binaries have a problem once again (or
  >> still).  If I try to run any shared x86 binaries, I get:
  >> 
  >> $ ls.x86
  >> ls.x86: error while loading shared libraries: librt.so.1: cannot map zero-fill pages: Error 14
  >> 
  >> Would someone take a look?

  Arun> We saw this behavior with 2.5.59 also. The attached work around should
  Arun> take care of the problem temporarily. Last time this happened, IA-32
  Arun> programs were doing mmaps, whose size was one page bigger than the
  Arun> size of the underlying file (even after rounding up the file size).

  Arun> I never got a chance to figure out why glibc was doing mmaps with the
  Arun> "wrong" size. Also, I failed to reproduce the problem with a more
  Arun> recent (RH 8.0) glibc.

Oops, looks like I may have dropped that patch by accident?  I'm
sorry, if so.

  Arun> Which version of IA-32 glibc were you using ?

Huh, good question.  It looks like it's glibc v2.2.5.

	--david

Re: [Linux-ia64] ia32 subsystem in 2.5.67

[Arun Sharma]

Arun Sharma <arun.sharma@intel.com> writes:

> We saw this behavior with 2.5.59 also. The attached work around should
> take care of the problem temporarily. Last time this happened, IA-32
> programs were doing mmaps, whose size was one page bigger than the
> size of the underlying file (even after rounding up the file size).
> 
> I never got a chance to figure out why glibc was doing mmaps with the
> "wrong" size. Also, I failed to reproduce the problem with a more
> recent (RH 8.0) glibc.
> 
> Which version of IA-32 glibc were you using ?

Some more details on the issue:

The problem libc.so.6 binary seems to be the one shipping with Redhat
7.1 IA-32 and Redhat Advanced Server 2.1 IPF (the RPM is named
x86-compat-libs-7.2-1.src.rpm but the SPEC file says the binaries
were copied from Redhat 7.1). I'm yet to look at the source for this
binary. But here are some details:

$ ls -l libc.so.6 
-rwxr-xr-x    1 adsharma adsharma  1282588 Apr 16 16:20 libc.so.6

When run on a IA-32 box, strace shows:

open("/home/adsharma/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\306"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size\x1282588, ...}) = 0
old_mmap(NULL, 1299272, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000
               ^^^^^^^
mprotect(0x4014c000, 37704, PROT_NONE)  = 0
old_mmap(0x4014c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x133000) = 0x4014c000
old_mmap(0x40152000, 13128, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40152000

Since 1299272 > PAGE_END(1282588) copy_from_user fails.

This problem doesn't exist with the libc.so.6 on RH 8.0 and 9.0:

Redhat 8.0:

open("/lib/i686/libc.so.6", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220Y\1"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size\x1395734, ...}) = 0
old_mmap(0x42000000, 1239844, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x42000000

Redhat 9.0:

open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`V\1B4\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size\x1531064, ...}) = 0
old_mmap(0x42000000, 1257224, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x42000000

But it looks like this can happen to DSOs other than libc.so.6. In
your case it seems to have happened with librt.so.1. I still don't
have an answer for why this (map size > file size) happens, but it
seems to be harmless in IA-32 land, but is a problem when we do mmap
sub paging on IPF.

So perhaps the patch I mailed earlier today should be more than a
temporary workaround ;)

        -Arun

Re: [Linux-ia64] ia32 subsystem in 2.5.67

[David Mosberger]

>>>>> On 16 Apr 2003 17:04:10 -0700, Arun Sharma <arun.sharma@intel.com> said:

  Arun> So perhaps the patch I mailed earlier today should be more than a
  Arun> temporary workaround ;)

OK, it's in my tree now.

	--david