Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

report: add missing locks for report_on_fatalerror accessors #32535

Closed
wants to merge 1 commit into from

Conversation

addaleax
Copy link
Member

Overlooked in 2fa74e3.

Refs: #32207

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. report Issues and PRs related to process.report. labels Mar 28, 2020
Copy link
Contributor

@cjihrig cjihrig left a comment

Choose a reason for hiding this comment

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

LGTM. I'm assuming the same thing should be done in #32497?

@nodejs-github-bot
Copy link
Collaborator

@@ -129,12 +130,14 @@ static void SetSignal(const FunctionCallbackInfo<Value>& info) {
}

static void ShouldReportOnFatalError(const FunctionCallbackInfo<Value>& info) {
Mutex::ScopedLock lock(node::per_process::cli_options_mutex);
Copy link
Member

Choose a reason for hiding this comment

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

will defining report_on_fatalerror as std::atomic<bool> be a better approach?

Copy link
Member Author

Choose a reason for hiding this comment

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

@gireeshpunathil You could do that, but I doubt that it’s worth the extra complexity.

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 30, 2020
@nodejs-github-bot
Copy link
Collaborator

@sam-github
Copy link
Contributor

This makes threads running js (workers and main) all get mutex on access via the js setter/getter, but don't all accesses to that value after the intial CLI parsing need protection?

Specifically,

if (per_process::cli_options->report_on_fatalerror) {
?

@sam-github
Copy link
Contributor

Do Set/GetFipsCrypto have the same issues? I didn't do a thorough review, I just did some grepping for some of the other process scope options, and they appear to be subject to the same problem as the on_error.

@gireeshpunathil 's atomic suggestion seems a pretty good one for all bools, it makes it safer by shifting the responsibility to the variable to be safe, rather than to the users of the variable.

Atomic won't work for types that are not trivially copyable, though, so strings will need to use the mutex.

addaleax added a commit that referenced this pull request Apr 2, 2020
Overlooked in 2fa74e3.

Refs: #32207

PR-URL: #32535
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
@addaleax
Copy link
Member Author

addaleax commented Apr 2, 2020

Landed in e06512b

@sam-github If you want to switch these over to using atomics, I think that’s okay – most importantly, I’d like to be consistent, and I’d like to be explicit about using global mutable state when we’re doing it. And yes, the FIPS accessors look like they should also be protected by a mutex.

@addaleax addaleax closed this Apr 2, 2020
@addaleax addaleax deleted the missing-locks branch April 2, 2020 15:56
@sam-github
Copy link
Contributor

@addaleax Did you see #32535 (comment)? Is no locking required on the other access?

Btw, I tried atomic bools, they aren't supported by the options parser, and adding an entire new specialization for the options parser didn't seem worth it. cc: @gireeshpunathil

@addaleax
Copy link
Member Author

addaleax commented Apr 2, 2020

@sam-github Yeah, as I said to @gireeshpunathil – it doesn’t seem worth the extra complexity.

And yes, I think technically the other accesses need a mutex, too.

Thinking about it, #31717 introduced a mechanism for this that might actually help a lot here – wrapping the per-process options struct in ExclusiveAccess would make sure that we acquire a lock before we access it. If you or @gireeshpunathil are interested in implementing that, feel free to go ahead, otherwise I’d be up for it. (Or if you think it’s a terrible idea, let me know that too, of course 😅.)

@sam-github
Copy link
Contributor

I like the #31717 approach, though I suspect it would break the options parsing even more thoroughly than atomics. On the plus side, it would also handle std::string (which can't be atomic), so that's a win.

@addaleax
Copy link
Member Author

addaleax commented Apr 2, 2020

@sam-github To be clear, my suggestion is to wrap the entire struct in ExclusiveAccess, not individual members. It shouldn’t affect the options parser code, or at least only very small parts of it.

BethGriggs pushed a commit that referenced this pull request Apr 7, 2020
Overlooked in 2fa74e3.

Refs: #32207

PR-URL: #32535
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
targos pushed a commit that referenced this pull request Apr 12, 2020
Overlooked in 2fa74e3.

Refs: #32207

PR-URL: #32535
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
@targos targos added backport-blocked-v12.x and removed author ready PRs that have at least one approval, no pending requests for changes, and a CI started. backport-blocked-v12.x labels Apr 22, 2020
targos pushed a commit to targos/node that referenced this pull request Apr 25, 2020
Overlooked in 2fa74e3.

Refs: nodejs#32207

PR-URL: nodejs#32535
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
targos pushed a commit that referenced this pull request Apr 28, 2020
Overlooked in 2fa74e3.

Refs: #32207

PR-URL: #32535
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. report Issues and PRs related to process.report.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants