All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: Preparing btier for kernel inclusion
Date: Tue, 12 Feb 2013 09:47:02 +0000	[thread overview]
Message-ID: <20130212094702.GN4937@mwanda> (raw)
In-Reply-To: <5119FBC9.7030308@gmail.com>

This is staging quality code.  (Not very good).  The staging tree is
closed for the 3.9 window so it couldn't make it in until 3.10.

*) Clean up the indenting.
*) Run checkpatch.pl over this and fix the warnings.
*) Don't include .c files into other .c files.
*) Get rid of homemade print macros like TIERERR().  Use dev_err()
   or pr_err().
*) Delete all compat code with older kernels like
	#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0)
*) Change Yoda code to the if (NULL = odinfo) to normal format
	if (!odinfo)
		return -ENOMEM;
   Or "if (NULL != dev->backdev[0]->blocklist)" should be:
	if (dev->backdev[0]->blocklist)
		memcpy( ...
*) Run Sparse and Smatch over the code.  This should complain about
   some poor error handling.  For example, printing "no memory"
   followed by a dereference instead of actual error handling.  Or
   in the ioctl() it returns with the lock held.

*) Make magic numbers a define.
	/* Allow max 24 devices to be configured */ 
	devicenames = kmalloc(sizeof(char) * 26, GFP_KERNEL);

	for (count = 0; count <= 25; count++) {
		devicenames[count] = 97 + count;
	}

   Where does the 97 come from?  Also it's hella messy to use
   24, 25, and 26!  The for loop should be written in the normal
   way:

	#define MAX_BTEIR_DEVS 26

	for (i = 0; i < MAX_BTEIR_DEVS; i++) {

   Btw, use "i" instead of "count" for the iterator.  Use "count"
   for counting.

   Some of the magic numbers are just wrong:
	res = snprintf(buf, 1023, "%s\n", msg);
   1023 should have been PAGE_SIZE.  If the size argument to
   snprintf() is non-zero then snprintf() adds a NUL terminator.
   No one ever creates a 1023 char buffer.  Also the return value
   is the number of bytes that would have been printed if there
   were enough space (not counting the NUL terminator).  Consider
   using scnprintf().

*) Use normal kernel style comments.
	/* single line comment */

	/*
	 * Multi line
	 * comment.
	 */

*) Some of functions could use more comments.  What does
   allocated_on_device() return?  I would have assumed from the name
   that it returns a bool, but actually it returns a u64.

*) It scares me that when list_for_each_safe() is used
   unnecessarily.  A lot of people assume it has to do with locking
   but it doesn't.  It's for when you remove a list item.  This is
   wrong:

	list_for_each_safe(pos, q, &device_list) {
		count++;
	}

*) Put a blank line between declarations and code.

*) Use temp variables to make lines shorter:

-	dev->backdev[count]->bitlistsize -		dev->backdev[count]->devmagic->bitlistsize;

+	back = dev->backdev[count];
+	back->bitlistsize = back->devmagic->bitlistsize;

*) Never return -1 as a error code.  Return proper error codes at
   every level.

*) The TIER_DEREGISTER ioctl takes a kernel pointer from user space
   which is a bug.  It should be doing copy_from_user().

There are a lot of other messy things about this code, but that
should be enough to get started.

My advice is that people will take you a lot more seriously if you
clean it up and make a good first impression.  The block layer
people are crotchety.

Also, when you send patches for review, send it as a patch which can
be reviewed without leaving the email client.  That way we can put
comments inline.

regards,
dan carpenter


  reply	other threads:[~2013-02-12  9:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12  8:22 Preparing btier for kernel inclusion Mark Ruijter
2013-02-12  9:47 ` Dan Carpenter [this message]
2013-02-12 10:09 ` Mark Ruijter
2013-02-12 10:23 ` walter harms
2013-02-12 11:26 ` Dan Carpenter

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=20130212094702.GN4937@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.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.