From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [103.22.144.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id DE42E1A0DBE for ; Tue, 12 Jan 2016 23:32:49 +1100 (AEDT) In-Reply-To: To: Hugh Dickins , Laurent Dufour From: Michael Ellerman Cc: Cyrill Gorcunov , linux-mm@kvack.org, "Aneesh Kumar K.V" , Martin Schwidefsky , Andrew Morton , linuxppc-dev@lists.ozlabs.org Subject: Re: [next] powerpc/mm: fix _PAGE_SWP_SOFT_DIRTY breaking swapoff Message-Id: <20160112123249.98EBF140A98@ozlabs.org> Date: Tue, 12 Jan 2016 23:32:49 +1100 (AEDT) List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sun, 2016-10-01 at 00:54:59 UTC, Hugh Dickins wrote: > Swapoff after swapping hangs on the G5, when CONFIG_CHECKPOINT_RESTORE=y > but CONFIG_MEM_SOFT_DIRTY is not set. That's because the non-zero > _PAGE_SWP_SOFT_DIRTY bit, added by CONFIG_HAVE_ARCH_SOFT_DIRTY=y, is not > discounted when CONFIG_MEM_SOFT_DIRTY is not set: so swap ptes cannot be > recognized. > > (I suspect that the peculiar dependence of HAVE_ARCH_SOFT_DIRTY on > CHECKPOINT_RESTORE in arch/powerpc/Kconfig comes from an incomplete > attempt to solve this problem.) > > It's true that the relationship between CONFIG_HAVE_ARCH_SOFT_DIRTY and > and CONFIG_MEM_SOFT_DIRTY is too confusing, and it's true that swapoff > should be made more robust; but nevertheless, fix up the powerpc ifdefs > as x86_64 and s390 (which met the same problem) have them, defining the > bits as 0 if CONFIG_MEM_SOFT_DIRTY is not set. > > Signed-off-by: Hugh Dickins > Reviewed-by: Cyrill Gorcunov > Acked-by: Laurent Dufour Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2f10f1a7884e97a68e52c4b6f7 cheers