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 04378C6FD18 for ; Wed, 19 Apr 2023 17:07:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5722D6B0071; Wed, 19 Apr 2023 13:07:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 521C36B0072; Wed, 19 Apr 2023 13:07:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E9D9900002; Wed, 19 Apr 2023 13:07:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2F0436B0071 for ; Wed, 19 Apr 2023 13:07:16 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0063FA0373 for ; Wed, 19 Apr 2023 17:07:15 +0000 (UTC) X-FDA: 80698771272.24.0102236 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf22.hostedemail.com (Postfix) with ESMTP id 20D31C0010 for ; Wed, 19 Apr 2023 17:07:13 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=LYzXyeHM; spf=pass (imf22.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.44 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=1681924034; 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=2tMDhyZV3Hgc/Al67mw6uSm3u02DMvYwTng02dpk0J8=; b=pJjUVt/NYgfCsK1EZ2SElCksVXoBwhQgkFj1NsoazVNrLnLMyRH1b50Djq0NBpDziXRWOs ATFT4Vc6hylKfVl72DNH+9vJLJlNhsMRhhaovyi43QaGZuijVqo+0VhWEgGstDqtGWLD4f AK1Jb1TGn+ePE6TxYKhp6RUdxOy7UnQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=LYzXyeHM; spf=pass (imf22.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.44 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=1681924034; a=rsa-sha256; cv=none; b=pmGZWsE05b0o0s2neGwoiibr8gokZ01fCyGxjysvEUk3V32kgD2GbTn4iU3JCLAuTx/qGr KmY3vhx56WHcCJfo9zy2GCPJxLc3hOWZFjqrqlsiHvjSwCz0I+Qwz+F81gjEB6e8MO1uh1 z5c6LNAPMnl5UoWr+OZycdg2tVautAE= Received: by mail-wm1-f44.google.com with SMTP id o29-20020a05600c511d00b003f1739de43cso1785981wms.4 for ; Wed, 19 Apr 2023 10:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681924032; x=1684516032; 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=2tMDhyZV3Hgc/Al67mw6uSm3u02DMvYwTng02dpk0J8=; b=LYzXyeHMRjZkwMpePS/pentjI6XWh5f4bYCE5sfZDJah2PnFG3g1CXYmQHv/bYb8xE UhpPzvuJvjYt/2dTACg7wxe6M9IL11BG7mftuAld3TOiZYIkLQ0asJTRZCsKhcoHqCPG A7lRQnDyeYnk7546nPUG+O0DN7HablK88JncWzd3etJO9Scbb+ssChcBdGa5mG3XVuD3 Hp+LQ/B0ns0onyjPgkPo7vwoaVGn7VKf4U8iBl+CMVuVuFGSNz6TQLuUURJ3yWDJtKMV YkSG6XoyNNP0Nwleo+5JUG4QBfIV1ARU/FQwif5DCJ/KQFVqDR4+Z56h6Tg5jYgPjrn9 nv/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681924032; x=1684516032; 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=2tMDhyZV3Hgc/Al67mw6uSm3u02DMvYwTng02dpk0J8=; b=BiO2wTGkjlWfrHSk8wBzfeH0mSqPoOsvhp29omjpcItI+Kh7B0wbOq/86j7zARhWD5 sAVNg26mNZFNbWM9WpwZNadUwirjWo097TBJSGPyr3oI3cHNS8nRud5RqXYoSuUsmdjR y+RTJ/D1PYCjYhhZMEUdcE2wSvcxYMjT4I96aPGV5ohLMlgjmVnkr6kXDjn2G3yN3VP2 DiGFT3YT3oscOCPOS+b8vXoT6hTVCqwVcuTSwYw8IpKPcsRUo65D5FeKvMfIQJAFW0Ta DQhG4RcVRs4th0HzWbvK3LCDepPU7woBvaxBzVsvEfSrizJPugyIOhVznk1KvVhO+DHm uGNA== X-Gm-Message-State: AAQBX9f5Ig+718+eqY8RFrUxw3+ED+1zuZvhadidv+Du8JoD2dnDreFT JyLNBv8bUIPZ9tbgNiz6bTg= X-Google-Smtp-Source: AKy350axLKbKSQbCVzHP1rMEE17C4ESwiyORCjzaGKv6fd66+tZj9hFbaObtfvAl7K5lZL2gGCbDBQ== X-Received: by 2002:a7b:cb06:0:b0:3f0:9564:f4f6 with SMTP id u6-20020a7bcb06000000b003f09564f4f6mr16578277wmj.1.1681924032437; Wed, 19 Apr 2023 10:07:12 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id z13-20020a5d44cd000000b002e61e002943sm16277742wrr.116.2023.04.19.10.07.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 10:07:11 -0700 (PDT) Date: Wed, 19 Apr 2023 18:07:10 +0100 From: Lorenzo Stoakes To: Jens Axboe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , David Hildenbrand , Pavel Begunkov , io-uring@vger.kernel.org Subject: Re: [PATCH v4 4/6] io_uring: rsrc: avoid use of vmas parameter in pin_user_pages() Message-ID: <82f26c52-bff7-4f54-b5ea-2fe635045e37@lucifer.local> References: <956f4fc2204f23e4c00e9602ded80cb4e7b5df9b.1681831798.git.lstoakes@gmail.com> <936e8f52-00be-6721-cb3e-42338f2ecc2f@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936e8f52-00be-6721-cb3e-42338f2ecc2f@kernel.dk> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 20D31C0010 X-Rspam-User: X-Stat-Signature: igk4373qnht3fy6iszugkqpqm89xn9ys X-HE-Tag: 1681924033-271901 X-HE-Meta: U2FsdGVkX1+7kFNVpd9jq9Lxl5DmEmYjFFYlutKEAEQSlqCzo42B3Eosdgl7eCFjYPGyxL02ow8PMYy9S/R6DSoFAoT+ZZvA6Malerp3S/6pozQJa74AxHe7981bUZAbZ20D+tyNwJoCoaSa+VnQJCZoLGKzksZuJoijcmGsx+bsijmUXEyhGdTUeT4n+dwi9PEh27d9OdGOC4oey7dtEhpNzIEVzY53bXUkZf1jbVGj6kSmXV+UAru6QBek7le2o3Aj5dGgMV9BF2W1FxF77QwgyOAZlFMnogT4YuB9KMhh5b06riEeYtpM6gBTYaDEjPkyP5HSNs43nZ//MpcVOzqWhMmQdPbz5VCTj8HQYio8UViIAPzUO9fWQf1QQtryu4yVHed1bghdJJIVsD+YtC67gQpfLz5NAyWRY9kaWhA3wN8vjWtkzy/DEIU7NMw+kjO5XKnpD2r6UwNe2XPacub7DesYI1bmux98245BXtEY+mGYLp0kNT5vD4Nu9xrT+TkNn6oWp73NhMF2WClA926M361TbwY3q9sM2hWY0/W7/9ODYOFAoRamaIl72CYgToJKlF+8CooliABxRFApPmsfcSdmdrwMSsvUdc+CXUbeMa/iUn3VByy07HcB5pcfErqn+AZM/8G02R0mYMB+NXJMVyvuWxnSfEmheLfQe2UvfWwIsAYkx5O1kSx2OGtBA+j0A6wzckZoRP8NSdBk1h3L0+07seMnIOLasTFE3bSV9rHuHvlc0t/J38TO56xqO+Jh3RS956eoERo89Hg9VIBCKHKym0qnErgcGxEl7IRAhOgC8rDaC6nwUntRMHeiEshS2qJ+KcMxuZcxAtBsnU1wKsVvsvVaSC6lvk+o9BM8yOj23tTyLTLgzNrGn3pOZruGDYHJEyZEgNg5viwJlim+Cmc+u/qgVxqo08C1mjUwUW7/PO3clA2l9gJ239llDHaHFthVkGRbnIlRaP7 IcZH6BwA 8ocWu1Ij4PPaA2dBlv/cGsbKn3wcKWAo6G5ANsEZslK0yGGANRkHqrIkUF5ZRXfNlotomotcPwz/2X3t/AU3LN7E4lyCTXu5FrVj4tlIfyIxZnjGMdIV3Lwcu9EMhvzMKtl1CviGLfOGtkOtwxx9AWpgMHCQekEryzSjB4nAOs/kaWZV2r5hNGxiDwSLTCxbIg28kpUBmbH6L1veofosb8LX+RuqaYpXIyTWbfnGzsnpl0TbYlxc8w9wZvL16B1ytKrrr2wdIhNylDJ/0WFWQHjl6LxZ845xfvZgjNN47QfsLBp6vUlrHrrng58gG+i9n6uxRVlMeSZRykfbx+p6hNRKN3uyvXyvZjlMZvOqusKTgdZAyqDSEZDNjWeBEhtH62777JBmSoF+L9DVyg+hK4AMpJS7FMcVJ3a+JhUrW8ysuOrGaLNDRNuLegvSrfbyoygT2EpXcUbfr8xtRAM5V612Nx2V/Rqz0PXJignRozKi1QS2k7rUKzVQYEGlCEulwhkSUa+sol1Mq9ffRp8AiuAb3jQ== 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 Wed, Apr 19, 2023 at 10:35:12AM -0600, Jens Axboe wrote: > On 4/18/23 9:49?AM, Lorenzo Stoakes wrote: > > We are shortly to remove pin_user_pages(), and instead perform the required > > VMA checks ourselves. In most cases there will be a single VMA so this > > should caues no undue impact on an already slow path. > > > > Doing this eliminates the one instance of vmas being used by > > pin_user_pages(). > > First up, please don't just send single patches from a series. It's > really annoying when you are trying to get the full picture. Just CC the > whole series, so reviews don't have to look it up separately. > Sorry about that, it's hard to strike the right balance between not spamming people and giving appropriate context, different people have different opinions about how best to do this, in retrospect would certainly have been a good idea to include you on all. > So when you're doing a respin for what I'll mention below and the issue > that David found, please don't just show us patch 4+5 of the series. ack > > > diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c > > index 7a43aed8e395..3a927df9d913 100644 > > --- a/io_uring/rsrc.c > > +++ b/io_uring/rsrc.c > > @@ -1138,12 +1138,37 @@ static int io_buffer_account_pin(struct io_ring_ctx *ctx, struct page **pages, > > return ret; > > } > > > > +static int check_vmas_locked(unsigned long addr, unsigned long len) > > +{ > > + struct file *file; > > + VMA_ITERATOR(vmi, current->mm, addr); > > + struct vm_area_struct *vma = vma_next(&vmi); > > + unsigned long end = addr + len; > > + > > + if (WARN_ON_ONCE(!vma)) > > + return -EINVAL; > > + > > + file = vma->vm_file; > > + if (file && !is_file_hugepages(file)) > > + return -EOPNOTSUPP; > > + > > + /* don't support file backed memory */ > > + for_each_vma_range(vmi, vma, end) { > > + if (vma->vm_file != file) > > + return -EINVAL; > > + > > + if (file && !vma_is_shmem(vma)) > > + return -EOPNOTSUPP; > > + } > > + > > + return 0; > > +} > > I really dislike this naming. There's no point to doing locked in the > naming here, it just makes people think it's checking whether the vmas > are locked. Which is not at all what it does. Because what else would we > think, there's nothing else in the name that suggests what it is > actually checking. > > Don't put implied locking in the naming, the way to do that is to do > something ala: > > lockdep_assert_held_read(¤t->mm->mmap_lock); > > though I don't think it's needed here at all, as there's just one caller > and it's clearly inside. You could even just make a comment instead. > > So please rename this to indicate what it's ACTUALLY checking. ack will do! > > -- > Jens Axboe >