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, 26 Oct 2022 19:44:17 +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: <Y1mOEfEM6MdnV8CX@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>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y1l8nx1KnTFP1xKj@zn.tnic>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RID6/BpR2RG49twhcCv1MP5dBM7E6C1zCQMDwIPA6R3jkUhKFqjeG7vq2gds?=
 =?us-ascii?Q?k+zdFi/qTgJXCdBBic4CcC61Dt2JUUBZ/jibRmyzxXq9zNCdp4tT1MMIRdBp?=
 =?us-ascii?Q?NxzorvXZ5VOUc9Xud6g7cDtfgJfisAkIDCsHCICVcOPiNwq5JeCgGfck5aYS?=
 =?us-ascii?Q?8Ha+UEaLMy3oSdnTJqSLmSCgyPc+0wlekO9xjTgdoVp+Fi3hUnuIMmjBrZ+z?=
 =?us-ascii?Q?xoFRvpuCn/Li1Efrcbrhnm6G+m2ZtSXQlbmgqOCkEL0EVzatXRR+IWcx7/vU?=
 =?us-ascii?Q?rvf7OiAViK7MchohZzZ/IH8jC7TTF+t+U3pMlca7Xy9wUqS9Y0/RWDz9nnpE?=
 =?us-ascii?Q?dv33GmEeY+5rrK4WziWMtocdOVOEpr1cjWoP3C1q4KIggxZ/kAZ1G/aEusSu?=
 =?us-ascii?Q?vmtZSIIQ/pqYWBHUprOPfhnYssRZITJRRf/rOX9CpuRVu+sxR/C0bktbSDrf?=
 =?us-ascii?Q?hBuJ4+E6OXnRYm+RNsFcnWb/zZI+pDOrWvJK1VvwWmMl1NSyKq6PwNoBU7Da?=
 =?us-ascii?Q?raiSz1kJ+O5A1oPJID0DzBf0RbJkzCMAG3YFPUr+BosHZg765URu4/sCXHUF?=
 =?us-ascii?Q?mprqB/6KAyJgwR4jHF4o8giIxRHtfKhPRdgc72trTNCIyc20igdJyPSTLvOP?=
 =?us-ascii?Q?5uJChOdKVKZrV8rBQSYtDMeD7q4YdaizkUcaIGOuZlQX7XtoOnKEuYmsalOz?=
 =?us-ascii?Q?m9DzlS0QFaT1ON0EwyuP7Zd4KsXIWpFCqW+0DbdMl/pEtr8YK/9TcncCFWs5?=
 =?us-ascii?Q?xkPETKKFO+jz33/IhkVjkzx61xYxeHMM7/eszZDP7JJ/AZUoWw5BnNSUWiaq?=
 =?us-ascii?Q?Lsu3tH9IjL+BHerGvCVY8+F/BEBdMnuWAc+MCuWfiwv07vGy3ySPnIWB+FSV?=
 =?us-ascii?Q?KT9EIEtbXNNPyRxOhVuaiP92x7lOMORQOIbSdwqtNQof0Y588yNbZyNE/bz8?=
 =?us-ascii?Q?JRZItuIQpiqg+OHd50ybjfiNzqAMlY9CAuqkcXgPpgMvmAB+BXipeG9BCcYh?=
 =?us-ascii?Q?J8Iw7KI2ZZcA2zui5J1t1bYJifnZAXSRr4yoGzy3ZcjYEVpiiH4IHUM2T0uH?=
 =?us-ascii?Q?wyHH87wmkdlArUn40ct/+b1a0HiD2OzFAjAWFJQv8ynbDgP2z71AhxGd+pRC?=
 =?us-ascii?Q?zH8jXUClXHVWdrp7Zp7gkn+BgqKxnQh89bq63dhKlQydVCYpcuxxy9ho7Bpk?=
 =?us-ascii?Q?weMVdyyihi3qZorom1tRq+kPaWE9YF6oI53Z4Dck49DOJFg/sP9Xh1yrNZ5h?=
 =?us-ascii?Q?vYFuzyNaNBvwKJ58ofxmdyB1cisntnNO9wk5HoLTik5/SV7fON5GkiH9D57C?=
 =?us-ascii?Q?uyUny6Q9wNz/OcnJe/L5mhJDVvKkXgjYqkQhMOeULOSpkfx75TOgcXdSkAmL?=
 =?us-ascii?Q?nDVhAvE+y7yeden9KGh0awe6wsfUQ9AWdycC0e19MJaw/DKYRMKcQ86KpyL5?=
 =?us-ascii?Q?RKz2XF5OsmAn/GEO4Jg58BPHpeg8nqDXTPISPoJ/3X9ca8mTRZLq7DxIX2e5?=
 =?us-ascii?Q?oyDGegNwYnPjTghrEkcdaLScWaldxHq79uqL3rYE2Y8egVtMuPHrLa1e/pb9?=
 =?us-ascii?Q?M0HgkZy+9r6lzRfxd4Ewxriq6A1jBix8FGEO8IaE?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 33c9b02f-3ef2-433f-ca43-08dab78a7c4e
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3108.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2022 19:44:24.7285
 (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: 2EnXTbzXkM0olI9R050U5126VoffEkNXxqoQNM71hYValXhU9jeJXf03cSNt38sT5GDHiG1oWCtgQkrA4n6r3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6325
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,URIBL_BLOCKED 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 08:29:51PM +0200, Borislav Petkov wrote:
> On Wed, Oct 26, 2022 at 03:39:15PM +0000, Yazen Ghannam wrote:
> > What's the issue with my original patch?
> 
> Do you see it?
> 
> > @@ -1258,10 +1258,10 @@ static void __threshold_remove_blocks(struct threshold_bank *b)
> >         struct threshold_block *pos = NULL;
> >         struct threshold_block *tmp = NULL;
> >  
> > -       kobject_del(b->kobj);
> > +       kobject_put(b->kobj);
> >  
> >         list_for_each_entry_safe(pos, tmp, &b->blocks->miscj, miscj)
> > -               kobject_del(&pos->kobj);
> > +               kobject_put(b->kobj);
> 
> You're basically putting the parent as many times as there are elements
> on the ->miscj list.
> 
> Basically what Greg doesn't like.
> 
> Him and I need to talk it over first whether my gross hack of grafting
> the bank4 kobject hierarchy from CPU0 onto the other CPUs on the node is
> even viable so stay tuned...
> 
> > I think this is the simplest way to fix the current implementation.
> > But we should probably get rid of this kobject sharing idea in light
> > of Greg's comments.
> 
> You said it. :)
> 
> Or maybe do a better one.

Right, so can we do the following two things?

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.

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.
   b. Disable the MCA Thresholding interface for Families before 0x17. This is
   an undocumented interface, and I don't know if anyone is using it on older
   systems. 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.

What do you think?

Thanks,
Yazen