Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
15649018:
Call crypto::InitializeTPMToken on the IO thread (Closed)
|
Created:
7 years, 6 months ago by stevenjb Modified:
7 years, 6 months ago CC:
chromium-reviews, gauravsh+watch_chromium.org, gspencer+watch_chromium.org, stevenjb+watch_chromium.org, oshima+watch_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionCall crypto::InitializeTPMToken on the IO thread
This appears to work, and scanning through the code I don't see any red
flags, but I'm not all that familiar with the crypto code, so I don't
know whether this might introduce any new/additional threading issues?
BUG=244455
For chrome/browser/ui/webui/options/certificate_manager_browsertest.cc
[email protected]
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=206265
Patch Set 1 #Patch Set 2 : Add localized Auth error messages #Patch Set 3 : Pass IO thread to CertLoader #Patch Set 4 : Rebase #Patch Set 5 : Merge #
Total comments: 17
Patch Set 6 : Address feedback; use PostTaskAndReply #Patch Set 7 : Test #
Total comments: 4
Patch Set 8 : Test2 #Patch Set 9 : Elim need for crypto WeakPtrFactory #Patch Set 10 : Rebase #Patch Set 11 : Fix tests #
Total comments: 4
Patch Set 12 : Better fix for tests #Patch Set 13 : rebase #
Total comments: 1
Patch Set 14 : Add CertLoader::SetCryptoTaskRunner #Patch Set 15 : Rebase #Patch Set 16 : Rebase #
Total comments: 4
Patch Set 17 : Address feedback #
Total comments: 2
Patch Set 18 : Rebase, move declaration #
Messages
Total messages: 27 (0 generated)
NACK InitializeTPMToken() should *only* be called on the IO thread. It's the only safe place to call it. The fact that it's called on the UI thread is unfortunate, but pushing it to a worker actually makes the UI/IO thread raciness *worse*. We're actually *helped* by the fact that this blocks the UI thread from startup - it reduces the races of the IO thread startup.
On 2013/05/31 23:40:32, Ryan Sleevi wrote: > NACK > > InitializeTPMToken() should *only* be called on the IO thread. It's the only > safe place to call it. > > The fact that it's called on the UI thread is unfortunate, but pushing it to a > worker actually makes the UI/IO thread raciness *worse*. We're actually *helped* > by the fact that this blocks the UI thread from startup - it reduces the races > of the IO thread startup. So then, we probably need to do some re-factoring. The "IO" thread is currently, to the best of my knowledge, a Browser concept. It sounds like we need to set up a thread for crypto operations (which could be the IO thread, but it will then need to be set up somewhere in src/chrome) and move the thread management to a class that manages that, i.e. make InitializeTPMToken an asynchronous call from the UI thread. btw, I forget what the non lgtm keyword is, but it doesn't seem to be nack :)
On 2013/06/01 00:11:15, stevenjb (chromium) wrote: > On 2013/05/31 23:40:32, Ryan Sleevi wrote: > > NACK > > > > InitializeTPMToken() should *only* be called on the IO thread. It's the only > > safe place to call it. > > > > The fact that it's called on the UI thread is unfortunate, but pushing it to a > > worker actually makes the UI/IO thread raciness *worse*. We're actually > *helped* > > by the fact that this blocks the UI thread from startup - it reduces the races > > of the IO thread startup. > > So then, we probably need to do some re-factoring. > > The "IO" thread is currently, to the best of my knowledge, a Browser concept. The IO thread comes from content/, not chrome/, but I'm guessing chromeos/ can't depend on content/? > > It sounds like we need to set up a thread for crypto operations (which could be > the IO thread, but it will then need to be set up somewhere in src/chrome) and > move the thread management to a class that manages that, i.e. make > InitializeTPMToken an asynchronous call from the UI thread. No. Both crypto/ and net/ are designed to assume a "single thread of operation". It's up to the layers above that to ensure it. If a higher layer needs to call into them from another thread, they should be doing the PostTaskAndReply dance, or suitably ensure the threading requirements are met (eg: always on the IO thread). If your chromeos/ code needs to be multi-threaded, or if it's design is that it always assumes single-thread, but that thread is the UI thread, then chromeos/ should receive a SequencedTaskRunner for where it should be calling crypto/ on, and yeah, then chrome/ (which I'm guessing is what calls both chromeos/ and crypto/) can pass in the IOThread's MessageLoop to chromeos/ > > btw, I forget what the non lgtm keyword is, but it doesn't seem to be nack :)
On 2013/06/01 00:14:59, Ryan Sleevi wrote: > On 2013/06/01 00:11:15, stevenjb (chromium) wrote: > > On 2013/05/31 23:40:32, Ryan Sleevi wrote: > > > NACK > > > > > > InitializeTPMToken() should *only* be called on the IO thread. It's the only > > > safe place to call it. > > > > > > The fact that it's called on the UI thread is unfortunate, but pushing it to > a > > > worker actually makes the UI/IO thread raciness *worse*. We're actually > > *helped* > > > by the fact that this blocks the UI thread from startup - it reduces the > races > > > of the IO thread startup. > > > > So then, we probably need to do some re-factoring. > > > > The "IO" thread is currently, to the best of my knowledge, a Browser concept. > > The IO thread comes from content/, not chrome/, but I'm guessing chromeos/ can't > depend on content/? > > > > > It sounds like we need to set up a thread for crypto operations (which could > be > > the IO thread, but it will then need to be set up somewhere in src/chrome) and > > move the thread management to a class that manages that, i.e. make > > InitializeTPMToken an asynchronous call from the UI thread. > > No. Both crypto/ and net/ are designed to assume a "single thread of operation". > It's up to the layers above that to ensure it. > > If a higher layer needs to call into them from another thread, they should be > doing the PostTaskAndReply dance, or suitably ensure the threading requirements > are met (eg: always on the IO thread). > > If your chromeos/ code needs to be multi-threaded, or if it's design is that it > always assumes single-thread, but that thread is the UI thread, then chromeos/ > should receive a SequencedTaskRunner for where it should be calling crypto/ on, > and yeah, then chrome/ (which I'm guessing is what calls both chromeos/ and > crypto/) can pass in the IOThread's MessageLoop to chromeos/ > I did a bit of investigating in the debugger, and we appear to access the g_nss_singleton LazyInstance from all over the place: UI, DB, IO, and Worker threads. Most of these appear to come from net::SSLClientSocketNSS or crypto::ECPrivateKey. They are mostly calls to EnsureNSSInit() (which is specifically mentioned as being safe) and IsTPMTokenReady() (which appears safe), but we also call GetPublicNSSKeySlot() from a Worker thread, and it is less clear whether or not that is safe. I was only looking at startup / shutdown, not at other code that may use src/crypto (because I'm not sure what that code might be other than the networking certificate code). Also, I do not see any mention of threading expectations in nss_util.h, other then that EnsureNSSInit() is thread-safe. So, I do think it would be nice to have a wrapper class with an asynchronous interface that ensured correct thread behavior, given the multi-threaded nature of Chrome. That said, I will trust your knowledge that the IO thread is the right thread to call crypto::InitializeTPMToken() from. I am also assuming that crypto::OpenPersistentNSSDB() should be called from the same thread; please correct me if I am mistaken. PTAL
On 2013/06/06 17:29:36, stevenjb (chromium) wrote: > On 2013/06/01 00:14:59, Ryan Sleevi wrote: > > On 2013/06/01 00:11:15, stevenjb (chromium) wrote: > > > On 2013/05/31 23:40:32, Ryan Sleevi wrote: > > > > NACK > > > > > > > > InitializeTPMToken() should *only* be called on the IO thread. It's the > only > > > > safe place to call it. > > > > > > > > The fact that it's called on the UI thread is unfortunate, but pushing it > to > > a > > > > worker actually makes the UI/IO thread raciness *worse*. We're actually > > > *helped* > > > > by the fact that this blocks the UI thread from startup - it reduces the > > races > > > > of the IO thread startup. > > > > > > So then, we probably need to do some re-factoring. > > > > > > The "IO" thread is currently, to the best of my knowledge, a Browser > concept. > > > > The IO thread comes from content/, not chrome/, but I'm guessing chromeos/ > can't > > depend on content/? > > > > > > > > It sounds like we need to set up a thread for crypto operations (which could > > be > > > the IO thread, but it will then need to be set up somewhere in src/chrome) > and > > > move the thread management to a class that manages that, i.e. make > > > InitializeTPMToken an asynchronous call from the UI thread. > > > > No. Both crypto/ and net/ are designed to assume a "single thread of > operation". > > It's up to the layers above that to ensure it. > > > > If a higher layer needs to call into them from another thread, they should be > > doing the PostTaskAndReply dance, or suitably ensure the threading > requirements > > are met (eg: always on the IO thread). > > > > If your chromeos/ code needs to be multi-threaded, or if it's design is that > it > > always assumes single-thread, but that thread is the UI thread, then chromeos/ > > should receive a SequencedTaskRunner for where it should be calling crypto/ > on, > > and yeah, then chrome/ (which I'm guessing is what calls both chromeos/ and > > crypto/) can pass in the IOThread's MessageLoop to chromeos/ > > > > I did a bit of investigating in the debugger, and we appear to access the > g_nss_singleton LazyInstance from all over the place: UI, DB, IO, and Worker > threads. Most of these appear to come from net::SSLClientSocketNSS or > crypto::ECPrivateKey. They are mostly calls to EnsureNSSInit() (which is > specifically mentioned as being safe) and IsTPMTokenReady() (which appears > safe), but we also call GetPublicNSSKeySlot() from a Worker thread, and it is > less clear whether or not that is safe. I was only looking at startup / > shutdown, not at other code that may use src/crypto (because I'm not sure what > that code might be other than the networking certificate code). The threading assumptions here at that EnsureNSSInit() can be called from anywhere GetPublicNSSKeySlot() can be called safely, at any time, from the IO thread - If workers are calling it, they should stop, and instead be passing the ScopedPK11Slot around for safely, getting the original PK11SlotInfo from the IO thread - The UI shouldn't be mutating this - it should always change/swap/be replaced on the IO thread IsTPMTokenReady() can be called safely, at any time, from the IO thread - Means marshalling data from the IO thread, possibly. > > Also, I do not see any mention of threading expectations in nss_util.h, other > then that EnsureNSSInit() is thread-safe. > > So, I do think it would be nice to have a wrapper class with an asynchronous > interface that ensured correct thread behavior, given the multi-threaded nature > of Chrome. That's something that belongs in src/chromeos or src/chrome. We really do not want to be exposing any public thread-aware APIs from crypto/ and net/ - if threads are involved (and they are - eg: MultiThreadedCertVerifier), those details really need to be hidden. > > That said, I will trust your knowledge that the IO thread is the right thread to > call crypto::InitializeTPMToken() from. > I am also assuming that crypto::OpenPersistentNSSDB() should be called from the > same thread; please correct me if I am mistaken. > > PTAL Nope, you're absolutely correct there as well. If it's called on any other thread, either it will block or block on the IO thread.
Looking much better. A few comments: https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (right): https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... chrome/browser/chromeos/chrome_browser_main_chromeos.cc:841: // Destroy DBus services after g_borowser_process and Ash are destroyed s/borowser_process/browser_process/ https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... chrome/browser/chromeos/chrome_browser_main_chromeos.cc:843: dbus_services_.reset(); THREADING: The Chaps token implicitly relies on DBus to be able to proxy requests to chapsd. The IO thread is where the Chaps token is added/removed. If you shut down dbus before the IO thread, is that going to create issues? Seems likely. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:114: VLOG(1) << "CallOpenPersistentNSSDB"; Necessary? https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:123: DCHECK(tpm_token_state_ == TPM_STATE_UNKNOWN); DCHECK_EQ https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:270: tpm_token_state_ = TPM_TOKEN_INITIALIZED; THREADING: You're mutating this object on another thread. Is that really safe? https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:275: initialize_token_factory_.GetWeakPtr())); THREADING: You're passing the same WeakPtr() on two different threads. This is a violation of the WeakPtr contract, which states that a WeakPtr may only be dereferenced on one thread. Design suggestion: Use PostTaskAndReplyWithResult to marshal the threading if (!PostTaskAndReplyWithResult( crypto_task_runner_.get(), FROM_HERE, base::Bind(&crypto::InitializeTPMToken, tpm_token_name_, tpm_user_pin_), base::Bind(&CertLoader::CallInitializeTPMToken, initialize_token_factory_.GetWeakPtr())) { // failed to initialize (no tasks posted) } CertLoader::CallInitializeTPMToken(bool initialized) { // handle yo stuff } this also frees you from tracking main_task_runner_ (PostTaskAndReplyWithResult implicitly handles this) https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... File chromeos/network/cert_loader.h (right): https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.h:85: // should be made from. In Chrome this is the IO thread. Given that chromeos/ is only allowed to depend on net/ and crypto/, it should be saying nothing about what "Chrome" (namely, src/chrome, but logically, src/content) is doing or how the threads are setup.
PTAL https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (right): https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... chrome/browser/chromeos/chrome_browser_main_chromeos.cc:841: // Destroy DBus services after g_borowser_process and Ash are destroyed On 2013/06/06 23:03:41, Ryan Sleevi wrote: > s/borowser_process/browser_process/ Done. https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... chrome/browser/chromeos/chrome_browser_main_chromeos.cc:843: dbus_services_.reset(); On 2013/06/06 23:03:41, Ryan Sleevi wrote: > THREADING: The Chaps token implicitly relies on DBus to be able to proxy > requests to chapsd. The IO thread is where the Chaps token is added/removed. If > you shut down dbus before the IO thread, is that going to create issues? Seems > likely. Does "The Chaps token" use DBusThreadManager? Can you point me to the code in question? That said... it probably is cleaner to finish running any tasks before we shut down these services. Any code that uses them at that point would be flawed. I will move this to PostDestroyThreads. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:114: VLOG(1) << "CallOpenPersistentNSSDB"; On 2013/06/06 23:03:41, Ryan Sleevi wrote: > Necessary? This can be very helpful when debugging hardware that is failing for some reason. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:123: DCHECK(tpm_token_state_ == TPM_STATE_UNKNOWN); On 2013/06/06 23:03:41, Ryan Sleevi wrote: > DCHECK_EQ Done. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:270: tpm_token_state_ = TPM_TOKEN_INITIALIZED; On 2013/06/06 23:03:41, Ryan Sleevi wrote: > THREADING: You're mutating this object on another thread. Is that really safe? Was that rhetorical? :) Fixed with the change suggested below. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:275: initialize_token_factory_.GetWeakPtr())); On 2013/06/06 23:03:41, Ryan Sleevi wrote: > THREADING: You're passing the same WeakPtr() on two different threads. This is a > violation of the WeakPtr contract, which states that a WeakPtr may only be > dereferenced on one thread. > > Design suggestion: > Use PostTaskAndReplyWithResult to marshal the threading > > if (!PostTaskAndReplyWithResult( > crypto_task_runner_.get(), > FROM_HERE, > base::Bind(&crypto::InitializeTPMToken, tpm_token_name_, tpm_user_pin_), > base::Bind(&CertLoader::CallInitializeTPMToken, > initialize_token_factory_.GetWeakPtr())) { > // failed to initialize (no tasks posted) > } > > CertLoader::CallInitializeTPMToken(bool initialized) { > // handle yo stuff > } > > this also frees you from tracking main_task_runner_ (PostTaskAndReplyWithResult > implicitly handles this) Yeah, that was an oversight. I like your suggestion. Done. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... File chromeos/network/cert_loader.h (right): https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.h:85: // should be made from. In Chrome this is the IO thread. On 2013/06/06 23:03:41, Ryan Sleevi wrote: > Given that chromeos/ is only allowed to depend on net/ and crypto/, it should be > saying nothing about what "Chrome" (namely, src/chrome, but logically, > src/content) is doing or how the threads are setup. This is still the chrome project codebase. We commonly make helpful statements like this. The 'e.g.' is implied, but I will add it explicitly.
lgtm https://codereview.chromium.org/15649018/diff/32001/chrome/browser/chromeos/l... File chrome/browser/chromeos/login/login_utils_browsertest.cc (right): https://codereview.chromium.org/15649018/diff/32001/chrome/browser/chromeos/l... chrome/browser/chromeos/login/login_utils_browsertest.cc:284: NetworkHandler::InitializeForTest(); This test has an IOThread, will it be harmful that CertLoader now doesn't use it but runs crypto on another thread? https://codereview.chromium.org/15649018/diff/32001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/32001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:198: void CertLoader::CallOpenPersistentNSSDB() { could be a global function in anonymous namespace, then the crypto_factory_.GetWeakPtr() wouldn't be needed for the call.
Looks like you're still doing testing with this?
On 2013/06/07 17:23:04, Ryan Sleevi wrote: > Looks like you're still doing testing with this? The tests are crashing for reasons I couldn't make sense of last night. Haven't had a chance to look at the code again this morning, figured I'd wait for the tests I set up last night to complete before looking again. I'll ping when this is ready for review again.
OK, this is why I shouldn't work late; passing a WeakPtr to another thread is, in retrospect, clearly a bad idea. Plus, as Philip pointed out, the crypto_factory_ was entirely unnecessary. So, this should be good to go now. PTAL. https://codereview.chromium.org/15649018/diff/32001/chrome/browser/chromeos/l... File chrome/browser/chromeos/login/login_utils_browsertest.cc (right): https://codereview.chromium.org/15649018/diff/32001/chrome/browser/chromeos/l... chrome/browser/chromeos/login/login_utils_browsertest.cc:284: NetworkHandler::InitializeForTest(); On 2013/06/07 14:00:49, pneubeck wrote: > This test has an IOThread, will it be harmful that CertLoader now doesn't use it > but runs crypto on another thread? Running crypto tasks on the UI thread should be safe, just slower, which should be OK for tests. https://codereview.chromium.org/15649018/diff/32001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/32001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:198: void CertLoader::CallOpenPersistentNSSDB() { On 2013/06/07 14:00:49, pneubeck wrote: > could be a global function in anonymous namespace, then the > crypto_factory_.GetWeakPtr() wouldn't be needed for the call. Good point. Done.
Much better! Mostly nits at this point. I'm happy to LGTM, although please see the comments about sync vs async. https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (right): https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... chrome/browser/chromeos/chrome_browser_main_chromeos.cc:843: dbus_services_.reset(); On 2013/06/07 02:37:47, stevenjb (chromium) wrote: > On 2013/06/06 23:03:41, Ryan Sleevi wrote: > > THREADING: The Chaps token implicitly relies on DBus to be able to proxy > > requests to chapsd. The IO thread is where the Chaps token is added/removed. > If > > you shut down dbus before the IO thread, is that going to create issues? Seems > > likely. > > Does "The Chaps token" use DBusThreadManager? Can you point me to the code in > question? > > That said... it probably is cleaner to finish running any tasks before we shut > down these services. Any code that uses them at that point would be flawed. I > will move this to PostDestroyThreads. No clue. From the view of the network stack, the Chaps proxy is an .so we load, so it "shouldn't" be able to reach into Chrome internals. However, I brought it up in the event that shutting down "DBus services" means "No DBus calls could possibly work" - which would almost certainly cause issues. https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... File chromeos/network/cert_loader.h (right): https://codereview.chromium.org/15649018/diff/19001/chromeos/network/cert_loa... chromeos/network/cert_loader.h:85: // should be made from. In Chrome this is the IO thread. On 2013/06/07 02:37:47, stevenjb (chromium) wrote: > On 2013/06/06 23:03:41, Ryan Sleevi wrote: > > Given that chromeos/ is only allowed to depend on net/ and crypto/, it should > be > > saying nothing about what "Chrome" (namely, src/chrome, but logically, > > src/content) is doing or how the threads are setup. > > This is still the chrome project codebase. We commonly make helpful statements > like this. The 'e.g.' is implied, but I will add it explicitly. Sorry I wasn't clear here. Even though this is the Chrome codebase, we still try to ensure that comments reflect the code layering and separation. That is, code in net/ should not reference how chrome/ is implemented, because chrome/ depends on net/, not vice-versa. Similarly, code in chromeos/ shouldn't mention how chrome/ is implemented, because chromeos/ doesn't depend on chrome/. This is why, for example, in net/, we talk about "the network task runner", rather than the IO thread. The problem with these comments, beyond them getting "out of date" (an argument against any comments, for sure), is that they highlight poor design assumptions. chromeos/ should just focus on how it *SHOULD BE* used, without having to talk about how it *IS* used. https://codereview.chromium.org/15649018/diff/48001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/48001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:136: // thread supplied to Init(). Call the crypto methonds on the current typo: s/methonds/methods https://codereview.chromium.org/15649018/diff/48001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:137: // thread which should be safe, just not asynchronous. I don't think this should be necessary. Your synchronous tests should just supply the current TaskRunner. https://codereview.chromium.org/15649018/diff/48001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:179: crypto::InitializeTPMToken(tpm_token_name_, tpm_user_pin_); Same here
https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (right): https://codereview.chromium.org/15649018/diff/19001/chrome/browser/chromeos/c... chrome/browser/chromeos/chrome_browser_main_chromeos.cc:843: dbus_services_.reset(); On 2013/06/07 23:12:43, Ryan Sleevi wrote: > On 2013/06/07 02:37:47, stevenjb (chromium) wrote: > > On 2013/06/06 23:03:41, Ryan Sleevi wrote: > > > THREADING: The Chaps token implicitly relies on DBus to be able to proxy > > > requests to chapsd. The IO thread is where the Chaps token is added/removed. > > If > > > you shut down dbus before the IO thread, is that going to create issues? > Seems > > > likely. > > > > Does "The Chaps token" use DBusThreadManager? Can you point me to the code in > > question? > > > > That said... it probably is cleaner to finish running any tasks before we shut > > down these services. Any code that uses them at that point would be flawed. I > > will move this to PostDestroyThreads. > > No clue. From the view of the network stack, the Chaps proxy is an .so we load, > so it "shouldn't" be able to reach into Chrome internals. > > However, I brought it up in the event that shutting down "DBus services" means > "No DBus calls could possibly work" - which would almost certainly cause issues. OK, cool, we should be fine then either way. https://codereview.chromium.org/15649018/diff/48001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/48001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:137: // thread which should be safe, just not asynchronous. On 2013/06/07 23:12:43, Ryan Sleevi wrote: > I don't think this should be necessary. Your synchronous tests should just > supply the current TaskRunner. I did some investigating and discovered that we were unnecessarily and incorrectly calling RequestCertificates() from Init(), before the IO thread was actually loaded. Hopefully fixing that will fix the tests.
CertLoader/NetworkHandler depends on IOThread IOThread depends on NetworkHandler through ProxyConfigServiceImpl. It only works currently, because CertLoader /uses/ the IOThread only after login and the BrowserThreadMessageLoopProxy internally stores a BrowserThread::ID instead of a reference to the IOThread. That looks too fragile to me. Please, move the (SequencedTaskRunner crypto_task_runner) argument from Init() to a separate setter in CertLoader, something like: void CertLoader::SetCryptoTaskRunner(const scoped_refptr<base::SequencedTaskRunner>& crypto_task_runner)
Sounds like pneubeck has some concerns, but from my side, the rest LGTM, mod nit. https://codereview.chromium.org/15649018/diff/67001/chromeos/network/network_... File chromeos/network/network_handler.h (right): https://codereview.chromium.org/15649018/diff/67001/chromeos/network/network_... chromeos/network/network_handler.h:35: const scoped_refptr<base::SequencedTaskRunner>& io_task_runner); nit: you call it crypto_task_runner in the CertLoader, but io_task_runner here; naming consistency?
On 2013/06/10 08:36:15, pneubeck wrote: > CertLoader/NetworkHandler depends on IOThread > IOThread depends on NetworkHandler through ProxyConfigServiceImpl. > I just looked at that code, and that's a nasty cyclic dependency. I need to look at this with a debugger, but if IOThread is created in BrowserMainLoop::CreateThreads then we really have the inverse problem since NetworkHandler is created after threads are constructed. > It only works currently, because CertLoader /uses/ the IOThread only after login > and the BrowserThreadMessageLoopProxy internally stores a BrowserThread::ID > instead of a reference to the IOThread. > That looks too fragile to me. > > > Please, move the (SequencedTaskRunner crypto_task_runner) argument from Init() > to a separate setter in CertLoader, something like: > > void CertLoader::SetCryptoTaskRunner(const > scoped_refptr<base::SequencedTaskRunner>& crypto_task_runner) This doesn't really help, does it? If IOThread and BrowserThreadMessageLoopProxy have already been created when we are calling CertLoader::Init(), where would we call SetcryptoTaskRunner to make this any safer?
On 2013/06/11 15:33:32, stevenjb (chromium) wrote: > On 2013/06/10 08:36:15, pneubeck wrote: > > CertLoader/NetworkHandler depends on IOThread > > IOThread depends on NetworkHandler through ProxyConfigServiceImpl. > > > I just looked at that code, and that's a nasty cyclic dependency. I need to look > at this with a debugger, but if IOThread is created in > BrowserMainLoop::CreateThreads then we really have the inverse problem since > NetworkHandler is created after threads are constructed. > > > It only works currently, because CertLoader /uses/ the IOThread only after > login > > and the BrowserThreadMessageLoopProxy internally stores a BrowserThread::ID > > instead of a reference to the IOThread. > > That looks too fragile to me. > > > > > > Please, move the (SequencedTaskRunner crypto_task_runner) argument from Init() > > to a separate setter in CertLoader, something like: > > > > void CertLoader::SetCryptoTaskRunner(const > > scoped_refptr<base::SequencedTaskRunner>& crypto_task_runner) > > This doesn't really help, does it? If IOThread and BrowserThreadMessageLoopProxy > have already been created when we are calling CertLoader::Init(), where would we > call SetcryptoTaskRunner to make this any safer? OK, I see. * PostMainMessageLoopStart() -> NetworkHandler::Initialize() * CreateThreads() -> PreCreateThreads() -> IOThread() -> ProxyConfigServiceImpl() * CreatThreads() -> io_thread_->StartWithOptions() The code works currently because we are actually passing a Proxy to the IO thread, but I agree that this is sloppy. I will add a setter and modify the code to delay RequestCertificates() if cert_loader_ is unset. I think that means I will need to create an interface to CertLoader so that we can mock it properly, but we wanted to do that anyway and this seems important enough to do properly. It may be a couple of days until I can get back to this, we will see.
OK, I added CertLoader::SetCryptoTaskRunner and modified RequestCertificates to fail if not set. This makes the code a bit simpler (no need for a special NetworkHandler initializer for tests), and appears to actually appease all tests with the existing modifications. PTAL
https://codereview.chromium.org/15649018/diff/91001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/91001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:112: !LoginState::Get()->IsUserLoggedIn() || Is this check safe, considering the check on line 116? Would it make more sense to check if (certificates_requested_ || !crypto_task_runner_.get()) return; and then fall through? https://codereview.chromium.org/15649018/diff/91001/chromeos/network/network_... File chromeos/network/network_handler.h (right): https://codereview.chromium.org/15649018/diff/91001/chromeos/network/network_... chromeos/network/network_handler.h:33: // |io_task_runner| is used to initialize CertLoader. changes to this file are no longer necessary.
https://codereview.chromium.org/15649018/diff/91001/chromeos/network/cert_loa... File chromeos/network/cert_loader.cc (right): https://codereview.chromium.org/15649018/diff/91001/chromeos/network/cert_loa... chromeos/network/cert_loader.cc:112: !LoginState::Get()->IsUserLoggedIn() || On 2013/06/12 20:58:50, Ryan Sleevi wrote: > Is this check safe, considering the check on line 116? > > Would it make more sense to check > if (certificates_requested_ || !crypto_task_runner_.get()) > return; > > and then fall through? Good catch, thanks. (This is a merge bug, the code below was added recently - by me, I should have noticed it.) https://codereview.chromium.org/15649018/diff/91001/chromeos/network/network_... File chromeos/network/network_handler.h (right): https://codereview.chromium.org/15649018/diff/91001/chromeos/network/network_... chromeos/network/network_handler.h:33: // |io_task_runner| is used to initialize CertLoader. On 2013/06/12 20:58:50, Ryan Sleevi wrote: > changes to this file are no longer necessary. Done.
lgtm. One tiny nit. https://codereview.chromium.org/15649018/diff/97001/chromeos/network/cert_loa... File chromeos/network/cert_loader.h (right): https://codereview.chromium.org/15649018/diff/97001/chromeos/network/cert_loa... chromeos/network/cert_loader.h:97: void OnPersistentNSSDBOpened(); nit: move behind RetryTokenInitializationLater();
https://codereview.chromium.org/15649018/diff/97001/chromeos/network/cert_loa... File chromeos/network/cert_loader.h (right): https://codereview.chromium.org/15649018/diff/97001/chromeos/network/cert_loa... chromeos/network/cert_loader.h:97: void OnPersistentNSSDBOpened(); On 2013/06/13 07:17:33, pneubeck wrote: > nit: move behind RetryTokenInitializationLater(); Done.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/15649018/101002
Retried try job too often on chromium_presubmit for step(s) presubmit http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/15649018/101002
Message was sent while issue was closed.
Change committed as 206265 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
