For now we are not sure about if this is a harmful data race or not. A potential fix could be using the same mutex lock port->mutex instead of port->lock, to protect every write on port->count so the reader can get a consistent view. However, this seems to be a big change so we are wondering it is worthy of this change.
Thanks,
Sishuai
> On Apr 14, 2021, at 2:20 AM, Greg KH <greg@xxxxxxxxx> wrote:
>
> On Wed, Apr 14, 2021 at 12:17:54AM +0000, Gong, Sishuai wrote:
>> Hi,
>>
>> We found a data race between two tty functions tty_port_open() and uart_do_autoconfig() in linux-5.12-rc3 and we are able to reproduce it under x86. In general, when tty_port_open() and uart_do_autoconfig() are running in parallel, uart_do_autoconfig() may fetch an out-of-date value of port->count and enter into a different execution path, as shown below.
>>
>> Currently, we haven’t found any explicit errors due to this data race but we noticed the developer has used lock to read port->count, so we want to point out this data race in case this is unexpected.
>>
>> ------------------------------------------
>> Execution interleaving
>>
>> Thread 1 Thread 2
>> tty_port_open() uart_do_autoconfig()
>>
>> spin_lock_irq(&port->lock);
>> if (mutex_lock_interruptible(&port->mutex))
>> …
>> if (tty_port_users(port) == 1) {
>> uart_shutdown(tty, state);
>>
>> ++port->count;
>> spin_unlock_irq(&port->lock);
>>
>>
>>
>
> Can you send a proposed patch for this to fix the issue as you sem to
> have a reproducer for this that you can test if the change resolves the
> issue or not?
>
> thanks,
>
> greg k-h
