Very Computer

In previous version of redhat (7.x) one could modify the value
for TASK_UNMAPPED_BASE and all the .so libraries
would load in order starting at the value specified (in mm/mmap.c).

Now, it seems that r.h. 8.0 has done something to the libc shared
library, so it loads in at 0x4200_0000. Thus if you change
TASK_UNMAPPED_BASE to be, say, 0xa000_0000 all the
other libraries will  start their load at 0xa000_0000 but  clib
still loads in at 0x4200_0000.

Since this leaves virtual memory fragmented, it is impossible to
allocate the  2.5 gigs of contiguous space my app needs, even
with a kernel patch.

So, does anyone know how to* this problem. Say, is there a
way to modify the clib.so to load at a different offset.

Or, does this mean that redhat built a clib that is not reloacatable?

I am not familiar with all the ld options. Is there a way to build the
clib from sources and specify the load address?

In fact, is there a way to modify .so files to "patch" in the starting
location?

thx
eric

IIRC, we had a discussion on this ng (or .apps, or possibly c.u.p.)
about this very thing about 2 weeks ago.  Check the history, I'm
sure it'll turn up.

--
 josh(at)intmain.net  |  http://www.veryComputer.com/

 130427 local keystrokes since last reboot (25 days ago)

maybe you can patch the so's so that they jmp to a different address of
memory, then tell them to free the previously allocated memory at the
pre-jmp point.

Nobu_Chaotix

 > Now, it seems that r.h. 8.0 has done something to the libc shared
 > library, so it loads in at 0x4200_0000

Yes, it is called "prelinking", and often it is a good idea because it reduces
application startup time by pre-selecting p_vaddr and doing most relocations
at build time instead of at runtime.  The Windows analog is "rebase".

 > So, does anyone know how to* this problem. Say, is there a
 > way to modify the clib.so to load at a different offset.

Get the glibc src rpm, install it, find the 0x42000000, change it to a better
value (such as 0x07800000 [120MB]), rebuild, install the binaries [be careful].
Or, disable prelinking entirely; it is an "add on" step.

 > Or, does this mean that redhat built a clib that is not reloacatable?

It is relocatable, but the runtime loader ld-linux.so.2 will leave it alone
at 0x42000000 unless other shlibs (loaded before glibc) overlap.  If overlap,
then glibc is relocated so that the process does not fail for this reason.

 > In fact, is there a way to modify .so files to "patch" in the starting
 > location?

It's not that simple.  In general, there are address constants that require
relocation before instructions from the .so are executed.

Last time the poster could tell us that this change happened
between 7.2 and 7.3. It turned out that with 7.3 the simplest
workaround would be to install the i386 version of glibc
instead of the i686 version. If you want a better solution,
you will have to grab the source rpm, modify the spec file,
and build a new rpm file.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

Don't do this at home kids: touch -- -rf

It is now in the faq:
http://www.veryComputer.com/~kasperd/comp.os.linux.development.faq.html#42...

--
Kasper Dupont -- der bruger for meget tid p? usenet.

Don't do this at home kids: touch -- -rf

Ahhh, I think I remember you. I found your patches to implement
a per process version of TASK_UNMAPPED_BASE, and was wondering
if this might make it into the "official" release.

I had once submitted a "system wide" version of this idea, but it was not
accepted. When newer linux kernels were released, my patch no
longer worked, and I did not have the time to keep upgrading it.

In my case, I have some control on the linking of my executable. It is
built with a runtime library that I don't have source to, and that is
where the need for the contiguous memory comes into play. I was
thinking I could link against a clib.a since all the other libraries will
still load releative to TASK_UNMAPPED_BASE.

We are probably within a year or two of 64 bit needs anyway, but
that requires a new proprietary compiler, so we will have squeeze out
all 32 bits worths of address space for a while.

And if I got it correct, we should be able to get another 1/4 gig using
the AMD Hammer in 32 bit mode. I read where it's compatibility
mode lets a 32 bit process use all 4 gigs since the 64-bit-kernel would
use space outside the 32 bit space of these sorts of legacy processes.

Thanks
Eric

I haven't tried to get it into an official release. I will
verify if it still applies against latest 2.4 kernels, and
put up a patch for 2.4.19 or 2.4.20. However I don't have
any system for intensive testing of the patch. I have just
verified that I could use the patch without crashing my
system. And I looked in /proc/%d/maps files to see if it
looked correct. I don't have so much memory that it really
makes a difference to me.

But if those who have tried the patch will provide some
feedback, I might consider sending it to the kernel
mailing list.

I'd like feedback from anybody who are using the patch,
and also anybody whom the patch has not helped.

Quote:

> And if I got it correct, we should be able to get another 1/4 gig using
> the AMD Hammer in 32 bit mode. I read where it's compatibility
> mode lets a 32 bit process use all 4 gigs since the 64-bit-kernel would
> use space outside the 32 bit space of these sorts of legacy processes.

I hope you are right. It does sound likely to me. At least
in any sane design I can think of you will be right.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

Don't do this at home kids: touch -- -rf

I took a look at the patch file dated 15 nov 2002 and did a dry run
which produced some errors.

cd /usr/src
patch ... (see below)
(this is on a redhat 8.0 system, with a 2.4.18-14 kernel)

Have you tried this on 2.4.18? Is this a redhat kernel issue or just that the
patch needs updating for 2.4.18 (it seems your patch was for 2.4.17).

Thanks
Eric

[830]$ patch -p1 -d linux-2.4 --dry-run --verbose <task_unmapped_base.patch
Hmm...  Looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/fs/exec.c linux.new/fs/exec.c
|--- linux.old/fs/exec.c        Fri Nov 15 17:39:34 2002
|+++ linux.new/fs/exec.c        Fri Nov 15 17:44:51 2002
--------------------------
Patching file fs/exec.c using Plan A...
Hunk #1 succeeded at 21.
Hunk #2 succeeded at 581 (offset 7 lines).
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/include/asm-i386/resource.h linux.new/include/asm-i386/resource.h
|--- linux.old/include/asm-i386/resource.h      Fri Nov 15 17:39:35 2002
|+++ linux.new/include/asm-i386/resource.h      Fri Nov 15 17:44:51 2002
--------------------------
Patching file include/asm-i386/resource.h using Plan A...
Hunk #1 succeeded at 16.
Hunk #2 succeeded at 41.
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/include/linux/mm.h linux.new/include/linux/mm.h
|--- linux.old/include/linux/mm.h       Fri Nov 15 17:39:36 2002
|+++ linux.new/include/linux/mm.h       Fri Nov 15 17:44:51 2002
--------------------------
Patching file include/linux/mm.h using Plan A...
Hunk #1 succeeded at 115 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/include/linux/sched.h linux.new/include/linux/sched.h
|--- linux.old/include/linux/sched.h    Fri Nov 15 17:39:42 2002
|+++ linux.new/include/linux/sched.h    Fri Nov 15 17:44:51 2002
--------------------------
Patching file include/linux/sched.h using Plan A...
Hunk #1 succeeded at 264 (offset 31 lines).
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/include/linux/sysctl.h linux.new/include/linux/sysctl.h
|--- linux.old/include/linux/sysctl.h   Fri Nov 15 17:39:37 2002
|+++ linux.new/include/linux/sysctl.h   Fri Nov 15 17:46:52 2002
--------------------------
Patching file include/linux/sysctl.h using Plan A...
Hunk #1 succeeded at 145 (offset 2 lines).
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/kernel/sys.c linux.new/kernel/sys.c
|--- linux.old/kernel/sys.c     Fri Nov 15 17:39:38 2002
|+++ linux.new/kernel/sys.c     Fri Nov 15 17:44:51 2002
--------------------------
Patching file kernel/sys.c using Plan A...
Hunk #1 succeeded at 3 with fuzz 2.
Hunk #2 succeeded at 1132 (offset 18 lines).
Hunk #3 succeeded at 1125.
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/kernel/sysctl.c linux.new/kernel/sysctl.c
|--- linux.old/kernel/sysctl.c  Fri Nov 15 17:39:39 2002
|+++ linux.new/kernel/sysctl.c  Fri Nov 15 17:44:51 2002
--------------------------
Patching file kernel/sysctl.c using Plan A...
Hunk #1 succeeded at 17.
Hunk #2 FAILED at 277.
1 out of 2 hunks FAILED -- saving rejects to file kernel/sysctl.c.rej
Hmm...  The next patch looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|diff -Nur linux.old/mm/mmap.c linux.new/mm/mmap.c
|--- linux.old/mm/mmap.c        Fri Nov 15 17:39:40 2002
|+++ linux.new/mm/mmap.c        Fri Nov 15 17:44:51 2002
--------------------------
Patching file mm/mmap.c using Plan A...
Hunk #1 FAILED at 3.
Hunk #2 succeeded at 64 with fuzz 2 (offset 17 lines).
Hunk #3 FAILED at 645.
2 out of 3 hunks FAILED -- saving rejects to file mm/mmap.c.rej
done

The latest patch dated 15 nov 2002 is for 2.4.19,
the older patch dated 20 jan 2002 is for 2.4.17.

Quote:

> cd /usr/src
> patch ... (see below)
> (this is on a redhat 8.0 system, with a 2.4.18-14 kernel)

> Have you tried this on 2.4.18?

Nope.

Quote:> Is this a redhat kernel issue or just that the
> patch needs updating for 2.4.18 (it seems your patch was for 2.4.17).

The older patch was for 2.4.17, the newest is for 2.4.19.
The newest patch is really just the previous one updated
for 2.4.19. I'd expect the newest patch to fail against
earlier kernels.

I have not tested any of them against 2.4.18, doesn't any
of them work? I can make a 2.4.18 patch also, shouldn't be
any major problem.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

I have now tested the 2.4.17-4 patch against 2.4.18, and it
applies cleanly. I haven't tried it against the RH kernel.

The patch is now available under these two names:
http://www.daimi.au.dk/~kasperd/linux_kernel/task_unmapped_base/task_...
http://www.daimi.au.dk/~kasperd/linux_kernel/task_unmapped_base/task_...
it is the same file.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

I will try this later today, when I get into the workplace.

Do you have a quick usage example? I forget just how to
set the value up for an individual process.

thanks
Eric

You need the userspace program:
http://www.daimi.au.dk/~kasperd/linux_kernel/task_unmapped_base/task_...

If you call the compiled executable tub, you can write on the
command line:

   tub soft=42 hard=47 command

To execute command with base=42*pagesize. And if the command
does more execve calls, they will use base=47*pagesize. Both
arguments are optional, if unspecified they are inherited
from the parent. The default inheritable from init is to use
the systemwide setting, that can be changed through a sysctl
or /proc.

There are a shorthand notation for setting both arguments to
the same value, you can type:

   tub both=43 command

--
Kasper Dupont -- der bruger for meget tid p? usenet.

char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

I don't know what the issue was, but 2 files, syscnt.h and mmap.c got
some complaints by patch (on RH 8.0 sources).

So, I made the patch manually and am building now (on a verrrry slow machine).
I will try it out tomorrow.

One other subject. Your faq page spoke of a way to change the
division between kernel memory and user space. The symbol
you mentioned is PAGE_OFFSET_RAW which I found
in /usr/include/asm/page_offset.h

Since that is not in the source tree where I am building a
kernel, did I find the right  file? Can I just change that
and do a kernel build?

This would appear to let us get into the top 1 gig as well.
I am anxious to try this. Say, a value of 0xf000_0000.
That should meet with the rounding and minimum size
settings that you mentioned.

eric

OK, I'll have to download the RH8.0 sources some day to test
this on my own.

Quote:

> So, I made the patch manually and am building now (on a verrrry slow machine).
> I will try it out tomorrow.

> One other subject. Your faq page spoke of a way to change the
> division between kernel memory and user space. The symbol
> you mentioned is PAGE_OFFSET_RAW which I found
> in /usr/include/asm/page_offset.h

> Since that is not in the source tree where I am building a
> kernel, did I find the right  file? Can I just change that
> and do a kernel build?

There is also an include directory in the kernel tree, that is
where you should make the change.

Quote:

> This would appear to let us get into the top 1 gig as well.
> I am anxious to try this. Say, a value of 0xf000_0000.
> That should meet with the rounding and minimum size
> settings that you mentioned.

Perhaps I should do a little more about that description,
I think a few details are missing. How much physical memory
do you have? If you cannot fit all the physical memory in the
kernel address space you will need to enable high memory
support. I don't know if there are any additional allignment
requirements if you are using high memory.

Even though I have far less than 1GB of physical memory on
my own computer, I should be able to test this. I will try
it some day.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";