01.09.2015 17:05, Eugene Shatokhin пишет:
The race 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 race does actually happen.
The race is on
"!skb_queue_empty(&dev->done)" is checked. So
usbnet_terminate_urbs() may stop waiting and return while dev->done
queue still has an item.
Locking in defer_bh() and usbnet_terminate_urbs() was revisited to avoid
this race.
Signed-off-by: Eugene Shatokhin
---
drivers/net/usb
01.09.2015 10:58, Oliver Neukum пишет:
On Mon, 2015-08-31 at 11:50 +0300, Eugene Shatokhin wrote:
But I would have liked it much better if the code became simpler
instead
of more complex.
Me too, but I can see no other way here. The code is simpler without
locking, indeed, but locking is
31.08.2015 10:32, Bjørn Mork пишет:
Eugene Shatokhin writes:
28.08.2015 11:55, Bjørn Mork пишет:
I guess you are right. At least I cannot prove that you are not :)
There is a bit too much complexity involved here for me...
:-)
Yes, it is quite complex.
I admit, it was easier for me to
28.08.2015 11:55, Bjørn Mork пишет:
Eugene Shatokhin writes:
25.08.2015 00:01, Bjørn Mork пишет:
Eugene Shatokhin writes:
The race 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
25.08.2015 00:01, Bjørn Mork пишет:
Eugene Shatokhin writes:
The race 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 race does actually happen
It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
usbnet_stop(), but its value should be read before it is cleared
when dev->flags is set to 0.
The problem was spotted and the fix was provided by
Oliver Neukum .
Signed-off-by: Eugene Shatokhin
---
drivers/net/usb/usbnet
"!skb_queue_empty(&dev->done)" is checked. So
usbnet_terminate_urbs() may stop waiting and return while dev->done
queue still has an item.
Locking in defer_bh() and usbnet_terminate_urbs() was revisited to avoid
this race.
Signed-off-by: Eugene Shatokhin
---
drivers/net/usb
The following problems found when investigating races in usbnet module
are fixed here:
1. EVENT_NO_RUNTIME_PM bit of dev->flags should be read before it is
cleared by "dev->flags = 0". Thanks to Oliver Neukum for spotting this
problem and providing a fix.
2. A race on on skb_queue between usbne
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
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, &
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
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
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_sch
rate */
clear_bit(EVENT_RX_KILL, &dev->flags);
It seems, setting dev->flags to 0 is not necessarily atomic w.r.t.
clear_bit() and other bit operations with dev->flags. It is safer to
make it atomic and this way, make the race harmless.
While at i
Hi,
21.07.2015 17:22, Oliver Neukum пишет:
On Mon, 2015-07-20 at 21:13 +0300, Eugene Shatokhin wrote:
And here, the code clears EVENT_RX_KILL bit in dev->flags, which may
execute concurrently with the above operation:
#0 clear_bit (bitops.h:113, inlined)
#1 usbnet_bh (usbnet.c:1
commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
drm/i915: add poweroff_late handler
If I revert that change, hibernation works well.
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
27.07.2015 13:00, Oliver Neukum пишет:
On Fri, 2015-07-24 at 17:41 +0300, Eugene Shatokhin wrote:
23.07.2015 12:15, Oliver Neukum пишет:
From what I see now in Documentation/atomic_ops.txt, stores to the
properly aligned memory locations are in fact atomic.
They are, but again only with
27.07.2015 15:29, Oliver Neukum пишет:
On Fri, 2015-07-24 at 20:38 +0300, Eugene Shatokhin wrote:
21.07.2015 15:04, Oliver Neukum пишет:
your analysis is correct and it looks like in addition to your proposed
fix locking needs to be simplified and a common lock to be taken.
Suggestions
21.07.2015 15:04, Oliver Neukum пишет:
On Mon, 2015-07-20 at 21:13 +0300, Eugene Shatokhin wrote:
Hi,
I have recently found several data races in "usbnet" module, checked on
vanilla kernel 4.1.0 on x86_64. The races do actually happen, I have
confirmed it by adding delays and usin
23.07.2015 12:15, Oliver Neukum пишет:
On Wed, 2015-07-22 at 21:33 +0300, Eugene Shatokhin wrote:
The following part is not necessary, I think. usbnet_bh() does not
touch
EVENT_NO_RUNTIME_PM bit explicitly and these bit operations are
atomic
w.r.t. each other.
+ mpn |= !test_and_clear_bit
23.07.2015 12:43, Oliver Neukum пишет:
On Mon, 2015-07-20 at 21:13 +0300, Eugene Shatokhin wrote:
[Race #5]
Race on dev->rx_urb_size. I reproduced it a similar way as the races
#2
and #3 (changing MTU while downloading files).
dev->rx_urb_size is written to here:
#0 usbnet_chan
21.07.2015 17:22, Oliver Neukum пишет:
On Mon, 2015-07-20 at 21:13 +0300, Eugene Shatokhin wrote:
And here, the code clears EVENT_RX_KILL bit in dev->flags, which may
execute concurrently with the above operation:
#0 clear_bit (bitops.h:113, inlined)
#1 usbnet_bh (usbnet.c:1
t() is atomic w.r.t. setting dev->flags to 0, this race is
not a problem, I guess. Otherwise, it may be.
--
[Race #5]
Race on dev->rx_urb_size. I reproduced it a similar way as the races #2
and #3 (changing MTU while downloading files).
dev->rx_urb_size is writte
hat KPROBE_INSN_SLOT_SIZE is not less than
MAX_INSN_SIZE.
Signed-off-by: Eugene Shatokhin
---
arch/x86/include/asm/kprobes.h | 15 +++
arch/x86/kernel/kprobes/core.c | 2 +-
kernel/kprobes.c | 20 ++--
3 files changed, 34 insertions(+), 3 deletions(
atch makes the insn slots 16 bytes long, like they were before while
keeping MAX_INSN_SIZE intact.
Other tools may benefit from this change as well.
Signed-off-by: Eugene Shatokhin
---
arch/x86/include/asm/kprobes.h | 1 +
arch/x86/kernel/kprobes/core.c | 2 +-
kernel/kprobes.c | 8
Kprobes' "boost" feature allows to avoid single-stepping in some cases, along
with its overhead. It is useful for the Kprobes that cannot be optimized for
some reason.
Currently, "boost" cannot be applied to the instructions of 10 and 11 bytes in
size, including some rather commonly used kinds
b 5f 52 45),
"movl $0x1,0xf8dd(%rip)" (c7 05 dd f8 00 00 01 00 00 00), etc.
This patch fixes that conditional.
Signed-off-by: Eugene Shatokhin
---
arch/x86/kernel/kprobes/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kprobes/core.c b
25.05.2015 01:32, Laurent Pinchart пишет:
Hi Eugene,
On Wednesday 20 May 2015 17:48:41 Eugene Shatokhin wrote:
Hi,
There is a race in uvcvideo module between uvc_disconnect() and
uvc_v4l2_open() on dev->state. Checked and reproduced that with kernel
4.1-rc1.
drivers/media/usb/
;Effective Data-Race Detection for the
Kernel" - Proc. 9th USENIX Symposium on Operating Systems Design and
Implementation (OSDI'10).
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
al but I guess, better to report it
anyway. Nothing has crashed during my (brief) testing yet, but still.
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.k
Lenovo B590 with kernel 4.0.1 and 4.0.3, x86_64.
Signed-off-by: Eugene Shatokhin
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d21f3b4..ed3c72a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers
= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Tested on Lenovo B590 with kernel 4.0.1 and 4.0.3, x86_64.
Signed-off-by: Eugene Shatok
Hi,
Now that the patch is in mainline (commit
c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd) and kernel 4.1-rc1 is out, do
you mind if I send the backports of that patch to -stable?
Regards,
Eugene
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hello,
It took a while to properly implement the technique I wrote about
earlier but I have prepared a working example. Initially, I did not
reset the Kprobe properly and that caused difficult-to-debug problems.
Anyway, it works now.
In this example, Kprobes are used to execute my functions
Commit-ID: c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd
Gitweb: http://git.kernel.org/tip/c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd
Author: Eugene Shatokhin
AuthorDate: Tue, 17 Mar 2015 19:09:18 +0900
Committer: Ingo Molnar
CommitDate: Tue, 17 Mar 2015 14:00:38 +0100
kprobes/x86: Return
nstruction will
fail, register_kprobe() will return -EINVAL.
This patch fixes the problem.
Signed-off-by: Eugene Shatokhin
---
arch/x86/kernel/kprobes/core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/co
(arch/x86/kernel/kprobes/core.c). The
latter is due to the second call to kernel_insn_init() which zeroes the
struct insn instance, including insn.length.
I will send a patch shortly, please consider it for inclusion.
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubscribe
> (2015/02/24 15:04), Eugene Shatokhin wrote:
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kpro
ay because all HW breakpoints may be already in use.
Would you mean sleep on your handler??
No, I use mdelay(). It is, in essence, a busy-wait loop as far as I
know. The delay intervals may vary, the default is 5 jiffies.
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubs
s are executed then in the same context as the
original instructions.
Still the implementation becomes more and more like Kprobes in some
places over time. If there is a way to avoid reinventing the wheel and
just use Kprobes, I would do that.
So, any ideas?
Regards,
Eugene
--
Eugene Shatokhin,
there, the tools found a number of less
significant of benign ones (racy stat updates, etc.).
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
[2], which I also maintain.
Suggestions, bug reports and other kinds of feedback are welcome, as usual.
Regards,
Eugene
[1] http://code.google.com/p/data-race-test/
[2] http://code.google.com/p/kedr/
--
Eugene Shatokhin, ROSA
www.rosalab.com
--
To unsubscribe from this list: send the line
On 12/11/2013 08:41 PM, Alan Stern wrote:
On Wed, 11 Dec 2013, Eugene Shatokhin wrote:
Hi,
On ROSA Linux with kernel 3.10.21 with DMA debug options enabled, the
kernel sometimes issues a warning about DMA pool corruption (see the log
below).
That happens sometimes, when the system boots or
bmit urb (err = -27)
0xa7 is POOL_POISON_FREED. The memory pages to be allocated from the
pool should be filled with such bytes.
Each time I observed this problem, the first 8 bytes of the listed
memory area were overwritten, with different data each time.
Regards
On 12/10/2013 04:23 PM, Daniel Vetter wrote:
On Tue, Dec 10, 2013 at 12:27:55PM +0400, Eugene Shatokhin wrote:
Hi,
I have recently observed a NULL pointer dereference in i915 driver
on my Eee PC running ROSA Linux with kernel 3.10.21.
The crash occurs during shutdown but quite rarely, not
0 (32-bit, prefetchable) [size=256M]
Memory at f7d0 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Kernel driver in use: i915
Hi,
>Looks like there is a hiccup in scheduling during resume and timer work is
>kicked before its time and starts unnecessary the reset flow.
>Can you check that the device is in good state (/mei/devastate , it
>should be ENABLED).
Yes, /sys/kernel/debug/mei/devstate contains "ENABLED" (chec
Hi,
> You can safely comment out all of the timer_work.
Well, I rebuilt the kernel with the schedule_... commented out (in
mei_me_pci_resume(), for the present). The errors are no longer visible in the
log. The full log is attached.
Regards,
Eugene
system-log-20131107.tar.bz2
Description:
Hi,
> Please try to comment out schedule_delayed_work(&dev->timer_work,
HZ); in pci-me.c
You mean this call in mei_me_pci_resume() rather than in .probe, I
suppose? There are two such calls in pci-me.c.
Regards,
Eugene
--
Eugene Shatokhin, ROSA Laboratory.
www.rosalab
.10.15.
Regards,
Eugene
--
Eugene Shatokhin, ROSA Laboratory.
www.rosalab.com
system_log_20131105.tar.bz2
Description: application/bzip
point release?
Thanks for the info!
Yes, I found this patch an hour ago as well as a similar one for hw_reset.
As we are currently more interested in kernel 3.10.x in ROSA (it is our
main production kernel), I will apply these patches to it first and
re-check.
Regards,
Eugene
--
Eugene
On 11/04/2013 07:48 PM, Eugene Shatokhin wrote:
- Original Message -
I would appreciate the full log and your .config
I have attached the config and the log.
Meanwhile, I have found one suspicious place in the code that could be related:
mei_reset() ignores the return value of
able- Count=1/1 Maskable- 64bit+
Kernel modules: mei_me
-
If you need other info, please let me know.
Regards,
Eugene
--
Eugene Shatokhin, ROSA Laboratory.
www.rosalab.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
54 matches
Mail list logo
