[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141031.161520.3547230591227504.davem@davemloft.net>
Date: Fri, 31 Oct 2014 16:15:20 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: hayeswang@...ltek.com
Cc: netdev@...r.kernel.org, nic_swsd@...ltek.com,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/3] r8152: clear the flag of
SCHEDULE_TASKLET in tasklet
From: Hayes Wang <hayeswang@...ltek.com>
Date: Fri, 31 Oct 2014 17:56:41 +0800
> Clear the flag of SCHEDULE_TASKLET in bottom_half() to avoid
> re-schedule the tasklet again by workqueue.
>
> Signed-off-by: Hayes Wang <hayeswang@...ltek.com>
> ---
> drivers/net/usb/r8152.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index ff54098..670279a 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1798,6 +1798,9 @@ static void bottom_half(unsigned long data)
> if (!netif_carrier_ok(tp->netdev))
> return;
>
> + if (test_bit(SCHEDULE_TASKLET, &tp->flags))
> + clear_bit(SCHEDULE_TASKLET, &tp->flags);
This is racey.
If another thread of control sets the bit between the test and the
clear, you will lose an event.
It really never makes sense to work with atomic bitops in a non-atomic
test-and-whatever manner like this, it's always a red flag and
indicates you're doing something very wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists