November 2016 - tor-commits - lists.torproject.org

[tor/master] Ask event_base_loop to finish when we add a pending stream
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit d89804a69d1b1f92076d47aac953776e1a3cd867 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Oct 31 00:23:53 2016 -0400 Ask event_base_loop to finish when we add a pending stream Fixes bug 19969; bugfix on b1d56fc58. We can fix this some more in later Tors, but for now, this is probably the right fix for us. --- changes/bug19969 | 10 ++++++++++ src/or/connection_edge.c | 9 +++++++++ 2 files changed, 19 insertions(+) diff --git a/changes/bug19969 b/changes/bug19969 new file mode 100644 index 0000000..0bdd880 --- /dev/null +++ b/changes/bug19969 @@ -0,0 +1,10 @@ + o Major bugfixes (client performance); + - Clients now respond to new application stream requests when + they arrive, rather than waiting up to one second before starting + to handle them. Fixes part of bug 19969; bugfix on 0.2.8.1-alpha. + + o Major bugfixes (clients on flaky network connections); + - When Tor leaves standby because of a new application request, open + circuits as needed to serve that request. Previously, we would + potentially wait a very long time. Fixes part of bug 19969; bugfix + on 0.2.8.1-alpha. diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index 754e976..8098fb0 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -892,6 +892,15 @@ connection_ap_mark_as_pending_circuit_(entry_connection_t *entry_conn, untried_pending_connections = 1; smartlist_add(pending_entry_connections, entry_conn); + + /* Work-around for bug 19969: we handle pending_entry_connections at + * the end of run_main_loop_once(), but in many cases that function will + * take a very long time, if ever, to finish its call to event_base_loop(). + * + * So the fix is to tell it right now that it ought to finish its loop at + * its next available opportunity. + */ + tell_event_loop_to_finish(); } /** Mark <b>entry_conn</b> as no longer waiting for a circuit. */

1 0

[tor/maint-0.2.9] Always call connection_ap_attach_pending() once a second.
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit b2f82d45b7e0166a8de3a7b6d38e288dd1e6d96e Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 31 14:42:26 2016 -0400 Always call connection_ap_attach_pending() once a second. Fixes bug 19969; bugfix on b1d56fc58. We can fix this some more in later Tors, but for now, this is probably the simplest fix possible. This is a belt-and-suspenders fix, where the earlier fix ("Ask event_base_loop to finish when we add a pending stream") aims to respond to new streams as soon as they arrive, and this one aims to make sure that we definitely respond to all of the streams. --- src/or/main.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/or/main.c b/src/or/main.c index cba19c3..d4d98ee 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -1525,6 +1525,12 @@ run_scheduled_events(time_t now) circuit_expire_old_circs_as_needed(now); } + if (!net_is_disabled()) { + /* This is usually redundant with circuit_build_needed_circs() above, + * but it is very fast when there is no work to do. */ + connection_ap_attach_pending(0); + } + /* 5. We do housekeeping for each connection... */ connection_or_set_bad_connections(NULL, 0); int i;

1 0

[tor/master] refactor out the tor_event_base_loopexit() call
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 28b755e66007c94521c45bdda07abdf3bcd59656 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Oct 31 00:20:22 2016 -0400 refactor out the tor_event_base_loopexit() call no actual changes --- src/or/main.c | 25 +++++++++++++++++-------- src/or/main.h | 2 ++ 2 files changed, 19 insertions(+), 8 deletions(-) diff --git a/src/or/main.c b/src/or/main.c index 6b5619c..cba19c3 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -726,6 +726,19 @@ connection_should_read_from_linked_conn(connection_t *conn) return 0; } +/** If we called event_base_loop() and told it to never stop until it + * runs out of events, now we've changed our mind: tell it we want it to + * finish. */ +void +tell_event_loop_to_finish(void) +{ + if (!called_loop_once) { + struct timeval tv = { 0, 0 }; + tor_event_base_loopexit(tor_libevent_get_base(), &tv); + called_loop_once = 1; /* hack to avoid adding more exit events */ + } +} + /** Helper: Tell the main loop to begin reading bytes into <b>conn</b> from * its linked connection, if it is not doing so already. Called by * connection_start_reading and connection_start_writing as appropriate. */ @@ -738,14 +751,10 @@ connection_start_reading_from_linked_conn(connection_t *conn) if (!conn->active_on_link) { conn->active_on_link = 1; smartlist_add(active_linked_connection_lst, conn); - if (!called_loop_once) { - /* This is the first event on the list; we won't be in LOOP_ONCE mode, - * so we need to make sure that the event_base_loop() actually exits at - * the end of its run through the current connections and lets us - * activate read events for linked connections. */ - struct timeval tv = { 0, 0 }; - tor_event_base_loopexit(tor_libevent_get_base(), &tv); - } + /* make sure that the event_base_loop() function exits at + * the end of its run through the current connections, so we can + * activate read events for linked connections. */ + tell_event_loop_to_finish(); } else { tor_assert(smartlist_contains(active_linked_connection_lst, conn)); } diff --git a/src/or/main.h b/src/or/main.h index ad865b8..6949376 100644 --- a/src/or/main.h +++ b/src/or/main.h @@ -45,6 +45,8 @@ int connection_is_writing(connection_t *conn); MOCK_DECL(void,connection_stop_writing,(connection_t *conn)); MOCK_DECL(void,connection_start_writing,(connection_t *conn)); +void tell_event_loop_to_finish(void); + void connection_stop_reading_from_linked_conn(connection_t *conn); void directory_all_unreachable(time_t now);

1 0

[tor/maint-0.2.8] Work around a behavior change in openssl's BUF_MEM code
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 9b18b215bb34c4df1b94dec218c68a532c341e26 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 10:46:27 2016 -0400 Work around a behavior change in openssl's BUF_MEM code In our code to write public keys to a string, for some unfathomable reason since 253f0f160e1185c, we would allocate a memory BIO, then set the NOCLOSE flag on it, extract its memory buffer, and free it. Then a little while later we'd free the memory buffer with BUF_MEM_free(). As of openssl 1.1 this doesn't work any more, since there is now a BIO_BUF_MEM structure that wraps the BUF_MEM structure. This BIO_BUF_MEM doesn't get freed in our code. So, we had a memory leak! Is this an openssl bug? Maybe. But our code was already pretty silly. Why mess around with the NOCLOSE flag here when we can just keep the BIO object around until we don't need the buffer any more? Fixes bug 20553; bugfix on 0.0.2pre8 --- changes/bug20553 | 3 +++ src/common/crypto.c | 5 ++--- src/tools/tor-gencert.c | 5 ++--- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/changes/bug20553 b/changes/bug20553 new file mode 100644 index 0000000..12a2780 --- /dev/null +++ b/changes/bug20553 @@ -0,0 +1,3 @@ + o Minor bugfixes (memory leak): + - Work around a memory leak in OpenSSL 1.1 when encoding public keys. + Fixes bug 20553; bugfix on 0.0.2pre8. diff --git a/src/common/crypto.c b/src/common/crypto.c index 2b96324..c5d07df 100644 --- a/src/common/crypto.c +++ b/src/common/crypto.c @@ -755,14 +755,13 @@ crypto_pk_write_key_to_string_impl(crypto_pk_t *env, char **dest, } BIO_get_mem_ptr(b, &buf); - (void)BIO_set_close(b, BIO_NOCLOSE); /* so BIO_free doesn't free buf */ - BIO_free(b); *dest = tor_malloc(buf->length+1); memcpy(*dest, buf->data, buf->length); (*dest)[buf->length] = 0; /* nul terminate it */ *len = buf->length; - BUF_MEM_free(buf); + + BIO_free(b); return 0; } diff --git a/src/tools/tor-gencert.c b/src/tools/tor-gencert.c index 5f2cd3a..ed6c066 100644 --- a/src/tools/tor-gencert.c +++ b/src/tools/tor-gencert.c @@ -429,12 +429,11 @@ key_to_string(EVP_PKEY *key) } BIO_get_mem_ptr(b, &buf); - (void) BIO_set_close(b, BIO_NOCLOSE); - BIO_free(b); result = tor_malloc(buf->length + 1); memcpy(result, buf->data, buf->length); result[buf->length] = 0; - BUF_MEM_free(buf); + + BIO_free(b); RSA_free(rsa); return result;

1 0

[tor/master] Merge branch 'maint-0.2.9'
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 0abaedbf3469dfca8833867feef789c6d4e59225 Merge: f0b86e3 3bb49c0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 15:41:18 2016 -0400 Merge branch 'maint-0.2.9'

1 0

[tor/maint-0.2.9] Work around a behavior change in openssl's BUF_MEM code
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 9b18b215bb34c4df1b94dec218c68a532c341e26 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 10:46:27 2016 -0400 Work around a behavior change in openssl's BUF_MEM code In our code to write public keys to a string, for some unfathomable reason since 253f0f160e1185c, we would allocate a memory BIO, then set the NOCLOSE flag on it, extract its memory buffer, and free it. Then a little while later we'd free the memory buffer with BUF_MEM_free(). As of openssl 1.1 this doesn't work any more, since there is now a BIO_BUF_MEM structure that wraps the BUF_MEM structure. This BIO_BUF_MEM doesn't get freed in our code. So, we had a memory leak! Is this an openssl bug? Maybe. But our code was already pretty silly. Why mess around with the NOCLOSE flag here when we can just keep the BIO object around until we don't need the buffer any more? Fixes bug 20553; bugfix on 0.0.2pre8 --- changes/bug20553 | 3 +++ src/common/crypto.c | 5 ++--- src/tools/tor-gencert.c | 5 ++--- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/changes/bug20553 b/changes/bug20553 new file mode 100644 index 0000000..12a2780 --- /dev/null +++ b/changes/bug20553 @@ -0,0 +1,3 @@ + o Minor bugfixes (memory leak): + - Work around a memory leak in OpenSSL 1.1 when encoding public keys. + Fixes bug 20553; bugfix on 0.0.2pre8. diff --git a/src/common/crypto.c b/src/common/crypto.c index 2b96324..c5d07df 100644 --- a/src/common/crypto.c +++ b/src/common/crypto.c @@ -755,14 +755,13 @@ crypto_pk_write_key_to_string_impl(crypto_pk_t *env, char **dest, } BIO_get_mem_ptr(b, &buf); - (void)BIO_set_close(b, BIO_NOCLOSE); /* so BIO_free doesn't free buf */ - BIO_free(b); *dest = tor_malloc(buf->length+1); memcpy(*dest, buf->data, buf->length); (*dest)[buf->length] = 0; /* nul terminate it */ *len = buf->length; - BUF_MEM_free(buf); + + BIO_free(b); return 0; } diff --git a/src/tools/tor-gencert.c b/src/tools/tor-gencert.c index 5f2cd3a..ed6c066 100644 --- a/src/tools/tor-gencert.c +++ b/src/tools/tor-gencert.c @@ -429,12 +429,11 @@ key_to_string(EVP_PKEY *key) } BIO_get_mem_ptr(b, &buf); - (void) BIO_set_close(b, BIO_NOCLOSE); - BIO_free(b); result = tor_malloc(buf->length + 1); memcpy(result, buf->data, buf->length); result[buf->length] = 0; - BUF_MEM_free(buf); + + BIO_free(b); RSA_free(rsa); return result;

1 0

[tor/maint-0.2.9] Merge branch 'maint-0.2.8' into maint-0.2.9
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 3bb49c011006d042f8a3f802d7abb3e9da51b15b Merge: ff3e08f 9b18b21 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 15:41:04 2016 -0400 Merge branch 'maint-0.2.8' into maint-0.2.9 changes/bug20553 | 3 +++ src/common/crypto.c | 5 ++--- src/tools/tor-gencert.c | 5 ++--- 3 files changed, 7 insertions(+), 6 deletions(-)

1 0

[tor/master] Merge branch 'maint-0.2.8' into maint-0.2.9
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 3bb49c011006d042f8a3f802d7abb3e9da51b15b Merge: ff3e08f 9b18b21 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 15:41:04 2016 -0400 Merge branch 'maint-0.2.8' into maint-0.2.9 changes/bug20553 | 3 +++ src/common/crypto.c | 5 ++--- src/tools/tor-gencert.c | 5 ++--- 3 files changed, 7 insertions(+), 6 deletions(-)

1 0

[tor/release-0.2.8] Merge branch 'maint-0.2.8' into release-0.2.8
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 6520ef5478731ef9a2a38d274f0840d9c26598ba Merge: badc444 9b18b21 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 15:40:56 2016 -0400 Merge branch 'maint-0.2.8' into release-0.2.8 changes/bug20553 | 3 +++ src/common/crypto.c | 5 ++--- src/tools/tor-gencert.c | 5 ++--- 3 files changed, 7 insertions(+), 6 deletions(-)

1 0

[tor/release-0.2.9] Merge branch 'maint-0.2.8' into maint-0.2.9
by nickm＠torproject.org 03 Nov '16

03 Nov '16

commit 3bb49c011006d042f8a3f802d7abb3e9da51b15b Merge: ff3e08f 9b18b21 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 3 15:41:04 2016 -0400 Merge branch 'maint-0.2.8' into maint-0.2.9 changes/bug20553 | 3 +++ src/common/crypto.c | 5 ++--- src/tools/tor-gencert.c | 5 ++--- 3 files changed, 7 insertions(+), 6 deletions(-)

1 0