The semantics of errseq and syncfs are such that it is impossible to track if any errors have occurred between the time the first error occurred, and the user checks for the error (calls syncfs, and subsequently errseq_check_and_advance. Overlayfs has a volatile feature which short-circuits syncfs. This, in turn makes it so that the user can have silent data corruption and not know about it. The third patch in the series introduces behaviour that makes it so that we can track errors, and bubble up whether the user has put themselves in bad situation. This required some gymanstics in errseq, and adding a wrapper around it called "errseq_counter" (errseq + counter). The data structure uses an atomic to track overflow errors. This approach, rather than moving to an atomic64 / u64 is so we can avoid bloating every person that subscribes to an errseq, and only add the subscriber behaviour to those who care (at the expense of space. The datastructure is write-optimized, and rightfully so, as the users of the counter feature are just overlayfs, and it's called in fsync checking, which is a rather seldom operation, and not really on any hotpaths. [1]: https://lore.kernel.org/linux-fsdevel/20201202092720.41522-1-sargun@xxxxxxxxx/ Sargun Dhillon (3): errseq: Add errseq_counter to allow for all errors to be observed errseq: Add mechanism to snapshot errseq_counter and check snapshot overlay: Implement volatile-specific fsync error behaviour Documentation/filesystems/overlayfs.rst | 8 ++ fs/buffer.c | 2 +- fs/overlayfs/file.c | 5 +- fs/overlayfs/overlayfs.h | 1 + fs/overlayfs/ovl_entry.h | 3 + fs/overlayfs/readdir.c | 5 +- fs/overlayfs/super.c | 26 +++-- fs/overlayfs/util.c | 28 +++++ fs/super.c | 1 + fs/sync.c | 3 +- include/linux/errseq.h | 18 ++++ include/linux/fs.h | 6 +- include/linux/pagemap.h | 2 +- lib/errseq.c | 129 ++++++++++++++++++++---- 14 files changed, 202 insertions(+), 35 deletions(-) -- 2.25.1
