2019-01-24 07:02:06

by Shijith Thotton

[permalink] [raw]
Subject: Re: [Qestion] Softlockup when send IPI to other CPUs

Hi Catalin,

On 01/23/2019 11:45 PM, Catalin Marinas wrote:
> On Tue, Jan 22, 2019 at 05:44:02AM +0000, Will Deacon wrote:
>> On Mon, Jan 21, 2019 at 02:21:28PM +0000, Catalin Marinas wrote:
>>> arm64: Do not issue IPIs for user executable ptes
>>>
>>> From: Catalin Marinas <[email protected]>
>>>
>>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
>>> for kernel mappings") was aimed at fixing the I-cache invalidation for
>>> kernel mappings. However, it inadvertently caused all cache maintenance
>>> for user mappings via set_pte_at() -> __sync_icache_dcache() to call
>>> kick_all_cpus_sync().
>>>
>>> Fixes: 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
>>> Cc: <[email protected]> # 4.19.x-
>>> Signed-off-by: Catalin Marinas <[email protected]>
>>> ---
>>> arch/arm64/include/asm/cacheflush.h | 2 +-
>>> arch/arm64/kernel/probes/uprobes.c | 2 +-
>>> arch/arm64/mm/flush.c | 14 ++++++++++----
>>> 3 files changed, 12 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
>>> index 19844211a4e6..18e92d9dacd4 100644
>>> --- a/arch/arm64/include/asm/cacheflush.h
>>> +++ b/arch/arm64/include/asm/cacheflush.h
>>> @@ -80,7 +80,7 @@ extern void __clean_dcache_area_poc(void *addr, size_t len);
>>> extern void __clean_dcache_area_pop(void *addr, size_t len);
>>> extern void __clean_dcache_area_pou(void *addr, size_t len);
>>> extern long __flush_cache_user_range(unsigned long start, unsigned long end);
>>> -extern void sync_icache_aliases(void *kaddr, unsigned long len);
>>> +extern void sync_icache_aliases(void *kaddr, unsigned long len, bool sync);
>>
>> I'd much prefer just adding something like sync_user_icache_aliases(), which
>> would avoid the IPI, since bool arguments tend to make the callsites
>> unreadable imo.
>
> I wonder whether we need the IPI for uprobes and ptrace. I would say we
> can avoid it for ptrace since normally the debugged thread should be
> stopped. I think it's different for uprobes but changing the text of a
> live thread doesn't come with many guarantees anyway. So I'm tempted to
> simply change sync_icache_aliases() to not issue an IPI at all, in which
> case we wouldn't even need the bool argument; it's only used for user
> addresses. So the new diff would be (the text is the same):
>
> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
> index 30695a868107..5c9073bace83 100644
> --- a/arch/arm64/mm/flush.c
> +++ b/arch/arm64/mm/flush.c
> @@ -33,7 +33,11 @@ void sync_icache_aliases(void *kaddr, unsigned long len)
> __clean_dcache_area_pou(kaddr, len);
> __flush_icache_all();
> } else {
> - flush_icache_range(addr, addr + len);
> + /*
> + * Don't issue kick_all_cpus_sync() after I-cache invalidation
> + * for user mappings.
> + */
> + __flush_icache_range(addr, addr + len);
> }
> }

We also faced similar issue with LTP test migrate_pages03 in past and this patch
fixes the issue.

http://lists.infradead.org/pipermail/linux-arm-kernel/2019-January/623574.html

Thanks,
Shijith


2019-01-24 16:39:03

by Catalin Marinas

[permalink] [raw]
Subject: Re: [Qestion] Softlockup when send IPI to other CPUs

Hi Shijith,

On Thu, Jan 24, 2019 at 07:00:42AM +0000, Shijith Thotton wrote:
> On 01/23/2019 11:45 PM, Catalin Marinas wrote:
> > diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
> > index 30695a868107..5c9073bace83 100644
> > --- a/arch/arm64/mm/flush.c
> > +++ b/arch/arm64/mm/flush.c
> > @@ -33,7 +33,11 @@ void sync_icache_aliases(void *kaddr, unsigned long len)
> > __clean_dcache_area_pou(kaddr, len);
> > __flush_icache_all();
> > } else {
> > - flush_icache_range(addr, addr + len);
> > + /*
> > + * Don't issue kick_all_cpus_sync() after I-cache invalidation
> > + * for user mappings.
> > + */
> > + __flush_icache_range(addr, addr + len);
> > }
> > }
>
> We also faced similar issue with LTP test migrate_pages03 in past and this patch
> fixes the issue.
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-January/623574.html

Thanks for confirming. I presume I can add your tested-by.

--
Catalin