From: Zach Brown <zach.brown@oracle.com>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: lkml <linux-kernel@vger.kernel.org>, akpm <akpm@osdl.org>
Subject: Re: [PATCH] kmap tracking
Date: Mon, 22 May 2006 09:43:24 -0700 [thread overview]
Message-ID: <4471EA2C.4010401@oracle.com> (raw)
In-Reply-To: <20060518155357.04066e9c.rdunlap@xenotime.net>
Randy.Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Track kmap/kunmap call history, storing caller function address,
> action, and time (jiffies), if CONFIG_DEBUG_KMAP is enabled.
> Based on a patch to 2.4.21 by Zach Brown that was used successfully
> at Oracle to track down some kmap/kunmap problems.
Thanks for bringing this to 2.6.. sorry for the lag in reviewing.
> +enum {
> + KMAP_FIRST = 1,
> + KMAP_ADDREF,
> + KMAP_DECREF,
> + KMAP_LAST,
> +};
I trust you got rid of these in the most recent version :)
> +#else
> +#define kmap_record_action(nr, action, refcount, retaddr) do {} while (0)
> +#endif
Make this an inline, please, so that we don't introduce unused var warnings.
> +static __init int kmap_history_init(void)
> +{
> + kmap_history_file = debugfs_create_file("kmap-history", 0644, NULL,
> + kh_running, &kmap_running_seq_fops);
> + if (!kmap_history_file)
> + goto out1;
> +
> + return 0;
> +
> +out1:
> + return -ENOMEM;
That seems noisy.. return -ENOMEM is probably fine for such a trivial
funciton :).
> +#define kmap(page) __kmap(page, __builtin_return_address(0))
> +#define kunmap(page) __kunmap(page, __builtin_return_address(0))
Hmm, I was hoping we wouldn't have to do this. Can we use
__builtin_return_address(1) from within the debug paths instead of
passing down (0)? Then we wouldn't have to ifdef around the declarations..
- z
next prev parent reply other threads:[~2006-05-22 16:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-18 22:53 [PATCH] kmap tracking Randy.Dunlap
2006-05-22 16:43 ` Zach Brown [this message]
2006-05-22 17:39 ` Andrew Morton
2006-05-22 17:58 ` Zach Brown
2006-05-22 18:11 ` Randy.Dunlap
2006-05-23 18:42 ` Randy.Dunlap
2006-05-24 1:59 ` Randy.Dunlap
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=4471EA2C.4010401@oracle.com \
--to=zach.brown@oracle.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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.