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 1C9EAC83F09 for ; Thu, 10 Jul 2025 05:49:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B49B46B00A3; Thu, 10 Jul 2025 01:49:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B21386B00A6; Thu, 10 Jul 2025 01:49:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5DE56B00A8; Thu, 10 Jul 2025 01:49:55 -0400 (EDT) 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 98B416B00A3 for ; Thu, 10 Jul 2025 01:49:55 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 562A01D95BB for ; Thu, 10 Jul 2025 05:49:55 +0000 (UTC) X-FDA: 83647278750.23.F6B102B Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf01.hostedemail.com (Postfix) with ESMTP id 7EA9C40002 for ; Thu, 10 Jul 2025 05:49:53 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=bLMr+Xcr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752126593; 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=g2DkamPXkqG5QCK86AOwRmXVbMEqNBmAF1PKjGfsOCw=; b=JxWpnRW94N+IeeIheuWNKm5H5i9Wfu+/MD63tg72hoP9h0oZhReQwDT9OsCLOMiRcdf3vw P3aN/uxnlzqD6fek56EJKk+TJG2d6FfJqJ+jF5OvBJPT4WRH8tglDVpf/nwtI8Ah8IHRaV Na1WK8wtUPoFSYJlRqSyo1BfPCWlZGk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=bLMr+Xcr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752126593; a=rsa-sha256; cv=none; b=UmNjW6pciVTd24jlo9yM9tHkXM9S36o+5lO2OvGdWM0rhZLEjCYzCPa82UbdL8pB6iSLnp EjXBboHUA14k4q4aQcteLrb8FS1Uv06vdWZIifVGE1B9N3+Lh7WmMnyoNWddRiNsY+k8ZM Kks/u5ShNjsinseu5dFdCHPExcZYCAk= Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4a7fc24ed5cso150241cf.1 for ; Wed, 09 Jul 2025 22:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752126592; x=1752731392; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=g2DkamPXkqG5QCK86AOwRmXVbMEqNBmAF1PKjGfsOCw=; b=bLMr+XcrsGrUmFAVD6hNCv7gTTfh0NZ5KIL1t0zVlr0ScGnGxmp+XDgEfBTcRKeq/O vBratghzZsAmEcOaFAqZOgsYdd8vOIoD28wgNGNBMa38KxP8jZZtZb5iU1Gv8bipwzL1 CPQuRkKXJX8kNRCmwLeOmQZb9SQJlq6XRhd26uJ93EmXAfdYCqaPdIXUguZIfhYsSqdB nmUVVAFzqup5daH5j8mt+aXLjzRg6hD49WqspGzSj6xEaWG287ZHuoZyViLM8vNLBDrY lzIY7uhF3rkGjQxRQD4LhGClmYyjfVAAL7FpeSZcSvXg48nlAGmjE5PvU34EDR3lteaX JOwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752126592; x=1752731392; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g2DkamPXkqG5QCK86AOwRmXVbMEqNBmAF1PKjGfsOCw=; b=MQ/vzFnHYPr5Ktn4nt8HjsHBeWp7irLbXeoYTfZub3uIgqMA6dQ3YbY2B8bEazfkH4 1LiMWieCRhV6y6eooPgCRTHTMREfpT+bnYPZBxbyfrcWHQupojyT62aMtL7cwGfq4YNV MxyXFCaU9WIm+GEr8JNvqiq4c+gPJLPVei4kahp4Zn1IhTnTw8gVxdp3T/cDjJT5sbfK 23ok4r41IXVmfNu3pEou2Q1454NpYxDI5gmlI9wTNbERo5J3cTM7HRbPq7l2QTxVWHFU kkXlLud7uHvER+eGPTY8GQubLP38u3B5kresPyVml4RrI9MajNoVmanUj9mwUOyfnn3T zVpA== X-Forwarded-Encrypted: i=1; AJvYcCVlQS4cC9KSot1aWDYm1yG0BbRxA2DCGB9ibT/aGaXzN7qNpK+5OYpqsacZH2GfNy3b0JdpmZXf6g==@kvack.org X-Gm-Message-State: AOJu0YzU2T55dgKuBf6AwdCg5ZMSDYPPiLZ0RKK60XKv9WtoLLfPGfOx iJr7ngQtA1iBGW7fYT/tUP4kLUeT2WlE+EGnOaptfx2MBBRplCjfs4b+WLxaYh7rdJLm3gxEjzU ErGRIOdHug0OBshVQUDOXolLP0kvIpHobEDfxz0tt X-Gm-Gg: ASbGncuQIMcLw5AIqwRSX0Ll11vFM1LL6qi4QVYmLAsmnZv8x3Ca05FeyPIrAVRS9bW hJtLKfvWFxFmP+uAnppasYp/GritdbWoGix5akccrLxqzJMX1dsXCscR3I+zFgpHIF6xmlpme28 1WXoSO+RuSR7RzsCRrwCO1d3NOa9nvrWb0FHIPT7V4rU9wDhjJrKMrj3ysAdoWQlsp4hv378a1B Q== X-Google-Smtp-Source: AGHT+IHd9bYNDNAN5ENOSYbR3QqescLdRwV2rs10KxjR/R0bjr3EaIwYCIh2/P1wreAPm2DA7zZ9VtunAr5OldSmhpc= X-Received: by 2002:a05:622a:8e0a:b0:4a7:ff6d:e956 with SMTP id d75a77b69052e-4a9ec7d20b7mr1710771cf.3.1752126592089; Wed, 09 Jul 2025 22:49:52 -0700 (PDT) MIME-Version: 1.0 References: <20250704060727.724817-1-surenb@google.com> <20250704060727.724817-7-surenb@google.com> <0e0312c9-9a89-4a1b-a135-4425ea95d6f6@suse.cz> In-Reply-To: <0e0312c9-9a89-4a1b-a135-4425ea95d6f6@suse.cz> From: Suren Baghdasaryan Date: Wed, 9 Jul 2025 22:49:40 -0700 X-Gm-Features: Ac12FXxTrq12WEb497yNoTrLUG113kauaA6N6gifPoRES-xwIKd4uwt6gAWXY3I Message-ID: Subject: Re: [PATCH v6 6/8] fs/proc/task_mmu: remove conversion of seq_file position to unsigned To: Vlastimil Babka Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, david@redhat.com, peterx@redhat.com, jannh@google.com, hannes@cmpxchg.org, mhocko@kernel.org, paulmck@kernel.org, shuah@kernel.org, adobriyan@gmail.com, brauner@kernel.org, josef@toxicpanda.com, yebin10@huawei.com, linux@weissschuh.net, willy@infradead.org, osalvador@suse.de, andrii@kernel.org, ryan.roberts@arm.com, christophe.leroy@csgroup.eu, tjmercier@google.com, kaleshsingh@google.com, aha310510@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7EA9C40002 X-Stat-Signature: h3gajkbuhjx1z67pk8m3j88k3aruw955 X-Rspam-User: X-HE-Tag: 1752126593-364831 X-HE-Meta: U2FsdGVkX19EBqHdJg/4Xs0fK6CggWy0tZCb8MVbDCd235Kkb+jMM+q3VgPDzGC66WhzgN15Jwq0bfzdhIdYWP/JYfri5qw7ZjyWcRgpej2gKQ05epjC9V3Ya0Ve6YQGeF+wkBemTCbOV+j7IoN41bl25eN251gFKFkNxXFuPtsM8uSYlPFYOPTnXgjoQWALi1YWmcLG4GjvGyaTsnIGwxi7xKHh+vqDAcCsK9zHvPx0NH3fooc/1gnSokKePflRdCSYwfnCAwm33CehFEv73T9Fd0LVEoxKLazIpj11FoXUv+0l7Y7CjfARj3OD3OYlADapIm41aJvQeob5hOEJ84ya4st2jpmOTGCkLzzRrd6i2ZXbuZ5gVn8P426Elbfid2F4TPDbLkGKUYfmWgCrBWqCZKcONNSE3wvsrqA29/eXT9By6njFT4VOjsfDj/ldBNr7X16P9EG98yaX1yJ4coPOpjwkqBEnUj86/ymCafXQUVD6yOnpFewcPaNfcjn88B6v6+poRJEzokDgH+/aHoEwFKhToDml6TjF0h8rbnjN0QKArtQR4kriqVsg5GnJYJHYtLQMURzS+h8GHI3e4Y8UaYbCqeZNx+JBbLuxoZb7vnsFt8YQ2nYK6BOujMfiG9BJs6q0A0qYFmgY9eyf5qon/R159YrsRwPCbSwai7l9S499NiF3ytclCQUzwdjK8+gkp0ATkwUgSDxVkB4L4xVdjXAkGeLKzF/srdeujoy/NjVhiGvr9cvAyY3sOa9QnbAIxEjDncutWTXccxj/XNfkj7rM+i6L6tcgEj4a8DBgsqkJH7XBBzpAPShyQGkNF0RTcvKFk6bxtIHox0kx0LYQ6ti4yMKffXtadirYh/sIaPOzcVtD244NrPfdL7uPKwjNNFOiV34oKpVW8KVF5ZkVoimLor8Z2vBxNjLUqYxcz4fi2SRkAYtHJV2RoBLXs6Ju5t3OrueKgKK1T+/ jErku3f3 uSvhLaOSzvikC1nebMKowE35hJ1sfA0PbIPu10zpGEwP2nVsN7bZEacMMtkCiS6roXRb+DE+xLS2UBcBPJ+jWH4QFWagUhyKQud1kC734Bhj/uEcT6U+TYmoiNMwhBBt+eBOepDSH3kMfD7hjJttKkhUCfYLkEjDpAkC8pqeDePNQ2iYGY0QXUBESkDf/gCyKMEJHNUdXlY8rJQ7gtTOkkyRgtDhlhHU3ayI16tWS494qOBoSHhFG6IsCUHZqb9PPtz2GozCYOuO2oYxJhr0H+ic/+OcRY7PfhWuSXmb0RwfmKWY= 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 Tue, Jul 8, 2025 at 10:37=E2=80=AFAM Vlastimil Babka wr= ote: > > On 7/4/25 08:07, Suren Baghdasaryan wrote: > > Back in 2.6 era, last_addr used to be stored in seq_file->version > > variable, which was unsigned long. As a result, sentinels to represent > > gate vma and end of all vmas used unsigned values. In more recent > > kernels we don't used seq_file->version anymore and therefore conversio= n > > from loff_t into unsigned type is not needed. Similarly, sentinel value= s > > don't need to be unsigned. Remove type conversion for set_file position > > and change sentinel values to signed. > > > > Signed-off-by: Suren Baghdasaryan > > Reviewed-by: Vlastimil Babka > > Some stuff in the code gave me a pause but it's out of scope here so just= in > case someone wants to do some extra churn... > > > --- > > fs/proc/task_mmu.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > > index 751479eb128f..b8bc06d05a72 100644 > > --- a/fs/proc/task_mmu.c > > +++ b/fs/proc/task_mmu.c > > @@ -135,7 +135,7 @@ static struct vm_area_struct *proc_get_vma(struct p= roc_maps_private *priv, > > if (vma) { > > *ppos =3D vma->vm_start; > > } else { > > - *ppos =3D -2UL; > > + *ppos =3D -2; > > vma =3D get_gate_vma(priv->mm); > > } > > > > @@ -145,11 +145,11 @@ static struct vm_area_struct *proc_get_vma(struct= proc_maps_private *priv, > > static void *m_start(struct seq_file *m, loff_t *ppos) > > { > > struct proc_maps_private *priv =3D m->private; > > - unsigned long last_addr =3D *ppos; > > + loff_t last_addr =3D *ppos; > > struct mm_struct *mm; > > > > /* See m_next(). Zero at the start or after lseek. */ > > - if (last_addr =3D=3D -1UL) > > + if (last_addr =3D=3D -1) > > return NULL; > > > > priv->task =3D get_proc_task(priv->inode); > > @@ -170,9 +170,9 @@ static void *m_start(struct seq_file *m, loff_t *pp= os) > > return ERR_PTR(-EINTR); > > } > > > > - vma_iter_init(&priv->iter, mm, last_addr); > > + vma_iter_init(&priv->iter, mm, (unsigned long)last_addr); > > I wonder if this should rather be done only after dealing with the -2 cas= e > below. It seems wrong to init the iterator with a bogus address. What if = it > acquires some sanity checks? > > > hold_task_mempolicy(priv); > > It seems suboptimal to do that mempolicy refcount dance for numa_maps sak= e > even if we're reading a different /proc file... maybe priv could have a f= lag > to determine? > > > - if (last_addr =3D=3D -2UL) > > + if (last_addr =3D=3D -2) > > return get_gate_vma(mm); > > I think only after the above it makes sense to init the iterator? Yes makes sense but let me do that outside of this patchset as it's rather unrelated. > > > return proc_get_vma(priv, ppos); > > @@ -180,8 +180,8 @@ static void *m_start(struct seq_file *m, loff_t *pp= os) > > > > static void *m_next(struct seq_file *m, void *v, loff_t *ppos) > > { > > - if (*ppos =3D=3D -2UL) { > > - *ppos =3D -1UL; > > + if (*ppos =3D=3D -2) { > > + *ppos =3D -1; > > return NULL; > > } > > return proc_get_vma(m->private, ppos); >