https://bugs.kde.org/show_bug.cgi?id=373574
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #3 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
I took a quick look at this problem.
I have to admit that I do not too much understand the logic used
to mark some syscall as SfMayBlock,
or mark them as SfMayBlock only if --sim-hints=fuse-compatible
or not marking them.
For example, sys_rename is FUSE_COMPATIBLE_MAY_BLOCK();
while sys_renameat is not marked.
I am guessing that depending on the fs (in particular, network file systems),
all/most file system operations might potentially block. See e.g. bug 278057
comment 2).
That being said, I think the problem you have is because PRE(sys_readlink)
is doing the complete work of the syscall to possibly have some
special logic needed to handle some /proc filenames.
When using fuse-compatible, the syscall is marked as SfMayBlock but that
is not expected when the PRE(sys_*) is doing all the work : effectively,
if the PRE(sys_*) is doing all the work, how can the syscall block later on ?
So, I think there are 2 ways to fix this:
* if this syscall cannot block, then we can just remove the
FUSE_COMPATIBLE_MAY_BLOCK.
* if the readlink syscall can really block, then it is not ok to
have the PRE(sys_readlink) doing the work. The PRE(sys_readlink)
should change the first argument when needed, let the async syscall
handling do the syscall, and then the POST(sys_readlink) should cleanup
the changed argument (assuming we need some dynamic memory for the
changed argument).
So, at this point, what is really needed is a better understanding of
the SfMayBlock logic ...
--
You are receiving this mail because:
You are watching all bug changes.
