On Mon, 2015-08-24 at 14:21 -0400, Alan Stern wrote:
> > In theory, an architecture could implement atomic bit operations
> using
> > a spinlock to insure atomicity. I don't know if any architectures
> do
> > this, but if they do then the scenario above could arise.
>
> Now that I see this in w
On Mon, 2015-08-24 at 15:29 +0200, Bjørn Mork wrote:
> Eugene Shatokhin writes:
>
> > 19.08.2015 15:31, Bjørn Mork пишет:
> >> Eugene Shatokhin writes:
> >> Stopping the tasklet rescheduling etc depends only on netif_running(),
> >> which will be false when usbnet_stop is called. There is no n
From: Alan Stern
Date: Mon, 24 Aug 2015 14:06:15 -0400 (EDT)
> On Mon, 24 Aug 2015, David Miller wrote:
>> Atomic operations like clear_bit also will behave that way.
>
> Are you certain about that? I couldn't find any mention of it in
> Documentation/atomic_ops.txt.
>
> In theory, an architec
On Mon, 24 Aug 2015, Alan Stern wrote:
> On Mon, 24 Aug 2015, David Miller wrote:
>
> > From: Eugene Shatokhin
> > Date: Wed, 19 Aug 2015 14:59:01 +0300
> >
> > > So the following might be possible, although unlikely:
> > >
> > > CPU0 CPU1
> > > clear_bit: read dev
24.08.2015 20:43, David Miller пишет:
From: Eugene Shatokhin
Date: Wed, 19 Aug 2015 14:59:01 +0300
So the following might be possible, although unlikely:
CPU0 CPU1
clear_bit: read dev->flags
clear_bit: clear EVENT_RX_KILL in the read value
dev-
On Mon, 24 Aug 2015, David Miller wrote:
> From: Eugene Shatokhin
> Date: Wed, 19 Aug 2015 14:59:01 +0300
>
> > So the following might be possible, although unlikely:
> >
> > CPU0 CPU1
> > clear_bit: read dev->flags
> > clear_bit: clear EVENT_RX_KIL
From: Eugene Shatokhin
Date: Wed, 19 Aug 2015 14:59:01 +0300
> So the following might be possible, although unlikely:
>
> CPU0 CPU1
> clear_bit: read dev->flags
> clear_bit: clear EVENT_RX_KILL in the read value
>
> dev->flags=0;
>
>
24.08.2015 16:29, Bjørn Mork пишет:
Eugene Shatokhin writes:
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin writes:
The problem is not in the reordering but rather in the fact that
"dev->flags = 0" is not necessarily atomic
w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice ver
Eugene Shatokhin writes:
> 19.08.2015 15:31, Bjørn Mork пишет:
>> Eugene Shatokhin writes:
>>
>>> The problem is not in the reordering but rather in the fact that
>>> "dev->flags = 0" is not necessarily atomic
>>> w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice versa.
>>>
>>> So the fol
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin writes:
The problem is not in the reordering but rather in the fact that
"dev->flags = 0" is not necessarily atomic
w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice versa.
So the following might be possible, although unlikely:
CPU0
Eugene Shatokhin writes:
> The problem is not in the reordering but rather in the fact that
> "dev->flags = 0" is not necessarily atomic
> w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice versa.
>
> So the following might be possible, although unlikely:
>
> CPU0 CPU1
>
19.08.2015 13:54, Bjørn Mork пишет:
Eugene Shatokhin writes:
19.08.2015 04:54, David Miller пишет:
From: Eugene Shatokhin
Date: Fri, 14 Aug 2015 19:58:36 +0300
2. The second race is on dev->flags.
dev->flags is set to 0 here:
*0 usbnet_stop (usbnet.c:816)
/* deferred work (task, ti
Eugene Shatokhin writes:
> 19.08.2015 04:54, David Miller пишет:
>> From: Eugene Shatokhin
>> Date: Fri, 14 Aug 2015 19:58:36 +0300
>>
>>> 2. The second race is on dev->flags.
>>>
>>> dev->flags is set to 0 here:
>>> *0 usbnet_stop (usbnet.c:816)
>>> /* deferred work (task, timer, softirq)
19.08.2015 04:54, David Miller пишет:
From: Eugene Shatokhin
Date: Fri, 14 Aug 2015 19:58:36 +0300
2. The second race is on dev->flags.
dev->flags is set to 0 here:
*0 usbnet_stop (usbnet.c:816)
/* deferred work (task, timer, softirq) must also stop.
* can't flush_scheduled_work()
From: Eugene Shatokhin
Date: Fri, 14 Aug 2015 19:58:36 +0300
> 2. The second race is on dev->flags.
>
> dev->flags is set to 0 here:
> *0 usbnet_stop (usbnet.c:816)
> /* deferred work (task, timer, softirq) must also stop.
> * can't flush_scheduled_work() until we drop rtnl (later),
>
Both races may happen when a device (e.g. YOTA 4G LTE Modem) is
unplugged while the system is downloading a large file from the Net.
Hardware breakpoints and Kprobes with delays were used to confirm that
the races do actually happen.
1. The first race is on skb_queue ('next' pointer) between usbn
16 matches
Mail list logo
