Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Tuong Tong Lien <tuong.t.lien@dektech.com.au>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"jmaloy@redhat.com" <jmaloy@redhat.com>,
	"maloy@donjonn.com" <maloy@donjonn.com>,
	"ying.xue@windriver.com" <ying.xue@windriver.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "tipc-discussion@lists.sourceforge.net" 
	<tipc-discussion@lists.sourceforge.net>
Subject: Re: [net] tipc: fix using smp_processor_id() in preemptible
Date: Wed, 2 Sep 2020 09:10:49 +0200	[thread overview]
Message-ID: <2b31e772-3229-3c67-1faf-9ae88849ce77@gmail.com> (raw)
In-Reply-To: <AM8PR05MB7332020CE2FB9E0B416D70BAE22E0@AM8PR05MB7332.eurprd05.prod.outlook.com>



On 9/1/20 10:52 AM, Tuong Tong Lien wrote:

> Ok, I've got your concern now. Actually when writing this code, I had the same thought as you, but decided to relax it because of the following reasons:
> 1. I don't want to use any locking methods here that can lead to competition (thus affect overall performance...);
> 2. The list is not an usual list but a fixed "ring" of persistent elements (no one will insert/remove any element after it is created);
> 3. It does _not_ matter at all if the function calls will result in the same element, or one call points to the 1st element while another at the same time points to the 3rd one, etc. as long as it returns an element in the list. Also, the per-cpu pointer is _not_ required to exactly point to the next element, but needs to be moved on this or next time..., so just relaxing!
> 4. Isn't a "write" to the per-cpu variable atomic?
> 

I think I will give up, this code is clearly racy, and will consider TIPC as broken.

Your patch only silenced syzbot report, but the bug is still there.



  reply	other threads:[~2020-09-02  7:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 19:37 [net] tipc: fix using smp_processor_id() in preemptible Tuong Lien
2020-08-31  2:14 ` David Miller
2020-08-31  8:14 ` Eric Dumazet
2020-08-31  8:33   ` Tuong Tong Lien
2020-08-31  9:47     ` Eric Dumazet
2020-08-31 10:05       ` Tuong Tong Lien
2020-08-31 12:48         ` Eric Dumazet
2020-09-01 12:18           ` Tuong Tong Lien
2020-09-01 13:15             ` Eric Dumazet
2020-09-01 17:52               ` Tuong Tong Lien
2020-09-02  7:10                 ` Eric Dumazet [this message]
2020-09-15 10:54                   ` Tuong Tong Lien

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=2b31e772-3229-3c67-1faf-9ae88849ce77@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jmaloy@redhat.com \
    --cc=maloy@donjonn.com \
    --cc=netdev@vger.kernel.org \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=tuong.t.lien@dektech.com.au \
    --cc=ying.xue@windriver.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