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 6EBB8C7618A for ; Sun, 19 Mar 2023 21:18:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B66786B0075; Sun, 19 Mar 2023 17:18:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B16EB6B0078; Sun, 19 Mar 2023 17:18:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DF726B007B; Sun, 19 Mar 2023 17:18:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8D3F06B0075 for ; Sun, 19 Mar 2023 17:18:33 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 45C64A04A9 for ; Sun, 19 Mar 2023 21:18:33 +0000 (UTC) X-FDA: 80586911706.09.05E5718 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by imf24.hostedemail.com (Postfix) with ESMTP id 50BA5180015 for ; Sun, 19 Mar 2023 21:18:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qVhoiiNy; spf=pass (imf24.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679260711; 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=xnsyvP8JbNs+veqAm6StM8UbBoUAPhLOI3XAytwZeZo=; b=EhqBx7goGB5GXLaoFcYZR3HDp0jwdURSPCnSNRRjWY2DfHzner3qnDFxRquY5sqs5IxJal UtCySgKnQVIyDqKa6Z0nMXOAI5BsQ/Y1gLa3HmICx+l2jp7fOGuaCxyvAsWIDG270n13Gm PD9b1aaqKojs+Mc9bKXmlkruG1SxJWk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qVhoiiNy; spf=pass (imf24.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679260711; a=rsa-sha256; cv=none; b=4/crUmA+JJ5ET5l8hTM7rfJJ3e02dweB5VOUzSsgIAMkeE9R+D6/X3T2vB0OApQeOjOo26 mw/ZKw8doySix4Gf+3/kOQ5eEJ7SyNOoxID0TGvvL12qRS4w2eGZZrMx4N9Rv1bhqUiUEs POSoI+35ukxJavMyYaiSDPIYTGSmu2g= Received: by mail-wm1-f53.google.com with SMTP id p13-20020a05600c358d00b003ed346d4522so6368305wmq.2 for ; Sun, 19 Mar 2023 14:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679260710; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xnsyvP8JbNs+veqAm6StM8UbBoUAPhLOI3XAytwZeZo=; b=qVhoiiNy51oSxFQEw23uh1HQRMG+qJploZdK1vaziW+lejF1UsQqj7JzeNQSGMucoo 8XPMnjHtu3XJNkHppDZc6Fo/OfJTmfVkMoy1dMicXzE7vPJamVY1sqJz6jnKoMr7R1ay tHqo7M7cQ372T/zX8ngHz0iCtP8ULEAIJbj1zSze80K6c7hihh2+9vfuEi1TMemZB3G6 C6x++ua1/dDaj9pNMgCunWevzPYKKTUnKs7TGRf0gtRqrhne1NEHo4/95Jt3J7fOYKa+ 0E/D+SGMp0doyEV2wxEr56RRBIiNNzDdraA2CvJwm+ilyy84cXoDezGMUBE7pSngPGN+ 8neg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679260710; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xnsyvP8JbNs+veqAm6StM8UbBoUAPhLOI3XAytwZeZo=; b=aKxSyKWjhNCtN7TeOAmh23mudUUcwbiMQ1pwP8KhFY82nd3XBHeCUJIhEFRurP2VEP Ryk5xHa6AwiPJRxWd9fzaydbVn7AIDVQRmTd4MRx8FfUxvzw8z+dEouJJcxs3sx0o/2t qQ+8kWlh0enwnloprPRq1f/rpZLJNUvfeFoqb4BJ4RpF1eRcsGJQ700NaQrRfoGFqXab 9KOCvPWMpc5RdbINRDzc39tDunlqvRvFpLfsBmUGdJm2LEmGz3ukwvFQXin84uDy1lE5 xfNA9PsEw4o6IsLm0i6cDj4T39Cpj8p+4cUpmu1Zo0sxtjnkDOxuKbfFgD2iKoEWrbTg EwqA== X-Gm-Message-State: AO0yUKWzu0sIGqhqX5VV38YMD+2o471flBKGgxttzimTZVHKymKr0ihP N761wh7dkJBVjo2htdkWjIM= X-Google-Smtp-Source: AK7set/tW/8C0xY/SSAu8Z2l3XOOV0YeweYmNiztltrsp6dMlMz2iIEqWHop066JFj2JpYd1xAM+ng== X-Received: by 2002:a05:600c:2185:b0:3ed:8780:f27b with SMTP id e5-20020a05600c218500b003ed8780f27bmr8062758wme.16.1679260709651; Sun, 19 Mar 2023 14:18:29 -0700 (PDT) Received: from localhost (host86-146-209-214.range86-146.btcentralplus.com. [86.146.209.214]) by smtp.gmail.com with ESMTPSA id h4-20020a05600c350400b003eddf20ed5bsm2477581wmq.18.2023.03.19.14.18.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Mar 2023 14:18:28 -0700 (PDT) Date: Sun, 19 Mar 2023 21:16:18 +0000 From: Lorenzo Stoakes To: Matthew Wilcox 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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 50BA5180015 X-Stat-Signature: cmrn7sjp9na66d9xztcmncshe51qn6zo X-Rspam-User: X-HE-Tag: 1679260711-450430 X-HE-Meta: U2FsdGVkX19keDE5X4I800jK5ihh+jVuej6I9Gfl/FWUU4yNRV4pNbJfKSW1iCXFBL34xe0MvbfVNhjaFu3hpQqzTizXtVUpy/Kjddnxj6i6ck4sdcZnQi3ctiBFlyZSLbvtfbRJzXt2iGKsRg8QGTqK4gB1dqXf98mOzY/Hnzo5IFhh7xFwKBho85LHWpY/TQgv4/JURjmXBiqFlO8FfnicC0R7hIDYinZmKM4rhExb1c9/oOW7Vqwy9+IP7MNS4OYXjSc6Sqyr5UtFcqpO2Pb3+dZr49qtGRQjNVhogSIHB6sLXf2MyzER8Zl7B7vtG8iYey21q9cseB1QRXf9qAEzeFKs+Z8edCZekW+5uzZvslYViO5GClE4lRRRx8EdMqvP2U65WZ0Zgkx0NFxTzn5bNWKTgo7bh9D5MER/CjI1dNG3yXZV/vN7vQCWDefKFyvlQiCX29f+XVXE5lEIAQmCYsYVJgDMF2h4wV3RdsRd65olp1omYHgr6leS4JB2VHQ48+jNgxf+xAhm2hb4KzmXYJPztusn/njpg5pvFCVnCwyjZLUzJOMhKKOaD5Pve2svzrgy2eEmXMgtlmC0zhnm+AunjiNXL+KmWTIvCh+e0XF4//rEn5hvpiFwMZ1Pgr62dWPVKZaKTQeghBuNyzKrLM5KCSKNi9N2gn2Fvw00R2u5+z5yHhAMRYBbHIVtN4A/573h/ujsgb15t6hoxe9JfrFJOF5ID0RE4zRo2c+Qmv7h5j9QbBjRnC1k/ceOi+oM/PBri5H2InYgWA7I5wpJtnqLISAo2xluQ2yYm/SfbiuP3xs9QS0SNvnAM3FLMKDX1sWm6G2HRVeCG/p6p3kzOERtQ7wnYw+SDVqs+B20696u7PSPgbstCWc7LqB83osUYvamgnVfqO9/+1o1+1N+naMIWIkrz045kbNp9jaMt/X0INVVRph/wUxQ67wP7vWqvyJJrSsdhDJ2MyX y2uMaHXj S++C/M0F+jfTajNZ/afD/j0k12X0Y1Cfefakg/IyT2IBnvHb9cyGAj+Xv9u7dugpceHwnoLN/NaLmvm0O4TlhjcW9lxDZ6k6ruIV84QiFrGlrteRak01TJoFl3ERUH6LDAe+tPcr0d4Zud2W70s9PYn16V/ByBfEHxr3U/tIclG0zwNu3405/nVRrIQbMiHOm7aDzrXe8zpGbRR2PVPkeJvTI3fMYAgEloeHC2nSIdUPvd5u6ctmx8nOJE+GIC0CKp/caQjZGr8UhxhdiKYjf+yoj5O8fbnxVDUrLQUqJqxABP3pAYNMP36QMXLvePcqFbzOWkyuNlkJVgF2SDj93UBToWd+L/q7bRFfwgS6e2pM5i2wFMUPPlsRS+owgx87VLMwhcAEvVsgoZybfVthoUYO04AgXXBZJqYwaZITdCu5JHtfa9NLwXtmcSM0wLDyTshMJYcIGspoVjhA= 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:47:14PM +0000, Matthew Wilcox wrote: > 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. > Thanks, sorry I missed the detail about iterators abstacting the three different targets there, that is definitely better! > 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() There are a number of aspects of vmalloc that are not atomic-safe, e.g. alloc_vmap_area() and vmap_range_noflush() are designated might_sleep(), equally vfree(). So I feel that making it safe for atomic context requires a bit more of a general rework. Given we would be able to revisit lock types at the point we do that (something that would fit very solidly into the context of any such change), and given that this patch series establishes that we use an iterator, I think it is useful to keep this as-is as defer that change until later.