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=YpAmMgoq; 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 723325A0619 for ; Tue, 28 Oct 2025 08:11:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761635508; 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=RD3XnvBqT6xu7L5yBHXpiQxtn4lrysFtGXrSGJw7Zrc=; b=YpAmMgoqJFWfz3a0BgNkQbansYcWYwkapoukUgCBp6dFxXc8lIIqj3+RCYdeEVRnOjqczQ /UgCXbYlaEqPngnTTnqOpDHcMoX/3jJ1Yiu/HrpjqJqcxK4jNdWqhPVhNGneM5vxlP14QN 6o737HXTpNlYw+0bct3sdE/1INthV1o= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-JR2hhEJaOGab6o-Hf2N4XA-1; Tue, 28 Oct 2025 03:11:46 -0400 X-MC-Unique: JR2hhEJaOGab6o-Hf2N4XA-1 X-Mimecast-MFC-AGG-ID: JR2hhEJaOGab6o-Hf2N4XA_1761635505 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-63c55116bdfso4597550a12.3 for ; Tue, 28 Oct 2025 00:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761635505; x=1762240305; 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=RD3XnvBqT6xu7L5yBHXpiQxtn4lrysFtGXrSGJw7Zrc=; b=Y3dw4MOBYPYynWCWmkjLsab9rdGksBNYTDVmxn33EL8iiYuA0bBqha5FDNeZMZsWOI QgQYbtqPtu519jGvbJXpbehtFhTIAgRPMeqjWaFBEdNOzabAKgbJyhQanooFzizKIJoM AzKVRqx0EBMLDJGusoIRJNhHkCIu8PlG5EOJIEW/qXK3t7Of2Kl6q/q8K00l4sKbhHMA 3LXS/+TmWVHC8fZ69jnbDc+AJmxm/Uq7v2GcoWEK6qeZMgiNKMjOprLG2DbdmmYClVJA ZyK+EZjZ3bjntu5GGRBnH/EJVykxvU+yMdG9lMIfaHCexRVs3VyYtPDTm14Mi0yUu1bQ YHYQ== X-Forwarded-Encrypted: i=1; AJvYcCV9+jjFQIB0OzTdUkPY0Q+r65zD0fNVj3cdk/lMFq40TWe6UuO/Al95tFmssMKONDEb+ILW66MOl3c=@passt.top X-Gm-Message-State: AOJu0Yxe/+qTQc95EgH/zFYAv2HTHNSclVC3O06mj0mwGGWbKlWs3Riz 026AE2ojMUvSLiywSWcv+RR/GvkM8TFpoiuOzPVSEMpFyaXQeY4ee511SCMtGMvbEoiUfkwcDPI zOmaPFJdc+P5nkXicnihtXXHlgdI76rTqTI670AqGHuBCCJX6B96e2Q7Gq+xO889RPHDtzGOTYf vf9egwcVGYrO3zOwD4ZsLo9QqLlDsN X-Gm-Gg: ASbGncuNuT409fUZmu62NNjAdrAJBgjIrCF4pd8OBVNOvXQWsnI0jGEyC1jOON+pJKZ r3ykDximEAG3PiVqAkkDes+ibJ2inRUDXFIXUMxgt6I7LpDTM6kF2SGmscBNYyuf93jFVzfRAFg VKP+Blf+pzaUaPAJTaBOogjNm1hso3pVxqSfszR7FaU0WSbuzHTFsc11g8 X-Received: by 2002:a05:6402:4313:b0:63b:dc3e:f01c with SMTP id 4fb4d7f45d1cf-63ed8109264mr2159330a12.12.1761635504584; Tue, 28 Oct 2025 00:11:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEtB+4koCoSF03Fwo3bszzX9AB5lMw0NIOfPGVqSX1gnz1FrV/qwKwnErUtg+XbP0lEvPsfUk3x9VjSqjK1g+g= X-Received: by 2002:a05:6402:4313:b0:63b:dc3e:f01c with SMTP id 4fb4d7f45d1cf-63ed8109264mr2159297a12.12.1761635503989; Tue, 28 Oct 2025 00:11:43 -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: Tue, 28 Oct 2025 15:11:32 +0800 X-Gm-Features: AWmQ_bmL87up36-wpAHzKMjHOvUs_XySUL9Ke1VXLG8CUlukJhG7WC20lBjc0_w 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: Y5LDS42Y_QxlTEYyk6ps42Qtsj75ZED-QANRnx331is_1761635505 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RGP56BF7IWL72SUG6J76RVGEPIA3QQBD X-Message-ID-Hash: RGP56BF7IWL72SUG6J76RVGEPIA3QQBD 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. Thank you. As I have to respin and this a minor change, I will update that in v7. > > > > + * @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. Same here. > > > > +*/ > > > +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) > bug. Then we can see if Coverity still complains (Yumei, I can walk > you through how to install and run Coverity locally using Red Hat's > subscription). Coverity doesn't complain about it in my setup. Stefano may give more info on that. In a word, it's a false positive. > > [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. The rest will update in v7 as well. > > -- > 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 -- Thanks, Yumei Huang