Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2942806imd; Sun, 28 Oct 2018 22:18:34 -0700 (PDT) X-Google-Smtp-Source: AJdET5dNSouNKORiOKgKDEH34ed+Ab/KOtIu9fDDEIPI7vuFYuS1OrSe/nHy0TOgkUuO5VUgyzrO X-Received: by 2002:a63:27c1:: with SMTP id n184-v6mr12422036pgn.334.1540790314163; Sun, 28 Oct 2018 22:18:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540790314; cv=none; d=google.com; s=arc-20160816; b=dujx2OnfTrH0C9V1ewLqWOlEHTImPETY+dGsT5qUc/GrL7LqOA1uL38ZyaijiWB02/ f4F8PJ8Xs2E9MHsjLSQ3oTAPsGj3CH4AmqO83Ydw2H5kXwzXWrm2TdtFMUfKS0vA/EQ4 u91ADiFr3Gm6FPa1JPhYAlPkjwHHdXL9sjDsqlNwdDZp/WSvRtqVFXWBpTNmtamk1wtB XQmlgQtDawXkvfmAAwJlzXxSxKhBwxMPv1ctXrFVfDYY+leNrzSJclF1z3ySB995uT/I JIkyC2iKCKzvDMkLTudH9sXgTRTral3who/95bnc+w5mL/MbStk6zOSPMY8SQMGLQAL6 03Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=0KNNKw1/amMnFlX3bpSyjsiBE9Q1u0znYuBXSNQ4r/U=; b=zAFLoVyfa6xrwGrfN/Rb3CVW0yv5s1gVM5znCi8h474H6AKH+QP8U3R0qLi4xHyD9m BffH4ZLiJ9EEFXZXyzeXul8vPDMuU7YfU7au3Z7HOwOxUeakuw/YU62QzgJT9clMSwBY oUn/OyBjxZcFfP+HrB2D4R77u0aexQdYCwVBfr5xN8LNRh5korps64ujBQD1rzA3HiVe ZapbRS54b9SUdKERXOTDJ4VCTUczMqOwPmS8uKl6LGfVg7nmC+2GfCvNT34tMVsoxoi3 uVTHlb29WOB+2e/WvUohiWLpODdsJ2eLn3ffWbFitqT1dfzrk1mirdG5zuuw0fyvAYTe O8dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r5-v6si16607137pli.248.2018.10.28.22.18.18; Sun, 28 Oct 2018 22:18:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729180AbeJ2OEK (ORCPT + 99 others); Mon, 29 Oct 2018 10:04:10 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:49827 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729153AbeJ2OEK (ORCPT ); Mon, 29 Oct 2018 10:04:10 -0400 X-UUID: a9d98cb000d24868b7ff3670f881530e-20181029 X-UUID: a9d98cb000d24868b7ff3670f881530e-20181029 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1181246590; Mon, 29 Oct 2018 13:16:42 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs03n2.mediatek.inc (172.21.101.182) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 13:16:28 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 29 Oct 2018 13:16:28 +0800 From: To: Andrew Morton , Michal Hocko , Joe Perches , Matthew Wilcox CC: , , , , , Miles Chen , "Michal Hocko" Subject: [PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc Date: Mon, 29 Oct 2018 13:16:16 +0800 Message-ID: <1540790176-32339-1-git-send-email-miles.chen@mediatek.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Content-Type: text/plain X-TM-SNTS-SMTP: 86B9739B61A74A4CABEA7080C5AC30440014C9C39DD983E7247355CD1A4FED4F2000:8 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. To solve this problem, use kvmalloc() to allocate kbuf from normal/highmem. But there is one problem here: kvmalloc() does not fallback to vmalloc for sub page allocations. So sub page allocation fails due to out of normal memory cannot fallback to vmalloc. Modify kvmalloc() to allow sub page allocations fallback to vmalloc when CONFIG_HIGHMEM=y and use kvmalloc() to allocate kbuf. Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation. Change since v2: - improve kvmalloc, allow sub page allocations fallback to vmalloc when CONFIG_HIGHMEM=y Change since v1: - use kvmalloc() - clamp buffer size to PAGE_SIZE Signed-off-by: Miles Chen Cc: Joe Perches Cc: Matthew Wilcox Cc: Michal Hocko --- mm/page_owner.c | 8 ++++---- mm/util.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index d80adfe702d3..a064cd046361 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include #include -#include #include #include #include @@ -351,7 +350,8 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, .skip = 0 }; - kbuf = kmalloc(count, GFP_KERNEL); + count = count > PAGE_SIZE ? PAGE_SIZE : count; + kbuf = kvmalloc(count, GFP_KERNEL); if (!kbuf) return -ENOMEM; @@ -397,11 +397,11 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, if (copy_to_user(buf, kbuf, ret)) ret = -EFAULT; - kfree(kbuf); + kvfree(kbuf); return ret; err: - kfree(kbuf); + kvfree(kbuf); return -ENOMEM; } diff --git a/mm/util.c b/mm/util.c index 8bf08b5b5760..7b1c59b9bfbf 100644 --- a/mm/util.c +++ b/mm/util.c @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) ret = kmalloc_node(size, kmalloc_flags, node); /* - * It doesn't really make sense to fallback to vmalloc for sub page - * requests + * It only makes sense to fallback to vmalloc for sub page + * requests if we might be able to allocate highmem pages. */ - if (ret || size <= PAGE_SIZE) + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE)) return ret; return __vmalloc_node_flags_caller(size, node, flags, -- 2.18.0