Hi Michael, On Wed, May 23, 2018 at 11:39 PM, Michael Schmitz <[email protected]> wrote: > On Wed, May 23, 2018 at 7:44 PM, Geert Uytterhoeven > <[email protected]> wrote: >>>> At first sight (and looking in full-history-linux git history), I see no >>>> reason for the gap. I'd assume having a block with address and size aligned >>>> to 256 KiB (which the caller already takes care of: IO_SIZE is 256 KiB if >>>> 020/030 support is enabled) should be sufficient to use early termination >>>> tables. >>> >>> My guess is that someone wanted to catch out of bounds accesses by >>> leaving the unmapped areas in between ioremapped 256 kB chunks. The >>> unmapped gaps must 256 kB as well to avoid disturbing the alignment. >>> >>> The adjustment for gap size was dropped sometime between 2.4.30 and >>> 2.6.18. At the same time, a comment in get_io_area was removed that >>> stated 'leave a gap of IO_SIZE'. I haven't looked at the full history to >>> find out who removed that comment (and the adjustment). >> >> I can't seem to find the addition/removal of that comment (checked >> full-history-linux and the old m68k-linux CVS)? > > Part of the problem may be that kmap.c was moved a few times during > integration of the nommu port. > > I happen to have a few old kernel trees around that I can consult for > a rough history, and 2.4.30 still has the comment while 2.6.18 or > 2.6.19 lost it.
Of course all historical git trees contain linear history, not the branch with the continued 2.4.x development after 2.5.x was spun off... So I guess this was fixed in 2.4.x, but never in 2.5.x :-( Linux/m68k CVS had a fix in m68k-2_4_21 and later: commit 7bfc690086f568f440f81c2bb3578dd07295b303 Author: Geert Uytterhoeven <[email protected]> Date: Mon Jul 21 21:36:10 2003 +0000 Take the gap into account in free_io_area() (from Michael Müller) diff --git a/arch/m68k/mm/kmap.c b/arch/m68k/mm/kmap.c index da23f36ec6a5..4a9676373a5b 100644 --- a/arch/m68k/mm/kmap.c +++ b/arch/m68k/mm/kmap.c @@ -71,7 +71,7 @@ static struct vm_struct *get_io_area(unsigned long size) addr = tmp->size + (unsigned long)tmp->addr; } area->addr = (void *)addr; - area->size = size + IO_SIZE; + area->size = size + IO_SIZE; /* leave a gap between */ area->next = *p; *p = area; return area; @@ -87,7 +87,10 @@ static inline void free_io_area(void *addr) for (p = &iolist ; (tmp = *p) ; p = &tmp->next) { if (tmp->addr == addr) { *p = tmp->next; - __iounmap(tmp->addr, tmp->size); + if ( tmp->size > IO_SIZE ) + __iounmap(tmp->addr, tmp->size - IO_SIZE); + else + printk("free_io_area: Invalid I/O area size %lu\n", tmp->size); kfree(tmp); return; } I can't seem to find a public git tree with full 2.4.x history, but https://git.linux-mips.org/cgit/ralf/linux.git/commit/arch/m68k/mm/kmap.c?h=linux-2.4&id=65456e0e26a40f4c4933d700847ed1a9d261811e shows it made upstream in 2.4.23-rc1. > Where is the old CVS hosted these days? Nowhere. Ralf Bächle was so kind to provide me with a git import a long time ago (his machine was more powerful than mine ;-). I could push it to kernel.org (a separate repo, else linux-m68k.git will grow a lot, and everyone will suffer ;-). I also have to re-add the various branches (it has tags only). Anyone interested? Anyway, applied and queued for 4.18, with a cc to stable. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
