Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1688735ybl; Thu, 30 Jan 2020 04:20:58 -0800 (PST) X-Google-Smtp-Source: APXvYqwblyVX96hRu9bWQD3Pnhvvm2AtUNXocuSS90dy4QHU2Z4WG9LbXUQQeN9lYwMbTnUIx+q1 X-Received: by 2002:a9d:7:: with SMTP id 7mr3160730ota.26.1580386858297; Thu, 30 Jan 2020 04:20:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580386858; cv=none; d=google.com; s=arc-20160816; b=rYVfALgVFCstnmZ0sw10DD4cEy/yaT7Mntm9gN0uyuRa1VWJSiQdaLGH5gEj3YEJDg kAvTGNhYe5CvypmkVPN4Lp6OHxvbpyKtXrocUPKxTxsYFp74FpUdVVS0dfRWfNZL/kSE UjBNcjCoCU0aXcT8UOCfDcn+phedGWyJNS7SD4aM8bG21n8wkuh9wHC0k9RpkdK/QyVb t4imA7Awj1AEYxas2wP5JTGrE0HCCSul6lhB1TBPpvAtar2NJOZ4UJW0sEaqNRdfwmpu edhl3aMExlwlZVxepQ5ZWWYyhd59RIh30JURxsx8AEi2XiOIgIFE/9l1fg5gU+mDqQrS xR6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=mi/4dKY7kWjGHTxsGCZltNSTK2XpV78oNuuuSAbGYo4=; b=JSKsJEIQVOJgN5VrP5fYrXJJVR8QJxU2A0rxVOG+YMqUb9gYAxUEXbicMgQMCVo9DW eIntLXt4MtT3b0Vm0mEjh0Itjew8g2xjwmtlR8Ov3a0dVk5TbsozkX0QdAxYSk4tPz9I I9SCtYMvR8GW51Usg/d6lE7xyRiFhQjyEL+jDZOawtUrLF82WQgq5VRV6j/hbA04QHV9 6U/LytB9JwHrnwjvJgcgCp2OhAnAO0PI90je9RpiZTcEqrItrogBtOQimgzdz4TwkEaL 3YjYJxGc+hR6hFa71nzdrEOMcuNamjqky5pKgXvBhyDESiDdSaoLmk9/7eo+HKEJc/nt 3qOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1si2754762oic.245.2020.01.30.04.20.45; Thu, 30 Jan 2020 04:20:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727165AbgA3MT1 (ORCPT + 99 others); Thu, 30 Jan 2020 07:19:27 -0500 Received: from jabberwock.ucw.cz ([46.255.230.98]:56500 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726873AbgA3MT1 (ORCPT ); Thu, 30 Jan 2020 07:19:27 -0500 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 1A7F41C2604; Thu, 30 Jan 2020 13:19:26 +0100 (CET) Date: Thu, 30 Jan 2020 13:19:26 +0100 From: Pavel Machek To: "Rafael J. Wysocki" Cc: Jonas Meurer , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM , Len Brown , Tim Dittler , Yannik Sembritzki Subject: Re: [PATCH v3] PM: suspend: Add sysfs attribute to control the "sync on suspend" behavior Message-ID: <20200130121926.cdz7dtrcbeuodqca@ucw.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > The sysfs attribute `/sys/power/sync_on_suspend` controls, whether or not > > filesystems are synced by the kernel before system suspend. > > > > Congruously, the behaviour of build-time switch CONFIG_SUSPEND_SKIP_SYNC > > is slightly changed: It now defines the run-tim default for the new sysfs > > attribute `/sys/power/sync_on_suspend`. > > > > The run-time attribute is added because the existing corresponding > > build-time Kconfig flag for (`CONFIG_SUSPEND_SKIP_SYNC`) is not flexible > > enough. E.g. Linux distributions that provide pre-compiled kernels > > usually want to stick with the default (sync filesystems before suspend) > > but under special conditions this needs to be changed. > > > > One example for such a special condition is user-space handling of > > suspending block devices (e.g. using `cryptsetup luksSuspend` or `dmsetup > > suspend`) before system suspend. The Kernel trying to sync filesystems > > after the underlying block device already got suspended obviously leads > > to dead-locks. Be aware that you have to take care of the filesystem sync > > yourself before suspending the system in those scenarios. > > > > Signed-off-by: Jonas Meurer > > Applied as 5.6 material with minor changes in the ABI document, thanks! For the record, I still believe this is bad idea. User should not have to tweak variables in /sys for system not to deadlock with cryptsetup.. and we are stuck with this pretty much forever. Pavel