Received-SPF: pass (google.com: domain of linux-kernel+bounces-92854-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <4a6bf7f4-afa2-4c7f-b923-d67d48f41954@arm.com>
Date: Tue, 5 Mar 2024 18:52:54 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64/mm: Add memory barrier for mm_cid
To: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, mark.rutland@arm.com, peterz@infradead.org,
 mathieu.desnoyers@efficios.com, linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, nd@arm.com, stable@vger.kernel.org,
 Aaron Lu <aaron.lu@intel.com>
References: <20240305145335.2696125-1-yeoreum.yun@arm.com>
 <20240305171324.GA22616@willie-the-truck>
Content-Language: en-US
From: "levi.yun" <yeoreum.yun@arm.com>
In-Reply-To: <20240305171324.GA22616@willie-the-truck>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
NoDisclaimer: true
X-Microsoft-Antispam-Message-Info-Original:
 yH3QNpbuE3BG8HVYccAVQpltaoNrXuDapupIjUzROrSt9JuM2gI1YkXcQOSQ1qw+LsdhBkpI5mKm0XDRwqBf5QXiDHoJoGRuCdKHWT4ZpyFATTCCy3DX7blHh3RzENlqxduz/s7foAzuF8/zrdhGoo4BY97XjanDAPgRvCfbzZc0kaMHVBMrBtDmiM5JuzoQBg6lr5ncnFWgtZlbi8C/XrR8/lqlz6KxnlvwgeN9Jl74QjhQwx09fH/5yiRt1+vk30g3/+vyL49L2CeBvRKXZkjOUYA7j06xKo8P3/yyh9kBYjg+VuIZHIYmpolah3FVi+q7/PbEbj31LP7pvVguQQy6rAn+x0vJZjYRmhgM12YeXf8TuZGD5JwJD22f/GexbZo7E2lOlnZhdykyhnjAriQrZ/8TZ2rZHJUvdkDEf4WzpFFfYB366vaPHAiHZf5ofpP33D81WvDMeX9xJ6KiKLotvA53Ss4rUa65sOTnPVcqg5aTZct51iWbaDFR+PLfut4jUhTYlzL2yudJg4VJ5ThfrhHZVXQuNn3+m4m7eJzXa6IbyVRGBdxttgWZR1tposiZ672T3YqJJQEuSye0ujwereoVmhMJDGaL3m3YIZrAnkEa0ltWRqI+cDU7kgH773G5r9PW2LC7JGRKA+SAciFVtawnX3FcU6aTpiyS5DM=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR08MB4289.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5519
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B8F.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	7a38f005-03ef-4204-b5dc-08dc3d457809
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	s0UY0FPqlAP3CH02JYkztvx5z+G2z+oEtt7BgZrNboWt7fXNizDfDN+7Z7AQuZqjFa7XnGPt7LH0IjOzZ01UYVNN9VhrA0qVWMlzkXhQMQ+H9bSWTADMuWiHQFBpDHHnM8q+Zgtzrg2MI09ahR1NPDylNr0eB6YtZDx5jPw9BoXY/Z9OfXwygagnBs64e5UNwqAFD6sGIOHN4jM9+vJmaJezAE//wZbLKqeG5Yoh4NvhfjATnOZLLEeStuGuvM5RXwU3xo2OLNgfpY1r9CDYomwM0RtaT1TxqM9Ij0TrBxaZZO2GeSQhBLQeTY20LWSLIJDAbCPKNNpBDpWUDehA0ZUmiZkUHObYyus2vxrRNR37QxbLzsPQaaxaLWRGCrZ/UO0v5Nef5iK0YWpzlQySf2kHpNklMZeRVM+ZW0PxKT6as/J2czfU6bqoJVMbNibz7zf96O0pojtA8FUcIoW3LWdB+N2j32PZHgBYJ9v8TtLeT6V8QOSmoGDKpK9FiXEyGUuQtFX5QlksxP1uSTeJwHzZ+W3ghr3UT3SYompBURNYcKAbE/MyJUXOkC0V9GzCh9C/pqMvqAoDkIwtiZCR9Mr/Ey+tFceLerc1CUEcxc7+8vdv7FD2yZCCAH/TaAi+DlzUnKNi17Awe3jbE2p4sZejN9V3t4bLPmEzcHgte+rwK3yhz7YkDMil2FA7qHI8zsetuA/ujvGvUf4eCqcfI84YMwgE7ZFT+HRUM6HGs88c6dnpeactCrREDXoAwD2W
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 18:53:05.0988
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 64dc4c91-fae0-4ce6-f47a-08dc3d457db9
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B8F.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5859

Hi will.

> We already have a stronger barrier than smp_mb() (dsb ish) in __switch_to().
> Is that not sufficient?

IIUC, It's not sufficient with smp_mb() in __switch_to().

Because, it can be broken in sched_mm_cid_remote_clear()

CPU0  in __schedule()                       CPU1 in 
sched_mm_cid_remote_clear()
rq->curr = new_task;
<no barrier>
mm_get_cid remote_clear
    - check valid cid and use it.            Invalidate CID.
<barrier>
rq->curr (not observed).
                                                           unset the cid 
(<<BUG).


If change of rq->curr couldn't be observed in sched_mm_cid_remote_clear(),
It could unset actively used cid.
Note that __switch_to()'s smp_mb() is called AFTER switch_mm_cid().
That means before __switch_to(), there's possibility that
sched_mm_cid_remote_clear() couldn't observe new active task,
after it sets lazy_put on active cid used by new active task.