From: Damien Le Moal <dlemoal@kernel.org>
To: Bill O'Donnell <bodonnel@redhat.com>, Ian Kent <raven@themaw.net>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] zonefs: convert zonefs to use the new mount api
Date: Wed, 14 Feb 2024 09:16:01 +0900 [thread overview]
Message-ID: <64ef9fd8-6fec-4fa5-987c-3ad401db02af@kernel.org> (raw)
In-Reply-To: <Zcv9L4t9t6QfAKJ0@redhat.com>
On 2/14/24 08:37, Bill O'Donnell wrote:
> 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
I will run tests today. Thanks.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2024-02-14 0:16 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
2024-02-14 0:16 ` Damien Le Moal [this message]
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=64ef9fd8-6fec-4fa5-987c-3ad401db02af@kernel.org \
--to=dlemoal@kernel.org \
--cc=bodonnel@redhat.com \
--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.