linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: linux@treblig.org
Cc: andriy.shevchenko@linux.intel.com, viro@zeniv.linux.org.uk,
	corbet@lwn.net, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] relay: Remove unused relay_late_setup_files
Date: Sun, 20 Apr 2025 14:07:58 -0700	[thread overview]
Message-ID: <20250420140758.601ae8abaa03aacb33ce7084@linux-foundation.org> (raw)
In-Reply-To: <20250418234932.490863-1-linux@treblig.org>

On Sat, 19 Apr 2025 00:49:32 +0100 linux@treblig.org wrote:

> From: "Dr. David Alan Gilbert" <linux@treblig.org>
> 
> The last use of relay_late_setup_files() was removed in 2018
> by commit 2b47733045aa ("drm/i915/guc: Merge log relay file and channel
> creation")
> 
> Remove it and the helper it used.
> 
> relay_late_setup_files() was used for eventually registering
> 'buffer only' channels.  With it gone, delete the docs that
> explain how to do that.   Which suggests it should be possible
> to lose the 'has_base_filename' flags.
> 
> (Are there any other uses??)
> 

For some reason get_maintainer points at Al and Andy for relay.c but my
mental rolodex thinks "Axboe".

Jens, does this look OK?

> ---
>  Documentation/filesystems/relay.rst |  10 ---
>  include/linux/relay.h               |   3 -
>  kernel/relay.c                      | 111 +---------------------------
>  3 files changed, 1 insertion(+), 123 deletions(-)
> 
> diff --git a/Documentation/filesystems/relay.rst b/Documentation/filesystems/relay.rst
> index 04ad083cfe62..292ba8492aeb 100644
> --- a/Documentation/filesystems/relay.rst
> +++ b/Documentation/filesystems/relay.rst
> @@ -301,16 +301,6 @@ user-defined data with a channel, and is immediately available
>  (including in create_buf_file()) via chan->private_data or
>  buf->chan->private_data.
>  
> -Buffer-only channels
> ---------------------
> -
> -These channels have no files associated and can be created with
> -relay_open(NULL, NULL, ...). Such channels are useful in scenarios such
> -as when doing early tracing in the kernel, before the VFS is up. In these
> -cases, one may open a buffer-only channel and then call
> -relay_late_setup_files() when the kernel is ready to handle files,
> -to expose the buffered data to the userspace.
> -
>  Channel 'modes'
>  ---------------
>  
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index 72b876dd5cb8..b3224111d074 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -159,9 +159,6 @@ struct rchan *relay_open(const char *base_filename,
>  			 size_t n_subbufs,
>  			 const struct rchan_callbacks *cb,
>  			 void *private_data);
> -extern int relay_late_setup_files(struct rchan *chan,
> -				  const char *base_filename,
> -				  struct dentry *parent);
>  extern void relay_close(struct rchan *chan);
>  extern void relay_flush(struct rchan *chan);
>  extern void relay_subbufs_consumed(struct rchan *chan,
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 5ac7e711e4b6..c0c93a04d4ce 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -452,7 +452,7 @@ int relay_prepare_cpu(unsigned int cpu)
>  
>  /**
>   *	relay_open - create a new relay channel
> - *	@base_filename: base name of files to create, %NULL for buffering only
> + *	@base_filename: base name of files to create
>   *	@parent: dentry of parent directory, %NULL for root directory or buffer
>   *	@subbuf_size: size of sub-buffers
>   *	@n_subbufs: number of sub-buffers
> @@ -465,10 +465,6 @@ int relay_prepare_cpu(unsigned int cpu)
>   *	attributes specified.  The created channel buffer files
>   *	will be named base_filename0...base_filenameN-1.  File
>   *	permissions will be %S_IRUSR.
> - *
> - *	If opening a buffer (@parent = NULL) that you later wish to register
> - *	in a filesystem, call relay_late_setup_files() once the @parent dentry
> - *	is available.
>   */
>  struct rchan *relay_open(const char *base_filename,
>  			 struct dentry *parent,
> @@ -540,111 +536,6 @@ struct rchan_percpu_buf_dispatcher {
>  	struct dentry *dentry;
>  };
>  
> -/* Called in atomic context. */
> -static void __relay_set_buf_dentry(void *info)
> -{
> -	struct rchan_percpu_buf_dispatcher *p = info;
> -
> -	relay_set_buf_dentry(p->buf, p->dentry);
> -}
> -
> -/**
> - *	relay_late_setup_files - triggers file creation
> - *	@chan: channel to operate on
> - *	@base_filename: base name of files to create
> - *	@parent: dentry of parent directory, %NULL for root directory
> - *
> - *	Returns 0 if successful, non-zero otherwise.
> - *
> - *	Use to setup files for a previously buffer-only channel created
> - *	by relay_open() with a NULL parent dentry.
> - *
> - *	For example, this is useful for perfomring early tracing in kernel,
> - *	before VFS is up and then exposing the early results once the dentry
> - *	is available.
> - */
> -int relay_late_setup_files(struct rchan *chan,
> -			   const char *base_filename,
> -			   struct dentry *parent)
> -{
> -	int err = 0;
> -	unsigned int i, curr_cpu;
> -	unsigned long flags;
> -	struct dentry *dentry;
> -	struct rchan_buf *buf;
> -	struct rchan_percpu_buf_dispatcher disp;
> -
> -	if (!chan || !base_filename)
> -		return -EINVAL;
> -
> -	strscpy(chan->base_filename, base_filename, NAME_MAX);
> -
> -	mutex_lock(&relay_channels_mutex);
> -	/* Is chan already set up? */
> -	if (unlikely(chan->has_base_filename)) {
> -		mutex_unlock(&relay_channels_mutex);
> -		return -EEXIST;
> -	}
> -	chan->has_base_filename = 1;
> -	chan->parent = parent;
> -
> -	if (chan->is_global) {
> -		err = -EINVAL;
> -		buf = *per_cpu_ptr(chan->buf, 0);
> -		if (!WARN_ON_ONCE(!buf)) {
> -			dentry = relay_create_buf_file(chan, buf, 0);
> -			if (dentry && !WARN_ON_ONCE(!chan->is_global)) {
> -				relay_set_buf_dentry(buf, dentry);
> -				err = 0;
> -			}
> -		}
> -		mutex_unlock(&relay_channels_mutex);
> -		return err;
> -	}
> -
> -	curr_cpu = get_cpu();
> -	/*
> -	 * The CPU hotplug notifier ran before us and created buffers with
> -	 * no files associated. So it's safe to call relay_setup_buf_file()
> -	 * on all currently online CPUs.
> -	 */
> -	for_each_online_cpu(i) {
> -		buf = *per_cpu_ptr(chan->buf, i);
> -		if (unlikely(!buf)) {
> -			WARN_ONCE(1, KERN_ERR "CPU has no buffer!\n");
> -			err = -EINVAL;
> -			break;
> -		}
> -
> -		dentry = relay_create_buf_file(chan, buf, i);
> -		if (unlikely(!dentry)) {
> -			err = -EINVAL;
> -			break;
> -		}
> -
> -		if (curr_cpu == i) {
> -			local_irq_save(flags);
> -			relay_set_buf_dentry(buf, dentry);
> -			local_irq_restore(flags);
> -		} else {
> -			disp.buf = buf;
> -			disp.dentry = dentry;
> -			smp_mb();
> -			/* relay_channels_mutex must be held, so wait. */
> -			err = smp_call_function_single(i,
> -						       __relay_set_buf_dentry,
> -						       &disp, 1);
> -		}
> -		if (unlikely(err))
> -			break;
> -	}
> -	put_cpu();
> -	mutex_unlock(&relay_channels_mutex);
> -
> -	return err;
> -}
> -EXPORT_SYMBOL_GPL(relay_late_setup_files);
> -
>  /**
>   *	relay_switch_subbuf - switch to a new sub-buffer
>   *	@buf: channel buffer
> -- 
> 2.49.0

  reply	other threads:[~2025-04-20 21:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-18 23:49 [PATCH] relay: Remove unused relay_late_setup_files linux
2025-04-20 21:07 ` Andrew Morton [this message]
2025-04-23 20:12   ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2025-05-12  1:12 Jason Xing
2025-05-12  1:30 ` Dr. David Alan Gilbert
2025-05-12  2:22   ` Jason Xing
2025-05-12 11:50     ` Dr. David Alan Gilbert
2025-05-12 12:04       ` Jason Xing
2025-05-12  6:14 ` Andy Shevchenko
2025-05-12  6:17   ` Andy Shevchenko
2025-05-12  6:55     ` Jason Xing
2025-05-12  7:25       ` Andy Shevchenko
2025-05-12  6:53   ` Jason Xing
2025-05-12  7:21     ` Andy Shevchenko
2025-05-12  7:34       ` Jason Xing
2025-05-12 13:27       ` Jens Axboe
2025-05-12 14:55   ` Christoph Hellwig
2025-05-13  0:49     ` Jason Xing
2025-05-13  1:49       ` Jens Axboe
2025-05-13  2:17         ` Jason Xing
2025-05-13 13:26           ` Jens Axboe

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=20250420140758.601ae8abaa03aacb33ce7084@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@treblig.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).