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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C68BCC433DB for ; Mon, 1 Feb 2021 12:17:37 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5D95964E9C for ; Mon, 1 Feb 2021 12:17:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D95964E9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 99EBF174F; Mon, 1 Feb 2021 13:16:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 99EBF174F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1612181853; bh=sdamcwCLI2S4TZqlwIYXxV4FrJsAzbGBOdggcN3shvE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=jHZmtbO4HdLyDt967HyC3tGjK2NJkY2AUs3mDUlt93I1dAqzD+1sy57OgWTcb9IIo KMEBmk5CWraDrGFh4YPdFiZKohy1uduBpguiWlambeQnWCxwyn45dDwHKGT4r6yrl7 zItdcpuXkjEqQURv7h4zy0RqKlfU2TFYFoZ/oVQ4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 27255F80152; Mon, 1 Feb 2021 13:16:43 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 4E542F80153; Mon, 1 Feb 2021 13:16:42 +0100 (CET) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 1CE1AF80151 for ; Mon, 1 Feb 2021 13:16:39 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 1CE1AF80151 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="G8Jhipht" Received: by mail-wr1-x433.google.com with SMTP id c4so13613955wru.9 for ; Mon, 01 Feb 2021 04:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oJabRfuTZeECePsHkmJf5HW1b5PdAIVWqevNIinvl8Q=; b=G8Jhiphtk8XwIw6iD4FdZHGkvygenNRGNM+WjY5BiAo7fHz4u1XswmFe9wAEZGGFju Fx6tWZ3Z2WHcqwZiK6T1jBWsm1W9nsmM9f2tT5JjyJVHIRjAt0FQpjESy4fWYdItUiDW CdjkW8WJ0HIGuy7T5lut9ww6biQr9AMxGKeZ61nc2f4xVCwlSfa3XqH2TgUGZm+s1J3t 2tW57SVmkjqQLKm9iRmtnyK/+ZiIqJWGUUXBpgKX3L/JGanrJLR6gA5LDlYRNqMIsxuY aLlalXkufcc7YcdfawsjypWnnT9IUXePdjoj4jgNwuQraTA3ZX/WSCQcQy690cpbH6g8 V0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oJabRfuTZeECePsHkmJf5HW1b5PdAIVWqevNIinvl8Q=; b=gnqUGKh7Y8Qh8PHc7+ltkSyEkb5Gjw8pHNr1SPK2nyiDpyUGG4wE3oklISh5ZC0tzK thVfOayTL6qkqRgalT2htX1t3oiAC8OrQfiqMnKzvFbvM/nUn+/RLpq4QOV/bBeY770q kjMtFoxb0Y8h5i8Ik0nRxineOR4I9RgihnBqMsfj8wrxMcbLYtNQntfRSrBuetzfc3ob 32egW1PLXgG9i1Cv7MPbI1HQfJ2w6SbtfC5v8zXeb6NdjXmXpHXD1IMGJqLfcgynck08 oyUVeuY8GGjtuvF6ZcqIxVRmbwALQlXDjE4Z6hXssoYbI8d0jsIAvSTeG+21C2/3b9LX eSvQ== X-Gm-Message-State: AOAM533U4vjcZhSbFyra40vH4RLdZg5W3nZyJ9SfM8tAvnO9xTNCdERa d4hC/wN7gfO+yPB74ewbKyOPt7IBw75uae7dHdE= X-Google-Smtp-Source: ABdhPJxK8qJ5CahqZe/ffBUqX/rfHLlY78dtxPHbgW380PZEKwltK8wpOq4XF1gJghr9iAOrH4Qk9XYedvW6p9HHEQQ= X-Received: by 2002:a5d:4c84:: with SMTP id z4mr17338087wrs.289.1612181799212; Mon, 01 Feb 2021 04:16:39 -0800 (PST) MIME-Version: 1.0 References: <1f0f7273-597e-cdf0-87d1-908e56c13133@linux.intel.com> <1dc2639a-ecbc-c554-eaf6-930256dcda96@linux.intel.com> In-Reply-To: From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= Date: Mon, 1 Feb 2021 13:16:16 +0100 Message-ID: Subject: Re: Crash in acpi_ns_validate_handle triggered by soundwire on Linux 5.10 To: "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , Erik Kaneda , "Rafael J. Wysocki" , Pierre-Louis Bossart , ACPI Devel Maling List , Vinod Koul , Bard Liao , Len Brown X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" pon., 1 lut 2021 o 12:43 Rafael J. Wysocki napisa=C5=82= (a): > > On Fri, Jan 29, 2021 at 9:03 PM Marcin =C5=9Alusarz wrote: > > > > pt., 29 sty 2021 o 19:59 Marcin =C5=9Alusarz = napisa=C5=82(a): > > > > > > czw., 28 sty 2021 o 15:32 Marcin =C5=9Alusarz napisa=C5=82(a): > > > > > > > > czw., 28 sty 2021 o 13:39 Rafael J. Wysocki nap= isa=C5=82(a): > > > > > The only explanation for that I can think about (and which does n= ot > > > > > involve supernatural intervention so to speak) is a stack corrupt= ion > > > > > occurring between these two calls in sdw_intel_acpi_cb(). IOW, > > > > > something scribbles on the handle in the meantime, but ATM I have= no > > > > > idea what that can be. > > > > > > > > I tried KASAN but it didn't find anything and kernel actually boote= d > > > > successfully. > > > > > > I investigated this and it looks like a compiler bug (or something na= stier), > > > but I can't find where exactly registers get corrupted because if I a= dd printks > > > the corruption seems on the printk side, but if I don't add them it s= eems > > > the value gets corrupted earlier. > > (...) > > > I'm using gcc 10.2.1 from Debian testing. > > > > Someone on IRC, after hearing only that "gcc miscompiles the kernel", > > suggested disabling CONFIG_STACKPROTECTOR_STRONG. > > It helped indeed and it matches my observations, so it's quite likely i= t > > is the culprit. > > > > What do we do now? > > Figure out why the stack protection kicks in, I suppose. > > The target object is not on the stack, so if the pointer to it is > valid (we need to verify somehow that it is indeed), dereferencing it > shouldn't cause the stack protection to trigger. Well, the problem is not that stack protector finds something, but the feature itself corrupts some registers.