From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 38997385702F; Fri, 24 Jul 2020 14:12:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 38997385702F Received: by mail-oi1-x22d.google.com with SMTP id r8so8120655oij.5; Fri, 24 Jul 2020 07:12:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k7P4nIVgQDY1lqaHOXVoAt/qU6WXN0ueXWsjGVhYyVI=; b=KWfZwPUD9NlJd6Kfx7Prr2jD+hvk9cIzuMrviKcjdUqH0Cx+k2k34w55AxiN3Su0I5 rZ4+itx4sosAw//jI1DF90vlLOyChJeKzCwsIwYxWW1OmEUrqVQdY5oL2IZpKBkBAeOi 8JTDJ0DCTuwVxxdUTOrkbprGorLTUFbGZ2KD1NZNN+veMFEt4mjSqgZI5UIJjzXV/BDt yFsDSgefFCuo6f/BVSqsY/KMIE32GkU/FhHfQWlP2xlk5hNdIwqFtismWl41xnzz3/xm 2ke30J6OJYU/Jn9Vap1th4vk5/U8fqIVdoeWnbRqtFrwJCteHurYevqYl5aIi4FLVDOH ak+Q== X-Gm-Message-State: AOAM531Rw82H52nylQUv61pt6L/mTvTOX7zXfkgp9YxXw8KJ17Qscms4 d+cGaweeXNCiwpDtOgrUTFAIao2uWDgtPj2UZdA= X-Google-Smtp-Source: ABdhPJxe7h2y6EFG4JVB0+aK2k8Epwx5+wcJNsyNM+xytUaQv0zTtlDyZ0kWZgCzQPPP6/BhAUkRoP8zbXoosgOMbZc= X-Received: by 2002:a05:6808:647:: with SMTP id z7mr7840103oih.73.1595599964540; Fri, 24 Jul 2020 07:12:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arkady Date: Fri, 24 Jul 2020 17:12:33 +0300 Message-ID: Subject: Re: [Bug translator/26296] New: delay script-global locking until required To: Craig Ringer Cc: fche at redhat dot com , systemtap Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 14:12:46 -0000 On Fri, Jul 24, 2020 at 8:23 AM Craig Ringer wrote: > > > > > IOW: defer locking to the first moment when any global is actually > > read/written, tracking locked-ness in a new context local. This would > > involve > > only a small change to the translator, involving only context-free logic. > > That > > could later be optimized to remove repeated checks/etc. over multiple > > global vars in > > a control-flow / context aware way. > > > > > Even an explicit construct that scopes locking would be handy. Borrow from > Java's "synchronized" perhaps. > > The fact that whole probes get locked is a serious limitation for one of my > systemtap use cases, where I inject delays and faults into the target > application. The probe flow is supposed to be something like: > > global targets_map; > > probe process("foo").mark("some_probe_point") { > if (pid() in targets_map) { > kdelay(100000); > } > } Usually there is a lock because of the use of maps/associative arrays. Use your own C implementation (check the code base I sent you) ... or we can implement inline C support. You can not sleep in many probes. Such code does not crash immediately, but eventually it will. In some probes it is safe to sleep. > > where kdelay is a simple embedded C wrapper around the kernel function of > the same name. But due to the locking on the global "targets_map", every > hit on "some_probe_point" will block on the lock held by the sleeping > probe. So probes can't inject sleeps or delays to try to trigger race > conditions. > > So yes, the ability to take a lock over a narrower scope than the whole > probe would be very desirable. > > I've wondered about the feasibility of doing this in embedded C, but > haven't had a chance to explore it properly yet. That's the route you have > > This reminds me - is it ever safe to sleep in a systemtap probe, e.g. to > call ksleep() rather than busy-loop? > > -- Spinlocks are Ok. Calls to sleep() generally is not safe,