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 E1159C3DA63 for ; Tue, 23 Jul 2024 10:50:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69CD06B0083; Tue, 23 Jul 2024 06:50:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64C476B0088; Tue, 23 Jul 2024 06:50:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 512E86B0089; Tue, 23 Jul 2024 06:50:44 -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 32EE76B0083 for ; Tue, 23 Jul 2024 06:50:44 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A04AA121E46 for ; Tue, 23 Jul 2024 10:50:43 +0000 (UTC) X-FDA: 82370699166.17.FF1E54F Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf27.hostedemail.com (Postfix) with ESMTP id AF45E40017 for ; Tue, 23 Jul 2024 10:50:41 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YZMroL1m; spf=pass (imf27.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721731780; 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=0dRtw8ZAunWvu++rHHyoAYfF4HuDJvNfZWM1BGrhWE4=; b=cc22rLWanSz9yMTr7IkEeI2ZngDpYlxslYdIsYZBnCX3TT1FhgISMESkbWlpqJ6es4AQ7x YBmXFdacQiwJuMyjy5H845W3rFkF+dGQb+XVmmJHknr2RcdLUkj6VlvxJKUxlKaC1An0aS F02l4uxr+cZh65EW7qV2vJVa/qzsxzQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YZMroL1m; spf=pass (imf27.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721731780; a=rsa-sha256; cv=none; b=o+Q1rlMccYkWkoIf/SANHDhhnBqCMa2fkh2epi/OnX5rqkp4niNmI35kR/NDVMUVmqIXMZ GDD3Akytg6STGvO74Y8gGtgfvBrYFDGJgigawf2lqmKG/D+mJNyNEEBdFe49pb2pPs8SDy 2ZSfys3UPzz3XRNz3+ZKeul6qPQEpdw= Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2ef2fbf1d14so18165771fa.1 for ; Tue, 23 Jul 2024 03:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721731840; x=1722336640; 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=0dRtw8ZAunWvu++rHHyoAYfF4HuDJvNfZWM1BGrhWE4=; b=YZMroL1miLu9nM6u2jA7oCx+Vy5g/LUh6ngO7OFGjKsmlpRlQG6H8WPFjbOCyC6bjn rGKgsVfAb8+K5CtF2fZdE8g0/MlEkBh825TingLQQ/YzN+ZIQvp9PJfCXG07VRwXaeF4 w5EncZyvy9LwVCCWrr0ShdnGZLVq0M4nNUJc27+54PdKnbN7X7H0TSRWSr+3fqj/iNRO 1fgsuwoX37Dx37SfArV5r3rnE6fbB5NN8Iv7L53asnib99iHCVTa++njR1NQLgrEK8l7 JZ0VG07ZMJEDBEtwHhC3atNJdLy5t+LDTroysPerzQB7z0pWBAFTak7Drfbgpp3pwB47 e9mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721731840; x=1722336640; 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=0dRtw8ZAunWvu++rHHyoAYfF4HuDJvNfZWM1BGrhWE4=; b=W6qPbB7PgWwX8R+s/0FGfW1lNkz3r2o19jfpo1xpM6NqzvZkbIMEt08V35Uwkg+x0j G3zpf3GJ8pzOrDn99eui3PJQyeyxzkTF3eDxPdVbeHftE+k4cjLLs3xS5k0WsWCZxUBF aCPKW2tL+PK/ysLkPGDd9hunqqe0bwnJe39rzMY2ftqvR6uO0eItbs3RjEf1FXh0fcRH TwBtgjJq+YtIDmZjGYFr2V0txEe5fHt4Pvh4emzk01Sokeser1UYXKLAyfIUVvS4Q9Ix KkqXw75kiVZJsNUkO37O4W76lQn7HedAjWOjeqIYbC7h+swCV3wpPp8cMrkqt05Gj6ba 9wRQ== X-Forwarded-Encrypted: i=1; AJvYcCVe1+Qx3YhHoJ5sfxge7tJaTzhKNQAkjiiswnThgsjuv1A8WVUf9Vz+r9fgR5Dx2UIo81MHB5sKbJcvZ/bI7wSgQ+Y= X-Gm-Message-State: AOJu0YytfC4SP2tyl8Fwns9Tc2qLdaMdv2KvZ1Hy77vyYBV+qHKhFfYx Yk+go3/zRk8fOxFKI+uJl0fAGwm/SzLLfhMMrg+FPfZRTaCjABq3 X-Google-Smtp-Source: AGHT+IGSthot0iKE/vnYRJKk2YUIwtdaQfsx4fYPIMwYj5KmJH4KDDVptJnU8LtEG8PCcRCc48D0Qg== X-Received: by 2002:a2e:a7ca:0:b0:2ee:7c35:d892 with SMTP id 38308e7fff4ca-2f0210dd6edmr7003811fa.17.1721731839466; Tue, 23 Jul 2024 03:50:39 -0700 (PDT) Received: from pc636 (host-90-233-197-231.mobileonline.telia.com. [90.233.197.231]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f01cc2ef3bsm3955251fa.98.2024.07.23.03.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jul 2024 03:50:38 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 23 Jul 2024 12:50:36 +0200 To: Adrian Huang Cc: urezki@gmail.com, ahuang12@lenovo.com, akpm@linux-foundation.org, hch@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, sunjw10@lenovo.com Subject: Re: [PATCH 1/1] mm/vmalloc: Add preempt point in purge_vmap_node() when enabling kasan Message-ID: References: <20240722115054.6295-1-ahuang12@lenovo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240722115054.6295-1-ahuang12@lenovo.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AF45E40017 X-Stat-Signature: 5h1xi9w3uiuehctxewruw4tkbb17o8xq X-Rspam-User: X-HE-Tag: 1721731841-621799 X-HE-Meta: U2FsdGVkX19VKUHiIHaCQMGprscytstR7ngfPNBu3y1KsXs/5rwM0cCJzH7LD6YXKdV5zz8Q5bJ7JsGRGrXnLHE6nf0tD/zeWvSmwUkfs8rZ7sNZrd+MAg0dlkLmP2Y6e/rNnjPSJQrASAFywQZUnhBEIR4zzApF9Ugd7c3LX8vIUGp/V1VGavVUbFHrjyqdB8c8Z4rSpwebfDaVTSksHNhBBn6O4lykPvPeuDv0IBZ3o8hXeEtsDZ3ugz1yVhxwYv/lzfDkzIHyTTrVYcdjzIyRcyXcyG+v+G1PTLEet78nsjGLfwXt4MO+OCA4PjfNVSuPtcYCMfZxSEhddNRqzAB9LRkkyJ+C/hl5H08uZ7TeC1YWf/adWZa/OAWZ1ERr3diCUDwIukwt0zoUmUzsRRgWW0Zw9WZfcUSIru0G1nKF1jmDc3YWRi1vk9gnh00QRbKRfVNxHbHziHpFuFJ6jDES/9sqX3zhD2ObqDm7IhpGUaMww41LRfCBMktH3I29p5UlG5AnOjUkZtVcnN+UVcT+ENxGu1ORVmXLMebyWOe3k9z4voRnH/FVHngnoObJnVXGnGxknnyJ578Ije67Ij1g6ZjLV6u93u7PLV9FD+Wz6HBAYHoseej/SXtVhaeUX0EHMAgHec6JVNKnVzB6UERR9rejVncO69z8mNhJljyUkPPFb/ZJmpK55IZYfvf9PyXyAt/65syR454DFWI3FZMDRKZJBsHwuGWgH6dKJ0FfCiioP5kZFtoT+oXjhNczqskYr6oIdqjsVwtBHROp0CjBp9wf9D8RAea8ukJQdlsFnZok+VZ8sa9eycBdWshpc91C78lydWw22BSqy1a9DTUq6kt2Chxy3ZciSe9AHueVErVcjMY/Z0BGUG4q+AQ45CpG38WRvv/hQjb28xhgrmiAcwLTSXXhCQM2ziCiRoDvL72X5Q0jR4HcwSEkepRuear1nIgxI1dneqYMLdk jXosFQQP UfwSdRrcjg17l8X5Vv1xWVOnbqIB92E3+5l33BxFhSrWiLafY2t8CY8vRMwSr/GEdMK22S9BfXPFZDSypv4UdlWN+QDw6q1dLYjfQ//RT2GnAdbPGOvlbWnj8XZrgxRjzw1wl/wE2dJPXbRDRTSm3F9zsYOABzHSJos9LEvrJGjYo8Qu6zsNwWYA6mkyDOMbKBkhdIdxioR0ovVvHSBDzsChPYNPvceq28Fc2tGdzIZ38EVpeQJAUYGLgF6MkoQmSsj3dMX8JG0l2WbmOeBj+pe1gohDyhGGsQCDuADbuJ2nkp/tHvP7GgTJXJdvpQoP7WxD+DoAIj2sTEj2lXQX/xp4VJ8ApykUlBb4zJ+HR3X7BdZWKE2NUfEFLNZgyy5N+3P77H2tWs1dS6us0l8T9srL56nry8wAXF3b1 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: > If we combine all tlb flush operations into one operation in the call path > 'purge_vmap_node()->kasan_release_vmalloc()', the running time of > drain_vmap_area_work() can be saved greately. The idea is from the > flush_tlb_kernel_range() call in __purge_vmap_area_lazy(). > And, the soft lockup won't not be triggered. Please refer to the following patch. > Here is the test result based on 6.10: > > [6.10 wo/ the patch below] > 1. ftrace latency profiling (record a trace if the latency > 20s): Commands > echo 20000000 > /sys/kernel/debug/tracing/tracing_thresh > echo drain_vmap_area_work > /sys/kernel/debug/tracing/set_graph_function > echo function_graph > /sys/kernel/debug/tracing/current_tracer > echo 1 > /sys/kernel/debug/tracing/tracing_on > > 2. Run `make -j $(nproc)` to compile the kernel source > > 3. Once the soft lockup is reproduced, check the ftace: > cat /sys/kernel/debug/tracing/trace > # tracer: function_graph > # > # CPU DURATION FUNCTION CALLS > # | | | | | | | > 76) $ 50412985 us | } /* __purge_vmap_area_lazy */ > 76) $ 50412997 us | } /* drain_vmap_area_work */ > 76) $ 29165911 us | } /* __purge_vmap_area_lazy */ > 76) $ 29165926 us | } /* drain_vmap_area_work */ > 91) $ 53629423 us | } /* __purge_vmap_area_lazy */ > 91) $ 53629434 us | } /* drain_vmap_area_work */ > 91) $ 28121014 us | } /* __purge_vmap_area_lazy */ > 91) $ 28121026 us | } /* drain_vmap_area_work */ > > > [6.10 w/ the patch below] > 1. Repeat step 1-2 in "[6.10 wo/ the patch below]" > > 2. The soft lockup is not triggered and the ftrace log is empty. > cat /sys/kernel/debug/tracing/trace > # tracer: function_graph > # > # CPU DURATION FUNCTION CALLS > # | | | | | | | > > > 3. Setting 'tracing_thresh' to 10/5 seconds does not get any ftrace log. > > 4. Setting 'tracing_thresh' to 1 second gets ftrace log. > cat /sys/kernel/tracing/trace > # tracer: function_graph > # > # CPU DURATION FUNCTION CALLS > # | | | | | | | > 51) $ 1019695 us | } /* __purge_vmap_area_lazy */ > 51) $ 1019703 us | } /* drain_vmap_area_work */ > 198) $ 1018707 us | } /* __purge_vmap_area_lazy */ > 198) $ 1018718 us | } /* drain_vmap_area_work */ > > 5. Run the following test_vmalloc command without any issues > modprobe test_vmalloc nr_threads=$(nproc) run_test_mask=0x1 nr_pages=4 > > Could you please test this patch in your VM environment? > It works great and does not generate the soft-lock-up splat :) See below some comments: > --- > diff --git a/include/linux/kasan.h b/include/linux/kasan.h > index 70d6a8f6e25d..ddbf42a1a7b7 100644 > --- a/include/linux/kasan.h > +++ b/include/linux/kasan.h > @@ -55,6 +55,9 @@ extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D]; > int kasan_populate_early_shadow(const void *shadow_start, > const void *shadow_end); > > +#define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply existing page range */ > +#define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */ > + > #ifndef kasan_mem_to_shadow > static inline void *kasan_mem_to_shadow(const void *addr) > { > @@ -511,7 +514,8 @@ void kasan_populate_early_vm_area_shadow(void *start, unsigned long size); > int kasan_populate_vmalloc(unsigned long addr, unsigned long size); > void kasan_release_vmalloc(unsigned long start, unsigned long end, > unsigned long free_region_start, > - unsigned long free_region_end); > + unsigned long free_region_end, > + unsigned long flags); > > #else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */ > > @@ -526,7 +530,8 @@ static inline int kasan_populate_vmalloc(unsigned long start, > static inline void kasan_release_vmalloc(unsigned long start, > unsigned long end, > unsigned long free_region_start, > - unsigned long free_region_end) { } > + unsigned long free_region_end, > + unsigned long flags) { } > > #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */ > > @@ -561,7 +566,8 @@ static inline int kasan_populate_vmalloc(unsigned long start, > static inline void kasan_release_vmalloc(unsigned long start, > unsigned long end, > unsigned long free_region_start, > - unsigned long free_region_end) { } > + unsigned long free_region_end, > + unsigned long flags) { } > > static inline void *kasan_unpoison_vmalloc(const void *start, > unsigned long size, > diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c > index d6210ca48dda..88d1c9dcb507 100644 > --- a/mm/kasan/shadow.c > +++ b/mm/kasan/shadow.c > @@ -489,7 +489,8 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr, > */ > void kasan_release_vmalloc(unsigned long start, unsigned long end, > unsigned long free_region_start, > - unsigned long free_region_end) > + unsigned long free_region_end, > + unsigned long flags) > { > void *shadow_start, *shadow_end; > unsigned long region_start, region_end; > @@ -522,12 +523,17 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end, > __memset(shadow_start, KASAN_SHADOW_INIT, shadow_end - shadow_start); > return; > } > - apply_to_existing_page_range(&init_mm, > + > + > + if (flags & KASAN_VMALLOC_PAGE_RANGE) > + apply_to_existing_page_range(&init_mm, > (unsigned long)shadow_start, > size, kasan_depopulate_vmalloc_pte, > NULL); > - flush_tlb_kernel_range((unsigned long)shadow_start, > - (unsigned long)shadow_end); > + > + if (flags & KASAN_VMALLOC_TLB_FLUSH) > + flush_tlb_kernel_range((unsigned long)shadow_start, > + (unsigned long)shadow_end); > } > } > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index e34ea860153f..d66e09135876 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2193,8 +2193,15 @@ static void purge_vmap_node(struct work_struct *work) > struct vmap_area *va, *n_va; > LIST_HEAD(local_list); > > + unsigned long start; > + unsigned long end; > + > vn->nr_purged = 0; > > + start = list_first_entry(&vn->purge_list, struct vmap_area, list)->va_start; > + > + end = list_last_entry(&vn->purge_list, struct vmap_area, list)->va_end; > + > list_for_each_entry_safe(va, n_va, &vn->purge_list, list) { > unsigned long nr = (va->va_end - va->va_start) >> PAGE_SHIFT; > unsigned long orig_start = va->va_start; > @@ -2205,7 +2212,8 @@ static void purge_vmap_node(struct work_struct *work) > > if (is_vmalloc_or_module_addr((void *)orig_start)) > kasan_release_vmalloc(orig_start, orig_end, > - va->va_start, va->va_end); > + va->va_start, va->va_end, > + KASAN_VMALLOC_PAGE_RANGE); > > atomic_long_sub(nr, &vmap_lazy_nr); > vn->nr_purged++; > @@ -2218,6 +2226,8 @@ static void purge_vmap_node(struct work_struct *work) > list_add(&va->list, &local_list); > } > > + kasan_release_vmalloc(start, end, start, end, KASAN_VMALLOC_TLB_FLUSH); > + > Do we need it here? We just did the TLB flush for en entire range in the __purge_vmap_area_lazy(). So, it is two times invoked and looks odd to me. Am i missing something? Thanks! -- Uladzislau Rezki