linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>, Sargun Dhillon <sargun@sargun.me>
Cc: 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>,
	Matthew Wilcox <willy@infradead.org>, NeilBrown <neilb@suse.com>,
	Jan Kara <jack@suse.cz>
Subject: [RFC PATCH v2 0/2] errseq+overlayfs: accomodate the volatile upper layer use-case
Date: Mon, 14 Dec 2020 17:14:19 -0500	[thread overview]
Message-ID: <20201214221421.1127423-1-jlayton@kernel.org> (raw)

Here's a second pass at working in the overlayfs volatile use case.
Some differences since the first RFC set:

- use the BIT() macro for the flags and counter, also add some new
  mask constants
- fix bug in errseq_sample (we don't want to set the SEEN bit there)
- fix handling in errseq_check_and_advance. We now need to reattempt
  the cmpxchg in one case, but we should only need to do it once.
- comment and documentation fixes and cleanup
- initialize upper_sb pointer before dereferencing it
- only call errseq_set when there is an error

I think this is getting closer to merge. It seems to do the right thing
on xfs (and I assume other filesystems). I've also sorted out a number
of bugs.

What I haven't actually tested is the overlayfs part. Sargun, would you
or someone else (Vivek?) be able to verify that it does the right thing?

This is in the errseq-mustinc branch in my kernel.org tree:

    https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/log/?h=errseq-mustinc

-------------[ Original cover letter follows ]--------------

What about this as an alternate approach to the problem that Sargun has
been working on? I have some minor concerns about the complexity of
managing a stateful object across two different words. That can be
done, but I think this may be simpler.

This set steals an extra flag bit from the errseq_t counter so that we
have two flags: one indicating whether to increment the counter at set
time, and another to indicate whether the error has been reported to
userland.

This should give you the semantics you want in the syncfs case, no?  If
this does look like it's a suitable approach, then I'll plan to clean up
the comments and docs.

I have a vague feeling that this might help us eventually kill the
AS_EIO and AS_ENOSPC bits too, but that would require a bit more work to
plumb in "since" samples at appropriate places.


Jeff Layton (2):
  errseq: split the SEEN flag into two new flags
  overlayfs: propagate errors from upper to overlay sb in sync_fs

 Documentation/core-api/errseq.rst |  22 +++--
 fs/overlayfs/ovl_entry.h          |   1 +
 fs/overlayfs/super.c              |  19 +++--
 include/linux/errseq.h            |   2 +
 lib/errseq.c                      | 136 ++++++++++++++++++++++--------
 5 files changed, 132 insertions(+), 48 deletions(-)

-- 
2.29.2


             reply	other threads:[~2020-12-14 22:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 22:14 Jeff Layton [this message]
2020-12-14 22:14 ` [RFC PATCH v2 1/2] errseq: split the SEEN flag into two new flags Jeff Layton
2020-12-16 23:51   ` NeilBrown
2020-12-14 22:14 ` [RFC PATCH v2 2/2] overlayfs: propagate errors from upper to overlay sb in sync_fs Jeff Layton
2020-12-15 16:30   ` Vivek Goyal
2020-12-15 16:43     ` Jeff Layton

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=20201214221421.1127423-1-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --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 \
    --cc=willy@infradead.org \
    /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).