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;
Date:   Thu, 3 Oct 2019 14:34:29 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Valdis =?utf-8?Q?Kl=C4=93tnieks?= <valdis.kletnieks@vt.edu>
Cc:     gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
        linux-kernel@vger.kernel.org,
        Saiyam Doshi <saiyamdoshi.in@gmail.com>
Subject: Re: [PATCH] drivers/staging/exfat - explain the fs_sync() issue in
 TODO
Message-ID: <20191003113429.GS22609@kadam>
References: <9837.1570042895@turing-police>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9837.1570042895@turing-police>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 02, 2019 at 03:01:35PM -0400, Valdis Klētnieks wrote:
> We've seen several incorrect patches for fs_sync() calls in the exfat driver.
> Add code to the TODO that explains this isn't just a delete code and refactor,
> but that actual analysis of when the filesystem should be flushed to disk
> needs to be done.
> 

This doesn't help at all because no one can be expected to read it.
Put a comment in the code which says something like:

diff --git a/drivers/staging/exfat/exfat_super.c b/drivers/staging/exfat/exfat_super.c
index 229ecabe7a93..c1710d99875e 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -287,6 +287,13 @@ static DEFINE_SEMAPHORE(z_sem);
 
 static inline void fs_sync(struct super_block *sb, bool do_sync)
 {
+	/*
+	 * Oct 2019:  Please, do not delete this code or the callers.  This
+	 * code is obviously bogus and many of the callers are dead code, yes,
+	 * but it may hold clues as to when syncing is required.  Someone needs
+	 * to go through and audit it really carefully.
+	 *
+	 */
 	if (do_sync)
 		bdev_sync(sb);
 }