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 X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0D5DC433DB for ; Wed, 6 Jan 2021 15:20:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E7CA2311F for ; Wed, 6 Jan 2021 15:20:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E7CA2311F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2DF436B028F; Wed, 6 Jan 2021 10:20:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 290186B0290; Wed, 6 Jan 2021 10:20:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10B8E6B0291; Wed, 6 Jan 2021 10:20:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id EAECE6B028F for ; Wed, 6 Jan 2021 10:20:18 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B2A2D824556B for ; Wed, 6 Jan 2021 15:20:18 +0000 (UTC) X-FDA: 77675711316.08.mint11_1502326274e2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 977FF1819E769 for ; Wed, 6 Jan 2021 15:20:18 +0000 (UTC) X-HE-Tag: mint11_1502326274e2 X-Filterd-Recvd-Size: 5163 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Jan 2021 15:20:17 +0000 (UTC) Received: by mail-wr1-f42.google.com with SMTP id r7so2759736wrc.5 for ; Wed, 06 Jan 2021 07:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=u9BfJw9bwODVGWCy/LjRuDollmtVrULB9sLGdsTMFog=; b=iSKYKqg3EPV9zohrHs4gWOkHtNCORtYsqfgfDl5RhqX/1KKvbLxhUa4ZdE4RfD0s0L A9HXrWQI6CgTBpGzMsV86U3ZM8Y++2zDRI0oUO1C+1OxixGQGryf8xjndjwK8dmRai15 9LPjyH3wdpiXGWCg959H5TZ85pV/nhyigUgExw/UhLSc7AgWJ1g/3yCht7Bh+D3ZzIr0 ClW3+EJ6XQwb55bEIEgNjTLXV8ySl0vKkUIjnokEtiFrORX6jOlQFzhgbV+N3u6hDdxV OvVpGMdLww8P5heIjJqoP+m30hOEOfdGQD8ObIgR2rdjvuKmIay6k7Le5JAfKh9aJpt3 942g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=u9BfJw9bwODVGWCy/LjRuDollmtVrULB9sLGdsTMFog=; b=CKBcvvU2i1x6dKT7W+o6dirDvFJwI2vuZfhJfhEAViG23VjyDEfPykOyWcO+9GHMaq gdd2hPfyqGOU9IVGvIww3K4PJyRdrmXVr2R12pQcgxEO7UYsdH4b2vFITyXJYGYys+fv RwfzipanaGaZoBZej8BsTKzPkivmUo5qUlDRSIH13StM56ggYtbsRczRkDNOOXPAaWk+ WZlHZro1E24gaMjo3qmQ/f+0wIsOdbUJQbhkVFfIFK8N/v1zB8+oduAtoSUiwmVf6po6 AyJLujBdkxxR9C9/3Iavd3mWWRIsOlhTvtDxY5Zn25xYDGQRdHYd6E0D/ZzK+XL50SJ0 AD3Q== X-Gm-Message-State: AOAM532nBSqyIte1dhpidKFax4uFGMEjqdyVrz8ryri5HTIGirq7l0RB WXVRBLdx72U1SFq/G0nDXCc= X-Google-Smtp-Source: ABdhPJx0D91P/ffwLygXmqp38D4DN2Dtv5gYGoKn7qC6szDZYAwuPY6qLtPHWN6jM0R7EBvCnJbO1g== X-Received: by 2002:a5d:5105:: with SMTP id s5mr4609164wrt.136.1609946416649; Wed, 06 Jan 2021 07:20:16 -0800 (PST) Received: from [192.168.2.27] (39.35.broadband4.iol.cz. [85.71.35.39]) by smtp.gmail.com with ESMTPSA id 138sm3673962wma.41.2021.01.06.07.20.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Jan 2021 07:20:16 -0800 (PST) To: linux-mm@kvack.org Cc: Linux Kernel Mailing List , Mikulas Patocka From: Milan Broz Subject: Very slow unlockall() Message-ID: <70885d37-62b7-748b-29df-9e94f3291736@gmail.com> Date: Wed, 6 Jan 2021 16:20:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Hi, we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code and someone tried to use it with hardened memory allocator library. Execution time was increased to extreme (minutes) and as we found, the problem is in munlockall(). Here is a plain reproducer for the core without any external code - it takes unlocking on Fedora rawhide kernel more than 30 seconds! I can reproduce it on 5.10 kernels and Linus' git. The reproducer below tries to mmap large amount memory with PROT_NONE (later never used). The real code of course does something more useful but the problem is the same. #include #include #include #include int main (int argc, char *argv[]) { void *p = mmap(NULL, 1UL << 41, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) return 1; if (mlockall(MCL_CURRENT | MCL_FUTURE)) return 1; printf("locked\n"); if (munlockall()) return 1; printf("unlocked\n"); return 0; } In traceback I see that time is spent in munlock_vma_pages_range. [ 2962.006813] Call Trace: [ 2962.006814] ? munlock_vma_pages_range+0xe7/0x4b0 [ 2962.006814] ? vma_merge+0xf3/0x3c0 [ 2962.006815] ? mlock_fixup+0x111/0x190 [ 2962.006815] ? apply_mlockall_flags+0xa7/0x110 [ 2962.006816] ? __do_sys_munlockall+0x2e/0x60 [ 2962.006816] ? do_syscall_64+0x33/0x40 ... Or with perf, I see # Overhead Command Shared Object Symbol # ........ ....... ................. ..................................... # 48.18% lock [kernel.kallsyms] [k] lock_is_held_type 11.67% lock [kernel.kallsyms] [k] ___might_sleep 10.65% lock [kernel.kallsyms] [k] follow_page_mask 9.17% lock [kernel.kallsyms] [k] debug_lockdep_rcu_enabled 6.73% lock [kernel.kallsyms] [k] munlock_vma_pages_range ... Could please anyone check what's wrong here with the memory locking code? Running it on my notebook I can effectively DoS the system :) Original report is https://gitlab.com/cryptsetup/cryptsetup/-/issues/617 but this is apparently a kernel issue, just amplified by usage of munlockall(). Thanks, Milan