Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D6A9C6FA8E for ; Thu, 2 Mar 2023 15:48:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229693AbjCBPsx (ORCPT ); Thu, 2 Mar 2023 10:48:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229486AbjCBPsu (ORCPT ); Thu, 2 Mar 2023 10:48:50 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C223D6EAE for ; Thu, 2 Mar 2023 07:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677772088; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=07sLndxtEbNcERZvee6i0lRr3/Y/p7RWfWIjrJTakUw=; b=RrtFQsum9nkTOzbQOV/sDgYVJfstKS06HYQak4ZLrz0WBWrSjQZiDS73CGlfGqEljz/h+I TibqEKwv0i15MiZ/IfobyGpE97pt3pmLdW/Wes4FIaDhAn8ciqPjOtTGwWrBZ21ZF1gbho AnKMgAOstK2QmsXbLq1Ii441q++p+dU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-44-okuLD5UbPwOSWhhuek_S9A-1; Thu, 02 Mar 2023 10:48:06 -0500 X-MC-Unique: okuLD5UbPwOSWhhuek_S9A-1 Received: by mail-wm1-f70.google.com with SMTP id m28-20020a05600c3b1c00b003e7d4662b83so1467851wms.0 for ; Thu, 02 Mar 2023 07:48:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677772084; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=07sLndxtEbNcERZvee6i0lRr3/Y/p7RWfWIjrJTakUw=; b=PL7ZK94Gjfkvcumw4FDL6La8RQbtqEzQbyBEviIZTL1b+GbOlbKW9/vzthv9+wZcKN ERlvWE8bBYaKByLR+96KzIJRaIwAxQGdeAMOaIH9oQPsWsXn+cm3PZvvEISnLELLshXy kuLO8jWWtW3pTbtpoVD4IPT8Unt1+PMoOC7l/ZEFkeUVTucqB8Nq/27WDMi+ZdEFceGa l42wTKUgNh/TA0ZHYyaPjcUxWtOyh510Ty4tKOAznjKHpvJ44aL+/VxqOR+AVcswdqdY MRjEb2R9edZzETWa1bobj4o28aM7Fj+vRIL9WcHg3AUVFc8Vsmb1CSIKUxZp/iV2JpjY US5A== X-Gm-Message-State: AO0yUKUMeIvdVOjv39I2gVXLmlN0frDeCdUXEIXcnJxGd/gAM5pf0IxG UDcIsb3l/Mcc35N9lN8wCpUv+VxCJlsR6RBDKJ32sX4luHc5221sbTCW3eavzIcJPvGPVwRtzNd 3WfVhr5f/yaQJ7Itvdx2QvpHr X-Received: by 2002:a05:6000:1a42:b0:2c3:be89:7c2a with SMTP id t2-20020a0560001a4200b002c3be897c2amr1809002wry.13.1677772084120; Thu, 02 Mar 2023 07:48:04 -0800 (PST) X-Google-Smtp-Source: AK7set/EzktI0OlHucSuQTWKTKC3fqx8GzoJhXbuJEu5Rqstra/4hZCkq7D6l1IWXwedBvmq/luXbw== X-Received: by 2002:a05:6000:1a42:b0:2c3:be89:7c2a with SMTP id t2-20020a0560001a4200b002c3be897c2amr1808989wry.13.1677772083843; Thu, 02 Mar 2023 07:48:03 -0800 (PST) Received: from sgarzare-redhat (c-115-213.cust-q.wadsl.it. [212.43.115.213]) by smtp.gmail.com with ESMTPSA id s18-20020a7bc392000000b003eb20d4d4a8sm3202128wmj.44.2023.03.02.07.48.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 07:48:03 -0800 (PST) Date: Thu, 2 Mar 2023 16:48:00 +0100 From: Stefano Garzarella To: Simon Horman Cc: virtualization@lists.linux-foundation.org, Andrey Zhadchenko , eperezma@redhat.com, netdev@vger.kernel.org, stefanha@redhat.com, linux-kernel@vger.kernel.org, Jason Wang , "Michael S. Tsirkin" , kvm@vger.kernel.org Subject: Re: [PATCH v2 6/8] vdpa_sim: use kthread worker Message-ID: <20230302154800.z3i4fpjlvtb74efu@sgarzare-redhat> References: <20230302113421.174582-1-sgarzare@redhat.com> <20230302113421.174582-7-sgarzare@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 02, 2023 at 04:30:04PM +0100, Simon Horman wrote: >On Thu, Mar 02, 2023 at 12:34:19PM +0100, Stefano Garzarella wrote: >> Let's use our own kthread to run device jobs. >> This allows us more flexibility, especially we can attach the kthread >> to the user address space when vDPA uses user's VA. >> >> Signed-off-by: Stefano Garzarella >> --- >> drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 ++- >> drivers/vdpa/vdpa_sim/vdpa_sim.c | 17 ++++++++++++----- >> 2 files changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h >> index acee20faaf6a..ce83f9130a5d 100644 >> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h >> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h >> @@ -57,7 +57,8 @@ struct vdpasim_dev_attr { >> struct vdpasim { >> struct vdpa_device vdpa; >> struct vdpasim_virtqueue *vqs; >> - struct work_struct work; >> + struct kthread_worker *worker; >> + struct kthread_work work; >> struct vdpasim_dev_attr dev_attr; >> /* spinlock to synchronize virtqueue state */ >> spinlock_t lock; >> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> index a6ee830efc38..6feb29726c2a 100644 >> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> @@ -11,8 +11,8 @@ >> #include >> #include >> #include >> +#include >> #include >> -#include >> #include >> #include >> #include >> @@ -116,7 +116,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim) >> static const struct vdpa_config_ops vdpasim_config_ops; >> static const struct vdpa_config_ops vdpasim_batch_config_ops; >> >> -static void vdpasim_work_fn(struct work_struct *work) >> +static void vdpasim_work_fn(struct kthread_work *work) >> { >> struct vdpasim *vdpasim = container_of(work, struct vdpasim, work); >> >> @@ -159,7 +159,13 @@ struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *dev_attr, >> >> vdpasim = vdpa_to_sim(vdpa); >> vdpasim->dev_attr = *dev_attr; >> - INIT_WORK(&vdpasim->work, vdpasim_work_fn); >> + >> + kthread_init_work(&vdpasim->work, vdpasim_work_fn); >> + vdpasim->worker = kthread_create_worker(0, "vDPA sim worker: %s", >> + dev_attr->name); >> + if (IS_ERR(vdpasim->worker)) >> + goto err_iommu; > >Branching to err_iommu will result in a call to put_device(dev)... Good catch! > >> + >> spin_lock_init(&vdpasim->lock); >> spin_lock_init(&vdpasim->iommu_lock); > >... but dev is not initialised until the line following this hunk, >which is: > > dev = &vdpasim->vdpa.dev; > >In order to avoid leaking dev I _think_ the correct approach >is to move the initialisation of dev above the branch to >err_iommu, perhaps above the call to kthread_init_work() >is a good place. Yep, I agree. I'll fix in v3. Thanks, Stefano > >This does move the assignment outside the locks above. >But I _think_ that is ok. > >> @@ -212,7 +218,7 @@ EXPORT_SYMBOL_GPL(vdpasim_create); >> >> void vdpasim_schedule_work(struct vdpasim *vdpasim) >> { >> - schedule_work(&vdpasim->work); >> + kthread_queue_work(vdpasim->worker, &vdpasim->work); >> } >> EXPORT_SYMBOL_GPL(vdpasim_schedule_work); >> >> @@ -612,7 +618,8 @@ static void vdpasim_free(struct vdpa_device *vdpa) >> struct vdpasim *vdpasim = vdpa_to_sim(vdpa); >> int i; >> >> - cancel_work_sync(&vdpasim->work); >> + kthread_cancel_work_sync(&vdpasim->work); >> + kthread_destroy_worker(vdpasim->worker); >> >> for (i = 0; i < vdpasim->dev_attr.nvqs; i++) { >> vringh_kiov_cleanup(&vdpasim->vqs[i].out_iov); >> -- >> 2.39.2 >> >