[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-KAQceDE9UmJAvepz8tWGgqyr+drv_WYp-q=7vEEUTfiA@mail.gmail.com>
Date: Wed, 7 Jun 2023 20:20:57 +0200
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>, Jakub Kicinski <kuba@...nel.org>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net, pabeni@...hat.com,
edumazet@...gle.com, netdev@...r.kernel.org, emil.s.tantilov@...el.com,
jesse.brandeburg@...el.com, sridhar.samudrala@...el.com,
shiraz.saleem@...el.com, sindhu.devale@...el.com, willemb@...gle.com,
decot@...gle.com, andrew@...n.ch, leon@...nel.org, mst@...hat.com,
simon.horman@...igine.com, shannon.nelson@....com, stephen@...workplumber.org,
Alan Brady <alan.brady@...el.com>, Joshua Hay <joshua.a.hay@...el.com>,
Madhu Chittim <madhu.chittim@...el.com>, Phani Burra <phani.r.burra@...el.com>,
Shailendra Bhatnagar <shailendra.bhatnagar@...el.com>,
Krishneil Singh <krishneil.k.singh@...el.com>
Subject: Re: [PATCH net-next 05/15] idpf: add create vport and netdev configuration
On Fri, Jun 2, 2023 at 1:48 AM Linga, Pavan Kumar
<pavan.kumar.linga@...el.com> wrote:
>
>
>
> On 5/31/2023 11:22 PM, Jakub Kicinski wrote:
> > On Tue, 30 May 2023 16:44:51 -0700 Tony Nguyen wrote:
> >> @@ -137,8 +210,12 @@ static int idpf_set_msg_pending_bit(struct idpf_adapter *adapter,
> >> * previous message.
> >> */
> >> while (retries) {
> >> - if (!test_and_set_bit(IDPF_VC_MSG_PENDING, adapter->flags))
> >> + if ((vport && !test_and_set_bit(IDPF_VPORT_VC_MSG_PENDING,
> >> + vport->flags)) ||
> >> + (!vport && !test_and_set_bit(IDPF_VC_MSG_PENDING,
> >> + adapter->flags)))
> >> break;
> >> +
> >> msleep(20);
> >> retries--;
> >> }
> >
> > Please use locks. Every single Intel driver comes with gazillion flags
> > and endless bugs when the flags go out of sync.
>
> Thanks for the feedback. Will use mutex lock instead of 'VC_MSG_PENDING'
> flag.
Was that the intent of the comment?
Or is it to replace these individual atomic test_and_set bit
operations with a single spinlock-protected critical section around
all the flag operations?
That's how I read the suggestion.
Powered by blists - more mailing lists