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
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
e 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/usbnet.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a
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
e 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 <eugene.shatok...@rosalab.ru>
---
drivers/net/usb/usbnet.c | 39 ---
1 file changed, 28 inserti
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
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
31.08.2015 10:32, Bjørn Mork пишет:
Eugene Shatokhin <eugene.shatok...@rosalab.ru> 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 compl
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
25.08.2015 00:01, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru 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
28.08.2015 11:55, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
25.08.2015 00:01, Bjørn Mork пишет:
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:
The race may happen when a device (e.g. YOTA 4G LTE Modem) is
unplugged while the system is downloading a large
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
e 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/usbnet.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a
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
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, >fl
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
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
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
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 oneu...@suse.de.
Signed-off-by: Eugene Shatokhin eugene.shatok
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
() was revisited to avoid
this race.
Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
drivers/net/usb/usbnet.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index e049857
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_schedule
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
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
and other bit operations with dev->flags. It is safer to
make it atomic and this way, make the race harmless.
While at it, the checking of EVENT_NO_RUNTIME_PM bit of dev->flags in
usbnet_stop() was fixed too: the bit should be checked before dev->flags
is cleared.
Sig
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
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:1475
at it, the checking of EVENT_NO_RUNTIME_PM bit of dev-flags in
usbnet_stop() was fixed too: the bit should be checked before dev-flags
is cleared.
Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
drivers/net/usb/usbnet.c | 49 --
include/linux/usb
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
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 a message to majord...@vger.kernel.org
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
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
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
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
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: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
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 using hardware
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
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_change_mtu (usbnet.c
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
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:1475
e races #2
and #3 (changing MTU while downloading files).
dev->rx_urb_size is written to here:
#0 usbnet_change_mtu (usbnet.c:392)
dev->rx_urb_size = dev->hard_mtu;
Here is the conflicting read from dev->rx_urb_size:
* rx_submit (usbnet.c:467)
size_t siz
-rx_urb_size;
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
PROBE_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(-)
d
is not less than
MAX_INSN_SIZE.
Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
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
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
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/arch
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 of
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 eugene.shatok...@rosalab.ru
---
arch/x86/include/asm/kprobes.h | 1 +
arch/x86/kernel/kprobes/core.c | 2 +-
kernel/kprobes.c | 8
05 dd f8 00 00 01 00 00 00), etc.
This patch fixes that conditional.
Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
arch/x86/kernel/kprobes/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
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/
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/uvc/uvc_driver.c
;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" in
t
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 in
the body of a message to majord
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...@vge
on 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
on Lenovo B590 with kernel 4.0.1 and 4.0.3, x86_64.
Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
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
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.kernel.org
More majordomo info at http
= 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
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 Shatokhin 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
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
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
Commit-ID: c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd
Gitweb: http://git.kernel.org/tip/c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd
Author: Eugene Shatokhin eugene.shatok...@rosalab.ru
AuthorDate: Tue, 17 Mar 2015 19:09:18 +0900
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 17 Mar
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/core.c
index
(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
will
fail, register_kprobe() will return -EINVAL.
This patch fixes the problem.
Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
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
(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 kprobes'
(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 kprobes' bug).
Yes
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 unsubscribe from
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, ROSA
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, ROSA
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 unsubscribe from
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
[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
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 majordomo info
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
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
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,
Eugene
)
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,
Eugene
--
Eugene
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
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
--
, non-prefetchable) [size=1M]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Kernel driver in use: i915
--
Regards,
Eugene
--
Eugene Shatokhin
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
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"
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 (debugfs/mei/devastate , it
should be ENABLED).
Yes, /sys/kernel/debug/mei/devstate contains ENABLED
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,
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(>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.com
--
To unsub
15.
Regards,
Eugene
--
Eugene Shatokhin, ROSA Laboratory.
www.rosalab.com
system_log_20131105.tar.bz2
Description: application/bzip
1 - 100 of 108 matches
Mail list logo
