From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Subject: Re: [PATCHv2, RFC 18/30] thp, mm: truncate support for transparent huge page cache Date: Fri, 22 Mar 2013 11:29:57 -0700 Message-ID: <514CA325.3010104@sr71.net> References: <1363283435-7666-1-git-send-email-kirill.shutemov@linux.intel.com> <1363283435-7666-19-git-send-email-kirill.shutemov@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrea Arcangeli , Andrew Morton , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: "Kirill A. Shutemov" Return-path: In-Reply-To: <1363283435-7666-19-git-send-email-kirill.shutemov@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote: > @@ -280,6 +291,7 @@ void truncate_inode_pages_range(struct address_space *mapping, > if (index > end) > break; > > + VM_BUG_ON(PageTransHuge(page)); > lock_page(page); > WARN_ON(page->index != index); > wait_on_page_writeback(page); This looks to be during the second truncate pass where things are allowed to block. What's the logic behind it not being possible to encounter TransHugePage()s here?