From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202510 header.b=TepbaHCP; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 8C48F5A061A for ; Fri, 17 Oct 2025 01:16:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1760656591; bh=vO6BKo8fCcglauCrjaJcz3wHZ0Dw5hz6jIzZez9hvWc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TepbaHCPkGwTHoRLYYu3NqggHWtGsPqiImmaD2ti1nGEWoCoMtSQPP/caQc1M0hhe /3s9qNhI8sl2BSMU42ac4SxjIE7SwDScSU531+s35blPjX4PVvEXcgEZteKb/kExtC Yy4fMnMUvCjPKyT8murPRUUXDvEGm3huN99+xPpQxBYN0sSE74uKPVBqg6VHcx9a0u Vcm8itCK6Vs1HIN1BV6E+U1IY6APWc8NuoXahym7osV1/jglSw6K4yrDRlCl62T2BP WriRBuVjVfZbPlynDuW3oo2V/UdVpwrWk/IsXf4aBd70kaCFyO7XRy9HM5e5zdffn0 KMdDM5K+rRnkw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4cnkNb08FXz4wD1; Fri, 17 Oct 2025 10:16:31 +1100 (AEDT) Date: Fri, 17 Oct 2025 10:16:26 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v4 2/4] util: Introduce read_file() and read_file_integer() function Message-ID: References: <20251016023423.8923-1-yuhuang@redhat.com> <20251016023423.8923-3-yuhuang@redhat.com> <20251017002214.3fd4955b@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RwyQ0F86DhZECNDx" Content-Disposition: inline In-Reply-To: <20251017002214.3fd4955b@elisabeth> Message-ID-Hash: 4T3LZGSJNDUG4QPAMHS4BW3T4MZ3MYLL X-Message-ID-Hash: 4T3LZGSJNDUG4QPAMHS4BW3T4MZ3MYLL X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Yumei Huang , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --RwyQ0F86DhZECNDx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2025 at 12:22:14AM +0200, Stefano Brivio wrote: > On Thu, 16 Oct 2025 15:49:39 +0800 > Yumei Huang wrote: >=20 > > On Thu, Oct 16, 2025 at 2:30=E2=80=AFPM David Gibson > > wrote: > > > > > > On Thu, Oct 16, 2025 at 10:34:21AM +0800, Yumei Huang wrote: =20 > > > > Signed-off-by: Yumei Huang [snip] > > > > + if (total_read =3D=3D buf_size) { > > > > + warn_perror("File %s truncated, buffer too small", pa= th); > > > > + return -2; > > > > + } > > > > + > > > > + buf[total_read] =3D '\0'; > > > > + > > > > + return (int)total_read; =20 > > > > > > Probably makes more sense for total_read and the return type to be ss= ize_t. =20 > >=20 > > Just tried to be consistent with write_file(). I can change it to > > ssize_t if needed. >=20 > ssize_t is the type designed for this, if write_file() has it wrong (I > didn't check), we should fix that as well. It does, and we should :). > > > > +} > > > > + > > > > +/** > > > > + * read_file_integer() - Read an integer value from a file > > > > + * @path: File to read > > > > + * @fallback: Default value if file can't be read > > > > + * > > > > + * Return: Integer value, fallback on failure > > > > +*/ > > > > +intmax_t read_file_integer(const char *path, intmax_t fallback) > > > > +{ > > > > + char buf[INTMAX_STRLEN]; > > > > + char *end; =20 > > > > > > passt coding style is to list (where possible) local variables in > > > reverse order of line length, so this should go after bytes_read. =20 > >=20 > > Oh, I didn't notice that. Will update later. >=20 > Rationale (added to my further list for CONTRIBUTING.md): >=20 > https://hisham.hm/2018/06/16/when-listing-repeated-things-make-pyramids/ >=20 > and see also https://lwn.net/Articles/758552/. If you want to update CONTRIBUTING.md to cover this, Yumei, that would be much appreciated. > > > > + intmax_t value; > > > > + int bytes_read; > > > > + > > > > + bytes_read =3D read_file(path, buf, sizeof(buf)); > > > > + > > > > + if (bytes_read < 0) > > > > + return fallback; > > > > + > > > > + if (bytes_read =3D=3D 0) { > > > > + debug("Empty file %s", path); > > > > + return fallback; > > > > + } > > > > + > > > > + errno =3D 0; > > > > + value =3D strtoimax(buf, &end, 10); > > > > + if (*end && *end !=3D '\n') { > > > > + debug("Invalid format in %s", path); > > > > + return fallback; > > > > + } > > > > + if (errno) { > > > > + debug("Invalid value in %s: %s", path, buf); > > > > + return fallback; > > > > + } > > > > + > > > > + return value; > > > > +} > > > > + > > > > #ifdef __ia64__ > > > > /* Needed by do_clone() below: glibc doesn't export the prototype = of __clone2(), > > > > * use the description from clone(2). > > > > diff --git a/util.h b/util.h > > > > index 22eaac5..887d795 100644 > > > > --- a/util.h > > > > +++ b/util.h > > > > @@ -222,6 +222,8 @@ void pidfile_write(int fd, pid_t pid); > > > > int __daemon(int pidfile_fd, int devnull_fd); > > > > int fls(unsigned long x); > > > > int write_file(const char *path, const char *buf); > > > > +int read_file(const char *path, char *buf, size_t buf_size); > > > > +intmax_t read_file_integer(const char *path, intmax_t fallback); > > > > int write_all_buf(int fd, const void *buf, size_t len); > > > > int write_remainder(int fd, const struct iovec *iov, size_t iovcnt= , size_t skip); > > > > int read_all_buf(int fd, void *buf, size_t len); > > > > @@ -249,6 +251,7 @@ static inline const char *af_name(sa_family_t a= f) > > > > } > > > > > > > > #define UINT16_STRLEN (sizeof("65535")) > > > > +#define INTMAX_STRLEN (sizeof("-9223372036854775808= ")) =20 > > > > > > It's correct for now, and probably for any systems we're likely to run > > > on, but I dislike hard-assuming the size of intmax_t here. I feel > > > like there must be a better way to derive the correct string length, > > > but I haven't figured out what it is yet :(. =20 > >=20 > > How about this: > >=20 > > #define INTMAX_STRLEN (sizeof(intmax_t) * 3 + 2) > >=20 > > Each byte can represent about 2.4 decimal digits as below, > > sizeof(intmax_t) * 3 gives us a safe upper bound, +2 for sign and null > > terminator. > >=20 > > 1 bit =3D log=E2=82=81=E2=82=80(2) =E2=89=88 0.30103 decimal digits > > 1 byte =3D 8 bits =3D 8 =C3=97 0.30103 =E2=89=88 2.408 decimal digits Works for me. > If it's sourced from https://stackoverflow.com/a/10536254 and comment, > don't forget to mention that in whatever implementation / commit > message. Good point. > But I was thinking... what if we keep it much simpler, use BUFSIZ, and > error out if the buffer is too small? It would be good to be robust > against any potential kernel issue anyway, so I think we need a > mechanism like that in any case. It already handles the case where the buffer isn't big enough (in read_file()). We could use BUFSIZ, but it's massive overkill for reading a single integer: 8192 versus ~21 bytes (or ~42 bytes if intmax_t were 128-bit). > It's not a security matter, because if the kernel was compromised, > we're compromised too, simply a matter of robustness. >=20 > --=20 > Stefano >=20 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --RwyQ0F86DhZECNDx Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjxfMkACgkQzQJF27ox 2GfnYg//cf5Lnq02tuYgTyu3FODu2aF2b4OeyeYlqvKMMTUmKTCt2qoLTM23D/rJ N11sWK1Wi9kICqlid/vuXy82tFWR+i1KD4nmx6LFgiSOEOMXNcwltp4EBSx3poqy uCvBydBUFmvMO3tVxpl3ywDqE+kk04CNjng+5Q1x64GAXwnpr/Q/ninEWgxyLQcF FGertntgUvVUnNfSnorjErpSnYePhOYeGoO0dnwqMAz9Gi3vSgkJqsjq3X6KSK/L APwwxt0jhbLZ40Im6b+plr6c7Zvyh8KsBSQXJC47a9KBDdYUEx4rhcVDn91DHaAw +InO2uU6Yh9Qm8jrLyb08d3rhp5uCalsV1qsihXt5D914vsqQ9sO0jTrvbopn2BW Bsm3v7hVzNsjqPqEOyPaXmGcogR57MmahvYuQQhLC1Jsxi70aNEfkBNnKIBA8cDH bTNO4jNn2oH1b6EI3KYiOiz0gwdZ5j1Lidq5w6wyq5v8mGl4hSPcl+6/E7H4PDy4 J6gDJ8g1auLIm54T0lrEJ483sWWuKDQcD0z/Ns5iv1iDTHv5Pme4uzbtpKOe+6R6 /evUUgV0lePDk73nc2Etz78mvYWJaLvUZ1TJDen4xgF7qyv4xfgeqwthCh5xe6Uv 1J4/m4tYmqLro7jY3jmczkbOE3z2YoocQ2Ih7ZncLFEhrgUlVXc= =wPi3 -----END PGP SIGNATURE----- --RwyQ0F86DhZECNDx--