From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0E52CCF9F4 for ; Wed, 25 Sep 2024 20:47:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E5226B0085; Wed, 25 Sep 2024 16:47:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 195856B0088; Wed, 25 Sep 2024 16:47:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 035906B00AD; Wed, 25 Sep 2024 16:47:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D6C236B0085 for ; Wed, 25 Sep 2024 16:47:10 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7F41A160603 for ; Wed, 25 Sep 2024 20:47:10 +0000 (UTC) X-FDA: 82604445420.30.BBE7296 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf27.hostedemail.com (Postfix) with ESMTP id C6B724000E for ; Wed, 25 Sep 2024 20:47:08 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=F845A0rO; dmarc=none; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727297131; a=rsa-sha256; cv=none; b=obc3+cdbMKADOoANmZeqduzDpHyIWRiYhNqag1C047vI8Nq4lQ9XPIsXEKkcpnF3zELlAa 56puxXH2J8XWzm2CZDIlgvgeAmoeq1oJyAgxW4Tl/dZ+i9XZQBoM7T/jrR46Prb0iAOUEw NaBmkuC5LX1T/IvHIiPKYtcXjp4VLm4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=F845A0rO; dmarc=none; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727297131; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8vwZsLsJqnGGsWmw9eRd6+825SvNtUPHR6+TnWRg3t8=; b=zco3F5VEPu9SXmvoUxnbRF36BrLbV+8G3HOs+DcT2f9/x7lSMVw/oIbzIFO7uoNheHrELT nPfoV04bbrrzD1n3yHPSUybOv9ETbDFUmx0i2nKznHOS/FmrpJjuTxWKr07Y/ALZ22ajiR kyzff0W+lCL3O3RLONQtTPhKlHwE6IY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8289FA44823; Wed, 25 Sep 2024 20:46:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD996C4CEC3; Wed, 25 Sep 2024 20:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1727297227; bh=WD+jMqvgC8MnHU3Lhm2a0gl+Uu82ABZjkjg4bL/0m3I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=F845A0rOvyN/U53R+uSQ/BHfMMCq1WP5EVLnSVqkUXzMRjWB5Bkc9opYk7w9HiIvc GPNNW505gW7LX88jmEOe72y9/UmSrNotcBN0dD/8ypblMvFZfyNdIkCBYAmunc5j3F PIuEAAi7CjqVZZOprZZmcohl0+k5QJsn2D35gb9I= Date: Wed, 25 Sep 2024 13:47:06 -0700 From: Andrew Morton To: Adrian Huang Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Uladzislau Rezki , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Adrian Huang Subject: Re: [PATCH 1/1] kasan, vmalloc: avoid lock contention when depopulating vmalloc Message-Id: <20240925134706.2a0c2717a41a338d938581ff@linux-foundation.org> In-Reply-To: <20240925134732.24431-1-ahuang12@lenovo.com> References: <20240925134732.24431-1-ahuang12@lenovo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C6B724000E X-Stat-Signature: zz8ef4kkb9n1fk7hgacci8b7tqm64dsg X-Rspam-User: X-HE-Tag: 1727297228-98338 X-HE-Meta: U2FsdGVkX1+rJHSjoS3ctNIY25COhOk5TyS6VuadSCDPhmkF5bxsnLaPbMzH7vL7lXDod3cmqTJbxPpkf+XYCvyO91JpNt6uyoZ3w51qzZTPdjk0vW+HkTplN7ok5DbJ8rF1thtUgMn/ipxIOg+WcnyTxeTHP/++rz5Jzd+aTH8B6js5rILrFfDkBH3SfnOLpIZU5Un51tuUeeAIFmWFotV03eifxBnjOcpB9WJ9/V/Q9mTGoGb/nx9fOZ5i9TrodezrLgGvkBMJA6tUYb4aiQKajnooIyezR68GIC79W6b3emKKd+MuCFC3pYBWNQEbEjaEskxrLw6rItmt+nTb8jm3OdCFwxllqzfXydBmFdGAltkrl9FZvnOSuUQzKZTyFsj4emaVheBNJW3T1UGsIve6jaLBu1PhOFvMVK94myHyE3YTu8VfRaqVUHcXYzvCVFydEXIzWV4H3Nk/vmgRYFYSq/vxEI6pE/P2fYPe1LU+aE4kDTq+ipUD2I15OB6lsn5JgleQAXVlp+SgITqhUb6DIGs/aRczxrIPWZSN2BThurMuzJ0zbZnQ4dXkBoP6xMdAudfXKrYpwaLxCeVy3XfhWu87lJujPMzlmvPRUJy55G9BCDjVDvtmtiEc7XgzWnSbo3ayYq56Ll3Czty52Kcgabwlw676xJsxGHhsKRjewlefBFXTbzTe/9YofJXF1hKPSx/nlg1o1H9/iosnflKvibXBcQkC5SDLbfQxHTcDCo/9o1wJluYpclgmZUe55Aki30kpmjekIUbzpgJtIGInzKOZ4350LDkFaIa8+TSY7FWBjC6Bsvts8jt7ZgLEiYOq+gYoLUHhMbu3cNr1Q4wixZ2bVjEKXjzrfnYN8Ddv8c8sSbHh0pxx8cEPwt1FFQnX0xY0qFHlHM68JBcJVAMcIXYfVO4rcTSJZpDkL2IQovfFW+k5CNGOgzDURIespbaKgjvXzSI+UPqDQ3W s8ftlWqh k/W213koTQfACSWnsUXl9ItY/xlnbbVxlt/rF7wYZEpLZtfc4DPHy0aSFv6MGB97DllwWSFJJ7QaX89jouzhBHxl0b7cQvZDfcW/ltWLMP7F17nxeIPHbUxQ83xbc7UZ5IJJyuRORL+J966kiRpA97jnnlHzNc6FtOhjQmDInL3F0gSwbA/J1MKYFnlyMoZK/t48aAslYiUAytj+BQnv+p4pL0FFnY7BP/vjuoeuBASbkOac3C9YnaCjL2Xlt41xbBd05x/y3PLZLTKTwz8mbCb2ruRIrCoAFVx9322FiGN9QDAH1pTqW8JK/C5f3yopvE6szYZ0NFgIECMdZei3B7gAXdPv9x3ZGXzkQq+PDHZUHOS6eAqfWE2AGpxMLlz/1gQSBXbG87ttXq1skYzq+bCp++FnkuAvq5mrv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 25 Sep 2024 21:47:32 +0800 Adrian Huang wrote: > > ... > > From: Adrian Huang > After re-visiting code path about setting the kasan ptep (pte pointer), > it's unlikely that a kasan ptep is set and cleared simultaneously by > different CPUs. So, use ptep_get_and_clear() to get rid of the spinlock > operation. "unlikely" isn't particularly comforting. We'd prefer to never corrupt pte's! I'm suspecting we need a more thorough solution here. btw, for a lame fix, did you try moving the spin_lock() into kasan_release_vmalloc(), around the apply_to_existing_page_range() call? That would at least reduce locking frequency a lot. Some mitigation might be needed to avoid excessive hold times.