From: Uladzislau Rezki <urezki@gmail.com>
To: Ze Zuo <zuoze1@huawei.com>
Cc: gustavoars@kernel.org, akpm@linux-foundation.org,
linux-hardening@vger.kernel.org, linux-mm@kvack.org,
willy@infradead.org, keescook@chromium.org, urezki@gmail.com,
wangkefeng.wang@huawei.com
Subject: Re: [PATCH -next] mm: usercopy: add a debugfs interface to bypass the vmalloc check.
Date: Tue, 3 Dec 2024 07:12:45 +0100 [thread overview]
Message-ID: <Z06hXVPhN_3RH8Vt@pc636> (raw)
In-Reply-To: <20241203023159.219355-1-zuoze1@huawei.com>
On Tue, Dec 03, 2024 at 10:31:59AM +0800, Ze Zuo wrote:
> The commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") introduced
> vmalloc check for usercopy. However, in subsystems like networking, when
> memory allocated using vmalloc or vmap is subsequently copied using
> functions like copy_to_iter/copy_from_iter, the check is triggered. This
> adds overhead in the copy path, such as the cost of searching the
> red-black tree, which increases the performance burden.
>
> We found that after merging this patch, network bandwidth performance in
> the XDP scenario significantly dropped from 25 Gbits/sec to 8 Gbits/sec,
> the hardened_usercopy is enabled by default.
>
> To address this, we introduced a debugfs interface that allows selectively
> enabling or disabling the vmalloc check based on the use case, optimizing
> performance.
>
> By default, vmalloc check for usercopy is enabled.
>
> To disable the vmalloc check:
> echo Y > /sys/kernel/debug/bypass_usercopy_vmalloc_check
>
> After executing the above command, the XDP performance returns to 25
> Gbits/sec.
>
To what Matthew has asked, could you please also specify the kernel version
you run your experiment on? Apart of that please describe your system and HW.
Thank you!
--
Uladzislau Rezki
prev parent reply other threads:[~2024-12-03 6:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 2:31 [PATCH -next] mm: usercopy: add a debugfs interface to bypass the vmalloc check Ze Zuo
2024-12-03 4:11 ` Matthew Wilcox
2024-12-03 11:23 ` zuoze
2024-12-03 12:39 ` Uladzislau Rezki
2024-12-03 13:10 ` zuoze
2024-12-03 13:25 ` Uladzislau Rezki
2024-12-03 13:30 ` Kefeng Wang
2024-12-03 13:39 ` Uladzislau Rezki
2024-12-03 13:45 ` Kefeng Wang
2024-12-03 13:51 ` Uladzislau Rezki
2024-12-03 14:10 ` Kefeng Wang
2024-12-03 14:20 ` Uladzislau Rezki
2024-12-03 19:02 ` Uladzislau Rezki
2024-12-03 19:56 ` Matthew Wilcox
2024-12-04 1:38 ` zuoze
2024-12-04 4:43 ` Kees Cook
2024-12-04 7:55 ` Uladzislau Rezki
2024-12-04 9:21 ` zuoze
2024-12-04 9:27 ` Uladzislau Rezki
2024-12-04 8:51 ` Uladzislau Rezki
2024-12-16 4:24 ` Matthew Wilcox
2024-12-16 19:18 ` Uladzislau Rezki
2024-12-04 1:21 ` zuoze
2024-12-03 6:12 ` Uladzislau Rezki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z06hXVPhN_3RH8Vt@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gustavoars@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=zuoze1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.