The migration harness will be expanded to deal with more commands
from the test, moving these checks into functions helps keep things
managable.
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 20 +++-
1 file changed, 15 insertions(+), 5 delet
On 19/03/2024 08.58, Nicholas Piggin wrote:
The migration harness will be expanded to deal with more commands
from the test, moving these checks into functions helps keep things
managable.
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 20 +++-
1 file changed, 15
The migration harness will be expanded to deal with more commands
from the test, moving these checks into functions helps keep things
managable.
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/scri
On Thu, Aug 31, 2023 at 12:13:39PM -0700 Kees Cook wrote:
> Currently the Kconfig fragments in kernel/configs and arch/*/configs
> that aren't used internally aren't discoverable through "make help",
> which consists of hard-coded lists of config fragments. Instead, li
> that aren't used internally aren't discoverable through "make help",
> > > which consists of hard-coded lists of config fragments. Instead, list
> > > all the fragment targets that have a "# Help: " comment prefix so the
> > > targets c
Kees Cook writes:
> Currently the Kconfig fragments in kernel/configs and arch/*/configs
> that aren't used internally aren't discoverable through "make help",
> which consists of hard-coded lists of config fragments. Instead, list
> all the fragment targets that
On Fri, Sep 01, 2023 at 04:58:37PM +0900, Masahiro Yamada wrote:
> On Fri, Sep 1, 2023 at 4:13 AM Kees Cook wrote:
> >
> > Currently the Kconfig fragments in kernel/configs and arch/*/configs
> > that aren't used internally aren't discoverable through "make hel
On Fri, Sep 1, 2023 at 4:13 AM Kees Cook wrote:
>
> Currently the Kconfig fragments in kernel/configs and arch/*/configs
> that aren't used internally aren't discoverable through "make help",
> which consists of hard-coded lists of config fragments. Instead, list
Currently the Kconfig fragments in kernel/configs and arch/*/configs
that aren't used internally aren't discoverable through "make help",
which consists of hard-coded lists of config fragments. Instead, list
all the fragment targets that have a "# Help: " commen
t line
> > of config fragments.
>
> Good call. Yes, this looks excellent; thank you! Do you want to send a
> formal patch? Please consider it:
>
> Reviewed-by: Kees Cook
>
> --
> Kees Cook
You can send it with
Co-developed-by: Masahiro Yamada
You can add help messag
On Tue, Aug 29, 2023 at 11:57:19PM +0900, Masahiro Yamada wrote:
> The attached patch will work too.
>
> I dropped the "in the first line" restriction
> because SPDX might be placed in the first line
> of config fragments.
Good call. Yes, this looks excellent; thank you! Do you want to send a
for
es Cook wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> This is my series to show *.config targets in the "help" target so
> > > >> these
> > > >> various topics can be more easily discoverd.
On Tue, Aug 29, 2023 at 3:55 PM Nicolas Schier wrote:
>
> On Mon 28 Aug 2023 16:17:07 GMT, Michael Ellerman wrote:
> > Masahiro Yamada writes:
> > > On Sat, Aug 26, 2023 at 4:55 AM Kees Cook wrote:
> > >>
> > >> Hi,
> > >>
> > >
On Mon 28 Aug 2023 16:17:07 GMT, Michael Ellerman wrote:
> Masahiro Yamada writes:
> > On Sat, Aug 26, 2023 at 4:55 AM Kees Cook wrote:
> >>
> >> Hi,
> >>
> >> This is my series to show *.config targets in the "help" target so these
> &g
Masahiro Yamada writes:
> On Sat, Aug 26, 2023 at 4:55 AM Kees Cook wrote:
>>
>> Hi,
>>
>> This is my series to show *.config targets in the "help" target so these
>> various topics can be more easily discoverd.
>>
>> v2:
>> - split .
On Sat, Aug 26, 2023 at 4:55 AM Kees Cook wrote:
>
> Hi,
>
> This is my series to show *.config targets in the "help" target so these
> various topics can be more easily discoverd.
>
> v2:
> - split .fragment from .config to hide "internal" fragments
Doing a "make help" would show only hard-coded Kconfig targets and
depended on the archhelp target to include ".config" targets. There was
nothing showing global kernel/configs/ targets. Solve this by walking
the wildcard list and include them in the output, using the first
Hi,
This is my series to show *.config targets in the "help" target so these
various topics can be more easily discoverd.
v2:
- split .fragment from .config to hide "internal" fragments
- fix various typos
- avoid duplicate entries
v1: https://lore.kernel.org/all/202308
On 8/25/23 11:20, Kees Cook wrote:
> On Thu, Aug 24, 2023 at 05:04:02PM -0700, Randy Dunlap wrote:
>> Hi Kees,
>>
>> On 8/24/23 15:36, Kees Cook wrote:
>>> Doing a "make help" would show only hard-coded Kconfig targets and
>>> depended on the ar
On Fri, Aug 25, 2023 at 04:11:58PM +1000, Michael Ellerman wrote:
> Kees Cook writes:
> > Doing a "make help" would show only hard-coded Kconfig targets and
> > depended on the archhelp target to include ".config" targets. There was
> > nothing showing g
On Fri, Aug 25, 2023 at 07:44:06AM +0200, Nicolas Schier wrote:
> On Thu, Aug 24, 2023 at 03:36:10PM -0700, Kees Cook wrote:
> > Doing a "make help" would show only hard-coded Kconfig targets and
> > depended on the archhelp target to include ".config" targets. T
On Fri, Aug 25, 2023 at 04:56:54AM +, Christophe Leroy wrote:
> Le 25/08/2023 à 00:36, Kees Cook a écrit :
> > +# Base hardware support for 86xx
>
> s/86xx/85xx
> [...]
Thanks for the typo fixes! I'll get these all fixed up. :)
--
Kees Cook
On Thu, Aug 24, 2023 at 05:04:02PM -0700, Randy Dunlap wrote:
> Hi Kees,
>
> On 8/24/23 15:36, Kees Cook wrote:
> > Doing a "make help" would show only hard-coded Kconfig targets and
> > depended on the archhelp target to include ".config" targets. Th
On Thu, Aug 24, 2023 at 03:36:10PM -0700, Kees Cook wrote:
> Doing a "make help" would show only hard-coded Kconfig targets and
> depended on the archhelp target to include ".config" targets. There was
> nothing showing global kernel/configs/ targets. Solve this by wa
Kees Cook writes:
> Doing a "make help" would show only hard-coded Kconfig targets and
> depended on the archhelp target to include ".config" targets. There was
> nothing showing global kernel/configs/ targets. Solve this by walking
> the wildcard list and inclu
Le 25/08/2023 à 00:36, Kees Cook a écrit :
> Doing a "make help" would show only hard-coded Kconfig targets and
> depended on the archhelp target to include ".config" targets. There was
> nothing showing global kernel/configs/ targets. Solve this by walking
> th
Hi Kees,
On 8/24/23 15:36, Kees Cook wrote:
> Doing a "make help" would show only hard-coded Kconfig targets and
> depended on the archhelp target to include ".config" targets. There was
> nothing showing global kernel/configs/ targets. Solve this by walking
> th
Doing a "make help" would show only hard-coded Kconfig targets and
depended on the archhelp target to include ".config" targets. There was
nothing showing global kernel/configs/ targets. Solve this by walking
the wildcard list and include them in the output, using the first
On Sat, Jun 24, 2023 at 10:06:23AM +, Christophe Leroy wrote:
> Hello Josh and Peter,
>
> As mentionned in the cover letter of my series "powerpc/objtool: uaccess
> validation for PPC32 (v3)" [1], a few switch table lookup fail, and it
> would help if you had id
Hello Josh and Peter,
As mentionned in the cover letter of my series "powerpc/objtool: uaccess
validation for PPC32 (v3)" [1], a few switch table lookup fail, and it
would help if you had ideas on how to handle them.
First one is as follows. First switch is properly detected, sec
Currently none of the generated defconfigs appear in the help output,
because the help text discovers defconfigs by looking for actual files
named "*_defconfig".
Collect the generated defconfig names into a variable and then print
those out in archhelp.
Output loo
On 2023/3/25 14:08, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Y
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Reviewed-by: Max Filippov
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-of
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Acked-by: Geert Uytterhoeven
Reviewed-by: Zi Yan
Signed-of
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-of
On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-of
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Reviewed-by: Max Filippov
Acked-by: Kirill A. Shutemov
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/sparc/Kc
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/sh/mm/Kc
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/powerpc/Kc
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/nios2/Kc
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
Acked-by: Geert Uy
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/arm64/Kc
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/arm/Kc
On Thu, Mar 23, 2023 at 10:23 AM Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
>
On Thu, Mar 23, 2023 at 11:21:45AM +0200, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option do
On Thu, Mar 23, 2023 at 2:24 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
&
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/xtensa/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/sparc/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/sh/mm/Kconfig | 17 +
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/nios2/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/m68k/Kconfig.cpu | 16 +---
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm64/Kconfig | 25 ---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/Kconfig | 16 +---
1 file
ozlabs.org
>> Subject: Re: [PATCH v2 00/10] crypto: Kconfig - simplify menus and help
>> text
>>
>> Le 29/08/2022 à 02:05, Elliott, Robert (Servers) a écrit :
>>>
>>>> -Original Message-
>>>> From: Christophe Leroy
>>>> Se
> -Original Message-
> From: Christophe Leroy
> Sent: Monday, August 29, 2022 3:53 AM
> To: Elliott, Robert (Servers) ; Nayna
> ; Andrew Donnellan
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 00/10] crypto: Kconfig - simplify menus and help
> t
ozlabs.org
>> Subject: Re: [PATCH v2 00/10] crypto: Kconfig - simplify menus and help
>> text
>>
>> Hi,
>>
>> Le 27/08/2022 à 22:06, Elliott, Robert (Servers) a écrit :
>>> (adding Christophe, per
>>> bba496656a73fc1 ("powerpc/32: Fix boot f
> -Original Message-
> From: Christophe Leroy
> Sent: Sunday, August 28, 2022 2:33 AM
> To: Elliott, Robert (Servers) ; Nayna
> ; Andrew Donnellan
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 00/10] crypto: Kconfig - simplify menus and help
> tex
Hi,
Le 27/08/2022 à 22:06, Elliott, Robert (Servers) a écrit :
> (adding Christophe, per
> bba496656a73fc1 ("powerpc/32: Fix boot failure with GCC latent entropy
> plugin")
>
>
> Adding libmpc-devel gets all the architectures building except powerpc.
>
> (I also installed gcc-plugins-devel to
Le 19/11/2021 à 12:31, Nicholas Piggin a écrit :
The printk layer at the moment does not seem to have a good way to force
flush printk messages that are created in NMI context, except in the
panic path.
NMI-context printk messages normally get to the console with irq_work,
but that won't
The printk layer at the moment does not seem to have a good way to force
flush printk messages that are created in NMI context, except in the
panic path.
NMI-context printk messages normally get to the console with irq_work,
but that won't help if the CPU is stuck with irqs disabled, as c
ntext printk messages normally get to the console with irq_work,
>> but that won't help if the CPU is stuck with irqs disabled, as can be
>> the case for hard lockup watchdog messages.
>>
>> The watchdog currently flushes the printk buffers after detecting a
>> lockup
Hi,
> The printk layer at the moment does not seem to have a good way to force
> flush printk messages that are created in NMI context, except in the
> panic path.
>
> NMI-context printk messages normally get to the console with irq_work,
> but that won't help if the
The printk layer at the moment does not seem to have a good way to force
flush printk messages that are created in NMI context, except in the
panic path.
NMI-context printk messages normally get to the console with irq_work,
but that won't help if the CPU is stuck with irqs disabled, as c
'And' the given page address with PAGE_MASK to help GCC.
With the patch:
0024 <__flush_dcache_icache>:
24: 54 63 00 26 rlwinm r3,r3,0,0,19
28: 39 40 00 40 li r10,64
2c: 7c 69 1b 78 mr r9,r3
3
'And' the given page address with PAGE_MASK to help GCC.
With the patch:
0024 <__flush_dcache_icache>:
24: 54 63 00 26 rlwinm r3,r3,0,0,19
28: 39 40 00 40 li r10,64
2c: 7c 69 1b 78 mr r9,r3
3
On Tue, Jan 05, 2021 at 08:20:51AM -0800, Andy Lutomirski wrote:
> > On Jan 5, 2021, at 5:26 AM, Will Deacon wrote:
> > Sorry for the slow reply, I was socially distanced from my keyboard.
> >
> >> On Mon, Dec 28, 2020 at 04:36:11PM -0800, Andy Lutomirski wrote:
> >> On Mon, Dec 28, 2020 at 4:11
On Tue, Jan 05, 2021 at 08:20:51AM -0800, Andy Lutomirski wrote:
> > Interestingly, the architecture recently added a control bit to remove
> > this synchronisation from exception return, so if we set that then we'd
> > have a problem with SYNC_CORE and adding an ISB would be necessary
> On Jan 5, 2021, at 5:26 AM, Will Deacon wrote:
>
> Hi Andy,
>
> Sorry for the slow reply, I was socially distanced from my keyboard.
>
>> On Mon, Dec 28, 2020 at 04:36:11PM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin wrote:
+static inline void me
Hi Andy,
Sorry for the slow reply, I was socially distanced from my keyboard.
On Mon, Dec 28, 2020 at 04:36:11PM -0800, Andy Lutomirski wrote:
> On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin wrote:
> > > +static inline void membarrier_sync_core_before_usermode(void)
> > > +{
> > > + /*
> >
From: Andy Lutomirski
> Sent: 29 December 2020 00:36
...
> I mean that the mapping from the name "sync_core" to its semantics is
> x86 only. The string "sync_core" appears in the kernel only in
> arch/x86, membarrier code, membarrier docs, and a single SGI driver
> that is x86-only. Sure, the ide
Excerpts from Russell King - ARM Linux admin's message of December 30, 2020
8:58 pm:
> On Wed, Dec 30, 2020 at 10:00:28AM +, Russell King - ARM Linux admin
> wrote:
>> On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
>> > Excerpts from Russell King - ARM Linux admin's message
On Wed, Dec 30, 2020 at 10:00:28AM +, Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
> > Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
> > 8:44 pm:
> > > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas P
On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
> Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
> 8:44 pm:
> > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
> >> I think it should certainly be documented in terms of what guarantees
Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
8:44 pm:
> On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
>> I think it should certainly be documented in terms of what guarantees
>> it provides to application, _not_ the kinds of instructions it may or
On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
> I think it should certainly be documented in terms of what guarantees
> it provides to application, _not_ the kinds of instructions it may or
> may not induce the core to execute. And if existing API can't be
> re-documented sanely,
Excerpts from Andy Lutomirski's message of December 29, 2020 10:36 am:
> On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin wrote:
>>
>> Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am:
>> > The old sync_core_before_usermode() comments said that a non-icache-syncing
>> > return-t
Excerpts from Andy Lutomirski's message of December 29, 2020 10:56 am:
> On Mon, Dec 28, 2020 at 4:36 PM Nicholas Piggin wrote:
>>
>> Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am:
>> > On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
>> > wrote:
>> >>
>> >> - On Dec
On Mon, Dec 28, 2020 at 4:36 PM Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am:
> > On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> > wrote:
> >>
> >> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
> >>
> >> > On Mon
Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am:
> On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
>> > wrote:
>
On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am:
> > The old sync_core_before_usermode() comments said that a non-icache-syncing
> > return-to-usermode instruction is x86-specific and that all other
> > architectures a
On Mon, Dec 28, 2020 at 1:09 PM Mathieu Desnoyers
wrote:
>
> - On Dec 27, 2020, at 4:36 PM, Andy Lutomirski l...@kernel.org wrote:
>
> [...]
>
> >> You seem to have noticed odd cases on arm64 where this guarantee does not
> >> match reality. Where exactly can we find this in the code, and whic
athieu Desnoyers
> Cc: x...@kernel.org
> Cc: sta...@vger.kernel.org
> Fixes: 70216e18e519 ("membarrier: Provide core serializing command,
> *_SYNC_CORE")
> Signed-off-by: Andy Lutomirski
> ---
>
> Hi arm64 and powerpc people-
>
> This is part of a series h
- On Dec 28, 2020, at 4:06 PM, Andy Lutomirski l...@kernel.org wrote:
> On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
>> > wro
- On Dec 27, 2020, at 4:36 PM, Andy Lutomirski l...@kernel.org wrote:
[...]
>> You seem to have noticed odd cases on arm64 where this guarantee does not
>> match reality. Where exactly can we find this in the code, and which part
>> of the architecture manual can you point us to which support
On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
wrote:
>
> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>
> > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
> > wrote:
> >>
> >> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> >> > Afte
- On Dec 28, 2020, at 3:24 PM, Russell King, ARM Linux
li...@armlinux.org.uk wrote:
> On Mon, Dec 28, 2020 at 11:44:33AM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
>> wrote:
>> >
>> > On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wr
- On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
> On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
> wrote:
>>
>> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
>> > After chatting with rmk about this (but without claiming that any of
>> > this
On Mon, Dec 28, 2020 at 11:44:33AM -0800, Andy Lutomirski wrote:
> On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> > > After chatting with rmk about this (but without claiming that any of
> > > this is hi
On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
wrote:
>
> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> > After chatting with rmk about this (but without claiming that any of
> > this is his opinion), based on the manpage, I think membarrier()
> > currently doesn't
On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> After chatting with rmk about this (but without claiming that any of
> this is his opinion), based on the manpage, I think membarrier()
> currently doesn't really claim to be synchronizing caches? It just
> serializes cores. So arguably i
thout claiming that any of
> this is his opinion), based on the manpage, I think membarrier()
> currently doesn't really claim to be synchronizing caches? It just
> serializes cores. So arguably if userspace wants to use membarrier()
> to synchronize code changes, userspace shou
On Mon, Dec 28, 2020 at 9:23 AM Russell King - ARM Linux admin
wrote:
>
> On Mon, Dec 28, 2020 at 09:14:23AM -0800, Andy Lutomirski wrote:
> > On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote:
> >
1 - 100 of 375 matches
Mail list logo
