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=-6.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 76F81C433DF for ; Sat, 1 Aug 2020 01:03:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 506D020829 for ; Sat, 1 Aug 2020 01:03:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726215AbgHABDZ (ORCPT ); Fri, 31 Jul 2020 21:03:25 -0400 Received: from www62.your-server.de ([213.133.104.62]:42910 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbgHABDY (ORCPT ); Fri, 31 Jul 2020 21:03:24 -0400 Received: from sslproxy03.your-server.de ([88.198.220.132]) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1k1fvk-0001vq-5c; Sat, 01 Aug 2020 03:03:20 +0200 Received: from [178.196.57.75] (helo=pc-9.home) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k1fvj-000Hg4-Vi; Sat, 01 Aug 2020 03:03:20 +0200 Subject: Re: [PATCH v6 bpf-next 0/6] bpf: tailcalls in BPF subprograms To: Maciej Fijalkowski , ast@kernel.org Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, bjorn.topel@intel.com, magnus.karlsson@intel.com References: <20200731000324.2253-1-maciej.fijalkowski@intel.com> From: Daniel Borkmann Message-ID: Date: Sat, 1 Aug 2020 03:03:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20200731000324.2253-1-maciej.fijalkowski@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.3/25890/Fri Jul 31 17:04:57 2020) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 7/31/20 2:03 AM, Maciej Fijalkowski wrote: > v5->v6: > - propagate only those poke descriptors that individual subprogram is > actually using (Daniel) > - drop the cumbersome check if poke desc got filled in map_poke_run() > - move poke->ip renaming in bpf_jit_add_poke_descriptor() from patch 4 > to patch 3 to provide bisectability (Daniel) I did a basic test with Cilium on K8s with this set, spawning a few Pods and checking connectivity & whether we're not crashing since it has bit more elaborate tail call use. So far so good. I was inclined to push the series out, but there is one more issue I noticed and didn't notice earlier when reviewing, and that is overall stack size: What happens when you create a single program that has nested BPF to BPF calls e.g. either up to the maximum nesting or one call that is using up the max stack size which is then doing another BPF to BPF call that contains the tail call. In the tail call map, you have the same program in there. This means we create a worst case stack from BPF size of max_stack_size * max_tail_call_size, that is, 512*32. So that adds 16k worst case. For x86 we have a stack of arch/x86/include/asm/page_64_types.h: #define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER) #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER) So we end up with 16k in a typical case. And this will cause kernel stack overflow; I'm at least not seeing where we handle this situation in the set. Hm, need to think more, but maybe this needs tracking of max stack across tail calls to force an upper limit.. Thanks, Daniel