Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1275332pxu; Sat, 12 Dec 2020 07:31:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7pk64WvQRq/ugGONXtppTQCVQax3S7bNYEYbwHC/PGW6+NnN93mAFGP3JrWZOg2jXj1ho X-Received: by 2002:aa7:cd9a:: with SMTP id x26mr16604607edv.226.1607787102809; Sat, 12 Dec 2020 07:31:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607787102; cv=none; d=google.com; s=arc-20160816; b=lJyHBenFZqfp0/+nGyDhGaL7duNJgPh5xfqG3yfZZzwN9/B0sHJGToiIkUCT2FhB1N FKak/zxhZiWMLet3V2iguAHDp2oaCXMb2U79Z+hEkeUTJrhOTxtmQCBsFaTi+5BqVRbe p8dC5rLy6GooWjSsD/sJ/FqJE/h6/bAOD/V6/q/0EMvbIWJCOZ8P8zJxn0jdpeFyXlkf HHTNZyPso5y2L2ZXEAXH2q5h0HU47rDNKc1RqsDHGGSaWJVphhvfjiXAX2dtuqmbWw8O N8iM62SVlH3xpJ0ZaDiMaZ/oidz3CJ/il6DFpIe7IWcndI3gQznaYKFBqGXNUip/bdqx f41g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gM69V9onbZaSEKvDodMrLsWMXGl6YnsxHFzlmXcxA9Y=; b=c0djbBMsz7gbFt2BqfF6rXKrjG2rAyw6Pb/P+OCUsUEZpD3F0vVDlz9ExqPgeMrdG+ 7lcqvoV2R3kWCN2g7cRNrsEM9VPZ4u+a+bzi8R9MaOmYegktSeLvr1uZvOQZ10Ofa5D1 5iozH7P0jbAfq/K/UvwPZN+JgmLmXyb5zad3+TNGEYux80I09vVSXEMfmBc8K/Bk9xe8 ksYj/wxrbGPxfJ3JpsG4K7Z1fF++HnwKMrow+Tt2MpvgGxlIZZhvbyPvGd5ITJQKA3z1 BNC0UAJxLR4SNOXCR0ZbnDg4+zAEEDb7BRb7N9Hx0B8po/cPc3a/Uwfq+zGRCo7Hgmrs HMyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BOUz6eYF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de20si6825613edb.171.2020.12.12.07.31.19; Sat, 12 Dec 2020 07:31:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BOUz6eYF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393863AbgLKNwK (ORCPT + 99 others); Fri, 11 Dec 2020 08:52:10 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:59285 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390535AbgLKNv4 (ORCPT ); Fri, 11 Dec 2020 08:51:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607694630; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gM69V9onbZaSEKvDodMrLsWMXGl6YnsxHFzlmXcxA9Y=; b=BOUz6eYFebWwm3dxwUlW9piR8Q3OOd0OZbgZLqM2y5HE1r5h50Hi7O5LeafjjfLuQr3HfF Wnv5jb+A1Do9Xt/yEBpkGHiHWMlx3KE1ouSgbRf75kMI2PAykwhZdt37wO+FDVaquo9iJy tB256ic8+kijnG9xgj52U+ZN8YCW/Mw= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-3-BOMVnZ8XMbeFvnhz6OgDAg-1; Fri, 11 Dec 2020 08:50:28 -0500 X-MC-Unique: BOMVnZ8XMbeFvnhz6OgDAg-1 Received: by mail-qv1-f72.google.com with SMTP id j24so6465804qvg.8 for ; Fri, 11 Dec 2020 05:50:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gM69V9onbZaSEKvDodMrLsWMXGl6YnsxHFzlmXcxA9Y=; b=r5AFwgjyYvxf6C+faLjxUaKy9eEmoU5+rcJrXWoqw/3Im6Q85GgAhkckB15fTFqvUT HxhSoFLTsBzArHqOgdE8FdiQMamESaCii83PXWKn4mQ5ADMoYt4frmJ91bCVsQrr4ud/ X4NYYTZLdOBusY+cASqJS3DVyOnltfRYlQeoJbgYEfdyvl5GOAnMLAAktvGK5HgBdCEX cwYS1pf7Rsh4U5vHO6rCtmvwDWD29TPQJ2eDnWBkIbiOTyQZCFbfbIRllCKv6Gzsug2/ e68zs5T6+z9hiyFi18n9dWV54WOTPBQZ0VGtie2DscNHCGV7U8LOsRb/oy6ouEMgKMF3 VRMw== X-Gm-Message-State: AOAM530Ht8IIxzkYYQp9iJNq5B4xw+QpJPwK3LNDEvD0Mr0+vn5wjS6H i+KJj+Re3ANnC9nGeutoHLcIBzlaopYJbuf4w5lDtRtEf/l931BijW+NPG8uw4JAt3WsY6Yi7NQ PitXoFEt6101WtaT5M/ZzBUBG X-Received: by 2002:a0c:ee87:: with SMTP id u7mr15458749qvr.21.1607694628097; Fri, 11 Dec 2020 05:50:28 -0800 (PST) X-Received: by 2002:a0c:ee87:: with SMTP id u7mr15458721qvr.21.1607694627847; Fri, 11 Dec 2020 05:50:27 -0800 (PST) Received: from xz-x1 ([142.126.83.202]) by smtp.gmail.com with ESMTPSA id u26sm7092520qke.57.2020.12.11.05.50.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Dec 2020 05:50:27 -0800 (PST) Date: Fri, 11 Dec 2020 08:50:25 -0500 From: Peter Xu To: Thomas Gleixner Cc: LKML , x86@kernel.org, Shung-Hsi Yu , Prarit Bhargava , Ming Lei Subject: Re: [PATCH] x86/apic/vector: Fix ordering in vector assignment Message-ID: <20201211135025.GA6520@xz-x1> References: <87ft4djtyp.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ft4djtyp.fsf@nanos.tec.linutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 10, 2020 at 09:18:22PM +0100, Thomas Gleixner wrote: > Prarit reported that depending on the affinity setting the > > ' irq $N: Affinity broken due to vector space exhaustion.' > > message is showing up in dmesg, but the vector space on the CPUs in the > affinity mask is definitely not exhausted. > > Shung-Hsi provided traces and analysis which pinpoints the problem: > > The ordering of trying to assign an interrupt vector in > assign_irq_vector_any_locked() is simply wrong if the interrupt data has a > valid node assigned. It does: > > 1) Try the intersection of affinity mask and node mask > 2) Try the node mask > 3) Try the full affinity mask > 4) Try the full online mask > > Obviously #2 and #3 are in the wrong order as the requested affinity > mask has to take precedence. > > In the observed cases #1 failed because the affinity mask did not contain > CPUs from node 0. That made it allocate a vector from node 0, thereby > breaking affinity and emitting the misleading message. > > Revert the order of #2 and #3 so the full affinity mask without the node > intersection is tried before actually affinity is broken. > > If no node is assigned then only the full affinity mask and if that fails > the full online mask is tried. > > Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor") > Reported-by: Shung-Hsi Yu > Reported-by: Prarit Bhargava > Signed-off-by: Thomas Gleixner > Tested-by: Shung-Hsi Yu > Cc: stable@vger.kernel.org Reviewed-by: Peter Xu -- Peter Xu