From: Valdis Klētnieks Date: Wed, 2 Oct 2019 19:01:35 +0000 (-0400) Subject: staging: exfat: explain the fs_sync() issue in TODO X-Git-Tag: v5.15~5053^2~365 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=d98bb9c2fec01254d2e04e1eed51dde9ae611314;p=platform%2Fkernel%2Flinux-starfive.git staging: exfat: explain the fs_sync() issue in TODO 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 Link: https://lore.kernel.org/r/9837.1570042895@turing-police Signed-off-by: Greg Kroah-Hartman --- diff --git a/drivers/staging/exfat/TODO b/drivers/staging/exfat/TODO index a3eb282..b60e50b 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