On 7/24/21 3:54 PM, Hin-Tak Leung wrote:
On Saturday, 24 July 2021, 19:35:12 BST, Salah Triki <salah.triki@xxxxxxxxx> wrote:
> Replace udev with usb_get_dev() in order to make code cleaner.
> Signed-off-by: Salah Triki <salah.triki@xxxxxxxxx>
> ---
> drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
> index eb68b2d3caa1..30bb3c2b8407 100644
> --- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
> +++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
> @@ -1455,9 +1455,7 @@ static int rtl8187_probe(struct usb_interface *intf,
> SET_IEEE80211_DEV(dev, &intf->dev);
> usb_set_intfdata(intf, dev);
> - priv->udev = udev;
> -
> - usb_get_dev(udev);
> + priv->udev = usb_get_dev(udev);
> skb_queue_head_init(&priv->rx_queue);
> --
> 2.25.1
It is not cleaner - the change is not functionally equivalent. Before the
change, the reference count is increased after the assignment; and after the
change, before the assignment. So my question is, does the reference count
increasing a little earlier matters? What can go wrong between very short time
where the reference count increases, and priv->udev not yet assigned? I think
there might be a race condition where the probbe function is called very shortly
twice.
Especially if the time of running the reference count function is non-trivial.
Larry, what do you think?
My belief was that probe routines were called in order, which was confirmed by
GregKH. As a result, there can be no race condition, and the order of setting
the reference count does not matter. On the other hand, the current code is not
misleading, nor unclear. Why should it be changed?
NACK on the patch.
Larry
