Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1238267pxb; Fri, 21 Jan 2022 13:04:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxgikrOKWSeXI4DWBA8IzkhgJIMHWQoIor6XPA93IWDqg9cDylg96tXtevQ1pqnZtFTopFr X-Received: by 2002:a17:902:c10c:b0:14b:13af:26fc with SMTP id 12-20020a170902c10c00b0014b13af26fcmr5530321pli.158.1642799097391; Fri, 21 Jan 2022 13:04:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642799097; cv=none; d=google.com; s=arc-20160816; b=V7hf8z0LndfDaaCae1hOmVRTW9Ijt0eAZnmjQrjcLQC79hvV7S7NnF4K3RuDSvOEir F/Ty43Z57KodkyEnXIGUeF6VqWgScjgtVKLnwF/f93W9uaQuIwCoNAdp92OspmTC5rsF yoB+O3OnKmOZvGkQxTbaTvYQzC2l5qUQ+F3X20geYm2tBpU+QzT7qxcM1kUb8NlVrmy3 0fSl9mtaAlY7uPbpUEc0i5TDBdLtPf/6klgFsrD0rapbOObv2asnNeVOd41UXssPVpOL DYDibLVl/XHAmxdZ4Z/vO8flt4tc4nexkSeVZzgOA7FSg4H5SOA/LnXkGKMTxZnjXSyV iKvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=cdVfVxqBrZIhumfm4vr3jeKxklpdza1CzXgrGhe9l8s=; b=WOK4vj9LbbE/PuKju2Vcyg9g5hOV3Es96YByub27Y2cfaDWIelfFcqpcGHoOodEfpk NYNB/NRkgI5L3MaA8bjRr6PzJdL7Bnd5gdr1nbvndDOhFZ5jJkiD6YqQ7J+59VxZzMuv jTaCNIE5yp41CBn3jQNLSF+pSgeXH/PQxNrVXBxD64HniAZQy6zCQ8xHidxRSwvyJx0X NqyiylNZ8WmrOFibVbKOgWtEiHn+UP8cHHp8qRPN/RvMlAFQ7eTqU1NEcCA7z39EvHzO fsyjNavqxqUfE19e6PXETcctbSt0Y1uM4pJGMN06zi2TpokYlKaJGmc9A90Rst0anbGB 10pg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n16si7733596plf.281.2022.01.21.13.04.45; Fri, 21 Jan 2022 13:04:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358350AbiATDhP (ORCPT + 99 others); Wed, 19 Jan 2022 22:37:15 -0500 Received: from foss.arm.com ([217.140.110.172]:49052 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232151AbiATDhO (ORCPT ); Wed, 19 Jan 2022 22:37:14 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8D8BC1FB; Wed, 19 Jan 2022 19:37:13 -0800 (PST) Received: from [10.163.74.136] (unknown [10.163.74.136]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 522953F766; Wed, 19 Jan 2022 19:37:07 -0800 (PST) Subject: Re: [PATCH] vmap(): don't allow invalid pages To: Yury Norov Cc: Matthew Wilcox , Catalin Marinas , Will Deacon , Andrew Morton , Nicholas Piggin , Ding Tianhong , Alexey Klimov , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Uladzislau Rezki References: <20220118235244.540103-1-yury.norov@gmail.com> From: Anshuman Khandual Message-ID: <5b62ed03-8da8-a94d-cc48-a8cac1eae1c9@arm.com> Date: Thu, 20 Jan 2022 09:07:11 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/19/22 10:52 PM, Yury Norov wrote: >> Why should not this just scan over the entire user provided struct page >> array and make sure that all pages there in are valid via above method, >> but in vmap() itself before calling vmap_pages_range(). Because seems >> like a single invalid page detected in vmap_pages_pte_range() will >> anyways abort the entire vmap(). This will also enable us to drop the >> existing NULL check above. > > I can do this, but why is it any better than the current approach? Because it will just return on the first instance where the valid page check fails, saving us some CPU cycles and an incomplete mapping ?