From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9CEDC5B543 for ; Sat, 7 Jun 2025 08:52:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 487246B0092; Sat, 7 Jun 2025 04:52:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 437D26B0093; Sat, 7 Jun 2025 04:52:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34CBA6B0095; Sat, 7 Jun 2025 04:52:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 129D46B0092 for ; Sat, 7 Jun 2025 04:52:59 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 84F30161A75 for ; Sat, 7 Jun 2025 08:52:58 +0000 (UTC) X-FDA: 83527989636.28.9EEBE8A Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf27.hostedemail.com (Postfix) with ESMTP id 9D26D40003 for ; Sat, 7 Jun 2025 08:52:56 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UzFM85bC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=ubizjak@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749286376; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KFyeqit6vTlbw/r6iPxMrJhoHvnvByEOju0HOOfl2RQ=; b=1k1mJQ+QDXVeqAMx5CUoJSGSZvGW7+a8B9QeS2j17QAa1+eNluNMtilhy2pX+BkD7Pkz5G QFQokE1xAlZsbfk6dorl+gEf6JJ4pZMiPwK9/58sm5hgw5f0fKoYfToGMBbpZQWE+vg85c +LDWm+A+mD05kwo088h3qDYn1Ih8L7E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749286376; a=rsa-sha256; cv=none; b=s8usx4TBkQIZH30oU3h09H9QTx/DmqbgGDCCN3UqoWMJz1zJ1VBcOLeTy93GDbUw6M5L+d 4DorhiEcLypGv+YaHbX/jV+0oI1juesSOYfpcsioFPnpuVq3E5WG2YV7amZlhCF4WZs0MI lopq3n8SZugCKAaxMl5Ibgpbwmsayco= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UzFM85bC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=ubizjak@gmail.com Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-32918fe5334so28240581fa.1 for ; Sat, 07 Jun 2025 01:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749286375; x=1749891175; darn=kvack.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=KFyeqit6vTlbw/r6iPxMrJhoHvnvByEOju0HOOfl2RQ=; b=UzFM85bC4VhMLdkJUltKyPy8UuphWkAbOTQKRkPFPPEL7rvmSr8eun/aVcvSC4o8gV y5nKu1Ng7C5hiL9dFVVMmWpbPMSbBS2fmphrCbCjy+Mmo5w254WvaqSfMSumG4D7dKjk /tBZJmppuXGwxrjKVUGyO8/13AHU0CpA8dUfBAnwuGsXUehEgxDU/IZsLLlVPl30dctQ 2k9hXoY/3T1Xb+JZqaCo172qEUDdVWhgk3Px2r6K9dRbG43IUghYZh1HpykdZKtaFbXy t2sduL07pR4zC403v4V9EgtzT6mtuT9zq0fc7VBhcIdTfZVtH2oV4bz06RDc2OoHclkN ZObA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749286375; x=1749891175; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KFyeqit6vTlbw/r6iPxMrJhoHvnvByEOju0HOOfl2RQ=; b=MOwx+eMD/aFRI+fGmsgO6vlTgpRpZxisaMbziGAUVd+TYHl1wzS9xbaSrQTAhVy3CS sHYmnCYdOvJ8rpOlioATBqN2Jq5d7K1RGBzkDZWLbcLXs2Zlx9FXEJzO93q1t/hII6oz fPjN3GzQZ0YmG3BFEbDUviTrVbRTzcgPbnW3HN/lSpZaQ6FqwLYXNzkvSa1ILNT9RQ7K 2Em4LvMWXVMNJLkUXZcJ/xXVhV61NB23khGD5Ce7HHYmrR/NFu2R4S22AMvcB0JlTaed Os/YS93FJnt10ZXAnqx4XP8znTljVNeNb3UOAV9wSDdIF9g87tCu4LDM5HgRqwrfq1Nj JacQ== X-Forwarded-Encrypted: i=1; AJvYcCVrpAZbrtamlt98EHMcf5p56fqO0+FnIfZy5JxEySfF8/KATlz3qjqcZuUO6d/ie9bP28Y3uD+s3g==@kvack.org X-Gm-Message-State: AOJu0YwW+O1ItBXCuUIJn78IRO3na6OtA4MKZK5zCNbe+NC4EfavxP6C aZ6Qrqr5En3Ck4IKwrSEjk9JazexXB3vSagpVW006c69zWZue2Y3FC3jVE98bC/ukrveXg65W6A Msu54AmiqdlBvIcYX0M4GpmZypIDqwqc= X-Gm-Gg: ASbGnctGkPnSh5knh+xIwAn8pW8ft0xpxWMiTlAU1djcxqSkKp9fd5bAkOMwRIiD5V4 NxjQhhjK3YkJLpOD//ECHI3/emM4M/13gI2t4dlNP5TSxQeY0Z9u8LOCwQdf+dIaYNhZ1No/2EG tVgTEg6voUEjX40wx/1bezOOaUzX5ulyIu X-Google-Smtp-Source: AGHT+IEv37WjEi+vaAOMeA5SgqO5lvoauaHOHnb329J/YwAGAVcoSaaoQm5IHeU+YLfaL/u+ZCEwVl2jWuJ6emEkASk= X-Received: by 2002:a05:651c:2125:b0:32a:613b:270e with SMTP id 38308e7fff4ca-32adfbd6680mr15634651fa.31.1749286374353; Sat, 07 Jun 2025 01:52:54 -0700 (PDT) MIME-Version: 1.0 References: <20250127160709.80604-1-ubizjak@gmail.com> <20250127160709.80604-7-ubizjak@gmail.com> <02c00acd-9518-4371-be2c-eb63e5d11d9c@kernel.org> <9767d411-81dc-491b-b6da-419240065ffe@kernel.org> <6412d84a-edc3-4723-89f1-b2017fb0d1ea@intel.com> In-Reply-To: <6412d84a-edc3-4723-89f1-b2017fb0d1ea@intel.com> From: Uros Bizjak Date: Sat, 7 Jun 2025 10:52:51 +0200 X-Gm-Features: AX0GCFvfdq2FOXmAZPfE7zBP4TMsOLROw_40PNuCe1ZfMVOzlSJ4vDSOaP8ertQ Message-ID: Subject: Re: Large modules with 6.15 [was: [PATCH v4 6/6] percpu/x86: Enable strict percpu checks via named AS qualifiers] To: Dave Hansen Cc: Jiri Slaby , x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-arch@vger.kernel.org, netdev@vger.kernel.org, Nadav Amit , Dennis Zhou , Tejun Heo , Christoph Lameter , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Linus Torvalds , Andy Lutomirski , Brian Gerst , Peter Zijlstra , Shung-Hsi Yu , Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9D26D40003 X-Stat-Signature: spiwtoxfgmwxm96nnyjk3nsndpoata86 X-Rspam-User: X-HE-Tag: 1749286376-43509 X-HE-Meta: U2FsdGVkX19GVdCWYtTwxqO+5Mk54NtQ6d49I/yiKB3FmFmZZB0JIbNPWzJJdnHMyOjdR9ZKNjUFDXsRmcMZ0F7MMODg+4bqldIhVcdRpPKcCEpnZV0S0mf9VYY3JoSSzozu9BHqC0bh5VWq4dpYG05iaHIqkl6+axWyswWL+nsXAOvbPEbwzmG8nS7Lr8g7ZSmfnK8BinFHnrODk6+PUCLlov/TbRe+8D0ek0y9et9y1biMXzT1WbHoVCmEMh+lOPuDSfYwpRBGj0EJd+tZtItmPrBG4ihCJZiLW7C0JirSVv0wdoQNTrsq6NllVQmGHgEaAZTf17G7ANin22UYcRZCkbhg1Rh0S73Yxt9uZZi22gjC39UJkniFd4L5YeKMe5cE4yPWmr6vfJ0KOINKnel0g6oNcqzE5vayFX0IkZxs2lPl2TQkILFJncAk8yf0cpZdJwoxpzNR1K0eZa3K8deGurlC7fyZ+57sQX4UCc39ai6o7Xo31dObeXdIfr41CbRBC3PI62BsAxq9lD+x7eRuHpJ69ZNWrZIOrFTUcQUOfFBim4iEiBNJPmNEHLOVXm4brJMHjUcOwQ0N7jwL11hNENWovY4aUNHaNNZ6IH07/Jtt+n3kIaTp+Ob+jokUxghjkqpaG/K66vGHxQoq/l0KK+Zt7dLuM9t+TZfibNHwmSanLGx1LsaVvXMQY1p3ZnO4ALumsrG/bnuBo01gutVGC/6wFzb5JvzRiDN5p/83dqKaVQ8K80GCMm9nEbtmhjZzavHXWsZt+mOlYWZoCC/igQBcajssM+2ynN1RFvJ37E6TB6kpAKWjHVXkgpegxlvzf3oFyA2gP1TWUvqIbrAPFGDPuVVUljUDPccEpiC9uHNaB5mM4C2AieTyscHfkgW8/q/hBDVPv6PcxaZq/n9c46qWRIt1z+J4bsr7glqljSpeLpAXl+Ei7O2wSGx9HEhR1o7RVRWKUx8DSju sRSCBawq D+ifGVzCVQAkIbpWsLPIVNUkYAxCusE5namL7StPgKVo4CyDX9aYOzD5X9fSid+SO/BqBikJQ7s4Z4Pb4TNWqsqz1nvKA+1CQNIppeo6RlFGwaTgMBaQDAaQzzGPAyol9rP1Oy+/ZTsbVOGvb8+BCreS93M+br+dhP1cQSNAJh06Bm2royXUwV0lADsczabf/lTt+hp30PUIAoydMiQCdFVd1/25qD3Oawm/AsaqctcvwZQB7j0mJFYnjFNd3ke2rN8VLEWk8z1Km53EzYQKYFPlpD+YdzFBTfqE4j8vaE8pQ/bTfR7iPxMkW1515yM4CxGKqAhJW6SntBZnJ16DKr6Iw2gkGb8r6P8Eu8rkO1JiSN8+ltItDXKtjPHK/SQY5PqpripF7wbLeKpfZdcIfC794V6pDNugsTqbaCEc+cshy/tU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 6, 2025 at 5:44=E2=80=AFPM Dave Hansen = wrote: > > On 6/6/25 02:17, Jiri Slaby wrote: > > Given this is the second time I hit a bug with this, perhaps introduce > > an EXPERIMENTAL CONFIG option, so that random users can simply disable > > it if an issue occurs? Without the need of patching random userspace an= d > > changing random kernel headers? > > What about something like the attached (untested) patch? That should at > least get folks back to the old, universal working behavior even when > using new compilers. IMO the commit message is unnecessarily overly dramatic. The "nasty bugs" were in fact: - unfortunate mix of clang < 19 and new gcc-14 [1], fixed by robustifying the detection of typeof_unqual [1] https://lore.kernel.org/lkml/CA+G9fYuP2bHnDvJwfMm6+8Y8UYk74qCw-2HsFyRzJ= DFiQ5dbpQ@mail.gmail.com/ - sparse doesn't understand new keyword, patch at [2], but sparse is effectively unmaintained so a workaround is in place [2] https://lore.kernel.org/linux-sparse/5b8d0dee-8fb6-45af-ba6c-7f74aff9a4= b8@stanley.mountain/ - genksyms didn't understand the new keyword, fixed by [3]. [3] https://lore.kernel.org/lkml/174461594538.31282.5752735096854392083.tip= -bot2@tip-bot2/ - a performance regression, again due to the unfortunate usage of old gcc-13 [4]. The new gcc-14 would break compilation due to the missing __percpu qualifier. This is one of the examples, where new checks would prevent the issue during the development. Fixed with the help of gcc-14. [4] https://lore.kernel.org/all/CAADnVQ+iFBxauKq99=3D-Xk+BdG+Lv=3DXgvwi1dC4= fpG0utmXJiiA@mail.gmail.com/ - the issue in this thread, already fixed/worked around. Looking at the fix, I don't think gcc is at fault, but I speculate that there could be some invalid assumption about dwarf representation of variables in non-default address space at play. I'll look at this one in some more detail. Please also note that besides the above issues, the GCC type system and related checks around named address spaces was rock solid; there were *zero* bugs regarding __percpu variables, and the referred patch moves *all of them* to __seg_gs named address space. The patch builds off an equally stable and now well proven GCC named address space support, so in my opinion, it *is* ready for prime time. As demonstrated in the above list of issues, it was *never* the compiler at fault. Let me reiterate what the patch brings to the table. It prevents invalid references of per cpu variables to non-percpu locations. One missing percpu dereference can have disastrous consequences (all CPUs will access data in the shared space). Currently, the safety builds on checking sparse logs, but sparse errors don't break the build. With new checks in place, *every* invalid access is detected and breaks the build with some 50 lines of errors. Hiding these checks behind the CONFIG_EXPERT option breaks the intention of the patch. IMO, it should be always enabled to avoid errors, mentioned in the previous paragraph, already during the development time. I'm much more inclined to James' proposal. Maybe we can disable these checks in v6.15 stable series, but leave them in v6.16? This would leave a couple of months for distributions to update libbpf. Thanks, Uros.