The call paths in Linux 4.16.7 that may raise the first data race:
CPU0:
tg3_open
tg3_start
line 11611: spin_lock_bh()
tg3_enable_ints
line 1023: tp->tnapi->last_tag [READ]
CPU1:
tg3_poll
line 7341: tnapi->last_tag [WRITE]
The READ operation in CPU0 is performed with holding a spinlock (line
11611), but the WRITE operation in CPU1 is performed without holding
this spinlock, so it may cause a data race here.
A possible fix may be to add spin_lock_bh() in tg3_poll().
-----------------------------------------------------------------------
The call paths in Linux 4.16.7 that may raise the second data race:
CPU0:
tg3_open
tg3_start
line 11611: spin_lock_bh()
tg3_enable_ints
line 1023: tp->irq_sync [WRITE]
CPU1:
tg3_interrupt_tagged
tg3_irq_sync
line 7341: tp->irq_sync [READ]
The WRITE operation in CPU0 is performed with holding a spinlock (line
11611), but the READ operation in CPU1 is performed without holding this
spinlock, so it may cause a data race here.
A possible fix may be to add spin_lock_bh() in tg3_irq_sync().
I am not sure that whether the possible fixes are correct, so I only
report the data races.
Best wishes,
Jia-Ju Bai
On Wed, Jun 27, 2018 at 7:17 AM, Jia-Ju Bai <[email protected]> wrote:
> The call paths in Linux 4.16.7 that may raise the first data race:
>
> CPU0:
> tg3_open
> tg3_start
> line 11611: spin_lock_bh()
> tg3_enable_ints
> line 1023: tp->tnapi->last_tag [READ]
>
> CPU1:
> tg3_poll
> line 7341: tnapi->last_tag [WRITE]
>
> The READ operation in CPU0 is performed with holding a spinlock (line
> 11611), but the WRITE operation in CPU1 is performed without holding this
> spinlock, so it may cause a data race here.
> A possible fix may be to add spin_lock_bh() in tg3_poll().
>
> -----------------------------------------------------------------------
>
> The call paths in Linux 4.16.7 that may raise the second data race:
>
> CPU0:
> tg3_open
> tg3_start
> line 11611: spin_lock_bh()
> tg3_enable_ints
> line 1023: tp->irq_sync [WRITE]
>
> CPU1:
> tg3_interrupt_tagged
> tg3_irq_sync
> line 7341: tp->irq_sync [READ]
>
> The WRITE operation in CPU0 is performed with holding a spinlock (line
> 11611), but the READ operation in CPU1 is performed without holding this
> spinlock, so it may cause a data race here.
> A possible fix may be to add spin_lock_bh() in tg3_irq_sync().
>
> I am not sure that whether the possible fixes are correct, so I only report
> the data races.
>
>
> Best wishes,
> Jia-Ju Bai
>
>
We will evaluate this and provide an update on this.