All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/1] a fix of logging return value.
Date: Fri, 10 Jul 2009 11:13:09 -0700	[thread overview]
Message-ID: <4A5784B5.40404@oracle.com> (raw)
In-Reply-To: <4A56E4ED.60101@oracle.com>

Tao Ma wrote:
> Hi wengang,
>
> Wengang Wang wrote:
>> Sunil,
>>
>> in the src, I see both mlog(ML_ERROR...)(finally printk(KERN_ERR...)) 
>> and ocfs2_error()(finally printk(KERN_CRIT...).
>> could you tell me in what case one should be used?
> mlog(ML_ERROR...) only print errors. But ocfs2_error does other 
> things, sometimes make the volume readonly. Please check 
> ocfs2_handle_error for details.
>

Yes. ocfs2_error() is only called when an ondisk structure read reveals
a corrupted block. Depending on the mount option, it either panics or
remounts ro.

printk(KERN_ERR) is only called if we need to print messages before
mlog_sys_init() is called. So you'll see those printks during module
loads.

There are few instances of printk(KERN_CRIT). We call them because mlog
does not handle such messages. We could add it. But there are only
3 instances of this message. So why bother.

The mlogs that you can use are:

mlog_errno() Error if the only information is ret/status.

mlog(ML_ERROR, ...) Error with vararg.

mlog(ML_NOTICE, ...) Notice with vararg. Use very very selectively as NOTICE
is enabled by default.

mlog(0, ...) Like notice but is printed only when the user enables the 
mask bit.
Use liberally.
 
mlog_entry() Entry with varargs. Use carefully. We don't want mlog to 
dereference
null pointers. ;)

mlog_entry_void() Entry with no args. Preferably use mlog(0) somewhere 
in the
middle of the function with usable information.

mlog_exit() All mlog_entry*() should have an exit.
mlog_exit_ptr()
mlog_exit_void()

We use mlog() to narrow down the scope of an error. Say a read is returning
EIO or EINVAL. By enabling tracing selectively, we can get more information.

However, too much tracing is counterproductive because not only is it hard
to wade thru the logs, the printk ring buffer loses a lot of messages. So,
when you add, think whether it will be useful. This is subjective of course.

An easy example would be function ocfs2_unlock_and_free_pages(). It does
what it says. Now we could add an entry and an exit trace. But the exit is
clearly useless because it does not return any information. So a better
solution could be to have a mlog(0, ...).

mlog(0, "num_pages = %d\n", num_pages);

Do not forget the trailing newline.

Thanks for taking on this task.
Sunil

  reply	other threads:[~2009-07-10 18:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-10  5:26 [Ocfs2-devel] [PATCH 1/1] a fix of logging return value Wengang Wang
2009-07-10  5:39 ` Sunil Mushran
2009-07-10  6:22   ` Wengang Wang
2009-07-10  6:40     ` Wengang Wang
2009-07-10  6:51       ` Tao Ma
2009-07-10 18:13         ` Sunil Mushran [this message]
2009-07-10 23:55 ` Joel Becker

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=4A5784B5.40404@oracle.com \
    --to=sunil.mushran@oracle.com \
    --cc=ocfs2-devel@oss.oracle.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.