RESOLVED FIXED Bug 232605
FileSystemSyncAccessHandle should be invalidated when network process crashes
https://bugs.webkit.org/show_bug.cgi?id=232605
Summary FileSystemSyncAccessHandle should be invalidated when network process crashes
Sihui Liu
Reported 2021-11-01 22:22:14 PDT
The newly launched network process will not know about pre-existing FileSystemSyncAccessHandle. Either FileSystemSyncAccessHandle needs to register to new network process, or FileSystemSyncAccessHandle should be invalidated.
Attachments
Patch (38.60 KB, patch)
2021-11-28 00:03 PST, Sihui Liu
no flags
Patch (33.21 KB, patch)
2021-11-30 14:43 PST, Sihui Liu
no flags
Patch (33.83 KB, patch)
2021-11-30 15:49 PST, Sihui Liu
ews-feeder: commit-queue-
Patch (33.86 KB, patch)
2021-11-30 16:24 PST, Sihui Liu
ews-feeder: commit-queue-
Patch (34.39 KB, patch)
2021-11-30 18:15 PST, Sihui Liu
ews-feeder: commit-queue-
Patch (34.47 KB, patch)
2021-11-30 21:16 PST, Sihui Liu
ews-feeder: commit-queue-
Patch (34.51 KB, patch)
2021-11-30 23:24 PST, Sihui Liu
no flags
Patch (36.76 KB, patch)
2021-12-01 13:45 PST, Sihui Liu
ews-feeder: commit-queue-
Patch (36.68 KB, patch)
2021-12-01 14:42 PST, Sihui Liu
ews-feeder: commit-queue-
Patch (36.69 KB, patch)
2021-12-01 17:15 PST, Sihui Liu
no flags
Radar WebKit Bug Importer
Comment 1 2021-11-08 21:23:20 PST
Sihui Liu
Comment 2 2021-11-28 00:03:51 PST
youenn fablet
Comment 3 2021-11-29 01:01:06 PST
Comment on attachment 445236 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=445236&action=review > Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h:75 > + void invalidateAccessHandle(FileSystemSyncAccessHandleIdentifier) final; I would tend to have a Worker specific method, like registerAccessHandle(FileSystemSyncAccessHandle), and WorkerFileSystemStorageConnection could store a WeakHashSet<FileSystemSyncAccessHandle>. Then what would be needed is for some code to call WorkerFileSystemStorageConnection::connectionClosed() when the network process connection gets closed. For instance by adding a DedicatedWorkerGlobalScope::forEach(Function<void(WorkerGlobalScope&)>&&). > Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.h:93 > + HashMap<WebCore::FileSystemSyncAccessHandleIdentifier, Function<void()>> m_accessHandleInvalidationHandlers; If we go with registerInvalidationHandler/unregisterInvalidationHandler at connection level, a Vector seems enough here. > Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.messages.in:24 > + InvalidateAccessHandle(WebCore::FileSystemSyncAccessHandleIdentifier identifier) Why do we need that message, it seems the IPC connection being closed should be enough?
Sihui Liu
Comment 4 2021-11-29 10:03:13 PST
(In reply to youenn fablet from comment #3) > Comment on attachment 445236 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=445236&action=review > > > Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h:75 > > + void invalidateAccessHandle(FileSystemSyncAccessHandleIdentifier) final; > > I would tend to have a Worker specific method, like > registerAccessHandle(FileSystemSyncAccessHandle), and > WorkerFileSystemStorageConnection could store a > WeakHashSet<FileSystemSyncAccessHandle>. > Then what would be needed is for some code to call > WorkerFileSystemStorageConnection::connectionClosed() when the network > process connection gets closed. > For instance by adding a > DedicatedWorkerGlobalScope::forEach(Function<void(WorkerGlobalScope&)>&&). > Do you mean to dispatch a task to each worker thread to invalidate all its sync access handles? That sounds reasonable if we want to invalidate all access handles. Here we may want to invalidate some handle for the data removal case, so I store handler for each handle (see below). > > Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.h:93 > > + HashMap<WebCore::FileSystemSyncAccessHandleIdentifier, Function<void()>> m_accessHandleInvalidationHandlers; > > If we go with registerInvalidationHandler/unregisterInvalidationHandler at > connection level, a Vector seems enough here. > > > Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.messages.in:24 > > + InvalidateAccessHandle(WebCore::FileSystemSyncAccessHandleIdentifier identifier) > > Why do we need that message, it seems the IPC connection being closed should > be enough? As mentioned in the changelog, the invalidation handler will be used in two cases: 1. connection to backend (network process) is lost 2. access handle is invalidated on network process's request (when website data is deleted) The message is needed for the second case (I will use it in https://bugs.webkit.org/show_bug.cgi?id=233567)
youenn fablet
Comment 5 2021-11-30 00:53:34 PST
> > Why do we need that message, it seems the IPC connection being closed should > > be enough? > > As mentioned in the changelog, the invalidation handler will be used in two > cases: > 1. connection to backend (network process) is lost > 2. access handle is invalidated on network process's request (when website > data is deleted) > The message is needed for the second case (I will use it in > https://bugs.webkit.org/show_bug.cgi?id=233567) Understood, let's add the IPC message in the patch that needs it then, here it does not seem used at all. Also, it seems we could manage a map <FileSystemSyncAccessHandleIdentifier, pair< ScriptExecutionContextIdentifier , FileSystemHandleIdentifier>> in WebFileSystemStorageConnection and use it for this purpose as well as future purposes.
Sihui Liu
Comment 6 2021-11-30 14:43:06 PST
Sihui Liu
Comment 7 2021-11-30 15:49:41 PST
Sihui Liu
Comment 8 2021-11-30 16:24:05 PST
Sihui Liu
Comment 9 2021-11-30 18:15:40 PST
Sihui Liu
Comment 10 2021-11-30 21:16:07 PST
Sihui Liu
Comment 11 2021-11-30 23:24:34 PST
youenn fablet
Comment 12 2021-12-01 10:58:45 PST
Comment on attachment 445529 [details] Patch WinCairo issue is legit, probably a missing include. View in context: https://bugs.webkit.org/attachment.cgi?id=445529&action=review > Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.cpp:100 > +void FileSystemFileHandle::registerSyncAccessHandle(FileSystemSyncAccessHandleIdentifier identifier, FileSystemSyncAccessHandle* handle) FileSystemSyncAccessHandle& would be better. > Source/WebCore/Modules/filesystemaccess/FileSystemSyncAccessHandle.cpp:52 > + m_source->registerSyncAccessHandle(m_identifier, this); *this would be better. > Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.cpp:319 > + handle->invalidate(); if (auto handle...) > Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h:73 > + void registerSyncAccessHandle(FileSystemSyncAccessHandleIdentifier, ScriptExecutionContextIdentifier, FileSystemSyncAccessHandle*) final; FileSystemSyncAccessHandle& is better. I would tend to make this registerSyncAccessHandle not virtual but specific to WorkerFileSystemStorageConnection. To call it, handle would need to do something like downcast<WorkerGlobalScope>(context).fileSystemStorageConnection().registerSyncAccessHandle(...). We could then take a reference instead of a pointer. FileSystemStorageConnection could have a registerSyncAccessHandle(FileSystemSyncAccessHandleIdentifier, ScriptExecutionContextIdentifier) that would do nothing in WorkerFileSystemStorageConnection. Or we could somehow introduce a MainThreadFileSystemStorageConnection. > Source/WebCore/workers/WorkerGlobalScope.h:96 > + WEBCORE_EXPORT WorkerFileSystemStorageConnection* fileSystemStorageConnection(); Can we return a reference here? > Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.cpp:215 > + if (FileSystemStorageConnection* connection = downcast<WebCore::WorkerGlobalScope>(context).fileSystemStorageConnection()) auto*. Would be good to be able to use a ref.
Sihui Liu
Comment 13 2021-12-01 12:58:45 PST
(In reply to youenn fablet from comment #12) > Comment on attachment 445529 [details] > Patch > > WinCairo issue is legit, probably a missing include. Thanks for the review. Will make sure bots are green before landing. > > View in context: > https://bugs.webkit.org/attachment.cgi?id=445529&action=review > > > Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.cpp:100 > > +void FileSystemFileHandle::registerSyncAccessHandle(FileSystemSyncAccessHandleIdentifier identifier, FileSystemSyncAccessHandle* handle) > > FileSystemSyncAccessHandle& would be better. Will change. > > > Source/WebCore/Modules/filesystemaccess/FileSystemSyncAccessHandle.cpp:52 > > + m_source->registerSyncAccessHandle(m_identifier, this); > > *this would be better. Will change. > > > Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.cpp:319 > > + handle->invalidate(); > > if (auto handle...) Sure. > > > Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h:73 > > + void registerSyncAccessHandle(FileSystemSyncAccessHandleIdentifier, ScriptExecutionContextIdentifier, FileSystemSyncAccessHandle*) final; > > FileSystemSyncAccessHandle& is better. > I would tend to make this registerSyncAccessHandle not virtual but specific > to WorkerFileSystemStorageConnection. > To call it, handle would need to do something like > downcast<WorkerGlobalScope>(context).fileSystemStorageConnection(). > registerSyncAccessHandle(...). > We could then take a reference instead of a pointer. > > FileSystemStorageConnection could have a > registerSyncAccessHandle(FileSystemSyncAccessHandleIdentifier, > ScriptExecutionContextIdentifier) that would do nothing in > WorkerFileSystemStorageConnection. > Or we could somehow introduce a MainThreadFileSystemStorageConnection. Sure, will make registerSyncAccessHandle non-virtual. > > > Source/WebCore/workers/WorkerGlobalScope.h:96 > > + WEBCORE_EXPORT WorkerFileSystemStorageConnection* fileSystemStorageConnection(); > > Can we return a reference here? > > > Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.cpp:215 > > + if (FileSystemStorageConnection* connection = downcast<WebCore::WorkerGlobalScope>(context).fileSystemStorageConnection()) > > auto*. Would be good to be able to use a ref. Sure.
Sihui Liu
Comment 14 2021-12-01 13:45:58 PST
Sihui Liu
Comment 15 2021-12-01 14:42:29 PST
Sihui Liu
Comment 16 2021-12-01 17:15:32 PST
EWS
Comment 17 2021-12-01 22:27:55 PST
Committed r286414 (244760@main): <https://commits.webkit.org/244760@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 445640 [details].
Note You need to log in before you can comment on or make changes to this bug.