Received-SPF: pass (google.com: domain of linux-kernel+bounces-134932-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <ca45f32d-b526-4bcd-b177-08698babaf3d@shopee.com>
Date: Mon, 8 Apr 2024 15:44:00 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 0/2] x86/resctrl: Track llc_occupancy of RMIDs in limbo
 list
To: Reinette Chatre <reinette.chatre@intel.com>, james.morse@arm.com
Cc: fenghua.yu@intel.com, babu.moger@amd.com, bp@alien8.de,
 tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com,
 hpa@zytor.com, peternewman@google.com, x86@kernel.org,
 linux-kernel@vger.kernel.org, corbet@lwn.net, linux-doc@vger.kernel.org
References: <20240319083039.223088-1-haifeng.xu@shopee.com>
 <4244b729-2eec-4999-9427-00b5c9f3e6fc@intel.com>
From: Haifeng Xu <haifeng.xu@shopee.com>
In-Reply-To: <4244b729-2eec-4999-9427-00b5c9f3e6fc@intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


On 2024/3/30 07:06, Reinette Chatre wrote:
> Hi Haifeng,
> 
> On 3/19/2024 1:30 AM, Haifeng Xu wrote:
>> After removing a monitor group, its RMID may not be freed immediately
>> unless its llc_occupancy is less than the re-allocation threshold. If
>> turning up the threshold, the RMID can be reused. In order to know how
>> much the threshold should be, it's necessary to acquire the llc_occupancy.
>>
>> The patch series provides a new tracepoint to track the llc_occupancy.
> 
> There seems to be a problem with the DKIM attestation. Here is what I see
> when I download this series:
> 
>     $ b4 am -Q 20240319083039.223088-1-haifeng.xu@shopee.com
>     Grabbing thread from lore.kernel.org/all/20240319083039.223088-1-haifeng.xu@shopee.com/t.mbox.gz
>     Analyzing 3 messages in the thread
>     Looking for additional code-review trailers on lore.kernel.org
>     Checking attestation on all messages, may take a moment...
>     ---
>       ✗ [PATCH v6 1/2] x86/resctrl: Rename pseudo_lock_event.h to trace.h
>       ✗ [PATCH v6 2/2] x86/resctrl: Add tracepoint for llc_occupancy tracking
>     ---
>       ✗ BADSIG: DKIM/shopee.com
>     ---
>     Total patches: 2
>     ---
> 

Hi, Reinette,

I can also reproduced it. After digging into it, I found that our DKIM signature header
has 't' and 'x' flags. They are recommended as a means to help identify spam.

t= is the DKIM signature timestamp.
x= is the DKIM signature expiration time.

The source code of DKIM Validation can be seen in dkim/__init__.py(line 351), I paste it
here.

 343     if b'x' in sig:
 344         if re.match(br"\d+$", sig[b'x']) is None:
 345             raise ValidationError(
 346               "x= value is not a decimal integer (%s)" % sig[b'x'])
 347         x_sign = int(sig[b'x'])
 348         now = int(time.time())
 349         slop = 36000 # 10H leeway for mailers with inaccurate clocks
 350         if x_sign < now - slop:
 351             raise ValidationError(
 352                 "x= value is past (%s)" % sig[b'x'])
 353             if x_sign < t_sign:
 354                 raise ValidationError(
 355                     "x= value is less than t= value (x=%s t=%s)" %
 356                     (sig[b'x'], sig[b't']))

The expiry time is less than the time point you download the patch, so the validation
fails. If I comment out these lines, this series can be successfully downloaded.

The signature is only valid for a week. So if you use b4 to download the patch series,
It's best to do it in a week after the patch is sent.

Thanks.


> The patches look good to me. Thank you very much for adding this.
> Please resubmit with the DKIM attestation fixed and then you can add:
> 
> | Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
> 
> Reinette

Thanks for your review.