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=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 443DFC433EF for ; Mon, 13 Sep 2021 08:44:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E744260F11 for ; Mon, 13 Sep 2021 08:44:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E744260F11 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 64F1A6B0071; Mon, 13 Sep 2021 04:44:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FF0A6B0073; Mon, 13 Sep 2021 04:44:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4ECFB6B0074; Mon, 13 Sep 2021 04:44:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) by kanga.kvack.org (Postfix) with ESMTP id 4215F6B0071 for ; Mon, 13 Sep 2021 04:44:31 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 06D53180AD83E for ; Mon, 13 Sep 2021 08:44:31 +0000 (UTC) X-FDA: 78581913942.07.593265E Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf25.hostedemail.com (Postfix) with ESMTP id 9C6C0B000184 for ; Mon, 13 Sep 2021 08:44:30 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id g8so13176304edt.7 for ; Mon, 13 Sep 2021 01:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJVLAgjPqP4xIJS9umrFtQA2JuduxsSgfZlrPIy+kDk=; b=VY3Zmvkj8mVPfQA/REWw0z8U6rmZ//lToHAyUr6eaOw76YsrXwFzNE4K0CZBDI9T1x gcBMDsEPgxkSMzqboJTdXnQTN9t13gTb+IyqX9W4gnjDFTCn+YZIl6KUnuyYjOGkwjGd YHRVbz65fQoy9m6b41cHBVMvyh47YLLQGiatQZpKs0Fb8vq7uUXyCy77GL4Dd4TNVjrE zpuNqS43xM12rm2dj53VUPuycaRHm4fqCRAxwnW3CfubUf0CckiLPmGI6QeiNbkc6m6h TtX61ECTdlytDlYEdxlsnxGya+EkhNrSSdocl6ej8yQ9uZkgvZDzndEw+O+C3xhK/qc9 iIRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DJVLAgjPqP4xIJS9umrFtQA2JuduxsSgfZlrPIy+kDk=; b=Yj37mtFLCrlTTR44yeLhtGFHdSZQQQ2LWWPLDSe1vBfWMsVcsY2NGcEakwgDozv8qJ 6qjlVHD/u0O9uo0oHbAEZOPAKCBQHzi7sOlpWwmgc58m5O0DZ0k++stR3JzmtZd1yUZ3 Y9KlPn6oH6CQVzpq1FoKi6x+7M9bkRaEDzHk/DutNpHsNz6i876MHXyZ66oPLGlUNhbU E3KxP5sBtM2GdA+PoDIhIf5r+EpDR4yYSGKBeWECJNbL9xFTDsVeFToqbeX7wnIze1uN gG9i7IxO+JrN+pf67mjsEHiUylp05DWLt3mP8iOzrlHKvsglIiNnidag1Knx9PmG4aPb n57Q== X-Gm-Message-State: AOAM533x7mMoRVE3YLtdJne0wbYaHVPYJzrd3uE/gtl0NaccOE9YO9pO N+qdGsIq05ONK5NE3pjXmz3gbbavk92U7ZoVMKA= X-Google-Smtp-Source: ABdhPJyXvc35ThSM56k2hv5/iCu97D4QsqZsoCkrHXWLBUmMQjxbuKufpiRubRI4zNvpkOX4bZI3M750SQcjDwvQgmc= X-Received: by 2002:aa7:da41:: with SMTP id w1mr10093692eds.344.1631522669397; Mon, 13 Sep 2021 01:44:29 -0700 (PDT) MIME-Version: 1.0 References: <20210908132727.16165-1-david@redhat.com> In-Reply-To: <20210908132727.16165-1-david@redhat.com> From: Uladzislau Rezki Date: Mon, 13 Sep 2021 10:44:18 +0200 Message-ID: Subject: Re: [PATCH v1] mm/vmalloc: fix exact allocations with an alignment > 1 To: David Hildenbrand Cc: LKML , Ping Fang , Andrew Morton , Roman Gushchin , Michal Hocko , Oscar Salvador , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9C6C0B000184 X-Stat-Signature: e61yruy343pwnapfim9zgxx16xecmph8 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VY3Zmvkj; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1631522670-644589 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: Hello. Let me have a look at it. Vlad Rezki On Wed, Sep 8, 2021 at 3:27 PM David Hildenbrand wrote: > > find_vmap_lowest_match() is imprecise such that it won't always > find "the first free block ... that will accomplish the request" if > an alignment > 1 was specified: especially also when the alignment is > PAGE_SIZE. Unfortuantely, the way the vmalloc data structures were > designed, propagating the max size without alignment information through > the tree, it's hard to make it precise again when an alignment > 1 is > specified. > > The issue is that in order to be able to eventually align later, > find_vmap_lowest_match() has to search for a slightly bigger area and > might skip some applicable subtrees just by lookign at the result of > get_subtree_max_size(). While this usually doesn't matter, it matters for > exact allocations as performed by KASAN when onlining a memory block, > when the free block exactly matches the request. > (mm/kasn/shadow.c:kasan_mem_notifier()). > > In case we online memory blocks out of order (not lowest to highest > address), find_vmap_lowest_match() with PAGE_SIZE alignment will reject > an exact allocation if it corresponds exactly to a free block. (there are > some corner cases where it would still work, if we're lucky and hit the > first is_within_this_va() inside the while loop) > > [root@vm-0 fedora]# echo online > /sys/devices/system/memory/memory82/state > [root@vm-0 fedora]# echo online > /sys/devices/system/memory/memory83/state > [root@vm-0 fedora]# echo online > /sys/devices/system/memory/memory85/state > [root@vm-0 fedora]# echo online > /sys/devices/system/memory/memory84/state > [ 223.858115] vmap allocation for size 16777216 failed: use vmalloc= to increase size > [ 223.859415] bash: vmalloc: allocation failure: 16777216 bytes, mode:0x6000c0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 > [ 223.860992] CPU: 4 PID: 1644 Comm: bash Kdump: loaded Not tainted 4.18.0-339.el8.x86_64+debug #1 > [ 223.862149] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 > [ 223.863580] Call Trace: > [ 223.863946] dump_stack+0x8e/0xd0 > [ 223.864420] warn_alloc.cold.90+0x8a/0x1b2 > [ 223.864990] ? zone_watermark_ok_safe+0x300/0x300 > [ 223.865626] ? slab_free_freelist_hook+0x85/0x1a0 > [ 223.866264] ? __get_vm_area_node+0x240/0x2c0 > [ 223.866858] ? kfree+0xdd/0x570 > [ 223.867309] ? kmem_cache_alloc_node_trace+0x157/0x230 > [ 223.868028] ? notifier_call_chain+0x90/0x160 > [ 223.868625] __vmalloc_node_range+0x465/0x840 > [ 223.869230] ? mark_held_locks+0xb7/0x120 > > While we could fix this in kasan_mem_notifier() by passing an alignment > of "1", this is actually an implementation detail of vmalloc and to be > handled internally. > > So use an alignment of 1 when calling find_vmap_lowest_match() for exact > allocations that are expected to succeed -- if the given range can > satisfy the alignment requirements. > > Fixes: 68ad4a330433 ("mm/vmalloc.c: keep track of free blocks for vmap allocation") > Reported-by: Ping Fang > Cc: Andrew Morton > Cc: Uladzislau Rezki (Sony) > Cc: Roman Gushchin > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: linux-mm@kvack.org > Signed-off-by: David Hildenbrand > --- > mm/vmalloc.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d5cd52805149..c6071f5f8de3 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1153,7 +1153,8 @@ is_within_this_va(struct vmap_area *va, unsigned long size, > /* > * Find the first free block(lowest start address) in the tree, > * that will accomplish the request corresponding to passing > - * parameters. > + * parameters. Note that with an alignment > 1, this function > + * can be imprecise and skip applicable free blocks. > */ > static __always_inline struct vmap_area * > find_vmap_lowest_match(unsigned long size, > @@ -1396,7 +1397,15 @@ __alloc_vmap_area(unsigned long size, unsigned long align, > enum fit_type type; > int ret; > > - va = find_vmap_lowest_match(size, align, vstart); > + /* > + * For exact allocations, ignore the alignment, such that > + * find_vmap_lowest_match() won't search for a bigger free area just > + * able to align later and consequently fail the search. > + */ > + if (vend - vstart == size && IS_ALIGNED(vstart, align)) > + va = find_vmap_lowest_match(size, 1, vstart); > + else > + va = find_vmap_lowest_match(size, align, vstart); > if (unlikely(!va)) > return vend; > > > base-commit: 7d2a07b769330c34b4deabeed939325c77a7ec2f > -- > 2.31.1 >