Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3317339imu; Sun, 11 Nov 2018 12:14:03 -0800 (PST) X-Google-Smtp-Source: AJdET5cCuyCyngOrk//+cm/dGFsCxS/qIg08PGBByeLdEqlqTUq693WNBpPhEpMu3NW7GVeG74ts X-Received: by 2002:a62:c5c6:: with SMTP id j189-v6mr17909734pfg.194.1541967242942; Sun, 11 Nov 2018 12:14:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541967242; cv=none; d=google.com; s=arc-20160816; b=n7eu6+1u0lssLzsHDKdFGzIS54AldOLNN2n08c3lBwi2m/Lw/EVg8vEfPpaojOSjr3 hDbEY1ZE99Fc6Wfmf9p/pfxcIj7EvdJ5VCW/ulhHhpd+cjYX4JuQzR72JibzmuH12EF2 6XLalUHh88DViET/DpZ02NFLw/1CAoiSa09pW6v0kd/cyy68gW1n/njGOf3X/hH/IzOH 8gzhGtB1tfTVx39kiQm9fU2JO4ZA384nzvxzxHgSA1bp9RKRF0IJuHhF7Wu6Jzqf045r n2JGg4/iuq5PhEeTIZXMB5Cuo6dzq9bD/AOwTWCzqOQYaTj3TRwBy+6wbPxL4MV5aJ/f qxew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=n2JwzkKqU6QjZ5hADU5PzrP0vVhjNgod4pDIknHqixA=; b=qjcR0S8QBdchxDbisQ3JDg05bd6g2/hDCP6TdSNdlTWY9HZxlUCQSlE7ehhBGqCqtt iBXEEjl6AFUnmcqvW0TGl6c5UwLhSPbbEJdqvmEJRUIoQa93FIPeLVvIKRvmTQLKANXh ZXpsjWoDFFlzkW530sqhIONYNVXPKo4p+5VjCz1JBdHz9b4KtMyv/wW5YGIENQdl8Gml 5aAtzb1OyOeaTy9bOOp/r9bUQ+QSzlQQktoq5pHyhHuyVeZfKLmnW5oZAYCdgcv348p/ TWchM+ZhIGXELaFgX0yKGHfRC+bO2PYCo3ZtiwblqapHJXodYU4V69qlyuPdq+z6cB4E 8lDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p80-v6si15142373pfk.275.2018.11.11.12.13.47; Sun, 11 Nov 2018 12:14:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731637AbeKLGCl (ORCPT + 99 others); Mon, 12 Nov 2018 01:02:41 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:52696 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726709AbeKLGCk (ORCPT ); Mon, 12 Nov 2018 01:02:40 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvt6-0000oJ-Pe; Sun, 11 Nov 2018 19:59:16 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsQ-0001Sq-6V; Sun, 11 Nov 2018 19:58:34 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Michael Schmitz" , "Geert Uytterhoeven" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 082/366] m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap() In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Michael Schmitz commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55 upstream. If 020/030 support is enabled, 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/060, unmapping of page table entries does not check for a valid 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). Signed-off-by: Michael Schmitz [geert: Minor commit description improvements] [geert: This was fixed in 2.4.23, but not in 2.5.x] Signed-off-by: Geert Uytterhoeven Signed-off-by: Ben Hutchings --- arch/m68k/mm/kmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/m68k/mm/kmap.c +++ b/arch/m68k/mm/kmap.c @@ -88,7 +88,8 @@ static inline void free_io_area(void *ad 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; }