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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 69569C433DB for ; Fri, 12 Feb 2021 04:47:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D6B1964E6C for ; Fri, 12 Feb 2021 04:47:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6B1964E6C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 26DF78D001E; Thu, 11 Feb 2021 23:47:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21F088D0015; Thu, 11 Feb 2021 23:47:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 135DA8D001E; Thu, 11 Feb 2021 23:47:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id F33A18D0015 for ; Thu, 11 Feb 2021 23:47:17 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B2304180AD81D for ; Fri, 12 Feb 2021 04:47:17 +0000 (UTC) X-FDA: 77808381714.05.hose18_050f9c72761e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 96908180318F8 for ; Fri, 12 Feb 2021 04:47:17 +0000 (UTC) X-HE-Tag: hose18_050f9c72761e X-Filterd-Recvd-Size: 5121 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Feb 2021 04:47:17 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id t26so5462664pgv.3 for ; Thu, 11 Feb 2021 20:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qdkQpYGmovlbLm9AjueiZQhJE1B/fzhKTm7VvpE05yU=; b=IWw8PdPLVOs42dU/36xHTH49SKCB/8a/J4SIMQ7yfWRHy+itvKyRi75luKceYVHpbe uaWiv94AqL5RVmKWuQV59fGlRt+6Lxq48RIpi3roRk364wIJTleE811ZG0294XYTo4SR BVDHySQWEXcugFC6i/enHaeRcrwBNPN8OKh5zMMVLmmDx0cspgbwtwjw89SB9ahfDeV3 0Z/ns9s4hhGdL3oZOjTkp/nx661zKqpOSkwe8I1AeAaXRFg2meLzkAt8tjdaCNk0OLRW ghKHwbAeFw7Mb1WIetLv1CcrSSVJLHYuuMHceaoAgn0u1GMcPjuyTJiVL/Vdzs53jv6u vAzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qdkQpYGmovlbLm9AjueiZQhJE1B/fzhKTm7VvpE05yU=; b=Yb6SfV47ilSbhisun2+/UZOUB2yTK3/ihNZ0osILe15GDVJCvIlwe3HDdalCpYZvS1 rDl1nORPn6HHHZTDEVBWha9SNNMvf6SqfsEOMBKxRZUPTc5BUR+Jcsjx85kjDn53Q0P7 pGk6MoYA/YcJq+eO4bwlv/Ae/FBB2lHyrP9k9m7FVcvegstxsRUzQi+j7vid6VwmIWwY Mn9o8pPpotz4RlbJgDXvhsGFuSgmjybZPYR8DaHykblZKzqXGJTvckXlyy7MkYJWhpJF KJkJMHt+lpcasn7lICvu74lsyK9+xyBRu4U0IVm4M8bhluZWdZt28HnmnMud4BRCxaYf 0XBQ== X-Gm-Message-State: AOAM530AgvDph57vz2+aT9S/2Ldf3JH1rC5JnHasmnBYGJnRRV/+gYaQ EFo74F4FwRYQ7hveLAIxYvA= X-Google-Smtp-Source: ABdhPJxKpx0BNz43kB6jP006to5mkzB0qD8G6ZTLjuDUPdTSv1dA8UfUvkPAZnHb0TXBS1x09QQlcA== X-Received: by 2002:a62:e804:0:b029:1dd:cf18:bdee with SMTP id c4-20020a62e8040000b02901ddcf18bdeemr1444005pfi.63.1613105236077; Thu, 11 Feb 2021 20:47:16 -0800 (PST) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:400::5:31f0]) by smtp.gmail.com with ESMTPSA id y20sm7148856pfo.210.2021.02.11.20.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Feb 2021 20:47:15 -0800 (PST) Date: Thu, 11 Feb 2021 20:47:13 -0800 From: Alexei Starovoitov To: Song Liu Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, ast@kernel.org, daniel@iogearbox.net, kernel-team@fb.com, akpm@linux-foundation.org, Yonghong Song Subject: Re: [PATCH v6 bpf-next 1/4] bpf: introduce task_vma bpf_iter Message-ID: <20210212044713.ptgvtsnh22vp5axg@ast-mbp.dhcp.thefacebook.com> References: <20210212014232.414643-1-songliubraving@fb.com> <20210212014232.414643-2-songliubraving@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210212014232.414643-2-songliubraving@fb.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 11, 2021 at 05:42:29PM -0800, Song Liu wrote: > +static int __task_vma_seq_show(struct seq_file *seq, bool in_stop) > +{ > + struct bpf_iter_seq_task_vma_info *info = seq->private; > + struct bpf_iter__task_vma ctx; > + struct bpf_iter_meta meta; > + struct bpf_prog *prog; > + > + meta.seq = seq; > + prog = bpf_iter_get_info(&meta, in_stop); > + if (!prog) > + return 0; > + > + ctx.meta = &meta; > + ctx.task = info->task; > + ctx.vma = info->vma; > + return bpf_iter_run_prog(prog, &ctx); > +} That part doesn't match patch 2. If it needs to call sleepable prog it should call it differently, since bpf_iter_run_prog() is doing rcu_read_lock(). Try adding the following: diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 845b2168e006..06f65b18bc54 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1159,6 +1159,8 @@ BPF_CALL_3(bpf_d_path, struct path *, path, char *, buf, u32, sz) long len; char *p; + might_sleep(); and you will see a splat from patch 4's task_vma test. But this might_sleep above is not correct. d_path is not about sleepability. It does its locking under rcu_read_lock. The bpf_d_path_allowed is confusing, since it checks for lsm sleepable hooks, but it's not about sleeping. Those hooks are safe because they don't hold any vfs locks. With bpf iterators the situation is the same. They all are called from bpf_seq_read. Which runs in user context and there are no vfs locks to worry about. So it's safe to enable all iterators to access bpf_d_path. No need to introduce sleepable iterators. The upcoming bpf_for_each_map_elem is kinda an iterator too where map elem callback shouldn't be able to call bpf_d_path, but it won't have expected_attach_type == BPF_TRACE_ITER, so bpf_for_each_map_elem will be fine the way last patches were done. So just drop 'prog->aux->sleepable' from patch 2 and delete patch 3.