Skip to content

ERR: re-use the err_data field when possible#9459

Closed
levitte wants to merge 3 commits intoopenssl:masterfrom
levitte:err-reuse-data-buffer
Closed

ERR: re-use the err_data field when possible#9459
levitte wants to merge 3 commits intoopenssl:masterfrom
levitte:err-reuse-data-buffer

Conversation

@levitte
Copy link
Member

@levitte levitte commented Jul 25, 2019

To deallocate the err_data field and then allocating it again might be
a waste of processing, but may also be a source of errors when memory
is scarce. While we normally tolerate that, the ERR sub-system is an
exception and we need to pay closer attention to how we handle memory.

This adds a new err_data flag, ERR_TXT_IGNORE, which means that even
if there is err_data memory allocated, its contents should be ignored.
Deallocation of the err_data field is much more selective, aand should
only happen when ERR_free_state() is called.

Fixes #9458

@levitte levitte added the branch: master Applies to master branch label Jul 25, 2019
@richsalz
Copy link
Contributor

I don't think you need a new flag. You just need to change the meaning of the "MALLOCED" flag to mean "owned by ERR facility"

@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

So how do you differentiate between an err_data that has been allocated and has content that belongs with the error record, and err_data that has been allocated but belonged to an error record that is now gone?

To deallocate the err_data field and then allocating it again might be
a waste of processing, but may also be a source of errors when memory
is scarce.  While we normally tolerate that, the ERR sub-system is an
exception and we need to pay closer attention to how we handle memory.

This adds a new err_data flag, ERR_TXT_IGNORE, which means that even
if there is err_data memory allocated, its contents should be ignored.
Deallocation of the err_data field is much more selective, aand should
only happen when ERR_free_state() is called.

Fixes openssl#9458
@levitte levitte force-pushed the err-reuse-data-buffer branch from 401aa0b to 5d0ce3f Compare July 25, 2019 16:22
@levitte levitte marked this pull request as ready for review July 25, 2019 17:10
@levitte levitte changed the title [WIP] ERR: re-use the err_data field when possible ERR: re-use the err_data field when possible Jul 25, 2019
@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

The CIs seem happy, my personal tests are happy, so this is no longer WIP

@richsalz
Copy link
Contributor

So how do you differentiate between an err_data that has been allocated and has content that belongs with the error record, and err_data that has been allocated but belonged to an error record that is now gone?

You keep the data pointer until completely releasing all the error-data. In order to re-use the data pointer, of course, you have to move away from free'ing it each time it comes to the top of the queue

@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

... you lost me. Do you understand what I'm asking? Basically, if err_data is non-NULL, how do I know that it points at valid data for the error record or if it points at old data that's lingering from a previous record?

@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

Hmmm... Another way to deal with the situation is by clearing the data itself, i.e. err_data[es->top][0] = '\0'

@richsalz
Copy link
Contributor

richsalz commented Jul 25, 2019 via email

@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

Hey @richsalz, you might want to look at 5d0ce3fc47f379, it does the same work without the extra flag. All I had to do was realise that I only needed to make err_data an empty string when "clearing". So while I protested, you did make me think of alternatives... and this one made it conceptually easier to boot. So Thanks

@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

(wrong commit, corrected)

@richsalz
Copy link
Contributor

The change is nice.

@levitte
Copy link
Member Author

levitte commented Jul 25, 2019

glad you like it :-)

Copy link
Contributor

@paulidale paulidale left a comment

Choose a reason for hiding this comment

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

One typo to fix but good to go.

@levitte levitte added the approval: done This pull request has the required number of approvals label Jul 30, 2019
@levitte
Copy link
Member Author

levitte commented Jul 30, 2019

Merged.

10f8b36 ERR: re-use the err_data field when possible

@levitte levitte closed this Jul 30, 2019
rhuijben pushed a commit to rhuijben/openssl that referenced this pull request Jul 30, 2019
To deallocate the err_data field and then allocating it again might be
a waste of processing, but may also be a source of errors when memory
is scarce.  While we normally tolerate that, the ERR sub-system is an
exception and we need to pay closer attention to how we handle memory.

This adds a new err_data flag, ERR_TXT_IGNORE, which means that even
if there is err_data memory allocated, its contents should be ignored.
Deallocation of the err_data field is much more selective, aand should
only happen when ERR_free_state() is called.

Fixes #9458

Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl/openssl#9459)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval: done This pull request has the required number of approvals branch: master Applies to master branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

re-use allocated space in error structure

3 participants