How to trigger races reliably in the Linux kernel

Re:How to trigger races reliably in the Linux kernel by klysm on Tuesday May 05, 2020 @10:25AM (#23080320)

If you manage to reproduce a race, is there some way to capture exactly what the scheduler did and force it to do that again?

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by muricula on Tuesday May 05, 2020 @05:44PM (#23085435)

Try reproducing the race under an emulator like bochs. Bochs can be made fully deterministic, and you can take a snapshot at the beginning of the race and reproduce it every time from the snapshot. One downside is that bochs is very slow.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by jfk13 on Tuesday May 05, 2020 @10:52AM (#23080626)

For debugging purposes, for example? You might be interested in https://rr-project.org.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by throwaway2048 on Tuesday May 05, 2020 @11:29AM (#23081075)

rr isn't going to work on a kernel.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by Hello71 on Tuesday May 05, 2020 @12:04PM (#23081518)

I'm inclined to say that it will work on User Mode Linux, and it looks like QEMU does have record/replay functionality.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by loeg on Tuesday May 05, 2020 @12:34PM (#23081849)

Yes, it works as long as you don't have any real devices that cannot be captured in a reverse-debugger's state history.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by ndesaulniers on Tuesday May 05, 2020 @02:49PM (#23083375)

That won't help with data races in drivers. MMIO can even race and isn't well specified.

[ Parent | on HN ]