On Sat, Dec 19, 2020 at 10:49:58AM -0500, Jeff Layton wrote: > On Sat, 2020-12-19 at 15:33 +0000, Matthew Wilcox wrote: > > On Sat, Dec 19, 2020 at 07:53:12AM -0500, Jeff Layton wrote: > > > On Sat, 2020-12-19 at 06:13 +0000, Matthew Wilcox wrote: > > > > On Thu, Dec 17, 2020 at 10:00:37AM -0500, Jeff Layton wrote: > > > > > Overlayfs's volatile mounts want to be able to sample an error for their > > > > > own purposes, without preventing a later opener from potentially seeing > > > > > the error. > > > > > > > > umm ... can't they just copy the errseq_t they're interested in, followed > > > > by calling errseq_check() later? > > > > > > > > > > They don't want the sampling for the volatile mount to prevent later > > > openers from seeing an error that hasn't yet been reported. > > > > That's why they should use errseq_check(), not errseq_check_and_advance() > > ... > > If you sample it without setting the OBSERVED (aka SEEN) bit, then you > can't guarantee that the next error that occurs will be recorded. The > counter won't be bumped unless that flag is set. Ah, right, that's why we set to zero when sampling. It isn't clear to me that overlayfs doesn't want that behaviour ... because the overlayfs people have been so very unclear on what they actually want. I'm beginning to think we want a test-suite for errseq_t, which would serve the twin purpose of documenting how to use it and what behaviours you can get from it, as well as making sure we don't regress anything when making changes.
