Re: context[2] stuck: (null)

[Arkady <arkady.miasnikov@gmail.com>]

On Wed, Jul 12, 2017 at 3:58 PM, David Smith <dsmith@redhat.com> wrote:
> On Tue, Jul 11, 2017 at 1:46 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> Update. Some of the system calls I am doing in the begin probe are
>> blocking. I understand that it will break things on multicore systems.
>> Am I right?
>
> Yes. Systemtap probes can never block.
>
> Perhaps we can suggest some ideas if you tell us a bit more of the
> background of what you are trying to do here.

My goal is to allocate the shared memory - one or more large (100s of
MBs) vzallocs,
add a dozen files to the sysfs and debugfs.
Some of the things I am doing involve kernel APIs which block. I was thinking
about the following options

*  Add a user defined hook in the systemtap_module_init() before "probe begin"
*  Make probes begin and end a special case and allow blocking
*  A separate driver which creates things I need in the kernel and "exports" API
*  Ask a kernel tasklet/workq/whatever to do the initialization

The first was easiest to implement and allowed me to solve the problem here and
now.
The second option involves SystemTap hacking which I am trying to avoid
because of the maintenance overhead in the future
A separate driver complicates boot and introduce security risks which I would
like to avoid for my specific application unless absolutely necessary.
The last option - take the initialization offline - a tasklet could do
the work. It
was longer to develop and the hour was late.

>
> --
> David Smith
> Principal Software Engineer
> Red Hat