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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 DBBBFC433DB for ; Mon, 8 Mar 2021 18:50:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A6CF65296 for ; Mon, 8 Mar 2021 18:50:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A6CF65296 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E46D78D0062; Mon, 8 Mar 2021 13:50:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1E328D001D; Mon, 8 Mar 2021 13:50:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D327D8D0062; Mon, 8 Mar 2021 13:50:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id BAD598D001D for ; Mon, 8 Mar 2021 13:50:27 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7636412C8 for ; Mon, 8 Mar 2021 18:50:27 +0000 (UTC) X-FDA: 77897597694.10.9E030D1 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id AC4EED6 for ; Mon, 8 Mar 2021 18:50:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=GCgtd/lVj4qCydlD5pGFGDf3WLJgh9lgIa+6AzkEMy8=; b=TsqST1l3ojmFBMc5qHJvgT9Cyy NRCa0UmXdfEVaBQVgNYinDtFIDNJqM2nQg2u6xoY6894LwqtOkewyVzgQmDoc9k1zogIxAlLI0jIz jItbxJFmraSNgJpqNLnanhuVVbwkOOve9ISTHLNYT0Pm/BQ8naQ0VPkToXiVcgJfAqMIixem3J1fR JW1f2HFFZjUxY84FCLNj8V1rFw74pZiHMiWHYP44C3RJDAhRjGzjs3OD9N6m96uIKlpoOH/9qMyjG yeB58S0veVwDBKQMin1NBn3E+FALwCCfLXfhAHonDU7AwJhQZWiBEmj1+uo1xPCgvkihrAgFPSMy9 3cDdb3CQ==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lJKx8-00FwDA-8Y; Mon, 08 Mar 2021 18:50:10 +0000 Date: Mon, 8 Mar 2021 18:50:02 +0000 From: Matthew Wilcox To: Andrew Morton Cc: jianhong chen , linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , "Kirill A . Shutemov" , Yang Shi , Michel Lespinasse Subject: mm/mmap.c: fix the adjusted length error Message-ID: <20210308185002.GD3479805@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Stat-Signature: 3sy86zo4ao9fhkqzuzhn6jnusnoe75iz X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AC4EED6 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615229421-796213 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 Andrew, You have a patch in your tree which I think is a bad idea. Link: http://lkml.kernel.org/r/1558073209-79549-1-git-send-email-chenjianhong2@huawei.com The problem it describes is real -- if you chew up all the address space with 64MB pages, free one and then try to allocate another one, it will fail. I don't like the solution, though. If memory is fragmented in a different way from that described by the patch, it will cause us to walk into rbtree nodes that look like they might be able to satisfy our allocation, only to find that they cannot, due to alignment issues. In the worst case, it turns into a linear scan of the address space instead of logarithmic. I would prefer to see this solved by doing two passes. The first would look for a 128MB size hole, as we do now, which is guaranteed to find us a 64MB hole if it succeeds. If that search fails, then we can fall back to the 64MB hole search, as done in this patch.