From batanun at hotmail.com Wed Mar 2 16:49:31 2022 From: batanun at hotmail.com (Batanun B) Date: Wed, 2 Mar 2022 16:49:31 +0000 Subject: Confusion about LTS versions. Any comprehensive documentation regarding everything LTS? Message-ID: Hi, Is there any documentation focused on the LTS versions of Varnish Cache? And with that I mean things like "What does the LTS version of Varnish mean?", "Why should or shouldn't I choose an LTS version?", "What is the latest LTS version?" and "How do I install an LTS version?". Currently I can't find any such documentation anywhere. We use Varnish Cache 6.0 LTS (6.0.6) now, on Ubuntu 18.04 LTS. I'm testing setting up a new Varnish server, on Ubuntu 20.04 LTS, and it automatically installs Varnish 6.2.1-2. Is that an LTS version? How can I verify that? And if not, how can I make sure that the version being selected is an LTS version? I followed the instructions at https://packagecloud.io/varnishcache/varnish60lts/install#manual-deb and in the file varnishcache_varnish60lts.list I made sure to change "trusty" to "focal" to match the Ubuntu version. Also, the "Releases & Downloads" page is quite confusing. First, it doesn't say _anything_ about LTS versions. Secondly, it specifically mentions version 7.0.2, 6.6.2 and 6.0.10 as supported, and says "All releases not mentioned above are End-Of-Life and unsupported". What does that mean? https://varnish-cache.org/releases/ Also, is there a place where we can see the roadmap for future planned LTS versions? Now I have no idea if there will be a new LTS coming next week, next year, or 2030. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume.quintard at gmail.com Wed Mar 2 17:02:52 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Wed, 2 Mar 2022 09:02:52 -0800 Subject: Confusion about LTS versions. Any comprehensive documentation regarding everything LTS? In-Reply-To: References: Message-ID: Hi, Would this help? https://lists.archive.carbon60.com/varnish/misc/49998 Cheers, -- Guillaume Quintard On Wed, Mar 2, 2022 at 8:51 AM Batanun B wrote: > Hi, > > Is there any documentation focused on the LTS versions of Varnish Cache? > And with that I mean things like "What does the LTS version of Varnish > mean?", "Why should or shouldn't I choose an LTS version?", "What is the > latest LTS version?" and "How do I install an LTS version?". > > Currently I can't find any such documentation anywhere. > > We use Varnish Cache 6.0 LTS (6.0.6) now, on Ubuntu 18.04 LTS. I'm testing > setting up a new Varnish server, on Ubuntu 20.04 LTS, and it automatically > installs Varnish 6.2.1-2. > > Is that an LTS version? How can I verify that? And if not, how can I make > sure that the version being selected is an LTS version? > > I followed the instructions at > https://packagecloud.io/varnishcache/varnish60lts/install#manual-deb and > in the file varnishcache_varnish60lts.list I made sure to change "trusty" > to "focal" to match the Ubuntu version. > > Also, the "Releases & Downloads" page is quite confusing. First, it > doesn't say _anything_ about LTS versions. Secondly, it specifically > mentions version 7.0.2, 6.6.2 and 6.0.10 as supported, and says "All > releases not mentioned above are End-Of-Life and unsupported". What does > that mean? > > https://varnish-cache.org/releases/ > > Also, is there a place where we can see the roadmap for future planned LTS > versions? Now I have no idea if there will be a new LTS coming next week, > next year, or 2030. > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From batanun at hotmail.com Wed Mar 2 17:17:59 2022 From: batanun at hotmail.com (Batanun B) Date: Wed, 2 Mar 2022 17:17:59 +0000 Subject: Confusion about LTS versions. Any comprehensive documentation regarding everything LTS? In-Reply-To: References:

Message-ID: Hi Guillaume, Well, not really. It is a snapshot of the state almost two years ago, and I expected some page where the information is kept up-to-date. And LTS is only mentioned two times in that email, not answering any of my LTS questions. Is there an up-to-date list of _all_ LTS versions (down to the minor version number)? Now I have no idea how to check if 6.2.1-2 is LTS or not. Is an LTS version just saying that "version x.y.z is LTS"? Or are the LTS versions completely separate from the non-LTS versions? As in, can there exist an LTS version 1.2.3 and a non-LTS 1.2.3 which does not contain the same thing? Any info on upcoming LTS versions? I'm specifically interested in new non-minor versions, like 6.6 or 7.0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Fri Mar 4 07:22:36 2022 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 04 Mar 2022 07:22:36 +0000 Subject: Confusion about LTS versions. Any comprehensive documentation regarding everything LTS? In-Reply-To: References:

Message-ID: <202203040722.2247MaJV004666@critter.freebsd.dk> -------- Batanun B writes: > Any info on upcoming LTS versions? I'm specifically interested in new non-minor versions, like 6.6 or 7.0. > The official status is on the "downloads" page of the project homepage: http://varnish-cache.org/releases/index.html I will admit that is pretty sparse information, but it is also as precise as we have it at this time. We generally only have one LTS release at any one time, although there can be small overlaps when we jump from one LTS to another. My advice would be to pick any release you want from LTS or younger. Upgrades, or even downgrades, between versions are close to painless. Poul-Henning -- 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 geoff at uplex.de Fri Mar 4 08:02:06 2022 From: geoff at uplex.de (Geoff Simmons) Date: Fri, 4 Mar 2022 09:02:06 +0100 Subject: Confusion about LTS versions. Any comprehensive documentation regarding everything LTS? In-Reply-To: <202203040722.2247MaJV004666@critter.freebsd.dk> References:

<202203040722.2247MaJV004666@critter.freebsd.dk> Message-ID: <540f970c-73cb-5e8b-e335-d9a70124e0a5@uplex.de> > Batanun B writes: > >> Any info on upcoming LTS versions? I'm specifically interested in >> new non-minor versions, like 6.6 or 7.0. This thread has helped me notice that some things I knew about LTS don't appear to be stated very obviously in the docs. LTS versions have been at an N.M.x version for years at a time. Currently 6.0.x, before that it was 4.1.x. That does change, but rarely. "Long term" is for real. But LTS versions don't ordinarily fall very far behind current development, because fixes and new features are backported to LTS as long as they aren't breaking changes. So if you're wondering about 6.6 or 7.0, is it because of some specific feature? If so, did that feature introduce a breaking change? If so, then you probably need 7.0. If you're just interested in an LTS version with recent fixes and maintenance, then you're probably all right with the most recent LTS version, currently 6.0.10. Details about features and fixes in the LTS versions are in doc/changes.rst in the 6.0 branch of the git repo: https://github.com/varnishcache/varnish-cache/blob/6.0/doc/changes.rst Peace, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From beuc at beuc.net Fri Mar 11 16:58:37 2022 From: beuc at beuc.net (Sylvain Beucler) Date: Fri, 11 Mar 2022 17:58:37 +0100 Subject: Determining whether VSV00008 affects 4.0.x Message-ID: Hello, I'm working on Debian security updates, and we're looking at fixing VSV00008 for Debian jessie (varnish 4.0.2). AFAICT this version is not affected by VSV00008. I'm posting my findings here in case this helps others distros or vendors. The test case for this vulnerability (f00008.vtc) passes for 4.0.x starting with 4.0.2. (note: backporting the test case requires s/resp.reason/resp.msg/) git-bissect shows that from: https://github.com/varnishcache/varnish-cache/commit/d11d4419f3f9fa1d70e984f80c2078ea44e9e53c (<4.0.2) "Deal with any remaining request body in cnt_synth" until: https://github.com/varnishcache/varnish-cache/commit/0c35ac8a7df799b53c31d8429206b928a9b9ca2b (<4.1.0-beta1) "Use the HTTP/1 VFP's for fetching the req.body" varnish-cache does not set "connection: keep-alive", but sets "connection: closes" as expected, which also matches the documentation work-around for VSV00008. Backporting VSV00008's fix for 4.0.2 does not appear to alter this behavior. So AFAICT we do not need to fix VSV00008 for 4.0.2 in Debian jessie. If you think I'm mistaken I'd be grateful if you could let me know. Cheers! Sylvain Beucler Debian LTS Team From martin at varnish-software.com Tue Mar 15 10:18:48 2022 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Tue, 15 Mar 2022 11:18:48 +0100 Subject: Determining whether VSV00008 affects 4.0.x In-Reply-To: References: Message-ID: Hello Sylvain, I believe the reason that you are seeing the test case succeed on 4.0.x regardless of if the fix for VSV00008 has been applied comes down to how the test case is constructed. The test case makes the Varnish server answer with a synthetic response (a response generated by VCL code internal to the Varnish server, as opposed to backend generated responses that Varnish normally delivers), because that is a convenient way to trigger the relevant code paths. And in Varnish prior to version 4.1 I believe, Varnish would always close the client connection when doing synthetic responses, meaning the test case always succeeds there. Though synthetic responses are not the only way to trigger the problematic code paths in Varnish. Any request handling that would end up with Varnish wanting to read and discard the unused request body from the client socket before starting a response delivery would be susceptible to the bug. One way to test it could maybe be to use a GET request with a request body on a URL that would result in a cache hit. These would then I presume also open the vulnerability on 4.0.x, but unfortunately a test case using this approach has not been constructed. When working on this vulnerability, we did not test specifically any Varnish versions prior to the supported releases, which stops at Varnish 6.0 LTS series as the oldest. Though code analysis suggests this vulnerability to be present since the very first releases, as listed in our vulnerability description. Regards, Martin Blix Grydeland On Fri, 11 Mar 2022 at 17:59, Sylvain Beucler wrote: > Hello, > > I'm working on Debian security updates, and we're looking at fixing > VSV00008 for Debian jessie (varnish 4.0.2). > > AFAICT this version is not affected by VSV00008. I'm posting my findings > here in case this helps others distros or vendors. > > The test case for this vulnerability (f00008.vtc) passes for 4.0.x > starting with 4.0.2. > (note: backporting the test case requires s/resp.reason/resp.msg/) > > git-bissect shows that from: > > https://github.com/varnishcache/varnish-cache/commit/d11d4419f3f9fa1d70e984f80c2078ea44e9e53c > (<4.0.2) "Deal with any remaining request body in cnt_synth" > until: > > https://github.com/varnishcache/varnish-cache/commit/0c35ac8a7df799b53c31d8429206b928a9b9ca2b > (<4.1.0-beta1) "Use the HTTP/1 VFP's for fetching the req.body" > varnish-cache does not set "connection: keep-alive", but sets > "connection: closes" as expected, which also matches the documentation > work-around for VSV00008. > > Backporting VSV00008's fix for 4.0.2 does not appear to alter this > behavior. > > So AFAICT we do not need to fix VSV00008 for 4.0.2 in Debian jessie. > If you think I'm mistaken I'd be grateful if you could let me know. > > Cheers! > Sylvain Beucler > Debian LTS Team > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- [image: A picture containing night sky Description automatically generated] Martin Blix Grydeland Senior Engineer | Varnish Software Group Cache Smarter, Store More, Deliver Faster www.varnish-software.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beuc at beuc.net Wed Mar 16 18:34:20 2022 From: beuc at beuc.net (Sylvain Beucler) Date: Wed, 16 Mar 2022 19:34:20 +0100 Subject: Determining whether VSV00008 affects 4.0.x In-Reply-To: References: Message-ID: <1ac5f09f-5c3c-3484-0e5f-d9d504c5636b@beuc.net> Hello Martin, Thank you for your detailed answer. Indeed I could reproduce the 'Connection:' behavior in 6.0.9 (unfixed, "keep-alive") vs 6.0.10 (fixed, "close") using an undersized GET body, mimicking the test case timeout: $ nc -v localhost 6081 < req.txt (req.txt attached) However I noted that 4.0.x always sets 'Connection: close' (and does close the connection) using this test, with or without my patch, unlike 3.0.7 or 4.1.11, so it seems there's a specific behavior for the whole 4.0.x branch. (no actual request smuggling detected with this test though) If you happen to have a reproducer for this vulnerability I'd be grateful and perform more tests. Otherwise I'll probably abstain from untestable patching and point users to the mitigation. Cheers! Sylvain PS: for the record 3.0.7 and 4.0.x < 4.0.2 do set "Connection: keep-alive" with f00008.vtc AFAICT On 15/03/2022 11:18, Martin Blix Grydeland wrote: > I believe the reason that you are seeing the test case succeed on 4.0.x > regardless of if the fix for VSV00008 has been applied comes down to how > the test case is constructed. The test case makes the Varnish server > answer with a synthetic response (a response generated by VCL code > internal to the Varnish server, as opposed to backend generated > responses that Varnish normally delivers), because that is a convenient > way to trigger the relevant code paths. And in Varnish prior to version > 4.1 I believe, Varnish would always close the client connection when > doing synthetic responses, meaning the test case always succeeds there. > > Though synthetic responses are not the only way to trigger the > problematic code paths in Varnish. Any request handling that would end > up with Varnish wanting to read and discard the unused request body from > the client socket before starting a response delivery would be > susceptible to the bug. One way to test it could maybe be to use a GET > request with a request body on a URL that would result in a cache hit. > These would then I presume also open the vulnerability on 4.0.x, but > unfortunately a test case using this approach has not been constructed. > > When working on this vulnerability, we did not test specifically any > Varnish versions prior to the supported releases, which stops at Varnish > 6.0 LTS series as the oldest. Though code analysis suggests this > vulnerability to be present since the very first releases, as listed in > our vulnerability description. > > Regards, > Martin Blix Grydeland > > On Fri, 11 Mar 2022 at 17:59, Sylvain Beucler > wrote: > > Hello, > > I'm working on Debian security updates, and we're looking at fixing > VSV00008 for Debian jessie (varnish 4.0.2). > > AFAICT this version is not affected by VSV00008. I'm posting my > findings > here in case this helps others distros or vendors. > > The test case for this vulnerability (f00008.vtc) passes for 4.0.x > starting with 4.0.2. > (note: backporting the test case requires s/resp.reason/resp.msg/) > > git-bissect shows that from: > https://github.com/varnishcache/varnish-cache/commit/d11d4419f3f9fa1d70e984f80c2078ea44e9e53c > > (<4.0.2) "Deal with any remaining request body in cnt_synth" > until: > https://github.com/varnishcache/varnish-cache/commit/0c35ac8a7df799b53c31d8429206b928a9b9ca2b > > (<4.1.0-beta1) "Use the HTTP/1 VFP's for fetching the req.body" > varnish-cache does not set "connection: keep-alive", but sets > "connection: closes" as expected, which also matches the documentation > work-around for VSV00008. > > Backporting VSV00008's fix for 4.0.2 does not appear to alter this > behavior. > > So AFAICT we do not need to fix VSV00008 for 4.0.2 in Debian jessie. > If you think I'm mistaken I'd be grateful if you could let me know. -------------- next part -------------- A non-text attachment was scrubbed... Name: CVE-2022-23959.patch Type: text/x-patch Size: 782 bytes Desc: not available URL: -------------- next part -------------- GET / HTTP/1.1 Host: localhost:6081 Content-Length: 25 GET /smug HTTP/1.0 From lee.hambley at gmail.com Wed Mar 23 14:26:44 2022 From: lee.hambley at gmail.com (Lee Hambley) Date: Wed, 23 Mar 2022 15:26:44 +0100 Subject: Question regarding lifetime of PRIV_TASK pointer Message-ID: Dear List, I inherited a project using PRIV_TASK [1] for which the documentation says: PRIV_TASK ?per task? private pointers are useful for state that applies to calls for either a specific request or a backend request. For instance this can be the result of a parsed cookie specific to a client. Note that PRIV_TASK contexts are separate for the client side and the backend side, so use in vcl_backend_* will yield a different private pointer from the one used on the client side. These private pointers live only for the duration of their task. We do a form of reference counting in our internal data structures, and the PRIV_TASK pointer in parts is used to hold a (counted) reference to some data in the shared structure. We are struggling to find the latest possible safest place to hook where PRIV_TASK is about to be invalid (end of the request) so that we can safely, and finally decrement the reference count and clean-up. Writing this out now, I suspect that there's a safe exit from the state machine [2] where we could modify our VCL to include a call to a clean-up function in our vmod, however it's not clear to me if this would be "safe" (restarts, request coalescing, etc, etc) In short then, is there an obvious place into which we can hook which is the place where Varnish is already about to discard the "task" and it is unoquivically safe for us to decrement our reference counted pointer to the PRIV_TASK referenced data? Thanks so much, very much enjoying being in a role hacking on Varnish, and Varnish adjacent stuff in my job currently. [1]: https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers [2]: https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/#finite-state-machine Lee Hambley http://lee.hambley.name/ +49 (0) 170 298 5667 -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume.quintard at gmail.com Wed Mar 23 16:15:29 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Wed, 23 Mar 2022 09:15:29 -0700 Subject: Question regarding lifetime of PRIV_TASK pointer In-Reply-To: References: Message-ID: Hi Lee, Looks like you had the right page, but missed the interesting part :-) In you https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers have this bit: > .fini will be called for a non-NULL .priv of the struct vmod_priv when the scope ends with that .priv pointer as its second argument besides a VRT_CTX. i.e. if your vmod_priv has a methods->fini pointer, it will be called when the vmod_priv is deleted. Was this what you were after, or did I misunderstand your question? -- Guillaume Quintard On Wed, Mar 23, 2022 at 7:28 AM Lee Hambley wrote: > Dear List, > > I inherited a project using PRIV_TASK [1] for which the documentation says: > > PRIV_TASK ?per task? private pointers are useful for state that applies > to calls for either a specific request or a backend request. For instance > this can be the result of a parsed cookie specific to a client. Note that > PRIV_TASK contexts are separate for the client side and the backend side, > so use in vcl_backend_* will yield a different private pointer from the > one used on the client side. These private pointers live only for the > duration of their task. > > We do a form of reference counting in our internal data structures, and > the PRIV_TASK pointer in parts is used to hold a (counted) reference to > some data in the shared structure. > > We are struggling to find the latest possible safest place to hook where > PRIV_TASK is about to be invalid (end of the request) so that we can > safely, and finally decrement the reference count and clean-up. > > Writing this out now, I suspect that there's a safe exit from the state > machine [2] where we could modify our VCL to include a call to a clean-up > function in our vmod, however it's not clear to me if this would be "safe" > (restarts, request coalescing, etc, etc) > > In short then, is there an obvious place into which we can hook which is > the place where Varnish is already about to discard the "task" and it is > unoquivically safe for us to decrement our reference counted pointer to the > PRIV_TASK referenced data? > > Thanks so much, very much enjoying being in a role hacking on Varnish, and > Varnish adjacent stuff in my job currently. > > [1]: > https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers > [2]: > https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/#finite-state-machine > > > Lee Hambley > http://lee.hambley.name/ > +49 (0) 170 298 5667 > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.hambley at gmail.com Thu Mar 24 13:45:59 2022 From: lee.hambley at gmail.com (Lee Hambley) Date: Thu, 24 Mar 2022 14:45:59 +0100 Subject: Question regarding lifetime of PRIV_TASK pointer In-Reply-To: References:

Message-ID: Hi, This is exaclty what we were looking for. Thank you sincerely. Lee Hambley http://lee.hambley.name/ +49 (0) 170 298 5667 On Wed, 23 Mar 2022 at 17:15, Guillaume Quintard < guillaume.quintard at gmail.com> wrote: > Hi Lee, > > Looks like you had the right page, but missed the interesting part :-) In > you > https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers > have this bit: > > > .fini will be called for a non-NULL .priv of the struct vmod_priv when > the scope ends with that .priv pointer as its second argument besides a > VRT_CTX. > > i.e. if your vmod_priv has a methods->fini pointer, it will be called > when the vmod_priv is deleted. > > Was this what you were after, or did I misunderstand your question? > > -- > Guillaume Quintard > > > On Wed, Mar 23, 2022 at 7:28 AM Lee Hambley wrote: > >> Dear List, >> >> I inherited a project using PRIV_TASK [1] for which the documentation >> says: >> >> PRIV_TASK ?per task? private pointers are useful for state that applies >> to calls for either a specific request or a backend request. For instance >> this can be the result of a parsed cookie specific to a client. Note that >> PRIV_TASK contexts are separate for the client side and the backend >> side, so use in vcl_backend_* will yield a different private pointer >> from the one used on the client side. These private pointers live only for >> the duration of their task. >> >> We do a form of reference counting in our internal data structures, and >> the PRIV_TASK pointer in parts is used to hold a (counted) reference to >> some data in the shared structure. >> >> We are struggling to find the latest possible safest place to hook where >> PRIV_TASK is about to be invalid (end of the request) so that we can >> safely, and finally decrement the reference count and clean-up. >> >> Writing this out now, I suspect that there's a safe exit from the state >> machine [2] where we could modify our VCL to include a call to a clean-up >> function in our vmod, however it's not clear to me if this would be "safe" >> (restarts, request coalescing, etc, etc) >> >> In short then, is there an obvious place into which we can hook which is >> the place where Varnish is already about to discard the "task" and it is >> unoquivically safe for us to decrement our reference counted pointer to the >> PRIV_TASK referenced data? >> >> Thanks so much, very much enjoying being in a role hacking on Varnish, >> and Varnish adjacent stuff in my job currently. >> >> [1]: >> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >> [2]: >> https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/#finite-state-machine >> >> >> Lee Hambley >> http://lee.hambley.name/ >> +49 (0) 170 298 5667 >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume.quintard at gmail.com Thu Mar 24 18:32:05 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Thu, 24 Mar 2022 11:32:05 -0700 Subject: Question regarding lifetime of PRIV_TASK pointer In-Reply-To: References:

Message-ID: My pleasure! Just to show off a bit, and because I know you have an eye on rust: https://github.com/gquintard/varnish-rs/blob/main/examples/vmod_timestamp/src/lib.rs VPriv (https://docs.rs/varnish/latest/varnish/vcl/vpriv/struct.VPriv.html) is the rust equivalent of vmod_priv and will properly be garbage-collected when dropped (yes, I do need to write some docs for it!) -- Guillaume Quintard On Thu, Mar 24, 2022 at 6:46 AM Lee Hambley wrote: > Hi, > > This is exaclty what we were looking for. Thank you sincerely. > > Lee Hambley > http://lee.hambley.name/ > +49 (0) 170 298 5667 > > > On Wed, 23 Mar 2022 at 17:15, Guillaume Quintard < > guillaume.quintard at gmail.com> wrote: > >> Hi Lee, >> >> Looks like you had the right page, but missed the interesting part :-) In >> you >> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >> have this bit: >> >> > .fini will be called for a non-NULL .priv of the struct vmod_priv when >> the scope ends with that .priv pointer as its second argument besides a >> VRT_CTX. >> >> i.e. if your vmod_priv has a methods->fini pointer, it will be called >> when the vmod_priv is deleted. >> >> Was this what you were after, or did I misunderstand your question? >> >> -- >> Guillaume Quintard >> >> >> On Wed, Mar 23, 2022 at 7:28 AM Lee Hambley >> wrote: >> >>> Dear List, >>> >>> I inherited a project using PRIV_TASK [1] for which the documentation >>> says: >>> >>> PRIV_TASK ?per task? private pointers are useful for state that applies >>> to calls for either a specific request or a backend request. For instance >>> this can be the result of a parsed cookie specific to a client. Note that >>> PRIV_TASK contexts are separate for the client side and the backend >>> side, so use in vcl_backend_* will yield a different private pointer >>> from the one used on the client side. These private pointers live only for >>> the duration of their task. >>> >>> We do a form of reference counting in our internal data structures, and >>> the PRIV_TASK pointer in parts is used to hold a (counted) reference to >>> some data in the shared structure. >>> >>> We are struggling to find the latest possible safest place to hook where >>> PRIV_TASK is about to be invalid (end of the request) so that we can >>> safely, and finally decrement the reference count and clean-up. >>> >>> Writing this out now, I suspect that there's a safe exit from the state >>> machine [2] where we could modify our VCL to include a call to a clean-up >>> function in our vmod, however it's not clear to me if this would be "safe" >>> (restarts, request coalescing, etc, etc) >>> >>> In short then, is there an obvious place into which we can hook which is >>> the place where Varnish is already about to discard the "task" and it is >>> unoquivically safe for us to decrement our reference counted pointer to the >>> PRIV_TASK referenced data? >>> >>> Thanks so much, very much enjoying being in a role hacking on Varnish, >>> and Varnish adjacent stuff in my job currently. >>> >>> [1]: >>> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >>> [2]: >>> https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/#finite-state-machine >>> >>> >>> Lee Hambley >>> http://lee.hambley.name/ >>> +49 (0) 170 298 5667 >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.hambley at gmail.com Wed Mar 30 14:53:58 2022 From: lee.hambley at gmail.com (Lee Hambley) Date: Wed, 30 Mar 2022 16:53:58 +0200 Subject: Question regarding lifetime of PRIV_TASK pointer In-Reply-To: References:

Message-ID: Hi Guillaume, Our problem is solved thanks to `methods` and cleanup (and the magic of `Arc`) Thanks so much the `struct.VPriv` looks very interesting, unfortuantely with our homebrew, ad-hoc bindings it's nothing we can profit from right away, but it's very nicely done, thanks for sharing. Cheers, and have a good day. Lee Hambley http://lee.hambley.name/ +49 (0) 170 298 5667 On Thu, 24 Mar 2022 at 19:32, Guillaume Quintard < guillaume.quintard at gmail.com> wrote: > My pleasure! > > Just to show off a bit, and because I know you have an eye on rust: > https://github.com/gquintard/varnish-rs/blob/main/examples/vmod_timestamp/src/lib.rs > > VPriv (https://docs.rs/varnish/latest/varnish/vcl/vpriv/struct.VPriv.html) > is the rust equivalent of vmod_priv and will properly be garbage-collected > when dropped (yes, I do need to write some docs for it!) > > -- > Guillaume Quintard > > > On Thu, Mar 24, 2022 at 6:46 AM Lee Hambley wrote: > >> Hi, >> >> This is exaclty what we were looking for. Thank you sincerely. >> >> Lee Hambley >> http://lee.hambley.name/ >> +49 (0) 170 298 5667 >> >> >> On Wed, 23 Mar 2022 at 17:15, Guillaume Quintard < >> guillaume.quintard at gmail.com> wrote: >> >>> Hi Lee, >>> >>> Looks like you had the right page, but missed the interesting part :-) >>> In you >>> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >>> have this bit: >>> >>> > .fini will be called for a non-NULL .priv of the struct vmod_priv when >>> the scope ends with that .priv pointer as its second argument besides a >>> VRT_CTX. >>> >>> i.e. if your vmod_priv has a methods->fini pointer, it will be called >>> when the vmod_priv is deleted. >>> >>> Was this what you were after, or did I misunderstand your question? >>> >>> -- >>> Guillaume Quintard >>> >>> >>> On Wed, Mar 23, 2022 at 7:28 AM Lee Hambley >>> wrote: >>> >>>> Dear List, >>>> >>>> I inherited a project using PRIV_TASK [1] for which the documentation >>>> says: >>>> >>>> PRIV_TASK ?per task? private pointers are useful for state that >>>> applies to calls for either a specific request or a backend request. For >>>> instance this can be the result of a parsed cookie specific to a client. >>>> Note that PRIV_TASK contexts are separate for the client side and the >>>> backend side, so use in vcl_backend_* will yield a different private >>>> pointer from the one used on the client side. These private pointers live >>>> only for the duration of their task. >>>> >>>> We do a form of reference counting in our internal data structures, and >>>> the PRIV_TASK pointer in parts is used to hold a (counted) reference to >>>> some data in the shared structure. >>>> >>>> We are struggling to find the latest possible safest place to hook >>>> where PRIV_TASK is about to be invalid (end of the request) so that we can >>>> safely, and finally decrement the reference count and clean-up. >>>> >>>> Writing this out now, I suspect that there's a safe exit from the state >>>> machine [2] where we could modify our VCL to include a call to a clean-up >>>> function in our vmod, however it's not clear to me if this would be "safe" >>>> (restarts, request coalescing, etc, etc) >>>> >>>> In short then, is there an obvious place into which we can hook which >>>> is the place where Varnish is already about to discard the "task" and it is >>>> unoquivically safe for us to decrement our reference counted pointer to the >>>> PRIV_TASK referenced data? >>>> >>>> Thanks so much, very much enjoying being in a role hacking on Varnish, >>>> and Varnish adjacent stuff in my job currently. >>>> >>>> [1]: >>>> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >>>> [2]: >>>> https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/#finite-state-machine >>>> >>>> >>>> Lee Hambley >>>> http://lee.hambley.name/ >>>> +49 (0) 170 298 5667 >>>> _______________________________________________ >>>> varnish-misc mailing list >>>> varnish-misc at varnish-cache.org >>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: