archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <>
To: Matthew Wilcox <>
Cc: Amir Goldstein <>,
	Sargun Dhillon <>,
	Miklos Szeredi <>,
	Vivek Goyal <>,
	overlayfs <>,
	Linux FS-devel Mailing List <>,
	NeilBrown <>, Jan Kara <>
Subject: Re: [PATCH v3] errseq: split the ERRSEQ_SEEN flag into two new flags
Date: Sat, 19 Dec 2020 07:53:12 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

If they copy the errseq_t (or just do an errseq_sample), and then follow
it with a errseq_check_and_advance then the SEEN bit will end up being
set and a later opener wouldn't see the error.

Aside from that though, I think this patch clarifies things a bit since
the SEEN flag currently means two different things:

1/ do I need to increment the counter when recording another error?

2/ do I need to report this error to new samplers (at open time)

That was ok before, since we those conditions were always changed
together, but with the overlayfs volatile mount use-case, it no longer

> actually, isn't errseq_check() buggy in the face of multiple
> watchers?  consider this:
> starts at 0
> = errseq_sample(&
> errseq_set(&, -EIO)
> = errseq_sample(&
> t2.err = errseq_check_and_advance(&es,
> 	** this sets ERRSEQ_SEEN **
> t1.err = errseq_check(&,
> 	** reports an error, even though the only change is that
> 	   ERRSEQ_SEEN moved **.
> i think errseq_check() should be:
> 	if (likely(cur | ERRSEQ_SEEN) == (since | ERRSEQ_SEEN))
> 		return 0;
> i'm not yet convinced other changes are needed to errseq.  but i am
> having great trouble understanding exactly what overlayfs is trying to do.

I think you're right on errseq_check. I'll plan to do a patch to fix
that up as well.

I too am having a bit of trouble understanding all of the nuances here.
My current understanding is that it depends on the "volatility" of the

normal (non-volatile): they basically want to be able to track errors as
if the files were being opened on the upper layer. For this case I think
they should aim to just do all of the error checking against the upper
sb and ignore the overlayfs s_wb_err field. This does mean pushing the
errseq_check_and_advance down into the individual filesystems in some
fashion though.

volatile: they want to sample at mount time and always return an error
to syncfs if there has been another error since the original sample
point. This sampling should also not affect later openers on the upper
layer (or on other overlayfs mounts).

I'm not 100% clear on whether I understand both use-cases correctly
Jeff Layton <>

  reply	other threads:[~2020-12-19 12: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 [this message]
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
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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).