From: Al Viro <viro@zeniv.linux.org.uk>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Miklos Szeredi <miklos@szeredi.hu>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: introduce struct fderr, convert overlayfs uses to that
Date: Thu, 17 Oct 2024 20:47:25 +0100 [thread overview]
Message-ID: <20241017194725.GM4017910@ZenIV> (raw)
In-Reply-To: <CAOQ4uxjS0CX+nA4xqmrrMYDPXRPWMT00+S8z8OMhMWc9omSvMw@mail.gmail.com>
On Fri, Oct 04, 2024 at 12:47:09PM +0200, Amir Goldstein wrote:
> I had already posted an alternative code for overlayfs, but in case this
> is going to be used anyway in overlayfs or in another code, see some
> comments below...
As far as I can see, the current #overlayfs-next kills the case for
struct fderr; we might eventually get a valid use for it, but for the
time being I'm going to strip the overlayfs-related parts of that branch
(obviously), fix the braino you've spotted in fdput() and archive the
branch in case it's ever needed.
> > +#define fd_empty(f) _Generic((f), \
> > + struct fd: unlikely(!(f).word), \
> > + struct fderr: IS_ERR_VALUE((f).word))
>
>
> I suggest adding a fd_is_err(f) helper to rhyme with IS_ERR().
Umm... Dropping fd_empty() for that one, you mean?
> > +#define fdput(f) (void) (_Generic((f), \
> > + struct fderr: IS_ERR_VALUE((f).word), \
>
> Should that be !IS_ERR_VALUE((f).word)?
It should, thanks for spotting that braino.
> or better yet
>
> #define fd_is_err(f) _Generic((f), \
> struct fd: false, \
> struct fderr: IS_ERR_VALUE((f).word))
I think that's a bad idea; too likely to spill into struct fd users,
with "it's never false here" being a nasty surprise.
next prev parent reply other threads:[~2024-10-17 19:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-03 23:45 [RFC][PATCHES] struct fderr Al Viro
2024-10-03 23:47 ` Al Viro
2024-10-03 23:47 ` introduce struct fderr, convert overlayfs uses to that Al Viro
2024-10-04 9:43 ` Christian Brauner
2024-10-04 10:47 ` Amir Goldstein
2024-10-17 19:47 ` Al Viro [this message]
2024-10-03 23:48 ` [PATCH 2/3] experimental: convert fs/overlayfs/file.c to CLASS(...) Al Viro
2024-10-04 9:40 ` Christian Brauner
2024-10-03 23:48 ` [PATCH 3/3] [experimental] another way to deal with scopes for overlayfs real_fd-under-inode_lock Al Viro
2024-10-04 10:32 ` [RFC][PATCHES] struct fderr Amir Goldstein
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=20241017194725.GM4017910@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.