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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 3EC2AC433E1 for ; Wed, 20 May 2020 13:56:57 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 8A493206C3 for ; Wed, 20 May 2020 13:56:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8A493206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 49RvSM5vqlzDqJW for ; Wed, 20 May 2020 23:56:51 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=csgroup.eu (client-ip=93.17.236.30; helo=pegase1.c-s.fr; envelope-from=christophe.leroy@csgroup.eu; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 49RvNF12TgzDqBK for ; Wed, 20 May 2020 23:53:14 +1000 (AEST) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 49RvN5065tz9tyk4; Wed, 20 May 2020 15:53:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id r63fDDQF1JkG; Wed, 20 May 2020 15:53:08 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 49RvN462xGz9tyjh; Wed, 20 May 2020 15:53:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id D56488B7C2; Wed, 20 May 2020 15:53:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id meo8fkqoZBDj; Wed, 20 May 2020 15:53:10 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 7B5988B7B9; Wed, 20 May 2020 15:53:10 +0200 (CEST) Subject: Re: [Regression 5.7-rc1] Random hangs on 32-bit PowerPC (PowerBook6,7) To: "Aneesh Kumar K.V" , Rui Salvaterra References: <3729805f-2638-6f0e-55fa-bd7d5c173899@csgroup.eu> <877dx6g1rr.fsf@linux.ibm.com> From: Christophe Leroy Message-ID: Date: Wed, 20 May 2020 15:53:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <877dx6g1rr.fsf@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: debian-powerpc@lists.debian.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Le 20/05/2020 à 15:43, Aneesh Kumar K.V a écrit : > Christophe Leroy writes: > >> Le 18/05/2020 à 17:19, Rui Salvaterra a écrit : >>> Hi again, Christophe, >>> >>> On Mon, 18 May 2020 at 15:03, Christophe Leroy >>> wrote: >>>> >>>> Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may >>>> have broken swap. >>> >>> Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top >>> survives the beating. I'll be happy to test a definitive patch! >>> >> >> Yeah I discovered recently that the way swap is implemented on powerpc >> expects RW and other important bits not be one of the 3 least >> significant bits (see __pte_to_swp_entry() ) > > The last 3 bits are there to track the _PAGE_PRESENT right? What is the > RW dependency there? Are you suggesting of read/write migration entry? > A swap entry should not retain the pte rw bits right? > > A swap entry is built using swap type + offset. And it should not have a > dependency on pte RW bits. Along with type and offset we also should > have the ability to mark it as a pte entry and also set not present > bits. With that understanding what am I missing here? That's probably me who is missing something, I have not digged into the swap functionning yet indeed, so that was only my first feeling. By the way, the problems is definitely due to the order changes in the PTE bits, whether that's because _PAGE_RW was moved to the last 3 bits or whether that's because _PAGE_PRESENT was moved out of the last 3 bits, I don't know yet. My (bad) understanding is from the fact that __pte_to_swp_entry() is a right shift by 3 bits, so it looses the last 3 bits, and therefore __swp_entry_to_pte(__pte_to_swp_entry(pte)) looses the last 3 bits of a PTE. Is there somewhere a description of how swap works exactly ? Christophe