Re: [PATCH v13 01/35] x86/cpufeatures,opcode,msr: Add the WRMSRNS instruction support
On Tue, Jan 02, 2024 at 10:06:27PM +, Li, Xin3 wrote: > Do I need to send an updated patch? > Or just leave it to the maintainer who is going to take care of it? While waiting, please take a look at this: https://kernel.org/doc/html/latest/process/submitting-patches.html#don-t-get-discouraged-or-impatient Might want to read the whole doc too. But to answer your question: you wait a few weeks and collect all comments and review feedback that you've received and incorporate them into the patchset. Then, after the time passes you send a new revision and explain in the 0th message what has changed. Ok? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: RESEND: Re: [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide
On 12/25/2023 7:25 PM, Ruipeng Qi wrote: <+How a kernel client driver can register region with minidump <+ <+ <+Client driver can use ``qcom_minidump_region_register`` API's to register <+and ``qcom_minidump_region_unregister`` to unregister their region from <+minidump driver. <+ <+Client needs to fill their region by filling ``qcom_minidump_region`` <+structure object which consists of the region name, region's virtual <+and physical address and its size. Hi, Mukesh, wish you a good holiday :) Hope you had the same..:-) I have the following idea, please help me to assess whether this can be implemented or not. As we all know, most of the kernel objects are allocated by the slab sub-system.I wonder if we can dump all memory keeped by the slab sub-system? If so, we got most of the kernel objects which will be helpful to fix problems when we run with system issues. How can we do this? From the description above, I think we should register one region for each slab, for each slab will have some pages, and the memory between each slab is non-continuous. As we all know, there are millions of slabs in the system, so if we dump slabs in this way, it will introduce a heavy overhead. I am not very familiar with qualcomm minidump, maybe my thought is wrong. Looking forward to your reply! In the current state and in simple terms, Qualcomm Minidump can not do this, Minidump is more of a consumer driver so, what ever gets registered with it, it can dump. Qualcomm Minidump serves bigger purpose to dump content in any kind of crash whether it is kernel or non-kernel like NOC errors/XPUs etc and both kernel/non-kernel entity can register to it, so we gets dump in any kind of system crash. One more thing, kernel part of minidump, we are calling it APSS Minidump has limitation of no of entries so it will be difficult to dump non-continuous regions after a certain number of registration ~200. However, we do have a solution in downstream kernel for it like to create a big CMA buffer and register this buffer with Minidump so that whatever gets dumped in that buffer gets captured during crash and fill up this buffer and create elf during panic. I think, similar thing you are also doing with your OS-minidump. I have just glanced into your implementation of OS-minidump, it more of relying on basic concept of RAM content preserved across boot and later reading it through procfs but this basic stuff is common to pstore(ram) as well and pstore has file system support why don't you make your driver as one of pstore record and that way Qualcomm minidump also gets benefited where entire OS-minidump record gets registered with Qualcomm minidump and we get this on panic and you get this via pstorefs. -Mukesh Best Regards Ruipeng
Re: [PATCH v2] ring-buffer/Documentation: Add documentation on buffer_percent file
Steven Rostedt writes:
> From: "Steven Rostedt (Google)"
>
> When the buffer_percent file was added to the kernel, the documentation
> should have been updated to document what that file does.
>
> Fixes: 03329f9939781 ("tracing: Add tracefs file buffer_percentage")
> Signed-off-by: Steven Rostedt (Google)
> ---
> Changes since v1:
> https://lore.kernel.org/all/20231226123525.71a6d...@gandalf.local.home/
>
> - Fixed some grammar issues.
>
> Documentation/trace/ftrace.rst | 15 +++
> 1 file changed, 15 insertions(+)
Are you planning on shipping this one upstream, or would you like me to
pick it up?
Thanks,
jon
Re: [PATCH v2] ring-buffer/Documentation: Add documentation on buffer_percent file
On Wed, 03 Jan 2024 14:15:30 -0700
Jonathan Corbet wrote:
> Steven Rostedt writes:
>
> > From: "Steven Rostedt (Google)"
> >
> > When the buffer_percent file was added to the kernel, the documentation
> > should have been updated to document what that file does.
> >
> > Fixes: 03329f9939781 ("tracing: Add tracefs file buffer_percentage")
> > Signed-off-by: Steven Rostedt (Google)
> > ---
> > Changes since v1:
> > https://lore.kernel.org/all/20231226123525.71a6d...@gandalf.local.home/
> >
> > - Fixed some grammar issues.
> >
> > Documentation/trace/ftrace.rst | 15 +++
> > 1 file changed, 15 insertions(+)
>
> Are you planning on shipping this one upstream, or would you like me to
> pick it up?
I was hoping you can take it, but please take v3.
https://lore.kernel.org/all/20231229122402.537eb...@gandalf.local.home/
Thanks!
-- Steve
Re: [PATCH] Docs: remove mentions of fdformat from util-linux
Thomas Weißschuh writes:
> Since util-linux commit 13b26e3c36d1
> ("fdformat: remove command from default build")
> the fdformat tool is not built anymore by default.
> As a result it is not packaged anymore by distributions and therefore
> not usable by users.
>
> Instead mention the "mount" command as more likely to be present
> alternative.
>
> Also drop the reference to fdformat from the list of features of new
> versions of util-linux.
>
> Signed-off-by: Thomas Weißschuh
> ---
> Documentation/process/changes.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Amusingly, my F39 system still has fdformat...but this change makes
sense, applied, thanks.
jon
Re: [PATCH v1 1/2] docs, kprobes: Update email address of Masami Hiramatsu
Tiezhu Yang writes: > According to the latest authorship and Signed-off-by: > > Masami Hiramatsu (Google) > > Masami Hiramatsu is working at Google, so the current email @redhat.com > is out of date, it is better to use the email @kernel.org. > > Signed-off-by: Tiezhu Yang > --- > Documentation/trace/kprobes.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst > index f825970a1495..968ae080accd 100644 > --- a/Documentation/trace/kprobes.rst > +++ b/Documentation/trace/kprobes.rst > @@ -4,7 +4,7 @@ Kernel Probes (Kprobes) > > :Author: Jim Keniston > :Author: Prasanna S Panchamukhi > -:Author: Masami Hiramatsu > +:Author: Masami Hiramatsu Masami, is this change OK with you? Thanks, jon
Re: [PATCH v2] ring-buffer/Documentation: Add documentation on buffer_percent file
Steven Rostedt writes:
> On Wed, 03 Jan 2024 14:15:30 -0700
> Jonathan Corbet wrote:
>
>> Steven Rostedt writes:
>>
>> > From: "Steven Rostedt (Google)"
>> >
>> > When the buffer_percent file was added to the kernel, the documentation
>> > should have been updated to document what that file does.
>> >
>> > Fixes: 03329f9939781 ("tracing: Add tracefs file buffer_percentage")
>> > Signed-off-by: Steven Rostedt (Google)
>> > ---
>> > Changes since v1:
>> > https://lore.kernel.org/all/20231226123525.71a6d...@gandalf.local.home/
>> >
>> > - Fixed some grammar issues.
>> >
>> > Documentation/trace/ftrace.rst | 15 +++
>> > 1 file changed, 15 insertions(+)
>>
>> Are you planning on shipping this one upstream, or would you like me to
>> pick it up?
>
> I was hoping you can take it, but please take v3.
>
> https://lore.kernel.org/all/20231229122402.537eb...@gandalf.local.home/
Yep, will do.
Thanks,
jon
Re: [PATCH v1 1/2] docs, kprobes: Update email address of Masami Hiramatsu
On Wed, 03 Jan 2024 14:36:47 -0700 Jonathan Corbet wrote: > Tiezhu Yang writes: > > > According to the latest authorship and Signed-off-by: > > > > Masami Hiramatsu (Google) > > > > Masami Hiramatsu is working at Google, so the current email @redhat.com > > is out of date, it is better to use the email @kernel.org. > > > > Signed-off-by: Tiezhu Yang > > --- > > Documentation/trace/kprobes.rst | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/trace/kprobes.rst > > b/Documentation/trace/kprobes.rst > > index f825970a1495..968ae080accd 100644 > > --- a/Documentation/trace/kprobes.rst > > +++ b/Documentation/trace/kprobes.rst > > @@ -4,7 +4,7 @@ Kernel Probes (Kprobes) > > > > :Author: Jim Keniston > > :Author: Prasanna S Panchamukhi > > -:Author: Masami Hiramatsu > > +:Author: Masami Hiramatsu > > Masami, is this change OK with you? I would like to know the policy. Should we update the author's mail address in the document (source) everytime? Anyway, I'm OK for this update. Acked-by: Masami Hiramatsu (Google) Thanks, > > Thanks, > > jon -- Masami Hiramatsu (Google)
Re: [PATCH v1 2/2] docs, kprobes: Add loongarch as supported architecture
On Tue, 19 Dec 2023 14:23:30 +0800
Tiezhu Yang wrote:
> After the following three changes at the beginning of the year:
>
> commit 6d4cc40fb5f5 ("LoongArch: Add kprobes support")
> commit 3f5536860086 ("LoongArch: Add kretprobes support")
> commit 09e679c28a4d ("LoongArch: Add kprobes on ftrace support")
>
> it is appropriate to add loongarch as supported architecture in
> kprobes documentation.
>
> Signed-off-by: Tiezhu Yang
Acked-by: Masami Hiramatsu (Google)
Thanks,
> ---
> Documentation/trace/kprobes.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst
> index 968ae080accd..e1636e579c9c 100644
> --- a/Documentation/trace/kprobes.rst
> +++ b/Documentation/trace/kprobes.rst
> @@ -321,6 +321,7 @@ architectures:
> - mips
> - s390
> - parisc
> +- loongarch
>
> Configuring Kprobes
> ===
> --
> 2.42.0
>
--
Masami Hiramatsu (Google)
