All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: David VomLehn <dvomlehn@cisco.com>
Cc: linux-embedded@vger.kernel.org, akpm@linux-foundation.org,
	dwm2@infradead.org, linux-kernel@vger.kernel.org,
	mpm@selenic.com, paul.gortmaker@windriver.com
Subject: Re: [PATCH, RFC] panic-note: Annotation from user space for panics
Date: Tue, 17 Nov 2009 11:03:00 +0200	[thread overview]
Message-ID: <1258448580.27437.81.camel@localhost> (raw)
In-Reply-To: <20091112021322.GA6166@dvomlehn-lnx2.corp.sa.net>

A pair of nit-picks.

On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
> @@ -0,0 +1,293 @@
> +/*
> + *				panic-note.c

No need to type file name there.

> + *
> + * Allow a blob to be registered with the kernel that will be printed if
> + * the kernel panics.
> + *
> + * Copyright (C) 2009  Cisco Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +/* Open issues:
> + * Where should the panic_note file be created? It's almost like a sysctl,
> + * but doesn't follow the same rules. When you write to a sysctl file, the
> + * previous data is replaced. When you write to the panic_note file, you
> + * can append to the end of the existing data.
> + */

Please, take a look at what is the kernel comment style at
Documentation/CodingStyle. We use

/*
 * Multi-line
 * comment
 */

style.

> +
> +#include <linux/semaphore.h>
> +#include <linux/fs.h>
> +#include <linux/proc_fs.h>
> +#include <linux/module.h>
> +#include <linux/uaccess.h>
> +
> +/* Maximum size, in bytes, allowed for the blob. Having this limit prevents
> + * an inadvertant denial of service attack that might happen if someone with
> + * root privileges was automatically generating this note and the generator
> + * had an infinite loop. Perhaps this is more of a a denial of service
> + * suicide. */
> +#define PANIC_NOTE_SIZE		(PAGE_SIZE * 4)
> +
> +/*
> + * struct panic_note_data - Information about the panic note
> + * @n:		Number of bytes in the note
> + * @p:		Pointer to the data in the note
> + * @sem:	Semaphore controlling access to data in the note
> + */
> +struct panic_note_state {
> +	size_t			n;
> +	void			*p;
> +	struct rw_semaphore	sem;
> +};
> +
> +static struct panic_note_state panic_note_state = {
> +	0, NULL, __RWSEM_INITIALIZER(panic_note_state.sem)
> +};
> +static const struct file_operations panic_note_fops;
> +static struct inode_operations panic_note_iops;
> +static struct proc_dir_entry *panic_note_entry;
> +
> +/*
> + * panic_note_print - display the panic note
> + * @priority:	Printk priority to use, e.g. KERN_EMERG
> + */
> +void panic_note_print()
> +{
> +	int i;
> +	int linelen;
int i, lineline is more compact.

> +
> +	/* We skip the semaphore stuff because we're in a panic situation and
> +	 * the scheduler isn't available in case the semaphore is already owned
> +	 * by someone else */
> +	for (i = 0; i < panic_note_state.n; i += linelen) {
> +		const char *p;
> +		int remaining;
> +		const char *nl;

const char *p, *nl is more compact. And there are several more places.
But this is matter of taste, really.

> +
> +		p = panic_note_state.p + i;
> +		remaining = panic_note_state.n - i;
> +
> +		nl = memchr(p, '\n', remaining);
> +
> +		if (nl == NULL) {
> +			linelen = remaining;
> +			pr_emerg("%.*s\n", linelen, p);
> +		} else {
> +			linelen = nl - p + 1;
> +			pr_emerg("%.*s", linelen, p);
> +		}
> +	}
> +}
> +
> +/*
> + * read_write_size - calculate the limited copy_to_user/copy_from_user count
> + * @nbytes:	The number of bytes requested
> + * @pos:	Offset, in bytes, into the file
> + * @size:	Maximum I/O offset, in bytes. For a read, this is the actual
> + *		number of bytes in the file, since you can't read past
> + *		the end. Writes can be done after the number of bytes in the
> + *		file, so this is the maximum possible file size, minus one.
> + *
> + * Returns the number of bytes to copy.
> + */
> +static ssize_t read_write_size(size_t nbytes, loff_t pos, size_t size)
> +{
> +	ssize_t retval;
> +
> +	if (pos >= size)
> +		retval = 0;
> +
Unnecessary \n
> +	else {
> +		retval = size - pos;
> +		if (retval > nbytes)
> +			retval = nbytes;
> +	}
> +
> +	return retval;
> +}


-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

      parent reply	other threads:[~2009-11-17  9:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12  2:13 [PATCH, RFC] panic-note: Annotation from user space for panics David VomLehn
2009-11-12 18:00 ` Marco Stornelli
2009-11-12 21:56   ` David VomLehn
2009-11-13  8:10     ` Simon Kagstrom
2009-11-13 11:45       ` Artem Bityutskiy
2009-11-13 11:59         ` Simon Kagstrom
2009-11-13 14:16           ` Artem Bityutskiy
2009-11-14  8:28         ` Marco Stornelli
2009-11-17  8:53           ` Artem Bityutskiy
2009-11-17 12:45             ` Marco Stornelli
2009-11-17 13:10               ` Artem Bityutskiy
2009-11-17 15:45                 ` Eric W. Biederman
2009-11-17 23:56                   ` David VomLehn
2009-11-18  0:28                     ` Eric W. Biederman
2009-11-18  0:53                       ` David VomLehn
2009-11-18  9:01                         ` Américo Wang
2009-11-18 17:01                         ` Eric W. Biederman
2009-11-18  0:56                       ` Matt Mackall
2009-11-18 16:07                         ` Eric W. Biederman
2009-11-18 17:52                           ` Tim Bird
2009-11-18 18:16                             ` Eric W. Biederman
2009-11-18 18:16                               ` Eric W. Biederman
2009-11-18  8:26                   ` Artem Bityutskiy
2009-11-17 17:53                 ` Marco Stornelli
2009-11-12 18:06 ` Matt Mackall
2009-11-12 21:58   ` David VomLehn
2009-11-13 11:35   ` Artem Bityutskiy
2009-11-12 19:50 ` Paul Gortmaker
2009-11-12 22:09   ` David VomLehn
2009-11-13 11:50     ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-11-13 11:26 ` Artem Bityutskiy
2009-11-17  9:03 ` Artem Bityutskiy [this message]

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=1258448580.27437.81.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvomlehn@cisco.com \
    --cc=dwm2@infradead.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=paul.gortmaker@windriver.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 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.