RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
Hi Andi, PPC64 IA64 and S390 use variable size TASK_SIZE for 32 bit and 64 bit program. I feel it is hard to maintain if we try to audit TASK_SIZE use everywhere, because most of them are in generic code. And maintaining those audit code in separate place is also a problem. E.g. in current 32 bit emulation code TASK_SIZE is defined as 0xfff in elf loading, but defined as 0xe000 in mmaping. How did that earlier patch break applications? Thanks Zou Nan hai > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 21, 2005 7:54 PM > To: Zou, Nanhai > Cc: Andi Kleen; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, > Suresh B > Subject: Re: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments > > > Another comment: > > In general I am not too happy about the variable size TASK_SIZE. > There was a patch for this earlier, but it broke 32bit emulation > completely. And I think it needs auditing of all uses of TASK_SIZE, > because I suspect there are more bugs lurking in it. > > The way hugetlb etc. mmap were supposed to be handled was to > let the mmap succeed and then check in the mmap wrapper > if any address is > 4GB and free it. Probably that code > has some problems or got broken (I think it worked at least > in 2.4, but there might have been regressions later) > > -Andi - 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: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
Another comment: In general I am not too happy about the variable size TASK_SIZE. There was a patch for this earlier, but it broke 32bit emulation completely. And I think it needs auditing of all uses of TASK_SIZE, because I suspect there are more bugs lurking in it. The way hugetlb etc. mmap were supposed to be handled was to let the mmap succeed and then check in the mmap wrapper if any address is > 4GB and free it. Probably that code has some problems or got broken (I think it worked at least in 2.4, but there might have been regressions later) -Andi - 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: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
Another comment: In general I am not too happy about the variable size TASK_SIZE. There was a patch for this earlier, but it broke 32bit emulation completely. And I think it needs auditing of all uses of TASK_SIZE, because I suspect there are more bugs lurking in it. The way hugetlb etc. mmap were supposed to be handled was to let the mmap succeed and then check in the mmap wrapper if any address is 4GB and free it. Probably that code has some problems or got broken (I think it worked at least in 2.4, but there might have been regressions later) -Andi - 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: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
Hi Andi, PPC64 IA64 and S390 use variable size TASK_SIZE for 32 bit and 64 bit program. I feel it is hard to maintain if we try to audit TASK_SIZE use everywhere, because most of them are in generic code. And maintaining those audit code in separate place is also a problem. E.g. in current 32 bit emulation code TASK_SIZE is defined as 0xfff in elf loading, but defined as 0xe000 in mmaping. How did that earlier patch break applications? Thanks Zou Nan hai -Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Thursday, April 21, 2005 7:54 PM To: Zou, Nanhai Cc: Andi Kleen; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B Subject: Re: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments Another comment: In general I am not too happy about the variable size TASK_SIZE. There was a patch for this earlier, but it broke 32bit emulation completely. And I think it needs auditing of all uses of TASK_SIZE, because I suspect there are more bugs lurking in it. The way hugetlb etc. mmap were supposed to be handled was to let the mmap succeed and then check in the mmap wrapper if any address is 4GB and free it. Probably that code has some problems or got broken (I think it worked at least in 2.4, but there might have been regressions later) -Andi - 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/
