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=-17.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=ham 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 A2A6FCA9EC9 for ; Fri, 1 Nov 2019 03:34:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 720162086D for ; Fri, 1 Nov 2019 03:34:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cydZe1ow" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729714AbfKADes (ORCPT ); Thu, 31 Oct 2019 23:34:48 -0400 Received: from mail-pf1-f202.google.com ([209.85.210.202]:33154 "EHLO mail-pf1-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726772AbfKADes (ORCPT ); Thu, 31 Oct 2019 23:34:48 -0400 Received: by mail-pf1-f202.google.com with SMTP id g20so6333193pfo.0 for ; Thu, 31 Oct 2019 20:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=unmgH0OiSy3jDJ6az+b/xInzZdYuHgLlqgn4pre13TA=; b=cydZe1owe05ISb5LJ/dCm3khNLU0GVAJ9uUDWLvpNLLc6hQfTpx7nns7zcTApAU8J0 RTh6Y1Ra3mVzHmVxTLo0VcTZfvqmTWvDlv4cEyyq96PvcJF8vXdZXC2qBEwBi5oZ0Uq8 udTtrsLj4OalXZ22tOE+CQC9HhgyK4dYmzPhK+v6w+n/XsMg3qVeKEpMFevIU1cmN2fQ ke4jqk3R/2jYo66D8jrFdFChreyQoC9dw8SbdbtHxffqzB+aDUuouLC4BuSHl0WMOJke 4YwTihxJDl5RsfnPBS2J2g7nfjARX5OLiMR3So+TBiNfs+zlcfQaRoumsl7gQj6FQG9F 5deQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=unmgH0OiSy3jDJ6az+b/xInzZdYuHgLlqgn4pre13TA=; b=dKjmYTOPfBEw0u9u8YSWvKfkKNlzDbZ6+K4fhpALL6qSrF2IkqicYxc6j/tPvVeWFY Ni7zGKI6Le6eyiVL/h9wIzDchOtJ3RTiJ2fzltuVDfg3iww/VLmc152Mqd/tt7KD4uov xjhgzljCgYTkYJbE3V8aQAvraCIimmdpr/6JpprDhCU/a1GqT8pills6IMOady2nXi6X Ggk+Yr+rNNL3loM/C0aPgvRekebLlUWec86YUKUtyRYcKA8UrJrpKm3WEe6uhFTnjs4s f13+WGM9KY/P1osVaCSjZJ2vWYLjERSQWVAeGsa2GphVHy0mA3Kq1N4XWIcJ9nUMEHwq pedw== X-Gm-Message-State: APjAAAUtjHL1qt9/+TmfFjBqSeHQ6hn5pTc6CT3KsgfQvSaEUQ4MGWUO eXSGKknr7zt+xy9RCZzJwe652usqwFHAVQ== X-Google-Smtp-Source: APXvYqxMwhIpgSPCGWaDzlp0xMzKAy0b4vaUJpHskEPwTvMaVqc15ftDiZfFQlXA9zR1CBYNtiSyLE1mU5RzMA== X-Received: by 2002:a63:7015:: with SMTP id l21mr9992972pgc.200.1572579287290; Thu, 31 Oct 2019 20:34:47 -0700 (PDT) Date: Thu, 31 Oct 2019 20:34:44 -0700 Message-Id: <20191101033444.143741-1-edumazet@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.24.0.rc1.363.gb1bccd3e3d-goog Subject: [PATCH net] powerpc/bpf: fix tail call implementation From: Eric Dumazet To: Alexei Starovoitov , Daniel Borkmann Cc: "David S . Miller" , netdev , Eric Dumazet , Eric Dumazet , bpf , "Naveen N. Rao" , Sandipan Das , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin KaFai Lau , Song Liu , Yonghong Song Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org We have seen many crashes on powerpc hosts while loading bpf programs. The problem here is that bpf_int_jit_compile() does a first pass to compute the program length. Then it allocates memory to store the generated program and calls bpf_jit_build_body() a second time (and a third time later) What I have observed is that the second bpf_jit_build_body() could end up using few more words than expected. If bpf_jit_binary_alloc() put the space for the program at the end of the allocated page, we then write on a non mapped memory. It appears that bpf_jit_emit_tail_call() calls bpf_jit_emit_common_epilogue() while ctx->seen might not be stable. Only after the second pass we can be sure ctx->seen wont be changed. Trying to avoid a second pass seems quite complex and probably not worth it. Fixes: ce0761419faef ("powerpc/bpf: Implement support for tail calls") Signed-off-by: Eric Dumazet Cc: "Naveen N. Rao" Cc: Sandipan Das Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: netdev@vger.kernel.org Cc: bpf@vger.kernel.org --- arch/powerpc/net/bpf_jit_comp64.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c index 02a59946a78af46416e9d949047ad3fefe3fc159..be3517ef0574d0911f6d63b530b33954c8ca343d 100644 --- a/arch/powerpc/net/bpf_jit_comp64.c +++ b/arch/powerpc/net/bpf_jit_comp64.c @@ -1141,6 +1141,19 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp) goto out_addrs; } + /* + * If we have seen a tail call, we need a second pass. + * This is because bpf_jit_emit_common_epilogue() is called + * from bpf_jit_emit_tail_call() with a not yet stable ctx->seen. + */ + if (cgctx.seen & SEEN_TAILCALL) { + cgctx.idx = 0; + if (bpf_jit_build_body(fp, 0, &cgctx, addrs, false)) { + fp = org_fp; + goto out_addrs; + } + } + /* * Pretend to build prologue, given the features we've seen. This will * update ctgtx.idx as it pretends to output instructions, then we can -- 2.24.0.rc1.363.gb1bccd3e3d-goog