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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80555C6FD1F for ; Sun, 19 Mar 2023 20:47:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8CD96B0075; Sun, 19 Mar 2023 16:47:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3CD96B0078; Sun, 19 Mar 2023 16:47:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB6826B007B; Sun, 19 Mar 2023 16:47:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 98AF26B0075 for ; Sun, 19 Mar 2023 16:47:25 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 65A9EA0479 for ; Sun, 19 Mar 2023 20:47:25 +0000 (UTC) X-FDA: 80586833250.14.24D2DE8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 8E71EC0015 for ; Sun, 19 Mar 2023 20:47:23 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=n6sHupCP; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679258843; a=rsa-sha256; cv=none; b=6CE4D4FAukTfmsKVFOaF4KhSLHjkoSgeVexolbIfIpWaQO8BsVh0u239zW7expz8ytTfjg hYpTL3XKqGtPFl+Yh0vvWU0uK8uHzMhSgX/OL+5rKufAgDlmw6FrMmpY0KsnJSEez98A0/ s4SqJnV0BV2GnP6RvTqKRJfF/a2+cww= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=n6sHupCP; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679258843; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uLso9CqfYCyg061D5wJXbbp0BELJ+NatQ0Cb1mhb6E0=; b=M5dnaFGweTa9Nw0+zLEjCgNrGypXIPqo631zykG0ckg7COkyDan++7T6T083qjE8rNgyoc Aiu98L1AAFN9XnKOzlqIVSyMVe0eowV//6ME9yybn9C9XhZa3mcPSWJtwvjBIseHHEQBJa DI8MXHnLIjTh63iS8NI08AuuzE9GZus= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=uLso9CqfYCyg061D5wJXbbp0BELJ+NatQ0Cb1mhb6E0=; b=n6sHupCPJxrkAJx1Ff2AslPhMX 084FCS4Y17DPH/qXsaDHcvkxd9TPgzoWbdz+sHBOqVljZNwfJFHyctiBMA+L0FDyEqKXVrCMpqjTt SRK9Sa75H3UZEwxTGDb8e13ar8PY09qC0HTUBANpcVae2t4/BWvqwJMaTDw5LmdlJMN6kSHT7oj8m Hr+zkhVUlqTdUM8bKXCfdJOfCoOeTsLSZy2fwglwz2Vov/ncnV15K6mcitMUI/LANIl0Tl4VrgBEo LtS9oaaV0LFVUR/lB0Cpaj9c4SYFqC4bBF8dT9MQxc+Q40BfwzNHr7qLPkJEAgNunDmm5V+O+QkQH vwbTe0+Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pdzvu-000O0l-D0; Sun, 19 Mar 2023 20:47:14 +0000 Date: Sun, 19 Mar 2023 20:47:14 +0000 From: Matthew Wilcox To: Lorenzo Stoakes Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Baoquan He , Uladzislau Rezki , David Hildenbrand , Liu Shixin , Jiri Olsa Subject: Re: [PATCH v2 2/4] mm: vmalloc: use rwsem, mutex for vmap_area_lock and vmap_block->lock Message-ID: References: <6c7f1ac0aeb55faaa46a09108d3999e4595870d9.1679209395.git.lstoakes@gmail.com> <20230319131047.174fa4e29cabe4371b298ed0@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 8E71EC0015 X-Rspamd-Server: rspam01 X-Stat-Signature: bugkw7p7ox56561u4x11csq9jouz4imj X-HE-Tag: 1679258843-227696 X-HE-Meta: U2FsdGVkX18LLihaJLLX+vLrwarjTWFpbyn1+SvSfSaWxKbd3XI5rZg4T0EHAkLtFsSYP6m2HyxeNUEbybM1fS3kBGyMm9pekA91J0wpXF61qXgQa0CN8IrLuhzk0Ojymxd5G20+JkQAtvA3KCJ8VelM+xXkgUdT/lSdvPqGkIbnrThOazCiQoqdl5BDamNSGuXmLd3zKXZcK3eZrW3ICFQU8XX3ooB6QsbOefL1vkKONKQ9YZ0Wjk2vLy6SjA0LsXBEpW5UjW0tYV6X0pCGoT/cYmdfZEp2tgn1qSLEzVkWHm8n/Jug6Rr7cbuKyi40547mAFNwYLSeMjAA7OWeuZRhLNRpygCmZdQtk2vV9kxWrKatbsL8o7a3uSEGWlXUlgrZd5WuC0jEah66P1LnDStqv4l6wqqJi652hK+b/o5br+o1Ztah44yAK3BhFMY39epDxnu7YZ8RAQle5uNsnPlXmPuMT8LVFav2tJLZIBTB7X87GUGln5oBAG0iE9dN8adx9u9r48sEJomOXoLhsxXVrrR6yAw/FCl6KWTkHAqFYCYWY77vRZuL4K3jA7FaYsrkyBTT88tOMFpvQk++cNxMZbG16hiS/ULmBh5LRFjmhf89Lo2zmEtdb94hKEzxBavo6XEo0i/KRf2Qcn6mEcGjvkW72DBX1Uca+h46XWiHib3ZttJ29mOwcPehSxYpTQlvUtu+uRC6Uq79BU2pPcjkY6IBdr2yMJc9P7VPBus9nlirfL1nUid44nkS06X0cWXb2FM1FGZrKah3YqWguc8WYx+LlC6EbsLmsr3G1Aq/eqNPJsXBspNqUO/kMZ8KI4lB+SLo7n4DEDMmrmpQb4u4Tk1gmmX7z3z6cSJJcrdAIV5P57d+8uzE5Dhzzx42WRh9/1d+r1mwXtgLEJpIp05d3m7DFud6w2NgXF5EGDdOvGYQZO6K5YvvrCzIcNwY6mkD+wnhGW4vr4tfcR5 twLddpil Lmz7A5iVWIL3QR8GKTjsw9Ttoky9nHbO0Wy0rB3feO2UhKMCCXh28nlY7dvMYTNACPcMIbX8GdqjtXt2CvnAJ5Hux8S7d9Y+jpnIyLkTvbo97tyH2SRHz2s8T0+Fdihd+J8/C4hZsmpHGNLNjXj12FQHKKlc/BqSDYNT5T0w9sY6gPToXhOtD4yQf5H0UFfn2P7Rr8/1dkxPiDQA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Mar 19, 2023 at 08:29:16PM +0000, Lorenzo Stoakes wrote: > The basis for saying asynchronous was based on Documentation/filesystems/vfs.rst > describing read_iter() as 'possibly asynchronous read with iov_iter as > destination', and read_iter() is what is (now) invoked when accessing > /proc/kcore. > > However I agree this is vague and it is clearer to refer to the fact that we are > now directly writing to user memory and thus wish to avoid spinlocks as we may > need to fault in user memory in doing so. > > Would it be ok for you to go ahead and replace that final paragraph with the > below?:- > > The reason for making this change is to build a basis for vread() to write > to user memory directly via an iterator; as a result we may cause page > faults during which we must not hold a spinlock. Doing this eliminates the > need for a bounce buffer in read_kcore() and thus permits that to be > converted to also use an iterator, as a read_iter() handler. I'd say the purpose of the iterator is to abstract whether we're accessing user memory, kernel memory or a pipe, so I'd suggest: The reason for making this change is to build a basis for vread() to write to memory via an iterator; as a result we may cause page faults during which we must not hold a spinlock. Doing this eliminates the need for a bounce buffer in read_kcore() and thus permits that to be converted to also use an iterator, as a read_iter() handler. I'm still undecided whether this change is really a good thing. I think we have line-of-sight to making vmalloc (and thus kvmalloc) usable from interrupt context, and this destroys that possibility. I wonder if we can't do something like prefaulting the page before taking the spinlock, then use copy_page_to_iter_atomic()