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
for the race on dev->flags has been removed because the race is
not considered harmful.
Regards,
Eugene
--
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/
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
removed because the race is
not considered harmful.
Regards,
Eugene
--
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 the FAQ at http
() 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
Checkpatch didn't stop complaining about it and as linux/uaccess.h also
includes asm/uaccess.h, there shouldn't be a problem.
Signed-off-by: Joseph-Eugene Winzer
---
drivers/staging/rtl8192u/r8192U_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging
Fixed a few lines that were longer than 80 chars.
Signed-off-by: Joseph-Eugene Winzer
---
drivers/staging/rtl8192u/r8192U_core.c | 61 +++---
1 file changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging
Reformatting the code without introducing other warnings
like 'Avoid unnecessary line continuations' or breaking strings.
Signed-off-by: Joseph-Eugene Winzer
---
drivers/staging/rtl8192u/r8192U_core.c | 809 ++---
1 file changed, 536 insertions(+), 273 deletions
Fixing several coding style issues, like
C99 Comment Style
Trailing whitespaces
Inconsistent spacing of operators
Started to reformat comments/expressions for 80 character limit
Signed-off-by: Joseph-Eugene Winzer
---
drivers/staging/rtl8192u/r8192U_core.c | 1323
kfree() can handle NULL pointers itself, so the check is unnecessary.
Signed-off-by: Joseph-Eugene Winzer
---
drivers/staging/rtl8192u/r8192U_core.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging
kfree() can handle NULL pointers itself, so the check is unnecessary.
Signed-off-by: Joseph-Eugene Winzer m...@openmailbox.org
---
drivers/staging/rtl8192u/r8192U_core.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b
Fixing several coding style issues, like
C99 Comment Style
Trailing whitespaces
Inconsistent spacing of operators
Started to reformat comments/expressions for 80 character limit
Signed-off-by: Joseph-Eugene Winzer m...@openmailbox.org
---
drivers/staging/rtl8192u/r8192U_core.c
Reformatting the code without introducing other warnings
like 'Avoid unnecessary line continuations' or breaking strings.
Signed-off-by: Joseph-Eugene Winzer m...@openmailbox.org
---
drivers/staging/rtl8192u/r8192U_core.c | 809 ++---
1 file changed, 536 insertions
Fixed a few lines that were longer than 80 chars.
Signed-off-by: Joseph-Eugene Winzer m...@openmailbox.org
---
drivers/staging/rtl8192u/r8192U_core.c | 61 +++---
1 file changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b
Checkpatch didn't stop complaining about it and as linux/uaccess.h also
includes asm/uaccess.h, there shouldn't be a problem.
Signed-off-by: Joseph-Eugene Winzer m...@openmailbox.org
---
drivers/staging/rtl8192u/r8192U_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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 +
obes/core.c | 2 +-
kernel/kprobes.c | 8 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
Regards,
Eugene
--
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 the FAQ at http://www.tux.org/lkml/
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
insertions(+), 3 deletions(-)
Regards,
Eugene
--
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 the FAQ at http://www.tux.org/lkml/
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
Hi Marcel,
Thanks for a quick reply!
19.05.2015 21:19, Marcel Holtmann пишет:
Hi Eugene,
USB Bluetooth module by Foxconn International, Inc. (USB IDs: 105b:e065)
is based on BCM43142A0 chip by Broadcom. This module can be found, for
example, in Lenovo B590 and a few other laptops
Hi Marcel,
Thanks for a quick reply!
19.05.2015 21:19, Marcel Holtmann пишет:
Hi Eugene,
USB Bluetooth module by Foxconn International, Inc. (USB IDs: 105b:e065)
is based on BCM43142A0 chip by Broadcom. This module can be found, for
example, in Lenovo B590 and a few other laptops
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
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
)
* opcodes f6 and f7 with ModRM.reg != 001(b): TEST, NOT, NEG, MUL, IMUL,
DIV, IDIV (Grp 3-1A)
* opcodes fe and ff with ModRM.reg being 000(b) or 001(b): INC, DEC (Grp
4-1A and 5-1A)
* opcode 0f c7 with ModRM.reg == 001(b): CMPXCHG8B, CMPXCHG16B.
Not sure why Kprobes do so.
Regards,
Eugene
)
* opcodes f6 and f7 with ModRM.reg != 001(b): TEST, NOT, NEG, MUL, IMUL,
DIV, IDIV (Grp 3-1A)
* opcodes fe and ff with ModRM.reg being 000(b) or 001(b): INC, DEC (Grp
4-1A and 5-1A)
* opcode 0f c7 with ModRM.reg == 001(b): CMPXCHG8B, CMPXCHG16B.
Not sure why Kprobes do so.
Regards,
Eugene
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
Commit-ID: b6085a865762236bb84934161273cdac6dd11c2d
Gitweb: http://git.kernel.org/tip/b6085a865762236bb84934161273cdac6dd11c2d
Author: Eugene Surovegin
AuthorDate: Thu, 23 Jan 2014 09:31:20 -0800
Committer: H. Peter Anvin
CommitDate: Tue, 25 Feb 2014 16:57:47 -0800
x86, kaslr: export
Commit-ID: b6085a865762236bb84934161273cdac6dd11c2d
Gitweb: http://git.kernel.org/tip/b6085a865762236bb84934161273cdac6dd11c2d
Author: Eugene Surovegin surove...@google.com
AuthorDate: Thu, 23 Jan 2014 09:31:20 -0800
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 25 Feb
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
201 - 300 of 554 matches
Mail list logo