: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-DKIM: signer='linux-foundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -2.4 (--)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (-2.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: pebblebed.com]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -2.8 NICE_REPLY_A           Looks like a legit reply (A)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: -23

On Mon, 19 Jan 2026 00:55:59 +0800 Kairui Song <ryncsn@gmail.com> wrote:

> From: Kairui Song <kasong@tencent.com>
> 
> The helper for shmem swap freeing is not handling the order of swap
> entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but
> it gets the entry order before that using xa_get_order without lock
> protection, and it may get an outdated order value if the entry is split
> or changed in other ways after the xa_get_order and before the
> xa_cmpxchg_irq.
> 
> And besides, the order could grow and be larger than expected, and cause
> truncation to erase data beyond the end border. For example, if the
> target entry and following entries are swapped in or freed, then a large
> folio was added in place and swapped out, using the same entry, the
> xa_cmpxchg_irq will still succeed, it's very unlikely to happen though.
> 
> To fix that, open code the Xarray cmpxchg and put the order retrieval
> and value checking in the same critical section. Also, ensure the order
> won't exceed the end border, skip it if the entry goes across the
> border.
> 
> Skipping large swap entries crosses the end border is safe here.
> Shmem truncate iterates the range twice, in the first iteration,
> find_lock_entries already filtered such entries, and shmem will
> swapin the entries that cross the end border and partially truncate the
> folio (split the folio or at least zero part of it). So in the second
> loop here, if we see a swap entry that crosses the end order, it must
> at least have its content erased already.
> 
> I observed random swapoff hangs and kernel panics when stress testing
> ZSWAP with shmem. After applying this patch, all problems are gone.
> 
> Fixes: 809bc86517cc ("mm: shmem: support large folio swap out")

September 2024.

Seems about right.  A researcher recently found that kernel bugs take two years
to fix.  https://pebblebed.com/blog/kernel-bugs?ref=itsfoss.com

>
> ...
>
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -962,17 +962,29 @@ static void shmem_delete_from_page_cache(struct folio *folio, void *radswap)
>   * being freed).
>   */
>  static long shmem_free_swap(struct address_space *mapping,
> -			    pgoff_t index, void *radswap)
> +			    pgoff_t index, pgoff_t end, void *radswap)
>  {
> -	int order = xa_get_order(&mapping->i_pages, index);
> -	void *old;
> +	XA_STATE(xas, &mapping->i_pages, index);
> +	unsigned int nr_pages = 0;
> +	pgoff_t base;
> +	void *entry;
>  
> -	old = xa_cmpxchg_irq(&mapping->i_pages, index, radswap, NULL, 0);
> -	if (old != radswap)
> -		return 0;
> -	swap_put_entries_direct(radix_to_swp_entry(radswap), 1 << order);
> +	xas_lock_irq(&xas);
> +	entry = xas_load(&xas);
> +	if (entry == radswap) {
> +		nr_pages = 1 << xas_get_order(&xas);
> +		base = round_down(xas.xa_index, nr_pages);
> +		if (base < index || base + nr_pages - 1 > end)
> +			nr_pages = 0;
> +		else
> +			xas_store(&xas, NULL);
> +	}
> +	xas_unlock_irq(&xas);
> +
> +	if (nr_pages)
> +		swap_put_entries_direct(radix_to_swp_entry(radswap), nr_pages);
>  
> -	return 1 << order;
> +	return nr_pages;
>  }
>  

What tree was this prepared against?

Both Linus mainline and mm.git have

: static long shmem_free_swap(struct address_space *mapping,
: 			    pgoff_t index, void *radswap)
: {
: 	int order = xa_get_order(&mapping->i_pages, index);
: 	void *old;
: 
: 	old = xa_cmpxchg_irq(&mapping->i_pages, index, radswap, NULL, 0);
: 	if (old != radswap)
: 		return 0;
: 	free_swap_and_cache_nr(radix_to_swp_entry(radswap), 1 << order);
: 
: 	return 1 << order;
: }

but that free_swap_and_cache_nr() call is absent from your tree.




From - Sun Jan 18 19:48:28 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-210241-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id ILkUEto3bWlQThwAYBR5ng
	(envelope-from <stable+bounces-210241-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sun, 18 Jan 2026 19:43:22 +0000
Return-path: <stable+bounces-210241-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sun, 18 Jan 2026 19:43:22 +0000
Received: from tor.lore.kernel.org ([172.105.105.114])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-210241-hi=josie.lol@vger.kernel.org>)
	id 1vhYgE-00000009MPz-0HaF
	for hi@josie.lol;
	Sun, 18 Jan 2026 19:43:22 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by tor.lore.kernel.org (Postfix) with ESMTP id 2BA5830056C3
	for <hi@josie.lol>; Sun, 18 Jan 2026 19:43:21 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 907F02FCC06;
	Sun, 18 Jan 2026 19:43:18 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JyVFMji/"
X-Original-To: stable@vger.kernel.org
Received: from mail-dy1-f172.google.com (mail-dy1-f172.google.com [74.125.82.172])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C5E72C3277
	for <stable@vger.kernel.org>; Sun, 18 Jan 2026 19:43:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.172
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1768765398; cv=pass; b=Q67XQiMQXVIuKHTAvaY2x4C0uGNhx3UNWTR0g4w09zA+MFZFkTVklMjt7Ui/nEgPafuCSOjvCt4ZqQFI96QPj4BMa1yiVFVY5850u0Y7NDdyF7OmV1AdV23BPgKC8T+L7WAKtMQNyJBqNfoim6gz6rnJCGC0sSeuJGDERKjnPk8=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1768765398; c=relaxed/simple;
	bh=YcWX4KpE5LzyFkGNlp0UmN6AScfsx8INQHNsRSOVao8=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=d75EI9Bl2WFJ9rpQsvx2ObaQvcIV/QJ3UvLf2GcZkOXO35Y9osfVIJ73XjQtweLDjc0hDsRyao2RvG6NjgvuckkwDYVJVxQ3qHxw4docUPzloScscdvFk/4MDD7TUGNZJFCefyt3TZyjdesR4RlS0ax1vYgeufGFK8CXJBQcQHY=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JyVFMji/; arc=pass smtp.client-ip=74.125.82.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-dy1-f172.google.com with SMTP id 5a478bee46e88-2b6ce77a2cbso50005eec.1
        for <stable@vger.kernel.org>; Sun, 18 Jan 2026 11:43:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1768765396; cv=none;
        d=google.com; s=arc-20240605;
        b=Ngb2ksL7hDavUB3jxbhohRpW0WuT0yKsIwWt+ajLDkh6yTrvhFs6izcZzryAFr2dh5
         SjKnn8zcEJfnwBVoTdtUYCSoWReW8noRQage30341C28kUaN7dRx5Gseh4Sr+H+6NC6/
         dkFlXhMBT9nvf00CnEBEonZFShU+NVRENb/QchXURw5wpHpGQEYt8gMLx119Tpw1eHz0
         z4t6mtXNoLTg0U85Z0ww5G+1Vyg96nBoRES41/3/9Nvcqe7P+RMot+kUknZPOg3tta06
         JOrjAgljo7GNzIPtfWJhfMldtBO3sgqRlrnM6ei2wrjyrh8hfGRSAUzeWXD5dO5FJhIc
         ab8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=3WkwnRacVzZnF9+VHDBdh2NvGD/q/Isu1ZQKlvNDN0I=;
        fh=zBgGoH6611pVKbDWTwQgnibDv0oCebu0/schIaAYg6g=;
        b=KSUZB13XaOXJnT+hdneI3yIVs7xA/N3W3JcITa5rMjx143zpzofRmYB7YRGgn683+U
         tKJ0lWZszF4c9mwDdX1DUXUB7069KddlvR3xVkvzP/Iuz7BrvTnDutygV2bES2bBx35L
         5W82quJct05ViyuajiowlHmpCRRJ23vcFm1pmrKHHIeHitRNkAIB6qWg8FL9Xif7oJLD
         6HBJwpx7wfbBDIVfjPTme1M38IeqPaiexshfaxY/xBqNCszb4UV39BywLONgbS9BqQcx
         S5xen1shnWZxz47SXaNLaTbSDRJfuWkkfyvvXcrF7keVuI2XpeTl5magovOJ7grM0ORx
         R0ow==;
        darn=vger.kernel.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1768765396; x=1769370196; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3WkwnRacVzZnF9+VHDBdh2NvGD/q/Isu1ZQKlvNDN0I=;
        b=JyVFMji/c1eBg4LJmOVPcjNlcOenkPq7z/Ysjq3Hehh3n2JscrHBsQqoX0KD9dIj/B
         CgGK4f6ikRvaXkaNakJpb9IqeqXcI3liEZr9ApuIuJ7hhwPV5z1v06CjEzlOiDIsqC5r
         f9DM+zzkFTg170yiNciTf9IZoMPVzY6JrDPmytalgfSnVJga+bl9uIrIjSt70kwxPhWZ
         lgNubit1H/r/xahYemoLlOJ9rrd8PPy4jnmXsNubOrK45nhpSEI1syOxwxUadEJ+7HSj
         0CfCLjMTsvLkyG0lZgj8v3eDZq4Zn4N+/Kiy19W/8WQllIrTJ9Cbf7nkaUtuiES+e3iP
         de3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1768765396; x=1769370196;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=3WkwnRacVzZnF9+VHDBdh2NvGD/q/Isu1ZQKlvNDN0I=;
        b=g4bdReOrVCzCHy2QLheOWb7FJUlQQ4FS1n/69fwf7F4akCIjtpr0j/udBqEae6vi7U
         aLeO1OSmMkvZGQwegnUgRDLbLxWixwJsql8ip6UAKSE99dzfSK7hiCheDwRl7n2gCswn
         Ls+beQBscbeZB8qHOZ172x89dt0cCoBOecF3DHKsy9dN+RIXviprjd/io5mJI34WKnvI
         UPLLaXjV9+RWSVPgmsL+RWa5vqLDHc5pSuBbMm3OXYNBbBdUeQF3nkz0DIzGLdj0OzRV
         3X/BwvIolqYMlvBqPq5mzvX0gdLilGrj59Ng2NYGdjgf2amBLGcCPf0WLHiWqkkZoKMS
         pOMw==
X-Forwarded-Encrypted: i=1; AJvYcCXbd0rYWQIe0mh40rtqgZjvOCK7ComB8/G/7f/dGdOvslc0JgAzju/usk3VqkbVpj/CQdNP/+U=@vger.kernel.org
X-Gm-Message-State: AOJu0YztSQzuE7ngejX4zdQinghI2k/JVF5DrQmIw20WlMFyzwByJ57D
	8KRdKcCTMCPqyC1cc+Ym0oNZrbqtITxvn60JIiHlxOydbsd8VKp0Gr+AqJ8tX/JwaM4kNkIvj3l
	RrPcPJjXQbVUoricJMCARnIjcL0tdVn4=
X-Gm-Gg: AY/fxX66zHyFCGlykbYoLGVBrktmpsnOc0qJ9wm0hZF4ri6W24QHXfEzQNZ+MnJLIFL
	mKQRPFA/oI0Qb2IlehwAVoMpMcrkKFoClHnjP9zt+dVYTbZ9ZifkmUJNdIovnOphRHHi/JIoNT7
	7/+ykJWv7VOzVXN8sSHA2tpLZ96juWjYFK60qPgMidm1KFc/C7ajU23gNYYBTKozl7szMJTaUu0
	mMlCM02p6FcmtPDaSagkj83xoTx7s+FRlEzhVdnCMku29oZfw4ClpxBxaUE1j0lE18QdiaRKjIN
	mSLt/bnH9p+RECBv3fSUXa+aW/HcjsjyKMUUwsM58U7JXwCwPpMAASqoLxpuhI9ATWw5uFRlfxo
	xdACxlWIBe1Ge
X-Received: by 2002:a05:7301:1f10:b0:2ae:5245:d50e with SMTP id
 5a478bee46e88-2b6b4114382mr3414544eec.8.1768765396119; Sun, 18 Jan 2026
 11:43:16 -0800 (PST)
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20260115183832.46595-1-ojeda@kernel.org>
In-Reply-To: <20260115183832.46595-1-ojeda@kernel.org>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Sun, 18 Jan 2026 20:43:03 +0100
X-Gm-Features: AZwV_Qird-lwibLosQ8SVV1mDXaYy8TIK_gyKIQwJqqY-9VOd-kxYQI5T5v3RQE
Message-ID: <CANiq72mRB1Hhu=m26GsFHDTdiRTditNZGT4bRYWhWo_oBWsYXA@mail.gmail.com>
Subject: Re: [PATCH] rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target
To: Miguel Ojeda <ojeda@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>, Nicolas Schier <nsc@kernel.org>, Boqun Feng <boqun.feng@gmail.com>, 
	Gary Guo <gary@garyguo.net>, =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, 
	Benno Lossin <lossin@kernel.org>, Andreas Hindborg <a.hindborg@kernel.org>, 
	Alice Ryhl <aliceryhl@google.com>, Trevor Gross <tmgross@umich.edu>, 
	Danilo Krummrich <dakr@kernel.org>, rust-for-linux@vger.kernel.org, 
	linux-kbuild@vger.kernel.org, stable@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-DKIM: signer='gmail.com' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider
                             [miguel.ojeda.sandonis[at]gmail.com]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.105.105.114 listed in list.dnswl.org]
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
  0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: 4

On Thu, Jan 15, 2026 at 7:38=E2=80=AFPM Miguel Ojeda <ojeda@kernel.org> wro=
te:
>
> `rustfmt` is configured via the `.rustfmt.toml` file in the source tree,
> and we apply `rustfmt` to the macro expanded sources generated by the
> `.rsi` target.
>
> However, under an `O=3D` pointing to an external folder (i.e. not just
> a subdir), `rustfmt` will not find the file when checking the parent
> folders. Since the edition is configured in this file, this can lead to
> errors when it encounters newer syntax, e.g.
>
>     error: expected one of `!`, `.`, `::`, `;`, `?`, `where`, `{`, or an =
operator, found `"rust_minimal"`
>       --> samples/rust/rust_minimal.rsi:29:49
>        |
>     28 | impl ::kernel::ModuleMetadata for RustMinimal {
>        |                                               - while parsing th=
is item list starting here
>     29 |     const NAME: &'static ::kernel::str::CStr =3D c"rust_minimal"=
;
>        |                                                 ^^^^^^^^^^^^^^ e=
xpected one of 8 possible tokens
>     30 | }
>        | - the item list ends here
>        |
>        =3D note: you may be trying to write a c-string literal
>        =3D note: c-string literals require Rust 2021 or later
>        =3D help: pass `--edition 2024` to `rustc`
>        =3D note: for more on editions, read https://doc.rust-lang.org/edi=
tion-guide
>
> A workaround is to use `RUSTFMT=3Dn`, which is documented in the `Makefil=
e`
> help for cases where macro expanded source may happen to break `rustfmt`
> for other reasons, but this is not one of those cases.
>
> One solution would be to pass `--edition`, but we want `rustfmt` to
> use the entire configuration, even if currently we essentially use the
> default configuration.
>
> Thus explicitly give the path to the config file to `rustfmt` instead.
>
> Reported-by: Alice Ryhl <aliceryhl@google.com>
> Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Applied to `rust-fixes` -- thanks everyone!

Cheers,
Miguel


From - Sun Jan 18 19:48:28 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-210242-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 2IgpJXo4bWlHDyAAYBR5ng
	(envelope-from <stable+bounces-210242-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sun, 18 Jan 2026 19:46:02 +0000
Return-path: <stable+bounces-210242-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sun, 18 Jan 2026 19:46:02 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-210242-hi=josie.lol@vger.kernel.org>)
	id 1vhYio-00000009QPe-1Ud8
	for hi@josie.lol;
	Sun, 18 Jan 2026 19:46:02 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id C210F3009405
	for <hi@josie.lol>; Sun, 18 Jan 2026 19:45:59 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id E176A2236E5;
	Sun, 18 Jan 2026 19:45:58 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a1kGETeY"
X-Original-To: stable@vger.kernel.org
Received: from mail-dy1-f172.google.com (mail-dy1-f172.google.com [74.125.82.172])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8355B1367
	for <stable@vger.kernel.org>; Sun, 18 Jan 2026 19:45:57 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.172
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1768765558; cv=pass; b=fHUCD4dwpDHI9sUdGw1LHSqXmA/RKUMoh6Bx6jjdZba/hfK+K9dkpYxlQFOcRVAnGLf3L61Ou2O0TPYVrbKFc3UzC1IYT+bhXbl2e+vDwnznDUqe3lR34NYB+UGkFnCXg/qmtVJCfT3iLQO2PRYFpxnW5h/5oM4J4Rk8cw27fj8=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1768765558; c=relaxed/simple;
	bh=KVHaohjIpkS8RF4XW8vpNt+aWDOb9cyMHNvbV9tdgrM=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=Z+ryLaiiXvfwws/az2c1goA7WQOzyeJrdc4MLe61ejMcD6ZBnXOtzJs4dYrkWHCiZaMn/uiZFO3cMnjCyobDpujYeUGZAjH+OpysK/8TQ1JEZ3akn6GTwmOkFi62pYAcrtugqEn3lMWTkzXeS4USGN8lbu5Y9yyIFUCdgZpu3as=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a1kGETeY; arc=pass smtp.client-ip=74.125.82.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-dy1-f172.google.com with SMTP id 5a478bee46e88-2b1769fda0eso381959eec.3
        for <stable@vger.kernel.org>; Sun, 18 Jan 2026 11:45:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1768765557; cv=none;
        d=google.com; s=arc-20240605;
        b=cEJvgRgvGCE1n8hqMYkpCQOucNVfxKiwYTJAwnr/XZ+0YnumWmais5z3HAXFKUtgp0
         0Yn4U1buPuV+QpGLm4t5OAeRQPzM2qF28GzlKr88TRH7xvzpcUhJgyVJHDyrMEwz7EbZ
         wvNyybe/zH5UNaSBGnrDYCRoIkMnVBkCW56KCAD8hgGYvGpYE8IcvYgVRxPZz1Pw2Pd8
         WxNRDIz0a+PoGBczK7unnxllxC6gJlBdXw3HOSxbRebJlO1NA5Kp2/W728OlvLv8qSjJ
         VXDyUH3bnsHyvHWZcNVY2DLzi29VhLeHyPJ5cxwAZChi5Ts5RGFeNobnXIcEFSGdwzWd
         aVSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=ngLJEmbzzfwIyJl3HgdWne+DdSWDFYCnHseYetxWc3E=;
        fh=BKqfmJr9SM3MIMUl1osCjn1Ytx9JyYjOMDLcIwiTFsg=;
        b=RuKNmMAj6aG+nu4Z+47+gV9udI+iZZQLqHyFE/JQOlXqFQ2sQbhZb7ZFWeXIkin61S
         d8Rm2ZdS64YBjIcsba8Cet1hdBLd+/N+7ZD42xwwAHqRJZsOI4U4kt90jOEkfXL6MIJ6
         E8vHiZDwNFigj4EUSf9WZWs03mPZZgB+kF2PFicBolhwW7cWAchMlrIqlV+WYuHA3CsX
         MzJc30ynmEIWXn36fLGzZcRgKWw2oygdsk2JxbgzY5KFDh1F+4b6X6ddGw6bW6a9x+OX
         HTadVn/HitqThMRFwdbLJyMsjF9rsHzEosm4ZNV7uh1AXiwwlwJ0C+LxU1WS+a8zgTa8
         n0xQ==;
        darn=vger.kernel.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1768765557; x=1769370357; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ngLJEmbzzfwIyJl3HgdWne+DdSWDFYCnHseYetxWc3E=;
        b=a1kGETeYn96vfAtUMnq3WWCUyDjZfuOjIYO5KJfsxBT6XOBL2QZUW8WlSERfWCZ+4R
         e0ThKDKGRjJJDvZLq025pLtHvGAHBPFmGRlh7DLTdTbQ/q8qqCIl1Gja4gWBeKDzzBei
         04rmBcVo3YV5C7B4iUgHbopUVNusdCjvLjJDb8khHlngeQtBAtDmMUm4FgUMu28bMWI6
         SY2xT1DgfE+DjPc2xE72ZtSsMjciuJlnNaa4WYlOhU0KmbyL7DKEeW1m87TPhiT7s2DD
         3vLQMsnPtUnwrWHMlfJxSom9JF2UQtYpwmz1VfWTEAGzDq9Uxw4ZC9RNpAepSChWYcmW
         Ar1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1768765557; x=1769370357;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=ngLJEmbzzfwIyJl3HgdWne+DdSWDFYCnHseYetxWc3E=;
        b=CBqhXBui8dnP4/zrLIMz26lkMe2x7gGNGsFuGHE7cPspRLON4POXlNGuJ2ajBPto/j
         00BCwDbWaUYYr2yj7K7K8lZJs5H1PyRU81tp0uYlRSOcF0PwvcR466d3RdFM66UubvPO
         LLfAa36z0KWpBVcUcp1qyAKRhVVy954JkzngPJI2/+Sa5UKkrZTCsrax6MqIl0yW5lMM
         Wijt+T10vq7sgPOBXwlb6siPIl6RB3TEIKQxITJnyT0SIKHEMwAyeK2lySn7bweBB311
         pm8jhdrjfVC5Ui1jL4a5glrGsXFI8pn424evSK/MD8Ek2AIgBE2EBQFdJ26TUjBddgVN
         45Nw==
X-Forwarded-Encrypted: i=1; AJvYcCUVuou3LDl4CEsOLMbVXJ6BCHpgiJz5g5fSVWhSZktWofpF6K9u0v+hHoiy4AIsE83TtXduz+g=@vger.kernel.org
X-Gm-Message-State: AOJu0YwBZfHh3PtzyLrW66lTL+GMva/eFtDKOZeW7SHxVuUP62g3DI9E
	EH765gr/qUU0RQ1uepQXDZYCAM7kaAePNEY4OTpFrQLcIa85o8uOVEBiy4PRr/LY1TKfB2HgYsu
	WZuhsiI/PbpzhIY5hLNidZ0NLBoBOooM=
X-Gm-Gg: AY/fxX71QZh0dl1TxoGH9+JucQp8bvC2I0X+4clOQqhncNIgsO5NYYdfKm4FUkrlD2D
	c4uK0Xx7IqEryjDRZibUWh3FnqQ3cvU6mMzmmgM9g6aOf2AEy21sqaLIaiwz4orrCd4JKLPC24b
	2v1UaDoJf8Q9+1tccnzU0VdkkEAJIbOTyOpm42Rg8/3sPRrs2VWlNVAwnvuVOm/pRCQfakw46fI
	nXqghayHvhVaSo82Y1sdW/S1KB5/p1KtunQxwl2tqz8+J036Cd8ZlGeiUAvF3ZXy6pigQwn6JMh
	xREMpZ19Zx2SGUdVANhqetcH44U8mbJF0xB0wf8p7/uZJ5Bo6FOkabO7Ih/+zJd9156aTdnSm8f
	YmQDQ9XVbEYVT
X-Received: by 2002:a05:7301:3f19:b0:2a4:3592:cf89 with SMTP id
 5a478bee46e88-2b6b380ec55mr3935044eec.0.1768765556660; Sun, 18 Jan 2026
 11:45:56 -0800 (PST)
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20251208-io-build-assert-v3-0-98aded02c1ea@nvidia.com>
In-Reply-To: <20251208-io-build-assert-v3-0-98aded02c1ea@nvidia.com>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Sun, 18 Jan 2026 20:45:44 +0100
X-Gm-Features: AZwV_Qij1ytH7g1-A1PT-QCFQRqVSpKUckCbAvhQA3vEU6vow4n76J5rAgj9nXw
Message-ID: <CANiq72kvMp0KS0wXGYRiPOdNvJLoBpM45G7BHgPF_g-M9b5t_A@mail.gmail.com>
Subject: Re: [PATCH v3 0/7] rust: build_assert: document and fix use with
 function arguments
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Danilo Krummrich <dakr@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	Daniel Almeida <daniel.almeida@collabora.com>, Miguel Ojeda <ojeda@kernel.org>, 
	Alex Gaynor <alex.gaynor@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, 
	Gary Guo <gary@garyguo.net>, =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, 
	Benno Lossin <lossin@kernel.org>, Andreas Hindborg <a.hindborg@kernel.org>, 
	Trevor Gross <tmgross@umich.edu>, "Rafael J. Wysocki" <rafael@kernel.org>, 
	Viresh Kumar <viresh.kumar@linaro.org>, Will Deacon <will@kernel.org>, 
	Peter Zijlstra <peterz@infradead.org>, Mark Rutland <mark.rutland@arm.com>, 
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-pm@vger.kernel.org, stable@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-DKIM: signer='gmail.com' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider
                             [miguel.ojeda.sandonis[at]gmail.com]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: 4

On Mon, Dec 8, 2025 at 3:47=E2=80=AFAM Alexandre Courbot <acourbot@nvidia.c=
om> wrote:
>
>       rust: bits: always inline functions using build_assert with argumen=
ts
>       rust: sync: refcount: always inline functions using build_assert wi=
th arguments
>       rust: num: bounded: add missing comment for always inlined function

Applied to `rust-fixes` -- thanks everyone!

The first one I will apply it into`rust-next`.

Cheers,
Miguel


From - Sun rt: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: githubusercontent.com]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [192.30.252.207 listed in list.dnswl.org]
  1.5 HTML_MESSAGE           BODY: HTML included in message
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
  0.0 T_KAM_HTML_FONT_INVALID Test for Invalidly Named or Formatted
                             Colors in HTML
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.1 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 2


----==_mimepart_6970132741eb2_10c10c817704b
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

rsevilla87 left a comment (kube-burner/kube-burner#1059)

> I would like to see us have some user defined parameters to increase load over-time.
> 
> Here is what I am thinking... `--min-iterations` - What is the minimum number of iterations (basically the start of the test) `--step-size` - How much we want to increment the iterations to `--max-iterations` - Where do we stop. We could have 0 be keep going until health-check fails.
> 
> After each "step" we run the health-check to determine if the cluster is healthy, I think having some mechanism to poll the cluster for 5m (for example) to ensure nothing is flapping -- versus how we do healthy check now as a snapshot in time.

Overall this approach make sense to me, at this point I'm more worried about the implementation details, these high level flags shouldn't be added to "kube-burner", instead they can live within "kube-burner-ocp". The implementation in kube-burner itself should be driven through its configuration files like any other feature.

Something along these lines:

```yaml
jobss:
- name: incremental-load
  namespace: incremental-load
  jobIterations: 25                      # Maps to min-iterations
  maxJobIterations: 100            # Maps to max-iterations
  incrementalLoadDelay: 10s   # Wait 10 seconds before moving on to the next step
  objects:
  - objectTemplate: object.yml
    replicas: 1
```

With the above, `kube-burner`, should be able to run the `incremental-load` job in 4 batches of 25 iterations each, the calculation would be
```
batches = maxJobIterations / jobIterations
```
As suggested, we can run a health check between each batch.

In terms of metric collection and indexing, we should be able to identify which metric correspond to which batch, so we'll need to track the start/finish timestamps of each batch to include that data in the generated documents.

Last but not least, as suggested by @venkataanil, similar to  `jobIterationDelay`, (https://github.com/kube-burner/kube-burner/blob/main/pkg/config/types.go#L138-L139), having a parameter to introduce a quiet period between batches fits totally here.

Hope this helps

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kube-burner/kube-burner/issues/1059#issuecomment-3775462099
You are receiving this because you are subscribed to this thread.

Message ID: <kube-burner/kube-burner/issues/1059/3775462099@github.com>
----==_mimepart_6970132741eb2_10c10c817704b
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div style=3D"display: flex; flex-wrap: wrap; white-space: pre-wrap; alig=
n-items: center; "><img height=3D"20" width=3D"20" style=3D"border-radius=
:50%; margin-right: 4px;" decoding=3D"async" src=3D"https://avatars.githu=
busercontent.com/u/4614641?s=3D20&amp;v=3D4" /><strong>rsevilla87</strong=
> left a comment <a href=3D"https://github.com/kube-burner/kube-burner/is=
sues/1059#issuecomment-3775462099">(kube-burner/kube-burner#1059)</a></di=
v>
<blockquote>
<p dir=3D"auto">I would like to see us have some user defined parameters =
to increase load over-time.</p>
<p dir=3D"auto">Here is what I am thinking... <code class=3D"notranslate"=
>--min-iterations</code> - What is the minimum number of iterations (basi=
cally the start of the test) <code class=3D"notranslate">--step-size</cod=
e> - How much we want to increment the iterations to <code class=3D"notra=
nslate">--max-iterations</code> - Where do we stop. We could have 0 be ke=
ep going until health-check fails.</p>
<p dir=3D"auto">After each "step" we run the health-check to determine if=
 the cluster is healthy, I think having some mechanism to poll the cluste=
r for 5m (for example) to ensure nothing is flapping -- versus how we do =
healthy check now as a snapshot in time.</p>
</blockquote>
<p dir=3D"auto">Overall this approach make sense to me, at this point I'm=
 more worried about the implementation details, these high level flags sh=
ouldn't be added to "kube-burner", instead they can live within "kube-bur=
ner-ocp". The implementation in kube-burner itself should be driven throu=
gh its configuration files like any other feature.</p>
<p dir=3D"auto">Something along these lines:</p>
<div class=3D"highlight highlight-source-yaml" dir=3D"auto"><pre class=3D=
"notranslate"><span class=3D"pl-ent">jobss</span>:
- <span class=3D"pl-ent">name</span>: <span class=3D"pl-s">incremental-lo=
ad</span>
  <span class=3D"pl-ent">namespace</span>: <span class=3D"pl-s">increment=
al-load</span>
  <span class=3D"pl-ent">jobIterations</span>: <span class=3D"pl-c1">25</=
span>                      <span class=3D"pl-c"><span class=3D"pl-c">#</s=
pan> Maps to min-iterations</span>
  <span class=3D"pl-ent">maxJobIterations</span>: <span class=3D"pl-c1">1=
00</span>            <span class=3D"pl-c"><span class=3D"pl-c">#</span> M=
aps to max-iterations</span>
  <span class=3D"pl-ent">incrementalLoadDelay</span>: <span class=3D"pl-c=
1">10s</span>   <span class=3D"pl-c"><span class=3D"pl-c">#</span> Wait 1=
0 seconds before moving on to the next step</span>
  <span class=3D"pl-ent">objects</span>:
  - <span class=3D"pl-ent">objectTemplate</span>: <span class=3D"pl-s">ob=
ject.yml</span>
    <span class=3D"pl-ent">replicas</span>: <span class=3D"pl-c1">1</span=
></pre></div>
<p dir=3D"auto">With the above, <code class=3D"notranslate">kube-burner</=
code>, should be able to run the <code class=3D"notranslate">incremental-=
load</code> job in 4 batches of 25 iterations each, the calculation would=
 be</p>
<pre class=3D"notranslate"><code class=3D"notranslate">batches =3D maxJob=
Iterations / jobIterations
</code></pre>
<p dir=3D"auto">As suggested, we can run a health check between each batc=
h.</p>
<p dir=3D"auto">In terms of metric collection and indexing, we should be =
able to identify which metric correspond to which batch, so we'll need to=
 track the start/finish timestamps of each batch to include that data in =
the generated documents.</p>
<p dir=3D"auto">Last but not least, as suggested by <a class=3D"user-ment=
ion notranslate" data-hovercard-type=3D"user" data-hovercard-url=3D"/user=
s/venkataanil/hovercard" data-octo-click=3D"hovercard-link-click" data-oc=
to-dimensions=3D"link_type:self" href=3D"https://github.com/venkataanil">=
@venkataanil</a>, similar to  <code class=3D"notranslate">jobIterationDel=
ay</code>, (<a href=3D"https://github.com/kube-burner/kube-burner/blob/ma=
in/pkg/config/types.go#L138-L139">https://github.com/kube-burner/kube-bur=
ner/blob/main/pkg/config/types.go#L138-L139</a>), having a parameter to i=
ntroduce a quiet period between batches fits totally here.</p>
<p dir=3D"auto">Hope this helps</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />Reply to this email directly, <a href=3D"https://github.com/ku=
be-burner/kube-burner/issues/1059#issuecomment-3775462099">view it on Git=
Hub</a>, or <a href=3D"https://github.com/notifications/unsubscribe-auth/=
AFIGSX7RFKAH66ZETTK5GET4H24SPAVCNFSM6AAAAACPGTKKFKVHI2DSMVQWIX3LMV43OSLTO=
N2WKQ3PNVWWK3TUHMZTONZVGQ3DEMBZHE">unsubscribe</a>.<br />You are receivin=
g this because you are subscribed to this thread.<img src=3D"https://gith=
ub.com/notifications/beacon/AFIGSX5GURAW5M6VLBBFRYL4H24SPA5CNFSM6AAAAACPG=
TKKFKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTXBBD5NG.=
gif" height=3D"1" width=3D"1" alt=3D"" /><span style=3D"color: transparen=
t; font-size: 0; display: none; visibility: hidden; overflow: hidden; opa=
city: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all"=
>Message ID: <span>&lt;kube-burner/kube-burner/issues/1059/3775462099</sp=
an><span>@</span><span>github</span><span>.</span><span>com&gt;</span></s=
pan></p>

<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/kube-burner/kube-burner/issues/1059#issueco=
mment-3775462099",
"url": "https://github.com/kube-burner/kube-burner/issues/1059#issuecomme=
nt-3775462099",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>

----==_mimepart_6970132741eb2_10c10c817704b--

From - Tue Jan 20 23:46:35 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <noreply@github.com>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id OOIECdcTcGlDLDYAYBR5ng
	(envelope-from <noreply@github.com>)
	for <hi@josie.lol>; Tue, 20 Jan 2026 23:46:31 +0000
Return-path: <noreply@github.com>
Envelope-to: github@josie.lol
Delivery-date: Tue, 20 Jan 2026 23:46:31 +0000
Received: from out-28.smtp.github.com ([192.30.252.211])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <noreply@github.com>)
	id 1viLQd-0000000Fb4L-00xJ
	for github@josie.lol;
	Tue, 20 Jan 2026 23:46:31 +0000
Received: from github.com (hubbernetes-node-daf41e8.ash1-iad.github.net [10.56.188.38])
	by smtp.github.com (Postfix) with ESMTPA id A1E6F921103
	for <github@josie.lol>; Tue, 20 Jan 2026 15:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
	s=pf2023; t=1768952790;
	bh=2dtP5DFESG0EA1R8vjm5UH8CqVsELnmUy2L7T1Hr0v8=;
	h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
	 List-Archive:List-Post:List-Unsubscribe:List-Unsubscribe-Post:
	 From;
	b=HorRtOxUlcT5957uELcFeeM5oAoLFnxNyXOSuu1nfb0Vrcd/0ZGn/If5d+f973EIc
	 8fQmRVAtbVIH+DUDISBBj+cVFS3zwXvQTPjTzUdDwU03BYIT6rGDSlXllC2x7Yeav4
	 sqvJ7zv0dIMGzLQ+NUADwqhXEmLibdegXhYgM7+A=
Date: Tue, 20 Jan 2026 15:46:30 -0800
From: Moamen Zakaria <notifications@github.com>
Reply-To: kubernetes-sigs/karpenter-provider-ibm-cloud <reply+AFIGSXYIKHG5YIP7YRTVCLTJ425NNEVBNHHOH7ZQUQ@reply.github.com>
To: kubernetes-sigs/karpenter-provider-ibm-cloud <karpenter-provider-ibm-cloud@noreply.github.com>
Cc: Josephine Pfeiffer <github@josie.lol>, 
 Assign <assign@noreply.github.com>
Message-ID: <kubernetes-si