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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 AA424C4361B for ; Fri, 18 Dec 2020 05:24:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C36B23A53 for ; Fri, 18 Dec 2020 05:24:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727198AbgLRFYu (ORCPT ); Fri, 18 Dec 2020 00:24:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727150AbgLRFYt (ORCPT ); Fri, 18 Dec 2020 00:24:49 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 494C2C0617B0; Thu, 17 Dec 2020 21:24:09 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id m12so2322836lfo.7; Thu, 17 Dec 2020 21:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jX44ZPL55asabwkQzLkhgcKHKlN7+aA9+rXnNNw2E2o=; b=n/dGqS31k7Swa7Q3KF/IFsI+zgXuecnX2lbygMeiGzrTxZoTck3QjBcKuHB4qNUOwA jwamRuZTIlJXHCHxGMPSpa+/WX/HJeOsDWW0Gr04ExP6rAtszXr3k21XdQTI7hjjMXBG o8rwMYhJ0ZrBMfjJuf/lHKO1gl+D4AR64+kkf/TJHrPnHgyMDxF9ZOoAj9zD+Q7xcY7O UCOA03axsqgeNpuSaqNz10n/NUkSFsZ8ts9DCK0+Qiz658o4mbmjfwk0lWNmkzivG8P/ Ay9mmbBiL09eN8MAqnjKohoJE9OGhQzHykIyIDWyIrNTWQ+Pm7jnVEKe3Ke5PDdKK+af w7xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jX44ZPL55asabwkQzLkhgcKHKlN7+aA9+rXnNNw2E2o=; b=DsIM3r+h0aqjm1J7ECdcEd284+6wX2ezA2XKuhk/dV0M4K9GJVPMSHjZByaCaXFhHd h75aiUuZSH8+hiX33umt7rYomX7rbMR25OA5Wnp8u8OhqgPXMOAhxEJ8+fytHrABjSar zkOgnYlEF7sBdtq0G3yaEHWZJ3kmN92P/3TNu1se/ZQBNWiFlFsmGUtgBT2OILOR+uyx hWoMPhrpI3glWEeTEd38MdbUUtB3/lWAyuUWRkQYsdefkfZanFonkKqDwaxLCnPqL7Mm aDTJt1yIUK0v/I80xYuMkrn5jUWfJHJJ+PHIPJ//zbgl64sibjhAhNMR6ejaoxLoevMz PAFw== X-Gm-Message-State: AOAM530s+/m8KF7+u0UWNSo0yfHeGzuEDMcNqCCNyB3gUKGbZ6ISXdjg HtEXHIdbxeVYerxeu7KYQNxcR2W+nekM2c3c0lU= X-Google-Smtp-Source: ABdhPJwXw9PLTZ92JMwNuYjfVr8vvzmmiUosRPtsfidqJzjyZIOLFytJpGYorrxS72Mqw7CryE/hqUjPtJPCi9jGd1c= X-Received: by 2002:a2e:86d4:: with SMTP id n20mr1060727ljj.486.1608269047780; Thu, 17 Dec 2020 21:24:07 -0800 (PST) MIME-Version: 1.0 References: <20201215233702.3301881-1-songliubraving@fb.com> <20201215233702.3301881-2-songliubraving@fb.com> <20201217190308.insbsxpf6ujapbs3@ast-mbp> <20201218023444.i6hmdi3bp5vgxou2@ast-mbp> In-Reply-To: From: Alexei Starovoitov Date: Thu, 17 Dec 2020 21:23:56 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 1/4] bpf: introduce task_vma bpf_iter To: Song Liu Cc: "bpf@vger.kernel.org" , "netdev@vger.kernel.org" , "ast@kernel.org" , "daniel@iogearbox.net" , "andrii@kernel.org" , "john.fastabend@gmail.com" , "kpsingh@chromium.org" , Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Dec 17, 2020 at 8:33 PM Song Liu wrote: > > > > ahh. I missed that. Makes sense. > > vm_file needs to be accurate, but vm_area_struct should be accessed as ptr_to_btf_id. > > Passing pointer of vm_area_struct into BPF will be tricky. For example, shall we > allow the user to access vma->vm_file? IIUC, with ptr_to_btf_id the verifier will > allow access of vma->vm_file as a valid pointer to struct file. However, since the > vma might be freed, vma->vm_file could point to random data. I don't think so. The proposed patch will do get_file() on it. There is actually no need to assign it into a different variable. Accessing it via vma->vm_file is safe and cleaner. > >> [1] ff9f47f6f00c ("mm: proc: smaps_rollup: do not stall write attempts on mmap_lock") > > > > Thanks for this link. With "if (mmap_lock_is_contended())" check it should work indeed. > > To make sure we are on the same page: I am using slightly different mechanism in > task_vma_iter, which doesn't require checking mmap_lock_is_contended(). In the > smaps_rollup case, the code only unlock mmap_sem when the lock is contended. In > task_iter, we always unlock mmap_sem between two iterations. This is because we > don't want to hold mmap_sem while calling the BPF program, which may sleep (calling > bpf_d_path). That part is clear. I had to look into mmap_read_lock_killable() implementation to realize that it's checking for lock_is_contended after acquiring and releasing if there is a contention. So it's the same behavior at the end.