How to trigger races reliably in the Linux kernel

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

For example, some profilers that count the number of times something is run will update a counter without any synchronisation. This risks lost updates, but since you really just need to know if the counter is very low or very high a few lost updates here or there don't really matter.

But I think from some accepted definitions (such as Padua et al) a data race specifically is a bug, so this data interleaving if we're happy with it isn't a data race because it isn't a bug.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by robocat on Tuesday May 05, 2020 @05:30PM (#23085304)

> a few lost updates here or there don't really matter

jerf disagrees in last sentence of other comment: https://news.ycombinator.com/item?id=23079788

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by chrisseaton on Tuesday May 05, 2020 @07:53PM (#23086477)

Well I don't know what to tell you except this is how real production compilers written by experts work in practice.

https://github.com/oracle/graal/blob/4553ea71f15c9e4721565e9...

You can argue this is a bug and they shouldn't write like this, but they don't consider it a bug and they do write like this.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by yencabulator on Wednesday May 06, 2020 @07:46PM (#23097882)

Profiling is a tricky edge case though. If gathering the profiling data costs too much, the results are completely useless. Especially relevant is all the quirky side effects like cache pressure.

So your choices here tend to be: sometimes wrong, or completely useless.

[ Parent | on HN ]

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

+1, at $DAYJOB we use intentional data races all the time for similar purposes.

[ Parent | on HN ]