From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5028 invoked by alias); 23 Jul 2018 20:01:44 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 4999 invoked by uid 89); 23 Jul 2018 20:01:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=hang, H*r:sk:systemt, H*r:209.85.218, lberkredhatcom X-HELO: mail-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Jul 2018 20:01:42 +0000 Received: by mail-oi0-f51.google.com with SMTP id n84-v6so3370726oib.9 for ; Mon, 23 Jul 2018 13:01:41 -0700 (PDT) MIME-Version: 1.0 References: <87y3e26ngs.fsf@redhat.com> In-Reply-To: <87y3e26ngs.fsf@redhat.com> From: David Smith Date: Mon, 23 Jul 2018 20:01:00 -0000 Message-ID: Subject: Re: freezes stap To: lberk@redhat.com Cc: systemtap , Anton Kiryushkin Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00036.txt.bz2 That's a reasonable thought, but assume the following script: stap -ve 'probe kernel.function("vfs_read") { printf("VFS_READ\n") } probe process("/usr/bin/foo").begin { printf("FOO\n") } probe module("bar").function("baz") { printf("BAZ\n") }'' In the case of kernel.function probes, a registration error is final. We won't ever find that kernel function if we don't find it on a stap module load. (Of course the weird thing here is that module wouldn't have gotten compiled unless we found vfs_read() in the kernel debuginfo, but yet for some reason we couldn't actually attach the probe.) In the case of a user process, if /usr/bin/foo isn't running right now, that isn't an error. The stap module will hang around and wait for /usr/bin/foo to be run and then attach to it. In the case of a loadable kernel module, if module "bar" isn't loaded right now, that isn't an error. The stap module will hang around and wait for module "bar" to be loaded and then the probe will get attached. Basically, each probe type has its own rules. Plus the probe types don't really know about each other. Doing what you suggest might be doable, but tricky. On Mon, Jul 23, 2018 at 9:22 AM Lukas Berk wrote: > > Hi, > > A somewhat tangential thought, > > David Smith writes: > >>> 2) WARNING: probe kernel.function("vfs_read@../fs/read_write.c:418") > >>> (address 0xffffffff95232f70) registration error (rc -84) > >>> > >>> That one is fairly fatal. Your probe couldn't be registered, and > >>> returned -84. Since your probe couldn't be registered, the module > >>> won't really do anything. > > From a usability standpoint, could we possibly keep track of the number > of targeted probe points vs successfully registered probe points? In > the event none exist, perhaps it'd be worthwhile to exit on our own > volition. It might spare users the extra time trying to debug the issue > with a message elaborating on why (ie, no probe points actually > registered, nothing for us to do). > > Cheers, > Lukas -- David Smith Associate Manager Red Hat