Message ID | 20221223092703.61927-3-hch@lst.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp225988wrn; Fri, 23 Dec 2022 01:32:07 -0800 (PST) X-Google-Smtp-Source: AMrXdXtVKJgLm9qdk1Rt0d88OwYHPV1vOZczYjLGd7vbgUAuKgDb++dHGz7whuUW8MO8A8H9GxHD X-Received: by 2002:a62:18c9:0:b0:580:17d9:5b25 with SMTP id 192-20020a6218c9000000b0058017d95b25mr10526212pfy.24.1671787927412; Fri, 23 Dec 2022 01:32:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671787927; cv=none; d=google.com; s=arc-20160816; b=oGiKTHPgErdMBK/TQ39gM9SNKMU5QG9dRIc56PwOwPiCTW6Qik/8PL7c9ljfE08ClF DC6tU3iqgjOsDlqH2R23uG9Czc3pbr2hIIjFb4fFTOGyInR493q+grbdiBsnzhpveMVf NczYpwljRuEmEKHu0K+Rb+CyVnZl5Fn19PMFm9WW+D234sbS2h2GxroV2qnrmkuy5ka0 TRytlCt+fhMhPctXkKc7+nelBdzwb1IsyjFAN5fGcgu3dWijaDrBp/gP/KQDxwtysyiE fz1fLdNEztzd017tTpDYNg0UuxFJI1Cxvrya8m9xdrDWMPGBwQ+QWBKg5+rzXKnpEncI pp9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=uj5J1LKb/4UIpagExHs49WqhLRVbYSUrTZ0b+D0WTrE=; b=xXE5a6vHgsSpeHcj/M5EtDhqkbkbGHIwBJLCCPwLn3SuuyIIe6XIFQ2DrGeNqoGmL2 QesPOqLuLSdJz+5BcxcNGHAlRqRkKgUbsC1Vqo87ceuqT6CF0f4BhuubK/7O824jKlRn p/Dgv2itQbtBJEv6hYDXgjGA8cOqVmAluPc+2xZUHN2o/Ma6hUNCSOfqMcLw+Lb3S7hN wMklmxCYzkJtAaPeNfMwyyaEGo+5SXMNUyVs0t5KP6qAOnAWL5rg7oAJZp3b7nO2tjYQ L/Rp8BYoofYmcqVXAxaKiCRTH/5FG2YckV4iiUQa+0gVO3f9sjZo+hp5waAZr8mK3Wn4 AI6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=nIi94Z7x; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 14-20020a63050e000000b0045a73a1790asi3098517pgf.613.2022.12.23.01.31.55; Fri, 23 Dec 2022 01:32:07 -0800 (PST) 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=@infradead.org header.s=bombadil.20210309 header.b=nIi94Z7x; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236205AbiLWJ11 (ORCPT <rfc822;pacteraone@gmail.com> + 99 others); Fri, 23 Dec 2022 04:27:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236197AbiLWJ1U (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 23 Dec 2022 04:27:20 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D301E3720E; Fri, 23 Dec 2022 01:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description; bh=uj5J1LKb/4UIpagExHs49WqhLRVbYSUrTZ0b+D0WTrE=; b=nIi94Z7xg6PPdFGLsL4tc1cRkg fk8vpDY3Qb3un4xD1x2lRvrSE26lm0N2VFu2vOaxEEGO0wHPAN1Yxwhvxql+tye9eIB5BRKK8X8XV qanYlBggDmH2iPfyygKTQw+sRmJFClDwKQ2kuS5u26BxfEccIXUncjf++Bd5jYUx+wbGGQKfYdk4c 7/mdYbO9Mwpwbfp/CjA+1UI4MNSaFjOBU4i6+PdCtDeRCOcmkq8GcN830iPnmFv/pc+vl/vmUZblo TDK7c8vj1Clg2JWlevxJIVFeIehSHNSv5VExgK9skZq/Qyl4aoiTv6ZetYah0ZlvZ0ESd3tYFwVPO Judum79A==; Received: from [2001:4bb8:199:7829:8d88:c8b3:6416:2f03] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8eKe-005hTn-Jv; Fri, 23 Dec 2022 09:27:13 +0000 From: Christoph Hellwig <hch@lst.de> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Andrew Morton <akpm@linux-foundation.org>, Uladzislau Rezki <urezki@gmail.com> Cc: linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux.dev Subject: [PATCH 2/2] vmalloc: reject vmap with VM_FLUSH_RESET_PERMS Date: Fri, 23 Dec 2022 10:27:03 +0100 Message-Id: <20221223092703.61927-3-hch@lst.de> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221223092703.61927-1-hch@lst.de> References: <20221223092703.61927-1-hch@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752996697745036775?= X-GMAIL-MSGID: =?utf-8?q?1752996697745036775?= |
Series |
[1/2] Revert "remoteproc: qcom_q6v5_mss: map/unmap metadata region before/after use"
|
|
Commit Message
Christoph Hellwig
Dec. 23, 2022, 9:27 a.m. UTC
VM_FLUSH_RESET_PERMS is just for use with vmalloc as it is tied to freeing
the underlying pages.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
mm/vmalloc.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Fri, Dec 23, 2022 at 10:27:03AM +0100, Christoph Hellwig wrote: > VM_FLUSH_RESET_PERMS is just for use with vmalloc as it is tied to freeing > the underlying pages. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > mm/vmalloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 9e30f0b3920325..88a644cde9fb12 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2849,6 +2849,9 @@ void *vmap(struct page **pages, unsigned int count, > > might_sleep(); > > + if (WARN_ON_ONCE(flags & VM_FLUSH_RESET_PERMS)) > + return NULL; > + Might it be worth adding a specific vmap mask that explicitly indicates what flags are permissible on vmap()? Then this could become e.g.:- if (WARN_ON_ONCE(flags & ~VM_VMAP_PERMITTED_MASK)) return NULL; And would be self-documenting as to why we are disallowing flags (i.e. they are not part of the permitted vmap mask).
On Fri, Dec 23, 2022 at 10:24:25AM +0000, Lorenzo Stoakes wrote: > Might it be worth adding a specific vmap mask that explicitly indicates what > flags are permissible on vmap()? Then this could become e.g.:- > > if (WARN_ON_ONCE(flags & ~VM_VMAP_PERMITTED_MASK)) > return NULL; > > And would be self-documenting as to why we are disallowing flags (i.e. they are > not part of the permitted vmap mask). That's probably a good idea. It might need some time to audit for use of all the flags, though.
On Fri, Dec 23, 2022 at 03:03:12PM +0100, Christoph Hellwig wrote: > On Fri, Dec 23, 2022 at 10:24:25AM +0000, Lorenzo Stoakes wrote: > > Might it be worth adding a specific vmap mask that explicitly indicates what > > flags are permissible on vmap()? Then this could become e.g.:- > > > > if (WARN_ON_ONCE(flags & ~VM_VMAP_PERMITTED_MASK)) > > return NULL; > > > > And would be self-documenting as to why we are disallowing flags (i.e. they are > > not part of the permitted vmap mask). > > That's probably a good idea. It might need some time to audit > for use of all the flags, though. Perhaps leave that for a later patch (I could take a look as well), but in the meantime might be worth adding a quick comment here indicating why the flag is prohibited?
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 9e30f0b3920325..88a644cde9fb12 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2849,6 +2849,9 @@ void *vmap(struct page **pages, unsigned int count, might_sleep(); + if (WARN_ON_ONCE(flags & VM_FLUSH_RESET_PERMS)) + return NULL; + /* * Your top guard is someone else's bottom guard. Not having a top * guard compromises someone else's mappings too.