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 863E5E7717D for ; Fri, 13 Dec 2024 04:29:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14ACD6B0088; Thu, 12 Dec 2024 23:29:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FC116B0089; Thu, 12 Dec 2024 23:29:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F043B6B008A; Thu, 12 Dec 2024 23:29:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CB4C86B0088 for ; Thu, 12 Dec 2024 23:29:06 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A7BAB1A045D for ; Fri, 13 Dec 2024 04:29:05 +0000 (UTC) X-FDA: 82888654884.13.5BA336F Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf19.hostedemail.com (Postfix) with ESMTP id 2917B1A0015 for ; Fri, 13 Dec 2024 04:28:36 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bpGSXFBI; spf=pass (imf19.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734064132; 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=uCvQILuEqni9koGNIRPa0LCov9Nq5Mb+hDK4nC1Iwh8=; b=TbsiOhT+JOR8ogtjRYWvbteqKhl6uNgXO4UnzqM7jS4PXYC/xKoTPZDy++6fVZW4pnfWKD OZOE32iAgyZgjYRvd91n9jJj52fZNhGo6BrK4pOHC/5iMQojaeRQIKgbUQx7V4kjDbd92e RnmSOQCKgu9fVrXd+vW5J1zC4G0aw84= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bpGSXFBI; spf=pass (imf19.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734064132; a=rsa-sha256; cv=none; b=UwMGd/V7O7k5H1GST1S3niBp+LMsCaeHfPtBA/0ae/MfMrEk0Pz3khLq2/6YuE0RYtVtCK gaCcbkTHP52KGrB8yeNt7RwL/nstxfrAXagRyTd2IDUfYeOhp3cLbH2mDMLdE40/AaVQ// pWvFewQ6477ShK2tdnlLGTCj/oi7A64= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-30033e07ef3so14022241fa.0 for ; Thu, 12 Dec 2024 20:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734064142; x=1734668942; 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=uCvQILuEqni9koGNIRPa0LCov9Nq5Mb+hDK4nC1Iwh8=; b=bpGSXFBIvNFD8rFSaQvOB/kn6/yVPpIs2K3VJ86TWxlQ112K+yuj2SMJU5aO4RdjVq qi3mMuzJpTZqp8iwEdZiQiY5XrqhotafPKw4y+xgtgVtz5g/kTaj4mf4Zndy23f/H0FA 5FF1DCug2fDrmixjSj/jRAsqlHo01wPLD8H0JjUfD9TxIdHaMQUnKU4Vu3urxNl9yctI RQ6Cyew4EOpIC+ahcR3AqhRzTMRL02X+HOxGNrPtdTTSlJ43X66iWpGpS4Dmi6KSXZJz dXx2a7Jy5ZSLQwLbAuooAbQy92msVj0DxPESsXFaw+aHNcEHjhipI68pbA1rn5Y/Mwbe TjJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734064142; x=1734668942; 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=uCvQILuEqni9koGNIRPa0LCov9Nq5Mb+hDK4nC1Iwh8=; b=iFjFIYKonxXEU6N1vI1z4bknqvrcaDjYlz9D84XWSHRbMbz8m6VSQbSRyPy/Le6iZL 8HkVPv1/Vi6UnMvkDIGXZ0flwSTVyBgGiQxmrMhlq/5oURdQkK8NxrweJfGh0Fm3BItC 2cSbFW4awvGUYDh+Ajg3Nt56ti4sBjO/WS107luxJ6kXn8gqXcVP1OOtf6NxJuuPuZAR UcTz2EOthQLF3hSpw2vA2XaWgPN4ePTYRMtrWSqDaQwW0xK6kCQhEpaKjPVTWUKzSQ8j H9zAFa+aeIz1o0vKE1KOdkZYikcb1ePu72mtSb2ihqxqzF7TQlworC+fOJgg5Z9nLbom P9pQ== X-Forwarded-Encrypted: i=1; AJvYcCUHe6Ku7e6hUqKj/pNvQyhFyoRWhJx4YKlgdr+H0w3EjglzqjE82JOkGpUD60W6Kvb/0X0/J2OiVQ==@kvack.org X-Gm-Message-State: AOJu0YzbHefG3loQjkiL2APLVcgnM7rRtGESOc/GfIkUuuadyHRiDGol ks1Tkg/J560MSVs2R4iVPGWXTYVWvtycUNKocyOyDDckf2ZYX3A9wOmJ3j12yTgaJCX67bzhZce UdN4cJaUgnoJ+lanvd6DfX+qbJUU= X-Gm-Gg: ASbGncseU9Wscoqu49MPJisKxD4N0C0b9AoGkzvsy22W2nAOl8hO5D8qTSh8gVUyXVq ZKhF5MydBn+FO2WmGiAk0O+tCvrQ0xh7Q1KWTDg== X-Google-Smtp-Source: AGHT+IHhIZMzrUjX6OhgTdgCbFrO6miMc56t5nTDb6E+vXxnejuRboiGgCQouuWXc64JICWARJa+c4QiTrxibRLPcbM= X-Received: by 2002:a2e:a58e:0:b0:302:215f:94ee with SMTP id 38308e7fff4ca-30251be6cc4mr9687611fa.4.1734064141597; Thu, 12 Dec 2024 20:29:01 -0800 (PST) MIME-Version: 1.0 References: <20241208204708.3742696-1-ubizjak@gmail.com> <20241212193541.fa3dcac867421a971c38135c@linux-foundation.org> In-Reply-To: <20241212193541.fa3dcac867421a971c38135c@linux-foundation.org> From: Uros Bizjak Date: Fri, 13 Dec 2024 05:28:50 +0100 Message-ID: Subject: Re: [PATCH v3 0/6] Enable strict percpu address space checks To: Andrew Morton Cc: 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, Thomas Gleixner , Dennis Zhou , Tejun Heo , Christoph Lameter , Linus Torvalds , Andy Lutomirski , Ingo Molnar , Nadav Amit , Brian Gerst , Dan Carpenter , "H . Peter Anvin" , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2917B1A0015 X-Stat-Signature: ewus6ugxczomeh1f7f7bmqjqiwz1ozxp X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1734064116-292572 X-HE-Meta: U2FsdGVkX18WUP74eOaOxdcVMzemIyRlEHTDzJOmIDjO2ksF5u62Rk25QfqK/ACGGr2H3bI/Hiq12kaKMQo76aYNoXOw77lWqZi7X/2Xl1p/+0Nf/HFvqOe7Wlbmxz7TJsv9pmsPCPKg6Dy54DdS4L4gkmjslFv2xbc562zXPgNNFvf+dZyAMM5B6KIzxafN8XX7Nli8VFd3MvaayDc+eRqNNlhob4p513DpcsKPSQyzN2ljz7w4ApTgv4BgXD8i8wfRPeieV21oU8XewClw0TbqY7Ob9xAlqxx18JnGPNI1KQb4kHaNky8vOKADbM+n50D71NnyUjV58zQv2Z6u55S0Y45BS+7jeXnOWdApilJqgDpq+KdSlocxIdZ9S5C8UiSh/m9EndfEXEPOVarBn03nO8lVnKHJluwunqgkFnRRIyuAJ7kHEFnrXnCSQGrC9NY6L8SSK3Mw27ngGs5+ETSHDdbm/N8kM8bNZNncj5SO2bDhXbJEKXdXcOIcmD90mrvKQ8aRMa1RpSlqlDTDtgKlBpiFwiiYu52wjQKyvchUTafr1Gp8uRDgcwRqNAEopyxtRRfjI8MXPQEJCAX+grTDO+UKicjl9xyfwWP9/RTNDRAW5qYAPJYPiaQGwPSbztpuQlYp/ZxO+bCfFygNV+v3ZSvkUmk1ciXpDKUjkbUlRSkEpnJLBVt2L62uUYzVRaM8+qLV9cyITbPUwggx5uxlbnLNkYuTi0YmSMgHV7RYT7qxAUrQSnXUmPTjAXZpVmCp6qAxu1K0wwVemNNcPzn54VmXbPpZvCiicoG1XmrUFrTm3mPEbl/vT9Aubb28KCGHZl8b7PSukZlrm1yT/XfqU5hs4YwErsZGp2fvKRCXdU7gCQNhBJieoYGeA/+4mcOYSR+jgKIDiEk9K02HGXrOWASzR5zgV3qN4RpO1AExHPzvgEPTyKSwgooXfOFiNhhqwpfw5rLDPAWnrlo iza4VuBr 93aIpvgcVEpj5V6Qq7J6icowDo9veAdw41iD8J5i3cs9V7rvDI/c+0AfuE0HEFoMXTTbSNaxzopnc0VqXqSLlHKzSz+dyUCKfbhatXLhRoab/MC6Q2DLswt7GCnM/EK3yTo+nz3bBJsZQoBW0WZgBBLwW0ZNdnNcifrdx7tc18eQJrti1I07wLasTwQhsg7xs2DJJffGTCnWFa6kYlSZndmBM1J0oyJzoTaJajUlDf3u1MHzW13bT5dezFw76BnovN8VerzXWQ2DjGW4dcmDGzdSslNmuSp+96aUStyGk4vnk4Fi+iPNLGclST2AgPIgfZ2UWim8APkbu6AjbTVcZEeQ3wTaCG19RpnyXnVq0Hm7F2vbydajJ8FfSU4eGXsNNBzQ+QjguaThxIdBZZhL4iyBPA2yL09OEdOjPa2qYg10FPNg2b1lDIaezSO5v7e6Z+bAEVNSEpPMppsAV93LkUDY5LJHsC4akw0DKr0uUjWQuZc3c9aFZXzQSqXZ62FSc7bB0xjuu1XUjNhiQ4Q58D5u/R/nXhgSnZxUx8muQrIsq3WqUR84283NsTVmmBsxUPZnVOnijID40tMuuT8p0xCO6CA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.020536, 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, Dec 13, 2024 at 4:35=E2=80=AFAM Andrew Morton wrote: > > On Sun, 8 Dec 2024 21:45:15 +0100 Uros Bizjak wrote: > > > Enable strict percpu address space checks via x86 named address space > > qualifiers. Percpu variables are declared in __seg_gs/__seg_fs named > > AS and kept named AS qualified until they are dereferenced via percpu > > accessor. This approach enables various compiler checks for > > cross-namespace variable assignments. > > > > Please note that current version of sparse doesn't know anything about > > __typeof_unqual__() operator. Avoid the usage of __typeof_unqual__() > > when sparse checking is active to prevent sparse errors with unknowing > > keyword. The proposed patch by Dan Carpenter to implement > > __typeof_unqual__() handling in sparse is located at: > > google("what the hell is typeof_unequal") failed me. It is not "typeof_unequal", but "typeof_unqual", as in "unqualified". Apparently, google does not like expletives, googling for "What is typeof_unqual?" returns some very informative hits, e.g.: https://en.cppreference.com/w/c/keyword/typeof_unqual https://learn.microsoft.com/en-us/cpp/c-language/typeof-unqual-c?view=3Dmsv= c-170 https://gcc.gnu.org/onlinedocs/gcc/Typeof.html https://dev.to/pauljlucas/typeof-in-c23-55p2 > I think it would be nice to include within the changelog (and code > comments!) an explanation-for-others of what this thing is and why > anyone would want to use it. Rather than assuming that all kernel > developers are typeof() experts! The comment above definition of TYPEOF_UNQUAL in [PATCH 2/6] summarises the above as: + * Define TYPEOF_UNQUAL() to use __typeof_unqual__() as typeof + * operator when available, to return unqualified type of the exp. which is basically what the standard says in its reference document. Thanks, Uros.