Skip to content

Grab lock before invoking hook #5855

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.

Sign up for GitHub

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

Closed
duke8253 wants to merge 1 commit into from
Closed

Grab lock before invoking hook #5855

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions iocore/net/SSLNetVConnection.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1747,6 +1747,7 @@ SSLNetVConnection::callHooks(TSEvent eventId)
}

if (curHook != nullptr) {
SCOPED_MUTEX_LOCK(lock, curHook->m_cont->mutex, this_ethread());
Copy link
Contributor

@masaori335 masaori335 Aug 22, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

Do you mean there is a case of curHook->m_cont->mutex is nullptr by "Requires #5857".
In that case, does this SCOPED_MUTEX_LOCK make sense?

Copy link
Member

@SolidWallOfCode SolidWallOfCode Aug 22, 2019

Choose a reason for hiding this comment

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

No, but overall the code is simplified by putting the check in SCOPED_MUTEX_LOCK. Otherwise every place that invokes the continuation would have to have the same cut and pasted logic. This is the reason that was moved in to MUTEX_TRY_LOCK.

Copy link
Contributor Author

@duke8253 duke8253 Aug 22, 2019

Choose a reason for hiding this comment

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

Yeah, I meant it needs the null checking , since some times the mutex could be pointing to nothing

Copy link
Member

@maskit maskit Aug 22, 2019

Choose a reason for hiding this comment

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

Less dup code is fine but failing silently doesn’t sounds great.

Copy link
Contributor Author

@duke8253 duke8253 Aug 22, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

I don't think it counts as failing. If a mutex is provided, it locks it just the same as before, if a nullptr is provided nothing happens.

Copy link
Member

@SolidWallOfCode SolidWallOfCode Aug 23, 2019

Choose a reason for hiding this comment

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

That doesn't help - this macro isn't accessible from the C API and so another macro doesn't provide the opportunity to specify "no lock needed". Passing nullptr isn't a mistake, even in your example it's done quite deliberately during creation of the continuation.

Perhaps you could be more explicit about an alternative that would allow having nullptr for a continuation mutex that does not result in an assertion based crash?

Copy link
Contributor

@bryancall bryancall Aug 23, 2019

Choose a reason for hiding this comment

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

Looking at the use of SCOPED_MUTEX_LOCK in most cases we don't do a nullptr check and require that there is a mutex. This would change the semantics in those cases and if some part of the code accidentally sets the mutex to null (not uncommon that memory is accentually written to) we would then not be holding a mutex.

The issue that @maskit has should have been addressed in #5857 before approving and merging the change.

Copy link
Member

@SolidWallOfCode SolidWallOfCode Aug 26, 2019

Choose a reason for hiding this comment

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

Does that imply reverting the change to MutexTryLock, which has had the same nullptr exception since February? Or should these two macros / classes have this fundamental difference?

Copy link
Member

@SolidWallOfCode SolidWallOfCode Aug 26, 2019

Choose a reason for hiding this comment

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

If the nullptr check is moved to be only in to the macro, the class constructor will crash on a nullptr mutex.

I would recommend WEAK_MUTEX_TRY_LOCK and WEAK_SCOPED_MUTEX_LOCK for the nullptr accepting versions. Then the current ones do an assert and invoke the WEAK version.

Copy link
Contributor

@bryancall bryancall Aug 26, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

Yes, that would mean changing MutexTryLock too. You could add a ink_assert() or ink_release_assert() for the mutex, but crashing on dereferencing a null pointer is easy to track down and I wouldn't bother.

curHook->invoke(eventId, this);
reenabled =
(this->sslHandshakeHookState != HANDSHAKE_HOOKS_CERT_INVOKE && this->sslHandshakeHookState != HANDSHAKE_HOOKS_PRE_INVOKE &&
Expand Down