Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp314614ybt; Fri, 10 Jul 2020 00:02:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/fnrAnkBPFptmZ5e2dQKtv0uDiokw0H5K9s3fDG+5G/yqRSZPif6+2eeXLC0nr0ut3RBC X-Received: by 2002:a17:906:d92e:: with SMTP id rn14mr63150723ejb.314.1594364543483; Fri, 10 Jul 2020 00:02:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594364543; cv=none; d=google.com; s=arc-20160816; b=GJM4a5RcvPDFUrVIPKffsS5ZncJyRRpqVoOrizHId2ec/HiLDudJby/EUlFbj9gr3j ni9Tnv7wAgLnS2/ie2yfwkWY9vTLatcUUyeY+PQIz4b6PKZqRUl6r/qKSOxwzNUsQjGV OhNgjJljPnoXgXroK5t11FpS4ILHSvdwxnk2R6TlEVeXFToUp93bAqoWvmkVns+t/KHD V/gMrw676p7f5ABnMbsw5KPkO6q1LxJRf/B+kUtbVDYxaLKe6zxYzN93oEQglippBCmj /OKhumCu1fdhn1z5Km0HLIoB0zj1Es4SJy0GM1GV5bXCujGCc4bVzazbcsrBCaAhputJ lo2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=mj7ui3T2WSMcLm0kBAfRUhjgf3qnwCC8dGYgMG/J8aQ=; b=Oi1TrabKnglIzq0LOWVYjJiKX9Y2Do5NZdaidj7fil4xtKIVSwhWjfdDSx30VChglw LhUOMacJNK/wq4LM1sSnrCdcz1PurPjyOsNjCWxBg2VF57Ew8xhVx+IxpyFy/SKR+pqd lzVAFuPi7McveQW0q++tcYKi9YuFOxbvnBsrO+lqgD4aWfiMGhxJ29KqPWinc0Tt7SEe NAPr9+3MqsVkQ5xNL4z9A/zH2u/rlwSwnj/TU/UxTroDIoTIzIV5XsR2CgCtMk9Scw32 9/p1Q9NNwUFGCWbLLWE/ddB4QUTJ1838ytJO0i+65IhxYTzBnHapqqde0nvFZhxQD/an 956A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id be11si3352348edb.482.2020.07.10.00.02.00; Fri, 10 Jul 2020 00:02:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727932AbgGJHBV (ORCPT + 99 others); Fri, 10 Jul 2020 03:01:21 -0400 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:45152 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725851AbgGJHBU (ORCPT ); Fri, 10 Jul 2020 03:01:20 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0U2GmRJK_1594364477; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U2GmRJK_1594364477) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2020 15:01:18 +0800 Subject: Re: a question of split_huge_page To: =?UTF-8?Q?Mika_Penttil=c3=a4?= , "Kirill A. Shutemov" , Matthew Wilcox Cc: Johannes Weiner , Linux-MM , "linux-kernel@vger.kernel.org" , Hugh Dickins References: <20200709155002.GF12769@casper.infradead.org> <20200709160750.utl46xvavceuvnom@box> <441ebbeb-0408-e22e-20f4-1be571c4a18e@nextfour.com> From: Alex Shi Message-ID: Date: Fri, 10 Jul 2020 15:00:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <441ebbeb-0408-e22e-20f4-1be571c4a18e@nextfour.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/7/10 下午1:28, Mika Penttilä 写道: >> Thanks a lot for quick reply! >> What I am confusing is the call chain: __iommu_dma_alloc_pages() >> to split_huge_page(), in the func, splited page, >> page = alloc_pages_node(nid, alloc_flags, order); >> And if the pages were added into lru, they maybe reclaimed and lost, >> that would be a panic bug. But in fact, this never happened for long time. >> Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests > > In  __iommu_dma_alloc_pages, after split_huge_page(),  who is taking a > reference on tail pages? Seems tail pages are freed and the function > errornously returns them in pages[] array for use? > Why you say so? It looks like the tail page returned and be used pages = __iommu_dma_alloc_pages() in iommu_dma_alloc_remap() and still on node's lru. Is this right? thanks!