Bug 201074 - CacheStorageConnection::computeRealBodySize is not thread-safe
Summary: CacheStorageConnection::computeRealBodySize is not thread-safe
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Service Workers (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-08-23 05:31 PDT by youenn fablet
Modified: 2019-08-26 10:52 PDT (History)
5 users (show)

See Also:


Attachments
Patch (2.58 KB, patch)
2019-08-23 05:34 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (2.33 KB, patch)
2019-08-26 01:57 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2019-08-23 05:31:04 PDT
CacheStorageConnection::computeRealBodySize is not thread-safe
Comment 1 youenn fablet 2019-08-23 05:34:07 PDT
Created attachment 377122 [details]
Patch
Comment 2 Darin Adler 2019-08-23 10:40:12 PDT
Comment on attachment 377122 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=377122&action=review

> Source/WebCore/Modules/cache/CacheStorageConnection.cpp:48
> +    uint64_t resultSize;
> +    BinarySemaphore semaphore;
> +    callOnMainThread([sessionID, formData = formData.isolatedCopy(), &semaphore, &resultSize] {
> +        resultSize = formData->lengthInBytes(sessionID);
> +        semaphore.signal();
> +    });
> +    semaphore.wait();

Why is the semaphore needed? Doesn’t callOnMainThread, which is synchronous, already contain enough synchronization to guarantee the correct value for resultSize? If not, it seems really hard to program with callOnMainThread correctly.
Comment 3 youenn fablet 2019-08-26 01:55:17 PDT
(In reply to Darin Adler from comment #2)
> Comment on attachment 377122 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=377122&action=review
> 
> > Source/WebCore/Modules/cache/CacheStorageConnection.cpp:48
> > +    uint64_t resultSize;
> > +    BinarySemaphore semaphore;
> > +    callOnMainThread([sessionID, formData = formData.isolatedCopy(), &semaphore, &resultSize] {
> > +        resultSize = formData->lengthInBytes(sessionID);
> > +        semaphore.signal();
> > +    });
> > +    semaphore.wait();
> 
> Why is the semaphore needed? Doesn’t callOnMainThread, which is synchronous,
> already contain enough synchronization to guarantee the correct value for
> resultSize? If not, it seems really hard to program with callOnMainThread
> correctly.

Using callOnMainThread does not wait, but I should replace the semaphore with a call to callOnMainThreadAndWait.
Comment 4 youenn fablet 2019-08-26 01:57:46 PDT
Created attachment 377236 [details]
Patch
Comment 5 Chris Dumez 2019-08-26 09:11:27 PDT
Comment on attachment 377236 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=377236&action=review

> Source/WebCore/Modules/cache/CacheStorageConnection.cpp:38
> +    if (isMainThread())

This branch is not really needed, callOnMainThreadAndWait() already does the right thing for you. Or are you doing this as an optimization to avoid the isolatedCopy() of the FormData? I guess that's fine.
Comment 6 youenn fablet 2019-08-26 10:13:27 PDT
(In reply to Chris Dumez from comment #5)
> Comment on attachment 377236 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=377236&action=review
> 
> > Source/WebCore/Modules/cache/CacheStorageConnection.cpp:38
> > +    if (isMainThread())
> 
> This branch is not really needed, callOnMainThreadAndWait() already does the
> right thing for you. Or are you doing this as an optimization to avoid the
> isolatedCopy() of the FormData? I guess that's fine.

Yes, there is no way we could optimise this.
Comment 7 WebKit Commit Bot 2019-08-26 10:51:24 PDT
Comment on attachment 377236 [details]
Patch

Clearing flags on attachment: 377236

Committed r249105: <https://trac.webkit.org/changeset/249105>
Comment 8 WebKit Commit Bot 2019-08-26 10:51:26 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Radar WebKit Bug Importer 2019-08-26 10:52:18 PDT
<rdar://problem/54713221>