Re: [patch] Re: Linux 2.4.5-ac6
On Fri, Jun 08, 2001 at 06:08:46PM +0200, Maciej W. Rozycki wrote:
> Still it has two loops...
Ok, here is a single loop version.
Ivan.
--- 2.4.5-ac11/mm/mmap.cFri Jun 8 15:59:35 2001
+++ linux/mm/mmap.c Sat Jun 9 12:50:05 2001
@@ -398,27 +398,37 @@ free_vma:
static inline unsigned long arch_get_unmapped_area(struct file *filp, unsigned long
addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct vm_area_struct *vma;
+ unsigned long addr_limit = TASK_SIZE - len;
+ unsigned long addr1 = 0;
if (len > TASK_SIZE)
return -ENOMEM;
if (addr) {
addr = PAGE_ALIGN(addr);
- vma = find_vma(current->mm, addr);
- if (TASK_SIZE - len >= addr &&
- (!vma || addr + len <= vma->vm_start))
- return addr;
+ if (addr > TASK_UNMAPPED_BASE)
+ addr1 = addr;
+ goto find_free_area;
}
+
+default_area:
addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
+find_free_area:
for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
/* At this point: (!vma || addr < vma->vm_end). */
- if (TASK_SIZE - len < addr)
- return -ENOMEM;
+ if (addr_limit < addr)
+ break;
if (!vma || addr + len <= vma->vm_start)
return addr;
addr = vma->vm_end;
}
+ if (addr1) {
+ /* No unmapped areas above addr; try below it */
+ addr_limit = addr1;
+ goto default_area;
+ }
+ return -ENOMEM;
}
#else
extern unsigned long arch_get_unmapped_area(struct file *, unsigned long, unsigned
long, unsigned long, unsigned long);
--- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
+++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
@@ -32,6 +32,9 @@ struct linux_binprm{
unsigned long loader, exec;
};
+/* Forward declaration */
+struct mm_struct;
+
/*
* This structure defines the functions that are used to load the binary formats that
* linux accepts.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Fri, Jun 08, 2001 at 06:08:46PM +0200, Maciej W. Rozycki wrote:
Still it has two loops...
Ok, here is a single loop version.
Ivan.
--- 2.4.5-ac11/mm/mmap.cFri Jun 8 15:59:35 2001
+++ linux/mm/mmap.c Sat Jun 9 12:50:05 2001
@@ -398,27 +398,37 @@ free_vma:
static inline unsigned long arch_get_unmapped_area(struct file *filp, unsigned long
addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct vm_area_struct *vma;
+ unsigned long addr_limit = TASK_SIZE - len;
+ unsigned long addr1 = 0;
if (len TASK_SIZE)
return -ENOMEM;
if (addr) {
addr = PAGE_ALIGN(addr);
- vma = find_vma(current-mm, addr);
- if (TASK_SIZE - len = addr
- (!vma || addr + len = vma-vm_start))
- return addr;
+ if (addr TASK_UNMAPPED_BASE)
+ addr1 = addr;
+ goto find_free_area;
}
+
+default_area:
addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
+find_free_area:
for (vma = find_vma(current-mm, addr); ; vma = vma-vm_next) {
/* At this point: (!vma || addr vma-vm_end). */
- if (TASK_SIZE - len addr)
- return -ENOMEM;
+ if (addr_limit addr)
+ break;
if (!vma || addr + len = vma-vm_start)
return addr;
addr = vma-vm_end;
}
+ if (addr1) {
+ /* No unmapped areas above addr; try below it */
+ addr_limit = addr1;
+ goto default_area;
+ }
+ return -ENOMEM;
}
#else
extern unsigned long arch_get_unmapped_area(struct file *, unsigned long, unsigned
long, unsigned long, unsigned long);
--- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
+++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
@@ -32,6 +32,9 @@ struct linux_binprm{
unsigned long loader, exec;
};
+/* Forward declaration */
+struct mm_struct;
+
/*
* This structure defines the functions that are used to load the binary formats that
* linux accepts.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote: > On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: > > On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: > > > > Exactly. However, there are situations when you have only two options: > > > rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) > > > > Why can't mozilla be fixed? With the -taso option there is actually less > > encouragement to do so. > > Mozilla is fine. Its netscape 4.X that probably needs -taso. And only the old netscape 4.x releases at that afik the newer releases are all compiled ELF. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:28:04PM +0200, Maciej W. Rozycki wrote: > DU seems to map as low as possible, it would seem. Yes, I've just checked, starting at 64K... > Maybe we could just > do the same for OSF/1 binaries by setting TASK_UNMAPPED_BASE > appropriately? No. I've changed in load_aout_binary() set_personality(PER_LINUX) to set_personality(PER_LINUX_32BIT), and now I have another error. You will laugh, but... $ netscape 665:/usr/lib/netscape/netscape-communicator: : Fatal Error: mmap available address is not larger than requested This happens after mmap(0x7fdc8000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 And note, this is the message from loader, not from netscape itself. So I think my second patch is an easiest solution for now. Look, compared with the code in Linus' tree: - it doesn't add any overhead in general case (addr == 0); - if the specified address is too high and we can't find a free area above it, we just continue search from TASK_UNMAPPED_BASE as usual; - if address is too low, extra cost is only compare and taken branch. I think it's clean enough. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: > On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: > > Exactly. However, there are situations when you have only two options: > > rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) > > Why can't mozilla be fixed? With the -taso option there is actually less > encouragement to do so. Mozilla is fine. Its netscape 4.X that probably needs -taso. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: Exactly. However, there are situations when you have only two options: rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) Why can't mozilla be fixed? With the -taso option there is actually less encouragement to do so. Mozilla is fine. Its netscape 4.X that probably needs -taso. Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: Exactly. However, there are situations when you have only two options: rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) Why can't mozilla be fixed? With the -taso option there is actually less encouragement to do so. Mozilla is fine. Its netscape 4.X that probably needs -taso. And only the old netscape 4.x releases at that afik the newer releases are all compiled ELF. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:28:04PM +0200, Maciej W. Rozycki wrote: DU seems to map as low as possible, it would seem. Yes, I've just checked, starting at 64K... Maybe we could just do the same for OSF/1 binaries by setting TASK_UNMAPPED_BASE appropriately? No. I've changed in load_aout_binary() set_personality(PER_LINUX) to set_personality(PER_LINUX_32BIT), and now I have another error. You will laugh, but... $ netscape 665:/usr/lib/netscape/netscape-communicator: : Fatal Error: mmap available address is not larger than requested This happens after mmap(0x7fdc8000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 And note, this is the message from loader, not from netscape itself. So I think my second patch is an easiest solution for now. Look, compared with the code in Linus' tree: - it doesn't add any overhead in general case (addr == 0); - if the specified address is too high and we can't find a free area above it, we just continue search from TASK_UNMAPPED_BASE as usual; - if address is too low, extra cost is only compare and taken branch. I think it's clean enough. Ivan. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Wed, 6 Jun 2001, Jeff Garzik wrote: > There are two things you can do here, one is easy: use linker tricks to > make sure that an application built on alpha -- with 64-bit pointers -- > uses no more than the lower 32 bits of each pointer for addressing. > This should fix a ton of applications which cast pointer values to ints > and similar garbage. Note we are only writing of executing an OSF/1 netscape binary. The binary is built with the -taso option on OSF/1 and is linked fine with respect to 31-bit pointers. It fails when mmap()ping shared libraries after applying my patch that went to -ac series recently. Since OSF/1 shared libraries are PIC, there should be no problem to mmap() them into the low 2GB provided mmap() know we want it. And mmap() has already all needed bits in place -- it's the ECOFF support on Alpha/Linux that does not set the personality as it should. > The other option, hacking gcc to output "32-bit alpha" binary code, is a > tougher job. > > I had mentioned this to Richard Henderson a while back, when I was > wondering how easy it is to implement -taso under Linux, and IIRC he > seemed to think that linker tricks were much easier. It might be unavoidable to prevent shared libraries from being mmap()ped outside the 31-bit address space unless we hint the dynamic linker somehow. Implementing the -taso option is trivial -- all it actually does on OSF/1 is mapping program's segments into low 2GB of memory (we may do it by selecting a different linker script) and setting the "31-bit address space flag" in the program's header so that the dynamic linker mmap()s shared libraries appropriately as well. We do have all the bits in place already as well. Note that personally I'm strongly against the -taso approach -- it's a hack to be meant as an excuse for fixing broken programs. But fixing programs is not that difficult (though it might be boring and time-consuming). I've already did a conversion of a moderately sized DOS program to *nix. The program was twisted by far and near pointers and casts to ints and longs (depending on the pointer type) scattered over the source. It took me about two weeks worth of full-time work (assuming eight hours per day; the actual time elapsed was longer, but I was only doing it in my free time) to make the program working on i386/Linux, another week to port it to Alpha/Linux (i.e. make it 64-bit clean) and yet another day to make it work on SPARC/Solaris (i.e. make it endianness-clean). The program was checked to be running fine on MIPS/Ultrix and Alpha/OSF/1 afterwards as well. Therefore I see no point in keeping programs broken. If a vendor is not willing to fix a non-open-sourced broken program, then maybe the program is just not worth attention. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Wed, 6 Jun 2001, Jeff Garzik wrote: There are two things you can do here, one is easy: use linker tricks to make sure that an application built on alpha -- with 64-bit pointers -- uses no more than the lower 32 bits of each pointer for addressing. This should fix a ton of applications which cast pointer values to ints and similar garbage. Note we are only writing of executing an OSF/1 netscape binary. The binary is built with the -taso option on OSF/1 and is linked fine with respect to 31-bit pointers. It fails when mmap()ping shared libraries after applying my patch that went to -ac series recently. Since OSF/1 shared libraries are PIC, there should be no problem to mmap() them into the low 2GB provided mmap() know we want it. And mmap() has already all needed bits in place -- it's the ECOFF support on Alpha/Linux that does not set the personality as it should. The other option, hacking gcc to output 32-bit alpha binary code, is a tougher job. I had mentioned this to Richard Henderson a while back, when I was wondering how easy it is to implement -taso under Linux, and IIRC he seemed to think that linker tricks were much easier. It might be unavoidable to prevent shared libraries from being mmap()ped outside the 31-bit address space unless we hint the dynamic linker somehow. Implementing the -taso option is trivial -- all it actually does on OSF/1 is mapping program's segments into low 2GB of memory (we may do it by selecting a different linker script) and setting the 31-bit address space flag in the program's header so that the dynamic linker mmap()s shared libraries appropriately as well. We do have all the bits in place already as well. Note that personally I'm strongly against the -taso approach -- it's a hack to be meant as an excuse for fixing broken programs. But fixing programs is not that difficult (though it might be boring and time-consuming). I've already did a conversion of a moderately sized DOS program to *nix. The program was twisted by far and near pointers and casts to ints and longs (depending on the pointer type) scattered over the source. It took me about two weeks worth of full-time work (assuming eight hours per day; the actual time elapsed was longer, but I was only doing it in my free time) to make the program working on i386/Linux, another week to port it to Alpha/Linux (i.e. make it 64-bit clean) and yet another day to make it work on SPARC/Solaris (i.e. make it endianness-clean). The program was checked to be running fine on MIPS/Ultrix and Alpha/OSF/1 afterwards as well. Therefore I see no point in keeping programs broken. If a vendor is not willing to fix a non-open-sourced broken program, then maybe the program is just not worth attention. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Tue, Jun 05, 2001 at 05:11:01PM +0200, Maciej W. Rozycki wrote:
> Iterating over memory areas twice is ugly.
Hmm, yes. However, your patch isn't pretty, too. You may check
the same area twice, and won't satisfy requested address > TASK_UNMAPPED_BASE.
What do you think about following? Everything is scanned only once, and
returned address matches specified one as close as possible.
Ivan.
--- linux/mm/mmap.c.origMon Jun 4 14:19:02 2001
+++ linux/mm/mmap.c Tue Jun 5 21:05:23 2001
@@ -398,22 +398,30 @@ free_vma:
static inline unsigned long arch_get_unmapped_area(struct file *filp, unsigned long
addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct vm_area_struct *vma;
+ unsigned long addr_limit = TASK_SIZE - len;
if (len > TASK_SIZE)
return -ENOMEM;
if (addr) {
addr = PAGE_ALIGN(addr);
- vma = find_vma(current->mm, addr);
- if (TASK_SIZE - len >= addr &&
- (!vma || addr + len <= vma->vm_start))
- return addr;
+ if (addr <= TASK_UNMAPPED_BASE)
+ goto scan_low;
+ addr_limit = addr;
+ for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
+ if (TASK_SIZE - len < addr)
+ break;
+ if (!vma || addr + len <= vma->vm_start)
+ return addr;
+ addr = vma->vm_end;
+ }
}
addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
+scan_low:
for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
/* At this point: (!vma || addr < vma->vm_end). */
- if (TASK_SIZE - len < addr)
+ if (addr_limit < addr)
return -ENOMEM;
if (!vma || addr + len <= vma->vm_start)
return addr;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Tue, Jun 05, 2001 at 05:11:01PM +0200, Maciej W. Rozycki wrote:
Iterating over memory areas twice is ugly.
Hmm, yes. However, your patch isn't pretty, too. You may check
the same area twice, and won't satisfy requested address TASK_UNMAPPED_BASE.
What do you think about following? Everything is scanned only once, and
returned address matches specified one as close as possible.
Ivan.
--- linux/mm/mmap.c.origMon Jun 4 14:19:02 2001
+++ linux/mm/mmap.c Tue Jun 5 21:05:23 2001
@@ -398,22 +398,30 @@ free_vma:
static inline unsigned long arch_get_unmapped_area(struct file *filp, unsigned long
addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct vm_area_struct *vma;
+ unsigned long addr_limit = TASK_SIZE - len;
if (len TASK_SIZE)
return -ENOMEM;
if (addr) {
addr = PAGE_ALIGN(addr);
- vma = find_vma(current-mm, addr);
- if (TASK_SIZE - len = addr
- (!vma || addr + len = vma-vm_start))
- return addr;
+ if (addr = TASK_UNMAPPED_BASE)
+ goto scan_low;
+ addr_limit = addr;
+ for (vma = find_vma(current-mm, addr); ; vma = vma-vm_next) {
+ if (TASK_SIZE - len addr)
+ break;
+ if (!vma || addr + len = vma-vm_start)
+ return addr;
+ addr = vma-vm_end;
+ }
}
addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
+scan_low:
for (vma = find_vma(current-mm, addr); ; vma = vma-vm_next) {
/* At this point: (!vma || addr vma-vm_end). */
- if (TASK_SIZE - len addr)
+ if (addr_limit addr)
return -ENOMEM;
if (!vma || addr + len = vma-vm_start)
return addr;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
