]> granicus.if.org Git - libevent/commit
Fix ssl/bufferevent_wm_filter when bev does not reach watermark on break
authorAzat Khuzhin <a3at.mail@gmail.com>
Sun, 4 Nov 2018 17:40:04 +0000 (20:40 +0300)
committerAzat Khuzhin <a3at.mail@gmail.com>
Sun, 4 Nov 2018 18:41:13 +0000 (21:41 +0300)
commit66304a23cf748714159c988e78f35401c5352827
treea6499b95978b693625f6bff72dde6b0f734b5cfc
parente8c407e7b56ced5cb2b76dd92e708148a71e2be9
Fix ssl/bufferevent_wm_filter when bev does not reach watermark on break

For the ssl/bufferevent_wm* we have next configuration:
- payload_len = 1024
- wm_high     = 5120
- limit       = 40960
- to_read     = 512

In this test we expect that with high watermark installed to "wm_high"
we will read "limit" bytes by reading "to_read" at a time, but adding
"payload_len" at a time (this "to_read"/"payload_len" limits is
installed to finally overflow watermark).

Once we read "limit" bytes we break, by disable EV_READ and reset
callbacks. Although this will not work if when we want to break we do
not reach watermark, this is because watermarks installs evbuffer
callback for the input buffer and if the watermark does not reached it
will enable EV_READ while be_openssl_enable() will read from the
underlying buffer (in case the openssl bufferevent created via
bufferevent_openssl_filter_new()) and call callback again (until it will
reach watermark or read al from the underlying buffer -- this is why it
stops in our caes).

And this is exactly what happened in win32, you can see this in the
following logs:

- win32 before:
    OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 40960
    OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
    OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 41472
    OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
    OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 41984
    OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
    OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 42496
    OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break

- win32 after:
    OK C:\vagrant\test\regress_ssl.c:821: wm_transfer-client(00FC26F0): break
    OK C:\vagrant\test\regress_ssl.c:836: wm_transfer-client(00FC26F0): in: 4800, out: 0, got: 40960

- linux before:
    OK ../test/regress_ssl.c:829: wm_transfer-client(0x55555566f5e0): in: 5120, out: 0, got: 40960
    OK ../test/regress_ssl.c:834: wm_transfer-client(0x55555566f5e0): break

- linux after:
    OK ../test/regress_ssl.c:821: wm_transfer-client(0x55555566f5e0): break
    OK ../test/regress_ssl.c:836: wm_transfer-client(0x55555566f5e0): in: 5120, out: 0, got: 40960

(As you can see in linux case we already reach watermark hence it passed
before).

So fix the issue by breaking before draining.

But during fixing this I was thinking is this right? I.e. reading from
the be_openssl_enable(), maybe we should force deferred callbacks at
least?
test/regress_ssl.c