Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp8456100rwi; Tue, 25 Oct 2022 07:00:23 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5zhojpngStTVK0wXMND3HrTE8LBRmbv6GX3V4yPwHS1QEZuFH1IynYPANrIqto1m0pAvZa X-Received: by 2002:a17:902:e202:b0:186:a478:3b35 with SMTP id u2-20020a170902e20200b00186a4783b35mr11680772plb.130.1666706423100; Tue, 25 Oct 2022 07:00:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666706423; cv=none; d=google.com; s=arc-20160816; b=dFM2n2Fds5aQ2OWTtx/1fUAfTPewxs9mBuMo3/jWq/JPz0i2FKwbaHthi6C2oJYXca PUDoCcO0CtrtLdA6hBhqZAUnLAWJaWEbnCnA1fVazt0+0cDwflBcMRznHrIbKWtpwJKf UfD+iJK9nyMwOJe6oPvRbZLDAkPXKmUy0X7B3KVM7R4pOpcN1sJ1vPkPId5Ttd3Bh/75 dWmrjG1ldLpTl2oTv/McjbQLZsReozXQ4daBwZMOuZZRbblvaRKzpEjW8kUhkukfzCJ8 uXc+2h55Bdr+GKC7MJwbOlfZNgnCjdkRl+YzjADkVQxAhE27ZPC4eEBdMAmTg8jwa39w Gp5g== 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:dkim-signature; bh=SyWiuSnRhOfuPHBSixwbMcIcH5CN3niLZenX1jS8ZEc=; b=gOv6wCWVOv+fBCuWzg9crZHOtR63twzxwt+GncSJcW6Buoa4oSMryh4a11JZ5CvZ0V 2fM2uo0/hvyuEWIXRjTnbg2nIE4N8rMnJLISGuCk9PafiWVorNu7iJYZMeuJT/o73ppf j7N2KzpyTy2a8ZtC+pOPNbSH5IHtEJ2Wh6PXsMv5P5JALLdwo3q5tdtlCuOw6Mn4zWwl Q1qM8mJ0ZMhJzavJ3zQ08tJhLmWKgl7LiJnw35iVx2TOSui8v99NYc1wnaC+hYvUyu8J od0bpIhx0/Qgskazytg3L8IzZPEiEZCvYdhKhNgerO71VeCVcYheALaczTi7MQyD9QYN CAGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Yop2QKol; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e14-20020a63e00e000000b004412f1207b9si3128782pgh.96.2022.10.25.07.00.04; Tue, 25 Oct 2022 07:00:23 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Yop2QKol; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232933AbiJYNhd (ORCPT + 99 others); Tue, 25 Oct 2022 09:37:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232956AbiJYNhP (ORCPT ); Tue, 25 Oct 2022 09:37:15 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04A601958C2; Tue, 25 Oct 2022 06:37:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A87A8B81D24; Tue, 25 Oct 2022 13:37:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BFB45C433C1; Tue, 25 Oct 2022 13:37:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666705027; bh=KMbVGpmzkqj97RY+FCnpBNDMX1gnC9wxo2uDdIdLrr8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Yop2QKol5jPn/4tN311qinrDKc3r6MuwidHA7ztZ+W2CjaphWSQOfPA0oyE6jdySn M3X6f8rrNSBVvXQRWc9YQS/DDkglYdn0IXTMjkrT/dn0DgEOMBsoRWyJHhliNTdJ5T oUQBIkG+OQsRMLYvzB1Mubg42ToCl432JX4wH6TM= Date: Tue, 25 Oct 2022 15:37:04 +0200 From: Greg KH To: Yang Yingliang Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, logang@deltatee.com, dan.j.williams@intel.com, hans.verkuil@cisco.com, alexandre.belloni@free-electrons.com, viro@zeniv.linux.org.uk Subject: Re: [PATCH v2] chardev: fix error handling in cdev_device_add() Message-ID: References: <20221025113957.693723-1-yangyingliang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 On Tue, Oct 25, 2022 at 09:20:12PM +0800, Yang Yingliang wrote: > Hi, Greg > > On 2022/10/25 19:50, Greg KH wrote: > > On Tue, Oct 25, 2022 at 07:39:57PM +0800, Yang Yingliang wrote: > > > While doing fault injection test, I got the following report: > > > > > > ------------[ cut here ]------------ > > > kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called. > > > WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0 > > > CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253 > > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 > > > RIP: 0010:kobject_put+0x23d/0x4e0 > > > Call Trace: > > > > > > cdev_device_add+0x15e/0x1b0 > > > __iio_device_register+0x13b4/0x1af0 [industrialio] > > > __devm_iio_device_register+0x22/0x90 [industrialio] > > > max517_probe+0x3d8/0x6b4 [max517] > > > i2c_device_probe+0xa81/0xc00 > > > > > > When device_add() is injected fault and returns error, if dev->devt is not set, > > > cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devt > > > in error path. > > Nit, please wrap your changelog text at 72 columns. > > > > > Fixes: 233ed09d7fda ("chardev: add helper function to register char devs with a struct device") > > > Signed-off-by: Yang Yingliang > > > --- > > > v1 -> v2: > > > Add information to update commit message. > > > v1 link: https://lore.kernel.org/lkml/1959fa74-b06c-b8bc-d14f-b71e5c4290ee@huawei.com/T/ > > > --- > > > fs/char_dev.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/fs/char_dev.c b/fs/char_dev.c > > > index ba0ded7842a7..3f667292608c 100644 > > > --- a/fs/char_dev.c > > > +++ b/fs/char_dev.c > > > @@ -547,7 +547,7 @@ int cdev_device_add(struct cdev *cdev, struct device *dev) > > > } > > > rc = device_add(dev); > > > - if (rc) > > > + if (rc && dev->devt) > > No, this is a layering violation and one that you do not know is really > > going to be true or not. the devt being present, or not, should not be > > an issue of if the device_add failed or not. This isn't correct, sorry. > Do you mean it's not a bug or the warn can be ignored or it's bug in driver > ? > I see devt is checked before calling cdev_del() in cdev_device_del(). Ah! The core doesn't set devt, the caller has that set. That makes more sense now, sorry for the confusion on my side. Yes, this looks correct, the diff didn't have the full context and I was confused. I'll go queue this up, very nice work. greg k-h