Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp5538840iob; Mon, 9 May 2022 19:57:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQeUpnprBvAKTiz6V2Ce76fe1Nm0jHvTzllfTQOIlqUlpSmZDojShqXBuiW9vVFTzwyciP X-Received: by 2002:a17:906:4783:b0:6d0:9b6e:b5a5 with SMTP id cw3-20020a170906478300b006d09b6eb5a5mr18058965ejc.526.1652151474545; Mon, 09 May 2022 19:57:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652151474; cv=none; d=google.com; s=arc-20160816; b=stUBweIU5Qtr1/v2RczQhO7qpRI8Z6xXvq9bQr/xDyraoacpq+xrApQyTojFjt0wpo JS5wrWZhGZieiH+09frLtrxn2lTVAXbNs0HgjSs3RZYNa/6RIl9nuJmcGj4vu04DdwCW pLWhL/5NgIwkCN+O3fFDlw4OmlWwIWgTQ/QxBNY1IxSN5bmxk3/5ge94E6EhqhweP846 aVcgg+982jqsi9tixtyvF5yADjviDJRQGkq4jxIMKDK34D2FEeHqDoREEKJW2VgU4Wcy 8fO0XGSIf5D9yYUtY1oXJ6JwQcc1aYeslS/88W1hAP4Ct1LfmsUkK27pUIDtvDPPEQj9 EwcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=3CHnTRVSx7EiMqE3gXZruy28LmKpNUBw2gGOVHAk0qc=; b=Uux6TlzJT0oHZHAGbSi8ALC8juUXcU6v0JK/Bq3kpJneuY3TJCF03LmBr/gy2sr/bI WBfOtHqAiivDmwCfRqUDNmUiLP+2jK1Jz1NK7SiKxnpbt/uJWg212LuzvA6zSTpu20Ev hlvyvfae/OhqE1TouWnCe9BzG1KW8G5oNDiGHODqxrtVUEVs1cxp2tliT/b8lRqduJ5z iTY+iNYFofcuFCr129EArlZs6Vs9viK3IGUV8Km+EsDJjJLdtD1zQRqN+mR/lLHSNf7Y /Nh3RKCThRQUHZSw4tRWxczdn59wloNdUpkVLMEMfncLbRXBUq+G/uW9vuVDQJG5O0J0 /Z8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=vbrYyQzx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bi13-20020a170906a24d00b006df76385cb5si14122487ejb.341.2022.05.09.19.57.30; Mon, 09 May 2022 19:57:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=vbrYyQzx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234889AbiEJCpx (ORCPT + 99 others); Mon, 9 May 2022 22:45:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232596AbiEJCpv (ORCPT ); Mon, 9 May 2022 22:45:51 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D853227F11C for ; Mon, 9 May 2022 19:41:54 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id r192so9351155pgr.6 for ; Mon, 09 May 2022 19:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:cc:references :from:in-reply-to:content-transfer-encoding; bh=3CHnTRVSx7EiMqE3gXZruy28LmKpNUBw2gGOVHAk0qc=; b=vbrYyQzxhp0kzXpHDjd4wnZjFNvSziTNaM92BL227G6XaufuQvxBCpQBYZWCqhtupK 7iBzTlFhTJ5mlWdCJDkdKiuiTGpwFEsc0og6zLqo7bugE6bqIkxKxaaWdr4UZn+cJjHk yT3fz3YSmbH4rYVKVAfzMw4TU/KFYVi7q76uXJa5RZ3W3ntqdmm4q6S77p8G7z0R31cI 3BLscLUWVKecV5dqMBP/S1xGPvjKZjR+t48UyeJkKaIu4YmKRUYhbWJO407hL6vH8cF6 dt5ey17+oeBMwfXeULIiYBiqKp3UWUKFgcvT6MuKQ38mBL7iHqtsm4MtS0GMAEbUIfg0 6y+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:cc:references:from:in-reply-to:content-transfer-encoding; bh=3CHnTRVSx7EiMqE3gXZruy28LmKpNUBw2gGOVHAk0qc=; b=ySuNwanQ/p8PcjX7ccdFnmhhgSRvbHMvZ1QC6wkvz7Wzi+ioTB8QI6Aw5pqT5Xv2rB 7QZBgEy0GxUBDqQDaGmcs9ox1TQ2AOBThK+Ao/xgx51W4WQRWEt0Lv+Jem5LMlU4tVF2 q7gn1h4R9Ba6shSTB9u6JAEZpS52EkEnLrpnufdPwafDFB8b2q5AA/xlUQ/bbbo+bOxj BCA1c5CZ7xAT+TwROxx91miAcICMQZGFshDMybyEvJ6iU2pdJslcXB4P6xM4FzrzZe0y sgBECWG0yIC6oMKEaY7ywT5Drp1hhlODiSByPuFZH3ae8Nt9SB4soHQ2mowVGT7pDVF+ xW0Q== X-Gm-Message-State: AOAM530YHab0i1xwGFWfeigxv3oW+YBCUjeC/ouP88Ie1ifmAI3x+AeU VPtzSPzg9QUTA6X1/gY272JB7Q== X-Received: by 2002:a62:d10b:0:b0:50d:a238:75d4 with SMTP id z11-20020a62d10b000000b0050da23875d4mr18377014pfg.78.1652150514074; Mon, 09 May 2022 19:41:54 -0700 (PDT) Received: from [10.86.119.184] ([139.177.225.231]) by smtp.gmail.com with ESMTPSA id g24-20020a170902d5d800b0015e8d4eb2e2sm566338plh.300.2022.05.09.19.41.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 May 2022 19:41:53 -0700 (PDT) Message-ID: Date: Tue, 10 May 2022 10:41:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [External] Re: [PATCH bpf-next] bpf: add bpf_map_lookup_percpu_elem for percpu map To: Yosry Ahmed , Andrii Nakryiko Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Steven Rostedt , Ingo Molnar , Jiri Olsa , Dave Marchevsky , Joanne Koong , Geliang Tang , Networking , bpf , open list , duanxiongchun@bytedance.com, Muchun Song , Dongdong Wang , Cong Wang , zhouchengming@bytedance.com References: <20220507024840.42662-1-zhoufeng.zf@bytedance.com> From: Feng Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/5/10 上午9:04, Yosry Ahmed 写道: > On Mon, May 9, 2022 at 5:34 PM Andrii Nakryiko > wrote: >> On Fri, May 6, 2022 at 7:49 PM Feng zhou wrote: >>> From: Feng Zhou >>> >>> Trace some functions, such as enqueue_task_fair, need to access the >>> corresponding cpu, not the current cpu, and bpf_map_lookup_elem percpu map >>> cannot do it. So add bpf_map_lookup_percpu_elem to accomplish it for >>> percpu_array_map, percpu_hash_map, lru_percpu_hash_map. >>> >>> The implementation method is relatively simple, refer to the implementation >>> method of map_lookup_elem of percpu map, increase the parameters of cpu, and >>> obtain it according to the specified cpu. >>> >> I don't think it's safe in general to access per-cpu data from another >> CPU. I'd suggest just having either a ARRAY_OF_MAPS or adding CPU ID >> as part of the key, if you need such a custom access pattern. > I actually just sent an RFC patch series containing a similar patch > for the exact same purpose. There are instances in the kernel where > per-cpu data is accessed from other cpus (e.g. > mem_cgroup_css_rstat_flush()). I believe, like any other variable, > percpu data can be safe or not safe to access, based on the access > pattern. It is up to the user to coordinate accesses to the variable. > > For example, in my use case, one of the accessors only reads percpu > values of different cpus, so it should be safe. If a user accesses > percpu data of another cpu without guaranteeing safety, they corrupt > their own data. I understand that the main purpose of percpu data is > lockless (and therefore fast) access, but in some use cases the user > may be able to safely (and locklessly) access the data concurrently. > Regarding data security, I think users need to consider before using it, such as hook enqueue_task_fair, the function itself takes the rq lock of the corresponding cpu, there is no problem, and the kernel only provides a method, like bpf_per_cpu_ptr and bpf_this_cpu_ptr, data security needs to be guaranteed by users in different scenarios, such as using bpf_spin_lock. >>> Signed-off-by: Feng Zhou >>> --- >>> include/linux/bpf.h | 2 ++ >>> include/uapi/linux/bpf.h | 9 +++++++++ >>> kernel/bpf/arraymap.c | 15 +++++++++++++++ >>> kernel/bpf/core.c | 1 + >>> kernel/bpf/hashtab.c | 32 ++++++++++++++++++++++++++++++++ >>> kernel/bpf/helpers.c | 18 ++++++++++++++++++ >>> kernel/bpf/verifier.c | 17 +++++++++++++++-- >>> kernel/trace/bpf_trace.c | 2 ++ >>> tools/include/uapi/linux/bpf.h | 9 +++++++++ >>> 9 files changed, 103 insertions(+), 2 deletions(-) >>> >> [...]