Question About Access Fault Handling in the Kernel

Alexandre Ghiti alex at ghiti.fr
Thu Jul 17 06:59:47 PDT 2025


Hi Vincent,

First sorry for the very late reply.

On 6/3/25 06:25, Vincent Chen wrote:
> Hi all,
> I have a question regarding the current handling flow for access
> faults in the kernel.
>
> In the current implementation, the kernel consistently reports tall
> access faults using a SIGSEGV with error code SEGV_ACCERR, where
> SEGV_ACCERR signifies "Invalid permissions for mapped object"
> according to the POSIX specification.
>
> However, in the RISC-V privilege specification, it states that
> "Implementations may raise access-fault exceptions instead of
> address-misaligned exceptions for some misaligned accesses, indicating
> the instruction should not be emulated by a trap handler". In other
> words, a load/store access fault may be caused by a misaligned AMO
> instruction. In such cases, it seems more appropriate to report the
> error using SIGBUS with the error code BUS_ADRALN, which indicates
> "Invalid address alignment."


I think you're right, it seems more appropriate. But then how do we 
recognize an access fault exception that is caused by a misaligned 
access? Do you have a solution? If that does not slow down the "normal" 
access fault, I guess we can give it a try, what do you think?

Did you encounter this situation where you were reported a SIGSEGV but 
it was actually a SIGBUS?

Sorry again for the delay,

Thanks,

Alex


>
> As I understand it, most access faults are typically caused by
> violations of either PMA or PMP settings. If these settings are
> considered a form of permission for a mapped object, then the current
> implementation using SIGSEGV with SEGV_ACCERR makes sense and helps
> simplify the fault-handling logic.
>
> I’d like to confirm whether this interpretation reflects the reasoning
> behind the current implementation. Any clarification would be
> appreciated. Thanks!
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



More information about the linux-riscv mailing list