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 E8961CDE020 for ; Thu, 26 Sep 2024 16:17:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D7656B0095; Thu, 26 Sep 2024 12:17:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 687716B0098; Thu, 26 Sep 2024 12:17:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54EE26B0099; Thu, 26 Sep 2024 12:17:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 37BED6B0095 for ; Thu, 26 Sep 2024 12:17:01 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 898A7120A29 for ; Thu, 26 Sep 2024 16:17:00 +0000 (UTC) X-FDA: 82607393400.05.52D81F8 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf04.hostedemail.com (Postfix) with ESMTP id 4ED274000B for ; Thu, 26 Sep 2024 16:16:58 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y5VvgXJu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727367401; a=rsa-sha256; cv=none; b=xVwSXQx0hMO1/gC41T60iarSf7jBUl58BPsrE3Muk7Zj70GR7RcNB3Hg2LhgF5DEP6/kl1 veg0itzeYREj85UAn+uynP8MeLgQuIVKoHmNjx/Sy22nsD7bGuucUznXGnkokoLT+BgmDu UbLBRJtPFIhPwvns3s+SJwOPSdGbDUs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y5VvgXJu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727367401; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LFxdlhcT77M863PodHeuS0sWay6s4jC4n9D3lU8otZM=; b=HXRMZIlo5vUjahMOVj6VDbVtbE3HYjoE+SksHb8sYj6Wq33e2qVTt+kG9TEO/HAFFuop24 COzOPRlFo58giRx7KLQjhLIAf+CSNMARm6BRZbHtyCV6kHDoMpDuemrus/4sbQKWImBTaR nUcFG6cr65AsQr8HcEVHLIHF3vMMuik= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-53661ac5ba1so1364032e87.2 for ; Thu, 26 Sep 2024 09:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727367417; x=1727972217; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=LFxdlhcT77M863PodHeuS0sWay6s4jC4n9D3lU8otZM=; b=Y5VvgXJuRISknlQFwTDIhMJwcZgwmy43zqhiLiFYGlWyE2EwCKwkfUEwxfxGRSzxMY ogYvTEnAJYSe7bO4+x8hA4NRxfh6Fk6Z50cw4pkWQF0OMCDiiEc4xqfbDxVa6V50eIM5 BKSPMmAA/4hvVlqZocThgqS4SPrNApWcB/NDF2MNeiQCDf96nIKbvcedDo3Er/3dhpcY OaZQsQ92nFtY9qL8l9T5ZEttsflVnz/wzUiOv8AM/jqgBiVOGZP6oHB6wBM1Q7qN6no7 sb++D/L7Uazp0yl27H3p+0bm3L8Pzbr0tp7NW95SNINPde7EQtlORjaSZbTcpgwE3abn wPUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727367417; x=1727972217; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LFxdlhcT77M863PodHeuS0sWay6s4jC4n9D3lU8otZM=; b=b2CIMX7syOLmGKn9VzDTgb6mmUpDRN5V2gTI3IY7lDqmesJUY1sHQLolEDBW79HTvl biTx6mst6/Q91G0LIJn2l1iqSA/ob26+n83ocbBgf++p4NuwGsKLm6h5CwoH2UjsntmM HGVWWzt9no8r1XLR1KjqFqn6ZJRiL0mjDihmNTd3J/ZsAjKosAjBQA8OVg9rH3smUl6A ITqt5VnNtoAmA/duu8FOwDUqFiI5KMbX/ErnUPluJMgNYpUQNNOnQtbKjVw/PyUpdc4B X+JLmLRQEMmeiglCe1RxZ56VfKicBfolzZv/2y7umuN3cEVOT4mJsfPbJx8LAd+Tj8mi EOyg== X-Forwarded-Encrypted: i=1; AJvYcCWjRJe9sX2cNJSXvcDz8pgtEj3uk8zZ+uxUNphQv/KRS65Bm7B3lV1HWS9P49v+ciYld/N/naXb7w==@kvack.org X-Gm-Message-State: AOJu0YyYRe/wKeaaBn7LKI72KeVa3w+l74w2sK5Ew7jsE97o1AB7Muuz dcF6FyVm14hXTQX0JmmoKqkSPWBa5vOnfu5W1PD8DTMSh3SunsbB X-Google-Smtp-Source: AGHT+IFJG+LUX4LyeIlwSMzb9cU5f4G7jXtWZ+RF3CQ2HkNVECY8KRkjL2vmR7o6zCLds5s8uWP3Yg== X-Received: by 2002:a05:6512:10c4:b0:52e:a699:2c8c with SMTP id 2adb3069b0e04-5389fc64385mr118423e87.45.1727367416312; Thu, 26 Sep 2024 09:16:56 -0700 (PDT) Received: from pc636 (host-90-233-216-205.mobileonline.telia.com. [90.233.216.205]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-538a0441777sm1359e87.274.2024.09.26.09.16.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2024 09:16:55 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 26 Sep 2024 18:16:53 +0200 To: Huang Adrian Cc: Andrew Morton , 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: References: <20240925134732.24431-1-ahuang12@lenovo.com> <20240925134706.2a0c2717a41a338d938581ff@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 9bnftjfj99tdr6r3xhpjhhk3mtpjcihm X-Rspamd-Queue-Id: 4ED274000B X-Rspamd-Server: rspam02 X-HE-Tag: 1727367418-193884 X-HE-Meta: U2FsdGVkX1/a3wsyS/ziLYLKhbuFui7PM+NKm0lC5wnr3mHGOsLpxNd/Nc589MyAa9dVgnVRmhOXg6DKtpfJOK/4tQph94cB/hQi5JuYHsCY4yLwGYpcXLjqywoBMNVCTYGrVj1f9bdTvaP2whhurCgzmDML0rDEosIlJSH/1KexX7PW9JSsjqEVZmSSZyVLo4c1tBv2cynbCZLcH/XpDr23hl9GQFaGBjotYyoXwGQSNOBkCGXjAu1+aioow/Dpne4hTY3HxLx8Q6b1KTsixO4KHAOOZV/+TWzvhpJrg1pBVoFLYfBZGS4WtvmY063lFIQ3PgCqz/KRLHOWw22Zra/lVlGUtchbCL0bGliWlkw9NDKw47Gwo7OveT/JoZKT53jR2ERUUIcTFEMn+b8rfyCK6kYp6Y/DRG0tNfishLtv6JxVY36dFn04jyP6LEVw0S+fW2CcpuQ0F7zarb3GYlP/7qH4vpgq5515TZQfqvToZmYEeziqI7ElmRw2kQNt+5FEhrQp5K0wozyMmoCvK/5ZNa9c2vdLKXZs2byiEoHIVvUrS8xs+lmQqdaKTdONetZ3QwDGhCx/Gs7a2YOkwUZKRaXoSgDKNxHifpAokCrfX3+djfI6KZ2tTnRLCmRHkz40Ct5ph/U5WA/DMidaI3gRhRijwOkQh5mdXAlGHyoPUPK7TgEijGeZ9YGxRz5R79EBLg5UaUOInGuBeF585gTzWkfRXJOScR/AEELASY3uS4ARg2DDQ4cMT+ttY0lW3tBq9cIl/e198rrrlMa5rQLkbBY1SfA6eeWVWT/J/FMScpbqAeVthSf77fVbtw7U5CusNHI/kShRS1KyYCDpvhq4DHLQ6lqk3+peM+Tf9FIIRrTTCW36jcfh/WMZsV0PlDjiIJ1ejct0xGLJg7VaQjTooWNt7uxZUwHWzrRkeb4TLvDLoZbkTr+Ivwasb7phQx+BS6IT3Ng35G6Zp0z BZD4T7UX u+8OudpC0/V0AYpir+ELbrTaMPxTLX3NjyBs5k8DqVGseBn3XtqkJ/hPwZNfAtEcqZmhzGCq+Yfqk/iUdQZWTHd25o6AzYo+l1w7WwDd1tnuChLjNpVtcdLQlLkAYHWznUjoSQ3TA5sPtRd5sM+IV2YQPfQwVYOUoL09XmCCg+l4Td/LiY39aotxjCCkBRraV0zKBxIN6VkJdTTUuCv6NnWfUN3eSfPeadcxoQwVOqhqqGkQxuAfucmqFPTW2j/KO3DPEqjB6VZ8RDpVtuFQSJT++IHPtXMzgeYRQCF+bZRtGuqTxKZgVFekeCI+ZjBuCOGVAx1B4hwnD3Ypxu4lvrKeGKULHzJNy5nhn+4D9USNMJPIXRTNDvnA4iUmgsE7jPEWuPNskb1lVUMBAWXvEwNkr8duMJNFzGaQLBmudqnmXENKtbf2WuXq5erujT6Ky51mBqVtkmxouNYfhpbwuU6Cs5o5SQHp4y3Jgr1s2hEpyIW8= 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: Hello, Adrian! > > > > > > 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. > > I did try it before. That didn't help. In this case, each iteration in > kasan_release_vmalloc_node() only needs to clear one pte. However, > vn->purge_list is the long list under the heavy load: 128 cores (128 > vmap_nodes) execute kasan_release_vmalloc_node() to clear the corresponding > pte(s) while other cores allocate vmalloc space (populate the page table > of the vmalloc address) and populate vmalloc shadow page table. Lots of > cores contend init_mm.page_table_lock. > > For a lame fix, adding cond_resched() in the loop of > kasan_release_vmalloc_node() is an option. > > Any suggestions and comments about this issue? > One question. Do you think that running a KASAN kernel and stressing the vmalloc allocator is an issue here? It is a debug kernel, which implies it is slow. Also, please note, the synthetic stress test is not a real workload, it is tighten in a hard loop to stress it as much as we can. Can you trigger such splat using a real workload. For example running stress-ng --fork XXX or any different workload? Thanks! -- Uladzislau Rezki