[tor-bugs] #27244 [Core Tor/Tor]: Use mmap to hold our cached consensus, when we even need it stored in RAM at all.
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Sep 8 00:01:46 UTC 2018
#27244: Use mmap to hold our cached consensus, when we even need it stored in RAM
at all.
-------------------------------------------------+-------------------------
Reporter: nickm | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.5.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: 035-roadmap-master, 035-triaged- | Actual Points:
in-20180711 |
Parent ID: #27243 | Points:
Reviewer: | Sponsor:
| Sponsor8
-------------------------------------------------+-------------------------
Comment (by nickm):
Turns out not to be redundant with #27247. Clients no longer need to keep
a cached_dir_t, and that ticket stops them -- but when they load it, they
still load it with read_file_to_string().
There's a slight difficulty in moving to mmap, however. When we mmap() a
file, it is not a NUL-terminated string, but rather a non-terminated pile
of bytes with an associated size_t.
There are three cases when a client needs a consensus text:
1. It's parsing it from disk
2. It's applying a consensus diff.
3. It's writing it to the controller
Case 3 is easy enough, since the client doesn't need to examine the bytes
at all.
But for case 1 and case 2, our networkstatus parsing code and our
consensus diff code both assume that the mapped object is NUL-terminated.
So before we can do this, we'll need to carefully revise a bunch of
functions.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27244#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list