Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp946219pxb; Wed, 16 Feb 2022 07:43:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJyluoY8eO2tDz5qB9t9Tl/iYFhMiIcQiP0vxx3seEpb+QhYlmKrJLVeh/fNztj5OjC6kteK X-Received: by 2002:a05:6402:40c8:b0:410:815e:4239 with SMTP id z8-20020a05640240c800b00410815e4239mr3801562edb.194.1645026182065; Wed, 16 Feb 2022 07:43:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645026182; cv=none; d=google.com; s=arc-20160816; b=XBcQ9d0K+XCpphFo91Uu6Gvx7TT1xdRCKhD5mpPRxFPPhuYRNrWO8CGHpsBH4bUKVC ONVFNtmohC80FdX3HBbHKfV4TYff5D2PPahIIuuoHrO2wP+Z19gprR9Cnagnbs3pw8Ag 4+bIEmdkHCzwImh625ehiB9HxClsYsidKrxVTrzFuufrE1vV0HX8YqfUO3sZ92BzOfTJ BLwNAbioALP4THcCE38lJ4M5X1fRdl3qFddAb+3ghFn/iUdy+cKYMlM4v7ScrRc7J6Jy 9EToOoXtct5JajimHLlxZafqODoPIHE+4U0plVdTtnvDLfgqZ+z28WcvCE+0d36qE5M7 xSRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=LmcqWXwseeG4I4bS/aEDRBMabNjMhuU+WWEWJ2QVP0A=; b=L3W6LokpQLlBW1aVrM9nbTs82VlR4RSVpQVjt73nvJP373xv/kXypwwZrHGE1TlrVe UxVlFJErgtuvqg/rmohvJ+Kj1okZ6KezorIHHMzvLnvjZ4QNhZUZrClh/uZpqTGD/G5c aJl8bHXG3tou8CJnV2NlivebinfLe3ofNOXkcXOeAwRH8sOPaZlOd5mP1UgBxb8FRNYi 2Bv4YD/L+FkY3Zq6/sbpsjd24fKW1gOmCwV8YPkm2xGbpY8lB+pIa8l9+HZ3MpqDoj1E Sq7wWHM2yRufjAp/GTCw/vY8/EdUo6T1Po9M5Hwi3iOOJ+cHAyVLusLSZJisd+AL0Qdj HpuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=ZKF01vsC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z69si338921ede.507.2022.02.16.07.42.37; Wed, 16 Feb 2022 07:43:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=ZKF01vsC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234337AbiBPNVh (ORCPT + 99 others); Wed, 16 Feb 2022 08:21:37 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:37656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234617AbiBPNVM (ORCPT ); Wed, 16 Feb 2022 08:21:12 -0500 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F40F12AE072 for ; Wed, 16 Feb 2022 05:19:45 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id t14so3250956ljh.8 for ; Wed, 16 Feb 2022 05:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LmcqWXwseeG4I4bS/aEDRBMabNjMhuU+WWEWJ2QVP0A=; b=ZKF01vsC92N6eCOjhBPsAWtAZrJ2+kiOfO1gXjHOH2Ud6qWy/xyX1OTnnvoRGaIwbP 5n9+MOk4PuipHjTueQ6wblFJ7cr9DYnfRB7Es3RhOPNWzroAoT+w0M0ea8XP/bRvHeJg XX/xgFRS3/Ug6VnlsVKbpczbKHnaSo2spijefK0lldXkNMN4Ujsw0IL/BTKq07CiN4fp ceQ4MUf3VjH1KIZ87BWGsYxp8SBqEkbEVc0ZjYjJiHezLvFbyVPmaI76doac6fvirQjd jh9PDq42+MR90ozXBIP8ajeTx5uWQKohaF8G+HPze6qab35QaWxpb5/bYp9vEgx+iWNS CFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LmcqWXwseeG4I4bS/aEDRBMabNjMhuU+WWEWJ2QVP0A=; b=S8yZG6w5OrddAlZSiu54T2XJ0nDo1P5d+jQhQii0AKfRce1ZYfpsFxCfLiNtfccpV1 4bvf8j4XUEm9r/0qhqHbFRsgkEiYFHU9U1j7ZJApDjsX7GeCJ9dKz+THk01GRRjhq2z0 HrbwaeJFdX6bVCxtC/GxMaZu4TAeR3c9D+LqHM5xvy0ToeOjwLvCRsn6k3b/O8fWJKqx LDccrJfejrnA55zmkGsPd0M9fkRskcKog3RjagbgVB/cYfNfcyb6+wW4UtyPo6rfjbZ9 V4uUykkzeUrqsma/w4++ANo8YUnmwlXuGBuAEaPs5yeaJxfZcnLXhKOY6J8pvP9pBmqa cbLw== X-Gm-Message-State: AOAM533gkrwP+pOnyzHY+BbiVt10wKl+jUp26GKuYWJGB50l13B+r0Uo 1iB6I1rZU07ktmsYt+N4QFD3K6MqlveFafjzdQXf1w== X-Received: by 2002:a05:651c:549:b0:245:6f1:8584 with SMTP id q9-20020a05651c054900b0024506f18584mr2068100ljp.474.1645017584253; Wed, 16 Feb 2022 05:19:44 -0800 (PST) MIME-Version: 1.0 References: <20220216090845.1278114-1-maz@kernel.org> In-Reply-To: <20220216090845.1278114-1-maz@kernel.org> From: Marcin Wojtas Date: Wed, 16 Feb 2022 14:19:30 +0100 Message-ID: Subject: Re: [PATCH 0/2] net: mvpp2: Survive CPU hotplug events To: Marc Zyngier Cc: Linux Kernel Mailing List , netdev , Greg Kroah-Hartman , Russell King , "David S. Miller" , Jakub Kicinski , Thomas Gleixner , John Garry , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, =C5=9Br., 16 lut 2022 o 10:08 Marc Zyngier napisa=C5=82(a)= : > > I recently realised that playing with CPU hotplug on a system equiped > with a set of MVPP2 devices (Marvell 8040) was fraught with danger and > would result in a rapid lockup or panic. > > As it turns out, the per-CPU nature of the MVPP2 interrupts are > getting in the way. A good solution for this seems to rely on the > kernel's managed interrupt approach, where the core kernel will not > move interrupts around as the CPUs for down, but will simply disable > the corresponding interrupt. > > Converting the driver to this requires a bit of refactoring in the IRQ > subsystem to expose the required primitive, as well as a bit of > surgery in the driver itself. > > Note that although the system now survives such event, the driver > seems to assume that all queues are always active and doesn't inform > the device that a CPU has gone away. Someout who actually understand > this driver should have a look at it. > > Patches on top of 5.17-rc3, lightly tested on a McBin. > Thank you for the patches. Can you, please, share the commands you used? I'd like to test it more. Best regards, Marcin > Marc Zyngier (2): > genirq: Extract irq_set_affinity_masks() from > devm_platform_get_irqs_affinity() > net: mvpp2: Convert to managed interrupts to fix CPU HP issues > > drivers/base/platform.c | 20 +----- > drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 - > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 67 ++++++++++--------- > include/linux/interrupt.h | 8 +++ > kernel/irq/affinity.c | 27 ++++++++ > 5 files changed, 72 insertions(+), 51 deletions(-) > > -- > 2.30.2 >