Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp313226ybe; Mon, 2 Sep 2019 01:57:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqxEyBL2dUU++ryG1460Smocf0n1u7uO8nPW5JtH3WRF8cy+GoZYtA/KV2/SSnJZo0KAbFX6 X-Received: by 2002:a17:90a:1b22:: with SMTP id q31mr11981550pjq.61.1567414666327; Mon, 02 Sep 2019 01:57:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567414666; cv=none; d=google.com; s=arc-20160816; b=H8U3+vxEv0Viu1ltqLKmc+Bh7dqR59gKx46jeAbdy5UdK7jFnls1TCLcwG/JrOPQ1T rR+dDCd0HU4FM+B+LYWZ/9Xlky43edSg5+jiYo5LZSDd/Z9tfZ7hBZuflSMo8ThOCr8M KW5k+eCLLHsPwcmTp7a1gzC1+QoR7IQEI027hGXn1rMDPFfRIgdqFHSrSyVQwMdKBDXb Uz2sXhuPORW3xHhhEop3gODq5opSaEjI1TSTbdemF2El3Glc7t7ttOZDbxnAsS8vdO90 FHYZSJ8SuBTbKQtC5GtkEEtcmgYiSUm65TAWpbsQMg57X1OGr8zR80thnh+JXAhsurMI NasQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=W/qJOS+3doJad9FKIIMuPQ1bcnW8AKb+VjVh2oYxTaM=; b=uCJAFY9wOkKX2h3m4Gj5nLkRnj9/eE74jP4U2qpvP1IwQQcQLD6pe1+ZT0K5CQ/vVK mbQe0vs+1x5tp0qnDH7Q7Og8sce9wwYsfR8uPhtUSUioZSDvD4oMijrPjBuJ7HmY7LkK B0fqJnLZQw0QCIMLkIhIoaqU2YiXa0JbeCb9HELLO9woidhOlcitIuOrs0kGUKGWihD7 EnF/tnyjdHC+eyd5sDowOiVn05v2WbPNQb0qtUO1xBJjJPqWtVSyKmkeAa17MlBazSB2 vo2+WNousiXNuPRw+Tm7nsgmkJUN3P9VXAFLiFqtMj+bXAgVANDvzLKtrcpDkGeXmYkN pAdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=skhlZgoe; 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 t2si11121299pgq.488.2019.09.02.01.57.31; Mon, 02 Sep 2019 01:57:46 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=skhlZgoe; 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 S1730791AbfIBIwR (ORCPT + 99 others); Mon, 2 Sep 2019 04:52:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:50880 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730694AbfIBIwQ (ORCPT ); Mon, 2 Sep 2019 04:52:16 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4DFC22173E; Mon, 2 Sep 2019 08:52:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567414335; bh=7q45iXzXunLrEfdieCJt0HR3qgt6eiWPJ1ACWX2hDCM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=skhlZgoeLultlGdvSHZDVs5Z26meHCHmYjdwNPNOSUDnaTsB4QfP4YKiizkVJFGs8 jTy0B2ochghJttd+sPsFx3dgHAE6fMzFvBEPiEJel2R6dBbOop7z1sJLkAou+A0nEn conUjlhWV2CkOQAet8efuNQFwsMLU6Hdh5PATxj4= Date: Mon, 2 Sep 2019 10:52:13 +0200 From: Greg Kroah-Hartman To: zhangfei Cc: Arnd Bergmann , jonathan.cameron@huawei.com, kenneth-lee-2012@foxmail.com, Wangzhou , linux-accelerators@lists.ozlabs.org, linux-kernel@vger.kernel.org, Kenneth Lee , Zaibo Xu Subject: Re: [PATCH v2 2/2] uacce: add uacce driver Message-ID: <20190902085213.GB18410@kroah.com> References: <1566998876-31770-1-git-send-email-zhangfei.gao@linaro.org> <1566998876-31770-3-git-send-email-zhangfei.gao@linaro.org> <20190828152201.GA10163@kroah.com> <5c2b0889-ea05-1ecd-fe5b-40611bd31945@linaro.org> <20190829095439.GA13915@kroah.com> <39f792df-e3e3-eaa6-f78b-bf325b79f1b7@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 02, 2019 at 11:44:16AM +0800, zhangfei wrote: > > Hi, Greg > > On 2019/8/30 下午10:54, zhangfei wrote: > > > > On 2019/8/28 下午11:22, Greg Kroah-Hartman wrote: > > > > > On Wed, Aug 28, 2019 at 09:27:56PM +0800, Zhangfei Gao wrote: > > > > > > +struct uacce { > > > > > > +    const char *drv_name; > > > > > > +    const char *algs; > > > > > > +    const char *api_ver; > > > > > > +    unsigned int flags; > > > > > > +    unsigned long qf_pg_start[UACCE_QFRT_MAX]; > > > > > > +    struct uacce_ops *ops; > > > > > > +    struct device *pdev; > > > > > > +    bool is_vf; > > > > > > +    u32 dev_id; > > > > > > +    struct cdev cdev; > > > > > > +    struct device dev; > > > > > > +    void *priv; > > > > > > +    atomic_t state; > > > > > > +    int prot; > > > > > > +    struct mutex q_lock; > > > > > > +    struct list_head qs; > > > > > > +}; > > > > > At a quick glance, this problem really stood out to me.  You CAN NOT > > > > > have two different objects within a structure that have different > > > > > lifetime rules and reference counts.  You do that here with both a > > > > > 'struct cdev' and a 'struct device'.  Pick one or the other, but never > > > > > both. > > > > > > > > > > I would recommend using a 'struct device' and then a 'struct cdev *'. > > > > > That way you get the advantage of using the driver model properly, and > > > > > then just adding your char device node pointer to "the side" which > > > > > interacts with this device. > > > > > > > > > > Then you might want to call this "struct uacce_device" :) > I think I understand now. > 'struct device' and then a 'struct cdev' have different refcounts. > Using 'struct cdev *', the release is not in uacce.c, but controlled by cdev > itself. > So uacce is decoupled with cdev. > > //Using 'struct cdev *' > cdev_alloc->cdev_dynamic_release:kfree(p); > uacce_destroy_chrdev: > cdev_device_del->cdev_del(cdev)->kobject_put(&p->kobj); > if (refcount--) == 0 > cdev_dynamic_release->kfree(p); > > //Using 'struct device' > cdev_init->cdev_default_release > cdev is freed in uacce.c, > So 'struct device' and then a 'struct cdev' are bind together, while cdev > and uacce->dev have different refcount. Yes, that is exactly the reason, glad you figured it out. thanks, greg k-h