From: Kalle Valo <kvalo@kernel.org>
To: <Ajay.Kathat@microchip.com>
Cc: <linux-wireless@vger.kernel.org>, <Claudiu.Beznea@microchip.com>,
<Sripad.Balwadgi@microchip.com>, <mwalle@kernel.org>
Subject: Re: [PATCH] wifi: wilc1000: fix kernel oops during interface down during background scan
Date: Sat, 06 May 2023 08:50:58 +0300 [thread overview]
Message-ID: <87sfcanh31.fsf@kernel.org> (raw)
In-Reply-To: <cffca4d1-5ab5-0633-7bab-00d65526bfa7@microchip.com> (Ajay Kathat's message of "Fri, 5 May 2023 20:53:12 +0000")
<Ajay.Kathat@microchip.com> writes:
>>> @@ -781,13 +776,15 @@ static int wilc_mac_close(struct net_device *ndev)
>>> if (vif->ndev) {
>>> netif_stop_queue(vif->ndev);
>>>
>>> + if (wl->open_ifcs == 0)
>>> + wl->close = 1;
>>> +
>>
>> wl-close is an int, I wonder if it's racy to int as a flag like this? In
>> cases like this I usually use set_bit() & co because those guarantee
>> atomicity, though don't know if that's overkill.
>>
>
> I think it's a good idea to use an atomic operation but I am not sure if
> using atomic for 'wl->close' will have much impact. For instance, if any
> new work gets added to the workqueue before the 'wl->close=1' is fully
> completed, then that work would get executed as normal.
Sure, this is most likely a small race condition. But still a race.
> However, I feel it's safe to define 'wl->close' as atomic_t type. I will
> prepare the conversion patch and will try to include it along with the
> updated version of this patch.
Why atomic_t? You only use values 0 and 1 so test_bit() and set_bit()
sounds more approriate to me.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2023-05-06 5:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 1:20 [PATCH] wifi: wilc1000: fix kernel oops during interface down during background scan Ajay.Kathat
2023-04-05 11:40 ` Michael Walle
2023-04-11 11:24 ` Johannes Berg
2023-04-12 0:04 ` Ajay.Kathat
2023-05-05 15:47 ` Kalle Valo
2023-05-05 20:53 ` Ajay.Kathat
2023-05-06 5:50 ` Kalle Valo [this message]
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=87sfcanh31.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=Ajay.Kathat@microchip.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=Sripad.Balwadgi@microchip.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mwalle@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.