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.

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

Jump to bottom

Entrypoint::wait_and_dispatch_one_io_signal() must be solely called by the entrypoint thread #2399

Closed
alex-ab opened this issue Apr 20, 2017 · 1 comment
Closed

Entrypoint::wait_and_dispatch_one_io_signal() must be solely called by the entrypoint thread #2399

alex-ab opened this issue Apr 20, 2017 · 1 comment
Assignees
@cproc
Labels
bug fixed

Comments

@alex-ab
Copy link
Member

alex-ab commented Apr 20, 2017

which is not the case everywhere (e.g. fs_file_system.h).

If a thread, e.g. a pthread of vbox on hw/muen, issues write requests, the pthread may wait for the acknowledgements of the write requests.
If the pthread has to wait, it calls ep().wait_and_dispatch_one_io_signal(). It will never return respectively wakeup, since the internal implementation will send the wakup to the entrypoint and not to the pthread (see repos/base-hw/src/lib/base/signal.cc Signal_receiver::unblock_signal_waiter()).

The generic implementation plays a bit better for the other platforms, e.g. vbox on nova (repos/base/src/lib/base/signal.cc Signal_receiver::unblock_signal_waiter()). There a Genode semaphore is used to block and unblock threads, so that the right thread will be woken up. That explains why vbox on nova still performs ok.

Nevertheless, Entrypoint::wait_and_dispatch_one_signal() in repos/base/src/lib/base/entrypoint.cc, will fail to work as soon as the entrypoint and several pthreads call wait_and_dispatch_one_signal() concurrently.
@alex-ab alex-ab added the bug label Apr 20, 2017
chelmuth added a commit to chelmuth/genode that referenced this issue May 2, 2017
@chelmuth
Warn about questionable call of wait_and_dispatch_one_io_signal
dc866e8 
Issue genodelabs#2399
@chelmuth
Copy link
Member

chelmuth commented May 2, 2017

@alex-ab dc866e8 logs a diagnostic message for this case.

alex-ab added a commit to alex-ab/genode that referenced this issue Aug 8, 2017
@alex-ab
vbox4: disable muen run targets due to issue genodelabs#2399
69b1cdd
nfeske pushed a commit that referenced this issue Aug 9, 2017
@alex-ab @nfeske
vbox4: disable muen run targets due to issue #2399
6b5e67f
cproc added a commit to cproc/genode that referenced this issue Aug 10, 2017
@cproc
VFS: nonblocking interface
4e8e4a1 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 14, 2017
@cproc
VFS: nonblocking interface
ee1a717 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 14, 2017
@cproc
VFS: nonblocking interface
03ad7b0 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
@cproc cproc self-assigned this Aug 15, 2017
@cproc cproc added the fixed label Aug 15, 2017
cproc added a commit to cproc/genode that referenced this issue Aug 15, 2017
@cproc
VFS: nonblocking interface
1006afb 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 15, 2017
@cproc
VFS: nonblocking interface
cde116a 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 15, 2017
@cproc
VFS: nonblocking interface
ebd9915 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 15, 2017
@cproc
VFS: nonblocking interface
9791e97 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
chelmuth pushed a commit that referenced this issue Aug 17, 2017
@alex-ab @chelmuth
vbox4: disable muen run targets due to issue #2399
d73c54c
chelmuth pushed a commit to chelmuth/genode that referenced this issue Aug 17, 2017
@cproc @chelmuth
VFS: nonblocking interface
71fb36c 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 17, 2017
@cproc
fixup "VFS: nonblocking interface" (debugging artifacts)
3bedb83 
Issue genodelabs#2399
chelmuth pushed a commit that referenced this issue Aug 18, 2017
@alex-ab @chelmuth
vbox4: disable muen run targets due to issue #2399
523b317
chelmuth pushed a commit that referenced this issue Aug 18, 2017
@cproc @chelmuth
VFS: nonblocking interface
266125d 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes #2399
chelmuth pushed a commit that referenced this issue Aug 18, 2017
@cproc @chelmuth
fixup "VFS: nonblocking interface" (debugging artifacts)
6e4c005 
Issue #2399
cproc added a commit to cproc/genode that referenced this issue Aug 20, 2017
@cproc
fixup "VFS: nonblocking interface" (Ram_file_system)
4d55248 
Issue genodelabs#2399
chelmuth pushed a commit that referenced this issue Aug 21, 2017
@cproc @chelmuth
fixup "VFS: nonblocking interface" (Ram_file_system)
0381cd6 
Issue #2399
cproc added a commit to cproc/genode that referenced this issue Aug 21, 2017
@cproc
fixup "VFS: nonblocking interface" (Dir_file_system)
e234475 
Issue genodelabs#2399
cproc added a commit to cproc/genode that referenced this issue Aug 21, 2017
@cproc
fixup "VFS: nonblocking interface" (gems)
9ab9571 
Issue genodelabs#2399
chelmuth pushed a commit that referenced this issue Aug 21, 2017
@cproc @chelmuth
fixup "VFS: nonblocking interface" (Dir_file_system)
aa29108 
Issue #2399
chelmuth pushed a commit that referenced this issue Aug 21, 2017
@cproc @chelmuth
fixup "VFS: nonblocking interface" (gems)
f2f6723 
Issue #2399
cproc added a commit to cproc/genode that referenced this issue Aug 22, 2017
@cproc
fixup "VFS: nonblocking interface" (fs_log)
40f6476 
Issue genodelabs#2399
chelmuth pushed a commit that referenced this issue Aug 22, 2017
@cproc @chelmuth
fixup "VFS: nonblocking interface" (fs_log)
1177d98 
Issue #2399
chelmuth pushed a commit that referenced this issue Aug 23, 2017
@cproc @chelmuth
VFS: nonblocking interface
8be6410 
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes #2399
chelmuth added a commit that referenced this issue Aug 24, 2017
@chelmuth
Revert "vbox4: disable muen run targets due to issue #2399"
bb67a59 
This reverts commit 523b317.
chelmuth added a commit that referenced this issue Aug 25, 2017
@chelmuth
Revert "vbox4: disable muen run targets due to issue #2399"
176416f 
This reverts commit 523b317.
chelmuth added a commit that referenced this issue Aug 28, 2017
@chelmuth
Revert "vbox4: disable muen run targets due to issue #2399"
feb2f56 
This reverts commit 523b317.
chelmuth added a commit that referenced this issue Aug 30, 2017
@chelmuth
Revert "vbox4: disable muen run targets due to issue #2399"
2f38f50 
This reverts commit 523b317.
chelmuth added a commit that referenced this issue Jun 4, 2019
@chelmuth
Warn about questionable call of wait_and_dispatch_one_io_signal
9757629 
Issue #2399
chelmuth added a commit that referenced this issue Jun 11, 2019
@chelmuth
Warn about questionable call of wait_and_dispatch_one_io_signal
fca7635 
Issue #2399
chelmuth added a commit that referenced this issue Jun 13, 2019
@chelmuth
Warn about questionable call of wait_and_dispatch_one_io_signal
5738e53 
Issue #2399
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cproc cproc

Labels
bug fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@chelmuth @cproc @alex-ab