Re: [BK PATCH 2.5] fs/binfmt_aout.c: Use PAGE_ALIGN_LL() on

[Anton Altaparmakov]

At 20:35 28/07/02, Eric W. Biederman wrote:
>Anton Altaparmakov <[e-mail]> writes:
>
> > At 18:59 28/07/02, Eric W. Biederman wrote:
> > >Anton Altaparmakov <[e-mail]> writes:
> > > > Following from previous patch which introduced PAGE_ALIGN_LL, this
> > > > one fixes a bug in fs/binfmt_aout.c which was using PAGE_ALIGN
> > > > on 64-bit values... It now uses PAGE_ALIGN_LL.
> > > >
> > > > Patch together with the other two patches available from:
> > > >
> > > >       bk pull http://linux-ntfs.bkbits.net/linux-2.5-pm
> > >
> > >Huh?
> > >
> > >All virtual addresses on 32bit platforms are 32bit, as are all lengths
> > >of address space.
> >
> > I thought (intel) CPUs did 48-bit addressing? How do we support 32GiB 
> of RAM?
> > With pure 32-bit addressing it would be limited to 4GiB only... No? (Of 
> course I
> >
> > am probably confusing varius types of addresses...)
>
>Hammers and Alphas have 48bit virtual and 40bit physical, in the
>current implementations.  The most common 48bit address though is that
>ide recently moved from 28bit sector addresses to 48bit sector addresses.
>
> > >Unless you are running a 32bit kernel with a 64bit user space,
> > >which is simply crazy, unless you are stuck doing it that way.
> >
> > The code is still broken. The values ARE 64-bit (check the struct 
> definitions if
> > you don't believe me).
>
>I just did.  The values are per arch, but at least for X86 the values are
>unsigned int.  Which is 32bits..

Ooops! Sorry! I appologise! This was my bad. For Alpha they are __u64 and I 
misguidedly looked at Alpha instead of i386. (darn ctags...) But of course 
on Alpha long is 64-bits so the issue is moot...

So yes, this patch is definitely bogus. (Well it just would make no 
difference whatsoever.)

Best regards,

         Anton