[BK PATCH 2.5] fs/binfmt_aout.c: Use PAGE_ALIGN_LL() on 64-bit values

[BK PATCH 2.5] fs/binfmt_aout.c: Use PAGE_ALIGN_LL() on 64-bit values

[Anton Altaparmakov]

Linus,

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

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/, http://www-stu.christs.cam.ac.uk/~aia21/

===================================================================

This will update the following files:

 fs/binfmt_aout.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

through these ChangeSets:

<aia21@cantab.net> (02/07/27 1.478)
   fs/binfmt_aout.c: Use PAGE_ALIGN_LL() on 64-bit values.


diff -Nru a/fs/binfmt_aout.c b/fs/binfmt_aout.c
--- a/fs/binfmt_aout.c	Sat Jul 27 14:23:02 2002
+++ b/fs/binfmt_aout.c	Sat Jul 27 14:23:02 2002
@@ -493,7 +493,7 @@
 	if (error != start_addr)
 		goto out;
 
-	len = PAGE_ALIGN(ex.a_text + ex.a_data);
+	len = PAGE_ALIGN_LL(ex.a_text + ex.a_data);
 	bss = ex.a_text + ex.a_data + ex.a_bss;
 	if (bss > len) {
 		error = do_brk(start_addr + len, bss - len);

===================================================================

This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##


begin 664 bkpatch21945
M'XL(`+:>0CT``\U476O;,!1]CG[%A;ZL%,OZ]-?P2-:6K"QT(://09;5V32V
M@RUW*?C'3W.A*2Y=6=G#)('$U>7HW',/.H&;SK3)3)6*470"7YK.)C.M:JLR
M7!OK0INF<2&_[UJ_:[6_*^O^X#$LO7V%W/5:65W`O6F[9$8Q?XK8A[U)9IO+
MY<UJL4$H3>&\4/4/\]U82%-DF_9>[?)NKFRQ:VIL6U5WE;$*ZZ8:GE('1@AS
M4]*0$QD,-"`B'#3-*56"FIPP$04"C?3G1]I3@)"%E--8BD'&,J#H`B@6802$
M^23T60A4)(PEDIP1FA`"4SPXH^`1]!G^+>USI.&V\[.ROJWL5C6]Q3KYW1%8
M+Y:7V\7J:GF]7:T^G$)30R"\K+3@GN]-A]%7D)&4!*V/NB+O+P="1!'TZ8VJ
MI@R?%Q?S:&!<\F#(,N(*HYQIE6>,1R\T?`5G;`UC3AXFJ."C4Z:9;QOF?1S1
MG2KG=D]QVQ>MU]>EES6ZZ"N<FU<0)>.NEQ$7#C&*@]%(E$]]),(_^8C^9SYZ
MU/T;>.W/<3E?K%_`O<-;%R(.@**KQVVV,S6D$T+F@-76FH,3!L9SKJPZ_7C\
75W1A]%W75VD@=2Q89M`O@6G#F+($````
`
end

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

[Eric W. Biederman]

Anton Altaparmakov <aia21@cantab.net> writes:

> Linus,
> 
> 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.  

Unless you are running a 32bit kernel with a 64bit user space,
which is simply crazy, unless you are stuck doing it that way.

Eric

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

[Anton Altaparmakov]

At 18:59 28/07/02, Eric W. Biederman wrote:
>Anton Altaparmakov <aia21@cantab.net> 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...)

>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). This is just a matter of correctness. 
It is incorrect as it is right now and it will do Bad Things(tm) if the 
supplied values are > 32-bit. (Whether it is possible for a malicious user 
to supply them is beyond my knowledge.)

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

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

[Christoph Hellwig]

On Sun, Jul 28, 2002 at 07:55:51PM +0100, Anton Altaparmakov wrote:
> 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...)

P6+ support 36bit _physical_ addressing.

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

[Eric W. Biederman]

Anton Altaparmakov <aia21@cantab.net> writes:

> At 18:59 28/07/02, Eric W. Biederman wrote:
> >Anton Altaparmakov <aia21@cantab.net> 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..

Eric

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

[Anton Altaparmakov]

At 20:35 28/07/02, Eric W. Biederman wrote:
>Anton Altaparmakov <aia21@cantab.net> writes:
>
> > At 18:59 28/07/02, Eric W. Biederman wrote:
> > >Anton Altaparmakov <aia21@cantab.net> 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


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/