* Is it ok to insert a module multiple times with staprun?
@ 2017-03-30 4:41 Shiyao Ma
2017-03-30 5:40 ` Arkady
0 siblings, 1 reply; 10+ messages in thread
From: Shiyao Ma @ 2017-03-30 4:41 UTC (permalink / raw)
To: systemtap
Hi,
In the staprun manpage, I saw this:
-R Rename the module to a unique name before inserting it.
So looks like it's safe to insert it multiple times as long as the -R
gives a different name.
My application scenario is to log information on different tcp
connections, and separately output them to different files.
The invocation is like this:
# first insertion
sudo staprun /path/to/module -o /path/to/tcp-2003 filterport=2003 -R tcp-2003
# second insertion
sudo staprun /path/to/module -o /path/to/tcp-2004 filterport=2004 -R tcp-2004
Does the above approach look natural?
Regards.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-30 4:41 Is it ok to insert a module multiple times with staprun? Shiyao Ma
@ 2017-03-30 5:40 ` Arkady
[not found] ` <e7f616ba-eb90-47ee-b784-ea02fdf519ff@Spark>
0 siblings, 1 reply; 10+ messages in thread
From: Arkady @ 2017-03-30 5:40 UTC (permalink / raw)
To: Shiyao Ma; +Cc: systemtap
Linux kernel krpobes farmework supports multiple probes for the same function.
On Thu, Mar 30, 2017 at 7:41 AM, Shiyao Ma <i@introo.me> wrote:
> Hi,
> In the staprun manpage, I saw this:
>
>
> -R Rename the module to a unique name before inserting it.
>
> So looks like it's safe to insert it multiple times as long as the -R
> gives a different name.
>
>
> My application scenario is to log information on different tcp
> connections, and separately output them to different files.
> The invocation is like this:
> # first insertion
> sudo staprun /path/to/module -o /path/to/tcp-2003 filterport=2003 -R tcp-2003
> # second insertion
> sudo staprun /path/to/module -o /path/to/tcp-2004 filterport=2004 -R tcp-2004
>
> Does the above approach look natural?
>
> Regards.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
[not found] ` <e7f616ba-eb90-47ee-b784-ea02fdf519ff@Spark>
@ 2017-03-30 8:22 ` Arkady
2017-03-30 14:53 ` David Smith
0 siblings, 1 reply; 10+ messages in thread
From: Arkady @ 2017-03-30 8:22 UTC (permalink / raw)
To: Shiyao Ma; +Cc: systemtap
You can try to use /proc support in the STAP - there is a "probe"
which adds a file to the procfs
For example, procfs("PATH").write { printf("User wrote: %s", $value) }
Alternatively you can use debugfs like I do in
https://github.com/larytet/YALAS/blob/master/src/driver/sysfs.c
On Thu, Mar 30, 2017 at 11:11 AM, Shiyao Ma <i@introo.me> wrote:
> Hi,
>
> Indeed I should insert the kernel module only once. And do some
> if-conditions based on the supplied parameters.
>
> The limitation on my side is, the params are rather long, exceeding the
> shell limitation.
>
> I'd like the module to read a file (that contains the arguments).
>
> Does systemstap script has such a support?
>
>
> Regards.
>
> On Mar 30, 2017, 13:40 +0800, Arkady <arkady.miasnikov@gmail.com>, wrote:
>
> Linux kernel krpobes farmework supports multiple probes for the same
> function.
>
> On Thu, Mar 30, 2017 at 7:41 AM, Shiyao Ma <i@introo.me> wrote:
>
> Hi,
> In the staprun manpage, I saw this:
>
>
> -R Rename the module to a unique name before inserting it.
>
> So looks like it's safe to insert it multiple times as long as the -R
> gives a different name.
>
>
> My application scenario is to log information on different tcp
> connections, and separately output them to different files.
> The invocation is like this:
> # first insertion
> sudo staprun /path/to/module -o /path/to/tcp-2003 filterport=2003 -R
> tcp-2003
> # second insertion
> sudo staprun /path/to/module -o /path/to/tcp-2004 filterport=2004 -R
> tcp-2004
>
> Does the above approach look natural?
>
> Regards.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-30 8:22 ` Arkady
@ 2017-03-30 14:53 ` David Smith
2017-03-31 3:51 ` Shiyao Ma
0 siblings, 1 reply; 10+ messages in thread
From: David Smith @ 2017-03-30 14:53 UTC (permalink / raw)
To: Arkady; +Cc: Shiyao Ma, systemtap
On Thu, Mar 30, 2017 at 3:22 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> You can try to use /proc support in the STAP - there is a "probe"
> which adds a file to the procfs
>
> For example, procfs("PATH").write { printf("User wrote: %s", $value) }
Procfs files can be used for several interesting situations. See the
json tapset for an example.
> Alternatively you can use debugfs like I do in
> https://github.com/larytet/YALAS/blob/master/src/driver/sysfs.c
>
> On Thu, Mar 30, 2017 at 11:11 AM, Shiyao Ma <i@introo.me> wrote:
>> Hi,
>>
>> Indeed I should insert the kernel module only once. And do some
>> if-conditions based on the supplied parameters.
>>
>> The limitation on my side is, the params are rather long, exceeding the
>> shell limitation.
>>
>> I'd like the module to read a file (that contains the arguments).
>>
>> Does systemstap script has such a support?
Systemtap, when run in its default 'linux' mode which installs kernel
modules, cannot read files. There are lots of reasons for this, but in
general the kernel cannot open/read/write files for itself. (Obviously
user programs request the kernel to open/read/write files.)
You've got a couple of options off the top of my head to handle your parameters.
1) Command line arguments - i.e. module parameters. Systemtap modules
can take parameters that do several things, like:
- specify probe points:
# stap -e 'probe kernel.function(@1) { printf("%s\n", ppfunc());
exit() }' vfs_read
vfs_read
- specify values to test:
# stap -e 'probe begin { if ($1 == 1) { printf("1 processing here\n")
} else { printf("non-1 processing here\n") }; exit() }' 1
1 processing here
These are really module parameters - that value isn't compiled into
the module. The value gets assigned at module insertion time.
2) Procfs probes. procfs probes create /proc files. These files can be
used for data output or input. Akady showed example of data input
above. That '$value' variable contains whatever the user wrote into
the /proc file.
Really to help you further you are going to have to describe what you
are trying to do a bit further.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-30 14:53 ` David Smith
@ 2017-03-31 3:51 ` Shiyao Ma
2017-03-31 4:08 ` Arkady
2017-03-31 14:50 ` David Smith
0 siblings, 2 replies; 10+ messages in thread
From: Shiyao Ma @ 2017-03-31 3:51 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
Hi,
> Really to help you further you are going to have to describe what you
> are trying to do a bit further.
My aim is to pass in some information (arguments) to the module at run
time (so in pass-5 time, not pass-[1-4]).
That rules out the first option. stap -e "foobar".
Also, using the command line of staprun does not work here, due to the
length limitation on shell command line.
The second procfs option, on the other hand, sounds feasible.
However, I have a minor concern here. I'd like the info passed to the
module (via procfs) be read at the very beginning, *before any
kernel.function" probe has been registered to the system.
In other words, any kernel.function probe should only be activated
after the procfs.read is done.
The closest thing I can come up in my mind is to do something like:
probe begin {
read_the_procfs_file_and_wait()
}
That is, put the reading file stuff into the begin probe.
Possible to achieve that?
Regards.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-31 3:51 ` Shiyao Ma
@ 2017-03-31 4:08 ` Arkady
2017-03-31 14:50 ` David Smith
1 sibling, 0 replies; 10+ messages in thread
From: Arkady @ 2017-03-31 4:08 UTC (permalink / raw)
To: Shiyao Ma; +Cc: David Smith, systemtap
The easiest is to have a global variable and check it in all probes.
You can set the flag from proc.read
On Fri, Mar 31, 2017 at 6:51 AM, Shiyao Ma <i@introo.me> wrote:
> Hi,
>
>> Really to help you further you are going to have to describe what you
>> are trying to do a bit further.
>
>
> My aim is to pass in some information (arguments) to the module at run
> time (so in pass-5 time, not pass-[1-4]).
> That rules out the first option. stap -e "foobar".
>
> Also, using the command line of staprun does not work here, due to the
> length limitation on shell command line.
>
> The second procfs option, on the other hand, sounds feasible.
> However, I have a minor concern here. I'd like the info passed to the
> module (via procfs) be read at the very beginning, *before any
> kernel.function" probe has been registered to the system.
> In other words, any kernel.function probe should only be activated
> after the procfs.read is done.
>
> The closest thing I can come up in my mind is to do something like:
> probe begin {
> read_the_procfs_file_and_wait()
> }
>
> That is, put the reading file stuff into the begin probe.
>
> Possible to achieve that?
>
>
> Regards.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-31 3:51 ` Shiyao Ma
2017-03-31 4:08 ` Arkady
@ 2017-03-31 14:50 ` David Smith
2017-03-31 15:40 ` David Smith
1 sibling, 1 reply; 10+ messages in thread
From: David Smith @ 2017-03-31 14:50 UTC (permalink / raw)
To: Shiyao Ma; +Cc: systemtap
On Thu, Mar 30, 2017 at 10:51 PM, Shiyao Ma <i@introo.me> wrote:
> Hi,
>
>> Really to help you further you are going to have to describe what you
>> are trying to do a bit further.
>
>
> My aim is to pass in some information (arguments) to the module at run
> time (so in pass-5 time, not pass-[1-4]).
> That rules out the first option. stap -e "foobar".
>\
> Also, using the command line of staprun does not work here, due to the
> length limitation on shell command line.
To be clear (and perhaps you understand this already), the following
*does* substitute "vfs_read" in at pass 5 time:
# stap -e 'probe kernel.function(@1) { printf("%s\n", ppfunc());
exit() }' vfs_read
> The second procfs option, on the other hand, sounds feasible.
> However, I have a minor concern here. I'd like the info passed to the
> module (via procfs) be read at the very beginning, *before any
> kernel.function" probe has been registered to the system.
> In other words, any kernel.function probe should only be activated
> after the procfs.read is done.
>
> The closest thing I can come up in my mind is to do something like:
> probe begin {
> read_the_procfs_file_and_wait()
> }
>
> That is, put the reading file stuff into the begin probe.
>
> Possible to achieve that?
As you have written above, no.
As Arkady said, you'd have a global variable that would be set after
the procfs information is set, something like the following:
====
global config_done
probe procfs.write("config")
{
# process $value here
config_done = 1
}
probe kernel.function("vfs_read")
{
if (!config_done) next
# real processing here...
}
====
You'd run it like the following:
# stap -m foo foo.stp &
# cat config > /proc/systemtap/foo/config
Actually, it is even easier if your kernel is > 2.6.30, you can use
on-the-fly probes. In this case, the kprobe is disabled until
config_done is set.
====
global config_done
probe procfs.write("config")
{
# process $value here
config_done = 1
}
probe kernel.function("vfs_read") if (config_done)
{
# real processing here...
}
====
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-31 14:50 ` David Smith
@ 2017-03-31 15:40 ` David Smith
2017-03-31 15:46 ` Shiyao Ma
2017-04-01 6:15 ` Shiyao Ma
0 siblings, 2 replies; 10+ messages in thread
From: David Smith @ 2017-03-31 15:40 UTC (permalink / raw)
To: Shiyao Ma; +Cc: systemtap
On Fri, Mar 31, 2017 at 9:50 AM, David Smith <dsmith@redhat.com> wrote:
> On Thu, Mar 30, 2017 at 10:51 PM, Shiyao Ma <i@introo.me> wrote:
OK, I had another sneaky thought here. You could use the system()
function to copy the config file to the /proc file. I haven't had time
to test this, but in theory something like this should work:
====
global config_done
probe procfs.write("config")
{
# process $value here
config_done = 1
}
probe kernel.function("vfs_read") if (config_done)
{
# real processing here...
}
probe begin
{
system(sprintf("cat config > /proc/systemtap/%s/config", module_name()))
}
====
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-31 15:40 ` David Smith
@ 2017-03-31 15:46 ` Shiyao Ma
2017-04-01 6:15 ` Shiyao Ma
1 sibling, 0 replies; 10+ messages in thread
From: Shiyao Ma @ 2017-03-31 15:46 UTC (permalink / raw)
To: David Smith, Arkady; +Cc: systemtap
Hi,
Just checked the system() command is async, though.
but I got the picture here.
Thanks.
On Fri, Mar 31, 2017 at 11:40 PM, David Smith <dsmith@redhat.com> wrote:
> On Fri, Mar 31, 2017 at 9:50 AM, David Smith <dsmith@redhat.com> wrote:
>> On Thu, Mar 30, 2017 at 10:51 PM, Shiyao Ma <i@introo.me> wrote:
>
> OK, I had another sneaky thought here. You could use the system()
> function to copy the config file to the /proc file. I haven't had time
> to test this, but in theory something like this should work:
>
> ====
> global config_done
>
> probe procfs.write("config")
> {
> # process $value here
> config_done = 1
> }
>
> probe kernel.function("vfs_read") if (config_done)
> {
> # real processing here...
> }
>
> probe begin
> {
> system(sprintf("cat config > /proc/systemtap/%s/config", module_name()))
> }
> ====
>
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Is it ok to insert a module multiple times with staprun?
2017-03-31 15:40 ` David Smith
2017-03-31 15:46 ` Shiyao Ma
@ 2017-04-01 6:15 ` Shiyao Ma
1 sibling, 0 replies; 10+ messages in thread
From: Shiyao Ma @ 2017-04-01 6:15 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
If the expr in `if expr' could support function invocation, that would
be awesome.
Currently, only
probe kernel.function("vfs_read") if (some_variable) is supported.
probe kernel.function("vfs_read") if (some_func()) is not supported.
Best.
On Fri, Mar 31, 2017 at 11:40 PM, David Smith <dsmith@redhat.com> wrote:
> On Fri, Mar 31, 2017 at 9:50 AM, David Smith <dsmith@redhat.com> wrote:
>> On Thu, Mar 30, 2017 at 10:51 PM, Shiyao Ma <i@introo.me> wrote:
>
> OK, I had another sneaky thought here. You could use the system()
> function to copy the config file to the /proc file. I haven't had time
> to test this, but in theory something like this should work:
>
> ====
> global config_done
>
> probe procfs.write("config")
> {
> # process $value here
> config_done = 1
> }
>
> probe kernel.function("vfs_read") if (config_done)
> {
> # real processing here...
> }
>
> probe begin
> {
> system(sprintf("cat config > /proc/systemtap/%s/config", module_name()))
> }
> ====
>
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-04-01 6:15 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-30 4:41 Is it ok to insert a module multiple times with staprun? Shiyao Ma
2017-03-30 5:40 ` Arkady
[not found] ` <e7f616ba-eb90-47ee-b784-ea02fdf519ff@Spark>
2017-03-30 8:22 ` Arkady
2017-03-30 14:53 ` David Smith
2017-03-31 3:51 ` Shiyao Ma
2017-03-31 4:08 ` Arkady
2017-03-31 14:50 ` David Smith
2017-03-31 15:40 ` David Smith
2017-03-31 15:46 ` Shiyao Ma
2017-04-01 6:15 ` Shiyao Ma
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).