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 4BFD1C3DA4A for ; Mon, 29 Jul 2024 06:05:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D82396B00A2; Mon, 29 Jul 2024 02:05:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D32946B00A3; Mon, 29 Jul 2024 02:05:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD3076B00A4; Mon, 29 Jul 2024 02:05:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9EE9C6B00A2 for ; Mon, 29 Jul 2024 02:05:54 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1743C120110 for ; Mon, 29 Jul 2024 06:05:54 +0000 (UTC) X-FDA: 82391754228.09.3715465 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf24.hostedemail.com (Postfix) with ESMTP id 1F95D180007 for ; Mon, 29 Jul 2024 06:05:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CTO71h0I; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722233125; a=rsa-sha256; cv=none; b=Ge+EvXm0N9+tnrcVitsTSpwTVrh/Kys+ngMPDuckURgURPhHoK2J3YRmlK1DovTlVNiKV6 S3+VaYmuVwlR6X6XcFKvr1c7yf1wFxEXZhKZgoycgqzsu1xF8dAkcH95PeXS51/E5aJQ3l y3FE/IiFU076tUhkknLCtP83Fe0fhic= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CTO71h0I; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=21cnbao@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=1722233125; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eT3+lq1z1ZjHF+rQzFZqGRDbKroE3rXEn1/7JfMa1Lw=; b=k7/+0TBG+oW926eW6BeJeyrf2dKRPLH7UVFwM9SohwVXIMnPUfC1V2GwhKVoHzI9W9UN0g 558sCKPqQalsVHaS7FS6rXN+TlB3pxrFKLKJvLXKbtxO7sxC4U73toSEvFqNKG4QzRzESD kZtV/QZC/1Vgj6Lu4PBpFpi6hSbxEfA= Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-7a1be7b7bb5so2078986a12.0 for ; Sun, 28 Jul 2024 23:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722233151; x=1722837951; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=eT3+lq1z1ZjHF+rQzFZqGRDbKroE3rXEn1/7JfMa1Lw=; b=CTO71h0Ihi9CPEIA8CejqDctqRMfv2TrbD0eElY8LQ9xJUhOeembqDv0V+Q5stRFo4 Z20pQCTpzJB63imJypVOsaeJyLC0a5GJe5R/f42pshUJXbFR+H4Ud/qNX4gRQhjRNJNe CVEvv9onBfMJrn+RM54y/p4lwpavZaMJ/+ZVlabfnUX8FsMu+x44IZXBLZ1iCSgF4D0W kszFAJlIaauANsiv2MAADvkG7AT1MGwbax9MqLvHIqPk9UwZszQnCSlOYj5tM9NffKdq eTKBiAiOzA8u/L1mBYDhqWTgOe4I2rs2gNBj2Jhe8q/2lJS9MIE0xEO0UNzl6bten6dq B/oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722233151; x=1722837951; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eT3+lq1z1ZjHF+rQzFZqGRDbKroE3rXEn1/7JfMa1Lw=; b=ktyIBNo5eSJTZDLeUAwottuTf0nWm23svQ2XZLAUVFl1sEu4ZN0EB/S3PwbbvVFLKO 9bVNnnH00WwkcOp/qIYSbFStrMQhd9bII4ai3rs9Pn2FqLbP6YWMSQdUvf8K7ohK2u6P SKjJk0CuZ347gFYXhkFIwS6VZdzGGke8ATh9NF8cNkUld1hJxCqG+IL92/c7BeJsJzLW 10ZMMfMSB9zJIIBVFuXR7cZmdCbdQuFO/TSTKYdC7CbUB4gyQAiba8x0MpUmeJZz3cJz Rq30HQVvZDErzmR9up9rAT50czd3mgST0Bq2XI1ezFaQxq2iHGBlO1S60LvLnGz1C6Xw 0YpQ== X-Forwarded-Encrypted: i=1; AJvYcCXAynD428Tmluhxz/4fV9paZxPpaw83CcSGQDuVnU1bNTJOPPIPP2SNofunDPSfEj0n5X4ODe+gV2eI9UOyP0f1d84= X-Gm-Message-State: AOJu0YxlJoHkJ1k88Tk0Yrp8s9xOS75gw70EJS7cpSGB7qrIhjL4ZVi0 o7a3SYTUXTMgxhyaOczCCtw1QoF4zI9ZpV1aN2iia8eBpOA7Zc+ImHDXefsw X-Google-Smtp-Source: AGHT+IEdEQUKUD1f/Ydw97yQv/cLZoGHfR7AP2bCzE4mGmm+B40OT2kvmDxGJpFvjolmsy7BX38Y3Q== X-Received: by 2002:a17:90a:ae17:b0:2cf:28c1:4cc2 with SMTP id 98e67ed59e1d1-2cf7e1ac75cmr8202569a91.3.1722233150582; Sun, 28 Jul 2024 23:05:50 -0700 (PDT) Received: from localhost.localdomain ([2407:7000:8942:5500:aaa1:59ff:fe57:eb97]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2cdb75de01dsm9612607a91.36.2024.07.28.23.05.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jul 2024 23:05:50 -0700 (PDT) From: Barry Song <21cnbao@gmail.com> To: jasowang@redhat.com Cc: 21cnbao@gmail.com, 42.hyeyoo@gmail.com, akpm@linux-foundation.org, cl@linux.com, eperezma@redhat.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, linux-mm@kvack.org, lstoakes@gmail.com, maxime.coquelin@redhat.com, mhocko@suse.com, mst@redhat.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, xuanzhuo@linux.alibaba.com Subject: Re: [PATCH RFC 1/5] vpda: try to fix the potential crash due to misusing __GFP_NOFAIL Date: Mon, 29 Jul 2024 18:05:29 +1200 Message-Id: <20240729060529.93243-1-21cnbao@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: 4g9r6sartpadhd9yw4m4tfa1t4b7atgt X-Rspamd-Queue-Id: 1F95D180007 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722233151-611492 X-HE-Meta: U2FsdGVkX18aX9YzgcTEYRozrlfV8mbPH22opc/474huJ2WDx6noIkpK6LWTAjqv/IbZ79KRRthtdaXrhUsJcHZMEFW8olbuDl4H5luTriuyX4PrgleZzhB+zwO7uNLcAk7UWIkngX3KyHKfvuNuhxzrkdYiPnO2QIMsmgnPoJ9M1+iYxAp10oGA25pVhUda3fFDENRHP4p9rKiB3oa+31wZNmgnZ9BAN44AJk5748Muy+eamwDUXUIcoDgO5TGwvAWvuXrqY8l1jYh5dHAipX2+YkmjkihUAdwnSeaFwWGGxwqzYlc6I0Z3JHEBDTakDGMfeFdfArR//8eD6uM+eLjyC6UlSy+Z3JxyTz4ZjKOOd+5vWhUvucei697nCwPxgUHeyM5Iq1se/ql+jMeBB7CtA9CgT7ZNKukomPxZhjdQPJlFjXoJqgyuaoOYcAJSviSMgwP7nHc102kraicX9VQhXs4CfWiUsEqZV8FQkVuDeJJNPlVMHe+4reMR+MWf/IlSqvkkkgoZtOqn2XowAbBZL0/3URKv4ulK9dmHrY4FBtcP7+cXTUes1E/mn7pp9gFLlK/p8iC1w5oy6Val+dt/mfrA5E3Y76d9BRLogJMQtfGluHHpem8lv1ytSd3BtY56D3ssVEbTJ5X8Po+9K1uGax87hrIpi/59atjxpV5+F3PO6EgCoao7KI8IKwx8cump8SGipsYCDRix3ioj7eQH3sg4iokXG2CrDYyBO76GIakjs9NVTvZBnUzDS68yVj3BBNPMm/gbXxSdNSUuz06dWVSAzMHNlvVW4FxmmOEyUEyIZtq1o4NvE6viAMOvAXFTCNQRdIZ209zg0MC1QJNkjJ3mHYUli1DFQljJHAaIvvzG+//vgyFNCFxrZyxn2imH4b3elR1xyFcmHqC0rhOOi8Tl1VJ2fyc/OraOjnR6IBRmmNifJB19kBY4iV6Goi6CMahB0T2Pm6MZuEQ Cmop/n1s y9J/0rm9nxuUTqxhdnTU1wQ8bxYRzRL2og+COeylEI5u5JL9sbMpajc3x/vaORQSt9i1naXKyLNXGAsVodGWb/tvwp3wgkAqceeULhP7Ce7FQ25IeG0rZeVgW2GkGXeefe9DKRtarEdi9IbVYLQE/oP0duhbe6ZnI1hT+b0DQIgWeU79MYb1DpzSf6y3jTNUKK4qoQKCBVLtxR66vwmUwcJ+R1Gvkqqlo6ts3/+1SYrCtySL1y/KVwmDamPqJF4NA3gQqwiu10goVk0XCwVyWsWQbmnKHYoeD90rcUj0fmLAOQ/IjWMWW3zSer+h5w7fVajLUWFudIzBeaXN1u4EoZk/fQimJwGOHWuxX6i0A98RxcZrcu+vionMOZTKoWe+5Wi/V2v6ScNgfnoP6uR9CMPwp+oSRbJDOH0WhYOmZddCXhBL+pMWb/z+hOWxuUl7CeuHnL1szRO5efPP1/UfFvTdb32FXNlnD9JAYSfoymtmyWTDy9OnVEAVaxTR/EfW9y2380MyQr1FT03JIRa/FUfi4vbu+bOwlaGfmUSt49hEzorOEq9QVQ01DdZyCuSw89eVN6BRNFLYa+GzINkRov6M9Uye9Gh/89ryIvs4QBcY6l6KKxb2YOuP2Cv4DXfBkTeVXB2AuyKEnSdAXDOkPJmQc1XjaDwmVsNNqArucgW/8p8vtngKYm/I9wrEpYJZ93vZwCCX6rq32yh0= 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: List-Subscribe: List-Unsubscribe: On Mon, Jul 29, 2024 at 3:42 PM Jason Wang wrote: > > On Thu, Jul 25, 2024 at 3:00 PM Barry Song <21cnbao@gmail.com> wrote: > > > > On Thu, Jul 25, 2024 at 6:08 PM Michal Hocko wrote: > > > > > > On Thu 25-07-24 10:50:45, Barry Song wrote: > > > > On Thu, Jul 25, 2024 at 12:27 AM Michal Hocko wrote: > > > > > > > > > > On Wed 24-07-24 20:55:40, Barry Song wrote: > > > [...] > > > > > > diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c > > > > > > index 791d38d6284c..eff700e5f7a2 100644 > > > > > > --- a/drivers/vdpa/vdpa_user/iova_domain.c > > > > > > +++ b/drivers/vdpa/vdpa_user/iova_domain.c > > > > > > @@ -287,28 +287,44 @@ void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain) > > > > > > { > > > > > > struct vduse_bounce_map *map; > > > > > > unsigned long i, count; > > > > > > + struct page **pages = NULL; > > > > > > > > > > > > write_lock(&domain->bounce_lock); > > > > > > if (!domain->user_bounce_pages) > > > > > > goto out; > > > > > > - > > > > > > count = domain->bounce_size >> PAGE_SHIFT; > > > > > > + write_unlock(&domain->bounce_lock); > > > > > > + > > > > > > + pages = kmalloc_array(count, sizeof(*pages), GFP_KERNEL | __GFP_NOFAIL); > > > > > > + for (i = 0; i < count; i++) > > > > > > + pages[i] = alloc_page(GFP_KERNEL | __GFP_NOFAIL); > > > > > > > > > > AFAICS vduse_domain_release calls this function with > > > > > spin_lock(&domain->iotlb_lock) so dropping &domain->bounce_lock is not > > > > > sufficient. > > > > > > > > yes. this is true: > > > > > > > > static int vduse_domain_release(struct inode *inode, struct file *file) > > > > { > > > > struct vduse_iova_domain *domain = file->private_data; > > > > > > > > spin_lock(&domain->iotlb_lock); > > > > vduse_iotlb_del_range(domain, 0, ULLONG_MAX); > > > > vduse_domain_remove_user_bounce_pages(domain); > > > > vduse_domain_free_kernel_bounce_pages(domain); > > > > spin_unlock(&domain->iotlb_lock); > > > > put_iova_domain(&domain->stream_iovad); > > > > put_iova_domain(&domain->consistent_iovad); > > > > vhost_iotlb_free(domain->iotlb); > > > > vfree(domain->bounce_maps); > > > > kfree(domain); > > > > > > > > return 0; > > > > } > > > > > > > > This is quite a pain. I admit I don't have knowledge of this driver, and I don't > > > > think it's safe to release two locks and then reacquire them. The situation is > > > > rather complex. Therefore, I would prefer if the VDPA maintainers could > > > > take the lead in implementing a proper fix. > > > > > > Would it be possible to move all that work to a deferred context? > > > > My understanding is that we need to be aware of both the iotlb_lock and > > bounce_lock to implement the correct changes. As long as we still need > > to acquire these two locks in a deferred context, there doesn't seem to > > be any difference. > > > > I can do the memory pre-allocation before spin_lock(&domain->iotlb_lock), > > but I have no knowledge whether the "count" will change after I make > > the preallocation. > > > > diff --git a/drivers/vdpa/vdpa_user/iova_domain.c > > b/drivers/vdpa/vdpa_user/iova_domain.c > > index 791d38d6284c..7ec87ef33d42 100644 > > --- a/drivers/vdpa/vdpa_user/iova_domain.c > > +++ b/drivers/vdpa/vdpa_user/iova_domain.c > > @@ -544,9 +544,12 @@ static int vduse_domain_release(struct inode > > *inode, struct file *file) > > { > > struct vduse_iova_domain *domain = file->private_data; > > > > + struct page **pages; > > + spin_lock(&domain->iotlb_lock); maybe also + bounce_lock? > > + count = domain->bounce_size >> PAGE_SHIFT; > > + spin_unlock(&domain->iotlb_lock); > > We probably don't need any lock here as bounce_size won't be changed . > > > + > > + preallocate_count_pages(pages, count); > > + > > .... > > spin_lock(&domain->iotlb_lock); > > vduse_iotlb_del_range(domain, 0, ULLONG_MAX); > > - vduse_domain_remove_user_bounce_pages(domain); > > + vduse_domain_remove_user_bounce_pages(domain, pages); > > vduse_domain_free_kernel_bounce_pages(domain); > > spin_unlock(&domain->iotlb_lock); > > put_iova_domain(&domain->stream_iovad); > > This seems to work. Thanks, Jason. I personally have no knowledge of vDPA. Could you please help review and test the patch below? >From 1f3cae091159bfcaffdb4a999a4a8e37db2eacf1 Mon Sep 17 00:00:00 2001 From: Barry Song Date: Wed, 24 Jul 2024 20:55:40 +1200 Subject: [PATCH RFC v2] vpda: try to fix the potential crash due to misusing __GFP_NOFAIL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit mm doesn't support non-blockable __GFP_NOFAIL allocation. Because __GFP_NOFAIL without direct reclamation may just result in a busy loop within non-sleepable contexts. static inline struct page * __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, struct alloc_context *ac) { ... /* * Make sure that __GFP_NOFAIL request doesn't leak out and make sure * we always retry */ if (gfp_mask & __GFP_NOFAIL) { /* * All existing users of the __GFP_NOFAIL are blockable, so warn * of any new users that actually require GFP_NOWAIT */ if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) goto fail; ... } ... fail: warn_alloc(gfp_mask, ac->nodemask, "page allocation failure: order:%u", order); got_pg: return page; } Let's move the memory allocation out of the atomic context and use the normal sleepable context to get pages. [RFC]: This has only been compile-tested; I'd prefer if the VDPA maintainers handles it. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Xuan Zhuo Cc: "Eugenio Pérez" Cc: Maxime Coquelin Signed-off-by: Barry Song --- drivers/vdpa/vdpa_user/iova_domain.c | 21 ++++++++++++++++----- drivers/vdpa/vdpa_user/iova_domain.h | 3 ++- drivers/vdpa/vdpa_user/vduse_dev.c | 13 ++++++++++++- 3 files changed, 30 insertions(+), 7 deletions(-) diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c index 791d38d6284c..014809ac2b7c 100644 --- a/drivers/vdpa/vdpa_user/iova_domain.c +++ b/drivers/vdpa/vdpa_user/iova_domain.c @@ -283,7 +283,7 @@ int vduse_domain_add_user_bounce_pages(struct vduse_iova_domain *domain, return ret; } -void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain) +void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain, struct page **pages) { struct vduse_bounce_map *map; unsigned long i, count; @@ -294,15 +294,16 @@ void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain) count = domain->bounce_size >> PAGE_SHIFT; for (i = 0; i < count; i++) { - struct page *page = NULL; + struct page *page = pages[i]; map = &domain->bounce_maps[i]; - if (WARN_ON(!map->bounce_page)) + if (WARN_ON(!map->bounce_page)) { + put_page(page); continue; + } /* Copy user page to kernel page if it's in use */ if (map->orig_phys != INVALID_PHYS_ADDR) { - page = alloc_page(GFP_ATOMIC | __GFP_NOFAIL); memcpy_from_page(page_address(page), map->bounce_page, 0, PAGE_SIZE); } @@ -543,10 +544,19 @@ static int vduse_domain_mmap(struct file *file, struct vm_area_struct *vma) static int vduse_domain_release(struct inode *inode, struct file *file) { struct vduse_iova_domain *domain = file->private_data; + struct page **pages = NULL; + unsigned long count, i; + + if (domain->user_bounce_pages) { + count = domain->bounce_size >> PAGE_SHIFT; + pages = kmalloc_array(count, sizeof(*pages), GFP_KERNEL | __GFP_NOFAIL); + for (i = 0; i < count; i++) + pages[i] = alloc_page(GFP_KERNEL | __GFP_NOFAIL); + } spin_lock(&domain->iotlb_lock); vduse_iotlb_del_range(domain, 0, ULLONG_MAX); - vduse_domain_remove_user_bounce_pages(domain); + vduse_domain_remove_user_bounce_pages(domain, pages); vduse_domain_free_kernel_bounce_pages(domain); spin_unlock(&domain->iotlb_lock); put_iova_domain(&domain->stream_iovad); @@ -554,6 +564,7 @@ static int vduse_domain_release(struct inode *inode, struct file *file) vhost_iotlb_free(domain->iotlb); vfree(domain->bounce_maps); kfree(domain); + kfree(pages); return 0; } diff --git a/drivers/vdpa/vdpa_user/iova_domain.h b/drivers/vdpa/vdpa_user/iova_domain.h index f92f22a7267d..db0b793d86db 100644 --- a/drivers/vdpa/vdpa_user/iova_domain.h +++ b/drivers/vdpa/vdpa_user/iova_domain.h @@ -74,7 +74,8 @@ void vduse_domain_reset_bounce_map(struct vduse_iova_domain *domain); int vduse_domain_add_user_bounce_pages(struct vduse_iova_domain *domain, struct page **pages, int count); -void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain); +void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain, + struct page **pages); void vduse_domain_destroy(struct vduse_iova_domain *domain); diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c index 7ae99691efdf..df7c1b6f1350 100644 --- a/drivers/vdpa/vdpa_user/vduse_dev.c +++ b/drivers/vdpa/vdpa_user/vduse_dev.c @@ -1030,6 +1030,8 @@ static int vduse_dev_queue_irq_work(struct vduse_dev *dev, static int vduse_dev_dereg_umem(struct vduse_dev *dev, u64 iova, u64 size) { + struct page **pages = NULL; + unsigned long count, i; int ret; mutex_lock(&dev->mem_lock); @@ -1044,13 +1046,22 @@ static int vduse_dev_dereg_umem(struct vduse_dev *dev, if (dev->umem->iova != iova || size != dev->domain->bounce_size) goto unlock; - vduse_domain_remove_user_bounce_pages(dev->domain); + if (dev->domain->user_bounce_pages) { + count = dev->domain->bounce_size >> PAGE_SHIFT; + pages = kmalloc_array(count, sizeof(*pages), + GFP_KERNEL | __GFP_NOFAIL); + for (i = 0; i < count; i++) + pages[i] = alloc_page(GFP_KERNEL | __GFP_NOFAIL); + } + + vduse_domain_remove_user_bounce_pages(dev->domain, pages); unpin_user_pages_dirty_lock(dev->umem->pages, dev->umem->npages, true); atomic64_sub(dev->umem->npages, &dev->umem->mm->pinned_vm); mmdrop(dev->umem->mm); vfree(dev->umem->pages); kfree(dev->umem); + kfree(pages); dev->umem = NULL; ret = 0; unlock: -- 2.34.1 > > Thanks > > > > > > > > -- > > > Michal Hocko > > > SUSE Labs > > Thanks Barry