rmation on how to ensure that syscalls with structure
> > arguments are extensible and add a section about naming conventions to
> > follow when adding revised versions of already existing syscalls.
> >
> > Co-Developed-by: Aleksa Sarai
> > Signed
port for it in 2016).
I agree with your overall point, but it should be noted that the vast
majority of Linux systems these days have protections against this (by
default) that use the pids cgroup controller.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
ork anymore -- at least not like it did in my original
patch. So I'm really not sure where to go from here.
I can send around another patchset to illustrate the problem if you like
(as well as show how the current unwinding code works).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
On 2018-11-09, Masami Hiramatsu wrote:
> On Thu, 8 Nov 2018 08:44:37 -0600
> Josh Poimboeuf wrote:
>
> > On Thu, Nov 08, 2018 at 07:04:48PM +1100, Aleksa Sarai wrote:
> > > On 2018-11-08, Aleksa Sarai wrote:
> > > > I will attach what I have at the
ed a quick impl
that I could test). I will fix this, thanks!
By is_kretprobe_handler_context() I imagine you are referring to
checking is_kretprobe(current_kprobe())?
> So, we should check we are in the kretprobe handler context if tsk == current,
> if not, we definately can lock the hash lock witho
On 2018-11-08, Aleksa Sarai wrote:
> I will attach what I have at the moment to hopefully explain what the
> issue I've found is (re-using the kretprobe architecture but with the
> shadow-stack idea).
Here is the patch I have at the moment (it works, except for the
question I hav
On 2018-11-06, Steven Rostedt wrote:
> On Sun, 4 Nov 2018 22:59:13 +1100
> Aleksa Sarai wrote:
>
> > The same issue is present in __save_stack_trace
> > (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> > as Steven said -- stacktraces wouldn&#x
On 2018-11-03, Aleksa Sarai wrote:
> This is actually a general bug in ftrace as well, because (for
> instance) while the unwinder calls into ftrace_graph_ret_addr() while
> walking up the stack this isn't used to correct regs->ip in
> perf_callchain_kernel(). I think this is
gs)
doesn't give the right result for some reason).
I will try to fix it up and attach it, but if you're already working on
a prototype the unifies all the users that works too. The patch I have
at the moment duplicates each of the key ftrace_graph_return_addr
invocations with a matching kretprobe_return_addr (though there's only
three of these).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
On 2018-11-02, Aleksa Sarai wrote:
> Unfortunately, I'm having a lot of trouble understanding how the current
> ftrace hooking works -- ORC has a couple of ftrace hooks that seem
> reasonable on the surface but I don't understand (for instance) how
> HAVE_FUNCTION_GRAPH_
On 2018-11-02, Aleksa Sarai wrote:
> For kretprobes I think it would be fairly easy to reconstruct what
> landed you into a kretprobe_trampoline by walking the set of
> kretprobe_instances (since all new ones are added to the head, you can
> get the real return address in-order).
>
On 2018-11-01, Steven Rostedt wrote:
> On Thu, 1 Nov 2018 19:35:50 +1100
> Aleksa Sarai wrote:
> > @@ -1834,6 +1853,11 @@ static int pre_handler_kretprobe(struct kprobe *p,
> > struct pt_regs *regs)
> > ri->rp = rp;
> &g
On 2018-11-02, Masami Hiramatsu wrote:
> On Fri, 2 Nov 2018 08:13:43 +1100
> Aleksa Sarai wrote:
>
> > On 2018-11-02, Masami Hiramatsu wrote:
> > > Please split the test case as an independent patch.
> >
> > Will do. Should the Documentation/ change also b
obe_trampoline. This is something I'm going
to look into some more (despite not having made progress on it last
time) since now it's something that actually needs to be fixed (and
as I mentioned in the other thread, show_stack() actually works on x86
in this context unlike the other stack_trace users).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
ce (switch
away from hlist_for_each_entry_safe)
* kprobe: make maximum stack size 127, which is the ftrace default
Aleksa Sarai (2):
kretprobe: produce sane stack traces
trace: remove kretprobed checks
Documentation/kprobes.txt | 6 +-
include/linux/kprobes.h
This is effectively a reversion of commit 76094a2cf46e ("ftrace:
distinguish kretprobe'd functions in trace logs"), as the checking of
kretprobe_trampoline *for tracing* is no longer necessary with the new
kretprobe stack trace changes.
Signed-off-by: Aleksa Sarai
--
entry stack trace when it is requested.
[1]: https://github.com/iovisor/bpftrace/issues/101
Cc: Brendan Gregg
Cc: Christian Brauner
Signed-off-by: Aleksa Sarai
---
Documentation/kprobes.txt | 6 +-
include/linux/kprobes.h | 27 +
kernel/e
entry stack trace when it is requested.
[1]: https://github.com/iovisor/bpftrace/issues/101
Cc: Brendan Gregg
Cc: Christian Brauner
Signed-off-by: Aleksa Sarai
---
Documentation/kprobes.txt | 6 +-
include/linux/kprobes.h | 15 +++
kernel/events/callch
This is effectively a reversion of commit 76094a2cf46e ("ftrace:
distinguish kretprobe'd functions in trace logs"), as the checking of
kretprobe_trampoline *for tracing* is no longer necessary with the new
kretprobe stack trace changes.
Signed-off-by: Aleksa Sarai
--
* kprobe: make maximum stack size 127, which is the ftrace default
(I forgot to Cc the BPF folks in v1, I've added them now.)
Aleksa Sarai (2):
kretprobe: produce sane stack traces
trace: remove kretprobed checks
Documentation/kprobes.txt |
uot;normal" OOM? Is there some peculiarity about
memcg OOM that I'm missing?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vge
On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:
If a user has a setup where they wait for notifications on changes to
pids.event, and then auto-adjust the cgroup limits based on the number of
failures you have a race condition between reading the pids.event file and
then setting
On Fri, Jun 24, 2016 at 01:00:48PM +1000, Aleksa Sarai wrote:
This allows users to dynamically adjust their limits based on how many
failed forks happened since they last reset their limits, otherwise they
would have to track (in a racy way) how many limit failures there were
since the last
set-we-log-failures-again semantics that Tejun said he liked.
Aleksa Sarai (2):
cgroup: pids: show number of failed forks since limit reset
docs: cgroup/pids: update documentation to include pids.events
Documentation/cgroup-v1/pids.txt | 18 ++
kernel/cgroup_pids.c
So that users know what the interface and meaning of the keyed values
are. In addition, mention that the only time that since=0 is when the
limit was changed.
Signed-off-by: Aleksa Sarai
---
Documentation/cgroup-v1/pids.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a
the limit was reset (which was the original semantics of
the patchset).
In addition, I clarified the licensing for this file.
Signed-off-by: Aleksa Sarai
---
kernel/cgroup_pids.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/kernel
26 matches
Mail list logo
