Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp591742iog; Wed, 15 Jun 2022 08:17:58 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tFtDdP2vDnrgOBxGFj2YdDgSIHgqpMRX1I53EhqG4nXlXHftfWMTv67p91sWrjYKNeYR86 X-Received: by 2002:a63:2125:0:b0:405:1652:668 with SMTP id h37-20020a632125000000b0040516520668mr284344pgh.400.1655306277916; Wed, 15 Jun 2022 08:17:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655306277; cv=none; d=google.com; s=arc-20160816; b=oLiwf4Z8XRhsj9tVXpmZtvAUaOSYevehP4Rn++EaM0S5OnU8PAKl7+gERUDxCzAPl7 GUeEaoMDD89gW5cj/PV1anDunUhjF+6/75yuEFOQMrNeRs4EP76J1geXl+CZih/mop5a TyWQb4irIUAVQED9J4WvdT0zgvPuWm4N/vNCC6mhv98Zf8G26jBFAzoZFzayi8H0MZpi oMpzqzEO++iYn2VjDT4vOYwZt0wD5qMAyvgk8bb2Qnmd9/WtCrHtwHFWEPzV2DUgUIcA DkfKp4mRSGtG0A00D9fjBvnYOlQb/giB9Pl33Jd4iWu0aaXPuMfzndTwVOqDfNPtxeRo cJvQ== 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=Wau0fGW8yZsKjnuoyb0VTR4qVyMVH48h3qQAcCmJxHM=; b=WG2jERiaAqDKlqSlTS8NW2dsLAzOdkmDyd6caqG3/NOJ8lfKObdL6Jf/zwtuGfzLRS 3ZZC17dJeUboMftwMW1Cfq3LRwo15FIgVreWXGvlFf30DCiJobQRSDEmw5y26l8yvQgU tDzghT+zNx4CSeW2O/AAKcPIzw6JuJd/fklbSI7EA//1AnJvfe31jT7X3wSOUGsNZI5h bsA+sbZ5T1vnOyYLzh8mTCBW3xarIBo71xHIbZ1pyy1Uz63KM+0LEh9z/ns9wlwsesjv hYdvuih3lKmM4UVwQWgmb2JBon87IiVqvHmaaNlVU293eCTTvKW30nGxYHzAt3ProDdE NiLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gsDwJdxl; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lj1-20020a17090b344100b001d6d8ba05a5si2519897pjb.125.2022.06.15.08.17.34; Wed, 15 Jun 2022 08:17:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-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=@linaro.org header.s=google header.b=gsDwJdxl; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346960AbiFOPQb (ORCPT + 99 others); Wed, 15 Jun 2022 11:16:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347318AbiFOPQa (ORCPT ); Wed, 15 Jun 2022 11:16:30 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 342223DA4C for ; Wed, 15 Jun 2022 08:16:29 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id i81-20020a1c3b54000000b0039c76434147so1342164wma.1 for ; Wed, 15 Jun 2022 08:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Wau0fGW8yZsKjnuoyb0VTR4qVyMVH48h3qQAcCmJxHM=; b=gsDwJdxlq2oa/E5drVyaHd8AqIB5EsHJGZX+yJs4Bh3IZRZWhyJg1tzAiW9vxJl9/Q I6bZWcAHui00mntM2ACoE/BL7ZEWL8139NyKHCSm8617afMK4Qeclks5GiCSExeiU6QX YOaHEWYs3I3Hy3jaUMZzD7qnubmVcnZR/NDqb/+uIGuUaw2hDDyLoyP5qkD1GvKWhAUq D1AXeoyOXog3gnba1I1g82Fzhom0FNx8iA6Uw1p3+kcd+hf9bvi1GtqbfUn9njQEvqDm FiY1W9rhvE/Z600Vn+e3KWPJ+NcO0SSJof7Hrm/ZFynpXA4M3t1Sc0kVO+U1Gzj+5tOg l9ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Wau0fGW8yZsKjnuoyb0VTR4qVyMVH48h3qQAcCmJxHM=; b=dfgp1j/qrpweWn3HSc7mlD2Lw8BXQ2o1aJ3vCK7juZejxIGDuWGtG5AfLexEO4MrBj KxdZ0YT6Cb0rbhsCGwYSexKRocDFA+XyfZIEbgi14umWdA9AC2Nkb5AGyQcbydtcFG4O V1CSAY8IRP/Dm1l6j4IOAV6eXihsgla2fxDyKP02RXoXOGknTEcowGCLiVseHRce+Ng9 gajAFaK1uvKMkXlNqjv9SGH9YJcHfxPgQOGqg4b7y+kTyHkHwoeLUVwdc6NNSxlLMRhA 8ArgVdtsJ1EUSzvNRmNdPeOxHs4AHpeAISElE7/j7QoEuU0sSI77lUxmT+xnt8g5ofCF Wjmg== X-Gm-Message-State: AJIora9+zsLa3eKQG8QmPA4JpPulTVsixHlYK/b+xDJDp+b2q66RRpOt w2zg1f1P5VNSOdTXuJeqCzjL6w== X-Received: by 2002:a1c:29c1:0:b0:39d:86c0:3ece with SMTP id p184-20020a1c29c1000000b0039d86c03ecemr9939wmp.138.1655306187683; Wed, 15 Jun 2022 08:16:27 -0700 (PDT) Received: from myrica (cpc92880-cmbg19-2-0-cust679.5-4.cable.virginm.net. [82.27.106.168]) by smtp.gmail.com with ESMTPSA id q16-20020a5d5750000000b0020e63ab5d78sm14781591wrw.26.2022.06.15.08.16.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 08:16:26 -0700 (PDT) Date: Wed, 15 Jun 2022 16:16:02 +0100 From: Jean-Philippe Brucker To: Zhangfei Gao Cc: Greg Kroah-Hartman , Arnd Bergmann , Herbert Xu , Wangzhou , Jonathan Cameron , linux-accelerators@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, Yang Shen Subject: Re: [PATCH] uacce: fix concurrency of fops_open and uacce_remove Message-ID: References: <20220610123423.27496-1-zhangfei.gao@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220610123423.27496-1-zhangfei.gao@linaro.org> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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-crypto@vger.kernel.org Hi, On Fri, Jun 10, 2022 at 08:34:23PM +0800, Zhangfei Gao wrote: > The uacce parent's module can be removed when uacce is working, > which may cause troubles. > > If rmmod/uacce_remove happens just after fops_open: bind_queue, > the uacce_remove can not remove the bound queue since it is not > added to the queue list yet, which blocks the uacce_disable_sva. > > Change queues_lock area to make sure the bound queue is added to > the list thereby can be searched in uacce_remove. > > And uacce->parent->driver is checked immediately in case rmmod is > just happening. > > Also the parent driver must always stop DMA before calling > uacce_remove. > > Signed-off-by: Yang Shen > Signed-off-by: Zhangfei Gao > --- > drivers/misc/uacce/uacce.c | 19 +++++++++++++------ > 1 file changed, 13 insertions(+), 6 deletions(-) > > diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c > index 281c54003edc..b6219c6bfb48 100644 > --- a/drivers/misc/uacce/uacce.c > +++ b/drivers/misc/uacce/uacce.c > @@ -136,9 +136,16 @@ static int uacce_fops_open(struct inode *inode, struct file *filep) > if (!q) > return -ENOMEM; > > + mutex_lock(&uacce->queues_lock); > + > + if (!uacce->parent->driver) { I don't think this is useful, because the core clears parent->driver after having run uacce_remove(): rmmod hisi_zip open() ... uacce_fops_open() __device_release_driver() ... pci_device_remove() hisi_zip_remove() hisi_qm_uninit() uacce_remove() ... ... mutex_lock(uacce->queues_lock) ... if (!uacce->parent->driver) device_unbind_cleanup() /* driver still valid, proceed */ dev->driver = NULL Since uacce_remove() disabled SVA, the following uacce_bind_queue() will fail anyway. However, if uacce->flags does not have UACCE_DEV_SVA set, we'll proceed further and call uacce->ops->get_queue(), which does not exist anymore since the parent module is gone. I think we need the global uacce_mutex to serialize uacce_remove() and uacce_fops_open(). uacce_remove() would do everything, including xa_erase(), while holding that mutex. And uacce_fops_open() would try to obtain the uacce object from the xarray while holding the mutex, which fails if the uacce object is being removed. Thanks, Jean > + ret = -ENODEV; > + goto out_with_lock; > + } > + > ret = uacce_bind_queue(uacce, q); > if (ret) > - goto out_with_mem; > + goto out_with_lock; > > q->uacce = uacce; > > @@ -153,7 +160,6 @@ static int uacce_fops_open(struct inode *inode, struct file *filep) > uacce->inode = inode; > q->state = UACCE_Q_INIT; > > - mutex_lock(&uacce->queues_lock); > list_add(&q->list, &uacce->queues); > mutex_unlock(&uacce->queues_lock); > > @@ -161,7 +167,8 @@ static int uacce_fops_open(struct inode *inode, struct file *filep) > > out_with_bond: > uacce_unbind_queue(q); > -out_with_mem: > +out_with_lock: > + mutex_unlock(&uacce->queues_lock); > kfree(q); > return ret; > } > @@ -171,10 +178,10 @@ static int uacce_fops_release(struct inode *inode, struct file *filep) > struct uacce_queue *q = filep->private_data; > > mutex_lock(&q->uacce->queues_lock); > - list_del(&q->list); > - mutex_unlock(&q->uacce->queues_lock); > uacce_put_queue(q); > uacce_unbind_queue(q); > + list_del(&q->list); > + mutex_unlock(&q->uacce->queues_lock); > kfree(q); > > return 0; > @@ -513,10 +520,10 @@ void uacce_remove(struct uacce_device *uacce) > uacce_put_queue(q); > uacce_unbind_queue(q); > } > - mutex_unlock(&uacce->queues_lock); > > /* disable sva now since no opened queues */ > uacce_disable_sva(uacce); > + mutex_unlock(&uacce->queues_lock); > > if (uacce->cdev) > cdev_device_del(uacce->cdev, &uacce->dev); > -- > 2.36.1 >