: 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 wrote: > From: Kairui Song > > 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: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id ILkUEto3bWlQThwAYBR5ng (envelope-from ) for ; Sun, 18 Jan 2026 19:43:22 +0000 Return-path: 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 ) 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 ; 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 ; 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 ; 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: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260115183832.46595-1-ojeda@kernel.org> In-Reply-To: <20260115183832.46595-1-ojeda@kernel.org> From: Miguel Ojeda Date: Sun, 18 Jan 2026 20:43:03 +0100 X-Gm-Features: AZwV_Qird-lwibLosQ8SVV1mDXaYy8TIK_gyKIQwJqqY-9VOd-kxYQI5T5v3RQE Message-ID: Subject: Re: [PATCH] rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target To: Miguel Ojeda Cc: Nathan Chancellor , Nicolas Schier , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , 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 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 > Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") > Cc: stable@vger.kernel.org > Signed-off-by: Miguel Ojeda 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: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 2IgpJXo4bWlHDyAAYBR5ng (envelope-from ) for ; Sun, 18 Jan 2026 19:46:02 +0000 Return-path: 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 ) 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 ; 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 ; 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 ; 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: List-Subscribe: List-Unsubscribe: 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 Date: Sun, 18 Jan 2026 20:45:44 +0100 X-Gm-Features: AZwV_Qij1ytH7g1-A1PT-QCFQRqVSpKUckCbAvhQA3vEU6vow4n76J5rAgj9nXw Message-ID: Subject: Re: [PATCH v3 0/7] rust: build_assert: document and fix use with function arguments To: Alexandre Courbot Cc: Danilo Krummrich , Alice Ryhl , Daniel Almeida , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , "Rafael J. Wysocki" , Viresh Kumar , Will Deacon , Peter Zijlstra , Mark Rutland , 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 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: ----==_mimepart_6970132741eb2_10c10c817704b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 (basi= cally 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 ke= ep 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 cluste= r 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 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.

Something along these lines:

jobss:
- name: incremental-lo=
ad
  namespace: increment=
al-load
  jobIterations: 25                      # Maps to min-iterations
  maxJobIterations: 1=
00            # M=
aps to max-iterations
  incrementalLoadDelay: 10s   # Wait 1=
0 seconds before moving on to the next step
  objects:
  - objectTemplate: ob=
ject.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 =3D maxJob=
Iterations / jobIterations

As suggested, we can run a health check between each batc= h.

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 jobIterationDel= ay, (https://github.com/kube-burner/kube-bur= ner/blob/main/pkg/config/types.go#L138-L139), having a parameter to i= ntroduce a quiet period between batches fits totally here.

Hope this helps

&m= dash;
Reply to this email directly, view it on Git= Hub, or unsubscribe.
You are receivin= g this because you are subscribed to this thread.3D""Message ID: <kube-burner/kube-burner/issues/1059/3775462099@github.com>

----==_mimepart_6970132741eb2_10c10c817704b-- From - Tue Jan 20 23:46:35 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id OOIECdcTcGlDLDYAYBR5ng (envelope-from ) for ; Tue, 20 Jan 2026 23:46:31 +0000 Return-path: 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 ) 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 ; 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 Reply-To: kubernetes-sigs/karpenter-provider-ibm-cloud To: kubernetes-sigs/karpenter-provider-ibm-cloud Cc: Josephine Pfeiffer , Assign Message-ID: