Hi Michael, On Mon, May 14, 2018 at 1:10 PM, Michael Schmitz <[email protected]> wrote:
On kernels with 020/030 support ... > get_io_area leaves an IO_SIZE gap between mappings which is added to > the vm_struct representing the mapping. __ioremap() uses the actual > requested size (after alignment), while __iounmap() is passed the > size from the vm_struct. > > On 020/030, early termination descriptors are used to set up mappings of > extent 'size', which are validated on unmapping. The unmapped gap of size > IO_SIZE defeats the sanity check of the pmd tables, causing __iounmap to > loop forever on 030. > > On 040/040, unmapping of page table entries does not check for a valid 040/060 > mapping, so the umapping loop always completes there. > > Adjust size to be unmapped by the gap that had been added in the vm_struct > prior. > > This fixes the hang in atari_platform_init() reported a long time ago, and > a similar one reported by Finn recently (addressed by removing ioremap() > use from the SWIM driver. > > Tested on my Falcon in 030 mode - untested but should work the same on > 040/060 (the extra page tables cleared there would never have been set up > anyway). > > Comment on whether the gap size should be considered in looking for a > suitable address to place the next mapping in get_io_area() would be welcome. 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. Obviously removing the gap would fix the issue as well, but that's more risky... > Signed-off-by: Michael Schmitz <[email protected]> > --- > arch/m68k/mm/kmap.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/m68k/mm/kmap.c b/arch/m68k/mm/kmap.c > index c2a3832..3b420f6 100644 > --- a/arch/m68k/mm/kmap.c > +++ b/arch/m68k/mm/kmap.c > @@ -89,7 +89,8 @@ 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); > + /* remove gap added in get_io_area() */ > + __iounmap(tmp->addr, tmp->size - IO_SIZE); > kfree(tmp); > return; > } Looks good to me, so I will apply and queue for v4.18 with the patch description slightly modified, but will wait one more day, in case someone has a comment. Thanks a lot! 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
