Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Dmitry Vyukov <dvyukov@google.com>,
        syzbot <syzbot+5c54bd3eb218bb595aa9@syzkaller.appspotmail.com>
Cc:     linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        Marco Elver <elver@google.com>
Subject: Re: [syzbot] [kernel?] KCSAN: data-race in do_timer_create /
 do_timer_create (8)
In-Reply-To: <CACT4Y+b2Bf6N=Wto686X=BJsjhpDJw7Xm4yJtszgxCSogX+0-g@mail.gmail.com>
References: <000000000000a3723305f9d98fc3@google.com>
 <CACT4Y+b2Bf6N=Wto686X=BJsjhpDJw7Xm4yJtszgxCSogX+0-g@mail.gmail.com>
Date:   Sat, 22 Apr 2023 00:36:45 +0200
Message-ID: <87cz3w277m.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Fri, Apr 21 2023 at 16:49, Dmitry Vyukov wrote:
> int first_free_id = sig->posix_timer_id;
>
> runs concurrently with:
>
> if (++sig->posix_timer_id < 0)
>     sig->posix_timer_id = 0;
> if ((sig->posix_timer_id == first_free_id) && (ret == -ENOENT))
>     /* Loop over all possible ids completed */
>     ret = -EAGAIN;
>
> I am not sure how important/realistic this wrap-around handling is,
> but as the result of the race first_free_id can be negative (if it
> reads the value at just the right moment). Then wrap-around will never
> be detected and the loop will loop forever uninterruptably.

It's probably not that problematic, but that code is silly for other
reasons. I'll have a look.

Thanks,

        tglx