RFR: 8310656: RISC-V: __builtin___clear_cache can fail silently.

Fei Yang fyang at openjdk.org
Wed Jun 28 07:18:04 UTC 2023


On Tue, 27 Jun 2023 08:19:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> We recently had a bug where user were missing permissions to use this syscall.
> Which caused crashing on, according to hs_err on things like "addi x11, x24, 0" with SIGILL.
> If it fails it is even possible to execute valid but 'old' instruction which may not lead to a crash, instead the program misbehaves.
> 
> To avoid this mess I suggest that we first test the syscall during vm init and we use it directly.
> This way we can make sure it never fails.
> 
> Tested failing syscall with qemu, tested t1 in qemu, t1 on jh7110 in-progress.

Hi, I don't quite understand how this issue triggers. Could it happen on real hardware platforms like Unmatched or others?
Since `__builtin___clear_cache` is a GCC built-in function which doesn't return an error code, my previous understanding is that it will never fail to do its job. And the GCC manual doesn't even mention the cases where this could fail. Also I see uses of this built-in funtions on other platforms like AArch64.


void __builtin___clear_cache (void *begin, void *end) [Built-in Function]
This function is used to flush the processor’s instruction cache for the region of memory
between begin inclusive and end exclusive. Some targets require that the instruction
cache be flushed, after modifying memory containing code, in order to obtain
deterministic behavior.
If the target does not require instruction cache flushes, __builtin___clear_cache
has no effect. Otherwise either instructions are emitted in-line to clear the instruction
cache or a call to the __clear_cache function in libgcc is made.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14670#issuecomment-1610891729


More information about the hotspot-dev mailing list