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 CB5C9C43334 for ; Wed, 13 Jul 2022 18:33:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236558AbiGMSdq (ORCPT ); Wed, 13 Jul 2022 14:33:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232114AbiGMSdn (ORCPT ); Wed, 13 Jul 2022 14:33:43 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9F8D6168 for ; Wed, 13 Jul 2022 11:33:41 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id os14so21384644ejb.4 for ; Wed, 13 Jul 2022 11:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KifgCMjgebK/NLp6nn+G8EJhgQBv0NBPfKiflov1mlU=; b=WXkiCM2m7cWXxt53oQNuRjMlHN9tRHeiD9hdMvRX9/jmGDWKVCpWfb/ymYf0GUrQkn 2gcUvM0fppN4jvlrJBHSQ6kMpDV+0P4G+reqg6RPyFytwCdFGVuiwifzJXcN+e0T0eK3 apqVZARbdC+XmrVpwiiRoZeHilhOPB7mXQ0Jw= 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; bh=KifgCMjgebK/NLp6nn+G8EJhgQBv0NBPfKiflov1mlU=; b=acGkdHiwLHt3UrTnjQyXLx+pp7VkmiTsxMFqC3WYkypjx+TWGF1tjquBMC5aBy11g1 86nb+toxha3A0br5F9rzRPgvFlP7bzZokeg6Z0IakEL8kFrTJS4kcIkm0NjhPFbfMgjx XdnfHQo3saSuwGe/Tfbt2Xw1i5xqeb3vgmWcSZNohezwT/W9/dto6t2VELMSWHd7Nhx/ qKYR+O3ws6b7O4yLvBbtCb+Z0G8VlYLC6jnrEqtkJMJ/DGvis20sgyhj4K4oWPtu3SW/ xBzxpzSaziFp2qZhORFQgvAHwluCzXuNOXmoIQTc8/pGsgzhwmcsQRntViFId16XxjKt H/8Q== X-Gm-Message-State: AJIora9vcvKKt/F0bhdLpXVLwp/rnbF2e+k28iF0y2TrYoihUUI1BEoG W4s9o2QWti4qaUGH7YpqSkQrG954Lnr5tr0ju7M= X-Google-Smtp-Source: AGRyM1vsWwqX1dkD6rz1GFKXhL0hd/59FbSlczaWG1evRkcczUYvH2wIFoEKCCKX6UpVJi2vrwQzfg== X-Received: by 2002:a17:906:5a68:b0:72b:3e88:fec1 with SMTP id my40-20020a1709065a6800b0072b3e88fec1mr4782411ejc.741.1657737220201; Wed, 13 Jul 2022 11:33:40 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com. [209.85.221.50]) by smtp.gmail.com with ESMTPSA id u22-20020a170906c41600b0072321c99b78sm5223845ejz.57.2022.07.13.11.33.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Jul 2022 11:33:39 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id b26so16697118wrc.2 for ; Wed, 13 Jul 2022 11:33:39 -0700 (PDT) X-Received: by 2002:a5d:544b:0:b0:21d:70cb:b4a2 with SMTP id w11-20020a5d544b000000b0021d70cbb4a2mr4440805wrv.281.1657737218805; Wed, 13 Jul 2022 11:33:38 -0700 (PDT) MIME-Version: 1.0 References: <20220712183238.844813653@linuxfoundation.org> In-Reply-To: From: Linus Torvalds Date: Wed, 13 Jul 2022 11:33:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5.15 00/78] 5.15.55-rc1 review To: Guenter Roeck , Peter Zijlstra , Borislav Petkov Cc: Naresh Kamboju , Greg Kroah-Hartman , kvm list , Linux Kernel Mailing List , stable , Andrew Morton , Shuah Khan , patches@kernelci.org, lkft-triage@lists.linaro.org, Pavel Machek , Jon Hunter , Florian Fainelli , Sudip Mukherjee , Slade Watkins , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Dave Hansen , X86 ML , "H. Peter Anvin" , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Anders Roxell Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 13, 2022 at 6:34 AM Guenter Roeck wrote: > > Looking into the log, I don't think that message is related to the crash. > > ... > [ 105.653777] Modules linked in: x86_pkg_temp_thermal > [ 105.902123] ---[ end trace cec99cae36bcbfd7 ]--- > [ 105.902124] RIP: 0010:xaddw_ax_dx+0x9/0x10 <--- crash > [ 105.902126] Code: 00 0f bb d0 c3 cc cc cc cc 48 0f bb d0 c3 cc cc Yeah, the code you snipped, shows 20: 66 0f c1 d0 xadd %dx,%ax 24: c3 ret 25: cc int3 26: cc int3 27: cc int3 28: cc int3 29:* 0f 1f 80 00 00 00 00 nopl 0x0(%rax) <-- trapping instruction 30: 0f c1 d0 xadd %edx,%eax 33: c3 ret 34: cc int3 35: cc int3 36: cc int3 37: cc int3 38: 48 0f c1 d0 xadd %rdx,%rax 3c: c3 ret 3d: cc int3 and that's a bit odd. It says "xaddw_ax_dx+0x9/0x10", but I think somebody jumped to "xaddw_ax_dx+8", hit the 'int3', and the RIP points to the next instruction (because that's how int3 works). And the fastop code says: * fastop functions have a special calling convention: ... * Moreover, they are all exactly FASTOP_SIZE bytes long, but that is clearly *NOT* the case for xaddw_ax_dx, because it's 16 bytes in size, and the other ones are 8 bytes. That's where the "nopl" comes from: it's the alignment instruction to the next fastop function. Compare that to the word-sized 'xaddl' case rigth afterwards: that one *is* just 8 bytes in size, so the 64-byte 'xaddq' comes 8 bytes aftrer it, and there's no 7-byte padding nop-instruction. So I think that that is where the "xaddw_ax_dx+8" comes from: some code assumes that FASTOP_SIZE is 8, but that xaddw_ax_dx case was actually 9 bytes and thus got that "int3 + padding" in the next 8 bytes. The whole kvm x86 emulation thiing is quite complicated and has lots of instruction size #defines and magic. I'm not familiar enough with it to go "Ahh, it's obviously XYZ", but I'm sure PeterZ and Borislav know exactly what's going on. Linus