From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Pxba2f6/; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 233735A0619 for ; Fri, 24 Oct 2025 08:05:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761285957; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R3JSI5zBdPlJ18hnh5r2zTLwT+AUq+TBj9hE3IVtDGg=; b=Pxba2f6/H2qpfXK01rH3BaILuHOP3d45c2gElYbUlY3jJ3vFXsTenQPwOIdZr9BbYoeKOp havxtmKR701+ylmtjogRxDP6xCpoSCClHq+2ND/9yTZPi9DI9qmEOZ4TIn7RSHYaM9EcHk vXS7jLdzHguTpHstGHM0YTt5GRt7x7c= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-572-CzB1xUEvOIOd_mAz72fIHA-1; Fri, 24 Oct 2025 02:05:56 -0400 X-MC-Unique: CzB1xUEvOIOd_mAz72fIHA-1 X-Mimecast-MFC-AGG-ID: CzB1xUEvOIOd_mAz72fIHA_1761285955 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-b479e43ad46so117131666b.2 for ; Thu, 23 Oct 2025 23:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761285955; x=1761890755; 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=R3JSI5zBdPlJ18hnh5r2zTLwT+AUq+TBj9hE3IVtDGg=; b=ZqRMxi94vbz3nMA2dk/7pjB8uzYnknMmX3IzJfIjo68VOwsTvG9lYU2RcBEzQhtnRx Ih4LD5iYtt+SkQ0C24NHuJpDAEyUJExftLaSMAZqwxDhzOPO2CIKmc3PMJiWFWoRBHcc j2LMF6zwvE24dgqVlBC4c8YqvIpTmKHJIlKRbl704yffXPvC4no0FYgUA2CrnG0Tgxn8 9UU1V8bYpehayddC0HHXrNSBjbwJX58sMhJic1jSu/SumAL/6m4jbEyX93zSSzBgkjae C8zbU3nbJ3vcJizAlVcR4hCrSs7oDFjKFMjPHOC0v0j1L4C8tpfPWzVchOIVV94cTEWR 9oVA== X-Forwarded-Encrypted: i=1; AJvYcCVkw3B7mYQi9Kg0cyuCGni3Dn+f+oyIWWZwypQt53syOo+KTZ+7s5wJTY9XpqRbY2EjLFfv5flOTSg=@passt.top X-Gm-Message-State: AOJu0YyD7hSlkq+tVLzrhfvDw2vROSi13CbzhCD1X0lBhBNStARvY/2Y eblEEMxgtWUrqXM+FoQQgfrYXvURLdNWa/2CwGKu/rCyMDANKJz+T7Yg/AD7ElZjqvSO3cc6V1a gYveZDf/JGPgM/CxLnCjvMokO0kCayvHk3BcEMPONum+ivXHxPyM3MlI9cm+uhQb7r0kZj4KXcy CKi1+XF42FTFVuPyVrEmevme5sTpiQotPztGvf X-Gm-Gg: ASbGncsQEjJV1pLevUcPYwRF2nYQjDOlxT8QdTK/gr1YHYsI7stuk2gNTLM1Pfcd9yd 9XYyOP6vISQulKRV3Wg6CG4IZTTJK/h/1LvwrI0cQD/ylDQG0dujn2mNeZ3Pj/wttW+Iec4mxTJ XgfhCFYjQGLdeXmDWtTu8FMYs6nQkiL6Mh05CpmBrNwpKmq8mDwXoU1wfz X-Received: by 2002:a17:907:3e0b:b0:b3f:e1e9:22c7 with SMTP id a640c23a62f3a-b6d70061231mr96807066b.65.1761285954743; Thu, 23 Oct 2025 23:05:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEFV/u1zW7fsIlDaHkECi2QvrzP8WVT7Y+rM94KePK5oNtldQ6n+Wt1C9ephzNoRsjOxs67SHjsrPSB4nR7Jfg= X-Received: by 2002:a17:907:3e0b:b0:b3f:e1e9:22c7 with SMTP id a640c23a62f3a-b6d70061231mr96803766b.65.1761285954284; Thu, 23 Oct 2025 23:05:54 -0700 (PDT) MIME-Version: 1.0 References: <20251017062838.21041-1-yuhuang@redhat.com> <20251017062838.21041-3-yuhuang@redhat.com> <20251024010427.1c8d1032@elisabeth> In-Reply-To: From: Yumei Huang Date: Fri, 24 Oct 2025 14:05:43 +0800 X-Gm-Features: AWmQ_bkJRJXQTYA-RhZElaksTvRi3pSxq4nmWfFFHfs9sy9vj9PTJ4PVZEU77zA Message-ID: Subject: Re: [PATCH v6 2/4] util: Introduce read_file() and read_file_integer() function To: David Gibson X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: s4FVO1ZRijWOSjhKBcyHEfiyOOkpOa2PNFZpCR-jHGA_1761285955 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: SRSTME7PTFUAJYRLB7I3UONQBQOQOPF7 X-Message-ID-Hash: SRSTME7PTFUAJYRLB7I3UONQBQOQOPF7 X-MailFrom: yuhuang@redhat.com 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: Stefano Brivio , 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: On Fri, Oct 24, 2025 at 11:30=E2=80=AFAM David Gibson wrote: > > On Fri, Oct 24, 2025 at 01:04:27AM +0200, Stefano Brivio wrote: > > Sorry for the delay, mostly nits but a couple of substantial comments: > > > > On Fri, 17 Oct 2025 14:28:36 +0800 > > Yumei Huang wrote: > > > > > Signed-off-by: Yumei Huang > > > --- > > > util.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++ > > > util.h | 8 ++++++ > > > 2 files changed, 92 insertions(+) > > > > > > diff --git a/util.c b/util.c > > > index c492f90..5c8c4bc 100644 > > > --- a/util.c > > > +++ b/util.c > > > @@ -579,6 +579,90 @@ int write_file(const char *path, const char *buf= ) > > > return len =3D=3D 0 ? 0 : -1; > > > } > > > > > > +/** > > > + * read_file() - Read contents of file into a buffer > > > + * @path: File to read > > > > I see this is the same as write_file(), so in some sense it's > > pre-existing, but @path isn't really a "file" in the sense that it's > > not a file descriptor as one might expect from the description alone. > > > > I'd rather say "Path to file" or "Path to file to read" or something > > like that. On the other hand, if you want to keep this consistent with > > write_file(), never mind. Not a strong preference from me. > > That's a good idea, but it's not crucial to the aim of this series, so > I'd suggest doing it as a later patch. > > > > + * @buf: Buffer to store file contents > > > + * @buf_size: Size of buffer > > > + * > > > + * Return: number of bytes read on success, -1 on any error, -2 on t= runcation > > > > Similar comment here: this is partially symmetric to read_file, but > > it's yet another convention we are introducing, because of the -2 > > special value. > > > > Other somewhat related functions in util.c return with a meaningful > > errno value set, this one doesn't. > > > > The majority of helpers in passt, though, return with a negative > > errno-like value, and truncation can be very well represented by > > returning -ENOBUFS, see snprintf_check(). I think that's preferable. > > > > Again, if the intention is to make this consistent to write_file(), it > > can be left as it is. > > Similarly. I considered commenting earlier on the -2 or truncation - > we don't actually use this, and it's a bit ugly. On the other hand it > doesn't hurt anything, so again, I think it can wait. > > > > +*/ > > > +ssize_t read_file(const char *path, char *buf, size_t buf_size) > > > +{ > > > + int fd =3D open(path, O_RDONLY | O_CLOEXEC); > > > + size_t total_read =3D 0; > > > + ssize_t rc; > > > + > > > + if (fd < 0) { > > > + warn_perror("Could not open %s", path); > > > + return -1; > > > + } > > > + > > > + while (total_read < buf_size) { > > > + rc =3D read(fd, buf + total_read, buf_size - total_read); > > > + > > > + if (rc < 0) { > > > + warn_perror("Couldn't read from %s", path); > > > + close(fd); > > > + return -1; > > > + } > > > + > > > + if (rc =3D=3D 0) > > > + break; > > > + > > > + total_read +=3D rc; > > > > Coverity Scan (I can provide instructions separately if desired) > > reports one issue below, but I'll mention it here for clarity: you are > > adding 'rc', of type ssize_t, to total_read, of type size_t, and > > buf_size is also of type size_t, so you could overflow total_read by > > adding for example the maximum value for ssize_t twice, to it. > > > > We can't run into the (theoretical) issue fixed by d836d9e34586 ("util: > > Remove possible quadratic behaviour from write_remainder()") but the > > solution here might be similar. > > > > In general we should make sure that rc is less than whatever value we > > might sum to total_read to make it overflow at any point in time. > > > > I didn't really check this in detail, I can do that if needed, and > > perhaps David remembers more clearly what we did in a similar > > situation. It might also be a false positive, by the way. > > I think there are two slightly overlapping issues here. > > 1) I'm not sure Coverity knows/trusts that read() will never return > more than its third argument. That's what stops total_read from > ever exceeding buf_size. I'd need to think a bit harder about how > to convince it that's the case. > > 2) buf_size is size_t, but we're returning ssize_t. If we passed a > buf_size greater than ssize_t can hold, it would make a mess (UB, I > think). I don't think there are any perfectly elegant solutions in > C, so I'd suggest: > ASSERT(buf_size <=3D SSIZE_MAX); > > at the top of the function. > > I'd try (2) first because it's a real (if unlikely to be triggered) > Yumei, I can walk > you through how to install and run Coverity locally using Red Hat's > subscription. That would be great! > > [snip] > > > + } > > > + > > > + close(fd); > > > + > > > + if (total_read =3D=3D buf_size) { > > > + warn("File %s truncated, buffer too small", path); > > > > The file wasn't truncated (on disk) as this comment might seem to > > indicate. I'd rather say "File contents exceed buffer size", or > > "Partial file read", something like that. > > > > While at it, you could print the size we read (it's %zu, see similar > > examples where we print size_t types). > > > > > + return -2; > > > > Safer to NULL-terminate also in this case, perhaps? A future caller > > might handle -2 (or equivalent) as a "partial" failure and use the > > buffer anyway, so not NULL-terminating it is rather subtle. > > That's a good idea. Given the purpose of the function, I think a > caller _should_ ignore the buffer if it gets an error, but it's > worthwhile to limit the damage if a caller forgets to check. That > applies for other error cases too. > > -- > 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 wa= y > | around. > http://www.ozlabs.org/~dgibson --=20 Thanks, Yumei Huang