Hi Greg, On Wed, May 26, 2010 at 12:54:49PM +1000, Greg Ungerer wrote: > > Hi Philippe, > > Philippe De Muyter wrote: >> Hi Greg, >> On Tue, May 25, 2010 at 11:19:43AM +1000, Greg Ungerer wrote: >>> Hi Philippe, >>> >>> Philippe De Muyter wrote: >>>> On Mon, May 24, 2010 at 11:29:50AM +1000, Greg Ungerer wrote: >>>> [...] >>>>> +#else >>>>> +#define TASK_SIZE (0xFFFFFFFFUL) >>>>> +#endif >>>> Because of do_getname() : >>>> len = TASK_SIZE - (unsigned long) filename; >>>> we should rather have >>>> #define TASK_SIZE (0x100000000ull) >>> I see what you mean. But in practice here I don't think it matters. >> Can no process have its stack allocated in the last block, and hence have >> some >> argv[i] put in the last addresses, with the terminating '\0' at 0xffffffff >> ? > > I think that is possible. But the "in practice" part is that > I don't know of any m68knommu platforms that actually map the RAM > right at the very top of the 32bit address space - so that it ends > at 0xffffffff.
OK then (I had missed/forgotten that your patch was for m68knommu only) Best regards Philippe PS: I have already been bitten (in another part of the kernel) by a bug that refused a zone containing 0xffffffff (see http://lkml.org/lkml/2009/12/6/204) -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
