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=-4.1 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 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 0EC82C433EA for ; Tue, 28 Jul 2020 05:15:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E16412177B for ; Tue, 28 Jul 2020 05:15:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fv37iyID" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726407AbgG1FPY (ORCPT ); Tue, 28 Jul 2020 01:15:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726251AbgG1FPY (ORCPT ); Tue, 28 Jul 2020 01:15:24 -0400 Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A5D5C061794 for ; Mon, 27 Jul 2020 22:15:24 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id l64so10787150qkb.8 for ; Mon, 27 Jul 2020 22:15:24 -0700 (PDT) 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=a+9MHK95XvFIIi5VsSDsCTxDbAbcs6bPPGtZ11sgwh0=; b=fv37iyIDuz3Ris3M9HRmXV+mVN+IChEFzap0B0cJUKB3CH6xtblxkTmCUHKk1r2rBK LU0YxoulAtg72s3dR/2MxCga1pvftWUe73vtm0Uzme8bdhvWh/UG3Sws/gcR4lHDYJQt GNX+l/XP7PxBajLKKIToic1HNsXdMYEaiux+Rz5hfaaE/KUKY1uzS9oyf7sGUkWmGsu+ eprR68tffq/n0izcIN0Jbo8Zs4oZjL/jBPlNFfxXqtmOjXdtfc6rTOD6vOdV5ElRJhIm STg4+KXi02gVDjvNy3XlraTH4J0cupFlpiFlPbknZPFpDH3wQNrjZ3FrNL3HXEf6jkoB 24RQ== 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=a+9MHK95XvFIIi5VsSDsCTxDbAbcs6bPPGtZ11sgwh0=; b=ovj9PS3JaZSWh/gMi3DG8DfeeLlxtoSW8hXnhPJJSXpLzQd3W3BnMSFjqaogKnPIyx ieiKs9qxAvSJf5h2K1A1qU330M38glPB16CYtfdz0gTOieB86KlSRwdkmf2j3qcTWz0x JjAUTW3S3qmriao6vkHm8qzOYqT3eqb136LPpaGm5M63/ybkpquomcFKiQo7Fcm3oaF3 KPC0hf26CSko1aYaCEY6O+0ajktOSqA1D7YiGTIcU8sZi8a+wML6K/D0kg615OdDats9 YRcfsU/5CbgkrwWuQl/0M6KSokjTsHSbFkYfdaU4TWFEGT4vlpwJamJ1o1FYvWTy8UqC Dq/w== X-Gm-Message-State: AOAM531sh0huwnE/kPF91T4ccESth2rqvLu+VS78A39dwkfj3ytblxs2 MoyUozGFJ7OUslcdncFiimR9m1xfTKRJN1IcEp8= X-Google-Smtp-Source: ABdhPJyqFCMtRIVuery6DBh3jy73yN13X3zIlac1N8LcQfozc9GJCzOz7aHytHNRJt74uaB45YdbR/BQazE1VrjS3dA= X-Received: by 2002:a05:620a:4c:: with SMTP id t12mr513794qkt.449.1595913323290; Mon, 27 Jul 2020 22:15:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Nakryiko Date: Mon, 27 Jul 2020 22:15:12 -0700 Message-ID: Subject: Re: selftests: bpf: mmap question To: Yauheni Kaliuta Cc: bpf , Andrii Nakryiko , Jiri Olsa , Jiri Benc Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Jul 23, 2020 at 4:02 AM Yauheni Kaliuta wrote: > > Hi! > > I have a question about the part of the test: > [...] > > In my configuration the first mapping > > /* map all but last page: pages 1-3 mapped */ > tmp1 = mmap(NULL, 3 * page_size, PROT_READ, MAP_SHARED, > data_map_fd, 0); > > > maps the area to the 3 pages right before the TLS page. > I find it's pretty ok. Hm... I never ran into this problem. The point here is to be able to re-mmap partial ranges. One way would be to re-write all those manipulations to start with a full range map, and then do partial un-mmaps/re-mmaps, eventually just re-mmaping everything back. I think that would work, right, as long as we never unmmap the last page? Do you mind trying to fix the test in such a fashion? > > But then the 4 page mapping > > /* re-map all 4 pages */ > tmp2 = mmap(tmp1, 4 * page_size, PROT_READ, MAP_SHARED | MAP_FIXED, > data_map_fd, 0); > > > since it has MAP_FIXED flag, unmaps TLS and maps the former TLS > address BPF map. > > Which is again exactly the behaviour of MAP_FIXED, but it breaks > the test. > > Using MAP_FIXED_NOREPLACE fails the check: > > CHECK(tmp1 != tmp2, "adv_mmap6", "tmp1: %p, tmp2: %p\n", tmp1, tmp2); > > as expected. > > > Should the test be modified to be a bit more relaxed? Since the > kernel behaviour looks correct or I'm missing something? > > > PS: BTW, the previous data_map mapping left unmmaped. Is it expected? Not intentional, the idea is that each test exits with a clean state. > > -- > WBR, > Yauheni Kaliuta >