Re: Bug in __ioremap() + Patch

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Wed, 21 Jan 1998 11:01:41 +0100 (MET)

> I've found a bug in __ioremap(), and have attached a patch to fix it. The bug
> occurs if the bit of memory you're interested in lies right at the end of the
> memory range, and so fulfils the following condition:
>
> phys-addr + size = 0
> (0xffffd000) (0x3000)
>
> The patch is:
>
> +++ linux-2.1.78c/arch/i386/mm/ioremap.c Tue Jan 20 20:41:53 1998
> --- orig/linux-2.1.78/arch/i386/mm/ioremap.c Fri Apr 4 16:52:17 1997
> @@ -95,7 +95,7 @@
> if (phys_addr & ~PAGE_MASK)
> return NULL;
> size = PAGE_ALIGN(size);
> - if (!size || size > phys_addr + size)
> + if (!size || (size != ~phys_addr+1 && size > phys_addr + size))
> return NULL;
> area = get_vm_area(size);
> if (!area)
>
> I'm sure there's better ways of writing the extra bit in the condition, but it
> works.

Really many places in Linux mm do the same, especially the generic mm/ code.
You cannot e.g. have user task VA space from 0 to ~0, as a lot of such tests
fail. It turned out the highest possible VA address for user tasks the Linux
MMU allows is (unsigned long)(-PGDIR_SIZE). That's a little bit pitty, as
e.g. Linux will not ever be able to test the sparcv9 ABI medhigh model, as
highest task address needs to be 0xfffffffc00000000.
On the other side, it is not that big pain for the sake of speed and
readability of generic MM code.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.79 on a sparc64 machine (494.80 BogoMips).
___________________________________________________________________