All of lore.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 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.