iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

staging: exfat: explain the fs_sync() issue in TODO

Browse Source 
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>

Link: https://lore.kernel.org/r/9837.1570042895@turing-police
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Valdis Klētnieks 2019-10-02 15:01:35 -04:00 committed by Greg Kroah-Hartman
parent 8789f13ddc
commit d98bb9c2fe
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
drivers/staging/exfat/TODO
View File

@ -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