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