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=WSwFcej0; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 39EA65A0619 for ; Tue, 28 Oct 2025 12:43:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761651797; 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=fA5zvB5koaHN3GHmwLQNowDlZ5YVGUDQ+fIHbb0rJjg=; b=WSwFcej0PkBCyGfOiJ18dP/vUCvCud1Ox5q1Loamhz2ytzfC8McV4YFpevI5kCuEPL82Qc oEadK+D4UHv0E0L3NK2ARxR/nRjWY8nQJ+yV+IInrzMu9EK3bYusJtchbOVaUanQlIXCdH FkW29r19ULfogo4RnwZiPVW8BfBvLfs= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-685-idMnjeg3O9ufFjlYtuwkAg-1; Tue, 28 Oct 2025 07:43:15 -0400 X-MC-Unique: idMnjeg3O9ufFjlYtuwkAg-1 X-Mimecast-MFC-AGG-ID: idMnjeg3O9ufFjlYtuwkAg_1761651795 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-46e47d14dceso31174305e9.2 for ; Tue, 28 Oct 2025 04:43:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761651794; x=1762256594; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=k5TT6l7rC8fujNd3IhiSsR6JvtBco2mMRjg+CkF0uFI=; b=fqx+TZPFO+KUff0+US7vIyeOWQGxyKf8pOvK8N1aKO2McxGzGumehe5Oje2pRp15sX VwYZB6touMugEP+FqVmhBhNRLUgNdsEKMYaZXYgJO09OrodE6DDXE60zxQjaRl0/JWo1 U6MKPQ2H0E+llDVKJCIPLUO5kIX9XrTOEaZPAXXVId0jdOUb9z0NybhKFfR700GBUUkH Vp3lmueJchDfSQXpFDiL/ILUYP5xOSv36SkIuD381vEuEzoGb+BRKfACiScCWHqI665F weFFkpHBSwKsWycvsobYZfMGJPGRil0SF8M3fNdwg1If4dghekf3WNSQEZ6KuX5g5ryq BxDQ== X-Forwarded-Encrypted: i=1; AJvYcCXV5zeiMcdrWGvPB+BfTkbcG/RLCndkzcXKwZrlMEgwHsqhA9DcTjYzaOryF8QqrgaQFyVROViJhC8=@passt.top X-Gm-Message-State: AOJu0YyHTDQpk2er7SjIe+JBU68arBPo/q6rHPqVC+mYn1BAq/Q10gn/ RDXMCI2yTTryDn6Dh1mf5HD+ZhV8Zy03vowWMW5vBeO+HMRVPEZ8b8Q9+wCq9QfNVw7WSevI3Yv IqqY9k6TM3gb0U7lEU8V4gu5t0kWeocOzTDhaLVVO09bM2kFn9UHCAg== X-Gm-Gg: ASbGncv26kPDFrUQQDARf6DLRPkoytBCNzkPKRyI9aAOoGQ2szvt6YdAYEmZSdPIhtN 9FMxpsXqCZX7kx3qrgYwGF3eJFcbQnm5gS5iHxdb+SvPlssUncuommlOmRIDIVhXA79YuwLTbMG 8+FlvR53G7dPY57HSAsAVPf1HU9vvh8HcbsSMq/hZzZRyKtiPEp3Q3TLmtAIEPRRGhgXWTsbo8u DpE3H1bhjM8OI2z4c9JXa1bOWyhcINLU9Kab4QJveMQ5GA7rAq2BIAVLGuiE4rRRWlrwmaxGrtz Ad/WlRait7XZsZrbZVzl/EDG/yKLDEIULq5QU4KgueA8s4/d70hUejrAi06rO79/fcXgMv7a/vn HHGuTpP6XuA== X-Received: by 2002:a05:600c:3b15:b0:477:e09:f0f with SMTP id 5b1f17b1804b1-47717df68e2mr30333115e9.8.1761651794367; Tue, 28 Oct 2025 04:43:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGIUjrY7NrjvRphV3IsxdZD8q9rZUhoB+IqqPRjkbl7XR2U5dvjKVm6oQOm87PMCUB11wJYxA== X-Received: by 2002:a05:600c:3b15:b0:477:e09:f0f with SMTP id 5b1f17b1804b1-47717df68e2mr30332935e9.8.1761651793717; Tue, 28 Oct 2025 04:43:13 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-429952d5768sm20476751f8f.24.2025.10.28.04.43.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Oct 2025 04:43:12 -0700 (PDT) Date: Tue, 28 Oct 2025 12:43:10 +0100 From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH v6 2/4] util: Introduce read_file() and read_file_integer() function Message-ID: <20251028124310.0ad38211@elisabeth> In-Reply-To: References: <20251017062838.21041-1-yuhuang@redhat.com> <20251017062838.21041-3-yuhuang@redhat.com> <20251024010427.1c8d1032@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: NcXov6Kg_k6we5LSs7guYdsQx76yPwFP9MIMMT0a0oI_1761651795 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: JQAZN5ZJPVT6DJJQNREG23JDT3VVWMJ2 X-Message-ID-Hash: JQAZN5ZJPVT6DJJQNREG23JDT3VVWMJ2 X-MailFrom: sbrivio@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: David Gibson , 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 Tue, 28 Oct 2025 15:11:32 +0800 Yumei Huang wrote: > 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: =20 > > > Sorry for the delay, mostly nits but a couple of substantial comments= : > > > > > > On Fri, 17 Oct 2025 14:28:36 +0800 > > > Yumei Huang wrote: > > > =20 > > > > 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 *b= uf) > > > > return len =3D=3D 0 ? 0 : -1; > > > > } > > > > > > > > +/** > > > > + * read_file() - Read contents of file into a buffer > > > > + * @path: File to read =20 > > > > > > 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 wit= h > > > write_file(), never mind. Not a strong preference from me. =20 > > > > 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. =20 >=20 > Thank you. As I have to respin and this a minor change, I will update > that in v7. Just for clarity: I think David meant that it *should* be done as a separate patch (maybe in the same series, if you have a moment, but it's not that critical). I don't have a particular preference, but David's point makes sense to me. > > > > + * @buf: Buffer to store file contents > > > > + * @buf_size: Size of buffer > > > > + * > > > > + * Return: number of bytes read on success, -1 on any error, -2 on= truncation =20 > > > > > > 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(), i= t > > > can be left as it is. =20 > > > > 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. =20 >=20 > Same here. Same as above ("I think it can wait"). Well, up to you, really. > > > > +*/ > > > > +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; =20 > > > > > > Coverity Scan (I can provide instructions separately if desired) > > > reports one issue below, but I'll mention it here for clarity: you ar= e > > > 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 ("uti= l: > > > 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. =20 > > > > 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). =20 >=20 > Coverity doesn't complain about it in my setup. Stefano may give more > info on that. In a word, it's a false positive. Right, my bad, it turns out I was using an outdated version and this false positive doesn't appear anymore. > > [snip] =20 > > > > + } > > > > + > > > > + close(fd); > > > > + > > > > + if (total_read =3D=3D buf_size) { > > > > + warn("File %s truncated, buffer too small", path); =20 > > > > > > 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). > > > =20 > > > > + return -2; =20 > > > > > > 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. =20 > > > > 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. =20 >=20 > The rest will update in v7 as well. Thanks. --=20 Stefano