From: Josef Bacik <josef@redhat.com>
To: rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org
Subject: trace_printk is doing weird things with my arguments
Date: Mon, 12 Dec 2011 13:59:48 -0500 [thread overview]
Message-ID: <20111212185947.GA3603@localhost.localdomain> (raw)
Hello,
I've been using trace_printk() to hash out where I want to put trace points so I
can do leak detection in the btrfs space accounting code. This has worked out
wonderfully, except in the case where I have trace_printk()'s towards the end of
umount() which is where everything gets freed up. After a lot of screwing
around I ended up with this in one of the functions
trace_printk("%pU is being released, fsinfo=%p\n", fs_info->fsid, fs_info);
printk(KERN_ERR "%pU is releaseing global_rsv\n", fs_info->fsid);
and then in my trace output I got this (I've cut the unnecessary line beginning)
0080880d-0488-ffff-0a0a-0a0a0a0a0a0a is being released, fsinfo=ffff88040d88b000
and in dmesg I got this
4e78b2a8-707a-4eef-97d5-11c0aa1b8f29 is releaseing global_rsv
The dmesg has the right fsid, and I have a ton of trace_printk()'s in
close_ctree() which is the function that we call from ->put_super, and all of
them will either randomly have the right fsid, they will all have the wrong
fsid, or some mixture, like half will have the right one but the last half will
not. The '0a' repeating thing is because i put a memset(fs_info, 0xa,
sizeof(*fsinfo)) in our freeing function because I thought we were screwing up,
but it looks like trace_printk is somehow not trying to fill in the arguments
until after the arguments have been freed, which seems wrong and is screwing me
up ;). Any thoughts? Thanks,
Josef
next reply other threads:[~2011-12-12 18:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 18:59 Josef Bacik [this message]
2011-12-12 19:57 ` trace_printk is doing weird things with my arguments Steven Rostedt
2011-12-12 20:32 ` Josef Bacik
2011-12-12 20:44 ` Steven Rostedt
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=20111212185947.GA3603@localhost.localdomain \
--to=josef@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox