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 BA0AEC3ABC3 for ; Sat, 10 May 2025 04:03:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A22F6B0121; Sat, 10 May 2025 00:03:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 950EB6B0122; Sat, 10 May 2025 00:03:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F1266B0123; Sat, 10 May 2025 00:03:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 618846B0121 for ; Sat, 10 May 2025 00:03:20 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A24E8BF3A8 for ; Sat, 10 May 2025 04:03:20 +0000 (UTC) X-FDA: 83425653360.22.31F7185 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf26.hostedemail.com (Postfix) with ESMTP id CCEB1140006 for ; Sat, 10 May 2025 04:03:18 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XwIUJytW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746849798; a=rsa-sha256; cv=none; b=BAF7rmZ0H3TChYyF4wMnOdSYsDukxzY859Pr/gOwfiDZYsP6i4X2s7M1MPgFGRkGypEnG/ WrVRTdteGzEd+WsnD4TlH//fpUKytyWoEFlBNTyYWhUxEcR3MxrxeIDdY5PXwoabyBxtkw uoEfN1ZHmo2+XL19fiPSZchjg1NgXp0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746849798; 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=Dvp7VCvFDKnx/a5kWY4TFIakrGqMlV1KSWlgl2jF3rk=; b=Dc2VHhxf1nKoEB00LapoJKhujwsXOQKY90LU+veTnmVEG7qC6xnr6p14KB93g8Y2BNeNy1 fmkhSLElpidqt4PSgpWouKG3qDDkzQ8bM4AFsZZZOTr3yGMYHdvxT/gF+v+7hIPFWrBdW0 569WPbxTlKitQuA+UmAsn2qb3Zi0QIs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XwIUJytW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-47e9fea29easo121491cf.1 for ; Fri, 09 May 2025 21:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746849798; x=1747454598; 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=Dvp7VCvFDKnx/a5kWY4TFIakrGqMlV1KSWlgl2jF3rk=; b=XwIUJytWQ60pt/dD0O8mjWukY5HMQjTdFYr+/zO0jenbyRM5xy7gx8snPWrVL/aSJn zS1JzXDiJ9oFBUmzBbTANgjc9whPfPwuSB+4DvdkEc1RiObKmUo9GBUXG3uV9K636ZXd BXW53mtnfBt2J+lFAUnQMO0PwBXQ6W0xevl9ugx3urozhqTyEPGu8WQsh4UCUwkAXxRt 8jvX2PniorAjBvaxbOmSZukfS33FmCCvdXYmMullnIgHAxyvgUhDweV5SvDSCNQLPBoA Jrf3AA75LKb39Qmnf8je4GA4yrCDUfLaWynpB+qSVtWUKUy54xm8ZaN1tK5As+nxzYMV PbdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746849798; x=1747454598; 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=Dvp7VCvFDKnx/a5kWY4TFIakrGqMlV1KSWlgl2jF3rk=; b=baT80aCF21jFvoacXzcAeloejGvQxWJqS2vkcuEhsmF6VfOD9a5dBuB7dYeabB22IQ cVTxT88tUwoJ24QKHT6Rh6CPpyYWdgn4SK7s18c8ecAjvj6xHhQxVcBq7awjBqnU+qk+ rMW4nThjx6Hsr1STlPPieSHyRG88s7ck3E+sf7ZS1xuypybJhmUqz4/bJ+k3RPUG0fyx c+gomQ7ZZDLpRQC0+iQdsmurIQTQVDzqTRNxk5+NA6UyX5Kh/KcpW7z9cv3iyvjg6BfW nXyy0gcPGmblT+aWI3ModO61impZGurTVxaD7NIiTbTvHpKKKwYnQedVHQk2vdhR+6mp bk+w== X-Forwarded-Encrypted: i=1; AJvYcCW7OyjCQV1Tkxk3TbTULS5EtWahmnXkigYQowGUCBGwnlBcISKN/K7fC4BtJbXal+WQBASU8Eagkg==@kvack.org X-Gm-Message-State: AOJu0Yz+P0gmVCL/LDezVTIgCyOh9dFQuujLZB1WTUOq0C0YrTaDCaSU sePiH2iBYWfpiQsW556fNoW4sBOo/OodmfK224v4pw6AD4GWitytZHsWTWVJbrtPJYOzOpEvSEY UtL9Hslg9G52AvkDaB4NWtvjj1ruzZd2+qVqV X-Gm-Gg: ASbGncvBmGoZknf5pscwQwSmR57tqnuA3SiCYBnUPLBlOoIZ+zcWC4DBHdKSLDIhEkK ehKYJCZ/PMrU2V14iwZ+QeciVx0dY7VmUTDg2Gp1SSmR/AnjW7b5nA8JBqMurw/HlpodN4yrJKd Qp02TaRvM8VSeDh3+ZdIf3Z8gltknqqQT/jeCeDFhOl08i5Bj2BfJYxcuRkh4npcw= X-Google-Smtp-Source: AGHT+IGa6MCZkC7TJO9+WiK45ItxubNoVxnApGxNlmqwtd4qdWS3wVJjqSuWv2sanSl5OfbToCZ9VTmOoruwm2aV73M= X-Received: by 2002:ac8:5ac7:0:b0:477:c4f:ee58 with SMTP id d75a77b69052e-494611a9033mr2461021cf.24.1746849797569; Fri, 09 May 2025 21:03:17 -0700 (PDT) MIME-Version: 1.0 References: <20250507175500.204569-1-00107082@163.com> <20250509173929.42508-1-00107082@163.com> <7f237574d9f08a9fa8dcaa60d2edf8d8e91441d4.camel@linux.intel.com> <294d0743c0b2e5c409857ef81a6fe8baaf87727f.camel@linux.intel.com> <3cbaf905.ef7.196b82bdcc9.Coremail.00107082@163.com> <7bb65ee6.129c.196b857cdb3.Coremail.00107082@163.com> In-Reply-To: <7bb65ee6.129c.196b857cdb3.Coremail.00107082@163.com> From: Suren Baghdasaryan Date: Fri, 9 May 2025 21:03:06 -0700 X-Gm-Features: AX0GCFsLYORsD96opZgIs85f1ii3lyJmLrotI3rCOLs3ZebES_QUF9_QvaGjKQ0 Message-ID: Subject: Re: [PATCH v2 2/2] alloc_tag: keep codetag iterator active between read() calls To: David Wang <00107082@163.com> Cc: Tim Chen , kent.overstreet@linux.dev, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CCEB1140006 X-Stat-Signature: a1we1ru5jbyc7c4thstms3he3e3m4o61 X-Rspam-User: X-HE-Tag: 1746849798-526970 X-HE-Meta: U2FsdGVkX18XKty8vuoR2I8rB5W/B1uIFHqxKlps/fgqLY+bRGU3iRJM52qj3moiQAsM81IKG6uyA+3pgkMoHBUEkptGcQG3H/DlIj2hfYOscEuuhDUsru50E6p/tdLd51JmsBJkxxcZsScSvCkHZtktyQrbOvbZL+Ygzb+c0+xszqobQbh67qRcqjAxw8DAoTMU8MkBVYIGycctPPqMi/pakBn2XsUwpREY3z82ptuVNkhlR8kt9CYb35+JBBVOqAI2Rg4bRIttve6UfLV13HuB5DeVBEzOSz8aHLyABv/rM40rXY4UHTwnBm7q7hVSQ11x0JuffZxAvDDPnOZLhbm3D+WCEKa333VAcydgQDNQufA2Oqg4Xp2bopOO0IliEKe3sU12VXmlZGGe7vlfAxWNDQ91A9UIh4LVIjcj0QfVHhmvWI98c/6ecO91KOTKhoJwLmj2tWAo5e2GiLf5O08nU1g1710s1ovMNiLckP0cjHJX9RqSyO2GzyoUvobhc1axuxrgDZxlAougfPYXMTSOb7oq2DlgrH9HHtQAqy1Rzx7kuvbVDhInOavOKGXly2Xg6LunzEJDUpMACVZ0QtoBhxOHHQr+Dea7PO2p410f4firzZN5yEnYfikpRxcbf11aGqOg5chBG0j4fD9vDQmbwcInPFenbBMmLO0DzdasanMq2pH4SeDIaOMYNx1IXbD+trGIR9WPhbZ6auRXZdhosLkq4cL6ngTCbA3N5bqQk+PtmqyEkChGCGz6mHrovEnPsn7NL/WbCjHNBZPc2D8xlzbmrVap6QklBwKBqEfvIfpDoYeQ6+gTy//SC+HgZHN6uMCQGy50abymStKIGMGPUqye+bGQrHXBc0d83bNZr7coz11UZrnMmD0GDMCdI4x/iQ2hTXgyEmnGTHV8rE1tNQjwyHTQ119QBCMN2BdioyUZzMriZgSOLRQUddpSCMIuHd5XpOCnXcBlZto 2gjUDSBA nc/KUcFypN32hQk7Hnd5wvAWB2EyCg6x3vx0p2Bn5NjXv/eJExCpCpbpiYuEYwXXs4iXBCrjHbQRWSFDgRJ3R0LZb3pAOmhLDkkWBl3diyvwub/FWgeYpxu18n/EsD1JabpOp5mRkFJ27z0H5kNIQZWQKKRjIbAphhZErrAIDUUzF23c3OHBRGPg7E7zO8NPeVW1NfoiXxqYjCn/ftqQJ0GnpsQ7/FXKdS3GySFIvANWzVJ33xAOC4Re5Zw63RYl9Yw2aCBpUfeNZ+ACqNXT92kzCfPbJ5k0UMsH4zM1iovFVbLOgWVNjS/zJCPOOkxnppJhrIOxjrtLPjO7oLw2W2pn6Avovz+d/KMuknVHKY1s33YgH/3AO04LkDJslC5pqPyDQCg3NqiIjHLZRv959EddponQtpBJm17SQXpNGbxG0X8nOv3MlQWA6CoCan/Sg488eszIhmtjB2kE= 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 Fri, May 9, 2025 at 8:58=E2=80=AFPM David Wang <00107082@163.com> wrote: > > > > At 2025-05-10 11:30:50, "Suren Baghdasaryan" wrote: > >On Fri, May 9, 2025 at 8:10=E2=80=AFPM David Wang <00107082@163.com> wro= te: > >> > >> > >> At 2025-05-10 05:15:43, "Suren Baghdasaryan" wrote= : > >> >On Fri, May 9, 2025 at 1:46=E2=80=AFPM Suren Baghdasaryan wrote: > >> >> > >> >> On Fri, May 9, 2025 at 12:46=E2=80=AFPM Tim Chen wrote: > >> >> > > >> >> > On Fri, 2025-05-09 at 12:36 -0700, Suren Baghdasaryan wrote: > >> >> > > On Fri, May 9, 2025 at 11:33=E2=80=AFAM Tim Chen wrote: > >> >> > > > > >> >> > > > On Sat, 2025-05-10 at 01:39 +0800, David Wang wrote: > >> >> > > > > > >> >> > > > > > >> >> > > > > Signed-off-by: David Wang <00107082@163.com> > >> >> > > > >> >> > > Acked-by: Suren Baghdasaryan > >> >> > > > >> >> > > > > --- > >> >> > > > > lib/alloc_tag.c | 29 ++++++++++------------------- > >> >> > > > > 1 file changed, 10 insertions(+), 19 deletions(-) > >> >> > > > > > >> >> > > > > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c > >> >> > > > > index 25ecc1334b67..fdd5887769a6 100644 > >> >> > > > > --- a/lib/alloc_tag.c > >> >> > > > > +++ b/lib/alloc_tag.c > >> >> > > > > @@ -45,21 +45,16 @@ struct allocinfo_private { > >> >> > > > > static void *allocinfo_start(struct seq_file *m, loff_t *p= os) > >> >> > > > > { > >> >> > > > > struct allocinfo_private *priv; > >> >> > > > > - struct codetag *ct; > >> >> > > > > loff_t node =3D *pos; > >> >> > > > > > >> >> > > > > - priv =3D kzalloc(sizeof(*priv), GFP_KERNEL); > >> >> > > > > - m->private =3D priv; > >> >> > > > > - if (!priv) > >> >> > > > > - return NULL; > >> >> > > > > - > >> >> > > > > - priv->print_header =3D (node =3D=3D 0); > >> >> > > > > + priv =3D (struct allocinfo_private *)m->private; > >> >> > > > > codetag_lock_module_list(alloc_tag_cttype, true); > >> >> > > > > - priv->iter =3D codetag_get_ct_iter(alloc_tag_cttype); > >> >> > > > > - while ((ct =3D codetag_next_ct(&priv->iter)) !=3D NUL= L && node) > >> >> > > > > - node--; > >> >> > > > > - > >> >> > > > > - return ct ? priv : NULL; > >> >> > > > > + if (node =3D=3D 0) { > >> >> > > > > + priv->print_header =3D true; > >> >> > > > > + priv->iter =3D codetag_get_ct_iter(alloc_tag_= cttype); > >> >> > > > > + codetag_next_ct(&priv->iter); > >> >> > > > > + } > >> >> > > > > >> >> > > > Do you need to skip print header when *pos !=3D 0? i.e add > >> >> > > > >> >> > > Technically not needed since proc_create_seq_private() allocate= s > >> >> > > seq->private using kzalloc(), so the initial value of > >> >> > > priv->print_header is always false. > >> >> > > >> >> > But we'll start with first call to allocinfo_start() with *pos = =3D=3D 0, > >> >> > >> >> Usually but not always if we do lseek() to a non-zero position befo= rehand. > >> > > >> >Actually, this change will break the lseek() case. We can't always > >> >assume that we start reading from *pos =3D=3D 0. Current patch will f= ail > >> >to initialize priv if we start reading with *pos !=3D 0. > >> >priv->iter should be tracking current position and allocinfo_start() > >> >should detect a mismatch between *pos and iter->pos and re-walk the > >> >tags if there was a position change. > >> > >> seq_file works line by line, I think even if it support lseek, seq_fi= le would still start with line #0, > >> since seq_file have on clue the byte size for each line. > >> > >> I will check the code, make some tests and update later. > > > >Ah, yes. You are correct. > >seq_lseek() will traverse restarting from 0: > >https://elixir.bootlin.com/linux/v6.14.6/source/fs/seq_file.c#L323. > >Position jumps are similarly handled with traversal from 0: > >https://elixir.bootlin.com/linux/v6.14.6/source/fs/seq_file.c#L194. > > > > Actually I was expecting EOPNOTSUPP when lseek on seq files, surprised to= see it works...... :) > > If seq_file somehow skips start(0), then nothing would be displayed sinc= e > priv->iter.ct would be 0 and `return priv->iter.ct ? priv : NULL;` would = return NULL; > But I think that case would be seq_file's bug, starting with 0 is kin= d of protocol promised by seq_file. Yes, I think that is the correct assumption. Even pread() with a jump in position should work the same way, restarting at 0. > > > >> > > >> > >> > > >> >> > >> >> > then print_header will be initialized to true. > >> >> > >> >> After the first call to allocinfo_show() print_header will be reset > >> >> back to false. > >> >> > >> >> > Will there be subsequent calls of allocinfo_start() with *pos != =3D0, > >> >> > but priv->print_header stays at 0? > >> >> > >> >> Yes, there will be subsequent calls to allocinfo_start() with *pos = !=3D0 > >> >> and priv->print_header=3Dfalse, which is what we want, right? We wa= nt to > >> >> print the header only at the beginning of the file (node =3D=3D 0). > >> >> > >> >> > > >> >> > Tim > >> >> > > > >> >> > > > > >> >> > > > } else { > >> >> > > > priv->print_header =3D false; > >> >> > > > } > >> >> > > > > >> >> > > > Tim > >> >> > > > > >> >> > > > > + return priv->iter.ct ? priv : NULL; > >> >> > > > > } > >> >> > > > > > >> >> > > > > >> >> >