Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp3302335rwo; Fri, 4 Aug 2023 02:44:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGFf2g2AACTrme77LSIW0G1dGV84paETyzVI3/Di3vo6OivobXEKi1JDpIN9BSNjtZYnKos X-Received: by 2002:aca:1b11:0:b0:3a3:fbf0:37db with SMTP id b17-20020aca1b11000000b003a3fbf037dbmr1143674oib.59.1691142243823; Fri, 04 Aug 2023 02:44:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691142243; cv=none; d=google.com; s=arc-20160816; b=x9Og01Fkl5dtxiPmjjkghYsvfGLUyLh5zkZROXEr43GrB3hxtbT6YUq38YwmTbPCLo e0CS19Gdms/je2+YTG4xxpNT314i3kB08P9G/gzNi6TOor4jW2IzpJ5etAojwjmxjlix LxDEBi0TtlnzQ/Nh6TbIRbtnycHtk+Hrb5ouzoFI76IxPlpUYKy4LThKBAId4/p/TVxE uxQF8Z7oTKwQ62fXNpSMatH1YIMQsEh8y+YnVXYBME71MT/Qg5u/nZx+0mX6T1JzRokd LKyIoc6JnH+M0oSIt6yYuAuR3w82IPntctdjZJppon1ilbT1Drc8Zs04W0E4qxcUw1MS nZkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Enh0RrSaBP/AX8x1Wb+gg7ZxfBvIZQaNz+WsfZMhyW8=; fh=TsKbnG1eU0bo7PJz89IqGr7HG4aUllMrbvtMeJCE3/g=; b=EoTZFvzK8tGQVf1A6HLR8a7paTI6d6W6cjZ2xsoCBCFJZYRWsUD8c+wgiCJoXyNwNd rXA004quvzLKp/Wx3OH601K7YuJttd+ihr3v/I32/RL1X4qhky8B+VR92m0A3DwEZpTO 8yhvo/+ZD/S6A+dpN60si+2bnMO5IZAX5fCL9oSQIGK23Bgsyb8KInm6oOmku4ng9N7C P24w+pS8HNu0GPPhrFvOvWEcMmalvRR3mFrvjfkJpOh7XhILLS2J+lqGwOuJmkFQdN0h mGcjaLwSyFL4DRf1yJzibuq3mRzdGwmQUssxX7c5mF5Fk1iAqfMY0NmzWBjOgrVGoX7m b89Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p10-20020a63fe0a000000b0055fdd303745si1559295pgh.421.2023.08.04.02.43.52; Fri, 04 Aug 2023 02:44:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230222AbjHDJXa (ORCPT + 99 others); Fri, 4 Aug 2023 05:23:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230364AbjHDJWy (ORCPT ); Fri, 4 Aug 2023 05:22:54 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 111EC5245; Fri, 4 Aug 2023 02:21:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 75C0980F7; Fri, 4 Aug 2023 09:21:06 +0000 (UTC) Date: Fri, 4 Aug 2023 12:21:05 +0300 From: Tony Lindgren To: Jiri Slaby Cc: Greg Kroah-Hartman , Andy Shevchenko , Andy Shevchenko , Dhruva Gole , Ilpo =?utf-8?B?SsOkcnZpbmVu?= , John Ogness , Johan Hovold , Sebastian Andrzej Siewior , Vignesh Raghavendra , linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, Tomi Valkeinen Subject: Re: [PATCH] serial: core: Fix kmemleak issue for serial core device remove Message-ID: <20230804092105.GI14799@atomide.com> References: <20230804090909.51529-1-tony@atomide.com> <959278d8-d76e-fda8-6d0d-64e284c0ba1b@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <959278d8-d76e-fda8-6d0d-64e284c0ba1b@kernel.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jiri Slaby [230804 09:16]: > On 04. 08. 23, 11:09, Tony Lindgren wrote: > > Kmemleak reports issues for serial8250 ports after the hardware specific > > driver takes over on boot as noted by Tomi. > > > > The kerneldoc for device_initialize() says we must call device_put() > > after calling device_initialize(). We are calling device_put() on the > > error path, but are missing it from the device remove path. This causes > > release() to never get called for the devices on remove. > > > > Let's add the missing put_device() calls for both serial ctrl and > > port devices. > > > > Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") > > Reported-by: Tomi Valkeinen > > Signed-off-by: Tony Lindgren > > --- > > drivers/tty/serial/serial_base_bus.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c > > --- a/drivers/tty/serial/serial_base_bus.c > > +++ b/drivers/tty/serial/serial_base_bus.c > > @@ -99,6 +99,7 @@ void serial_base_ctrl_device_remove(struct serial_ctrl_device *ctrl_dev) > > return; > > device_del(&ctrl_dev->dev); > > + put_device(&ctrl_dev->dev); > > } > > struct serial_ctrl_device *serial_base_ctrl_add(struct uart_port *port, > > @@ -174,6 +175,7 @@ void serial_base_port_device_remove(struct serial_port_device *port_dev) > > return; > > device_del(&port_dev->dev); > > + put_device(&port_dev->dev); > > I didn't check the code, but device_unregister()? I thought about that as it does the same, but since we're not calling device_register() I felt it would be and unpaired call. No objections to changing to use device_unregister() naturally if folks prefer that. Regards, Tony