Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp541565rdh; Sun, 24 Sep 2023 00:50:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGbcBE1bNP6q/GLwhsC7o6q6AqgWStXZ65kS4gC/q39rsFqWG3fEkamYescF1j1y4FUL3kx X-Received: by 2002:a05:6a20:3d29:b0:131:a21:9f96 with SMTP id y41-20020a056a203d2900b001310a219f96mr5043714pzi.6.1695541803013; Sun, 24 Sep 2023 00:50:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695541802; cv=none; d=google.com; s=arc-20160816; b=Qf9KIRcxsLFrB7o9QbYpWweWE6PYzFHAhq2NeykLbTITDGQJ1fULRDHf7DcMbRH+Wj BZ4WMPy4ETcibGmDzuctVRlTgPEtJAWDeCJ4CIiw1/QoB9gRoo0l6goaCbYGepX29RGq n5CjCPiKFltlsO3z5mXO5LfGzQtDckRl46zvTaN5gSxzp3ZncwcYhckjGnNlwnV3M4Mc uwKPvKNkSFEjssHgxyclmz3Cq9a/yWyZUOmqJjcKD2mdwe3JxakQMKCwHyvxUQtwnpth 2/msn25oxymfc0zsDs3H15xLSvZNv1ZID/0H4KPKo45WLylVdBwro7GY6MKRQ62hRByI 33rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id; bh=b/Ko60wv3bcSplV0tuXIMdaMl5knwIzo4rE9k4wxpVU=; fh=2gKFCUzySrHeIBJMSHAx1HXclSr/Lo4PFuCedPzqT9A=; b=j+4FCE4r+IGhmRuOt0+ZDXNrL7Hy2cplzlQYD5GWE26ufNPPxHO208mP5CoJKIpdQP 3s0cyD3Mb+5NzgPLj7GBgkuQYDx0dzgvqIxGy3HUoTzrctwBhjwyOwkx7xLwjRehKshS GWQbm+GQFLXWYBUX2n54Z0/GvA0inA7fLbirrqxLmtzfK8VceNJ6z+i+6RRdbspDvhyL QSH4aJfPhX77RWgj/UBeYQFHsCLROct3La67omVnYHFwWXR4iXkHKu64vZqdrBmVlKir HzTCkSliBk1LKCzoKLwJo9CTgjpgrDpXBBVhtAGGT6eBpCRJSySkxcRImNUEHCMNyM1U bylg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id bx22-20020a056a02051600b00569da5e2e5esi8489306pgb.255.2023.09.24.00.50.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Sep 2023 00:50:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id F1A31802A03C; Sun, 24 Sep 2023 00:49:59 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229962AbjIXHti (ORCPT + 99 others); Sun, 24 Sep 2023 03:49:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229475AbjIXHti (ORCPT ); Sun, 24 Sep 2023 03:49:38 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3D57106; Sun, 24 Sep 2023 00:49:30 -0700 (PDT) Received: from kwepemm000012.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4RtdMN6W6KztSZQ; Sun, 24 Sep 2023 15:45:04 +0800 (CST) Received: from [10.174.178.220] (10.174.178.220) by kwepemm000012.china.huawei.com (7.193.23.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Sun, 24 Sep 2023 15:49:22 +0800 Message-ID: <236310e2-b253-553e-d210-4a4928ed8ec8@huawei.com> Date: Sun, 24 Sep 2023 15:49:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 1/2] scsi: core: cleanup scsi_dev_queue_ready() Content-Language: en-US From: Wenchao Hao To: Damien Le Moal CC: "James E . J . Bottomley" , "Martin K . Petersen" , , , References: <20230922093842.2646157-1-haowenchao2@huawei.com> <20230922093842.2646157-2-haowenchao2@huawei.com> <7a11374c-4e8e-b7f9-aca4-55686a6ec501@huawei.com> In-Reply-To: <7a11374c-4e8e-b7f9-aca4-55686a6ec501@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.220] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm000012.china.huawei.com (7.193.23.142) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-2.2 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Sun, 24 Sep 2023 00:50:00 -0700 (PDT) On 2023/9/24 14:27, Wenchao Hao wrote: > On 2023/9/22 20:50, Damien Le Moal wrote: >> On 2023/09/22 2:38, Wenchao Hao wrote: >>> This is just a cleanup for scsi_dev_queue_ready() to avoid >>> redundant goto and if statement, it did not change the origin >>> logic. >>> >>> Signed-off-by: Wenchao Hao >>> --- >>>   drivers/scsi/scsi_lib.c | 35 ++++++++++++++++++----------------- >>>   1 file changed, 18 insertions(+), 17 deletions(-) >>> >>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c >>> index ca5eb058d5c7..f3e388127dbd 100644 >>> --- a/drivers/scsi/scsi_lib.c >>> +++ b/drivers/scsi/scsi_lib.c >>> @@ -1254,28 +1254,29 @@ static inline int scsi_dev_queue_ready(struct request_queue *q, >>>       int token; >>>       token = sbitmap_get(&sdev->budget_map); >>> -    if (atomic_read(&sdev->device_blocked)) { >>> -        if (token < 0) >>> -            goto out; >>> +    if (token < 0) >>> +        return -1; >> >> This is changing how this function works... >> > > I don't think so... > The origin function flow: > > static inline int scsi_dev_queue_ready(struct request_queue *q, >                   struct scsi_device *sdev) > { >     ... >     token = sbitmap_get(&sdev->budget_map); >     if (atomic_read(&sdev->device_blocked)) { >         if (token < 0) >             goto out; >     } >     return token; > out: >     return -1 > } > > If the token is less than 0, it would always return -1. So we can found > it's not necessary to check token after atomic_read(). > >>> -        if (scsi_device_busy(sdev) > 1) >>> -            goto out_dec; >>> +    /* >>> +     * device_blocked is not set at mostly time, so check it first >>> +     * and return token when it is not set. >>> +     */ >>> +    if (!atomic_read(&sdev->device_blocked)) >>> +        return token; >> >> ...because you reversed the tests order. > > As explained in comment, the device_blocked is not set at mostly time, > so when it's not set, just return the token. > >>> -        /* >>> -         * unblock after device_blocked iterates to zero >>> -         */ >>> -        if (atomic_dec_return(&sdev->device_blocked) > 0) >>> -            goto out_dec; >>> -        SCSI_LOG_MLQUEUE(3, sdev_printk(KERN_INFO, sdev, >>> -                   "unblocking device at zero depth\n")); >>> +    /* >>> +     * unblock after device_blocked iterates to zero >>> +     */ >>> +    if (scsi_device_busy(sdev) > 1 || >>> +        atomic_dec_return(&sdev->device_blocked) > 0) { >> >> And here too, you are changing how the function works. The atomic_dec may not be >> done if the first condition is true. >> > > the origin flow would not call atomic_dec_return() too when condition > "scsi_device_busy(sdev) > 1" is true like following: > > static inline int scsi_dev_queue_ready(struct request_queue *q, >                   struct scsi_device *sdev) > { >     ... >     if (atomic_read(&sdev->device_blocked)) { >         if (scsi_device_busy(sdev) > 1) >             goto out_dec; > >         /* >          * unblock after device_blocked iterates to zero >          */ >         if (atomic_dec_return(&sdev->device_blocked) > 0) >             goto out_dec; >         SCSI_LOG_MLQUEUE(3, sdev_printk(KERN_INFO, sdev, >                    "unblocking device at zero depth\n")); >     } >     return token; > out_dec: >     if (token >= 0) >         sbitmap_put(&sdev->budget_map, token); > out: >     return -1; > } > > Here is the function before and after my change: > > The old function: > static inline int scsi_dev_queue_ready(struct request_queue *q, >                   struct scsi_device *sdev) > { >     int token; > >     token = sbitmap_get(&sdev->budget_map); >     if (token < 0) >         return -1; > >     /* >      * device_blocked is not set at mostly time, so check it first >      * and return token when it is not set. >      */ >     if (!atomic_read(&sdev->device_blocked)) >         return token; > >     /* >      * unblock after device_blocked iterates to zero >      */ >     if (scsi_device_busy(sdev) > 1 || >         atomic_dec_return(&sdev->device_blocked) > 0) { >         sbitmap_put(&sdev->budget_map, token); >         return -1; >     } > >     SCSI_LOG_MLQUEUE(3, sdev_printk(KERN_INFO, sdev, >              "unblocking device at zero depth\n")); > >     return token; > } > Sorry, I paste wrong for old function, the old function is: static inline int scsi_dev_queue_ready(struct request_queue *q, struct scsi_device *sdev) { int token; token = sbitmap_get(&sdev->budget_map); if (atomic_read(&sdev->device_blocked)) { if (token < 0) goto out; if (scsi_device_busy(sdev) > 1) goto out_dec; /* * unblock after device_blocked iterates to zero */ if (atomic_dec_return(&sdev->device_blocked) > 0) goto out_dec; SCSI_LOG_MLQUEUE(3, sdev_printk(KERN_INFO, sdev, "unblocking device at zero depth\n")); } return token; out_dec: if (token >= 0) sbitmap_put(&sdev->budget_map, token); out: return -1; }