From: Matthew Wilcox <willy@infradead.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
Sargun Dhillon <sargun@sargun.me>,
Miklos Szeredi <miklos@szeredi.hu>,
Vivek Goyal <vgoyal@redhat.com>,
overlayfs <linux-unionfs@vger.kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
NeilBrown <neilb@suse.com>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v3] errseq: split the ERRSEQ_SEEN flag into two new flags
Date: Sat, 19 Dec 2020 16:53:35 +0000 [thread overview]
Message-ID: <20201219165335.GT15600@casper.infradead.org> (raw)
In-Reply-To: <9a1263329effe436a970d5aa61a4cfad3098a076.camel@kernel.org>
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.
next prev parent reply other threads:[~2020-12-19 16:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 15:00 [PATCH v3] errseq: split the ERRSEQ_SEEN flag into two new flags Jeff Layton
2020-12-17 20:35 ` Sargun Dhillon
2020-12-17 21:18 ` Jeff Layton
2020-12-18 23:44 ` Sargun Dhillon
2020-12-19 1:03 ` Jeff Layton
2020-12-19 9:09 ` Amir Goldstein
2020-12-19 6:13 ` Matthew Wilcox
2020-12-19 12:53 ` Jeff Layton
2020-12-19 13:25 ` Jeff Layton
2020-12-19 15:33 ` Matthew Wilcox
2020-12-19 15:49 ` Jeff Layton
2020-12-19 16:53 ` Matthew Wilcox [this message]
2020-12-21 15:14 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201219165335.GT15600@casper.infradead.org \
--to=willy@infradead.org \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.com \
--cc=sargun@sargun.me \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).