Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Shijith Thotton <sthotton@marvell.com>
To:     Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>
CC:     chenwandun <chenwandun@huawei.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "Wangkefeng (Kevin)" <wangkefeng.wang@huawei.com>,
        "anshuman.khandual@arm.com" <anshuman.khandual@arm.com>,
        Ganapatrao Kulkarni <gkulkarni@marvell.com>,
        Jayachandran Chandrasekharan Nair <jnair@marvell.com>
Subject: Re: [Qestion] Softlockup when send IPI to other CPUs
Thread-Topic: [Qestion] Softlockup when send IPI to other CPUs
Thread-Index: AQHUsFLrrYWN2sDbSEeIkTghgif1Ug==
Date:   Thu, 24 Jan 2019 07:00:42 +0000
Message-ID: <DM6PR18MB24607427B3B2BEAD80A75780D99A0@DM6PR18MB2460.namprd18.prod.outlook.com>
References: <95C141B25E7AB14BA042DCCC556C0E6501620A47@dggeml529-mbx.china.huawei.com>
 <20190119235825.GG26876@brain-police>
 <20190121142127.GD29504@arrakis.emea.arm.com>
 <20190122054400.GB6445@brain-police>
 <20190123181530.GA234790@arrakis.emea.arm.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: marvell.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 195d9aa4-fa8f-4086-2638-08d681c9a80d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 07:00:42.6722
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR18MB2537
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-24_03:,,
 signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501
 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1810050000 definitions=main-1901240049
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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