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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH autolearn=unavailable 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 CDF43C28CC2 for ; Wed, 29 May 2019 20:16:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A4C9124140 for ; Wed, 29 May 2019 20:16:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="bwKrSUcA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726362AbfE2UQN (ORCPT ); Wed, 29 May 2019 16:16:13 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:46640 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726225AbfE2UQM (ORCPT ); Wed, 29 May 2019 16:16:12 -0400 Received: by mail-pg1-f194.google.com with SMTP id v9so516941pgr.13 for ; Wed, 29 May 2019 13:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=byH71jcEnWiZocWjFrPDlTMOE7pd8EPRHoYGyukaY04=; b=bwKrSUcAFY5li8JHROxevBRkVdZvfftmbN2jvX4D8l/n4Q/b0ePv+zprqpG2KluSLn rSYJBFUhtygfnfgM4xMNPYR/Vp/NGpVKFovwEIHmtk8emThGP6iRNZH+rg7exn2dW3QV qTeu7YoFimL+W4CSITeRLNxas0G8YpYTWwbHw= 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=byH71jcEnWiZocWjFrPDlTMOE7pd8EPRHoYGyukaY04=; b=MY6f7BgxEmXgNXJ50txHjQJ/jrdAfzf1dXvGBX7DzKPvYj0vjnIZGq0v4umacgzjx/ vY7ENMu1aGX3QnVUwAOJ7E5InffXAk/aYbeCwZNH6PE+j3TW9VYlYNuSYNQq8SuDiDq4 UdT22j7SXrhjeFfovRqLHuA/qDZTQu43i2g9kN3Rple+n7Yf8aJ7LVouerNhYqqmhRi9 EDkt2K8TPsV6ZzDrrp/BJt3g69u5Jgaz2nryA1iBVR/AyhedikyIvEDVIl186ud/t6EU 4FIqGVNLasOuu71y/+5tDln9F0n0IRtL1Q68lhiXxXm1a/LxpzCn3pkXRObfmqCWmJNY c+eA== X-Gm-Message-State: APjAAAWp6lFVOcGr3rj2MOR+mncWSQSIRiWxLYEVk807aeEYuEehdg7a SM5aZgUPlyMqBdEdBeoCV9VsIw== X-Google-Smtp-Source: APXvYqwOtLbXvQF12v2iQzcTzlTPHXYwr/VbPiH/+9zX0lzSfnaAmA5ZoEnSGfNESsFHQ7AnnjhQoA== X-Received: by 2002:a63:f44b:: with SMTP id p11mr139393871pgk.225.1559160971649; Wed, 29 May 2019 13:16:11 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id u6sm227693pgm.22.2019.05.29.13.16.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 May 2019 13:16:10 -0700 (PDT) Date: Wed, 29 May 2019 13:16:09 -0700 From: Kees Cook To: Alexandre Ghiti Cc: Andrew Morton , Christoph Hellwig , Russell King , Catalin Marinas , Will Deacon , Ralf Baechle , Paul Burton , James Hogan , Palmer Dabbelt , Albert Ou , Alexander Viro , Luis Chamberlain , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 00/14] Provide generic top-down mmap layout functions Message-ID: <201905291313.1E6BD2DFB@keescook> References: <20190526134746.9315-1-alex@ghiti.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190526134746.9315-1-alex@ghiti.fr> Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Sun, May 26, 2019 at 09:47:32AM -0400, Alexandre Ghiti wrote: > This series introduces generic functions to make top-down mmap layout > easily accessible to architectures, in particular riscv which was > the initial goal of this series. > The generic implementation was taken from arm64 and used successively > by arm, mips and finally riscv. As I've mentioned before, I think this is really great. Making this common has long been on my TODO list. Thank you for the work! (I've sent separate review emails for individual patches where my ack wasn't already present...) > - There is no common API to determine if a process is 32b, so I came up with > !IS_ENABLED(CONFIG_64BIT) || is_compat_task() in [PATCH v4 12/14]. Do we need a common helper for this idiom? (Note that I don't think it's worth blocking the series for this.) -Kees -- Kees Cook