Skip to content
Snippets Groups Projects
Commit d98bb9c2 authored by Valdis Kletnieks's avatar Valdis Kletnieks Committed by Greg Kroah-Hartman
Browse files

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: default avatarValdis Kletnieks <valdis.kletnieks@vt.edu>

Link: https://lore.kernel.org/r/9837.1570042895@turing-police


Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent 8789f13d
No related branches found
No related tags found
No related merge requests found
......@@ -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
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment