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 8492BC7115C for ; Fri, 20 Jun 2025 14:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 242C56B0095; Fri, 20 Jun 2025 10:32:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 212B36B0096; Fri, 20 Jun 2025 10:32:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1020A6B0098; Fri, 20 Jun 2025 10:32:54 -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 F126A6B0095 for ; Fri, 20 Jun 2025 10:32:53 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A843A58F5E for ; Fri, 20 Jun 2025 14:32:53 +0000 (UTC) X-FDA: 83576020626.04.15F1B4D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf02.hostedemail.com (Postfix) with ESMTP id 4E6FC8000B for ; Fri, 20 Jun 2025 14:32:51 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ztKpN6GB; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=kj9XM2l2; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="UIEgGh/n"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="aStaRjd/"; spf=pass (imf02.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750429971; 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=6E5rNSmzsJbLyKsIseYuITu6Ey5hvk/Ibrtzg16pIB0=; b=fWUQQupmlL2rKU+sq7KLYJ7LLsebra5SGzJAi5L0cUhxGD/nAawO2CwIHwaYVxS9ks9bc2 ZGYXJ2XdNiu4UdmK359gf6Q9UCFPPuKJZSXp/mUhoqC2fsN+ej1VnemY4IMpUe8ukRcjpT yxdkmFEBRA/UPV3TGDdt4NGGBv/7JwA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750429971; a=rsa-sha256; cv=none; b=pNNQM7wk+O+xrBBTRNN6MEnPg8i20FKYgUKGhyqnvJn7mANefvDlppdARNMHyTMSmyIB8e GGw/mAn6uBRVGxTR0R2DS1hE3pYgVqbAZe5bPEDUtzCkLagVUXddafpJBshmoRPgV6t8j9 FmjpnTy2AnbADPOLSP9rrqejd4FPQTc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ztKpN6GB; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=kj9XM2l2; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="UIEgGh/n"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="aStaRjd/"; spf=pass (imf02.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E8FF821194; Fri, 20 Jun 2025 14:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1750429970; h=from:from:reply-to: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:autocrypt:autocrypt; bh=6E5rNSmzsJbLyKsIseYuITu6Ey5hvk/Ibrtzg16pIB0=; b=ztKpN6GB/DbKyv/XNDSbsqJ2SraLdAiabqVDqf0ct0ZEgzeecIx/G7bCsZ03e0/0nfsmym p7HOAHO+AVwxjfVu8Dxg7+EgcY1J+AZcr+Zw4mbcXap4bt9F2OcXa9gE6LxrS4aEr8Z+md 5lgeOZ7vzWT6gRcRaDxjHApgycaJV1c= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1750429970; h=from:from:reply-to: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:autocrypt:autocrypt; bh=6E5rNSmzsJbLyKsIseYuITu6Ey5hvk/Ibrtzg16pIB0=; b=kj9XM2l2rqOyxG/al4Q6POfaDA+e52UTSDLbYRNPDWJoQyowB98hYmpMLJJHGZvKUfBT3O QY1noWv6+cx9FMDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1750429968; h=from:from:reply-to: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:autocrypt:autocrypt; bh=6E5rNSmzsJbLyKsIseYuITu6Ey5hvk/Ibrtzg16pIB0=; b=UIEgGh/nHufbhd1IqkdmVFtlg6KrFh3vMwIhOajWcw0IecGOfsCjnXxgc/22ecI1N3X72k MKxEv9NnXHPkygWh67MVASohhWkKa32WqFeD3sELVvhqpu2gnLLJFcYtWdZ/XrQNox5huM hqnBfqKma+7UCrcCmPr0+fABQKr6ppY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1750429968; h=from:from:reply-to: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:autocrypt:autocrypt; bh=6E5rNSmzsJbLyKsIseYuITu6Ey5hvk/Ibrtzg16pIB0=; b=aStaRjd/e6LC5VbVJt1hSnmCaWNQMwvICzggY4XCg+9JXCqiIwDMKvQB+HhlvyEbN9xjAZ DJbIlt2vKNBuwcCA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CA774136BA; Fri, 20 Jun 2025 14:32:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 7bwSMRBxVWjwTgAAD6G6ig (envelope-from ); Fri, 20 Jun 2025 14:32:48 +0000 Message-ID: <117f730b-6107-4093-afd2-51c15e503cda@suse.cz> Date: Fri, 20 Jun 2025 16:32:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] mm/madvise: thread all madvise state through madv_behavior Content-Language: en-US To: Lorenzo Stoakes , Andrew Morton Cc: David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Lance Yang , SeongJae Park , Suren Baghdasaryan References: From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJnyBr8BQka0IFQAAoJECJPp+fMgqZkqmMQ AIbGN95ptUMUvo6aAdhxaOCHXp1DfIBuIOK/zpx8ylY4pOwu3GRe4dQ8u4XS9gaZ96Gj4bC+ jwWcSmn+TjtKW3rH1dRKopvC07tSJIGGVyw7ieV/5cbFffA8NL0ILowzVg8w1ipnz1VTkWDr 2zcfslxJsJ6vhXw5/npcY0ldeC1E8f6UUoa4eyoskd70vO0wOAoGd02ZkJoox3F5ODM0kjHu Y97VLOa3GG66lh+ZEelVZEujHfKceCw9G3PMvEzyLFbXvSOigZQMdKzQ8D/OChwqig8wFBmV QCPS4yDdmZP3oeDHRjJ9jvMUKoYODiNKsl2F+xXwyRM2qoKRqFlhCn4usVd1+wmv9iLV8nPs 2Db1ZIa49fJet3Sk3PN4bV1rAPuWvtbuTBN39Q/6MgkLTYHb84HyFKw14Rqe5YorrBLbF3rl M51Dpf6Egu1yTJDHCTEwePWug4XI11FT8lK0LNnHNpbhTCYRjX73iWOnFraJNcURld1jL1nV r/LRD+/e2gNtSTPK0Qkon6HcOBZnxRoqtazTU6YQRmGlT0v+rukj/cn5sToYibWLn+RoV1CE Qj6tApOiHBkpEsCzHGu+iDQ1WT0Idtdynst738f/uCeCMkdRu4WMZjteQaqvARFwCy3P/jpK uvzMtves5HvZw33ZwOtMCgbpce00DaET4y/UzsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZ8gcVAUJFhTonwAKCRAiT6fnzIKmZLY8D/9uo3Ut9yi2YCuASWxr7QQZ lJCViArjymbxYB5NdOeC50/0gnhK4pgdHlE2MdwF6o34x7TPFGpjNFvycZqccSQPJ/gibwNA zx3q9vJT4Vw+YbiyS53iSBLXMweeVV1Jd9IjAoL+EqB0cbxoFXvnjkvP1foiiF5r73jCd4PR rD+GoX5BZ7AZmFYmuJYBm28STM2NA6LhT0X+2su16f/HtummENKcMwom0hNu3MBNPUOrujtW khQrWcJNAAsy4yMoJ2Lw51T/5X5Hc7jQ9da9fyqu+phqlVtn70qpPvgWy4HRhr25fCAEXZDp xG4RNmTm+pqorHOqhBkI7wA7P/nyPo7ZEc3L+ZkQ37u0nlOyrjbNUniPGxPxv1imVq8IyycG AN5FaFxtiELK22gvudghLJaDiRBhn8/AhXc642/Z/yIpizE2xG4KU4AXzb6C+o7LX/WmmsWP Ly6jamSg6tvrdo4/e87lUedEqCtrp2o1xpn5zongf6cQkaLZKQcBQnPmgHO5OG8+50u88D9I rywqgzTUhHFKKF6/9L/lYtrNcHU8Z6Y4Ju/MLUiNYkmtrGIMnkjKCiRqlRrZE/v5YFHbayRD dJKXobXTtCBYpLJM4ZYRpGZXne/FAtWNe4KbNJJqxMvrTOrnIatPj8NhBVI0RSJRsbilh6TE m6M14QORSWTLRg== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4E6FC8000B X-Stat-Signature: sdyux1y4wd6nr8di85nryonzfxhwgdbg X-Rspam-User: X-HE-Tag: 1750429971-600744 X-HE-Meta: U2FsdGVkX1/q42BcQlIoMzQravClpLJ+XS77g4LnZZJVLcTJRBfQrCi4Q/gseTyAspyH9Z/IOJ+A8+p3iEIE35STnVB2IOngVQTMZyN1HEqzFSleFY1urh6229zvkkuD25olce5/jLjfknmjChc7qoHwr6qm9gw1LGO/lwj1ldShNs9xxayHJQwTYU8jKnqzH5ikVOHSjDd7FfOOoymw1wKqB2WBpoiBjCFa+xPWYZQY/tpYglXahrjw3YOGTaT+CaMykWYUb8ocQf+IH9TfsF1+EPgjjjiDSjxUFkMcXWwnuHf3kA71eXwrx4AK112c0xiZPceyXy/55VcIOPDNcrM/YJ1skEh9S6jnW5ByK0+tyYNM55xmPugFrRc7KBurObR8iv1ojjJkZsxE4uQ4uMfQGVXdd7hCvsmhwU30CILqBoxM5aWR2HjcWZSjGQ9eGS68EdZn2Rezv+H5dWsuO9nbcAnV/pcftB+UatirtgtL1gJKMxSwMzcWWj1A9/eJJ3xIpm0tzFCUpeYMgDi+sUVB5THZlaWKM1SGTXdKs59B6XxNgtDjAm9qtibTjnzaCX7/s58dWx8JicNtx10KiaqCHnjGgM20yc1pv287L8maIEBL7hmTRPR3hBwhNRZl8d1HZrmOvZL8K7c3B1nw1AXpxWU+nDDeqgbAhuPe0j0lK5W2TZ4rwoRmOg4QqYUi1apBTzuGRsS7R/3EqdcPYOODdR5AHqn8DhTqJg7rJgZuBkU4WyNBNmzySahHZK0J36Hp4Rd7/3Jmn5+VnaVnE8XpRlXiwYyCPB01+ItqNy28gSird5IrOK/5YoXrFHQjdMOeY5CdjeOkJpKBz5fXpNftHWJlveW7fosy7/r3dXE03STNWBANnHc2l3C+e1fG8fBx4AxPlf33o4sPUiBFjbg/xEabiwQGdF0Uv7HmJVPGKvApdBuGw2pZqhF6/axXnb7mELugeQtJX7vmx44 l/Exuu4F zmwQU9ptLDOk8b2eKDLnbL7F2nwc6VJml+wcE04iB9iiB/s4g3HcVAyM0q59yFfZt6dCzEpIr4AGbqWJmhm8lDu/g6iukuw6llUPquQvm3aO84XcJSoZP1cnJKDUfVDKJxkaG2lmsRyQtZ5kXD3IVLudRtBPKHrKaBs6BGFVA/fKgsAyJ6xRoKQjB2RvXBNTNT6PZhs8riBB58z7uT49g7DT3GqqLkQSBjl7KKWWfFVt1fDB1bDQ9tY2hATWo5lpjCOnqsNU4L/K+OLxyZAAvtgzYKFGicwbOVgdwB7khKJrNZNUffe95reVWz7yIOCOlZLfCBCdMMebsEEvaj/TKx7CvpRQPBS8mkTULNzBJhpPo7nc= 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 6/19/25 22:26, Lorenzo Stoakes wrote: > Doing so means we can get rid of all the weird struct vm_area_struct **prev > stuff, everything becomes consistent and in future if we want to make > change to behaviour there's a single place where all relevant state is > stored. > > This also allows us to update try_vma_read_lock() to be a little more > succinct and set up state for us, as well as cleaning up > madvise_update_vma(). > > We also update the debug assertion prior to madvise_update_vma() to assert > that this is a write operation as correctly pointed out by Barry in the > relevant thread. > > We can't reasonably update the madvise functions that live outside of > mm/madvise.c so we leave those as-is. > > Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka The prev manipulation is indeed confusing, looking forward to the next patch... Nits: > --- > mm/madvise.c | 283 ++++++++++++++++++++++++++------------------------- > 1 file changed, 146 insertions(+), 137 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index 6faa38b92111..86fe04aa7c88 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -74,6 +74,8 @@ struct madvise_behavior { > * traversing multiple VMAs, this is updated for each. > */ > struct madvise_behavior_range range; > + /* The VMA and VMA preceding it (if applicable) currently targeted. */ > + struct vm_area_struct *prev, *vma; Would also do separate lines here. > -static long madvise_dontneed_free(struct vm_area_struct *vma, > - struct vm_area_struct **prev, > - unsigned long start, unsigned long end, > - struct madvise_behavior *madv_behavior) > +static long madvise_dontneed_free(struct madvise_behavior *madv_behavior) > { > + struct mm_struct *mm = madv_behavior->mm; > + struct madvise_behavior_range *range = &madv_behavior->range; > int behavior = madv_behavior->behavior; > - struct mm_struct *mm = vma->vm_mm; > > - *prev = vma; > - if (!madvise_dontneed_free_valid_vma(vma, start, &end, behavior)) > + madv_behavior->prev = madv_behavior->vma; > + if (!madvise_dontneed_free_valid_vma(madv_behavior)) > return -EINVAL; > > - if (start == end) > + if (range->start == range->end) > return 0; > > - if (!userfaultfd_remove(vma, start, end)) { > - *prev = NULL; /* mmap_lock has been dropped, prev is stale */ > + if (!userfaultfd_remove(madv_behavior->vma, range->start, range->end)) { > + struct vm_area_struct *vma; > + > + madv_behavior->prev = NULL; /* mmap_lock has been dropped, prev is stale */ > > mmap_read_lock(mm); > - vma = vma_lookup(mm, start); > + madv_behavior->vma = vma = vma_lookup(mm, range->start); This replaces vma in madv_behavior... > @@ -1617,23 +1625,19 @@ int madvise_walk_vmas(struct madvise_behavior *madv_behavior) > struct mm_struct *mm = madv_behavior->mm; > struct madvise_behavior_range *range = &madv_behavior->range; > unsigned long end = range->end; > - struct vm_area_struct *vma; > - struct vm_area_struct *prev; > int unmapped_error = 0; > int error; > + struct vm_area_struct *vma; > > /* > * If VMA read lock is supported, apply madvise to a single VMA > * tentatively, avoiding walking VMAs. > */ > - if (madv_behavior->lock_mode == MADVISE_VMA_READ_LOCK) { > - vma = try_vma_read_lock(madv_behavior); > - if (vma) { > - prev = vma; > - error = madvise_vma_behavior(vma, &prev, madv_behavior); > - vma_end_read(vma); > - return error; > - } > + if (madv_behavior->lock_mode == MADVISE_VMA_READ_LOCK && > + try_vma_read_lock(madv_behavior)) { > + error = madvise_vma_behavior(madv_behavior); > + vma_end_read(madv_behavior->vma); > + return error; And here we could potentially do vma_end_read() on the replaced vma. And it's exactly cases using madvise_dontneed_free() that use MADVISE_VMA_READ_LOCK mode. But it's not an issue as try_vma_read_lock() will fail with uffd and that vma replacement scenario is tied to userfaultfd_remove(). It's just quite tricky, hm... > } > > /* > @@ -1641,11 +1645,13 @@ int madvise_walk_vmas(struct madvise_behavior *madv_behavior) > * ranges, just ignore them, but return -ENOMEM at the end. > * - different from the way of handling in mlock etc. > */ > - vma = find_vma_prev(mm, range->start, &prev); > + vma = find_vma_prev(mm, range->start, &madv_behavior->prev); > if (vma && range->start > vma->vm_start) > - prev = vma; > + madv_behavior->prev = vma; > > for (;;) { > + struct vm_area_struct *prev; > + > /* Still start < end. */ > if (!vma) > return -ENOMEM; > @@ -1662,13 +1668,16 @@ int madvise_walk_vmas(struct madvise_behavior *madv_behavior) > range->end = min(vma->vm_end, end); > > /* Here vma->vm_start <= range->start < range->end <= (end|vma->vm_end). */ > - error = madvise_vma_behavior(vma, &prev, madv_behavior); > + madv_behavior->vma = vma; > + error = madvise_vma_behavior(madv_behavior); > if (error) > return error; > + prev = madv_behavior->prev; > + > range->start = range->end; > if (prev && range->start < prev->vm_end) > range->start = prev->vm_end; > - if (range->start >= range->end) > + if (range->start >= end) > break; > if (prev) > vma = find_vma(mm, prev->vm_end);