From mboxrd@z Thu Jan 1 00:00:00 1970 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 1E35CC4167B for ; Wed, 9 Nov 2022 11:25:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230416AbiKILZQ (ORCPT ); Wed, 9 Nov 2022 06:25:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231208AbiKILZJ (ORCPT ); Wed, 9 Nov 2022 06:25:09 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91F9F1A813 for ; Wed, 9 Nov 2022 03:25:07 -0800 (PST) Received: from zn.tnic (p200300ea9733e7e8329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e7e8:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1E16B1EC03B9; Wed, 9 Nov 2022 12:25:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1667993106; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=rNfWtR13plF3k6hKgWHcsrXb6x06XarGBqpNpJ/g01Q=; b=Sj+2UHwd5waIkzuXuwjKoBoQd8S+uYzoTS/ztvKWQ6onXw+J+cs1JCEXRinioq3DdBavy8 w2BMz9I8F/dWbl2rDwqI1JAUsYSJADcFrhy4fJmQn0Caw6ZyL9pxoj4PcXJRTw7qT0qbU/ pXNmjJyHZI6Cc3NU8D0hJiWHRwjNAcE= Date: Wed, 9 Nov 2022 12:25:02 +0100 From: Borislav Petkov To: Ashok Raj Cc: Thomas Gleixner , LKML Mailing List , X86-kernel , Tony Luck , Dave Hansen , Arjan van de Ven , Andy Lutomirski , Jacon Jun Pan , Tom Lendacky , Kai Huang , Andrew Cooper Subject: Re: [v2 03/13] x86/microcode/intel: Fix a hang if early loading microcode fails Message-ID: References: <20221103175901.164783-1-ashok.raj@intel.com> <20221103175901.164783-4-ashok.raj@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20221103175901.164783-4-ashok.raj@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 03, 2022 at 05:58:51PM +0000, Ashok Raj wrote: > When early loading of microcode fails for any reason other than the wrong > family-model-stepping, Linux can get into an infinite loop retrying the > same failed load. > > A single retry is needed to handle any mixed stepping case. > > Assume we have a microcode that fails to load for some reason. > load_ucode_ap() seems to retry if the loading fails. But it searches for Seems to retry because we were supporting mixed revisions. Which we do not now. And if you say "seems" then this sounds like the problem hasn't been analyzed properly. If this can happen with the current code, then this needs to be fixed in stable. So, how do you trigger exactly? I'd like to reproduce it myself. As to this patch: it should simply be removing the retrying instead of doing silly crap like bool retried = false; ... In light of how a lot has changed since last time, yes, please redo the patchset ontop of tip:x86/microcode, keeping in mind now that we don't support mixed revisions anymore. Just like dhansen said, you can split it in fixes and new features so that it is not too many patches at once - your call. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette