Bug 207911 - Potential data races in `settimeofday`
Summary: Potential data races in `settimeofday`
Status: RESOLVED DUPLICATE of bug 207913
Alias: None
Product: Timers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: john stultz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-27 02:24 UTC by Yanze
Modified: 2020-05-27 02:31 UTC (History)
0 users

See Also:
Kernel Version: 5.7-rc7
Subsystem:
Regression: No
Bisected commit-id:


Attachments
No.1 race report (firsttime) (130.19 KB, image/png)
2020-05-27 02:24 UTC, Yanze
Details

Description Yanze 2020-05-27 02:24:10 UTC
Created attachment 289321 [details]
No.1 race report (firsttime)

Hello, we are working on a static race detection tool and we tested it on the Linux kernel.

The races we found do not appear to be dangerous to the core functions of the kernel, but we thought it would be better to report it just in case it leads to undefined behavior.

The well-formatted reports are attached.

There are 3 races in total, all potentially happen when the system call `settimeofday` is called concurrently:

1. The race is on `firsttime` in `do_sys_settimeofday64()` in the `kernel/time/time.c`. The read of `firsttime` at line 188 and the write at line 189 are not protected by locks.

2. The race is on `persistent_clock_is_local` in `timekeeping_warp_clock()` in `kernel/time/timekeeping.c`. The write at line 1337 could potentially race with itself, if `settimeofday` is called concurrently

3. The race is on `vdata[CS_HRES_COARSE]` in `update_vsyscall_tz()` in `kernel/time/vsyscall.c`. The write at line 125 and 126 could potentially race with themselves, if `settimeofday` is called concurrently.
Comment 1 Yanze 2020-05-27 02:31:57 UTC

*** This bug has been marked as a duplicate of bug 207913 ***

Note You need to log in before you can comment on or make changes to this bug.