Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp20041255ybl; Sat, 4 Jan 2020 15:54:58 -0800 (PST) X-Google-Smtp-Source: APXvYqyvpkXHgAJLz7ameiUmHzB9IBhXtAwO8w1mEg5TMRVB8Vp9tg7wkFN0lwqUYrgcUYNnbZFQ X-Received: by 2002:a05:6830:1257:: with SMTP id s23mr107381400otp.241.1578182098350; Sat, 04 Jan 2020 15:54:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578182098; cv=none; d=google.com; s=arc-20160816; b=RUwJokICL4UxD+nwp0O10iJA2kCEOE2vOsxyJPfMxD6XytpEDvvYIHbhFTO26mf329 vojbi7tl1TxYtt3kr9o6RrOBGXEo8WyZOnEA78nlDR9bOyUuqIgsvT2lksHwf5jGtjtr 3HFXZZEfoxihfCVXHx6rdI7TBwpY3CcSiUKhHlMhO2Q2moi5B2msufJgdwYRK6FC5ldy u/YBK+sICZ9lEFfitwzz4bxiStLFcD2zdX2RRZtcyNHjP3GPKsLS4OnRNA9VRhbpAsqK m3KdJE3CCYQeiPrhMg8zsmpvVGfzNh/Iv6Uwch9fveVwEeTSalnTM0C7a8zMpsslhb1A 5iAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=+a6F0qmlklLZe6JVIHrDJQJXjnQZeWM6pQd3qAZUrnY=; b=nMrmY81dU7JRNmA3YaYJ617RlWEFuZUWTS+yBtXfHSJgQl4p9JYo7foXnlBl76P+OQ XfAikYCQj+15R7cn8ek4+Yvi0acQvMcaIoBE16/KFUs1Rv0K8Ob97KaC524QJzuKd13Y AXnHdM/4O73LCKZr3Yr/yWitchpTnGZ0n5lNDWcKDr/Sg6/Z+/nMoD997y/nkkgRfP0L mSwOTS5Y0FNiQb16xcbBhSSoWAr+/7ORtaxUY6I7Jo+xZhoHsyKaA6cXjIHzSCL7TpWQ mAYr94sDiYMndaQNeBBu7mKvXfOQk4xmGDZr6zz8cJKnSK1xNBBfhDVt/+ZT2psTSP6t ESdQ== 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 a3si27097059otr.37.2020.01.04.15.54.18; Sat, 04 Jan 2020 15:54: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 S1726296AbgADXwB (ORCPT + 99 others); Sat, 4 Jan 2020 18:52:01 -0500 Received: from trent.utfs.org ([94.185.90.103]:35320 "EHLO trent.utfs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726135AbgADXwB (ORCPT ); Sat, 4 Jan 2020 18:52:01 -0500 Received: from localhost (localhost [IPv6:::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id 77FF96003F; Sun, 5 Jan 2020 00:51:57 +0100 (CET) Date: Sat, 4 Jan 2020 15:51:57 -0800 (PST) From: Christian Kujau To: Linus Torvalds cc: Deepa Dinamani , Jeff Layton , LKML , Eric Biggers Subject: Re: [PATCH] Re: filesystem being remounted supports timestamps until 2038 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.99999 (DEB 375 2019-10-29) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 29 Dec 2019, Linus Torvalds wrote: > > When file systems are remounted a couple of times per day (e.g. rw/ro for backup > > purposes), dmesg gets flooded with these messages. Change pr_warn into pr_debug > > to make it stop. > > How about just doing it once per mount? Yes, once per mount would work, and maybe not print a warning on remounts at all. Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp expiry") introduced: Mounted %s file system at %s supports timestamps until [...] in mnt_warn_timestamp_expiry(), but then 0ecee6699064 ("fs/namespace.c: fix use-after-free of mount in mnt_warn_timestamp_expiry") changed this to %s filesystem being %s at %s supports timestamps until [...] in order to fix a use-after-free. > Of course, if you actually unmount and completely re-mount a > filesystem, then that would still warn multiple times, but at that > point I think it's reasonable to do. Yes, of course. Umount/remount cycles should still issue a warning, but "-o remount" should not, IMHO. Thanks, Christian. -- BOFH excuse #108: The air conditioning water supply pipe ruptured over the machine room