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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 E01A0C34047 for ; Wed, 19 Feb 2020 15:17:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B514724656 for ; Wed, 19 Feb 2020 15:17:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="cBhnjQYo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726927AbgBSPRb (ORCPT ); Wed, 19 Feb 2020 10:17:31 -0500 Received: from mail.efficios.com ([167.114.26.124]:55552 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726691AbgBSPRb (ORCPT ); Wed, 19 Feb 2020 10:17:31 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id D7BC02490A3; Wed, 19 Feb 2020 10:17:29 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2MXQCndbR0nH; Wed, 19 Feb 2020 10:17:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 946A7248E45; Wed, 19 Feb 2020 10:17:29 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 946A7248E45 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1582125449; bh=E+T2zau6Nrzd/5UrHxBwjFO/z6zZmEyWpKIt0k5o2nw=; h=Date:From:To:Message-ID:MIME-Version; b=cBhnjQYooRNjkzLDy0EtHNIr0MyHS+be39Ze0qlXO3sCvsU1Yj2PiVygBNOpGqcSp sZ0FgDegopcSsZYkbQtm24enMnm41JSZs7ecwoOJUs7oZANxMC6bpoU1TA/e2utw3v Dvo0sbsYkU/i2V4JINq7iDku3UFIUow25QevcGzOtZRTdeVBYybp+l5pnKyzCfMS/O +zK5ZuBF3QUgpI4f6wSwfkBG5P/b27iiVmnxdngYxcyPvDVMdwbvi20lFCS5kylVCH euvJRAHMDK8ElCyDRlfzPucBAAXCaBMYBpRETN++FOGjkKBAm8F6RAoneYa4TtAlCR qLMwim9QBTteA== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id i_e6Jf-_d-MZ; Wed, 19 Feb 2020 10:17:29 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 7F9E2248E3F; Wed, 19 Feb 2020 10:17:29 -0500 (EST) Date: Wed, 19 Feb 2020 10:17:28 -0500 (EST) From: Mathieu Desnoyers To: Alexei Starovoitov Cc: Thomas Gleixner , linux-kernel , "David S. Miller" , bpf , netdev , Alexei Starovoitov , Daniel Borkmann , Sebastian Andrzej Siewior , Peter Zijlstra , Clark Williams , rostedt , Juri Lelli , Ingo Molnar Message-ID: <1127123648.641.1582125448879.JavaMail.zimbra@efficios.com> In-Reply-To: <20200218233641.i7fyf36zxocgucap@ast-mbp> References: <20200214133917.304937432@linutronix.de> <20200214161504.325142160@linutronix.de> <20200214191126.lbiusetaxecdl3of@localhost> <87imk9t02r.fsf@nanos.tec.linutronix.de> <20200218233641.i7fyf36zxocgucap@ast-mbp> Subject: Re: [RFC patch 14/19] bpf: Use migrate_disable() in hashtab code MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3901 (ZimbraWebClient - FF72 (Linux)/8.8.15_GA_3895) Thread-Topic: Use migrate_disable() in hashtab code Thread-Index: FMpBzgOmPiKRGoH6zx7fdw8jq3/Jnw== Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org ----- On Feb 18, 2020, at 6:36 PM, Alexei Starovoitov alexei.starovoitov@gmail.com wrote: [...] > If I can use migrate_disable() without RT it will help my work on sleepable > BPF programs. I would only have to worry about rcu_read_lock() since > preempt_disable() is nicely addressed. Hi Alexei, You may want to consider using SRCU rather than RCU if you need to sleep while holding a RCU read-side lock. This is the synchronization approach I consider for adding the ability to take page faults when doing syscall tracing. Then you'll be able to replace preempt_disable() by combining SRCU and migrate_disable(): AFAIU eBPF currently uses preempt_disable() for two reasons: - Ensure the thread is not migrated, -> can be replaced by migrate_disable() in RT - Provide RCU existence guarantee through sched-RCU -> can be replaced by SRCU, which allows sleeping and taking page faults. I wonder if it would be acceptable to take a page fault while migration is disabled though ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com