linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] drivers/staging/exfat - explain the fs_sync() issue in TODO
@ 2019-10-02 19:01 Valdis Klētnieks
  2019-10-03 11:34 ` Dan Carpenter
  0 siblings, 1 reply; 2+ messages in thread
From: Valdis Klētnieks @ 2019-10-02 19:01 UTC (permalink / raw)
  To: gregkh; +Cc: devel, linux-kernel

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.

Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>

---
diff --git a/drivers/staging/exfat/TODO b/drivers/staging/exfat/TODO
index a3eb282f9efc..77c302acfcb8 100644
--- a/drivers/staging/exfat/TODO
+++ b/drivers/staging/exfat/TODO
@@ -3,6 +3,15 @@ same for ffsWriteFile.
 
 exfat_core.c - fs_sync(sb,0) all over the place looks fishy as hell.
 There's only one place that calls it with a non-zero argument.
+Randomly removing fs_sync() calls is *not* the right answer, especially
+if the removal then leaves a call to fs_set_vol_flags(VOL_CLEAN), as that
+says the file system is clean and synced when we *know* it isn't.
+The proper fix here is to go through and actually analyze how DELAYED_SYNC
+should work, and any time we're setting VOL_CLEAN, ensure the file system
+has in fact been synced to disk.  In other words, changing the 'false' to
+'true' is probably more correct. Also, it's likely that the one current
+place where it actually does an bdev_sync isn't sufficient in the DELAYED_SYNC
+case.
 
 ffsTruncateFile -  if (old_size <= new_size) {
 That doesn't look right. How did it ever work? Are they relying on lazy


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] drivers/staging/exfat - explain the fs_sync() issue in TODO
  2019-10-02 19:01 [PATCH] drivers/staging/exfat - explain the fs_sync() issue in TODO Valdis Klētnieks
@ 2019-10-03 11:34 ` Dan Carpenter
  0 siblings, 0 replies; 2+ messages in thread
From: Dan Carpenter @ 2019-10-03 11:34 UTC (permalink / raw)
  To: Valdis Klētnieks; +Cc: gregkh, devel, linux-kernel, Saiyam Doshi

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);
 }

^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-10-03 11:34 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-02 19:01 [PATCH] drivers/staging/exfat - explain the fs_sync() issue in TODO Valdis Klētnieks
2019-10-03 11:34 ` Dan Carpenter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).