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 BFD00C433FE for ; Thu, 3 Nov 2022 20:39:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 438D26B0072; Thu, 3 Nov 2022 16:39:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E8A18E0001; Thu, 3 Nov 2022 16:39:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B0436B0074; Thu, 3 Nov 2022 16:39:36 -0400 (EDT) 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 19C156B0072 for ; Thu, 3 Nov 2022 16:39:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E3D0A1C6F6A for ; Thu, 3 Nov 2022 20:39:35 +0000 (UTC) X-FDA: 80093296710.21.B04C7C0 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by imf20.hostedemail.com (Postfix) with ESMTP id 80BDB1C0002 for ; Thu, 3 Nov 2022 20:39:35 +0000 (UTC) Received: by mail-qv1-f51.google.com with SMTP id x15so1975557qvp.1 for ; Thu, 03 Nov 2022 13:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LyVB93e4kr6HW490iz0JjvkzkF10jJfiYRfzQXQPofc=; b=ZfICdQ57uGJHF4OYcToaJcO61Joxd+rQUqggVs6a4vRPpvw5Vg54PJ58xxIdXvxuR7 zlTLX3eFjDabEVsc4tJElGaQSKA4jjYcEmtdv287OJpRHbf4noPP9LpSbndleJQO4hwl 65BMPDDrdnF7ZtDk3UTn91+OJFiO1xFMmPe5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=LyVB93e4kr6HW490iz0JjvkzkF10jJfiYRfzQXQPofc=; b=AWOX+fbG2LE89wLV48UUUyHfLzD0yHcF2OjMS5EFJ0Hp3vzrnfObP4vBzoBzcOrcgn IHuH6XGurQ7586v0nVvehv9GD/ouxf2BJ9eD/pKxoEYQFI91I0BBZHk/aGhY3iq0Hcps IokywxoiqpjH/jhQf4W1Nz08YKAddJcDiPm8iDSdkBBCyonqVyiEObdAqeTbZ/JkzAGB cp29fsxpK9aVKi2DGyHoNAc45dYPPEXfzKc6oTd1JN7KJ9LNG5erHRmlGbdVNXbld1I5 OzDkhyNgN4grTa6nfgWHuKztShPBn65mvYQmwgyG4DwgswYRgWEqbu5dm8BeBZMwyqUr YSKA== X-Gm-Message-State: ACrzQf0SOLhajKBkliDC/ZTgq+ZujktHvqhS1kSYBWrNy5aM4Wd/+05a beFZOSZJazO8AwwoOjQINdphgrUBPS7auA== X-Google-Smtp-Source: AMsMyM4JHW/OZmmZhaAAsLzMX34lz4xtr6c+yy0BrHJRG68oiXUHjI/YkKo+jHuyPZUxIT1hQ52K3Q== X-Received: by 2002:a0c:f491:0:b0:4bb:6387:51c7 with SMTP id i17-20020a0cf491000000b004bb638751c7mr28415891qvm.110.1667507974561; Thu, 03 Nov 2022 13:39:34 -0700 (PDT) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com. [209.85.219.169]) by smtp.gmail.com with ESMTPSA id i65-20020a378644000000b006ceb933a9fesm1373008qkd.81.2022.11.03.13.39.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 13:39:33 -0700 (PDT) Received: by mail-yb1-f169.google.com with SMTP id n130so3634498yba.10 for ; Thu, 03 Nov 2022 13:39:33 -0700 (PDT) X-Received: by 2002:a05:6902:124f:b0:66e:e3da:487e with SMTP id t15-20020a056902124f00b0066ee3da487emr32776102ybu.310.1667507973048; Thu, 03 Nov 2022 13:39:33 -0700 (PDT) MIME-Version: 1.0 References: <20221022111403.531902164@infradead.org> <20221022114425.168036718@infradead.org> In-Reply-To: From: Linus Torvalds Date: Thu, 3 Nov 2022 13:39:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 11/13] x86_64: Remove pointless set_64bit() usage To: Nathan Chancellor Cc: Uros Bizjak , Peter Zijlstra , x86@kernel.org, willy@infradead.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, aarcange@redhat.com, kirill.shutemov@linux.intel.com, jroedel@suse.de Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667507975; a=rsa-sha256; cv=none; b=33nhDu6nARcgCtouyHUkCMCHKJLlWqMIXTqzyD1RlExZiSm/Jc8+3FoC+oZwoZt+atFKNV qCInlaHQrDCzyvK0aHq/gtC64cMQfsJJ/bvMF+Bx6LL5orMtRP4JkvNub4s6E5KgjqijdO zJn5H0A1uMnXt7Qssb/xV9i1CTNVu5E= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZfICdQ57; dmarc=none; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.51 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667507975; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LyVB93e4kr6HW490iz0JjvkzkF10jJfiYRfzQXQPofc=; b=syYa2Ol4f/8tXWR1lPmJRrgIklU6mN/xpcFTcHNxo9IdoUXyBcxlgeszYpjSnSHpojOY5y wQr4E/A4cALRkkRIgWrddi6yTM7+bH45PXzTXNDeQ0MpF4biCsIG8gqcYZm93tXUedxK2H aNwr3oPOzw4O/pZfvDXMWd471gMrxb8= X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 80BDB1C0002 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZfICdQ57; dmarc=none; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.51 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Stat-Signature: tgk49y5ooajgb3cgnpumgw97ar7j3rcp X-HE-Tag: 1667507975-64686 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: On Thu, Nov 3, 2022 at 12:36 PM Nathan Chancellor wrote: > > Thanks, I also realized that only a couple minutes after I sent my > initial message. I just got done testing the following diff, which > resolves my issue. That looks obviously correct. Except in this case "obviously correct patch" is to some very non-obvious code, and I think the whole code around it is very very questionable. I had to actually go check that this code can only be enabled on x86-64 (because "IRQ_REMAP" has a "depends on X86_64" on it), because it also uses cmpxchg_double and that now exists on x86-32 too (but only does 64 bits, not 128 bits, of course). Now, to make things even more confusing, I think that #if defined(CONFIG_HAVE_CMPXCHG_DOUBLE) has *never* made sense, since it's always enabled for x86. HOWEVER - there were actually early AMD x86-64 machines that didn't have CMPXCHG16B. So the conditional kind of makes sense, but doing it based on CONFIG_HAVE_CMPXCHG_DOUBLE does not. It turns out that we do do this all correctly, except we do it at boot time, with a test for boot_cpu_has(X86_FEATURE_CX16): /* * Note: GA (128-bit IRTE) mode requires cmpxchg16b supports. * XT, GAM also requires GA mode. Therefore, we need to * check cmpxchg16b support before enabling them. */ if (!boot_cpu_has(X86_FEATURE_CX16) || ... but that #ifdef has apparenrly never been valid (I didn't go back and see if we at some point had a config entry for those old CPUs). And even after I checked *that*, I then checked the 'struct irte' to check that it's actually properly defined, and it isn't. Considering that this all requires 16-byte alignment to work, I think that type should also be marked as being 16-byte aligned. In fact, I wonder if we should aim to actually force compile-time checking, because right now we have VM_BUG_ON((unsigned long)(p1) % (2 * sizeof(long))); VM_BUG_ON((unsigned long)((p1) + 1) != (unsigned long)(p2)); in our x86-64 __cmpxchg_double() macro, and honestly, that first one might be better as a compile time check of __alignof__, and the second one shouldn't exisrt at all because our interface shouldn't be using two different pointers when the only possible use is for one single aligned value. If somebody actually wants the old m68k type of "DCAS" that did a cmpxchg on two actually *different* pointers, we should call it somethign else (and that's not what any current architecture does). So honestly, just looking at this trivially correct patch, I got into a rats nest of horribly wrong code. Nasty. Linus