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=-6.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 0CEFAC433E7 for ; Mon, 19 Oct 2020 15:44:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C84822284 for ; Mon, 19 Oct 2020 15:44:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bytedance-com.20150623.gappssmtp.com header.i=@bytedance-com.20150623.gappssmtp.com header.b="KSEfVetm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C84822284 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 40B4E6B0072; Mon, 19 Oct 2020 11:44:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BCFE6B0074; Mon, 19 Oct 2020 11:44:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AC2D6B0075; Mon, 19 Oct 2020 11:44:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id F0B2F6B0072 for ; Mon, 19 Oct 2020 11:44:49 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8C8F482C4F30 for ; Mon, 19 Oct 2020 15:44:49 +0000 (UTC) X-FDA: 77389097898.01.brain01_060a1b627238 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 630FB100473A9 for ; Mon, 19 Oct 2020 15:44:49 +0000 (UTC) X-HE-Tag: brain01_060a1b627238 X-Filterd-Recvd-Size: 7419 Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Mon, 19 Oct 2020 15:44:48 +0000 (UTC) Received: by mail-ej1-f68.google.com with SMTP id p5so14595534ejj.2 for ; Mon, 19 Oct 2020 08:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2mF3B0fuuNszPl6j+tIHSOj4JFvDonl1oow4TWcY6vg=; b=KSEfVetmGTtSHGHirWnOuKQjLosysvDjlooiDwr0vGgJ+xvJUZXq/U8FzJ75UOHo3J Gca7RnGSrSkchI6gWpoHn5gZulfKmw9PMZs2b4RjF0kXuPhvW9Bf9HZIzNBA7/2one2c t62dEkZcjn4YEWta/55CWBNlwdAnTK2pAzRiN2IG7PEfwmB7S8d2i8TQNPuKu89FlncA rw8UorxPrn75OT7jkbgvzzwX8L5loRgHKii/4QenTnJIb1SM9rthcCbkDStIlMdf0msx kjKv8g7o8moYCRaR3URK8V2OnP6NjQ6vZzFn4VWnkLdyKy4Y/j8U3TnjNi1PxZcEGHxm lJbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2mF3B0fuuNszPl6j+tIHSOj4JFvDonl1oow4TWcY6vg=; b=CQvNolwbxWF/F3QhpPBmBJPcK4dM/pypnEk7LQStmftYeLuP1Koz0WTCVPMT4AGorQ j4CnMmMMxx+QJXF2fzip6/pfDhQ01uAz+SGib5damHEu+6g7I6DqzKPin97dwHbffod+ 4Ej8H2uQjU+kRS8Stn42CFhCRYIcC3w50wNNSVxor24+R5NpAns/EZzcPpgmaq/jxCAN /vXoztJO+fdV8VVefWLQlZmwcNDdqx+JQ6PrY0PrKKF2kJXs12Ejg+8kqQinqzgVMBtd /mDpfe4orGVA/DiPrbzbPmZ4h7XATvXGTwXZsPCd/Ss0tZGOOpSbIAQe0AUuo8wqKTGl tQOA== X-Gm-Message-State: AOAM5333WJEteDnV4a4eKNc4fCJ65jWieR9I1/1NE6hyHm49Ihj4HmWQ pP9tT1vJtS2mBEm1tdW4JQjXEHoKkHQgP5gOxwDs X-Google-Smtp-Source: ABdhPJxv+6kVY0KwzNgu48FbM/62wqouJQBX+SACsOH2PDTgMZv/DzuVJCorkxJeLZ03iwsYCGxWg4wt8Vx5JpyGx1M= X-Received: by 2002:a17:907:2089:: with SMTP id pv9mr471080ejb.427.1603122287488; Mon, 19 Oct 2020 08:44:47 -0700 (PDT) MIME-Version: 1.0 References: <20201019145623.671-1-xieyongji@bytedance.com> <20201019145623.671-4-xieyongji@bytedance.com> <20201019110359-mutt-send-email-mst@kernel.org> In-Reply-To: <20201019110359-mutt-send-email-mst@kernel.org> From: =?UTF-8?B?6LCi5rC45ZCJ?= Date: Mon, 19 Oct 2020 23:44:36 +0800 Message-ID: Subject: Re: [External] Re: [RFC 3/4] vduse: grab the module's references until there is no vduse device To: "Michael S. Tsirkin" Cc: jasowang@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, virtualization@lists.linux-foundation.org Content-Type: multipart/alternative; boundary="0000000000007a631705b207fe48" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --0000000000007a631705b207fe48 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 19, 2020 at 11:05 PM Michael S. Tsirkin wrote: > On Mon, Oct 19, 2020 at 10:56:22PM +0800, Xie Yongji wrote: > > The module should not be unloaded if any vduse device exists. > > So increase the module's reference count when creating vduse > > device. And the reference count is kept until the device is > > destroyed. > > > > Signed-off-by: Xie Yongji > > --- > > drivers/vdpa/vdpa_user/vduse_dev.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c > b/drivers/vdpa/vdpa_user/vduse_dev.c > > index 6787ba66725c..f04aa02de8c1 100644 > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > @@ -887,6 +887,7 @@ static int vduse_destroy_dev(u32 id) > > kfree(dev->vqs); > > vduse_iova_domain_destroy(dev->domain); > > vduse_dev_destroy(dev); > > + module_put(THIS_MODULE); > > > > return 0; > > } > > @@ -931,6 +932,7 @@ static int vduse_create_dev(struct vduse_dev_config > *config) > > > > dev->connected = true; > > list_add(&dev->list, &vduse_devs); > > + __module_get(THIS_MODULE); > > > > return fd; > > err_fd: > > This kind of thing is usually an indicator of a bug. E.g. > if the refcount drops to 0 on module_put(THIS_MODULE) it > will be unloaded and the following return will not run. > > Should this happen? The refcount should be only decreased to 0 after the misc_device is closed? Thanks, Yongji > > > > -- > > 2.25.1 > > --0000000000007a631705b207fe48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 19, 2020 at 11:05 PM Mich= ael S. Tsirkin <mst@redhat.com>= wrote:
On Mon, = Oct 19, 2020 at 10:56:22PM +0800, Xie Yongji wrote:
> The module should not be unloaded if any vduse device exists.
> So increase the module's reference count when creating vduse
> device. And the reference count is kept until the device is
> destroyed.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
>=C2=A0 drivers/vdpa/vdpa_user/vduse_dev.c | 2 ++
>=C2=A0 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_us= er/vduse_dev.c
> index 6787ba66725c..f04aa02de8c1 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -887,6 +887,7 @@ static int vduse_destroy_dev(u32 id)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kfree(dev->vqs);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0vduse_iova_domain_destroy(dev->domain); >=C2=A0 =C2=A0 =C2=A0 =C2=A0vduse_dev_destroy(dev);
> +=C2=A0 =C2=A0 =C2=A0module_put(THIS_MODULE);
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
>=C2=A0 }
> @@ -931,6 +932,7 @@ static int vduse_create_dev(struct vduse_dev_confi= g *config)
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0dev->connected =3D true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0list_add(&dev->list, &vduse_devs)= ;
> +=C2=A0 =C2=A0 =C2=A0__module_get(THIS_MODULE);
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return fd;
>=C2=A0 err_fd:

This kind of thing is usually an indicator of a bug. E.g.
if the refcount drops to 0 on module_put(THIS_MODULE) it
will be unloaded and the following return will not run.


Should this happen?=C2=A0 The refcount= should be only decreased to 0 after the misc_device is closed?
<= br>
Thanks,
Yongji
=C2=A0

> --
> 2.25.1

--0000000000007a631705b207fe48--