Skip to content

Conversation

@sedited
Copy link
Contributor

@sedited sedited commented Aug 7, 2023

Moving the kernel sanity check code to kernel context instantiation time ensures that it is impossible to create an invalid kernel context. This is based on a suggestion made in a comment by @theuni in the original pull request first introducing the kernel::Context.

@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 7, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type Reviewers
Stale ACK stickies-v

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #29252 (kernel: Remove key module from kernel library by TheCharlatan)
  • #28960 (kernel: Remove dependency on CScheduler by TheCharlatan)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@sedited sedited force-pushed the contextSanityChecks branch from cfe9364 to 3c1c434 Compare August 11, 2023 09:31
@sedited
Copy link
Contributor Author

sedited commented Aug 11, 2023

Thank you for the review @furszy

Updated cfe9364 -> 3c1c434 (contextSanityChecks_0 -> contextSanityChecks_1, compare)

  • Addressed @furszy's comment, cleaned up includes of context.cpp/.h.
  • Addressed @furszy's comment, squashed the two log messages into one message. Also made sure that both the daemon and gui are still logging the same message.
  • Addressed @furszy's comment, removed failure log statement in MakeContext.

@theuni
Copy link
Member

theuni commented Aug 11, 2023

Assuming I'm understanding the init order bug, please correct me if I'm not...
If AppInitBasicSetup() and AppInitBasicSetup() and AppInitParameterInteraction() are relying on globals created by the kernel, perhaps it makes sense for them to require a kernel to be passed in, even if it's unused inside those functions for now?

  • It would document/force the correct creation order
  • Presumably when de-globalizing, these functions will need the kernel anyway.

@sedited
Copy link
Contributor Author

sedited commented Aug 11, 2023

Re #28228 (comment)

Presumably when de-globalizing, these functions will need the kernel anyway.

I am not sure how we could go about registering our signal handlers without the shutdown global.

It would document/force the correct creation order

I originally wanted to to introduce this in a separate PR (fixing the order for gui initialization), but I think it makes more sense here, yes.

@sedited sedited marked this pull request as draft August 11, 2023 15:54
@sedited sedited force-pushed the contextSanityChecks branch from 3c1c434 to b333faa Compare August 12, 2023 08:46
@sedited
Copy link
Contributor Author

sedited commented Aug 12, 2023

Thank you for the comments @theuni

Updated 3c1c434 -> 8275733 (contextSanityChecks_1 -> contextSanityChecks_2, compare)

  • Added check and precondition docs for the global kernel context.
  • Fixed initialization order for bitcoin-qt in baseInitialize

Copy link
Contributor

@stickies-v stickies-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approach ACK

Comment on lines 96 to 102
auto res{kernel::Context::MakeContext()};
if (!res) {
return InitError(strprintf(_("Initialization kernel sanity check failed: %s. %s is shutting down."),
util::ErrorString(res), PACKAGE_NAME));
}
m_context->kernel = std::move(res.value());

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could implement a NodeContext::make_kernel() method to avoid this duplication between here and bitcoind.cpp?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember some prior comments that adding helper methods directly to the NodeContext struct is undesirable. Could add a init.h helper function instead that takes a NodeContext as an argument?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, it's in the docstring.

I think a non-member function in init makes sense, yeah. It aligns well with the existing design of baseInitialize and AppInit.

@sedited
Copy link
Contributor Author

sedited commented Sep 6, 2023

Thank you for the comments @stickies-v

Rebased 8275733 -> 14448df (contextSanityChecks_2 -> contextSanityChecks_3, compare)

Updated 14448df -> d0daf3e (contextSanityChecks_3 -> contextSanityChecks_4, compare)

Copy link
Contributor

@stickies-v stickies-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK d0daf3e

  • PR description needs updating to reflect dropping the bugfix
  • nit: commit message mentions deduplicating the init error messages, but that's not entirely true since bitcoind.cpp didn't have an init error message to begin with, this change is relative to a previous version of this PR but not to master, I think? edit: resolved as clarified here

@sedited
Copy link
Contributor Author

sedited commented Sep 6, 2023

Re #28228 (review)

nit: commit message mentions deduplicating the init error messages, but that's not entirely true since bitcoind.cpp didn't have an init error message to begin with, this change is relative to a previous version of this PR but not to master, I think?

This refers to these two messages here: https://github.com/bitcoin/bitcoin/pull/28228/files#diff-b1e19192258d83199d8adaa5ac31f067af98f63554bfdd679bd8e8073815e69dL1034-L1035 that have been merged into a single one.

@sedited sedited force-pushed the contextSanityChecks branch from d0daf3e to 53f0be7 Compare September 6, 2023 10:52
@sedited
Copy link
Contributor Author

sedited commented Sep 6, 2023

Updated d0daf3e -> 53f0be7 (contextSanityChecks_4 -> contextSanityChecks_5, compare)

Also fixed-up PR description.

@stickies-v
Copy link
Contributor

re-ACK 53f0be7

@ryanofsky
Copy link
Contributor

Looking at 53f0be7, I don't understand the benefits of this PR. It seems unfortunate for the kernel struct now to have to live in a unique_ptr instead of kernel library users being able to declare and allocate it however they want. It seems unfortunate for the context struct now to have a static method, when it's intended to be passive container holding state, not a place where functionality is implemented. It seems unfortunate for it now to depend on checks.cpp and do extra work that's not strictly necessary. I know there's history and discussion here that I'm not aware of but the current change by itself does seem like a regression.

@maflcko
Copy link
Member

maflcko commented Oct 25, 2023

Are you still working on this?

@sedited
Copy link
Contributor Author

sedited commented Oct 25, 2023

Re #28228 (comment)

Are you still working on this?

I would like to hear @theuni's opinion here, since he originally suggested the concept.

This ensures that it is impossible to construct a context that does not
pass the sanity checks.

Also de-duplicate the init error messages in case of a kernel context
sanity check error.
@sedited sedited force-pushed the contextSanityChecks branch from 53f0be7 to 673bcf4 Compare January 10, 2024 10:09
@sedited
Copy link
Contributor Author

sedited commented Jan 10, 2024

@DrahtBot
Copy link
Contributor

DrahtBot commented Mar 9, 2024

🐙 This pull request conflicts with the target branch and needs rebase.

@achow101 achow101 requested a review from theuni April 9, 2024 14:22
#include <script/sigcache.h>
#include <util/chaintype.h>
#include <util/fs.h>
#include <util/signalinterrupt.h>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hhfft

@sedited
Copy link
Contributor Author

sedited commented Sep 2, 2024

Closing this again, having worked with the code some more over the past year, I don't think this is particularly pressing change anymore. As ryanofsky elaborated, our context objects should have functionality and instead just hold state - which is what it does already.

@sedited sedited closed this Sep 2, 2024
@bitcoin bitcoin locked and limited conversation to collaborators Sep 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

Status: Done or Closed or Rethinking

Development

Successfully merging this pull request may close these issues.

8 participants