public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@gmail.com>
To: karim@opersys.com
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@muc.de>,
	Roman Zippel <zippel@linux-m68k.org>, Greg KH <greg@kroah.com>,
	Tom Zanussi <zanussi@us.ibm.com>,
	Robert Wisniewski <bob@watson.ibm.com>,
	Tim Bird <tim.bird@am.sony.com>,
	penberg@cs.helsinki.fi
Subject: Re: [PATCH] relayfs redux for 2.6.10: lean and mean
Date: Thu, 20 Jan 2005 21:51:39 +0200	[thread overview]
Message-ID: <84144f02050120115172375893@mail.gmail.com> (raw)
In-Reply-To: <41EF4E74.2000304@opersys.com>

On Thu, 20 Jan 2005 01:23:48 -0500, Karim Yaghmour <karim@opersys.com> wrote:
> +config RELAYFS_FS
> +	tristate "Relayfs file system support"
> +	---help---
> +	  Relayfs is a high-speed data relay filesystem designed to provide
> +	  an efficient mechanism for tools and facilities to relay large
> +	  amounts of data from kernel space to user space.  It's not useful
> +	  on its own, and should only be enabled if other facilities that
> +	  need it are enabled, such as for example the Linux Trace Toolkit.
> +
> +	  See <file:Documentation/filesystems/relayfs.txt> for further
> +	  information.

Please remove the above if you don't include the file in this patch.

>  menu "Miscellaneous filesystems"
> --- linux-2.6.10/fs/Makefile	2004-12-24 16:34:58.000000000 -0500
> +++ linux-2.6.10-relayfs-redux-1/fs/Makefile	2005-01-20 01:23:27.000000000 -0500
> @@ -1,5 +1,4 @@
> -#
> -# Makefile for the Linux filesystems.
> +## Makefile for the Linux filesystems.

Please remove the patch noise above.

> +/**
> + *	alloc_page_array - alloc array to hold pages, but not pages
> + *	@size: the total size of the memory represented by the page array
> + *	@page_count: the number of pages the array can hold
> + *	@err: 0 on success, negative otherwise
> + *
> + *	Returns a pointer to the page array if successful, NULL otherwise.
> + */
> +static struct page **
> +alloc_page_array(int size, int *page_count, int *err)
> +{
> +	int n_pages;
> +	struct page **page_array;
> +	int page_array_size;
> +
> +	*err = 0;
> +
> +	size = PAGE_ALIGN(size);
> +	n_pages = size >> PAGE_SHIFT;
> +	page_array_size = n_pages * sizeof(struct page *);
> +	page_array = kmalloc(page_array_size, GFP_KERNEL);
> +	if (page_array == NULL) {
> +		*err = -ENOMEM;
> +		return NULL;
> +	}
> +	*page_count = n_pages;
> +	memset(page_array, 0, page_array_size);
> +
> +	return page_array;
> +}

err parameter seems overkill as you can simply return NULL when failing.
Furthermore this allocator looks a lot like kcalloc(). As there's only one
caller for this function, please switch to kcalloc and inline this method
to the caller.

> +
> +/**
> + *	free_page_array - free array to hold pages, but not pages
> + *	@page_array: pointer to the page array
> + */
> +static inline void
> +free_page_array(struct page **page_array)
> +{
> +	kfree(page_array);
> +}

Please remove this useless wrapper and inline kfree() in the code.

> +/**
> + *	relaybuf_free - free a resized channel buffer
> + *	@private: pointer to the channel struct
> + *
> + *	Internal - manages the de-allocation and unmapping of old channel
> + *	buffers.
> + */
> +static void
> +relaybuf_free(void *private)
> +{
> +	struct free_rchan_buf *free_buf = (struct free_rchan_buf *)private;

Please remove the redundant cast.

> +/**
> + *     remove_rchan_file - remove the channel file
> + *     @private: pointer to the channel struct
> + *
> + *     Internal - manages the removal of old channel file
> + */
> +static void
> +remove_rchan_file(void *private)
> +{
> +	struct rchan *rchan = (struct rchan *)private;

Please remove the redundant cast.

> +/**
> + *	rchan_put - decrement channel refcount, releasing it if 0
> + *	@rchan: the channel
> + *
> + *	If the refcount reaches 0, the channel will be destroyed.
> + */
> +void
> +rchan_put(struct rchan *rchan)
> +{
> +	if (atomic_dec_and_test(&rchan->refcount))
> +		relay_release(rchan);

relay_release returns an error code. Either check for it or remove the
pointless error value propagation from the code.

> +/**
> + *	wakeup_readers - wake up VFS readers waiting on a channel
> + *	@private: the channel
> + *
> + *	This is the work function used to defer reader waking.  The
> + *	reason waking is deferred is that calling directly from commit
> + *	causes problems if you're writing from say the scheduler.
> + */
> +static void
> +wakeup_readers(void *private)
> +{
> +	struct rchan *rchan = (struct rchan *)private;
> +

Remove the redundant cast.

> +/*
> + * close() vm_op implementation for relayfs file mapping.
> + */
> +static void
> +relay_file_mmap_close(struct vm_area_struct *vma)
> +{
> +	struct file *filp = vma->vm_file;
> +	struct rchan_reader *reader;
> +	struct rchan *rchan;
> +
> +	reader = filp->private_data;
> +	rchan = reader->rchan;

Why not move these initializations to the declaration like vma->vm_file.

> +		if (err == 0)
> +			atomic_inc(&rchan->mapped);
> +	}
> +exit:
> +	return err;
> +}
> +
> +/*
> + * High-level relayfs kernel API.  See Documentation/filesystems/relafys.txt.
> + */

s/relafys/relayfs/

> +static inline int
> +rchan_create_buf(struct rchan *rchan, int size_alloc)
> +{
> +	struct page **page_array;
> +	int page_count;
> +
> +	if ((rchan->buf = (char *)alloc_rchan_buf(size_alloc, &page_array, &page_count)) == NULL) {

Please remove the redundant cast.

> +/**
> + *	rchan_create - allocate and initialize a channel, including buffer
> + *	@chanpath: path specifying the relayfs channel file to create
> + *	@bufsize: the size of the sub-buffers within the channel buffer
> + *	@nbufs: the number of sub-buffers within the channel buffer
> + *	@rchan_flags: flags specifying buffer attributes
> + *	@err: err code
> + *
> + *	Returns channel if successful, NULL otherwise, err receives errcode.
> + *
> + *	Allocates a struct rchan representing a relay channel, according
> + *	to the attributes passed in via rchan_flags.  Does some basic sanity
> + *	checking but doesn't try to do anything smart.  In particular, the
> + *	number of buffers must be a power of 2, and if the lockless scheme
> + *	is being used, the sub-buffer size must also be a power of 2.  The
> + *	locking scheme can use buffers of any size.
> + */
> +static struct rchan *
> +rchan_create(const char *chanpath,
> +	     int bufsize,
> +	     int nbufs,
> +	     u32 rchan_flags,
> +	     int *err)

err parameter seems overkill as you can achieve the same thing by returning
NULL to the caller.

> +exit:
> +	if (*err) {
> +		kfree(rchan);
> +		rchan = NULL;
> +	}
> +
> +	return rchan;
> +}
> +
> +
> +static char tmpname[NAME_MAX];

Hmm? At least move this bugger into rchan_create_dir. How are you serializing
accesses to this anyway?

> +/**
> + *	restore_callbacks - restore default channel callbacks
> + *	@rchan: the channel
> + *
> + *	Restore callbacks to the default versions.
> + */
> +static inline void
> +restore_callbacks(struct rchan *rchan)
> +{
> +	if (rchan->callbacks != &default_channel_callbacks)
> +		rchan->callbacks = &default_channel_callbacks;

The if clause achieves nothing. Please remove it and inline the code to its
callers.

                                  Pekka

  parent reply	other threads:[~2005-01-20 19:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20  6:23 [PATCH] relayfs redux for 2.6.10: lean and mean Karim Yaghmour
2005-01-20 14:50 ` Greg KH
2005-01-21  1:38   ` Karim Yaghmour
2005-01-21  2:15     ` Peter Williams
2005-01-21  6:39       ` Greg KH
2005-01-21  7:27         ` Peter Williams
2005-01-21  7:46           ` Greg KH
2005-01-21  6:43     ` Greg KH
2005-01-23  8:07       ` Karim Yaghmour
2005-01-20 15:06 ` Greg KH
2005-01-20 19:51 ` Pekka Enberg [this message]
2005-02-07  3:04 ` [PATCH] relayfs crash Kingsley Cheung
2005-02-07  3:16   ` Karim Yaghmour
2005-02-07  4:42   ` Tom Zanussi
2005-02-07  4:47     ` Kingsley Cheung

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=84144f02050120115172375893@mail.gmail.com \
    --to=penberg@gmail.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=bob@watson.ibm.com \
    --cc=greg@kroah.com \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=tim.bird@am.sony.com \
    --cc=zanussi@us.ibm.com \
    --cc=zippel@linux-m68k.org \
    /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