https://bugs.kde.org/show_bug.cgi?id=359871
Steven Smith <so...@archy.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #97682|0 |1 is obsolete| | --- Comment #17 from Steven Smith <so...@archy.org.uk> --- Created attachment 97688 --> https://bugs.kde.org/attachment.cgi?id=97688&action=edit Forth attempt at a Linux fix. I think this one is actually correct. My main concern was that, because we drop the global lock while making the syscall, we might be racing with some other guest thread calling mmap/munmap, so the system call might happen even if ML_(safe_to_deref) says no, and if we've skipped the sanitisation the bug I was trying to fix will come back. Similarly, if POST calls ML_(safe_to_deref) to figure out whether to VG_(free) things then it might either free something it shouldn't or allow the memory to leak. Force-failing guest calls where we can't do the sanitisation seemed like the easiest way of avoiding the issues, except that I still need some way for the PRE call to tell the POST one what/whether it needs to VG_(free), which brought me to the assertion failures in my last attempt. But I suppose it's possible to make syscalls fail without using SET_STATUS_Failure, so that's what this variant does. I think it covers all the relevant cases, or at least all of the ones I've thought of, even if it is a bit more dependent on kernel implementation details than I would have liked. Perhaps I was just overthinking things and the right answer would have been to just ignore the races? The guest would have to be doing something pretty crazy for them to matter, after all. On the other hand, I think this one'll work, and it'd be nice to get the edge cases right, even if it is perhaps a little pedantic. This patch also includes some more bits in scalar.c, but I'm not convinced they represent a sensible way of testing this: 1) I can reproduce the issue with --tool=none, so it clearly isn't a problem with memcheck, and it seems a bit odd to put the test case there. 2) The scalar.c regtest fails on my machine even without any of my changes, seemingly because it only works in 32 bit more and I have a 64 bit system, and it doesn't seem to like the debug symbols on the libc in my cross-compile setup. That makes it tricky for me to do any sensible testing of the test case. I defer to your judgement on whether this ends up being a net positive for the codebase. -- You are receiving this mail because: You are watching all bug changes.