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;
Date:   Wed, 2 Nov 2022 02:36:16 +0000
From:   Yazen Ghannam <yazen.ghannam@amd.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Greg KH <gregkh@linuxfoundation.org>, linux-edac@vger.kernel.org,
        linux-kernel@vger.kernel.org, tony.luck@intel.com, x86@kernel.org,
        Smita.KoralahalliChannabasappa@amd.com, mpatocka@redhat.com
Subject: Re: [PATCH] x86/MCE/AMD: Decrement threshold_bank refcount when
 removing threshold blocks
Message-ID: <Y2HXoHeFt+BJRb6n@yaz-fattaah>
References: <20220614174346.3648305-1-yazen.ghannam@amd.com>
 <Yql9TqFtebd2h9Z9@kroah.com>
 <Yqnj88FPkZ6kBU7k@yaz-fattaah>
 <Y1kJCHBtatohj/JK@zn.tnic>
 <Y1kiNBh3/XBNe6uv@kroah.com>
 <Y1lUo08UzaqIaI7r@yaz-fattaah>
 <Y1l8nx1KnTFP1xKj@zn.tnic>
 <Y1mOEfEM6MdnV8CX@yaz-fattaah>
 <Y1mUn/xvx1RYPqAQ@zn.tnic>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y1mUn/xvx1RYPqAQ@zn.tnic>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?P4tHvgPf7imcy8dF15Hg2aNuT8f4Zn23DO988oa5fWLm8EIYXZopwR9b/Fla?=
 =?us-ascii?Q?fTtmC3ujJb4cqvlf/cuPDpHG4i//DKJPtfDrahu9/SN+NZMJxXhZ8q3PvUL6?=
 =?us-ascii?Q?t1CAL7RfI/z1YrfZc9/gQgFZWY0ZF3elaN4yMtWB2do7o9qyEPvPGEh/MeIW?=
 =?us-ascii?Q?N15Ji10nfA9wKv9hvH30eSx4oFzK4AsVV4o9RhqFXUb1TLZ6v8SxYtKXkyfc?=
 =?us-ascii?Q?ETx1OtG/kJvD+rxB0ZB7B6IAhKkWgwHIVZmQj+0lZi3rI1CJiIM0QyhK8wvn?=
 =?us-ascii?Q?SlNya1oE1R0xHzMm23iBstOYRwNiQo1GQJGOJ7neX0U9GlH3uDoBHcHVq9lT?=
 =?us-ascii?Q?myNVgb2Vd6mTO+Ts8gaH+yGDvze7oNBasU4XFCLlZ8kpmajwUfN76Qqj+NcH?=
 =?us-ascii?Q?E/r9z+IYFZ1u2JAzMCqc5ILDx8O4qijDRdWY3epBbdiCMRlmNKEagEgXLkp6?=
 =?us-ascii?Q?mu84F6WwoWAM6XFFeZeDKnnJkEXV53/XHbavaMocCYaGki/bpiWlEAD7/2jE?=
 =?us-ascii?Q?LVrmj8qPQuqZfenTTIKecEH05F0uum5TaV8fDjIzKTRLblxRbPPBR4R39M3v?=
 =?us-ascii?Q?ocwaKpm5AyeH0Ox7iwKCA9ayO6hR8Q5i3HSgsJXreZeNKDAS1hmD9/mRdmme?=
 =?us-ascii?Q?EwD0RQB6YX8fZ/A1UmEp6ZxzM6XEtGsG86YGVJdojl16aALkOE8WvhEvowQX?=
 =?us-ascii?Q?Jmmdqj3hPiHUFO+/Rn+1gt3Z2xJ8pWBEnS4Aw3+YQjsUBbiGuja07EW/gC3Y?=
 =?us-ascii?Q?SE1lVwcjJzcXcHEg4KbhxfaVb0Jkf+Jgv/PxnK1QmAd3eerAst0HJ4B1x/aI?=
 =?us-ascii?Q?kLNu5WImmd7MNOSEACjRU8Ez4c8b0thaXvv9AseqxRxCEityBL50vWz8Twom?=
 =?us-ascii?Q?4dE2Vz4EL1zHAyV/UxQt9kRK08wpRc1o/KprUHMeTpwyzeTt1kqT2eK/1Ywf?=
 =?us-ascii?Q?AQT8AC8c/UTTnrmEPCZsjovSfZ9nZsMOq2+f6mouk9AVNxKaSsqYZ2hfvAiA?=
 =?us-ascii?Q?2H2CexNdjwiIcKLIGc8CFbF5ENXzS9ZEqrQiL4KTtJXKPzr+YPsQvLHzqKZo?=
 =?us-ascii?Q?H/CYdYWQrgGLPxnz7lLwYWJnoNpKEYuj9/pan3z8zGvB1dEQ7c/3Qcm77fE5?=
 =?us-ascii?Q?+PpTucDnMlPFeubeIaq0Rcm07plfE68yBqU3XwBSpBiFQUDhl5uiH7us+UF3?=
 =?us-ascii?Q?6szN9RH2PswXjqbEilxoQqKnbS3pgSr/3ERD4ia+6JhNZ20REvhHezOEAXlD?=
 =?us-ascii?Q?sT21lValw3iy0uQllxXvzF34cWGyx7IsotjLAYZISk+RtLrxgzWacXCP9Uqj?=
 =?us-ascii?Q?AGvPBdyyVkOQ4kjt19I1yJx9RcBdgrDRCAnjX/IRPuUoWKA1wQj1syt9CN23?=
 =?us-ascii?Q?XfHGZVSdJieS/hKw4eJdGc+1UO4zCw9vlReMcipuKXQ/AE4X6GbWl3DS8R1r?=
 =?us-ascii?Q?MghLQWsm9sPN4Sio6ER4lmKKAihg7LSHl5OrA+ECCSmTRlRzhxKRHSjbTAl3?=
 =?us-ascii?Q?NABSVrCMWpWcpzL/Ca5sRb0ZzgDRp6MO/VjftTcc8SU/tJrA68//tH4MUtLU?=
 =?us-ascii?Q?IZYW6CwPVe2eYvOcwa7IOk477VsS4Hnt9/Gg7Nd8?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8df55ded-e945-485f-4187-08dabc7b05c3
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3108.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2022 02:36:19.2840
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: +2uXrMT3wLlJd7g2oKmE4gjzQ/2nzPKIBIHn4vKCGiXBIqQw+UXZ8WDmh/nORqhVFzHNRBHBoLmw7TLMEnmrHw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7098
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Oct 26, 2022 at 10:12:15PM +0200, Borislav Petkov wrote:
> On Wed, Oct 26, 2022 at 07:44:17PM +0000, Yazen Ghannam wrote:
> > 1) Apply the patch I submitted as a simple fix/workaround for the presented
> > symptom. I tried to keep it small and well described to be a stable backport.
> > Obviously I wrote it without knowing the shared kobject behavior isn't ideal.
> 
> We'll see.
> 
> > 2) Address the shared kobject thing.
> >    Here are some options:
> >    a. Only set up the thresholding kobject on a single CPU per "AMD Node".
> >    Technically MCA Bank 4 is "shared" on legacy systems. But AFAICT from
> >    looking at old BKDG docs, in practice only the "Node Base Core" can access
> >    the registers. This behavior is controlled by a bit in NB which BIOS is
> >    supposed to set. Maybe some BIOSes don't do this, but I think that's a
> >    "broken BIOS on legacy system" issue if so.
> 
> I guess we can do that. And I even think we have some code which finds
> out which the NBC is...
> 
> /me greps a bit:
> 
> ah, there it is: get_nbc_for_node() in arch/x86/kernel/cpu/mce/inject.c.
> 
> 
> >    b. Disable the MCA Thresholding interface for Families before 0x17.
> 
> Can't. It is user-visible and you don't know for sure whether someone is
> using it or not.
> 
> Believe me, I have been wanting to disable this thing forever. I've
> never heard of anyone using it and all the energy we put in it was for
> nothing. :-\
> 
> We could try to deprecate it, though, make it default=n in Kconfig and
> see who complains. And after a couple of releases, kill it.
> 
> >    This is an undocumented interface, 
> 
> Of course it is documented - it is in the old BKDGs.
> 
> > and I don't know if anyone is using it on older systems.
> 
> Yap.
> 
> > The issue we're discussing here started because of a splat during
> > suspend/resume/CPU hotplug. In disable_err_thresholding(), we disable
> > MCA Thresholding for bank 4 on Family 15h, so there's some precedent.
> > c. Do nothing at the moment. I *really* want to clean up the MCA
> > Thresholding interface, and the shared kobject thing may get resolved
> > in that.
> 
> Clean it up how exactly?
> 
> Put it behind a Kconfig item, disable it and remove it after a while?
> 
> :-)
> 
> If so, I wouldn't mind. No one's using this. At least I haven't heard of
> a single bug report or of a use case. Only when CPU hotplug explodes and
> that thing is involved, only then.
> 
> Might as well remove it. And then remove it in the hardware too. RAS
> folks would love to get rid of some of that crap which takes up verif
> resources for no good reason.
> 
> :-)
>

Cool beans. I think this'll be a long process, so let me start by removing the
shared bank stuff. Thanks!

-Yazen