Wrong size calculation in __ioremap(), various platforms

Florian Zumbiehl (florz@gmx.de)
Thu, 14 Nov 2002 17:16:50 +0100


Hi all,

in arch/*/mm/ioremap.c, __ioremap() of several platforms there seems to
be a minor mistake in the calculation of the page-aligned mapping size:

void * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags)
{
void * addr;
struct vm_struct * area;
unsigned long offset, last_addr;

/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
if (!size || last_addr < phys_addr)
return NULL;

/* ... code which doesn't change last_addr ... */

size = PAGE_ALIGN(last_addr) - phys_addr;

/* ... */
}

For this calculation to work, PAGE_ALIGN(last_addr) would have to be
the address immediately after the last address to be mapped - if
last_addr is the first address of a page however, PAGE_ALIGN() of course
"returns" it unchanged.

So, the correct version IMO should look like this:

size = PAGE_ALIGN(last_addr + 1) - phys_addr;

(2.5.47?/)i386 even seems to be affected twice - bt_ioremap() contains the
same piece of code.

In the hope not to have overlooked something,

Florian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ds of things. Changing module refcounts to track the
device bindings would be a "hard" policy, interfering with driver
developer and sysadmins (gotta reboot or unplug to change drivers).
Tracking such device-to-driver bindings in userland is fragile.
Today's workaround is not to rmmod ... an undesirable answer.

So I keep thinking the right answer is to have a separate count
to track hardware bindings, or at any rate some "soft" policy
hook is needed to prevent rmmod in such cases. Sysadmins and
driver developers would be able to override the policy, but
Joe Tux-user would just stick to the default.

- Dave

>>That'd be a user-friendly policy, but we'd still need to handle
>>today's developer-oriented "sysadmin can always remove module"
>>policy. (Me, I'd run with the "user friendly" policy except
>>when hacking a driver. Then I'd debug/rmmod/update/modprobe.)
>
>
> rmmod -f is about as unfriendly as you can get, really 8)
>
> Cheers,
> Rusty.
> --
> Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/