Re: ioremap()/PCI sickness in 2.4.18-rc2 (FIXED ALMOST)

Jeff V. Merkey
2002-02-22T18:00:39Z

On Fri, Feb 22, 2002 at 12:08:25PM +0100, Steffen Persvold wrote:
> "Jeff V. Merkey" wrote:
> >
> > On Wed, Feb 20, 2002 at 02:54:49PM -0700, Jeff V. Merkey wrote:
> >
> > > struct vm_struct * get_vm_area(unsigned long size, unsigned long flags)
> > > {
> > > unsigned long addr;
> > > struct vm_struct **p, *tmp, *area;
> > >
> > > area = (struct vm_struct *) kmalloc(sizeof(*area), GFP_KERNEL);
> > > if (!area)
> > > return NULL;
> > > size += PAGE_SIZE;
> > > addr = VMALLOC_START;
> > > write_lock(&vmlist_lock);
> > > for (p = &vmlist; (tmp = *p) ; p = &tmp->next) {
> > >
> > > ===============> we barf here since the size + addr wraps
> > >
> >
> > Also, this function should be moved to the /arch/i386/mm area since
> > it is doing pointer arithmetic with 32 bit assumptions (i.e.
> > unsigned long + unsigned long) Last time I checked, unsigned long
> > was a construct for a 32 bit value in any gcc compiler version, ia64
> > or not.
> >
>
> Jeff,
>
> I think you'll have to check again. In LP64 programming models (used on most
> 64-bit OS'es) 'long' is 64 bit. Thus a 'unsigned long' is always safe to use
> for pointer arithmetic since it will be 32 bit on 32bit machines and 64bit on
> 64bit machines.
>
> Regards,
> --

Hi Steffan,

On early IA64 long long was assumed to be 64 bit, long 32 bit. After
emailing some folks off line I relaize this may not be the case
any longer, but still is on some compiler options.

Say hi to Hugo for me next time you see him. :-) I have reviewed this
and we will need some changes to the page table setup in Linux
and copy to/from user macros in order to get around this problem
for preallocating prefetch space.

Any ideas and joint work on this problem is appreciated.

Jeff

> Steffen Persvold | Scalable Linux Systems | Try out the world's best
> mailto:sp@scali.com | http://www.scali.com | performing MPI implementation:
> Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.13.8 -
> Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >320MBytes/s and <4uS latency