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 AB49BC282D0 for ; Tue, 4 Mar 2025 21:45:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F2E3280002; Tue, 4 Mar 2025 16:45:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A427280001; Tue, 4 Mar 2025 16:45:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAD66280002; Tue, 4 Mar 2025 16:45:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C8B12280001 for ; Tue, 4 Mar 2025 16:45:36 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 59EAFA4252 for ; Tue, 4 Mar 2025 21:45:36 +0000 (UTC) X-FDA: 83185200672.24.9633A24 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) by imf10.hostedemail.com (Postfix) with ESMTP id 669E0C0005 for ; Tue, 4 Mar 2025 21:45:34 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="EkAsh/L4"; spf=pass (imf10.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.182 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741124734; 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=qs/wzcpT9hBhaXD05toVZbE5lL3id+EHNVqnHRGisc4=; b=ILcZpSn7Ac5rqLqKvx44gzXY05NWLD8XT6L8T76Dx9gh9vS84nQvdf8C+2W/1Y3awHvy8w 5QzHtuZQCYNxlVn20X03JtyhyaTTablEkIbWS4xjNfsyUXxlP64GXfVdDrX3yapRBNOncI 3dTJX5J1VuZ6ecXt0WRPJrMUM0M8Lpk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="EkAsh/L4"; spf=pass (imf10.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.182 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741124734; a=rsa-sha256; cv=none; b=poKzf++DiK8tbMLK08e5d1bLVMF0IttysNoyWX9isWS0qvSKJ0bN8GzMbVGFfczJf7DI2c hfyMP8W/M2RveNILcIhj8fAU04/qBPfgsRQg4vCM9Xdj+qbPlwbqG7DDH4MlySWyjVRcUc IxXjN1SCDTJlDiPolUhcqPug49thedA= Date: Tue, 4 Mar 2025 21:45:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741124732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qs/wzcpT9hBhaXD05toVZbE5lL3id+EHNVqnHRGisc4=; b=EkAsh/L45UrrJYiJTuPWsbyfA0iB5HPWPr3bLIIBzT9eUfEbbSluIOboqQ0/UkKYY70PZb RWBTwRxGTqbmhrrdx7KN0zdylzPd+RPxbB85TBXAWd72ufxV+6GOh0jsTn9rSCSU1EfMzI wXvl7/v28o3P9hooxKTBNWX9TCCE4RI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Lorenzo Stoakes Cc: Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/7] mm/mremap: initial refactor of move_vma() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: pyyf6c57cts9kysj4j3ugtkdzpg3f6ee X-Rspamd-Queue-Id: 669E0C0005 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1741124734-374782 X-HE-Meta: U2FsdGVkX189eAzXeG+R/GmIjW3JFAoBAQykemjfR+TBpKsfCW/i0Df6X43BQ/yJ/AQIJSFc30hDZg25ZFJA8zVJm8HD57hBeUeoNdX0NGx0Ki3QNTDIAJsOOqKg7c6QvxD8VY/CeQQsdszWkaiMXe+qOnSBsCY6s2Ugag+fNwG53VJJHS5omAKfnRUfNiRp9r27lDWeBn6nnDXVUprDNUJ3vb/LCnNmBbbg8DybKtELAPvVCnmeUcYi3q8xb3vy8vvzLkqgS8NYtX4IbrDYKaUlwoucAULleu3CD2OHeuCRrJITLItr0emcj2tlRCyDMshCmw29uRcxBOqGX/RIVWbfNmRbvhQ1bo0C2QD3vpbxoiP2apcMImE9CYzQ2rRp1IRiL8pDzfh4hjrZrtONuODmvk5PQg7zfsAGxA2g076RoLVSEsJSKI6up1pK3cpQk/sZ3hH6/Mc3mh8TbhGa/OAM8oTmqQcan7tt0m2oz+vUoBV/6zoSfYdmKNTzhOPtUbkwJCpd7UagvMnoLm3wkkqSS4Wt94C43urCuDLX4/TdcpCLw6buG77aDfwCxXRf5OxPi1mxt4xR9qn428CUCjTtsF10NB5uyjXiiISl5SnUpPfyWbcWaeM+G0xqQnCU1BqzN3pxGdvcK9pQl+/4m0A+pkzxWVJrdKaxVg372FpOlIrf1utbmpexg9HGPfjQmvpOKoGzXbeWX76+qA59yBSY8zMl1Q6vL2SzdQ/5aIyjkuyuEcvl2Fel/4uhzRSgbR2MKLETJ/mnWRHK6/AfWpTVQMNT9J3I898y2ImkC9CUa/z6Sjk4EyWFILbXeBNX7aE6/Y7WslmuKw+h5XpZbXOXExq7S/kxefqPS4zRnfr3z4pPeV5akkT1LQcldDiiu69KvhjB/Lb1lHbJEpx3VOQoZv4e4uDOFm85qMdMN8+uzdUGpRT4kbwcgSR2J0VNAA2HjN2wr4Z5OV/HajJ 37OctXaB 7tKtyBw+DU2teW0NckN0DO8ppXgspFCwqMoou73VoZtH/a/TFGqG7mR3aJHMuN1i3sVbU/MZLTIvj+tx+xh+IpDFQDQDm01aZqIGbvVwjfMDIWyrEnDU3sk3JQpzFVz1/k8mVmdpQqHKIB6D9ZngnjJpY9spFGq8MdHW8tUVFJDWARqE1+RDY86zTe+xqzWwSqIBqPavVD+Z5XskOkEpvKVjaEtLnJIKwrzdYcsq1hJ30zSuaN5wieeBrOR8CrjTA7MFjiBA02NRLv4zGA5eyUQhjXNBXNAxvqbIF 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, Mar 03, 2025 at 11:08:34AM +0000, Lorenzo Stoakes wrote: > Update move_vma() to use the threaded VRM object, de-duplicate code and > separate into smaller functions to aid readability and debug-ability. > > This in turn allows further simplification of expand_vma() as we can simply > thread VRM through the function. > > We also take the opportunity to abstract the account charging page count > into the VRM in order that we can correctly thread this through the > operation. > > We additionally do the same for tracking mm statistics - exec_vm, stack_vm, > data_vm, and locked_vm. > > As part of this change, we slightly modify when locked pages statistics are > counted for in mm_struct statistics. However this should cause no issues, > as there is no chance of underflow, nor will any rlimit failures occur as a > result. > > This is an intermediate step before a further refactoring of move_vma() in > order to aid review. > > Signed-off-by: Lorenzo Stoakes > --- [..] > +/* > + * Perform checks before attempting to write a VMA prior to it being > + * moved. > + */ > +static unsigned long prep_move_vma(struct vma_remap_struct *vrm, > + unsigned long *vm_flags_ptr) > +{ > + unsigned long err; I am getting a warning on mm-unstable because 'err' is sometimes used uninitialized, I think here: if (vma->vm_ops && vma->vm_ops->may_split) { if (vma->vm_start != old_addr) err = vma->vm_ops->may_split(vma, old_addr); if (!err && vma->vm_end != old_addr + old_len) err = vma->vm_ops->may_split(vma, old_addr + old_len); if (err) return err; } > + struct vm_area_struct *vma = vrm->vma; > + unsigned long old_addr = vrm->addr; > + unsigned long old_len = vrm->old_len; > > /* > * We'd prefer to avoid failure later on in do_munmap: > * which may split one vma into three before unmapping. > */ > - if (mm->map_count >= sysctl_max_map_count - 3) > + if (current->mm->map_count >= sysctl_max_map_count - 3) > return -ENOMEM; > > - if (unlikely(flags & MREMAP_DONTUNMAP)) > - to_account = new_len; > - > if (vma->vm_ops && vma->vm_ops->may_split) { > if (vma->vm_start != old_addr) > err = vma->vm_ops->may_split(vma, old_addr); [..]