Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp8682112rwi; Tue, 25 Oct 2022 09:31:07 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6DxhvIi+9kYbROmeiaPTj7uJvCmaezv3RyozIxm1a2t127kc+o+GXVM1W68ufubG8ZIUPL X-Received: by 2002:aa7:c40b:0:b0:45d:4492:a8cb with SMTP id j11-20020aa7c40b000000b0045d4492a8cbmr35747367edq.217.1666715466747; Tue, 25 Oct 2022 09:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666715466; cv=none; d=google.com; s=arc-20160816; b=yxWYG3YCtwm1aVY8gP7pMvXGsAfXx9uakNykMlYHlgIJwiey6kuP8Ywws/Zt6VzTcC DfpdDRsjbQfsvJSfJ4CM7xMwXVUAih7ItLPxY6/Sq3UNTS8oKSnmAzBtwHkCcxUMABbc lI1TNusacwylU0vkXJBO/vb6y6n0qNHOdrtfQ2yfGgD9td2+dst8MC8J6ouJf0rESAL9 tuJn1tDhU6LplTBiI5iiAI812OWVSEuj46c/PzF4SQ1dnQHegHXcd+tHwAh9bx33trpV qhA2y0BPblUrw/ykYn2/7iuCPqLlce7wRZnlkPm5eo8K6EnpgLtj5SZrNNtKtYO1ul1l xavg== 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:cc :references:to:subject:from:user-agent:mime-version:date:message-id; bh=xha5qCyTCBp57mGB8bK9KFG7c3NEhdsN8/lwowS8AwQ=; b=F+IPkbDu4rvHEqMykOfTv83WIy+gvjr9RLKlsOw6wwLyB8n1ELpt9jC0jj4vE22PGs 8DoA/MG+WsAO7Ak4TPLakMEN0R7dru+mkzY12B/FHhaUkRGcUizvKFyVWqI1ubrAbUAl EgBJftj2gOKAkMfplBDS6lD7+4UBp1AKvZg87ElQ7CqU3HW48n+IZBe6jXbBGqsH88RX UnQlMPPjLOZbKnOQldeNRTTFI93Hb3X7astxKWICKap0tz8Eo8XhXPLjgxEaUTS9USAN LHh7ryn4wfmF3mIkeWRlGcgQJ5ffCvb10ezqLLcS4bafnj/xEn9arC/llXPkx58CQtCy htIg== 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:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m11-20020a50cc0b000000b0045d5e3c7f44si2913035edi.180.2022.10.25.09.30.40; Tue, 25 Oct 2022 09:31:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233255AbiJYPbQ (ORCPT + 99 others); Tue, 25 Oct 2022 11:31:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231639AbiJYPbJ (ORCPT ); Tue, 25 Oct 2022 11:31:09 -0400 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3086E5F10A for ; Tue, 25 Oct 2022 08:31:05 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=shawnwang@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0VT3XzXp_1666711854; Received: from 30.32.74.15(mailfrom:shawnwang@linux.alibaba.com fp:SMTPD_---0VT3XzXp_1666711854) by smtp.aliyun-inc.com; Tue, 25 Oct 2022 23:31:02 +0800 Message-ID: <140177ee-da8f-c6eb-caf6-af0775a3de0e@linux.alibaba.com> Date: Tue, 25 Oct 2022 23:30:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 From: Shawn Wang Subject: Re: [PATCH v2] x86/resctrl: Clear the stale staged config after the configuration is completed To: Reinette Chatre , fenghua.yu@intel.com References: <1665304608-120466-1-git-send-email-shawnwang@linux.alibaba.com> <7fa6ed4e-abae-85fb-4e95-8c73755a4263@intel.com> <86fc22a2-e779-b7ab-67d6-a3aff975ae56@linux.alibaba.com> <30637459-7419-6497-6230-b13c73a947de@intel.com> <2cdfbe28-01cc-926d-2f6d-2a974a4c5a74@linux.alibaba.com> Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, James Morse , jamie@nuviainc.com, linux-kernel@vger.kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham 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 Hi Reinette, On 10/25/2022 12:45 AM, Reinette Chatre wrote: > Hi Shawn, > > On 10/23/2022 7:31 PM, Shawn Wang wrote: >> On 10/22/2022 2:05 AM, Reinette Chatre wrote: >> >> ... >> >>>> It may not be enough to just clear staged_config[] when >>>> resctrl_arch_update_domains() exits. I think the fix needs to make >>>> sure staged_config[] can be cleared where it is set. >>>> >>>> The modification of staged_config[] comes from two paths: >>>> >>>> Path 1: >>>> rdtgroup_schemata_write() { >>>>      ... >>>>      rdtgroup_parse_resource()     // set staged_config[] >>>>      ... >>>>      resctrl_arch_update_domains()     // clear staged_config[] >>>>      ... >>>> } >>>> >>>> Path 2: >>>> rdtgroup_init_alloc() { >>>>      ... >>>>      rdtgroup_init_mba()/rdtgroup_init_cat()    // set staged_config[] >>>>      ... >>>>      resctrl_arch_update_domains()        // clear staged_config[] >>>>      ... >>>> } >>>> >>>> If we clear staged_config[] in resctrl_arch_update_domains(), goto >>>> statement for error handling between setting staged_config[] and >>>> calling resctrl_arch_update_domains() will be ignored. This can still >>>> remain the stale staged_config[]. >>> ah - indeed. Thank you for catching that. >>> >>>> >>>> I think maybe it is better to put the clearing work where >>>> rdtgroup_schemata_write() and rdtgroup_init_alloc() exit. >>>> >>> >>> It may be more robust to let rdtgroup_init_alloc() follow >>> how rdtgroup_schemata_write() already ensures that it is >>> working with a clean state by clearing staged_config[] before >>> placing its staged config within. >>> >> >> I want to make sure, do you mean just ignore the stale value and >> place the clearing work before staged_config[] is used? If so, maybe >> the only thing the fix should do is to add memset() to >> rdtgroup_init_alloc().> > > No, let us not leave stale data lying around. > > The idea is that the function calling resctrl_arch_update_domains() is > responsible for initializing staged_config[] correctly and completely. > To confirm, yes, the idea is to clear the staged_config[] in > rdtgroup_init_alloc() before resctrl_arch_update_domains() is called > to follow how it is currently done in rdtgroup_schemata_write(). > > But, as you indicate, by itself this would leave stale data lying around. > > The solution that you suggested earlier, to put the clearing work where > rdtgroup_schemata_write() and rdtgroup_init_alloc() exit, is most logical. > That makes the code symmetrical in that staged_config[] is cleared > where it is initialized and no stale data is left lying around. What was > not clear to me is how this would look in the end. Were you planning to > keep the staged_config[] clearing within rdtgroup_schemata_write() but > not do so in rdtgroup_init_alloc()? rdtgroup_schemata_write() and > rdtgroup_init_alloc() has to follow the same pattern to reduce confusion. > > So, to be more robust, how about: > > /* Clear staged_config[] to make sure working from a clean slate */ > resctrl_arch_update_domains() > /* Clear staged_config[] to not leave stale data lying around */ > Thank you for your explanation, and it makes sense to me. But this will require 4 memset() loops, how about putting the clearing work in a separate function in rdtgroup.c, like rdt_last_cmd_clear(): void staged_configs_clear(void) { struct resctrl_schema *s; struct rdt_domain *dom; lockdep_assert_held(&rdtgroup_mutex); list_for_each_entry(s, &resctrl_schema_all, list) { list_for_each_entry(dom, &s->res->domains, list) memset(dom->staged_config, 0, sizeof(dom->staged_config)); } } Thanks, Shawn