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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78B8FC433EF for ; Wed, 20 Oct 2021 13:49:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 18EFD6135E for ; Wed, 20 Oct 2021 13:49:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 18EFD6135E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 702876B0071; Wed, 20 Oct 2021 09:49:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B19F6B0072; Wed, 20 Oct 2021 09:49:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A12A6B0073; Wed, 20 Oct 2021 09:49:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 4D6ED6B0071 for ; Wed, 20 Oct 2021 09:49:39 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E0CCF180ABF4A for ; Wed, 20 Oct 2021 13:49:38 +0000 (UTC) X-FDA: 78716948436.09.8EB5567 Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by imf11.hostedemail.com (Postfix) with ESMTP id 7EB81F0000A1 for ; Wed, 20 Oct 2021 13:49:37 +0000 (UTC) Received: by mail-ot1-f46.google.com with SMTP id 34-20020a9d0325000000b00552cae0decbso6596483otv.0 for ; Wed, 20 Oct 2021 06:49:37 -0700 (PDT) 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=O5SM7nz52G6r6F/j6nBMR15lNFGtJZYmywBZSEd7ZW0=; b=3wBxadglQ8bvRm6RNRAObgj/bZ1HX0X98qKwWcJ9xo/Rih3yQry/O7/jjA81lTJ8wX oeDZNNenZgCAjqV+AsaYM7r3M2IBtljsNlw5IH8l0O5N3fj4Q2nKsLjoJ4aiqI2tIjaf tfH26GwFgb9eDsBFLVCOhbdiqpA80zvXu7e3qNFdbHXZBcmcYTqivao+OwBmMKwq4u0L Dp+ExXTKf3jnxn8eoNzt+8uyDgaDMZmdjIXeyDdLU2p/YSptEE7MiIYR6RDf2KKVA5uQ fBGIZdxONHmWFyb8oVJN7Ds0cu9NMV7YhX0D5JpRyLnkEWXZeEkw03pjzRUsI3YrkMP7 sA8g== X-Gm-Message-State: AOAM531LFG1FVV+qAi4741abqMRZpm1uv/H1L6ygMG0r8BuSkVBfkpYi 8PaeLmP0AwDPu3XXk41r9MKT230fg8oDC2G1lpc= X-Google-Smtp-Source: ABdhPJxx30v2bkve5AFhgtcLtf7OOUE8C9Ixo4OpNz528FBnu5rYBtYHcgG71uEXup0SQ7FWIAm0MklwhCidkBGRyeE= X-Received: by 2002:a05:6830:1af0:: with SMTP id c16mr10268otd.16.1634737776720; Wed, 20 Oct 2021 06:49:36 -0700 (PDT) MIME-Version: 1.0 References: <20211014075731.GB18719@xsang-OptiPlex-9020> <51c0a15f-1941-f161-dcec-a7a9acc726f2@gmail.com> <6755cf07-fa5a-cbb7-c076-57c162a08c99@gmail.com> <20aedfba-14e3-3677-d21a-b87610095445@gmail.com> <4300a3d4-76de-70c5-2a7b-c4d066ef5bc6@gmail.com> In-Reply-To: <4300a3d4-76de-70c5-2a7b-c4d066ef5bc6@gmail.com> From: "Rafael J. Wysocki" Date: Wed, 20 Oct 2021 15:49:25 +0200 Message-ID: Subject: Re: [PM] bfcc1e67ff: kernel-selftests.breakpoints.step_after_suspend_test.fail To: Florian Fainelli Cc: "Rafael J. Wysocki" , LKML , Linux Memory Management List , lkp@lists.01.org, kbuild test robot , kernel test robot , Linux PM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7EB81F0000A1 X-Stat-Signature: pauz8gk168jz7c91q7pmza1aau9g83xd Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf11.hostedemail.com: domain of rjwysocki@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=rjwysocki@gmail.com X-HE-Tag: 1634737777-621589 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 19, 2021 at 9:04 PM Florian Fainelli wrote: > > On 10/19/21 11:53 AM, Rafael J. Wysocki wrote: > > On 10/15/2021 9:40 PM, Florian Fainelli wrote: > >> On 10/15/21 11:45 AM, Rafael J. Wysocki wrote: > >>> On 10/14/2021 11:55 PM, Florian Fainelli wrote: > >>>> On 10/14/21 12:23 PM, Rafael J. Wysocki wrote: > >>>>> On 10/14/2021 6:26 PM, Florian Fainelli wrote: > >>>>>> On 10/14/21 12:57 AM, kernel test robot wrote: > >>>>>>> Greeting, > >>>>>>> > >>>>>>> FYI, we noticed the following commit (built with gcc-9): > >>>>>>> > >>>>>>> commit: bfcc1e67ff1e4aa8bfe2ca57f99390fc284c799d ("PM: sleep: Do not > >>>>>>> assume that "mem" is always present") > >>>>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git > >>>>>>> master > >>>>>>> > >>>>>>> > >>>>>>> in testcase: kernel-selftests > >>>>>>> version: kernel-selftests-x86_64-c8c9111a-1_20210929 > >>>>>>> with following parameters: > >>>>>>> > >>>>>>> group: group-00 > >>>>>>> ucode: 0x11 > >>>>>>> > >>>>>>> test-description: The kernel contains a set of "self tests" under > >>>>>>> the > >>>>>>> tools/testing/selftests/ directory. These are intended to be small > >>>>>>> unit tests to exercise individual code paths in the kernel. > >>>>>>> test-url: https://www.kernel.org/doc/Documentation/kselftest.txt > >>>>>>> > >>>>>>> > >>>>>>> on test machine: 288 threads 2 sockets Intel(R) Xeon Phi(TM) CPU > >>>>>>> 7295 > >>>>>>> @ 1.50GHz with 80G memory > >>>>>>> > >>>>>>> caused below changes (please refer to attached dmesg/kmsg for entire > >>>>>>> log/backtrace): > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> If you fix the issue, kindly add following tag > >>>>>>> Reported-by: kernel test robot > >>>>>> Thanks for your report. Assuming that the code responsible for > >>>>>> registering the suspend operations is drivers/acpi/sleep.c for your > >>>>>> platform, and that acpi_sleep_suspend_setup() iterated over all > >>>>>> possible > >>>>>> sleep states, your platform must somehow be returning that > >>>>>> ACPI_STATE_S3 > >>>>>> is not a supported state somehow? > >>>>>> > >>>>>> Rafael have you ever encountered something like that? > >>>>> Yes, there are systems with ACPI that don't support S3. > >>>> OK and do you know what happens when we enter suspend with "mem" in > >>>> those cases? Do we immediately return because ultimately the firmware > >>>> does not support ACPI S3? > >>> "mem" should not be present in the list of available strings then, so it > >>> should be rejected right away. > >> Well yes, that was the purpose of the patch I submitted, but assuming > >> that we did provide "mem" as one of the possible standby modes even > >> though that was wrong (before patch), and the test was trying to enter > >> ACPI S3 standby, what would have happened, would the ACPI firmware honor > >> the request but return an error, or would it actually enter ACPI S3? > >> > >> In any case, I will change the test to check that this is a supported > >> standby mode before trying it. > > > > Unfortunately, I will need to revert bfcc1e67ff1e4aa8bfe2, because it > > breaks user space compatibility and that's got caught properly by the test. > > Reverting my commit will break powerpc and other ARM/ARM64 platforms > where mem is not supported (via PSCI), It won't break anything, although the things that didn't work before will still not work after it. And "mem" is always supported even if there are no suspend_ops at all, in which case it becomes an alternative way to trigger s2idle. So, on the affected systems, what's there in /sys/power/? Is mem_sleep present? If so, what's in it? > I have a change pending for PSCI > that will actually check that SYSTEM_SUSPEND is supported before > unconditionally making use of it. > > > > > What happens is that "mem" is a "pointer" to a secondary list of > > possible states and that generally is "s2idle shallow deep" and if > > s2idle is the only available option, it will be just "s2idle". > > > > This list is there in /sys/power/mem_sleep. > > > > It was done this way, because some variants of user space expect "mem" > > to be always present and don't recognize "freeze" properly. > > > > Sorry for the confusion. > > So how do we all get our cookie here? Should we just slap an #ifndef > CONFIG_ACPI in order to allow platforms that do not have "mem" to not > have it? Certainly not. I've just hacked my test-bed system with ACPI so it does not register any suspend_ops at all and I have "freeze mem disk" in /sys/power/state and "s2idle" in /sys/power/mem_sleep. Writing "mem" to /sys/power/state causes s2idle to be carried out. Since this is the expected behavior, I'm not sure what the problem is.