linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: tj@kernel.org, peterz@infradead.org, lujialin4@huawei.com,
	lizefan.x@bytedance.com, hannes@cmpxchg.org, mingo@redhat.com,
	ebiggers@kernel.org, oleg@redhat.com, akpm@linux-foundation.org,
	viro@zeniv.linux.org.uk, brauner@kernel.org,
	juri.lelli@redhat.com, vincent.guittot@linaro.org,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file
Date: Tue, 27 Jun 2023 08:25:39 +0200	[thread overview]
Message-ID: <2023062757-hardening-confusion-6f4e@gregkh> (raw)
In-Reply-To: <20230626201713.1204982-1-surenb@google.com>

On Mon, Jun 26, 2023 at 01:17:12PM -0700, Suren Baghdasaryan wrote:
> kernfs_ops.release operation can be called from kernfs_drain_open_files
> which is not tied to the file's real lifecycle. Introduce a new kernfs_ops
> free operation which is called only when the last fput() of the file is
> performed and therefore is strictly tied to the file's lifecycle. This
> operation will be used for freeing resources tied to the file, like
> waitqueues used for polling the file.

This is confusing, shouldn't release be the "last" time the file is
handled and then all resources attached to it freed?  Why do we need
another callback, shouldn't release handle this?


> 
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> ---
>  fs/kernfs/file.c       | 8 +++++---
>  include/linux/kernfs.h | 5 +++++
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
> index 40c4661f15b7..acc52d23d8f6 100644
> --- a/fs/kernfs/file.c
> +++ b/fs/kernfs/file.c
> @@ -766,7 +766,7 @@ static int kernfs_fop_open(struct inode *inode, struct file *file)
>  
>  /* used from release/drain to ensure that ->release() is called exactly once */
>  static void kernfs_release_file(struct kernfs_node *kn,
> -				struct kernfs_open_file *of)
> +				struct kernfs_open_file *of, bool final)

Adding flags to functions like this are a pain, now we need to look it
up every time to see what that bool means.

And when we do, we see that it is not documented here so we have no idea
of what it is :(

This is not going to be maintainable as-is, sorry.

>  {
>  	/*
>  	 * @of is guaranteed to have no other file operations in flight and
> @@ -787,6 +787,8 @@ static void kernfs_release_file(struct kernfs_node *kn,
>  		of->released = true;
>  		of_on(of)->nr_to_release--;
>  	}
> +	if (final && kn->attr.ops->free)
> +		kn->attr.ops->free(of);
>  }
>  
>  static int kernfs_fop_release(struct inode *inode, struct file *filp)
> @@ -798,7 +800,7 @@ static int kernfs_fop_release(struct inode *inode, struct file *filp)
>  		struct mutex *mutex;
>  
>  		mutex = kernfs_open_file_mutex_lock(kn);
> -		kernfs_release_file(kn, of);
> +		kernfs_release_file(kn, of, true);
>  		mutex_unlock(mutex);
>  	}
>  
> @@ -852,7 +854,7 @@ void kernfs_drain_open_files(struct kernfs_node *kn)
>  		}
>  
>  		if (kn->flags & KERNFS_HAS_RELEASE)
> -			kernfs_release_file(kn, of);
> +			kernfs_release_file(kn, of, false);

Why isn't this also the "last" time things are touched here?  why is it
false?


>  	}
>  
>  	WARN_ON_ONCE(on->nr_mmapped || on->nr_to_release);
> diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
> index 73f5c120def8..a7e404ff31bb 100644
> --- a/include/linux/kernfs.h
> +++ b/include/linux/kernfs.h
> @@ -273,6 +273,11 @@ struct kernfs_ops {
>  	 */
>  	int (*open)(struct kernfs_open_file *of);
>  	void (*release)(struct kernfs_open_file *of);
> +	/*
> +	 * Free resources tied to the lifecycle of the file, like a
> +	 * waitqueue used for polling.
> +	 */
> +	void (*free)(struct kernfs_open_file *of);

I agree with Tejun, this needs to be documented much better and show how
you really should never need to use this :)

thanks,

greg k-h

  parent reply	other threads:[~2023-06-27  6:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26 20:17 [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file Suren Baghdasaryan
2023-06-26 20:17 ` [PATCH 2/2] sched/psi: tie psi trigger destruction with file's lifecycle Suren Baghdasaryan
2023-06-26 20:21 ` [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file Suren Baghdasaryan
2023-06-26 20:31 ` Tejun Heo
2023-06-26 20:39   ` Suren Baghdasaryan
2023-06-27  8:24   ` Christian Brauner
2023-06-27 17:09     ` Suren Baghdasaryan
2023-06-27 17:30       ` Christian Brauner
2023-06-27 17:36         ` Suren Baghdasaryan
2023-06-27 18:42         ` Tejun Heo
2023-06-27 20:09           ` Suren Baghdasaryan
2023-06-27 21:43             ` Suren Baghdasaryan
2023-06-27 21:58               ` Suren Baghdasaryan
2023-06-28  1:54                 ` Tejun Heo
2023-06-28  3:09                   ` Suren Baghdasaryan
2023-06-28  7:26                     ` Christian Brauner
2023-06-28  7:46                       ` Suren Baghdasaryan
2023-06-28  8:41                         ` Christian Brauner
2023-06-28 16:28                           ` Suren Baghdasaryan
2023-06-28 17:35                             ` Christian Brauner
2023-06-28 18:02                               ` Tejun Heo
2023-06-28 18:18                                 ` Suren Baghdasaryan
2023-06-28 18:42                                   ` Greg KH
2023-06-28 20:12                                     ` Suren Baghdasaryan
2023-06-28 20:34                                       ` Tejun Heo
2023-06-28 21:50                                         ` Suren Baghdasaryan
2023-06-30  0:59                                           ` Suren Baghdasaryan
2023-06-30  8:21                                             ` Christian Brauner
2023-07-10 20:38                                               ` Tejun Heo
2023-06-28 17:58                       ` Tejun Heo
2023-06-27  6:25 ` Greg KH [this message]
2023-06-27 17:03   ` Suren Baghdasaryan
2023-06-27 17:23     ` Christian Brauner
2023-06-27 17:36     ` Matthew Wilcox

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=2023062757-hardening-confusion-6f4e@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=ebiggers@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=lujialin4@huawei.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vschneid@redhat.com \
    /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).