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
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
On Mon, 2015-08-24 at 15:29 +0200, Bjørn Mork wrote:
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
Stopping the tasklet rescheduling etc depends only on netif_running(),
which will be false
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 writing, I
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
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
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
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
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, >flags)", and vice versa.
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, >flags)", and vice versa.
>>>
>>> So the
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, >flags)", and vice versa.
So the following might be possible, although unlikely:
CPU0
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru 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),
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru 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,
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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 eugene.shatok...@rosalab.ru writes:
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
The problem is not in the reordering but rather in the fact that
dev-flags = 0 is not necessarily atomic
w.r.t.
24.08.2015 20:43, David Miller пишет:
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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
On Mon, 24 Aug 2015, David Miller wrote:
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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:
On Mon, 24 Aug 2015, Alan Stern wrote:
On Mon, 24 Aug 2015, David Miller wrote:
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
Date: Wed, 19 Aug 2015 14:59:01 +0300
So the following might be possible, although unlikely:
CPU0 CPU1
clear_bit:
From: Alan Stern st...@rowland.harvard.edu
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
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, >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,
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,
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
Eugene Shatokhin eugene.shatok...@rosalab.ru 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
19.08.2015 13:54, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
19.08.2015 04:54, David Miller пишет:
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
19.08.2015 04:54, David Miller пишет:
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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)
/*
19.08.2015 04:54, David Miller пишет:
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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.
*
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),
>
From: Eugene Shatokhin eugene.shatok...@rosalab.ru
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
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
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
32 matches
Mail list logo
