From scan-admin at coverity.com Mon May 6 08:10:43 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 06 May 2024 08:10:43 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <663890824f666_11c7ea2adb3d0179b047793@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DlbnR_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR3RHQseH9LYNQM0iRnKesxH4AHAjvCnr02R4OCfsJpoL8dGmamGTdwkHrIoPVR95NGtZpSQpHXbfrb4zDmm7Dn1MW1EKMVBoX0L91gZhBB-2BiJ0vV-2B6nximEFz3FBC39R9qYrmtbggOCPjqIH0nH-2F26BwkBiU5muvXprxS4QslQyHqf-2BmWF6MPSLZb9g7xLmYR0-3D Build ID: 611090 Analysis Summary: New defects found: 0 Defects eliminated: 0 From scan-admin at coverity.com Mon May 13 08:11:49 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 13 May 2024 08:11:49 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <6641cb44bc3fb_18d8a62adb3d0179b04772f@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DvI8k_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR02PHFBwZCW7Aah-2BiuBoy7Ac26hhIE0HJJALPcCYmK-2FAmN3lFRJJCoE0icfjrTuvLqsGgMQtahK16SHq17IacJfPIULciIzYDV2SCfCHC-2Fyt8emRxdvWM-2Be6VCjZjOgJU6sFlwMmbNBOTpFsc6dg1SVbAY4ckwTjCRI-2BSboNavbacdcwVoGfzqsdBEF3I2GnWQ-3D Build ID: 612842 Analysis Summary: New defects found: 0 Defects eliminated: 0 From scan-admin at coverity.com Mon May 20 08:48:31 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 20 May 2024 08:48:31 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <664b0e5f37def_3dd7d2df1ce92f994909d1@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DmgI9_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR1oWk8aKgZ-2FZqw69HIehGz8C8WXwP-2BGzs-2BtUcwjVIF7g0KKvEDCIeI0epUtNYEt4LtIfx-2FKeOV5i4X5B5gYxcvlrLIOW-2F8snF5vB4xZ2vn1ACFM46DXZu-2BBtGpAaI55BK-2BN1gzAC0A9dbzraQOcR-2BmxnsjUGhkLoJhYokwVxjC1LgtAS20rt3kmQHgfr99vykQ-3D Build ID: 614485 Analysis Summary: New defects found: 0 Defects eliminated: 0 From dridi at varni.sh Tue May 21 17:19:42 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 21 May 2024 17:19:42 +0000 Subject: SHA256 from file descriptor Message-ID: Hi, Are we interested in that kind of change (see attached diff) or do we strictly stick to the original source that was bundled in libvarnish? Dridi -------------- next part -------------- A non-text attachment was scrubbed... Name: sha256_fd.diff Type: text/x-patch Size: 1480 bytes Desc: not available URL: From phk at phk.freebsd.dk Tue May 21 17:38:19 2024 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 21 May 2024 17:38:19 +0000 Subject: SHA256 from file descriptor In-Reply-To: References: Message-ID: <202405211738.44LHcJPa007120@critter.freebsd.dk> Dridi Boukelmoune writes: > Are we interested in that kind of change (see attached diff) or do we > strictly stick to the original source that was bundled in libvarnish? What's the usecase ? If regular file: Why not mmap and save the kernel/userland copies ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Tue May 21 17:52:29 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 21 May 2024 17:52:29 +0000 Subject: SHA256 from file descriptor In-Reply-To: <202405211738.44LHcJPa007120@critter.freebsd.dk> References: <202405211738.44LHcJPa007120@critter.freebsd.dk> Message-ID: On Tue, May 21, 2024 at 5:38?PM Poul-Henning Kamp wrote: > > Dridi Boukelmoune writes: > > > Are we interested in that kind of change (see attached diff) or do we > > strictly stick to the original source that was bundled in libvarnish? > > What's the usecase ? > > If regular file: Why not mmap and save the kernel/userland copies ? Because the code from which I extracted this function was doing a copy while computing the checksum on the fly, so I didn't consider mmap when I extracted the read part of the code. Dridi From phk at phk.freebsd.dk Wed May 22 06:18:24 2024 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 22 May 2024 06:18:24 +0000 Subject: SHA256 from file descriptor In-Reply-To: References: <202405211738.44LHcJPa007120@critter.freebsd.dk> Message-ID: <202405220618.44M6IOub011326@critter.freebsd.dk> -------- Dridi Boukelmoune writes: > On Tue, May 21, 2024 at 5:38=E2=80=AFPM Poul-Henning Kamp dk> wrote: > > > > Dridi Boukelmoune writes: > > > > > Are we interested in that kind of change (see attached diff) or do we > > > strictly stick to the original source that was bundled in libvarnish? > > > > What's the usecase ? > > > > If regular file: Why not mmap and save the kernel/userland copies ? > > Because the code from which I extracted this function was doing a copy > while computing the checksum on the fly, so I didn't consider mmap > when I extracted the read part of the code. But what is the use-case ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Wed May 22 07:52:59 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 22 May 2024 07:52:59 +0000 Subject: SHA256 from file descriptor In-Reply-To: <202405220618.44M6IOub011326@critter.freebsd.dk> References: <202405211738.44LHcJPa007120@critter.freebsd.dk> <202405220618.44M6IOub011326@critter.freebsd.dk> Message-ID: > > > What's the usecase ? > > > > > > If regular file: Why not mmap and save the kernel/userland copies ? > > > > Because the code from which I extracted this function was doing a copy > > while computing the checksum on the fly, so I didn't consider mmap > > when I extracted the read part of the code. > > But what is the use-case ? My bad, in my mind replying about mmap implied that this was indeed about having a convenience functtion to compute the hash of a regular file. Would the attached patch be welcome? Slightly off topic, why have both definitions? #define VSHA256_LEN 32 #define VSHA256_DIGEST_LENGTH 32 Dridi -------------- next part -------------- A non-text attachment was scrubbed... Name: sha256_fd_with_mmap.diff Type: text/x-patch Size: 1354 bytes Desc: not available URL: From dridi at varni.sh Wed May 22 08:02:44 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 22 May 2024 08:02:44 +0000 Subject: SHA256 from file descriptor In-Reply-To: References: <202405211738.44LHcJPa007120@critter.freebsd.dk> <202405220618.44M6IOub011326@critter.freebsd.dk> Message-ID: > Slightly off topic, why have both definitions? > > #define VSHA256_LEN 32 > #define VSHA256_DIGEST_LENGTH 32 A question for upstream... https://github.com/varnishcache/varnish-cache/commit/1f631aa61dd170aa3bdd6485fbdb801c7cc36eb0 From phk at phk.freebsd.dk Wed May 22 08:16:54 2024 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 22 May 2024 08:16:54 +0000 Subject: SHA256 from file descriptor In-Reply-To: References: <202405211738.44LHcJPa007120@critter.freebsd.dk> <202405220618.44M6IOub011326@critter.freebsd.dk> Message-ID: <202405220816.44M8Gs5u012036@critter.freebsd.dk> -------- Dridi Boukelmoune writes: > My bad, in my mind replying about mmap implied that this was indeed > about having a convenience functtion to compute the hash of a regular > file. Yes, but what do we need that for ? > Would the attached patch be welcome? If we have a need, that's pretty much how I would do it. > Slightly off topic, why have both definitions? > > #define VSHA256_LEN 32 > #define VSHA256_DIGEST_LENGTH 32 I think I kept it to not break any VMODs which relied on it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Wed May 22 09:36:54 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 22 May 2024 09:36:54 +0000 Subject: SHA256 from file descriptor In-Reply-To: <202405220816.44M8Gs5u012036@critter.freebsd.dk> References: <202405211738.44LHcJPa007120@critter.freebsd.dk> <202405220618.44M6IOub011326@critter.freebsd.dk> <202405220816.44M8Gs5u012036@critter.freebsd.dk> Message-ID: > Yes, but what do we need that for ? We don't, I'm working in a VMOD that computes hashes of regular files among other things. This looked like generic code not specific to that VMOD. > > Would the attached patch be welcome? > > If we have a need, that's pretty much how I would do it. If you agree to expose this to VMODs, I can push this patch as is, modulus paint color. I'm not sure I would keep the name "VSHA256_Fd" if the fie descriptors are limited to regular (or mmap-able) files, maybe "VSHA256_File" or "VSHA256_Map" is a better fit. If we want to go all the way, I can also expose it to VUTs in libvarnishapi. Dridi From phk at phk.freebsd.dk Wed May 22 10:40:46 2024 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 22 May 2024 10:40:46 +0000 Subject: SHA256 from file descriptor In-Reply-To: References: <202405211738.44LHcJPa007120@critter.freebsd.dk> <202405220618.44M6IOub011326@critter.freebsd.dk> <202405220816.44M8Gs5u012036@critter.freebsd.dk> Message-ID: <202405221040.44MAeljj012947@critter.freebsd.dk> -------- Dridi Boukelmoune writes: > > Yes, but what do we need that for ? > > We don't, I'm working in a VMOD that computes hashes of regular files > among other things. This looked like generic code not specific to that > VMOD. Is it a VMOD you expect to be adopted into the tree, and if so, could you say a bit more about it ? If it is an out-of-tree VMOD, I'm not very keen on adding library functions just for one VMOD (but can probably be persuaded if the functions are tied to Varnish through data structures etc.) This specific suggestion does not meet that threshold, and we would also have to add an explicit test-case for gcov, so I really dont see much benefit ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Wed May 22 12:15:22 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 22 May 2024 12:15:22 +0000 Subject: SHA256 from file descriptor In-Reply-To: <202405221040.44MAeljj012947@critter.freebsd.dk> References: <202405211738.44LHcJPa007120@critter.freebsd.dk> <202405220618.44M6IOub011326@critter.freebsd.dk> <202405220816.44M8Gs5u012036@critter.freebsd.dk> <202405221040.44MAeljj012947@critter.freebsd.dk> Message-ID: On Wed, May 22, 2024 at 10:40?AM Poul-Henning Kamp wrote: > > -------- > Dridi Boukelmoune writes: > > > > Yes, but what do we need that for ? > > > > We don't, I'm working in a VMOD that computes hashes of regular files > > among other things. This looked like generic code not specific to that > > VMOD. > > Is it a VMOD you expect to be adopted into the tree, and if so, could > you say a bit more about it ? This is for a third-party VMOD. > If it is an out-of-tree VMOD, I'm not very keen on adding library > functions just for one VMOD (but can probably be persuaded if the > functions are tied to Varnish through data structures etc.) > > This specific suggestion does not meet that threshold, and we would > also have to add an explicit test-case for gcov, so I really dont > see much benefit ? The goal was to offer convenience, but this code is trivial to embed. Dridi From scan-admin at coverity.com Mon May 27 08:54:52 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 27 May 2024 08:54:52 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66544a5b62edb_ad1fb2df1ce92f99490928@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3Ds5_7_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR2iu2cBqiaDiQq9wG9SafZw-2BlBINgRq3x6kwG5QffgRjz9LKHiJMkHfqUBeL3nnhKj52oynSjdvIb3uBVuvdgOmN-2F-2BRSmsfgVQA8lXTmxxq4NEob7lFMnNyJy5u-2Fg6iryuZRsBBGkL-2FTBsOJOSHGiUKv6j4CMnznlDkuhEl-2FkjMpLcNPGdUtDrfhftsjkTr-2BHY-3D Build ID: 616195 Analysis Summary: New defects found: 0 Defects eliminated: 0