From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4556C433EF for ; Thu, 30 Jun 2022 14:06:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236390AbiF3OGO (ORCPT ); Thu, 30 Jun 2022 10:06:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236294AbiF3OFw (ORCPT ); Thu, 30 Jun 2022 10:05:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAEE54D15D; Thu, 30 Jun 2022 06:53:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BD7D261FDB; Thu, 30 Jun 2022 13:53:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8AA6C34115; Thu, 30 Jun 2022 13:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597232; bh=Iu1OfCnEgYMCTBqhY7LS0FaFYOCSYNxznq0CJFpxzPg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WWZUE/fyIn8pGGtB0D0bnQV5Xemu/UaSyHvOgZfSHeW5ZFQwbI/5HZkUvHyk0LiXX cSpmDEGpS1TwFuYK21RJxvahzRFIH7edbjX2xqPQ93B2JQQm4+g2ZVWsKfyPbzJb2y vuUmy/9Ub6yT45kSND1Fsmth/m9JcKcrjZtBxkSc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Amir Goldstein Subject: [PATCH 5.10 01/12] MAINTAINERS: add Amir as xfs maintainer for 5.10.y Date: Thu, 30 Jun 2022 15:47:06 +0200 Message-Id: <20220630133230.722432211@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Amir Goldstein This is an attempt to direct the bots and human that are testing LTS 5.10.y towards the maintainer of xfs in the 5.10.y tree. This is not an upstream MAINTAINERS entry and 5.15.y and 5.4.y will have their own LTS xfs maintainer entries. Update Darrick's email address from upstream and add Amir as xfs maintaier for the 5.10.y tree. Suggested-by: Darrick J. Wong Link: https://lore.kernel.org/linux-xfs/Yrx6%2F0UmYyuBPjEr@magnolia/ Signed-off-by: Amir Goldstein Reviewed-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19246,7 +19246,8 @@ F: arch/x86/xen/*swiotlb* F: drivers/xen/*swiotlb* =20 XFS FILESYSTEM -M: Darrick J. Wong +M: Amir Goldstein +M: Darrick J. Wong M: linux-xfs@vger.kernel.org L: linux-xfs@vger.kernel.org S: Supported From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AB5FCCA47B for ; Thu, 30 Jun 2022 14:07:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236646AbiF3OG6 (ORCPT ); Thu, 30 Jun 2022 10:06:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236567AbiF3OGI (ORCPT ); Thu, 30 Jun 2022 10:06:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C3F14507B; Thu, 30 Jun 2022 06:54:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 875F3B82AEE; Thu, 30 Jun 2022 13:54:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E03C2C34115; Thu, 30 Jun 2022 13:54:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597243; bh=P8wgigXF/dPAJ0DvVhyrXIGDLXoNGiFI2i0TY4IRoeI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MkCo4VVpwa020p1hXsfEnSvGJHaHPSR+xOOLm6ZdoaBim/267mHSpizLbNipNDhPD uAJOcrUg98V6L0R53LpwvJhIrCCuZ/CN08ZtDWyXZrPO/3k9jqerK5dnb+4ktwIswH 4MMx7AZP3xT1eIMw7NOxk7qaKvlQN6ibGd7N+xD4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Vetter , Christoph Hellwig , Jessica Yu Subject: [PATCH 5.10 02/12] drm: remove drm_fb_helper_modinit Date: Thu, 30 Jun 2022 15:47:07 +0200 Message-Id: <20220630133230.753964438@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Christoph Hellwig commit bf22c9ec39da90ce866d5f625d616f28bc733dc1 upstream. drm_fb_helper_modinit has a lot of boilerplate for what is not very simple functionality. Just open code it in the only caller using IS_ENABLED and IS_MODULE, and skip the find_module check as a request_module is harmless if the module is already loaded (and not other caller has this find_module check either). Acked-by: Daniel Vetter Signed-off-by: Christoph Hellwig Signed-off-by: Jessica Yu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/drm_crtc_helper_internal.h | 10 ---------- drivers/gpu/drm/drm_fb_helper.c | 21 --------------------- drivers/gpu/drm/drm_kms_helper_common.c | 23 +++++++++++------------ 3 files changed, 11 insertions(+), 43 deletions(-) --- a/drivers/gpu/drm/drm_crtc_helper_internal.h +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h @@ -32,16 +32,6 @@ #include #include =20 -/* drm_fb_helper.c */ -#ifdef CONFIG_DRM_FBDEV_EMULATION -int drm_fb_helper_modinit(void); -#else -static inline int drm_fb_helper_modinit(void) -{ - return 0; -} -#endif - /* drm_dp_aux_dev.c */ #ifdef CONFIG_DRM_DP_AUX_CHARDEV int drm_dp_aux_dev_init(void); --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2271,24 +2271,3 @@ void drm_fbdev_generic_setup(struct drm_ drm_client_register(&fb_helper->client); } EXPORT_SYMBOL(drm_fbdev_generic_setup); - -/* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT) - * but the module doesn't depend on any fb console symbols. At least - * attempt to load fbcon to avoid leaving the system without a usable cons= ole. - */ -int __init drm_fb_helper_modinit(void) -{ -#if defined(CONFIG_FRAMEBUFFER_CONSOLE_MODULE) && !defined(CONFIG_EXPERT) - const char name[] =3D "fbcon"; - struct module *fbcon; - - mutex_lock(&module_mutex); - fbcon =3D find_module(name); - mutex_unlock(&module_mutex); - - if (!fbcon) - request_module_nowait(name); -#endif - return 0; -} -EXPORT_SYMBOL(drm_fb_helper_modinit); --- a/drivers/gpu/drm/drm_kms_helper_common.c +++ b/drivers/gpu/drm/drm_kms_helper_common.c @@ -64,19 +64,18 @@ MODULE_PARM_DESC(edid_firmware, =20 static int __init drm_kms_helper_init(void) { - int ret; + /* + * The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT) + * but the module doesn't depend on any fb console symbols. At least + * attempt to load fbcon to avoid leaving the system without a usable + * console. + */ + if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) && + IS_MODULE(CONFIG_FRAMEBUFFER_CONSOLE) && + !IS_ENABLED(CONFIG_EXPERT)) + request_module_nowait("fbcon"); =20 - /* Call init functions from specific kms helpers here */ - ret =3D drm_fb_helper_modinit(); - if (ret < 0) - goto out; - - ret =3D drm_dp_aux_dev_init(); - if (ret < 0) - goto out; - -out: - return ret; + return drm_dp_aux_dev_init(); } =20 static void __exit drm_kms_helper_exit(void) From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EA81C43334 for ; Thu, 30 Jun 2022 14:07:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236650AbiF3OHC (ORCPT ); Thu, 30 Jun 2022 10:07:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236584AbiF3OGJ (ORCPT ); Thu, 30 Jun 2022 10:06:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7C3E4D17F; Thu, 30 Jun 2022 06:54:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8379962110; Thu, 30 Jun 2022 13:54:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90DF1C34115; Thu, 30 Jun 2022 13:54:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597245; bh=LT6vxAJaxOlUkHNIIenFXTidkL0G26ejR08qb9ntrzU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=agMCABdyHKP0pr/5/d4YlKvvndOrZ2ZeLRVxuWpkHmqno9cqydcvPPHpov1kdEi/c dt40AsbyLTGvQPK+LgYVtsDSQ17EhKwv8aqj4YRZhzzYigd8QVCE95AyjL0knttesY R/LvLaFpIXFKEfhFepF7EBv4UHJjMUUhBgbqjfQg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Torvalds , Masahiro Yamada , "Paul E. McKenney" , Thomas Backlund Subject: [PATCH 5.10 03/12] tick/nohz: unexport __init-annotated tick_nohz_full_setup() Date: Thu, 30 Jun 2022 15:47:08 +0200 Message-Id: <20220630133230.783719499@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Masahiro Yamada commit 2390095113e98fc52fffe35c5206d30d9efe3f78 upstream. EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade. Commit 28438794aba4 ("modpost: fix section mismatch check for exported init/exit sections") fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Sec= tion mismatch in reference from the variable __ksymtab_tick_nohz_full_setup= to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or dro= p the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. Fixes: ae9e557b5be2 ("time: Export tick start/stop functions for rcutorture= ") Reported-by: Linus Torvalds Signed-off-by: Masahiro Yamada Tested-by: Paul E. McKenney Signed-off-by: Linus Torvalds Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/time/tick-sched.c | 1 - 1 file changed, 1 deletion(-) --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -425,7 +425,6 @@ void __init tick_nohz_full_setup(cpumask cpumask_copy(tick_nohz_full_mask, cpumask); tick_nohz_full_running =3D true; } -EXPORT_SYMBOL_GPL(tick_nohz_full_setup); =20 static int tick_nohz_cpu_down(unsigned int cpu) { From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E40E7C43334 for ; Thu, 30 Jun 2022 14:07:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236435AbiF3OHG (ORCPT ); Thu, 30 Jun 2022 10:07:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236593AbiF3OGJ (ORCPT ); Thu, 30 Jun 2022 10:06:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED0B86EEA9; Thu, 30 Jun 2022 06:54:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3BA176211C; Thu, 30 Jun 2022 13:54:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48116C34115; Thu, 30 Jun 2022 13:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597248; bh=tUbC9P3+yubDDefe29H5IMHi8x/o38Uf9ZD+Vi3xwK8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EUE8/8qagHcuvBzXf6NoH0yN3Jj4ZAmCTCIckudkX2FSUGcJsrySNKnk93i21osaB wgRltucYMpbCATxhU+7SAUCLWs1HqhUERNukD0YpeJ4Rbi7mxBeOB5Ue0H9hqDzuwE ujelhR/6ChSvkP0O7j6cNhP6f+92teAJralnhojI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Walleij , Daniel Lezcano Subject: [PATCH 5.10 04/12] clocksource/drivers/ixp4xx: remove __init from ixp4xx_timer_setup() Date: Thu, 30 Jun 2022 15:47:09 +0200 Message-Id: <20220630133230.813883677@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Greg Kroah-Hartman ixp4xx_timer_setup is exported, and so can not be an __init function. Remove the __init marking as the build system is rightfully claiming this is an error in older kernels. This is fixed "properly" in commit 41929c9f628b ("clocksource/drivers/ixp4xx: Drop boardfile probe path") but that can not be backported to older kernels as the reworking of the IXP4xx codebase is not suitable for stable releases. Cc: Linus Walleij Cc: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/clocksource/mmio.c | 2 +- drivers/clocksource/timer-ixp4xx.c | 10 ++++------ include/linux/platform_data/timer-ixp4xx.h | 5 ++--- 3 files changed, 7 insertions(+), 10 deletions(-) --- a/drivers/clocksource/mmio.c +++ b/drivers/clocksource/mmio.c @@ -46,7 +46,7 @@ u64 clocksource_mmio_readw_down(struct c * @bits: Number of valid bits * @read: One of clocksource_mmio_read*() above */ -int __init clocksource_mmio_init(void __iomem *base, const char *name, +int clocksource_mmio_init(void __iomem *base, const char *name, unsigned long hz, int rating, unsigned bits, u64 (*read)(struct clocksource *)) { --- a/drivers/clocksource/timer-ixp4xx.c +++ b/drivers/clocksource/timer-ixp4xx.c @@ -170,9 +170,8 @@ static int ixp4xx_resume(struct clock_ev * We use OS timer1 on the CPU for the timer tick and the timestamp * counter as a source of real clock ticks to account for missed jiffies. */ -static __init int ixp4xx_timer_register(void __iomem *base, - int timer_irq, - unsigned int timer_freq) +static int ixp4xx_timer_register(void __iomem *base, int timer_irq, + unsigned int timer_freq) { struct ixp4xx_timer *tmr; int ret; @@ -245,9 +244,8 @@ static __init int ixp4xx_timer_register( * @timer_irq: Linux IRQ number for the timer * @timer_freq: Fixed frequency of the timer */ -void __init ixp4xx_timer_setup(resource_size_t timerbase, - int timer_irq, - unsigned int timer_freq) +void ixp4xx_timer_setup(resource_size_t timerbase, int timer_irq, + unsigned int timer_freq) { void __iomem *base; =20 --- a/include/linux/platform_data/timer-ixp4xx.h +++ b/include/linux/platform_data/timer-ixp4xx.h @@ -4,8 +4,7 @@ =20 #include =20 -void __init ixp4xx_timer_setup(resource_size_t timerbase, - int timer_irq, - unsigned int timer_freq); +void ixp4xx_timer_setup(resource_size_t timerbase, int timer_irq, + unsigned int timer_freq); =20 #endif From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3034BC433EF for ; Thu, 30 Jun 2022 14:07:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236622AbiF3OHO (ORCPT ); Thu, 30 Jun 2022 10:07:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236603AbiF3OGM (ORCPT ); Thu, 30 Jun 2022 10:06:12 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0484B6F34C; Thu, 30 Jun 2022 06:54:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F0EDC61FC0; Thu, 30 Jun 2022 13:54:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04B85C34115; Thu, 30 Jun 2022 13:54:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597251; bh=38FD9szrywuOziQywvQPvGcPzan/Dfw4GrYnqgtmQ+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iDIju4ciZVfP4ktnj5MxmxGUzotkqX/AXCAY14ZTe1sG7S7vcWI3L7qZ3A5ImkOIs 24YQUSOmgrfOjCqpiNtNUOcmR60Yg5muY7XehLGE4kaEYMVW/lG4wH1Qi+zzc/8wha vi2JdtpT7izU1s1+CCL2mqxmdK+XpRYJ0l31WCRs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Coly Li , Jens Axboe Subject: [PATCH 5.10 05/12] bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init() Date: Thu, 30 Jun 2022 15:47:10 +0200 Message-Id: <20220630133230.843307110@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Coly Li commit 7d6b902ea0e02b2a25c480edf471cbaa4ebe6b3c upstream. The local variables check_state (in bch_btree_check()) and state (in bch_sectors_dirty_init()) should be fully filled by 0, because before allocating them on stack, they were dynamically allocated by kzalloc(). Signed-off-by: Coly Li Link: https://lore.kernel.org/r/20220527152818.27545-2-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/md/bcache/btree.c | 1 + drivers/md/bcache/writeback.c | 1 + 2 files changed, 2 insertions(+) --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -2017,6 +2017,7 @@ int bch_btree_check(struct cache_set *c) if (c->root->level =3D=3D 0) return 0; =20 + memset(&check_state, 0, sizeof(struct btree_check_state)); check_state.c =3D c; check_state.total_threads =3D bch_btree_chkthread_nr(); check_state.key_idx =3D 0; --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -901,6 +901,7 @@ void bch_sectors_dirty_init(struct bcach return; } =20 + memset(&state, 0, sizeof(struct bch_dirty_init_state)); state.c =3D c; state.d =3D d; state.total_threads =3D bch_btre_dirty_init_thread_nr(); From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2785AC433EF for ; Thu, 30 Jun 2022 14:08:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236724AbiF3OIz (ORCPT ); Thu, 30 Jun 2022 10:08:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236557AbiF3OG4 (ORCPT ); Thu, 30 Jun 2022 10:06:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EEC04F19E; Thu, 30 Jun 2022 06:54:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C64E861FDB; Thu, 30 Jun 2022 13:54:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D03D8C34115; Thu, 30 Jun 2022 13:54:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597254; bh=SbgGPTyNglffG3TwFHx2LhmFF+pZS8w3mcJvxg7lWy0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LnI4t9mBjn969MrsJPPTV2tstg8WB2cTq8PDbhaGXQUu7DTlkpchgzrhXMp0UMvg/ wuNjyxufwqztoRPcM8wUugaPCA6CL+ZyvnarlnnA1Sy/Sq7mdLuu4OSTOMIMSZGFs0 eQ9iYKAgQKOfxajLww1Z4BXSurLTiGjSejliHLU8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rustam Kovhaev , "Darrick J. Wong" , Amir Goldstein Subject: [PATCH 5.10 06/12] xfs: use kmem_cache_free() for kmem_cache objects Date: Thu, 30 Jun 2022 15:47:11 +0200 Message-Id: <20220630133230.871663272@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Rustam Kovhaev commit c30a0cbd07ecc0eec7b3cd568f7b1c7bb7913f93 upstream. For kmalloc() allocations SLOB prepends the blocks with a 4-byte header, and it puts the size of the allocated blocks in that header. Blocks allocated with kmem_cache_alloc() allocations do not have that header. SLOB explodes when you allocate memory with kmem_cache_alloc() and then try to free it with kfree() instead of kmem_cache_free(). SLOB will assume that there is a header when there is none, read some garbage to size variable and corrupt the adjacent objects, which eventually leads to hang or panic. Let's make XFS work with SLOB by using proper free function. Fixes: 9749fee83f38 ("xfs: enable the xfs_defer mechanism to process extent= s to free") Signed-off-by: Rustam Kovhaev Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_extfree_item.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_extfree_item.c +++ b/fs/xfs/xfs_extfree_item.c @@ -482,7 +482,7 @@ xfs_extent_free_finish_item( free->xefi_startblock, free->xefi_blockcount, &free->xefi_oinfo, free->xefi_skip_discard); - kmem_free(free); + kmem_cache_free(xfs_bmap_free_item_zone, free); return error; } =20 @@ -502,7 +502,7 @@ xfs_extent_free_cancel_item( struct xfs_extent_free_item *free; =20 free =3D container_of(item, struct xfs_extent_free_item, xefi_list); - kmem_free(free); + kmem_cache_free(xfs_bmap_free_item_zone, free); } =20 const struct xfs_defer_op_type xfs_extent_free_defer_type =3D { @@ -564,7 +564,7 @@ xfs_agfl_free_finish_item( extp->ext_len =3D free->xefi_blockcount; efdp->efd_next_extent++; =20 - kmem_free(free); + kmem_cache_free(xfs_bmap_free_item_zone, free); return error; } From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E77D0CCA481 for ; Thu, 30 Jun 2022 14:08:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236693AbiF3OIo (ORCPT ); Thu, 30 Jun 2022 10:08:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235377AbiF3OHC (ORCPT ); Thu, 30 Jun 2022 10:07:02 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B4DE4D163; Thu, 30 Jun 2022 06:54:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 48813B82AF4; Thu, 30 Jun 2022 13:54:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93668C34115; Thu, 30 Jun 2022 13:54:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597257; bh=y7RjIpPTJdsuZnRv738o0NqQH+oYqZEghea+VF06qW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I48QhDJ1kVd1ydGdQ6FmOnu4RIPBaprmOpbIRNFsEjuXlcth/LAZFAdJcpC/ubT4D caZ9qL9y9Audzq5GOMUriv8jzIEDAhP99AfhPly10vQuKYrgjhV5lQwfl1IND2HOxv 5bT93Wa+wsTbPOI6rdduWyj/fRuitK2bbRQvM6/w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , "Darrick J. Wong" , Amir Goldstein Subject: [PATCH 5.10 07/12] xfs: punch out data fork delalloc blocks on COW writeback failure Date: Thu, 30 Jun 2022 15:47:12 +0200 Message-Id: <20220630133230.906794591@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Brian Foster commit 5ca5916b6bc93577c360c06cb7cdf71adb9b5faf upstream. If writeback I/O to a COW extent fails, the COW fork blocks are punched out and the data fork blocks left alone. It is possible for COW fork blocks to overlap non-shared data fork blocks (due to cowextsz hint prealloc), however, and writeback unconditionally maps to the COW fork whenever blocks exist at the corresponding offset of the page undergoing writeback. This means it's quite possible for a COW fork extent to overlap delalloc data fork blocks, writeback to convert and map to the COW fork blocks, writeback to fail, and finally for ioend completion to cancel the COW fork blocks and leave stale data fork delalloc blocks around in the inode. The blocks are effectively stale because writeback failure also discards dirty page state. If this occurs, it is likely to trigger assert failures, free space accounting corruption and failures in unrelated file operations. For example, a subsequent reflink attempt of the affected file to a new target file will trip over the stale delalloc in the source file and fail. Several of these issues are occasionally reproduced by generic/648, but are reproducible on demand with the right sequence of operations and timely I/O error injection. To fix this problem, update the ioend failure path to also punch out underlying data fork delalloc blocks on I/O error. This is analogous to the writeback submission failure path in xfs_discard_page() where we might fail to map data fork delalloc blocks and consistent with the successful COW writeback completion path, which is responsible for unmapping from the data fork and remapping in COW fork blocks. Fixes: 787eb485509f ("xfs: fix and streamline error handling in xfs_end_io") Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_aops.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -145,6 +145,7 @@ xfs_end_ioend( struct iomap_ioend *ioend) { struct xfs_inode *ip =3D XFS_I(ioend->io_inode); + struct xfs_mount *mp =3D ip->i_mount; xfs_off_t offset =3D ioend->io_offset; size_t size =3D ioend->io_size; unsigned int nofs_flag; @@ -160,18 +161,26 @@ xfs_end_ioend( /* * Just clean up the in-memory strutures if the fs has been shut down. */ - if (XFS_FORCED_SHUTDOWN(ip->i_mount)) { + if (XFS_FORCED_SHUTDOWN(mp)) { error =3D -EIO; goto done; } =20 /* - * Clean up any COW blocks on an I/O error. + * Clean up all COW blocks and underlying data fork delalloc blocks on + * I/O error. The delalloc punch is required because this ioend was + * mapped to blocks in the COW fork and the associated pages are no + * longer dirty. If we don't remove delalloc blocks here, they become + * stale and can corrupt free space accounting on unmount. */ error =3D blk_status_to_errno(ioend->io_bio->bi_status); if (unlikely(error)) { - if (ioend->io_flags & IOMAP_F_SHARED) + if (ioend->io_flags & IOMAP_F_SHARED) { xfs_reflink_cancel_cow_range(ip, offset, size, true); + xfs_bmap_punch_delalloc_range(ip, + XFS_B_TO_FSBT(mp, offset), + XFS_B_TO_FSB(mp, size)); + } goto done; } From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB393C43334 for ; Thu, 30 Jun 2022 14:09:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236697AbiF3OJN (ORCPT ); Thu, 30 Jun 2022 10:09:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236547AbiF3OG4 (ORCPT ); Thu, 30 Jun 2022 10:06:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5BB76F342; Thu, 30 Jun 2022 06:54:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5CA916211A; Thu, 30 Jun 2022 13:54:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6137BC34115; Thu, 30 Jun 2022 13:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597259; bh=qiyJ6ZqStaVBXRF5MPGLLNG1dYk/bGu+j7tVjqJ/dcw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SsmcFZZM25AZy3jTIuTi/H+924QLi2hKHfl2bKVr4kihMGUyZP3A6/VVEW5O8PwGt P5CR2rWt4IJB97iP/IfyqxkyObDRTbSDO/h/xBPB+SdfkodaM2LTdxC1bkKnv9YWZ1 1qhTWsmgepddvLHDvR8trKLa12kgdou0DPByRSvU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yang Xu , "Darrick J. Wong" , Amir Goldstein Subject: [PATCH 5.10 08/12] xfs: Fix the free logic of state in xfs_attr_node_hasname Date: Thu, 30 Jun 2022 15:47:13 +0200 Message-Id: <20220630133230.938024271@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Yang Xu commit a1de97fe296c52eafc6590a3506f4bbd44ecb19a upstream. When testing xfstests xfs/126 on lastest upstream kernel, it will hang on s= ome machine. Adding a getxattr operation after xattr corrupted, I can reproduce it 100%. The deadlock as below: [983.923403] task:setfattr state:D stack: 0 pid:17639 ppid: 14687= flags:0x00000080 [ 983.923405] Call Trace: [ 983.923410] __schedule+0x2c4/0x700 [ 983.923412] schedule+0x37/0xa0 [ 983.923414] schedule_timeout+0x274/0x300 [ 983.923416] __down+0x9b/0xf0 [ 983.923451] ? xfs_buf_find.isra.29+0x3c8/0x5f0 [xfs] [ 983.923453] down+0x3b/0x50 [ 983.923471] xfs_buf_lock+0x33/0xf0 [xfs] [ 983.923490] xfs_buf_find.isra.29+0x3c8/0x5f0 [xfs] [ 983.923508] xfs_buf_get_map+0x4c/0x320 [xfs] [ 983.923525] xfs_buf_read_map+0x53/0x310 [xfs] [ 983.923541] ? xfs_da_read_buf+0xcf/0x120 [xfs] [ 983.923560] xfs_trans_read_buf_map+0x1cf/0x360 [xfs] [ 983.923575] ? xfs_da_read_buf+0xcf/0x120 [xfs] [ 983.923590] xfs_da_read_buf+0xcf/0x120 [xfs] [ 983.923606] xfs_da3_node_read+0x1f/0x40 [xfs] [ 983.923621] xfs_da3_node_lookup_int+0x69/0x4a0 [xfs] [ 983.923624] ? kmem_cache_alloc+0x12e/0x270 [ 983.923637] xfs_attr_node_hasname+0x6e/0xa0 [xfs] [ 983.923651] xfs_has_attr+0x6e/0xd0 [xfs] [ 983.923664] xfs_attr_set+0x273/0x320 [xfs] [ 983.923683] xfs_xattr_set+0x87/0xd0 [xfs] [ 983.923686] __vfs_removexattr+0x4d/0x60 [ 983.923688] __vfs_removexattr_locked+0xac/0x130 [ 983.923689] vfs_removexattr+0x4e/0xf0 [ 983.923690] removexattr+0x4d/0x80 [ 983.923693] ? __check_object_size+0xa8/0x16b [ 983.923695] ? strncpy_from_user+0x47/0x1a0 [ 983.923696] ? getname_flags+0x6a/0x1e0 [ 983.923697] ? _cond_resched+0x15/0x30 [ 983.923699] ? __sb_start_write+0x1e/0x70 [ 983.923700] ? mnt_want_write+0x28/0x50 [ 983.923701] path_removexattr+0x9b/0xb0 [ 983.923702] __x64_sys_removexattr+0x17/0x20 [ 983.923704] do_syscall_64+0x5b/0x1a0 [ 983.923705] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 983.923707] RIP: 0033:0x7f080f10ee1b When getxattr calls xfs_attr_node_get function, xfs_da3_node_lookup_int fai= ls with EFSCORRUPTED in xfs_attr_node_hasname because we have use blocktrash to random it in xfs/12= 6. So it free state in internal and xfs_attr_node_get doesn't do xfs_buf_trans relea= se job. Then subsequent removexattr will hang because of it. This bug was introduced by kernel commit 07120f1abdff ("xfs: Add xfs_has_at= tr and subroutines"). It adds xfs_attr_node_hasname helper and said caller will be responsible fo= r freeing the state in this case. But xfs_attr_node_hasname will free state itself instead of c= aller if xfs_da3_node_lookup_int fails. Fix this bug by moving the step of free state into caller. [amir: this text from original commit is not relevant for 5.10 backport: Also, use "goto error/out" instead of returning error directly in xfs_attr_= node_addname_find_attr and xfs_attr_node_removename_setup function because we should free state oursel= ves. ] Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Signed-off-by: Yang Xu Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/libxfs/xfs_attr.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -876,21 +876,18 @@ xfs_attr_node_hasname( =20 state =3D xfs_da_state_alloc(args); if (statep !=3D NULL) - *statep =3D NULL; + *statep =3D state; =20 /* * Search to see if name exists, and get back a pointer to it. */ error =3D xfs_da3_node_lookup_int(state, &retval); - if (error) { - xfs_da_state_free(state); - return error; - } + if (error) + retval =3D error; =20 - if (statep !=3D NULL) - *statep =3D state; - else + if (!statep) xfs_da_state_free(state); + return retval; } From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39E70C43334 for ; Thu, 30 Jun 2022 14:08:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236711AbiF3OIw (ORCPT ); Thu, 30 Jun 2022 10:08:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236679AbiF3OHW (ORCPT ); Thu, 30 Jun 2022 10:07:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3E0872EEA; Thu, 30 Jun 2022 06:54:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 132B061F5F; Thu, 30 Jun 2022 13:54:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 230BBC341CB; Thu, 30 Jun 2022 13:54:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597262; bh=YSrChqLUMjIgAIyGJymSZd2Gm+5E0kMjXymR4Fw4Kz8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xqt4fvJg53Eeg/SOdmmFnQUl9P1ZMHpLGSO9Km5tDaNjKWlQsPYuDqXoS+WCVUfXn I/aWZGobp6JBRU8UNCi5qGAfKzm1it0GvajzOGudUKSz2OSNux+kdKjsiGod+XRolL MiFFn1PYeH66voNzXU6ktUpKuz9UE6iXTbyIrL/I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Dave Chinner , Chandan Babu R , Amir Goldstein Subject: [PATCH 5.10 09/12] xfs: remove all COW fork extents when remounting readonly Date: Thu, 30 Jun 2022 15:47:14 +0200 Message-Id: <20220630133230.967036087@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Darrick J. Wong" commit 089558bc7ba785c03815a49c89e28ad9b8de51f9 upstream. [backport xfs_icwalk -> xfs_eofblocks for 5.10.y] As part of multiple customer escalations due to file data corruption after copy on write operations, I wrote some fstests that use fsstress to hammer on COW to shake things loose. Regrettably, I caught some filesystem shutdowns due to incorrect rmap operations with the following loop: mount # (0) fsstress & # (1) while true; do fsstress mount -o remount,ro # (2) fsstress mount -o remount,rw # (3) done When (2) happens, notice that (1) is still running. xfs_remount_ro will call xfs_blockgc_stop to walk the inode cache to free all the COW extents, but the blockgc mechanism races with (1)'s reader threads to take IOLOCKs and loses, which means that it doesn't clean them all out. Call such a file (A). When (3) happens, xfs_remount_rw calls xfs_reflink_recover_cow, which walks the ondisk refcount btree and frees any COW extent that it finds. This function does not check the inode cache, which means that incore COW forks of inode (A) is now inconsistent with the ondisk metadata. If one of those former COW extents are allocated and mapped into another file (B) and someone triggers a COW to the stale reservation in (A), A's dirty data will be written into (B) and once that's done, those blocks will be transferred to (A)'s data fork without bumping the refcount. The results are catastrophic -- file (B) and the refcount btree are now corrupt. Solve this race by forcing the xfs_blockgc_free_space to run synchronously, which causes xfs_icwalk to return to inodes that were skipped because the blockgc code couldn't take the IOLOCK. This is safe to do here because the VFS has already prohibited new writer threads. Fixes: 10ddf64e420f ("xfs: remove leftover CoW reservations when remounting= ro") Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Chandan Babu R Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_super.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1695,7 +1695,10 @@ static int xfs_remount_ro( struct xfs_mount *mp) { - int error; + struct xfs_eofblocks eofb =3D { + .eof_flags =3D XFS_EOF_FLAGS_SYNC, + }; + int error; =20 /* * Cancel background eofb scanning so it cannot race with the final @@ -1703,8 +1706,13 @@ xfs_remount_ro( */ xfs_stop_block_reaping(mp); =20 - /* Get rid of any leftover CoW reservations... */ - error =3D xfs_icache_free_cowblocks(mp, NULL); + /* + * Clear out all remaining COW staging extents and speculative post-EOF + * preallocations so that we don't leave inodes requiring inactivation + * cleanups during reclaim on a read-only mount. We must process every + * cached inode, so this requires a synchronous cache scan. + */ + error =3D xfs_icache_free_cowblocks(mp, &eofb); if (error) { xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); return error; From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FE98C43334 for ; Thu, 30 Jun 2022 14:06:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236283AbiF3OGK (ORCPT ); Thu, 30 Jun 2022 10:06:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236520AbiF3OFh (ORCPT ); Thu, 30 Jun 2022 10:05:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9B5A6EEBA; Thu, 30 Jun 2022 06:53:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D8F162112; Thu, 30 Jun 2022 13:53:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F036C34115; Thu, 30 Jun 2022 13:53:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597234; bh=HlUdkeevkwlkADXGp1lJ6XF/tQ3oXFSVRy8yE4P3sXM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zcy9xcN41hZIyKgAgBHrDctZ/6bJyoi6qaYYDcAZC0WvtblTiz3Dbcsk8XxdBIkHD 8SgSCJ/lxIXwTxNmsUsAaPSYwFwfS+KlzJmoCxH5xLRMQ2Xuaj76LDMD7DDv0yetej 6MnmExEil0zak/cqqp6qJWlkmcuUd+c/hBIwWY9I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Chinner , "Darrick J. Wong" , Amir Goldstein Subject: [PATCH 5.10 10/12] xfs: check sb_meta_uuid for dabuf buffer recovery Date: Thu, 30 Jun 2022 15:47:15 +0200 Message-Id: <20220630133230.996324972@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dave Chinner commit 09654ed8a18cfd45027a67d6cbca45c9ea54feab upstream. Got a report that a repeated crash test of a container host would eventually fail with a log recovery error preventing the system from mounting the root filesystem. It manifested as a directory leaf node corruption on writeback like so: XFS (loop0): Mounting V5 Filesystem XFS (loop0): Starting recovery (logdev: internal) XFS (loop0): Metadata corruption detected at xfs_dir3_leaf_check_int+0x99/= 0xf0, xfs_dir3_leaf1 block 0x12faa158 XFS (loop0): Unmount and run xfs_repair XFS (loop0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 3d f1 00 00 e1 9e d5 8b ........=3D....= ... 00000010: 00 00 00 00 12 fa a1 58 00 00 00 29 00 00 1b cc .......X...).... 00000020: 91 06 78 ff f7 7e 4a 7d 8d 53 86 f2 ac 47 a8 23 ..x..~J}.S...G.# 00000030: 00 00 00 00 17 e0 00 80 00 43 00 00 00 00 00 00 .........C...... 00000040: 00 00 00 2e 00 00 00 08 00 00 17 2e 00 00 00 0a ................ 00000050: 02 35 79 83 00 00 00 30 04 d3 b4 80 00 00 01 50 .5y....0.......P 00000060: 08 40 95 7f 00 00 02 98 08 41 fe b7 00 00 02 d4 .@.......A...... 00000070: 0d 62 ef a7 00 00 01 f2 14 50 21 41 00 00 00 0c .b.......P!A.... XFS (loop0): Corruption of in-memory data (0x8) detected at xfs_do_force_s= hutdown+0x1a/0x20 (fs/xfs/xfs_buf.c:1514). Shutting down. XFS (loop0): Please unmount the filesystem and rectify the problem(s) XFS (loop0): log mount/recovery failed: error -117 XFS (loop0): log mount failed Tracing indicated that we were recovering changes from a transaction at LSN 0x29/0x1c16 into a buffer that had an LSN of 0x29/0x1d57. That is, log recovery was overwriting a buffer with newer changes on disk than was in the transaction. Tracing indicated that we were hitting the "recovery immediately" case in xfs_buf_log_recovery_lsn(), and hence it was ignoring the LSN in the buffer. The code was extracting the LSN correctly, then ignoring it because the UUID in the buffer did not match the superblock UUID. The problem arises because the UUID check uses the wrong UUID - it should be checking the sb_meta_uuid, not sb_uuid. This filesystem has sb_uuid !=3D sb_meta_uuid (which is fine), and the buffer has the correct matching sb_meta_uuid in it, it's just the code checked it against the wrong superblock uuid. The is no corruption in the filesystem, and failing to recover the buffer due to a write verifier failure means the recovery bug did not propagate the corruption to disk. Hence there is no corruption before or after this bug has manifested, the impact is limited simply to an unmountable filesystem.... This was missed back in 2015 during an audit of incorrect sb_uuid usage that resulted in commit fcfbe2c4ef42 ("xfs: log recovery needs to validate against sb_meta_uuid") that fixed the magic32 buffers to validate against sb_meta_uuid instead of sb_uuid. It missed the magicda buffers.... Fixes: ce748eaa65f2 ("xfs: create new metadata UUID field and incompat flag= ") Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_buf_item_recover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -805,7 +805,7 @@ xlog_recover_get_buf_lsn( } =20 if (lsn !=3D (xfs_lsn_t)-1) { - if (!uuid_equal(&mp->m_sb.sb_uuid, uuid)) + if (!uuid_equal(&mp->m_sb.sb_meta_uuid, uuid)) goto recover_immediately; return lsn; } From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98922C433EF for ; Thu, 30 Jun 2022 14:06:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236618AbiF3OGW (ORCPT ); Thu, 30 Jun 2022 10:06:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236391AbiF3OFx (ORCPT ); Thu, 30 Jun 2022 10:05:53 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D06DC4D16A; Thu, 30 Jun 2022 06:54:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CD68EB82AD8; Thu, 30 Jun 2022 13:53:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32FCAC34115; Thu, 30 Jun 2022 13:53:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597237; bh=5cYcswnD9bzIj7ja95kn+E7EGC6en3Fc8aGW1HQhA4I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uE0IFEywkRw/ffiMCxGoJ5Iyy1YJprp7ZSZTYeFBA1wgO5R5vsLcOXrV6nn/gp2T6 hfMIrV3Zg/bSNd5KPFT5raAwQ8gQbBwDhwj4At9lh8Ve7ly5PoE66/MDsAXQYmQJ6G BGECJjPw2lZF5XsYXgw2/ONfYW/gHPNS5AxaqKbA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Naveen N. Rao" , Michael Ellerman Subject: [PATCH 5.10 11/12] powerpc/ftrace: Remove ftrace init tramp once kernel init is complete Date: Thu, 30 Jun 2022 15:47:16 +0200 Message-Id: <20220630133231.025237779@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naveen N. Rao commit 84ade0a6655bee803d176525ef457175cbf4df22 upstream. Stop using the ftrace trampoline for init section once kernel init is complete. Fixes: 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220516071422.463738-1-naveen.n.rao@linux.= vnet.ibm.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/powerpc/include/asm/ftrace.h | 4 +++- arch/powerpc/kernel/trace/ftrace.c | 15 ++++++++++++--- arch/powerpc/mm/mem.c | 2 ++ 3 files changed, 17 insertions(+), 4 deletions(-) --- a/arch/powerpc/include/asm/ftrace.h +++ b/arch/powerpc/include/asm/ftrace.h @@ -96,7 +96,7 @@ static inline bool arch_syscall_match_sy #endif /* PPC64_ELF_ABI_v1 */ #endif /* CONFIG_FTRACE_SYSCALLS */ =20 -#ifdef CONFIG_PPC64 +#if defined(CONFIG_PPC64) && defined(CONFIG_FUNCTION_TRACER) #include =20 static inline void this_cpu_disable_ftrace(void) @@ -120,11 +120,13 @@ static inline u8 this_cpu_get_ftrace_ena return get_paca()->ftrace_enabled; } =20 +void ftrace_free_init_tramp(void); #else /* CONFIG_PPC64 */ static inline void this_cpu_disable_ftrace(void) { } static inline void this_cpu_enable_ftrace(void) { } static inline void this_cpu_set_ftrace_enabled(u8 ftrace_enabled) { } static inline u8 this_cpu_get_ftrace_enabled(void) { return 1; } +static inline void ftrace_free_init_tramp(void) { } #endif /* CONFIG_PPC64 */ #endif /* !__ASSEMBLY__ */ =20 --- a/arch/powerpc/kernel/trace/ftrace.c +++ b/arch/powerpc/kernel/trace/ftrace.c @@ -336,9 +336,7 @@ static int setup_mcount_compiler_tramp(u =20 /* Is this a known long jump tramp? */ for (i =3D 0; i < NUM_FTRACE_TRAMPS; i++) - if (!ftrace_tramps[i]) - break; - else if (ftrace_tramps[i] =3D=3D tramp) + if (ftrace_tramps[i] =3D=3D tramp) return 0; =20 /* Is this a known plt tramp? */ @@ -882,6 +880,17 @@ void arch_ftrace_update_code(int command =20 extern unsigned int ftrace_tramp_text[], ftrace_tramp_init[]; =20 +void ftrace_free_init_tramp(void) +{ + int i; + + for (i =3D 0; i < NUM_FTRACE_TRAMPS && ftrace_tramps[i]; i++) + if (ftrace_tramps[i] =3D=3D (unsigned long)ftrace_tramp_init) { + ftrace_tramps[i] =3D 0; + return; + } +} + int __init ftrace_dyn_arch_init(void) { int i; --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -51,6 +51,7 @@ #include #include #include +#include =20 #include =20 @@ -347,6 +348,7 @@ void free_initmem(void) mark_initmem_nx(); init_mem_is_free =3D true; free_initmem_default(POISON_FREE_INITMEM); + ftrace_free_init_tramp(); } =20 /** From nobody Sun Apr 19 13:41:51 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 897DCC433EF for ; Thu, 30 Jun 2022 14:06:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232844AbiF3OGj (ORCPT ); Thu, 30 Jun 2022 10:06:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236431AbiF3OF5 (ORCPT ); Thu, 30 Jun 2022 10:05:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 461964D16F; Thu, 30 Jun 2022 06:54:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DB27662005; Thu, 30 Jun 2022 13:54:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E54B9C34115; Thu, 30 Jun 2022 13:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597240; bh=MN6iCT5yYY3Cx/dd3nAqdid5+V43uTKmGhUbJ6Qrbn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zwF57qaXk1gsuzauB093EG7eEifhX8CzKSIOHUcQUdQy84uOj5RUmevkdRxJM2VME Xnc5BWw5ZiwxcIjsorpQGZK8jkoMK2RMn9EF2y+QElI1hRtYLPEZAcpksmumCML6+f O6e2XEFLfh4+LAXF43Mzilm/alvMl+22ilbGpYYE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Vladimir Oltean Subject: [PATCH 5.10 12/12] net: mscc: ocelot: allow unregistered IP multicast flooding Date: Thu, 30 Jun 2022 15:47:17 +0200 Message-Id: <20220630133231.055686574@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133230.676254336@linuxfoundation.org> References: <20220630133230.676254336@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vladimir Oltean Flooding of unregistered IP multicast has been broken (both to other switch ports and to the CPU) since the ocelot driver introduction, and up until commit 4cf35a2b627a ("net: mscc: ocelot: fix broken IP multicast flooding"), a bug fix for commit 421741ea5672 ("net: mscc: ocelot: offload bridge port flags to device") from v5.12. The driver used to set PGID_MCIPV4 and PGID_MCIPV6 to the empty port mask (0), which made unregistered IPv4/IPv6 multicast go nowhere, and without ever modifying that port mask at runtime. The expectation is that such packets are treated as broadcast, and flooded according to the forwarding domain (to the CPU if the port is standalone, or to the CPU and other bridged ports, if under a bridge). Since the aforementioned commit, the limitation has been lifted by responding to SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS events emitted by the bridge. As for host flooding, DSA synthesizes another call to ocelot_port_bridge_flags() on the NPI port which ensures that the CPU gets the unregistered multicast traffic it might need, for example for smcroute to work between standalone ports. But between v4.18 and v5.12, IP multicast flooding has remained unfixed. Delete the inexplicable premature optimization of clearing PGID_MCIPV4 and PGID_MCIPV6 as part of the init sequence, and allow unregistered IP multicast to be flooded freely according to the forwarding domain established by PGID_SRC, by explicitly programming PGID_MCIPV4 and PGID_MCIPV6 towards all physical ports plus the CPU port module. Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support") Cc: stable@kernel.org Signed-off-by: Vladimir Oltean Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/mscc/ocelot.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/mscc/ocelot.c +++ b/drivers/net/ethernet/mscc/ocelot.c @@ -1593,8 +1593,12 @@ int ocelot_init(struct ocelot *ocelot) ocelot_write_rix(ocelot, ANA_PGID_PGID_PGID(GENMASK(ocelot->num_phys_ports, 0)), ANA_PGID_PGID, PGID_MC); - ocelot_write_rix(ocelot, 0, ANA_PGID_PGID, PGID_MCIPV4); - ocelot_write_rix(ocelot, 0, ANA_PGID_PGID, PGID_MCIPV6); + ocelot_write_rix(ocelot, + ANA_PGID_PGID_PGID(GENMASK(ocelot->num_phys_ports, 0)), + ANA_PGID_PGID, PGID_MCIPV4); + ocelot_write_rix(ocelot, + ANA_PGID_PGID_PGID(GENMASK(ocelot->num_phys_ports, 0)), + ANA_PGID_PGID, PGID_MCIPV6); =20 /* Allow manual injection via DEVCPU_QS registers, and byte swap these * registers endianness.