From: Dave Sperry <dave_sperry@ieee.nospam.dot.org>
To: Perry Cheng <perryche@us.ibm.com>, systemtap@sources.redhat.com
Subject: Re: Cannot access data passed in via gettimeofday
Date: Fri, 15 Dec 2006 03:45:00 -0000 [thread overview]
Message-ID: <1166148904.3034.3.camel@fc6-rt> (raw)
In-Reply-To: <OF326DF462.A6D86C8A-ON85257245.00099860-85257245.00099F31@mck.us.ray.com>
Perry,
The test worked the first time I ran it. The second time I ran it I got
wacky results. Then I noticed I had a number of runaway processes after
the second test.
You may want to try a reboot and run the test again
Dave
> Perry Cheng wrote:
> > I am having trouble getting parameters out of what seems to be a simple
> > but buggy system-tap script. The script is included below and the test
> > case (a short C program) follows. Basically, I am trying to hi-jack
> > gettimeofday and piggyback some information back by treating the struct
> it
> > passes in as a larger buffer than struct timeval. However, I need to
> > separate regular calls to gettimeofday from the special ones where the
> > special path triggers. To do this, I though I could treat the struct as
> > an incoming parameter by looking for unusual bit patterns in the struct.
> > Unfortunately, I can't seem to see the data at all despite using the
> > copy_from_user function to copy data from user to kernel space. Any idea
>
> > what's going on here? I additionally hijack stime so i can distinguish
> > in the output my special call to gettimeofday. The sample out below
> > shows that the special values 0xaaaaaaaa and 0xbbbbbbbb are not
> > transmitted. If I use settimeofday instead of gettimeofday, then this
> > program seems to work. It feels like there is some other mechanism at
> > work here that I don't know about.
>
> [eteo@kerndev tmp]$ stap -g test.stp -c ./test
> Password:
> ---------------------------
> gettimeofday 0: sec = aaaaaaaa usec = bbbbbbbb
> ---------------------------
> gettimeofday 0: sec = 23a usec = 1
> ...
>
> Eugene
> --
> 1024D/58DF8823 print 47B9 90F6 AE4A 9C51 37E0 D6E1 EA84 C6A2 58DF 8823
> main(i) { putchar(182623909 >> (i-1) * 5&31|!!(i<7)<<6) && main(++i); }
>
next parent reply other threads:[~2006-12-15 2:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OF326DF462.A6D86C8A-ON85257245.00099860-85257245.00099F31@mck.us.ray.com>
2006-12-15 3:45 ` Dave Sperry [this message]
2006-12-14 23:20 Perry Cheng
2006-12-15 3:16 ` Eugene Teo
2006-12-15 21:08 ` Frank Ch. Eigler
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=1166148904.3034.3.camel@fc6-rt \
--to=dave_sperry@ieee.nospam.dot.org \
--cc=perryche@us.ibm.com \
--cc=systemtap@sources.redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).