Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp502005pxu; Thu, 3 Dec 2020 05:57:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwRZ2Hc1Q3es1aENyG0xVw3Vw+Sl48tcPkeWP+Ysu6wPPZgtZUXQOGay/jQ5XkMPJt0kjPB X-Received: by 2002:a17:906:76c9:: with SMTP id q9mr2663226ejn.484.1607003876451; Thu, 03 Dec 2020 05:57:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607003876; cv=none; d=google.com; s=arc-20160816; b=z14xt7Gl7SRqc4GTl8J8YFuM1q9Hv2J77YDxOyU3bx3LJDF4xM4o486bjyIsTK3kfq VHv82FrpE0xdqqbq+Efu+ZuqTzLYQLzSvXz4r6VFxzfEp40tgycrqdczL7pntr8ycN/j dfvtVB219Y6A7IEAsLmLX/rxEX1Fm/7A5Vp+yt2ff/pH3y2/r3tWGntWR8zxqml5L3/M 4rLWsARhZpzDYo7t090I9J7xup4Y+QVYU6pPV4roqKavShTf1RV355qXhg7bUSmPADDn 5SsRoIGhl4Hpe9OWBC0SP8Y6t3zQF9lJA0Yt8xSbVwTdyX1OdRXEWm+B4ghIBcCrRD8j qvkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:dkim-signature; bh=dZoNrIv6luoppB1moIu/G1luuav3IB0WKtYk1t6susw=; b=dPDNziTsMN0hepVpc7P1X/HQbHH7onsUNTfa78gXbZ3khTqW1ZpohDW8cih3BAvoB0 LmJ2NP1xAvjVb36y+yZ0hOYoflL92gTyYqz3GUilwEL/uV1DUPNoYih5iUvWkU2t9e7E KwDIcgbTJffdJQdNwDToNIUiT0hgagHsju9MtgAhCXpKGEDrNoYqzthG8PzdTYFg58vC GFff+lumDA9aoUtlZ0Y2PkzcQ3p8i9ELmk0P6jiR2/Bg8qs9AT9mCFf9LslYScUOQjKR CnCbmujSQ5e1uqbWB+dnLdHX3OBUUXt69HkTC/BQyS/9HRY0oC4EGIaB7w7hJi2Hv4ZK XXhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@essensium.com header.s=google header.b=LYpEWPHf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=essensium.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zc17si1079902ejb.579.2020.12.03.05.57.31; Thu, 03 Dec 2020 05:57:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@essensium.com header.s=google header.b=LYpEWPHf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=essensium.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388521AbgLCNy5 (ORCPT + 99 others); Thu, 3 Dec 2020 08:54:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727065AbgLCNy5 (ORCPT ); Thu, 3 Dec 2020 08:54:57 -0500 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68A45C061A4F for ; Thu, 3 Dec 2020 05:54:11 -0800 (PST) Received: by mail-ej1-x641.google.com with SMTP id f23so3609567ejk.2 for ; Thu, 03 Dec 2020 05:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=essensium.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dZoNrIv6luoppB1moIu/G1luuav3IB0WKtYk1t6susw=; b=LYpEWPHfDqrC9YwMQyshIiEjce5BcSItpSX5YhpOE93vLaQOCbU1pk9guDLImSsk0Z pMpFdEKwJ8vLScBG/V+uihhfM5vqEVlWRSEHTPaXNF51AWdbJhk8DGFnzNU32M1O/XmJ wJnpOCPn8FsutWmSsbNIU3GJuRKkpaHswo4Obca6j3o//RbIZHJH0JYb1FCLOEIJAtqI ePsxmobQGeI39y0hskIzLGrfDvg345cXgv9yJi5B4qZccI5Rs8VlFgFF875PuFrKFZ/3 W7vAiGqk7jiZql/C7puS0MFB7PKaDaSP9fiZ0lDwT52XYx0E3jjlPwFO1CY8B1xpiGI9 GJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dZoNrIv6luoppB1moIu/G1luuav3IB0WKtYk1t6susw=; b=TzBp1xPnhXGTzt2T3EA+V5BMvAtsxoiCTdzJBSZ3bJNDe2P4fq4EzwwAATnXznBNxE 5RlIuOSc+Qc8CPGzcrJixxscIxLNhX7jy5aIWDalTX87zCjP5HyWWt7oqxoui9Gt58Mv ZIsDRlPISX7AdLYf/eWegkIoK7cbP0L0FTTPq9bU7wplcqYTLZV7ZPkNPhKhO2sc61pS ydGJbykEJLeyIfSvA/I9H8NrQDCRmGOLyZqLaMg6QBWmBbUssWe/ZnjJB92iIE8EXbkJ K3bZKf1IFb0xGxb4VFp1A8yIrVxYqp9Pymwv9JYFx4fp7LqJZE0QfAUu9v0Fk4ETPMfg b5LA== X-Gm-Message-State: AOAM533umHNU5FyiTF20jJWrFr/Y1+/nM78OcTjIw1UZgVMjnyo/SYy/ fR41Ik8AGrfPJtNcIDj0yBF8dtQuCP88IA== X-Received: by 2002:a17:906:b2d1:: with SMTP id cf17mr2656808ejb.281.1607003649968; Thu, 03 Dec 2020 05:54:09 -0800 (PST) Received: from [10.8.0.46] (ip-188-118-3-185.reverse.destiny.be. [188.118.3.185]) by smtp.gmail.com with ESMTPSA id u19sm912447ejg.16.2020.12.03.05.54.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 05:54:09 -0800 (PST) Subject: Re: [PATCH 2/4] net: freescale/fman-port: remove direct use of __devm_request_region To: Madalin Bucur , "David S. Miller" , Jakub Kicinski , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20201202161600.23738-1-patrick.havelange@essensium.com> <20201202161600.23738-2-patrick.havelange@essensium.com> From: Patrick Havelange Message-ID: <6e64e64d-0bbe-bab6-72a1-db6a304858f6@essensium.com> Date: Thu, 3 Dec 2020 14:54:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-12-03 09:44, Madalin Bucur wrote: >> -----Original Message----- >> From: Patrick Havelange >> Sent: 02 December 2020 18:16 >> To: Madalin Bucur ; David S. Miller >> ; Jakub Kicinski ; >> netdev@vger.kernel.org; linux-kernel@vger.kernel.org >> Cc: Patrick Havelange >> Subject: [PATCH 2/4] net: freescale/fman-port: remove direct use of >> __devm_request_region >> >> This driver was directly calling __devm_request_region with a specific >> resource on the stack as parameter. This is invalid as >> __devm_request_region expects the given resource passed as parameter >> to live longer than the call itself, as the pointer to the resource >> will be stored inside the internal struct used by the devres >> management. >> >> In addition to this issue, a related bug has been found by kmemleak >> with this trace : >> unreferenced object 0xc0000001efc01880 (size 64): >> comm "swapper/0", pid 1, jiffies 4294669078 (age 3620.536s) >> hex dump (first 32 bytes): >> 00 00 00 0f fe 4a c0 00 00 00 00 0f fe 4a cf ff .....J.......J.. >> c0 00 00 00 00 ee 9d 98 00 00 00 00 80 00 02 00 ................ >> backtrace: >> [] .alloc_resource+0xb8/0xe0 >> [] .__request_region+0x70/0x1c4 >> [] .__devm_request_region+0x8c/0x138 >> [] .fman_port_probe+0x170/0x420 >> [] .platform_drv_probe+0x84/0x108 >> [] .driver_probe_device+0x2c4/0x394 >> [] .__driver_attach+0x124/0x128 >> [] .bus_for_each_dev+0xb4/0x110 >> [] .driver_attach+0x34/0x4c >> [] .bus_add_driver+0x264/0x2a4 >> [] .driver_register+0x94/0x160 >> [] .__platform_driver_register+0x60/0x7c >> [] .fman_port_load+0x28/0x64 >> [] .do_one_initcall+0xd4/0x1a8 >> [] .kernel_init_freeable+0x1bc/0x2a4 >> [] .kernel_init+0x24/0x138 >> >> Indeed, the new resource (created in __request_region) will be linked >> to the given resource living on the stack, which will end its lifetime >> after the function calling __devm_request_region has finished. >> Meaning the new resource allocated is no longer reachable. >> >> Now that the main fman driver is no longer reserving the region >> used by fman-port, this previous hack is no longer needed >> and we can use the regular call to devm_request_mem_region instead, >> solving those bugs at the same time. >> >> Signed-off-by: Patrick Havelange >> --- >> drivers/net/ethernet/freescale/fman/fman_port.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c >> b/drivers/net/ethernet/freescale/fman/fman_port.c >> index d9baac0dbc7d..354974939d9d 100644 >> --- a/drivers/net/ethernet/freescale/fman/fman_port.c >> +++ b/drivers/net/ethernet/freescale/fman/fman_port.c >> @@ -1878,10 +1878,10 @@ static int fman_port_probe(struct platform_device >> *of_dev) >> >> of_node_put(port_node); >> >> - dev_res = __devm_request_region(port->dev, &res, res.start, >> - resource_size(&res), "fman-port"); >> + dev_res = devm_request_mem_region(port->dev, res.start, >> + resource_size(&res), "fman-port"); >> if (!dev_res) { >> - dev_err(port->dev, "%s: __devm_request_region() failed\n", >> + dev_err(port->dev, "%s: devm_request_mem_region() failed\n", >> __func__); >> err = -EINVAL; >> goto free_port; >> -- >> 2.17.1 > > Hi Patrick, > > please send a fix for the issue, targeting the net tree, separate from the > other change you are trying to introduce. We need a better explanation for > the latter and it should go through the net-next tree, if accepted. Hello, I've resent the series with a cover letter having a bit more explanations. I think all the patches should be applied on net, as they are linked to the same issue/resolution, and are not independent. BR, Patrick H.