From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F4080CA9EA1 for ; Fri, 18 Oct 2019 12:43:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C74F320820 for ; Fri, 18 Oct 2019 12:43:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2633903AbfJRMnq convert rfc822-to-8bit (ORCPT ); Fri, 18 Oct 2019 08:43:46 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:56707 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2633871AbfJRMnq (ORCPT ); Fri, 18 Oct 2019 08:43:46 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1iLRbV-00072Z-6y; Fri, 18 Oct 2019 14:43:37 +0200 Date: Fri, 18 Oct 2019 14:43:37 +0200 From: Sebastian Sewior To: Thomas Gleixner Cc: Clark Williams , David Miller , daniel@iogearbox.net, bpf@vger.kernel.org, ast@kernel.org, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, Peter Zijlstra , Arnaldo Carvalho de Melo Subject: Re: [PATCH] BPF: Disable on PREEMPT_RT Message-ID: <20191018124337.eycbrt25jmxfmar6@linutronix.de> References: <20191017090500.ienqyium2phkxpdo@linutronix.de> <20191017145358.GA26267@pc-63.home> <20191017154021.ndza4la3hntk4d4o@linutronix.de> <20191017.132548.2120028117307856274.davem@davemloft.net> <20191017214917.18911f58@tagon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 2019-10-18 10:46:01 [+0200], Thomas Gleixner wrote: > Clark, > > On Thu, 17 Oct 2019, Clark Williams wrote: > > On Thu, 17 Oct 2019 23:54:07 +0200 (CEST) > > Thomas Gleixner wrote: > > > #2) BPF does allocations in atomic contexts, which is a dubious decision > > > even for non RT. That's related to #1 > > > > I guess my question here is, are the allocations done on behalf of an about-to-run > > BPF program, or as a result of executing BPF code? Is it something we might be able > > to satisfy from a pre-allocated pool rather than kmalloc()? Ok, I need to go dive > > into BPF a bit deeper. > > Sebastion? The data structures use raw_spinlock_t as protection. This is where the atomic context is from. lpm_trie with trie_update_elem() allocates a new element while holding the lock. I tried to make it a spinlock_t which wouldn't have the problem but then https://lore.kernel.org/bpf/4150a0db-18f9-aa93-cdb4-8cf047093740@iogearbox.net/ pointed out that it has been made raw_spinlock_t due to kprobe on -RT. Commit ac00881f92210 ("bpf: convert hashtab lock to raw lock") was "okay" back then (according to Steven Rostedt) but it got wrong with the memory allocation which came in later. In order to tackle one thing at a time, I would say that kprobe isn't our biggest concern… > tglx Sebastian