All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Tim Gardner <tim.gardner@canonical.com>
Cc: linux-fsdevel@vger.kernel.org, tyler.hicks@canonical.com,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] ecryptfs: Improve metatdata read failure logging
Date: Wed, 11 Jan 2012 12:36:51 -0800	[thread overview]
Message-ID: <20120111203651.GR2618@outflux.net> (raw)
In-Reply-To: <1326301242-5817-2-git-send-email-tim.gardner@canonical.com>

On Wed, Jan 11, 2012 at 06:00:41PM +0100, Tim Gardner wrote:
> There are 3 read failure cases in ecryptfs_read_metadata(), but only 2
> of them are uniquely noted by kernel log messages. This patch
> identifies and logs each read failure case. It also correctly interprets
> a negative return value from ecryptfs_read_lower().
> 
> Removes unnecessary variable initialization.
> 
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
> Cc: Tyler Hicks <tyler.hicks@canonical.com>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

I always like more verbose error reporting. :)

Reviewed-by: Kees Cook <keescook@chromium.org>

> +		printk(KERN_ERR "%s: Could not read %u bytes\n",
> +			__func__, crypt_stat->extent_size);

I wonder if eCryptfs in general might want to consider using the "pr_fmt"
and "pr_*" macros to do printk handling:

#define pr_fmt(fmt) __func__ ": " fmt

...

	pr_err("Could not read %u bytes\n", crypt_stat->extent_size);


-Kees

-- 
Kees Cook

  reply	other threads:[~2012-01-11 20:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11 17:00 [PATCH 0/2] ecryptfs: Improved metadata read failure logging Tim Gardner
2012-01-11 17:00 ` [PATCH 1/2] ecryptfs: Improve metatdata " Tim Gardner
2012-01-11 20:36   ` Kees Cook [this message]
2012-01-12 12:00   ` Tyler Hicks
2012-01-12 16:45     ` Tim Gardner
2012-01-12 16:45       ` Tim Gardner
2012-01-20 19:50       ` Tyler Hicks
2012-01-20 20:17         ` Tim Gardner
2012-01-11 17:00 ` [PATCH 2/2] ecryptfs: Print inode on metadata error Tim Gardner
2012-01-11 20:38   ` Kees Cook
2012-01-12 12:02   ` Tyler Hicks

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=20120111203651.GR2618@outflux.net \
    --to=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tim.gardner@canonical.com \
    --cc=tyler.hicks@canonical.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.