Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov wrote: > > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after > PTRACE_INTERRUPT, you know that the tracee did not report the "new" > SIGTTIN. It seems possible to remember whether or not we injected a stopping

How does the size field work in IOCTL numbers?

Hi folks, this is more of a general linux question, but since I noticed it while looking perf_events code, I'm ccing perf_events folks in case the answer is perf_events specific (hope that's ok). uapi/linux/perf_event.h has the following: #define PERF_EVENT_IOC_PERIOD _IOW('$', 4, __u64) #define

Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

11:34 AM, Oleg Nesterov <o...@redhat.com> wrote: > On 08/18, Keno Fischer wrote: >> >> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov <o...@redhat.com> wrote: >> > >> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after >> > PTRA

Use of r10 in powerpc syscall entry

Hi Anton, I was reading the powerpc syscall entry code and git points me at your commit 05b05f28 (powerpc: Relocatable system call no longer uses the LR) for one part that confused me, so I hope you don't mind a quick question. In particular, that commit removed the use of r10 to restore lr, but

ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

Consider below test case (not all of it is necessary for reproducing the behavior in question, but I wanted to cover related cases as well to make sure they behave as expected). In this test case, the last group-stop (after PTRACE_INTERRUPT) is delivered with a WSTOPSIG(status) of SIGTTIN, which

[PATCH] um: Fix compile failure due to current_text_address() definition

Fixes the following link error: ``` /usr/bin/ld: net/built-in.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC ``` This is the same definition used on some other architectures. Signed-off-by: Keno Fischer <k...@juliacomputing.com>

[PATCH] gpio: Guard devm_* functions behind CONFIG_GPIO_DEVRES not CONFIG_GPIOLIB

problems in modpost. Signed-off-by: Keno Fischer <k...@juliacomputing.com> --- I encountered this while trying to build uml in an attempt to debug some kernel behavior I don't understand. To be as close to my actual kernel as possible, I used the same .config, which of course tried to build a

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

Yes On Thu, Nov 10, 2016 at 3:14 PM, Richard Weinberger <rich...@nod.at> wrote: > Keno, > > On 10.11.2016 21:10, Keno Fischer wrote: >>> The problem is ready being solved in a generic way: >>> http://marc.info/?l=linux-kernel=147828481602561=2 >>>

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

> The problem is ready being solved in a generic way: > http://marc.info/?l=linux-kernel=147828481602561=2 > > Can you please give this patch a try? No dice. After backing out my patch and applying that one I get: /usr/bin/ld: error: net/built-in.o: requires unsupported dynamic reloc 11;

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

On Thu, Nov 10, 2016 at 3:19 PM, Richard Weinberger wrote: > Can you please reply to Sebastian's patch series and explain him how you > trigger > that error? > I don't have a gcc broken by Debian on my machine right now. I'm not sure how to reply to his patch series directly

Bug in fs/gs_base PTRACE_SETREGS on pre-4.7 kernels

Hi Andy (), this is more of a heads up than a bug report, since it turns out you already fixed this in 731e33e: x86/arch_prctl/64: Remove FSBASE/GSBASE < 4G optimization In any case, without that commit, trying to use PTRACE_SETREGS to set either fs_base, or gs_base to 0 when it was previously

[PATCH v2] gpio: Remove GPIO_DEVRES option

This option was added in 6a89a314ab107a12af08c71420c19a37a30fc2d3 to allow use of the devm_gpio_* functions without CONFIG_GPIOLIB. However, only a few months later in b69ac52449c658b7ac40034dc3c5f5f4a71a723d, CONFIG_GPIOLIB, was added as a dependency, defeating the original purpose of this

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

Just as an FYI, the linker bug has been fixed in binutils. On Fri, Nov 11, 2016 at 5:07 PM, Richard Weinberger <rich...@nod.at> wrote: > On 11.11.2016 22:03, Keno Fischer wrote: >> Did you have CONFIG_INET set? I'm attaching my full .config. This is >> on vanilla

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

Did you have CONFIG_INET set? I'm attaching my full .config. This is on vanilla Ubuntu 16.10. I did see the same error when building with `CONFIG_STATIC_LINK=y`. Note that I also, separately, ran into a linker problem, though I believe it is unrelated to this patch (though perhaps is related to

Re: [PATCH] mm: Respect FOLL_FORCE/FOLL_COW for thp

>> @@ -783,7 +793,7 @@ struct page *follow_devmap_pmd(struct vm_area_struct >> *vma, unsigned long addr, >> >> assert_spin_locked(pmd_lockptr(mm, pmd)); >> >> - if (flags & FOLL_WRITE && !pmd_write(*pmd)) >> + if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags)) >>

[PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

NCE to make sure we notice if we ever do. Signed-off-by: Keno Fischer <k...@juliacomputing.com> --- Changes since v1: * In follow_devmap_pmd, WARN_ONCE if FOLL_COW is encountered, rather than allowing it, since that situation should not happen. As suggested by Kirill A. Shutemov mm/huge_me

[PATCH] mm: Respect FOLL_FORCE/FOLL_COW for thp

n gup.c in the original commit. The same pattern existed in follow_devmap_pmd, so I have changed that location as well. However, I do not have a test case that for that code path. Signed-off-by: Keno Fischer <k...@juliacomputing.com> --- mm/huge_memory.c | 14 -- 1 file changed, 12

Why do Zombie process' /proc entries have uid 0?

This is mostly out of curiosity, but I was surprised by the behavior, so I was hoping somebody might be able to explain why this behavior was chosen. In particular, consider any zombie process, e.g. $ cat /proc/77078/status Name: test State: Z (zombie) Tgid: 77078 Ngid: 0 Pid: 77078 PPid: 77077

Yes, people use FOLL_FORCE ;)

Hi Linus et al., In 8ee74a91 "proc: try to remove use of FOLL_FORCE entirely", you removed punch through semantics of /proc//mem. We used these semantics as a hardening mechanism in the julia JIT. By opening /proc/self/mem and using these semantics, we could avoid needing RWX pages, or a dual

Re: Yes, people use FOLL_FORCE ;)

Hi Linus, > But it sounds like your JIT case actually uses it for writing - > but if you can write a small blurb about it, that would be nice. yes, we use it for writing. Happy to describe the scheme in more detail. > (b) it would probably be nice to limit FOLL_FORCE in general as much >

Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR

has been reached. On Mon, Dec 4, 2017 at 3:58 PM, Michael Kerrisk (man-pages) <mtk.manpa...@gmail.com> wrote: > Hello Keno > > On 12/03/2017 04:15 AM, Keno Fischer wrote: >> Resending as plain text (apologies for those receiving it twice, and >> those that got >>

[PATCH RFC] stat.2: Document that stat can fail with EINTR

Particularly on network file systems, a stat call may require submitting a message over the network and waiting interruptably for a reply. Signed-off-by: Keno Fischer <k...@juliacomputing.com> --- The catalyst for this patch was me experiencing EINTR errors when using the 9p file

Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR

not advocating for anything other than clarity of what kernel behavior user space may assume. On Sat, Dec 2, 2017 at 9:25 PM, Matthew Wilcox <wi...@infradead.org> wrote: > On Sat, Dec 02, 2017 at 07:23:59PM -0500, Keno Fischer wrote: >> The catalyst for this patch was me experienci

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> So we're talking about a workaround for broken software. The question > is how wide spread is it? For rr to work, it tries to replicate the process state *exactly*. That means: 1. The same instructions executed in the same order 2. The exact same register state at those instructions 3. The

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> So, to be useful, this interface needs to be called before an > application can run XGETBV or XSAVE for the first time and caches a > "bad" value. I think that means that it might not be feasible to use > outside of cases where you ptrace() something and inject things before > it has a chance

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

On Mon, Jun 18, 2018 at 12:16 PM, Dave Hansen wrote: > On 06/18/2018 08:13 AM, Keno Fischer wrote: >>>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update >>>> XCR0, redo the xsaves/restores, put XCR0 back and continue >>>> e

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update >> XCR0, redo the xsaves/restores, put XCR0 back and continue >> execution after the faulting instruction. > > I'm worried about the kernel pieces that go digging in the XSAVE data > getting confused more than the

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

Hi Dave, thank you for your thorough comments, replies inline: On Mon, Jun 18, 2018 at 8:47 AM, Dave Hansen wrote: > On 06/16/2018 05:33 PM, Keno Fischer wrote: >> For my use case, it would be sufficient to simply disallow >> any value of XCR0 with "holes" in it, >

[RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

From: Keno Fischer The rr (http://rr-project.org/) debugger provides user space record-and-replay functionality by carefully controlling the process environment in order to ensure completely deterministic execution of recorded traces. The recently added ARCH_SET_CPUID arch_prctl allows rr

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> Patch seems pointless if you can already control CPUID, which rr > supports. Just disable AVX512 in CPUID. All code using AVX should check > cpuid (or will fail anyways). Unfortunately, that is insufficient. Almost difference in CPU behavior between the replayer and the replayee. In particular,

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> Almost difference in CPU behavior > between the replayer and the replayee. Not sure what happened to this sentence. What I meant to say was: Almost any difference in CPU behavior between the replayer and the replayee will cause problems for the determinism of the trace. To elaborate on this,

Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR

has been reached. On Mon, Dec 4, 2017 at 3:58 PM, Michael Kerrisk (man-pages) wrote: > Hello Keno > > On 12/03/2017 04:15 AM, Keno Fischer wrote: >> Resending as plain text (apologies for those receiving it twice, and >> those that got >> an HTML copy, I'm used

[PATCH RFC] stat.2: Document that stat can fail with EINTR

Particularly on network file systems, a stat call may require submitting a message over the network and waiting interruptably for a reply. Signed-off-by: Keno Fischer --- The catalyst for this patch was me experiencing EINTR errors when using the 9p file system. In linux commit 9523feac, the 9p

Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR

not advocating for anything other than clarity of what kernel behavior user space may assume. On Sat, Dec 2, 2017 at 9:25 PM, Matthew Wilcox wrote: > On Sat, Dec 02, 2017 at 07:23:59PM -0500, Keno Fischer wrote: >> The catalyst for this patch was me experiencing EINTR errors when >&g

brk checks in PR_SET_MM code

Hi all, The code in prctl(PR_SET_MM, ...) performs a number of sanity checks, among them ``` /* * @brk should be after @end_data in traditional maps. */ if (prctl_map->start_brk <= prctl_map->end_data || prctl_map->brk <= prctl_map->end_data) goto out; ``` The original commit that

Re: [PATCH 0/3 v2] arm64/ptrace: allow to get all registers on syscall traps

Hi Andrei, > This series introduces the PTRACE_O_ARM64_RAW_REGS option. If it is set, > PTRACE_GETREGSET returns values of all registers, and PTRACE_SETREGSET > allows to change any of them. thanks for picking this up. I meant to work on this, but unfortunately ran out of time to be able to push

arm64: Register modification during syscall entry/exit stop

Continuing my theme of "weird things I encounter while trying to use ptrace on arm64", I ran into the effect of the following code in the syscall entry/exit reporting: ``` /* * A scratch register (ip(r12) on AArch32, x7 on AArch64) is * used to denote syscall entry/exit: */ regno =

Re: arm64: Register modification during syscall entry/exit stop

Hi Will, > Yes, we inherited this from ARM and I think strace relies on it. In > hindsight, it is a little odd, although x7 is a parameter register in the > PCS and so it won't be live on entry to a system call. I'm not familiar with the PCS acronym, but I assume you mean the calling convention?

ptrace: seccomp: Return value when the call was already invalid

I'm seeing the following while porting a ptracer from x86_64 to arm64 (cc'ing arm64 folks, but in this case x86_64 is the odd one out, I think other archs would be consistent with arm64). Consider userspace code like the following: ``` int ret = syscall(-10, 0); assert(ret == -ENOSYS); ```

Re: arm64: Register modification during syscall entry/exit stop

I got bitten by this again, so I decided to write up a simple example that shows the problem: https://gist.github.com/Keno/cde691b26e32373307fb7449ad305739 This runs the same child twice. First vanilla where it prints "Hello world". The second time, using a textbook ptrace example, to only print

[PATCH] arm64: ptrace: Fix PTRACE_SINGLESTEP into signal handler

be quite disruptive to the userspace program. This patch brings the arm64 behavior in line with the other major architectures by using the generic pseudo-single-step-stop, avoiding the problematic interaction with SIGTRAP masks. Fixes: 2c020ed8 ("arm64: Signal handling support") Signed-of

Re: arm64: Register modification during syscall entry/exit stop

is a syscall-stop, so the tracer's write to x7 was ignored and x7 retained the value it had in the signal handler, which broke the tracee. Keno On Sat, May 23, 2020 at 1:35 AM Keno Fischer wrote: > > I got bitten by this again, so I decided to write up a simple example > that shows th

mm: Behavior of process_vm_* with short local buffers

Hi everyone, I'm in the process of trying to port a debugging tool (http://rr-project.org/) from x86 to various other architectures. This tool relies on noting every change that was made to the memory of the process being debugged. As such, it has a battery of tests for corner cases of copyin/out

Re: arm64: Register modification during syscall entry/exit stop

On Mon, Jun 1, 2020 at 5:14 AM Dave Martin wrote: > Can you explain why userspace would write a changed value for x7 > but at the same time need that new to be thrown away? The discarding behavior is the primary reason things aren't completely broken at the moment. If it read the wrong x7 value

Re: arm64: Register modification during syscall entry/exit stop

On Mon, Jun 1, 2020 at 5:23 AM Dave Martin wrote: > > > Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the > > > syscall at the syscall enter stop, then modifying the regs at the > > > syscall exit stop? > > > > Yes, it can. The idea behind SYSEMU is to be able to save half

Re: arm64: Register modification during syscall entry/exit stop

> Keno -- are you planning to send out a patch? You previously spoke about > implementing this using PTRACE_SETOPTIONS. Yes, I'll have a patch for you. Though I've come to the conclusion that introducing a new regset is probably a better way to solve it. We can then also expose orig_x0 at the

Re: arm64: Register modification during syscall entry/exit stop

> Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the > syscall at the syscall enter stop, then modifying the regs at the > syscall exit stop? Yes, it can. The idea behind SYSEMU is to be able to save half the ptrace traps that would require, in theory making the ptracer a

PTRACE_SYSEMU behavior difference on arm64

The behavior of PTRACE_SYSEMU on arm64 appears to differ substantially from that of x86 and powerpc (the other two architectures on which this feature is implemented). In particular, after PTRACE_SYSEMU the syscall will always be skipped on x86 and powerpc, but executed on arm64 unless the

Re: PTRACE_SYSEMU behavior difference on arm64

On Fri, May 15, 2020 at 8:13 AM Will Deacon wrote: > But it also > means that nobody is using this on arm64, so we could also consider removing > it entirely. Did you spot this because you are trying to use it for > something or just by inspection/unit-testing? No, I was trying to port a tool

[PATCH] arm64: Fix PTRACE_SYSEMU semantics

method was used to re-start the syscall at the entry stop, rather than the method that was used to reach it. Fix that by recording the original flag before performing the ptrace stop, bringing the behavior in line with documentation and x86/powerpc. Signed-off-by: Keno Fischer --- arch/arm64/kernel

Re: ptrace: seccomp: Return value when the call was already invalid

> > Now, if we have a seccomp filter that simply does > > SECCOMP_RET_TRACE, and a ptracer that simply > > does PTRACE_CONT > > Ok, so this means that we're _skipping_ the system call, right? If the system call were positive this would result in the system call being executed. The notion of

[RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

From: Keno Fischer The rr (http://rr-project.org/) debugger provides user space record-and-replay functionality by carefully controlling the process environment in order to ensure completely deterministic execution of recorded traces. The recently added ARCH_SET_CPUID arch_prctl allows rr

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> Patch seems pointless if you can already control CPUID, which rr > supports. Just disable AVX512 in CPUID. All code using AVX should check > cpuid (or will fail anyways). Unfortunately, that is insufficient. Almost difference in CPU behavior between the replayer and the replayee. In particular,

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> Almost difference in CPU behavior > between the replayer and the replayee. Not sure what happened to this sentence. What I meant to say was: Almost any difference in CPU behavior between the replayer and the replayee will cause problems for the determinism of the trace. To elaborate on this,

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

Hi Dave, thank you for your thorough comments, replies inline: On Mon, Jun 18, 2018 at 8:47 AM, Dave Hansen wrote: > On 06/16/2018 05:33 PM, Keno Fischer wrote: >> For my use case, it would be sufficient to simply disallow >> any value of XCR0 with "holes" in it, >

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update >> XCR0, redo the xsaves/restores, put XCR0 back and continue >> execution after the faulting instruction. > > I'm worried about the kernel pieces that go digging in the XSAVE data > getting confused more than the

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

On Mon, Jun 18, 2018 at 12:16 PM, Dave Hansen wrote: > On 06/18/2018 08:13 AM, Keno Fischer wrote: >>>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update >>>> XCR0, redo the xsaves/restores, put XCR0 back and continue >>>> e

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> So we're talking about a workaround for broken software. The question > is how wide spread is it? For rr to work, it tries to replicate the process state *exactly*. That means: 1. The same instructions executed in the same order 2. The exact same register state at those instructions 3. The

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> So, to be useful, this interface needs to be called before an > application can run XGETBV or XSAVE for the first time and caches a > "bad" value. I think that means that it might not be feasible to use > outside of cases where you ptrace() something and inject things before > it has a chance

Use of r10 in powerpc syscall entry

Hi Anton, I was reading the powerpc syscall entry code and git points me at your commit 05b05f28 (powerpc: Relocatable system call no longer uses the LR) for one part that confused me, so I hope you don't mind a quick question. In particular, that commit removed the use of r10 to restore lr, but

[PATCH] mm: Respect FOLL_FORCE/FOLL_COW for thp

n gup.c in the original commit. The same pattern existed in follow_devmap_pmd, so I have changed that location as well. However, I do not have a test case that for that code path. Signed-off-by: Keno Fischer --- mm/huge_memory.c | 14 -- 1 file changed, 12 insertions(+), 2 deletion

Re: [PATCH] mm: Respect FOLL_FORCE/FOLL_COW for thp

>> @@ -783,7 +793,7 @@ struct page *follow_devmap_pmd(struct vm_area_struct >> *vma, unsigned long addr, >> >> assert_spin_locked(pmd_lockptr(mm, pmd)); >> >> - if (flags & FOLL_WRITE && !pmd_write(*pmd)) >> + if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags)) >>

[PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

NCE to make sure we notice if we ever do. Signed-off-by: Keno Fischer --- Changes since v1: * In follow_devmap_pmd, WARN_ONCE if FOLL_COW is encountered, rather than allowing it, since that situation should not happen. As suggested by Kirill A. Shutemov mm/huge_memory.c | 18 +++

Yes, people use FOLL_FORCE ;)

Hi Linus et al., In 8ee74a91 "proc: try to remove use of FOLL_FORCE entirely", you removed punch through semantics of /proc//mem. We used these semantics as a hardening mechanism in the julia JIT. By opening /proc/self/mem and using these semantics, we could avoid needing RWX pages, or a dual

Re: Yes, people use FOLL_FORCE ;)

Hi Linus, > But it sounds like your JIT case actually uses it for writing - > but if you can write a small blurb about it, that would be nice. yes, we use it for writing. Happy to describe the scheme in more detail. > (b) it would probably be nice to limit FOLL_FORCE in general as much >

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

Just as an FYI, the linker bug has been fixed in binutils. On Fri, Nov 11, 2016 at 5:07 PM, Richard Weinberger wrote: > On 11.11.2016 22:03, Keno Fischer wrote: >> Did you have CONFIG_INET set? I'm attaching my full .config. This is >> on vanilla Ubuntu 16.10. > > Yes, CONFI

Bug in fs/gs_base PTRACE_SETREGS on pre-4.7 kernels

Hi Andy (), this is more of a heads up than a bug report, since it turns out you already fixed this in 731e33e: x86/arch_prctl/64: Remove FSBASE/GSBASE < 4G optimization In any case, without that commit, trying to use PTRACE_SETREGS to set either fs_base, or gs_base to 0 when it was previously

[PATCH v2] gpio: Remove GPIO_DEVRES option

This option was added in 6a89a314ab107a12af08c71420c19a37a30fc2d3 to allow use of the devm_gpio_* functions without CONFIG_GPIOLIB. However, only a few months later in b69ac52449c658b7ac40034dc3c5f5f4a71a723d, CONFIG_GPIOLIB, was added as a dependency, defeating the original purpose of this

[PATCH] um: Fix compile failure due to current_text_address() definition

Fixes the following link error: ``` /usr/bin/ld: net/built-in.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC ``` This is the same definition used on some other architectures. Signed-off-by: Keno Fischer --- I am not sure

[PATCH] gpio: Guard devm_* functions behind CONFIG_GPIO_DEVRES not CONFIG_GPIOLIB

problems in modpost. Signed-off-by: Keno Fischer --- I encountered this while trying to build uml in an attempt to debug some kernel behavior I don't understand. To be as close to my actual kernel as possible, I used the same .config, which of course tried to build a bunch of drivers. Arguably I

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

> The problem is ready being solved in a generic way: > http://marc.info/?l=linux-kernel=147828481602561=2 > > Can you please give this patch a try? No dice. After backing out my patch and applying that one I get: /usr/bin/ld: error: net/built-in.o: requires unsupported dynamic reloc 11;

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

Yes On Thu, Nov 10, 2016 at 3:14 PM, Richard Weinberger wrote: > Keno, > > On 10.11.2016 21:10, Keno Fischer wrote: >>> The problem is ready being solved in a generic way: >>> http://marc.info/?l=linux-kernel=147828481602561=2 >>> >>> Can you pleas

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

On Thu, Nov 10, 2016 at 3:19 PM, Richard Weinberger wrote: > Can you please reply to Sebastian's patch series and explain him how you > trigger > that error? > I don't have a gcc broken by Debian on my machine right now. I'm not sure how to reply to his patch series directly since I'm not

Re: [PATCH] um: Fix compile failure due to current_text_address() definition

Did you have CONFIG_INET set? I'm attaching my full .config. This is on vanilla Ubuntu 16.10. I did see the same error when building with `CONFIG_STATIC_LINK=y`. Note that I also, separately, ran into a linker problem, though I believe it is unrelated to this patch (though perhaps is related to

How does the size field work in IOCTL numbers?

Hi folks, this is more of a general linux question, but since I noticed it while looking perf_events code, I'm ccing perf_events folks in case the answer is perf_events specific (hope that's ok). uapi/linux/perf_event.h has the following: #define PERF_EVENT_IOC_PERIOD _IOW('$', 4, __u64) #define

Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

11:34 AM, Oleg Nesterov wrote: > On 08/18, Keno Fischer wrote: >> >> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov wrote: >> > >> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after >> > PTRACE_INTERRUPT, you know that the tracee did

Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov wrote: > > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after > PTRACE_INTERRUPT, you know that the tracee did not report the "new" > SIGTTIN. It seems possible to remember whether or not we injected a stopping signal and if so

Why do Zombie process' /proc entries have uid 0?

This is mostly out of curiosity, but I was surprised by the behavior, so I was hoping somebody might be able to explain why this behavior was chosen. In particular, consider any zombie process, e.g. $ cat /proc/77078/status Name: test State: Z (zombie) Tgid: 77078 Ngid: 0 Pid: 77078 PPid: 77077

ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

Consider below test case (not all of it is necessary for reproducing the behavior in question, but I wanted to cover related cases as well to make sure they behave as expected). In this test case, the last group-stop (after PTRACE_INTERRUPT) is delivered with a WSTOPSIG(status) of SIGTTIN, which

Re: [PATCH 0/3 v2] arm64/ptrace: allow to get all registers on syscall traps

> > Could you describe the problem in more details? I wonder whether we have > the same thing in CRIU... > Sure, basically the issue is that orig_x0 gets recorded at the start of the syscall entry, but is not otherwise part of the ptrace state. It used to be primarily used for resetting the