All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jules Maselbas" <jmaselbas@kalray.eu>
Cc: "Yann Sionneau" <ysionneau@kalray.eu>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Aneesh Kumar" <aneesh.kumar@linux.ibm.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	bpf@vger.kernel.org, "Christian Brauner" <brauner@kernel.org>,
	devicetree@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Eric Paris" <eparis@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Jason Baron" <jbaron@akamai.com>, "Jiri Olsa" <jolsa@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Kieran Bingham" <kbingham@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-audit@redhat.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-perf-users@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org,
	"Marc Zyngier" <maz@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Waiman Long" <longman@redhat.com>,
	"Will Deacon" <will@kernel.org>,
	"Alex Michon" <amichon@kalray.eu>,
	"Ashley Lesdalons" <alesdalons@kalray.eu>,
	"Benjamin Mugnier" <mugnier.benjamin@gmail.com>,
	"Clement Leger" <clement.leger@bootlin.com>,
	"Guillaume Missonnier" <gmissonnier@kalray.eu>,
	"Guillaume Thouvenin" <gthouvenin@kalray.eu>,
	"Jean-Christophe Pince" <jcpince@gmail.com>,
	"Jonathan Borne" <jborne@kalray.eu>,
	"Julian Vetter" <jvetter@kalray.eu>,
	"Julien Hascoet" <jhascoet@kalray.eu>,
	"Julien Villette" <jvillette@kalray.eu>,
	"Louis Morhet" <lmorhet@kalray.eu>,
	"Luc Michel" <lmichel@kalray.eu>,
	"Marc Poulhiès" <dkm@kataplop.net>,
	"Marius Gligor" <mgligor@kalray.eu>,
	"Samuel Jones" <sjones@kalray.eu>,
	"Thomas Costis" <tcostis@kalray.eu>,
	"Vincent Chardon" <vincent.chardon@elsys-design.com>
Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port
Date: Thu, 05 Jan 2023 13:05:32 +0100	[thread overview]
Message-ID: <5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com> (raw)
In-Reply-To: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu>

On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote:
> On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote:
>> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote:

>> I commented on the syscall patch directly, I think it's
>> important to stop using the deprecated syscalls as soon
>> as possible to avoid having dependencies in too many
>> libc binaries. Almost everything else can be changed
>> easily as you get closer to upstream inclusion.
>> 
>> I did not receive most of the other patches as I'm
>> not subscribed to all the mainline lists. For future 
>> submissions, can you add the linux-arch list to Cc for
>> all patches?
>
> We misused get_maintainers.pl, running it on each patch instead
> of using it on the whole series. next time every one will be in
> copy of every patch in the series and including linux-arch.

Be careful not to make the list too long though, there is
usually a limit of 1024 characters for the entire Cc list,
above this your mails may get dropped by the mailing lists.

>> Reading the rest of the series through lore.kernel.org,
>> most of the comments I have are for improvements that
>> you may find valuable rather than serious mistakes:
>> 
>> - the {copy_to,copy_from,clear}_user functions are
>>   well worth optimizing better than the byte-at-a-time
>>   version you have, even just a C version built around
>>   your __get_user/__put_user inline asm should help, and
>>   could be added to lib/usercopy.c.
>
> right, we are using memcpy for {copy_to,copy_from}_user_page
> which has a simple optimized version introduced in
> (kvx: Add some library functions).
> I wonder if it is possible to do the same for copy_*_user functions.

copy_from_user_page() is only about managing cache aliases,
not user access, and it's not used anywhere in the fast
path, so it's a bit different.

arch/arm/lib/copy_template.S has an example for how
you can share the same assembler implementation between
memcpy() and copy_from_user(), but it's not very
intuitive.

The tricky bit with copy_from_user() is the partial copy
that relies on copying the exact amount of data that can
be accessed including the last byte before the end of
the mapping, and returning the correct count of non-copied
bytes.

If you want a C version, you can probably use the
copy_from_kernel_nofault implementation mm/maccess.c
as a template, but have to add code for the correct
return value.

    Arnd

WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jules Maselbas" <jmaselbas@kalray.eu>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"Marc Poulhiès" <dkm@kataplop.net>,
	linux-doc@vger.kernel.org,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Marius Gligor" <mgligor@kalray.eu>,
	"Oleg Nesterov" <oleg@redhat.com>,
	linux-mm@kvack.org, "Louis Morhet" <lmorhet@kalray.eu>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Luc Michel" <lmichel@kalray.eu>,
	linux-riscv@lists.infradead.org,
	"Ashley Lesdalons" <alesdalons@kalray.eu>,
	"Will Deacon" <will@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	"Marc Zyngier" <maz@kernel.org>,
	"Thomas Costis" <tcostis@kalray.eu>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jonathan Borne" <jborne@kalray.eu>,
	"Aneesh Kumar" <aneesh.kumar@linux.ibm.com>,
	"Samuel Jones" <sjones@kalray.eu>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Jean-Christophe Pince" <jcpince@gmail.com>,
	"Waiman Long" <longman@redhat.com>,
	"Clement Leger" <clement.leger@bootlin.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	devicetree@vger.kernel.org, "Albert Ou" <aou@eecs.berkeley.edu>,
	"Kees Cook" <keescook@chromium.org>,
	linux-pm@vger.kernel.org, "Yann Sionneau" <ysionneau@kalray.eu>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Guillaume Thouvenin" <gthouvenin@kalray.eu>,
	"Julian Vetter" <jvetter@kalray.eu>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Julien Hascoet" <jhascoet@kalray.eu>,
	"Jason Baron" <jbaron@akamai.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	"Julien Villette" <jvillette@kalray.eu>,
	"Christian Brauner" <brauner@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Benjamin Mugnier" <mugnier.benjamin@gmail.com>,
	"Vincent Chardon" <vincent.chardon@elsys-design.com>,
	"Guillaume Missonnier" <gmissonnier@kalray.eu>,
	linux-kernel@vger.kernel.org, "Eric Paris" <eparis@redhat.com>,
	"Alex Michon" <amichon@kalray.eu>,
	linux-perf-users@vger.kernel.org, linux-audit@redhat.com,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Jiri Olsa" <jolsa@kernel.org>,
	"Kieran Bingham" <kbingham@kernel.org>,
	bpf@vger.kernel.org
Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port
Date: Thu, 05 Jan 2023 13:05:32 +0100	[thread overview]
Message-ID: <5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com> (raw)
In-Reply-To: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu>

On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote:
> On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote:
>> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote:

>> I commented on the syscall patch directly, I think it's
>> important to stop using the deprecated syscalls as soon
>> as possible to avoid having dependencies in too many
>> libc binaries. Almost everything else can be changed
>> easily as you get closer to upstream inclusion.
>> 
>> I did not receive most of the other patches as I'm
>> not subscribed to all the mainline lists. For future 
>> submissions, can you add the linux-arch list to Cc for
>> all patches?
>
> We misused get_maintainers.pl, running it on each patch instead
> of using it on the whole series. next time every one will be in
> copy of every patch in the series and including linux-arch.

Be careful not to make the list too long though, there is
usually a limit of 1024 characters for the entire Cc list,
above this your mails may get dropped by the mailing lists.

>> Reading the rest of the series through lore.kernel.org,
>> most of the comments I have are for improvements that
>> you may find valuable rather than serious mistakes:
>> 
>> - the {copy_to,copy_from,clear}_user functions are
>>   well worth optimizing better than the byte-at-a-time
>>   version you have, even just a C version built around
>>   your __get_user/__put_user inline asm should help, and
>>   could be added to lib/usercopy.c.
>
> right, we are using memcpy for {copy_to,copy_from}_user_page
> which has a simple optimized version introduced in
> (kvx: Add some library functions).
> I wonder if it is possible to do the same for copy_*_user functions.

copy_from_user_page() is only about managing cache aliases,
not user access, and it's not used anywhere in the fast
path, so it's a bit different.

arch/arm/lib/copy_template.S has an example for how
you can share the same assembler implementation between
memcpy() and copy_from_user(), but it's not very
intuitive.

The tricky bit with copy_from_user() is the partial copy
that relies on copying the exact amount of data that can
be accessed including the last byte before the end of
the mapping, and returning the correct count of non-copied
bytes.

If you want a C version, you can probably use the
copy_from_kernel_nofault implementation mm/maccess.c
as a template, but have to add code for the correct
return value.

    Arnd

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit


WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jules Maselbas" <jmaselbas@kalray.eu>
Cc: "Yann Sionneau" <ysionneau@kalray.eu>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Aneesh Kumar" <aneesh.kumar@linux.ibm.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	bpf@vger.kernel.org, "Christian Brauner" <brauner@kernel.org>,
	devicetree@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Eric Paris" <eparis@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Jason Baron" <jbaron@akamai.com>, "Jiri Olsa" <jolsa@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Kieran Bingham" <kbingham@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-audit@redhat.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-perf-users@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org,
	"Marc Zyngier" <maz@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Waiman Long" <longman@redhat.com>,
	"Will Deacon" <will@kernel.org>,
	"Alex Michon" <amichon@kalray.eu>,
	"Ashley Lesdalons" <alesdalons@kalray.eu>,
	"Benjamin Mugnier" <mugnier.benjamin@gmail.com>,
	"Clement Leger" <clement.leger@bootlin.com>,
	"Guillaume Missonnier" <gmissonnier@kalray.eu>,
	"Guillaume Thouvenin" <gthouvenin@kalray.eu>,
	"Jean-Christophe Pince" <jcpince@gmail.com>,
	"Jonathan Borne" <jborne@kalray.eu>,
	"Julian Vetter" <jvetter@kalray.eu>,
	"Julien Hascoet" <jhascoet@kalray.eu>,
	"Julien Villette" <jvillette@kalray.eu>,
	"Louis Morhet" <lmorhet@kalray.eu>,
	"Luc Michel" <lmichel@kalray.eu>,
	"Marc Poulhiès" <dkm@kataplop.net>,
	"Marius Gligor" <mgligor@kalray.eu>,
	"Samuel Jones" <sjones@kalray.eu>,
	"Thomas Costis" <tcostis@kalray.eu>,
	"Vincent Chardon" <vincent.chardon@elsys-design.com>
Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port
Date: Thu, 05 Jan 2023 13:05:32 +0100	[thread overview]
Message-ID: <5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com> (raw)
In-Reply-To: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu>

On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote:
> On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote:
>> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote:

>> I commented on the syscall patch directly, I think it's
>> important to stop using the deprecated syscalls as soon
>> as possible to avoid having dependencies in too many
>> libc binaries. Almost everything else can be changed
>> easily as you get closer to upstream inclusion.
>> 
>> I did not receive most of the other patches as I'm
>> not subscribed to all the mainline lists. For future 
>> submissions, can you add the linux-arch list to Cc for
>> all patches?
>
> We misused get_maintainers.pl, running it on each patch instead
> of using it on the whole series. next time every one will be in
> copy of every patch in the series and including linux-arch.

Be careful not to make the list too long though, there is
usually a limit of 1024 characters for the entire Cc list,
above this your mails may get dropped by the mailing lists.

>> Reading the rest of the series through lore.kernel.org,
>> most of the comments I have are for improvements that
>> you may find valuable rather than serious mistakes:
>> 
>> - the {copy_to,copy_from,clear}_user functions are
>>   well worth optimizing better than the byte-at-a-time
>>   version you have, even just a C version built around
>>   your __get_user/__put_user inline asm should help, and
>>   could be added to lib/usercopy.c.
>
> right, we are using memcpy for {copy_to,copy_from}_user_page
> which has a simple optimized version introduced in
> (kvx: Add some library functions).
> I wonder if it is possible to do the same for copy_*_user functions.

copy_from_user_page() is only about managing cache aliases,
not user access, and it's not used anywhere in the fast
path, so it's a bit different.

arch/arm/lib/copy_template.S has an example for how
you can share the same assembler implementation between
memcpy() and copy_from_user(), but it's not very
intuitive.

The tricky bit with copy_from_user() is the partial copy
that relies on copying the exact amount of data that can
be accessed including the last byte before the end of
the mapping, and returning the correct count of non-copied
bytes.

If you want a C version, you can probably use the
copy_from_kernel_nofault implementation mm/maccess.c
as a template, but have to add code for the correct
return value.

    Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-01-05 12:06 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03 16:43 [RFC PATCH 00/25] Upstream kvx Linux port Yann Sionneau
2023-01-03 16:43 ` Yann Sionneau
2023-01-03 16:43 ` Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 01/25] Documentation: kvx: Add basic documentation Yann Sionneau
2023-01-03 17:50   ` Jonathan Corbet
2023-01-09  9:51     ` [PATCH 0/8] kvx documentation improv (was: Re: [RFC PATCH 01/25] Documentation: kvx: Add basic documentation) Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 1/8] Documentation: kvx: Convert to reST Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 2/8] Documentation: kvx: Wrap diagrams in literal code block Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 3/8] Documentation: kvx: Fix lists Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 4/8] Documentation: kvx: kvx-iommu: Use reST syntax for subsections Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 5/8] Documentation: kvx: kvx-iommu: monospacize kvx iommu device tree path Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 6/8] Documentation: kvx: Promote title headings Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 7/8] Documentation: kvx: Use literal code block for command-line inputs Bagas Sanjaya
2023-01-09  9:51       ` [PATCH 8/8] Documentation: kvx: reword Bagas Sanjaya
2023-01-09 10:59       ` [PATCH 0/8] kvx documentation improv (was: Re: [RFC PATCH 01/25] Documentation: kvx: Add basic documentation) Jules Maselbas
2023-01-10  0:18       ` Randy Dunlap
2023-01-18  8:44     ` [RFC PATCH 01/25] Documentation: kvx: Add basic documentation Yann Sionneau
2023-01-05 18:38   ` kernel test robot
2023-01-18 15:09   ` Jeff Xie
2023-01-03 16:43 ` [RFC PATCH 02/25] kvx: Add ELF-related definitions Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-03 21:35   ` Eric W. Biederman
2023-01-03 21:35     ` Eric W. Biederman
2023-01-18  8:48     ` Yann Sionneau
2023-01-18  8:48       ` Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 03/25] kvx: Add build infrastructure Yann Sionneau
2023-01-03 17:29   ` Randy Dunlap
2023-01-05 13:12     ` Jules Maselbas
2023-01-06  0:43   ` kernel test robot
2023-01-03 16:43 ` [RFC PATCH 04/25] kvx: Add CPU definition headers Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 05/25] kvx: Add atomic/locking headers Yann Sionneau
2023-01-04  9:53   ` Mark Rutland
2023-01-06 14:11     ` Jules Maselbas
2023-01-10 13:24       ` Mark Rutland
2023-01-18 13:40         ` Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 06/25] kvx: Add other common headers Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 07/25] kvx: Add boot and setup routines Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 08/25] kvx: Add exception/interrupt handling Yann Sionneau
2023-01-09 20:54   ` Thomas Gleixner
2023-01-03 16:43 ` [RFC PATCH 09/25] kvx: irqchip: Add support for irq controllers Yann Sionneau
2023-01-03 21:28   ` Rob Herring
2023-01-03 16:43 ` [RFC PATCH 10/25] kvx: Add process management Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 11/25] kvx: Add memory management Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-04 11:37   ` Mike Rapoport
2023-01-04 11:37     ` Mike Rapoport
2023-01-03 16:43 ` [RFC PATCH 12/25] kvx: Add system call support Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-04 15:07   ` Arnd Bergmann
2023-01-04 15:07     ` Arnd Bergmann
2023-01-09 20:55   ` Thomas Gleixner
2023-01-09 20:55     ` Thomas Gleixner
2023-01-03 16:43 ` [RFC PATCH 13/25] kvx: Add signal handling support Yann Sionneau
2023-01-04 11:28   ` Mark Rutland
2023-01-03 16:43 ` [RFC PATCH 14/25] kvx: Add ELF relocations and module support Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 15/25] kvx: Add misc common routines Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 16/25] kvx: Add some library functions Yann Sionneau
2023-01-05 13:05   ` Clément Léger
2023-01-03 16:43 ` [RFC PATCH 17/25] kvx: Add multi-processor (SMP) support Yann Sionneau
2023-01-03 21:22   ` Rob Herring
2023-01-05  8:12   ` Clément Léger
2023-01-03 16:43 ` [RFC PATCH 18/25] kvx: Add kvx default config file Yann Sionneau
2023-01-04 13:02   ` Bagas Sanjaya
2023-01-06 14:52     ` Jules Maselbas
2023-01-03 16:43 ` [RFC PATCH 19/25] kvx: power: scall poweroff driver Yann Sionneau
2023-01-04 17:08   ` Sebastian Reichel
2023-01-03 16:43 ` [RFC PATCH 20/25] kvx: gdb: add kvx related gdb helpers Yann Sionneau
2023-01-04  7:41   ` Jan Kiszka
2023-01-05 15:19     ` Dmitrii Bundin
2023-01-03 16:43 ` [RFC PATCH 21/25] kvx: Add support for ftrace Yann Sionneau
2023-01-05 12:55   ` Clément Léger
2023-01-05 14:20     ` Steven Rostedt
2023-01-05 14:50   ` Mark Rutland
2023-01-03 16:43 ` [RFC PATCH 22/25] kvx: Add support for jump labels Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 23/25] kvx: Add debugging related support Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 24/25] kvx: Add support for CPU Perf Monitors Yann Sionneau
2023-01-03 16:43   ` Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 25/25] kvx: Add support for cpuinfo Yann Sionneau
2023-01-03 20:52 ` [RFC PATCH 00/25] Upstream kvx Linux port Rob Herring
2023-01-03 20:52   ` Rob Herring
2023-01-03 20:52   ` Rob Herring
2023-01-04 15:58 ` Arnd Bergmann
2023-01-04 15:58   ` Arnd Bergmann
2023-01-04 15:58   ` Arnd Bergmann
2023-01-05 10:40   ` Jules Maselbas
2023-01-05 10:40     ` Jules Maselbas
2023-01-05 10:40     ` Jules Maselbas
2023-01-05 12:05     ` Arnd Bergmann [this message]
2023-01-05 12:05       ` Arnd Bergmann
2023-01-05 12:05       ` Arnd Bergmann
2023-01-05 14:12       ` Steven Rostedt
2023-01-05 14:12         ` Steven Rostedt
2023-01-05 14:12         ` Steven Rostedt
2023-01-07  6:25 ` Jeff Xie
2023-01-07  6:25   ` Jeff Xie
2023-01-07  6:25   ` Jeff Xie
2023-01-09 13:21   ` Yann Sionneau
2023-01-09 13:21     ` Yann Sionneau
2023-01-09 13:21     ` Yann Sionneau
2023-01-09 15:11     ` Jeff Xie
2023-01-09 15:11       ` Jeff Xie
2023-01-09 15:11       ` Jeff Xie
2023-01-09 15:30       ` Yann Sionneau
2023-01-09 15:30         ` Yann Sionneau
2023-01-09 15:53         ` Jeff Xie
2023-01-09 15:53           ` Jeff Xie
2023-01-16  7:31           ` Jeff Xie
2023-01-16  7:31             ` Jeff Xie
2023-01-16  7:31             ` Jeff Xie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alesdalons@kalray.eu \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=amichon@kalray.eu \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=clement.leger@bootlin.com \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dkm@kataplop.net \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=gmissonnier@kalray.eu \
    --cc=gthouvenin@kalray.eu \
    --cc=jan.kiszka@siemens.com \
    --cc=jbaron@akamai.com \
    --cc=jborne@kalray.eu \
    --cc=jcpince@gmail.com \
    --cc=jhascoet@kalray.eu \
    --cc=jmaselbas@kalray.eu \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=jvetter@kalray.eu \
    --cc=jvillette@kalray.eu \
    --cc=kbingham@kernel.org \
    --cc=keescook@chromium.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lmichel@kalray.eu \
    --cc=lmorhet@kalray.eu \
    --cc=longman@redhat.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mgligor@kalray.eu \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mugnier.benjamin@gmail.com \
    --cc=namhyung@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=oleg@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paul@paul-moore.com \
    --cc=peterz@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sjones@kalray.eu \
    --cc=sre@kernel.org \
    --cc=tcostis@kalray.eu \
    --cc=tglx@linutronix.de \
    --cc=vincent.chardon@elsys-design.com \
    --cc=will@kernel.org \
    --cc=ysionneau@kalray.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.