From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6713C4360F for ; Fri, 5 Apr 2019 13:53:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 95F6821738 for ; Fri, 5 Apr 2019 13:53:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DpqVwCVv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95F6821738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=k3lNA02Z5u3LbHeXjwsIAXuIN9IL6Wry73RyYydO1/U=; b=DpqVwCVvtoWXko OfZh00PEKQS1Zve1J3qCBXXq0Fqvah6czjJA/pQxvdKFJ+itG8k6wsZ7DlruqTlWi3ncBzQPlK8EJ THmcA8cMDTPDewNgJhVl7vW4M1RiDi/MzoZAT88B7yPs+ZpJQbAnkvNpyay0bqJVqjMoi0sGHF2jM FZ/jd0Z0S3engVrMBvmz41S9QpSWV4W1nvJfrBJ1zxKUJDqf8P9NkGnmZYDHlQgOgCqyBP2K/kfjP STknR5gijLFm9XpoJc+61F89fhw+bIgLQ1XbRKPkfcFp99Qd572iJ+Vj1VdvmJGWroi/TwS1Q73Lw 9pWkEevWURfqdFp10Ipg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCPHg-0005Xo-CU; Fri, 05 Apr 2019 13:53:32 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCPHc-0005XK-6s for linux-arm-kernel@lists.infradead.org; Fri, 05 Apr 2019 13:53:30 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F5484902D; Fri, 5 Apr 2019 13:53:27 +0000 (UTC) Received: from redhat.com (unknown [10.20.6.236]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7E13860C11; Fri, 5 Apr 2019 13:53:26 +0000 (UTC) Date: Fri, 5 Apr 2019 09:53:24 -0400 From: Jerome Glisse To: Anshuman Khandual Subject: Re: struct dev_pagemap corruption Message-ID: <20190405135324.GA5627@redhat.com> References: <7885dce0-edbe-db04-b5ec-bd271c9a0612@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7885dce0-edbe-db04-b5ec-bd271c9a0612@arm.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 05 Apr 2019 13:53:27 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190405_065328_290361_7E069AF6 X-CRM114-Status: GOOD ( 18.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-mm@kvack.org" , Dan Williams , Will Deacon , Linux ARM , Catalin Marinas Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 05, 2019 at 10:10:22AM +0530, Anshuman Khandual wrote: > Hello, > = > On arm64 platform "struct dev_pagemap" is getting corrupted during ZONE_D= EVICE > unmapping path through device_destroy(). Its device memory range end addr= ess > (pgmap->res.end) which is getting corrupted in this particular case. AFAI= CS > pgmap which gets initialized by the driver and mapped with devm_memremap_= pages() > should retain it's values during the unmapping path as well. Is this assu= mption > right ? > = > [ 62.779412] Call trace: > [ 62.779808] dump_backtrace+0x0/0x118 > [ 62.780460] show_stack+0x14/0x20 > [ 62.781204] dump_stack+0xa8/0xcc > [ 62.781941] devm_memremap_pages_release+0x24/0x1d8 > [ 62.783021] devm_action_release+0x10/0x18 > [ 62.783911] release_nodes+0x1b0/0x220 > [ 62.784732] devres_release_all+0x34/0x50 > [ 62.785623] device_release+0x24/0x90 > [ 62.786454] kobject_put+0x74/0xe8 > [ 62.787214] device_destroy+0x48/0x58 > [ 62.788041] zone_device_public_altmap_init+0x404/0x42c [zone_device_p= ublic_altmap] > [ 62.789675] do_one_initcall+0x74/0x190 > [ 62.790528] do_init_module+0x50/0x1c0 > [ 62.791346] load_module+0x1be4/0x2140 > [ 62.792192] __se_sys_finit_module+0xb8/0xc8 > [ 62.793128] __arm64_sys_finit_module+0x18/0x20 > [ 62.794128] el0_svc_handler+0x88/0x100 > [ 62.794989] el0_svc+0x8/0xc > = > The problem can be traced down here. > = > diff --git a/drivers/base/devres.c b/drivers/base/devres.c > index e038e2b3b7ea..2a410c88c596 100644 > --- a/drivers/base/devres.c > +++ b/drivers/base/devres.c > @@ -33,7 +33,7 @@ struct devres { > * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same > * buffer alignment as if it was allocated by plain kmalloc(). > */ > - u8 __aligned(ARCH_KMALLOC_MINALIGN) data[]; > + u8 __aligned(__alignof__(unsigned long long)) data[]; > }; I doubt that pgmap->res.end get corrupted during device_destroy() but given that the above changes fix the issue it kind of boggle the mind. If i where to debug this i would probably run a kernel with qemu -s to get a gdbserver and then attach gdb and set breakpoint on devm_memremap_pages() then when that trigger i would set memory watch on the pgmap->res.end (there use to be way to use memory as pmem through kernel boot option). A printk alternative solution is, assuming you only have one pgmap, add a global static struct pgmap *debug_pgmap =3D NULL; in memremap.c set that in devm_memremap_pages() and add an helper function: void debug_pgmap(const char *file, unsigned line) { printk(... file, line); printk(... debug_pmap->res.end); } In a header: #define DEBUG_PGMAP debug_pgmap(__FILE__, __LINE__); Then sprinkle DEBUG_PGMAP within device_destroy(), device_unregister(), device_release() and see when it get corrupted. gdb would be faster but sometime i got issue with memory watchpoint and vir= t. Cheers, J=E9r=F4me _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel