From: Jia-Ju Bai <baijiaju1990@gmail.com>
To: sgruszka@redhat.com, kvalo@codeaurora.org, davem@davemloft.net
Cc: linux-wireless@vger.kernel.org, netdev <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [Report] net: wireless: iwlegacy: Several possible data races
Date: Sat, 6 Oct 2018 10:25:13 +0800 [thread overview]
Message-ID: <be47676b-baf3-7655-ff83-8b3ed370c624@gmail.com> (raw)
****** Possible race 0 ******
CPU0:
il4965_mac_tx
il4965_tx_skb
line 1687: spin_lock_irqsave(&il->lock, flags)
line 1894: q->write_ptr = il_queue_inc_wrap(...) [WRITE]
CPU1:
il4965_irq_tasklet
il_txq_update_write_ptr
line 2749: il_wr(..., txq->q.write_ptr); [READ]
line 2757: _il_wr(..., txq->q.write_ptr); [READ]
CPU2:
il_bg_watchdog
il_check_stuck_queue
line 4817: if (q->read_ptr == q->write_ptr) [READ]
CPU3:
il4965_irq_tasklet
il4965_rx_handle
line 4827, function pointer: il->handlers[pkt->hdr.cmd] (il, rxb);
il4965_hdl_tx
il_queue_used
line 868: return q->write_ptr >= ... q->write_ptr ...
[READ]
As for q->write_ptr, the WRITE operation in CPU0 is performed with holding
a spinlock il->lock, but the READ operations in CPU1, CPU2 and CPU3
are performed without holding this spinlock, so there may exist data races.
****** Possible race 1 ******
CPU0:
il4965_irq_tasklet
il4965_rx_handle
line 4827, function pointer: il->handlers[pkt->hdr.cmd] (il, rxb);
il4965_hdl_tx
line 2834: spin_lock_irqsave(&il->sta_lock, flags)
il4965_tx_queue_reclaim
line 2490: q->read_ptr = ... [WRITE]
CPU1:
il_bg_watchdog
il_check_stuck_queue
line 4817: q->read_ptr == q->write_ptr [READ]
As for q->read_ptr, the WRITE operation in CPU0 is performed with
holding a spinlock il->sta_lock, but the READ operation in CPU1 is
performed without holding this spinlock, so there may exist a data race.
****** Possible race 2 ******
CPU0:
il4965_mac_tx
il4965_tx_skb
line 1687: spin_lock_irqsave(&il->lock, flags)
line 1863: txq->need_update = 1 [WRITE]
CPU1:
il4965_irq_tasklet
il_txq_update_write_ptr
line 2731: if (txq->need_update == 0) [READ]
As for txq->need_update, the WRITE operation in CPU0 is performed with
holding a spinlock il->lock, but the READ operation in CPU1 is performed
without holding this spinlock, so there may exist a data race.
I do not find good ways to fix these possible data races, so I only
report them.
Best wishes,
Jia-Ju Bai
reply other threads:[~2018-10-06 2:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=be47676b-baf3-7655-ff83-8b3ed370c624@gmail.com \
--to=baijiaju1990@gmail.com \
--cc=davem@davemloft.net \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sgruszka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).