Re: [PATCH? v2] powerpc: Hard wire PT_SOFTE value to 1 in gpr_get() too

On Thu, 11 Jun 2020 12:58:31 +0200, Oleg Nesterov wrote: > On 06/11, Madhavan Srinivasan wrote: > > On 6/10/20 8:37 PM, Oleg Nesterov wrote: > > > > This is not consistent and this breaks > > > > http://sourceware.org/systemtap/wiki/utrace/tests/user-regs-peekpoke > > this is 404. Attaching the

Re: perf report: fix off-by-one for non-activation frames

On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote: > Not sure whether it needs be fixed or not. If we fix it, srcline and > address would not match so it can give its own confusion to users. > Ideally it should display an addressof the instruction before the > address IMHO. One can figure

Re: perf report: fix off-by-one for non-activation frames

On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote: > Not sure whether it needs be fixed or not. If we fix it, srcline and > address would not match so it can give its own confusion to users. > Ideally it should display an addressof the instruction before the > address IMHO. One can figure

Re: perf report: fix off-by-one for non-activation frames

On Fri, 16 Jun 2017 13:51:37 +0200, Milian Wolff wrote: > > perf-4.12.0-0.rc5.git0.1.fc27.x86_64 > > 39e32e gdb_main (/usr/libexec/gdb) > > 10b6fa main (/usr/libexec/gdb) > >0x5565f6f6 <+54>:callq 0x558f17a0 > >

Re: perf report: fix off-by-one for non-activation frames

On Fri, 16 Jun 2017 13:51:37 +0200, Milian Wolff wrote: > > perf-4.12.0-0.rc5.git0.1.fc27.x86_64 > > 39e32e gdb_main (/usr/libexec/gdb) > > 10b6fa main (/usr/libexec/gdb) > >0x5565f6f6 <+54>:callq 0x558f17a0 > > >0x5565f6fb

Re: perf report: fix off-by-one for non-activation frames

On Mon, 15 May 2017 17:04:44 +0200, Milian Wolff wrote: commit 1982ad48fc82c284a5cc55697a012d3357e84d01 Author: Milian Wolff Date: Wed May 24 15:21:25 2017 +0900 > --- a/tools/perf/util/unwind-libdw.c > +++ b/tools/perf/util/unwind-libdw.c > @@ -168,12 +168,16 @@

Re: perf report: fix off-by-one for non-activation frames

On Mon, 15 May 2017 17:04:44 +0200, Milian Wolff wrote: commit 1982ad48fc82c284a5cc55697a012d3357e84d01 Author: Milian Wolff Date: Wed May 24 15:21:25 2017 +0900 > --- a/tools/perf/util/unwind-libdw.c > +++ b/tools/perf/util/unwind-libdw.c > @@ -168,12 +168,16 @@ frame_callback(Dwfl_Frame

Re: [PATCH 1/2] perf report: ensure the perf DSO mapping matches what libdw sees

On Mon, 05 Jun 2017 12:41:30 +0200, Jiri Olsa wrote: > On Fri, Jun 02, 2017 at 04:37:52PM +0200, Milian Wolff wrote: > > Debug output showed me that libdw found a module for the last frame > > address, but it thinks it belongs to /usr/lib/ld-2.25.so. I find your patch as a correct workaround of

Re: [PATCH 1/2] perf report: ensure the perf DSO mapping matches what libdw sees

On Mon, 05 Jun 2017 12:41:30 +0200, Jiri Olsa wrote: > On Fri, Jun 02, 2017 at 04:37:52PM +0200, Milian Wolff wrote: > > Debug output showed me that libdw found a module for the last frame > > address, but it thinks it belongs to /usr/lib/ld-2.25.so. I find your patch as a correct workaround of

Re: [PATCH 2/2] perf report: report module before querying isactivation in dwfl unwind

On Mon, 05 Jun 2017 12:47:20 +0200, Jiri Olsa wrote: > On Fri, Jun 02, 2017 at 12:25:08PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 02, 2017 at 04:37:53PM +0200, Milian Wolff escreveu: > > > The PC returned by dwfl_frame_pc may map into a not-yet-reported > > > module. We have to

Re: [PATCH 2/2] perf report: report module before querying isactivation in dwfl unwind

On Mon, 05 Jun 2017 12:47:20 +0200, Jiri Olsa wrote: > On Fri, Jun 02, 2017 at 12:25:08PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 02, 2017 at 04:37:53PM +0200, Milian Wolff escreveu: > > > The PC returned by dwfl_frame_pc may map into a not-yet-reported > > > module. We have to

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, 20 Jun 2016 12:07:56 +0200, Pedro Alves wrote: > On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > > Yuck. I should have dug in to the history. Why not just > > unconditionally sign-extend eax when set by a 32-bit tracer? > > No idea. Roland McGrath knows why he wrote it that way, Cced.

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, 20 Jun 2016 12:07:56 +0200, Pedro Alves wrote: > On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > > Yuck. I should have dug in to the history. Why not just > > unconditionally sign-extend eax when set by a 32-bit tracer? > > No idea. Roland McGrath knows why he wrote it that way, Cced.

Re: [PATCH] perf top: Make -g refer to callchains

On Tue, 19 Nov 2013 10:26:42 +0100, Jean Pihet wrote: > Do you know about the support of AARCH64, both in 64-bit and 32-bit > (compat) mode? > I would be glad to give it a try. Please move this topic to: https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel aarch64 elfutils port

Re: [PATCH] perf top: Make -g refer to callchains

On Tue, 19 Nov 2013 10:26:42 +0100, Jean Pihet wrote: Do you know about the support of AARCH64, both in 64-bit and 32-bit (compat) mode? I would be glad to give it a try. Please move this topic to: https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel aarch64 elfutils port is

Re: [PATCH] perf top: Make -g refer to callchains

On Mon, 18 Nov 2013 18:49:45 +0100, Jiri Olsa wrote: > I think it's an option.. but it'll simpler to try the libdw > interface first and see if it's good/fast enough.. The elfutils libdw unwinder is being upstreamed these weeks, the x86* unwinder itself is already upstream now. > also I recall

Re: [PATCH] perf top: Make -g refer to callchains

On Mon, 18 Nov 2013 18:49:45 +0100, Jiri Olsa wrote: I think it's an option.. but it'll simpler to try the libdw interface first and see if it's good/fast enough.. The elfutils libdw unwinder is being upstreamed these weeks, the x86* unwinder itself is already upstream now. also I recall

Re: [PATCH] ptrace: make PTRACE_DETACH work on non-stopped tracees.

On Wed, 19 Jun 2013 17:15:36 +0200, Denys Vlasenko wrote: > CCing Jan to hear his comments from gdb side. GDB never calls PTRACE_DETACH without having the inferior already stopped. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH] ptrace: make PTRACE_DETACH work on non-stopped tracees.

On Wed, 19 Jun 2013 17:15:36 +0200, Denys Vlasenko wrote: CCing Jan to hear his comments from gdb side. GDB never calls PTRACE_DETACH without having the inferior already stopped. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()

On Tue, 16 Apr 2013 15:25:45 +0200, Oleg Nesterov wrote: > On 04/16, Frederic Weisbecker wrote: > > On Sun, Apr 14, 2013 at 09:12:05PM +0200, Oleg Nesterov wrote: > > Looking at the bug report, it seems they only reproduced with a homemade > > test. No real app has reported that issue? > > iirc

Re: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()

On Tue, 16 Apr 2013 15:25:45 +0200, Oleg Nesterov wrote: On 04/16, Frederic Weisbecker wrote: On Sun, Apr 14, 2013 at 09:12:05PM +0200, Oleg Nesterov wrote: Looking at the bug report, it seems they only reproduced with a homemade test. No real app has reported that issue? iirc (Jan can

Re: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()

On Sun, 14 Apr 2013 21:12:05 +0200, Oleg Nesterov wrote: > Jan, Frederic, et all. What do you think we should do? > > 1. Change ptrace_write_dr7() to do register_user_hw_breakpoint() > if necessary. > > This is what I was going to do, but I am no longer sure > we

Re: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()

On Sun, 14 Apr 2013 21:12:05 +0200, Oleg Nesterov wrote: Jan, Frederic, et all. What do you think we should do? 1. Change ptrace_write_dr7() to do register_user_hw_breakpoint() if necessary. This is what I was going to do, but I am no longer sure we want

Re: PTRACE_SYSCALL && vsyscall (Was: arch_check_bp_in_kernelspace: fix the range check)

On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote: > Yes, that is why I said this needs the new option. I do not mind new options although personally I do not find them meaningful for an already deprecated ABI compatibility-only issue. > If the tracer does PTRACE_SYSCALL the tracee

Re: PTRACE_SYSCALL vsyscall (Was: arch_check_bp_in_kernelspace: fix the range check)

On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote: Yes, that is why I said this needs the new option. I do not mind new options although personally I do not find them meaningful for an already deprecated ABI compatibility-only issue. If the tracer does PTRACE_SYSCALL the tracee reports

Re: [BUG] i386 relocable kernel breakes /proc/kcore debugging

On Mon, 30 Jul 2007 10:03:03 +0200, Vivek Goyal wrote: > On Sat, Jul 28, 2007 at 04:43:43AM +0300, Maxim Levitsky wrote: ... > > gdb 'thinks' that all kernel symbols are below 0x8000 , while they are > > at > > 0xC000 > > > > Turning CONFIG_RELOCATABLE off fixes that, so I assume that

Re: [BUG] i386 relocable kernel breakes /proc/kcore debugging

On Mon, 30 Jul 2007 10:03:03 +0200, Vivek Goyal wrote: On Sat, Jul 28, 2007 at 04:43:43AM +0300, Maxim Levitsky wrote: ... gdb 'thinks' that all kernel symbols are below 0x8000 , while they are at 0xC000 Turning CONFIG_RELOCATABLE off fixes that, so I assume that is the

Re: [PATCH] Support for controlling leds on xbox 360 pad.

. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/input/joystick/Kconfig |2 +- drivers/input/joystick/xpad.c | 87 ++-- 2 files changed, 49 insertions(+), 40 deletions(-) diff --git a/drivers/input/joystick/Kconfig b/drivers/input/jo

Re: [PATCH] Support for controlling leds on xbox 360 pad.

On Wed, 30 May 2007, Jan Kratochvil wrote: Hi, In ideal world having the code in drivers/leds would be preferred but if you want to add the LED code directly to the input driver in this case I have no objection and it probably makes sense. The LED code is already spread about a bit anyway

Re: [PATCH] Support for controlling leds on xbox 360 pad.

On Wed, 30 May 2007, Jan Kratochvil wrote: Hi, In ideal world having the code in drivers/leds would be preferred but if you want to add the LED code directly to the input driver in this case I have no objection and it probably makes sense. The LED code is already spread about a bit anyway

Re: [PATCH] Support for controlling leds on xbox 360 pad.

. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/input/joystick/Kconfig |2 +- drivers/input/joystick/xpad.c | 87 ++-- 2 files changed, 49 insertions(+), 40 deletions(-) diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick

Re: [PATCH] Support for controlling leds on xbox 360 pad.

Hi, On Thu, 31 May 2007, Pavel Machek wrote: Led subsystem allows us to set brightness, but there is nothing like brightness on this device. So brightness is actually interpreted as the command (only values between 0 and 14 are accepted). Ugh, no, I do not think we want to do that. finally!

Re: [PATCH] Support for controlling leds on xbox 360 pad.

Hi, On Thu, 31 May 2007, Pavel Machek wrote: Led subsystem allows us to set brightness, but there is nothing like brightness on this device. So brightness is actually interpreted as the command (only values between 0 and 14 are accepted). Ugh, no, I do not think we want to do that. finally!

Re: [PATCH] Support for controlling leds on xbox 360 pad.

Hi, On Wed, 30 May 2007, Richard Purdie wrote: On Wed, 2007-05-30 at 10:56 -0400, Dmitry Torokhov wrote: Do you think it makes sense to split the driver (and Kconfig options) between input and leds directories as Jan had done? I know that I prefer to keep anything input related in input

Re: [PATCH] Support for controlling leds on xbox 360 pad.

Hi, On Wed, 30 May 2007, Richard Purdie wrote: On Wed, 2007-05-30 at 10:56 -0400, Dmitry Torokhov wrote: Do you think it makes sense to split the driver (and Kconfig options) between input and leds directories as Jan had done? I know that I prefer to keep anything input related in input

Re: [PATCH] Support for controlling leds on xbox 360 pad.

counter. Is it ok? Thanks Jan Kratochvil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Support for controlling leds on xbox 360 pad.

between 0 and 14 are accepted). So this patch uses led subystem in such way that it makes led in /sys/class/leds/xpad:[0-9][0-9]/ for each attached xbox 360 pad. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/input/joystick/xpad.c | 34 --- drivers/input/joystick/

[PATCH] Support for controlling leds on xbox 360 pad.

between 0 and 14 are accepted). So this patch uses led subystem in such way that it makes led in /sys/class/leds/xpad:[0-9][0-9]/ for each attached xbox 360 pad. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/input/joystick/xpad.c | 34 --- drivers/input/joystick/xpad.h | 35

Re: [PATCH] Support for controlling leds on xbox 360 pad.

counter. Is it ok? Thanks Jan Kratochvil - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH][RESEND] PIE randomization

-pie/-fpie) ET_DYN binaries onto a random address (in cases in which mmap() is allowed to perform a randomization). Origin of this patch is in exec-shield (http://people.redhat.com/mingo/exec-shield/) Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- fs/binfmt_elf.c

Re: [PATCH][RESEND] PIE randomization

-pie/-fpie) ET_DYN binaries onto a random address (in cases in which mmap() is allowed to perform a randomization). Origin of this patch is in exec-shield (http://people.redhat.com/mingo/exec-shield/) Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- fs/binfmt_elf.c | 99

[PATCH][RESEND] PIE randomization

, but in exec-shield it is afaik i386 only. Right? Randomizes -pie compiled binaries. The implementation is part of Redhat's exec-shield (http://people.redhat.com/mingo/exec-shield/). Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- fs/binfmt_elf.c

[PATCH][RESEND] PIE randomization

, but in exec-shield it is afaik i386 only. Right? Randomizes -pie compiled binaries. The implementation is part of Redhat's exec-shield (http://people.redhat.com/mingo/exec-shield/). Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- fs/binfmt_elf.c | 96

[PATCH] PIE randomization

/exec-shield/). Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- fs/binfmt_elf.c | 96 ++ 1 files changed, 74 insertions(+), 22 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 9cc4f0a..1156f41 100644 --- a/fs/binfmt

[PATCH] PIE randomization

/exec-shield/). Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- fs/binfmt_elf.c | 96 ++ 1 files changed, 74 insertions(+), 22 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 9cc4f0a..1156f41 100644 --- a/fs/binfmt_elf.c

Re: [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.

Hi again, what do you think about this? (This patch will work only against last gamepad rumble support patch) Thanks for your time Jan Kratochvil BigX button on xbox360 gamepad is surrounded by 4 green leds. This patch adds support to control them. This device understand to 14

Re: [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.

Hi Dmitry, thanks for feedback. Improved version of this patch follows: It is enabled only if CONFIG_XPAD_FF is set to y. Implementation is using force feedback support for memoryless devices. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/usb/input/Kconfig

Re: [PATCH 2/3] xpad.c: Initial support for xbox360 gamepad.

different types of xbox devices. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/usb/input/xpad.c | 151 +++-- 1 files changed, 117 insertions(+), 34 deletions(-) diff --git a/drivers/usb/input/xpad.c b/drivers/usb/input/xpad.c index e

Re: [PATCH 1/3] xpad.c: Added flags into xpad_device structure and removed dpad_mapping.

Hi Dmitry, On Wed, 2 May 2007, Dmitry Torokhov wrote: Hi Jan, On Wednesday 02 May 2007 11:01, Jan Kratochvil wrote: This changes are expected to simplify further improves of this driver, We will need to add information if the driver is xbox360 device or not. Second option was to simply add

Re: [PATCH 1/3] xpad.c: Added flags into xpad_device structure and removed dpad_mapping.

Hi Dmitry, On Wed, 2 May 2007, Dmitry Torokhov wrote: Hi Jan, On Wednesday 02 May 2007 11:01, Jan Kratochvil wrote: This changes are expected to simplify further improves of this driver, We will need to add information if the driver is xbox360 device or not. Second option was to simply add

Re: [PATCH 2/3] xpad.c: Initial support for xbox360 gamepad.

different types of xbox devices. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/usb/input/xpad.c | 151 +++-- 1 files changed, 117 insertions(+), 34 deletions(-) diff --git a/drivers/usb/input/xpad.c b/drivers/usb/input/xpad.c index e4bc76e

Re: [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.

Hi Dmitry, thanks for feedback. Improved version of this patch follows: It is enabled only if CONFIG_XPAD_FF is set to y. Implementation is using force feedback support for memoryless devices. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/usb/input/Kconfig |7 +++ drivers

Re: [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.

Hi again, what do you think about this? (This patch will work only against last gamepad rumble support patch) Thanks for your time Jan Kratochvil BigX button on xbox360 gamepad is surrounded by 4 green leds. This patch adds support to control them. This device understand to 14

[PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.

It is enabled only if CONFIG_XPAD_FF is set to y. Implementation is using force feedback support for memoryless devices. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/usb/input/Kconfig |8 +++ drivers/usb/input/xpad.c | 116 ++

[PATCH 2/3] xpad.c: Initial support for xbox360 gamepad.

one interface protocol from four availaible. It means USB_DEVICE can't be used either. Added xpad360_btn structure with additional buttons for x360 gamepad. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/usb/input/xpad.c | 80 +- 1

[PATCH 1/3] xpad.c: Added flags into xpad_device structure and removed dpad_mapping.

. Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- drivers/usb/input/xpad.c | 102 - 1 files changed, 54 insertions(+), 48 deletions(-) diff --git a/drivers/usb/input/xpad.c b/drivers/usb/input/xpad.c index e4bc76e..2a20aa2 100644 --- a/drive

[PATCH] [RFC] Added USB_DEVICE_INTERFACE_PROTOCOL

The USB_DEVICE_INTERFACE_PROTOCOL will allow to match one interface protocol of vendor specific device. This macro is used in patch adding support for xbox360 to xpad.c Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> --- include/linux/usb.h | 15 +++ 1 files chang

[PATCH 1/3] xpad.c: Added flags into xpad_device structure and removed dpad_mapping.

. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/usb/input/xpad.c | 102 - 1 files changed, 54 insertions(+), 48 deletions(-) diff --git a/drivers/usb/input/xpad.c b/drivers/usb/input/xpad.c index e4bc76e..2a20aa2 100644 --- a/drivers/usb

[PATCH] [RFC] Added USB_DEVICE_INTERFACE_PROTOCOL

The USB_DEVICE_INTERFACE_PROTOCOL will allow to match one interface protocol of vendor specific device. This macro is used in patch adding support for xbox360 to xpad.c Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- include/linux/usb.h | 15 +++ 1 files changed, 15 insertions

[PATCH 2/3] xpad.c: Initial support for xbox360 gamepad.

one interface protocol from four availaible. It means USB_DEVICE can't be used either. Added xpad360_btn structure with additional buttons for x360 gamepad. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/usb/input/xpad.c | 80 +- 1 files

[PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.

It is enabled only if CONFIG_XPAD_FF is set to y. Implementation is using force feedback support for memoryless devices. Signed-off-by: Jan Kratochvil [EMAIL PROTECTED] --- drivers/usb/input/Kconfig |8 +++ drivers/usb/input/xpad.c | 116 + 2