Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp966478pxp; Wed, 16 Mar 2022 22:54:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzCFIQcG2zTG+mSZboy1GxkrWF/ArWXCWN/n9UtrWe9wFejxNyFpnYMv+5OzBPph0oE7HnV X-Received: by 2002:a17:90b:4d88:b0:1bf:793:7134 with SMTP id oj8-20020a17090b4d8800b001bf07937134mr13974139pjb.112.1647496479812; Wed, 16 Mar 2022 22:54:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647496479; cv=none; d=google.com; s=arc-20160816; b=wmzntIpdxln+i89gQuEpWbeA2jwZ6UNitk2Y6X/Zr+r6byQz5qm1kzxkj9OlHNEju6 cUrW5QyKiuM5MbiaVzuy+g6ECVK/ByrXnJ7wH0A4m127nifs7i/k0VZFM0qa5aSyfU/x TuALvFUvvAU4yulJcJ43StjL4yULhRbymCrV0rC8aKkIk/6D11tOdWAEf3hFg/nE9fnu QvS1u+JQgtRdl3ZHp/O+hCJphEqLoieTDRxSEOCmOssHSpgEkPxKzy/3CSHIfSPyx8sx /wlZShJFJzP5PlkTlctsSp8Bn9A5BooZ4pF99D6vK1WhNXCjmhoLb3dPP0zWsOLGEDuw AzIw== 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:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=/XJx133N1mOc7AJxJkTXGtWp6PjHQ2yQeUpaAlhISc4=; b=miYw6vB3MZhkLhvgZPAcditKnBbaiPtwb/nH9cK2rk3CVWRhkXO6snYGwWe3b8o1of 8qbF3Vemu9l/jN6Ab9BwjfmOJiEx7CduBdOHOMk063G8oLEODk4S2NugJg9YhBbYSgu0 crC3PwfHFdohVuqRHME6vQkXP9NjkzjFNf6AER1SQr9lcQDrLN1sIYNqKDuTO90w52jQ SDwcnZKZ/nLwc4srcE0Q4QLAk5rYm7hCP6+T68W5ajjZkPMhP/HSG09yGTw9DGuxZrmv TMkz929r0jDZx8luGXDLU+BB+HyGDjb3ExGtIg2iP26lI80UYgPxtEhH6/zz1+x3LrTD of0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id y185-20020a638ac2000000b003816043ef46si1124433pgd.315.2022.03.16.22.54.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 22:54:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6B4F413E157; Wed, 16 Mar 2022 21:49:52 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245173AbiCOPM2 (ORCPT + 99 others); Tue, 15 Mar 2022 11:12:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234857AbiCOPM0 (ORCPT ); Tue, 15 Mar 2022 11:12:26 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AE0D13F10; Tue, 15 Mar 2022 08:11:14 -0700 (PDT) Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KHxdZ2s5nz67ww1; Tue, 15 Mar 2022 23:09:22 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 15 Mar 2022 16:11:11 +0100 Received: from [10.47.84.96] (10.47.84.96) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 15 Mar 2022 15:11:10 +0000 Message-ID: <88ec9cac-f2ad-4728-6ce0-eb4358846463@huawei.com> Date: Tue, 15 Mar 2022 15:11:09 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 1/2] scsi: core: Fix sbitmap depth in scsi_realloc_sdev_budget_map() To: Bart Van Assche , , , , , , CC: , , , References: <1647340746-17600-1-git-send-email-john.garry@huawei.com> <1647340746-17600-2-git-send-email-john.garry@huawei.com> <51c2d9da-a0c5-8ae5-5c22-ceb56c7f5a27@acm.org> From: John Garry In-Reply-To: <51c2d9da-a0c5-8ae5-5c22-ceb56c7f5a27@acm.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.47.84.96] X-ClientProxiedBy: lhreml735-chm.china.huawei.com (10.201.108.86) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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-kernel@vger.kernel.org On 15/03/2022 14:33, Bart Van Assche wrote: >> sbitmap sb_backup; >> +    depth = min_t(unsigned int, depth, >> scsi_device_max_queue_depth(sdev)); >> + >>       /* >>        * realloc if new shift is calculated, which is caused by setting >>        * up one new default queue depth after calling ->slave_configure >> @@ -245,6 +247,9 @@ static int scsi_realloc_sdev_budget_map(struct >> scsi_device *sdev, >>                   scsi_device_max_queue_depth(sdev), >>                   new_shift, GFP_KERNEL, >>                   sdev->request_queue->node, false, true); >> +    if (!ret) >> +        sbitmap_resize(&sdev->budget_map, depth); > > Hmm ... why to call both sbitmap_init_node() and sbitmap_resize() > instead of combining both calls into a single call with the proper depth? Hi Bart, Is the user wants to change the queue depth later via sysfs we do not reallocate the sbitmap then. So we need to ensure that the size we reallocate here will satisfy the scsi device max depth. I'm referencing scsi_change_queue_depth() for this. Thanks, John