From: Bill O'Donnell <bodonnel@redhat.com>
To: Ian Kent <raven@themaw.net>
Cc: Damien Le Moal <dlemoal@kernel.org>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] zonefs: convert zonefs to use the new mount api
Date: Tue, 13 Feb 2024 17:37:19 -0600 [thread overview]
Message-ID: <Zcv9L4t9t6QfAKJ0@redhat.com> (raw)
In-Reply-To: <341e9b40-17b9-4607-8bac-693980c1ab75@themaw.net>
On Wed, Feb 14, 2024 at 07:31:09AM +0800, Ian Kent wrote:
> On 12/2/24 20:12, Ian Kent wrote:
> > On 12/2/24 09:13, Damien Le Moal wrote:
> > > On 2/11/24 12:36, Ian Kent wrote:
> > > > > > +static void zonefs_free_fc(struct fs_context *fc)
> > > > > > +{
> > > > > > + struct zonefs_context *ctx = fc->fs_private;
> > > > > I do not think you need this variable.
> > > > That's a fair comment but it says fs_private contains the fs context
> > > >
> > > > for the casual reader.
> > > >
> > > > > > +
> > > > > > + kfree(ctx);
> > > > > Is it safe to not set fc->fs_private to NULL ?
> > > > I think it's been safe to call kfree() with a NULL argument for ages.
> > > That I know, which is why I asked if *not* setting fc->fs_private to
> > > NULL after
> > > the kfree is safe. Because if another call to kfree for that pointer
> > > is done, we
> > > will endup with a double free oops. But as long as the mount API
> > > guarantees that
> > > it will not happen, then OK.
> >
> > Interesting point, TBH I hadn't thought about it.
> >
> >
> > Given that, as far as I have seen, VFS struct private fields leave the
> >
> > setting and freeing of them to the file system so I assumed that, seeing
> >
> > this done in other mount api implementations, including ones written by
> >
> > the mount api author, it was the same as other VFS cases.
> >
> >
> > But it's not too hard to check.
>
> As I thought, the context private data field is delegated to the file
> system.
>
> The usage here is as expected by the VFS.
Thanks for the reviews. I submitted a v2 patch.
Cheers-
Bill
>
>
> Ian
>
> >
> >
> > Ian
> >
> > >
> > > >
> > > > This could be done but so far the convention with mount api code
> > > >
> > > > appears to have been to add the local variable which I thought was for
> > > > descriptive purposes but it could just be the result of cut and pastes.
> > > Keeping the variable is fine. After all, that is not the fast path :)
> > >
> > >
> >
>
next prev parent reply other threads:[~2024-02-13 23:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-09 0:08 [PATCH] zonefs: convert zonefs to use the new mount api Bill O'Donnell
2024-02-09 2:10 ` Damien Le Moal
2024-02-09 16:55 ` Bill O'Donnell
2024-02-11 2:01 ` Ian Kent
2024-02-11 3:36 ` Ian Kent
2024-02-12 1:13 ` Damien Le Moal
2024-02-12 12:12 ` Ian Kent
2024-02-13 23:31 ` Ian Kent
2024-02-13 23:37 ` Bill O'Donnell [this message]
2024-02-14 0:16 ` Damien Le Moal
2024-02-14 11:15 ` Damien Le Moal
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=Zcv9L4t9t6QfAKJ0@redhat.com \
--to=bodonnel@redhat.com \
--cc=dlemoal@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=raven@themaw.net \
/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.