ef="https://lkml.kernel.org/g/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com";>surprised
> me
> + href="https://lkml.kernel.org/r/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com";>surprised
> me
> with this requirement;
&g
On Fri, 20 Apr 2018 07:44:25 +0200
Dominik Brodowski wrote:
> For v4.17-rc1, the naming of syscall stubs changed. Update stack
> traces and similar instances in the documentation to avoid sources
> for confusion.
>
> Signed-off-by: Dominik Brodowski
Except that on x86 I don't see any __se_sys_
I just noticed that this was never applied.
Jon, can you take this?
-- Steve
On Mon, 27 Nov 2017 22:46:36 -0500
Steven Rostedt wrote:
> On Tue, 28 Nov 2017 12:26:13 +0900
> Masanari Iida wrote:
>
> > This patch corrects some spelling typo in ftrace-users.rst
> &g
On Tue, 17 Apr 2018 10:02:37 +0530
Ravi Bangoria wrote:
> From: Ravi Bangoria
>
> Make function names more meaningful by adding vma_ prefix
> to them.
Actually, I would have done this patch before the first one, since the
first one makes the functions global.
-- Steve
>
> Signed-off-by: Rav
acepoint.h
> @@ -4,7 +4,7 @@
> /*
> * Kernel Tracepoint API.
> *
> - * See Documentation/trace/tracepoints.txt.
> + * See Documentation/trace/tracepoints.rst.
> *
> * Copyright (C) 2008-2014 Mathieu Desnoyers
> *
Acked-by: Steven Rostedt (VMwar
On Wed, 23 May 2018 09:33:30 -0500
"Alex G." wrote:
> > Well I'll agree to disagree with Linus on this one. It's ugly as fsck
> > and allows for ambiguous statements in the code.
>
> You misspelled "fuck".
No, Jes is Danish. That's how they spell it.
-- Steve
--
To unsubscribe from this list
function
> in arch/s390/include/asm/processor.h. Without the option it is possible
> to trace __load_psw_mask which leads to kernel stack overflow.
Acked-by: Steven Rostedt (VMware)
-- Steve
>
> Signed-off-by: Martin Schwidefsky
> ---
> arch/s390/include/asm/processor.h | 4 +
the change, but how much are they going to "no longer
resemble regular init calls"?
-- Steve
>
> Cc: James Morris
> Cc: "Serge E. Hallyn"
> Cc: Abderrahmane Benbachir
> Cc: Steven Rostedt (VMware)
> Cc: linux-security-mod...@vger.kernel.org
> Signed-off-b
On Wed, 26 Sep 2018 11:35:21 -0700
Kees Cook wrote:
> On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt wrote:
> > On Mon, 24 Sep 2018 17:18:07 -0700
> > Kees Cook wrote:
> >
> >> This partially reverts commit 58eacfffc417 ("init, tracing: instrument
>
no longer resemble regular init calls.
> >
> > Cc: James Morris
> > Cc: "Serge E. Hallyn"
> > Cc: Abderrahmane Benbachir
> > Cc: Steven Rostedt (VMware)
> > Cc: linux-security-mod...@vger.kernel.org
> > Signed-off-by: Kees Cook
>
>
On Wed, 3 Oct 2018 14:14:28 +0200
Miguel Ojeda wrote:
> HI Dominique,
>
> On Wed, Oct 3, 2018 at 12:37 AM Dominique Martinet
> wrote:
> >
> > Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > > As I have read, -next is supposed to be a vision of what the merge
> > > window will look like after mer
On Wed, 3 Oct 2018 14:34:28 +0200
Miguel Ojeda wrote:
> When I sent the first email, I assumed that changes in -next were
> supposed to be clean -- my mistake, but please document somewhere how
> -next works! Specially that you are rerere'ing conflicts and
> re-resolving them every day.
Yes, a d
On Thu, 18 Oct 2018 17:19:32 -0700
"Paul E. McKenney" wrote:
> I figured that whoever calls preempt_enable_no_resched() is taking the
> responsibility for permitting preemption in the near future, and if they
> fail to do so, they will get called on it. Hard to hide from the latency
> tracer, af
On Thu, 18 Oct 2018 18:26:45 -0700
Joel Fernandes wrote:
> Yes, local_irq_restore is light weight, and does not check for reschedules.
>
> I was thinking of case where ksoftirqd is woken up, but does not run unless
> we set the NEED_RESCHED flag. But that should get set anyway since probably
> k
On Thu, 18 Oct 2018 19:25:29 -0700
Joel Fernandes wrote:
> On Thu, Oct 18, 2018 at 09:50:35PM -0400, Steven Rostedt wrote:
> > On Thu, 18 Oct 2018 18:26:45 -0700
> > Joel Fernandes wrote:
> >
> > > Yes, local_irq_restore is light weight, and does no
On Thu, 1 Nov 2018 19:35:50 +1100
Aleksa Sarai wrote:
> Historically, kretprobe has always produced unusable stack traces
> (kretprobe_trampoline is the only entry in most cases, because of the
> funky stack pointer overwriting). This has caused quite a few annoyances
> when using tracing to deb
On Fri, 2 Nov 2018 17:59:32 +1100
Aleksa Sarai wrote:
> As an aside, I just tested with the frame unwinder and it isn't thrown
> off-course by kretprobe_trampoline (though obviously the stack is still
> wrong). So I think we just need to hook into the ORC unwinder to get it
> to continue skipping
On Fri, 2 Nov 2018 10:43:26 -0500
Josh Poimboeuf wrote:
> > I'll hopefully have a prototype ready by plumbers.
>
> Why do we need multiple users? It would be a lot simpler if we could
> just enforce a single user per fgraphed/kretprobed function (and return
> -EBUSY if it's already being trac
On Sat, 3 Nov 2018 22:00:12 +0900
Masami Hiramatsu wrote:
> On Fri, 2 Nov 2018 12:13:07 -0400
> Steven Rostedt wrote:
>
> > Because that means if function graph tracer is active, then you can't
> > do a kretprobe, and vice versa. I'd really like to have it worki
On Sun, 4 Nov 2018 01:34:30 +0900
Masami Hiramatsu wrote:
>
> > I was thinking of a bitmask that represents the handlers, and use that
> > to map which handler gets called for which shadow entry for a
> > particular task.
>
> Hmm, I doubt that is too complicated and not scalable. I rather like
On Sat, 3 Nov 2018 13:30:21 -0400
Steven Rostedt wrote:
> What I was thinking was to store a count and the functions to be called:
>
>
> [original_return_address]
> [function_A]
> [function_B]
> [function_C]
> [ 3 ]
>
> Then the
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't work with ftrace-graph (and thus
> with the refactor both of you are discussing
On Mon, 23 May 2016 13:08:31 -0700
Brian Norris wrote:
Hi Brian,
> It took me browsing through the source code to determine that I was,
> indeed, using the wrong delimiter in my command lines. So I might as
> well document it for the next person.
>
> Signed-off-by: Brian Norris
> ---
> Docum
you want to take this patch?
Acked-by: Steven Rostedt
-- Steve
> Signed-off-by: Brian Norris
> ---
> v2: remove language about /sys/kernel/debug/tracing/set_event, to avoid
> implying it also takes a comma separated list
>
> Documentation/kernel-parameters.txt | 5 +++--
&
On Fri, 9 Sep 2016 16:17:14 +0200
Richard Weinberger wrote:
> > Signed-off-by: Michael Opdenacker
> > ---
> > Documentation/RCU/Design/Requirements/Requirements.html | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requ
On Tue, 19 Nov 2024 16:34:47 +0100
Valentin Schneider wrote:
> Context
> ===
>
> We've observed within Red Hat that isolated, NOHZ_FULL CPUs running a
> pure-userspace application get regularly interrupted by IPIs sent from
> housekeeping CPUs. Those IPIs are caused by activity on the housek
On Fri, 10 Jan 2025 16:21:35 -0800
Jacob Keller wrote:
> I personally find the date helpful as it can help place a commit without
> needing to take the extra time to do a lookup.
I've never found dates to be meaningful. I'm always more concerned about
when a commit was added to mainline. Thus th
On Sun, 12 Jan 2025 11:54:21 +0100
Geert Uytterhoeven wrote:
> FTR, while I do not support adding dates to Fixes-tags, I would just
> need to make a small modification to my fixes alias:
>
> $ git help fixes
> 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'
Hmm, I've just been manua
On Mon, 13 Jan 2025 14:38:00 +0200
Jani Nikula wrote:
> As a maintainer, I mostly use Acked-by for two slightly different cases:
>
> 1) I've seen the patch. I have no objections to it being merged, I
>approve of it. I haven't done a detailed review of it. Additionally,
>I may indicate wh
On Mon, 13 Jan 2025 09:22:27 -0500
"Theodore Ts'o" wrote:
> On Sun, Jan 12, 2025 at 10:47:02AM -0500, Neal Gompa wrote:
> >
> > A tag must not be dropped without the tag submitter's authorization.
> > Otherwise it doesn't matter what you write here, the submitter *will*
> > feel unwelcome.
> >
On Fri, 10 Jan 2025 12:20:09 +
yek...@red54.com wrote:
> The old Fixes tag style is at least 10 years old. It lacks date
> information, which can lead to misjudgment. So I added short author date
> to avoid this. This make it clear at a glance and reduce
> misunderstandings.
How can it lead t
myself for not catching that.
-- Steve
>
> >
> >> Reviewed-by: Greg Kroah-Hartman
> >> Acked-by: Miguel Ojeda
> >> Acked-by: Steven Rostedt
> >> Acked-by: Jonathan Corbet
> >> Signed-off-by: Shuah Khan
> >> ---
On Wed, 05 Mar 2025 11:54:28 +0200
Jani Nikula wrote:
> 2/3 actually means 7/10 for the TAB.
>
> Except two of the CoC committee members currently serve on the TAB, and
> will not vote. Assuming they will also not count for the total, 2/3
> means 6/8 = 75%.
>
> All of a sudden you actually need
On Thu, 17 Jul 2025 12:55:54 +0200
Peter Zijlstra wrote:
> On Thu, Jul 17, 2025 at 03:06:13PM +0700, Bagas Sanjaya wrote:
> > Atomic types, atomic bitops, and memory barriers docs are included in kernel
> > docs build since commit e40573a43d163a ("docs: put atomic*.txt and
> > memory-barriers.txt
On Thu, 24 Jul 2025 21:52:12 -0400
Sasha Levin wrote:
> We'll be hitting these issues all over the place if we try and draw a
> line... For example, with more advances autocompletion: where would you
> draw the line between completing variable names and writing an entire
> function based on a com
On Fri, 25 Jul 2025 13:53:57 -0400
Sasha Levin wrote:
> Create a single source of truth for AI instructions in
> Documentation/AI/main.md with symlinks for all major AI coding
> assistants:
> - CLAUDE.md (Claude Code)
> - .github/copilot-instructions.md (GitHub Copilot)
> - .cursorrules (Cursor)
On Fri, 25 Jul 2025 13:34:32 -0700
wrote:
> > This touches on explainability of AI. Perhaps the metadata would be
> > interesting for XAI research... not sure that's enough to be lugging
> > those tags in git history.
>
> Agree. The "who to blame" is "Author:". They signed DCO they are
> respo
On Thu, 24 Jul 2025 14:20:03 -0700
Kees Cook wrote:
> On Thu, Jul 24, 2025 at 09:12:30PM +, Dr. David Alan Gilbert wrote:
> > * Kees Cook (k...@kernel.org) wrote:
> > > [...]
> > > do for Coccinelle or other scripts. It's a bit buried in the Researcher
> > > Guidelines[1], but we have expli
On Fri, 25 Jul 2025 11:41:14 -0700
Jakub Kicinski wrote:
> On Fri, 25 Jul 2025 13:53:56 -0400 Sasha Levin wrote:
> > Co-developed-by: Claude claude-opus-4-20250514
> > ---
> > Documentation/power/opp.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I think we
On Wed, 30 Jul 2025 18:23:14 +0100
Lorenzo Stoakes wrote:
> > I don't think we should (or can) set a policy here for other
> > maintainers. Right now we allow tool-assisted contributions - flipping
> > this would mean we need to get an ack from at least a majority of the
> > MAINTAINERS folks.
On Wed, 30 Jul 2025 16:40:39 +
"Dr. David Alan Gilbert" wrote:
> * Steven Rostedt (rost...@goodmis.org) wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this t
On Wed, 30 Jul 2025 18:10:51 +0100
Lorenzo Stoakes wrote:
> > > I guess a statement in submitting-patches.rst would suffice, or should it
> > > be a separate standalone document?
> >
> > If it's separate I think it needs to have a link from submitting-patches.rst
> > to get people to read it.
On Wed, 30 Jul 2025 13:12:54 -0400
Sasha Levin wrote:
> >>
> >> Some sort of a "traffic light" system:
> >>
> >> 1. Green: the subsystem is happy to receive patches from any source.
> >>
> >> 2. Yellow: "If you're unfamiliar with the subsystem and using any
> >> tooling to generate your patche
On Wed, 30 Jul 2025 16:34:28 +0100
Lorenzo Stoakes wrote:
> > Which looked like someone else (now Cc'd on this thread) took it public,
> > and I wanted to see where that ended. I didn't want to start another
> > discussion when there's already two in progress.
>
> OK, but having a document lik
On Wed, 30 Jul 2025 11:31:35 +0200
Krzysztof Kozlowski wrote:
> I pop up there a lot, but there is no confusion. I am (and maybe we are
> all?) well aware that checkpatch hard limit is 100 as explained also here:
> https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0ed...@kernel.org/
>
>
On Mon, 28 Jul 2025 11:52:47 +0100
Lorenzo Stoakes wrote:
> On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> > > So to me:
> > >
> > > - We should establish an official kernel AI policy document.
> >
> > Steven Rostedt is working on
On Wed, 30 Jul 2025 13:46:47 -0400
Sasha Levin wrote:
> >My point here is that AI can now add questions that maintainers can't
> >answer. Is it really legal? Can the maintainer trust it? Yes, these too can
> >fall under the "technical reasons" but having a clear policy that states
> >that a maint
On Wed, 30 Jul 2025 12:36:25 -0400
Sasha Levin wrote:
> >
> >That sounds pretty much exactly as what I was stating in our meeting. That
> >is, it is OK to submit a patch written with AI but you must disclose it. It
> >is also the right of the Maintainer to refuse to take any patch that was
> >wri
On Wed, 30 Jul 2025 15:10:33 -0400
"Theodore Ts'o" wrote:
> Any tool can be a force multipler, either for good or for ill.
>
> For example, I suspect we have a much greater set of problems from
> $TOOL's other than Large Language Models. For example people who use
> "git grep strcpy" and send p
On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
Jiri Kosina wrote:
> Al made a very important point somewhere earlier in this thread.
>
> The most important (from the code quality POV) thing is -- is there a
> person that understands the patch enough to be able to answer questions
> (coming from some
On Tue, 5 Aug 2025 02:39:06 +0300
Laurent Pinchart wrote:
> > >
> > >"Be prepared to declare a confidence interval in every detail of a patch
> > >series, especially any AI generated pieces."
Honestly, I think we need to state that.
> >
> > Something along the lines of a Social Credit system
101 - 151 of 151 matches
Mail list logo
