context[2] stuck: (null)

[David Smith]

On Wed, Jul 12, 2017 at 8:16 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> 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.

Note that systemtap already has procfs 'probes', which create procfs files.

> 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.

If we wanted to include this functionality with systemtap, we'd have
to generalize this a bit and make it less domain specific. Can you
think of a script language extension that would express what you are
trying to do here?

-- 
David Smith
Principal Software Engineer
Red Hat