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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F35EDC433EF for ; Fri, 22 Oct 2021 11:16:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 698976109F for ; Fri, 22 Oct 2021 11:16:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 698976109F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C974B900003; Fri, 22 Oct 2021 07:16:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C47F6900002; Fri, 22 Oct 2021 07:16:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B35C2900003; Fri, 22 Oct 2021 07:16:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id A3238900002 for ; Fri, 22 Oct 2021 07:16:52 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5A58718041CF2 for ; Fri, 22 Oct 2021 11:16:52 +0000 (UTC) X-FDA: 78723821064.35.E76D7C8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id AE76B5085E2F for ; Fri, 22 Oct 2021 11:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=j71blNuhZOgX+/cgAj5pKSXOeyCTnqXp4/c8vquRDLs=; b=YGQJcluzDOvsTvrCMCXr4eZ5MS BhPc8iNKXeVEE3JCb8WYseynOwxBsc+mprdRTAMR+C926bc876bLxJ5dZGb3fl0VfiO1xMdBOB8Gm bHnR9iydqms+CjZ7dkGSS1fmWV+38XjkCDd5KAgJLwnKiaNDt2Xl8ZVF7EDMY6ya+wB6KuoiIPAmN u20EGiSICFTSFDSMGe6ZBg0S8reu945elOtwxhtYvRE3lfzJy+zZSliiJBqN2mHHycIiBxh2rudTQ mKCPmApMyk2Q5y+hKE5PGIeJ2xe/eFyq+ta1es3VIQRKXjF+shGWh0lcYe7muFSbK2Fb2cBj2sjbq l9PTSomA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mdsW4-00DruN-8E; Fri, 22 Oct 2021 11:15:29 +0000 Date: Fri, 22 Oct 2021 12:15:16 +0100 From: Matthew Wilcox To: Andrea Righi Cc: Andrew Morton , Yang Shi , Minchan Kim , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: fix sleeping copy_huge_page called from atomic context Message-ID: References: <20211022074619.57355-1-andrea.righi@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211022074619.57355-1-andrea.righi@canonical.com> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: AE76B5085E2F X-Stat-Signature: 77nrw7g16xheaee9pfe7eie8hxsfmbof Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YGQJcluz; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1634901403-732415 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: On Fri, Oct 22, 2021 at 09:46:19AM +0200, Andrea Righi wrote: > copy_huge_page() can be called with mapping->private_lock held from > __buffer_migrate_page() -> migrate_page_copy(), so it is not safe to > do a cond_resched() in this context. > > Introduce migrate_page_copy_nowait() and copy_huge_page_nowait() > variants that can be used from an atomic context. I think this is a consequence of THPs being created when they should not be. This is the wrong way to fix this problem; and I suspect it may already be fixed at least in -mm. We should have taken this path: if (!page_has_buffers(page)) return migrate_page(mapping, newpage, page, mode); but since we didn't, we can infer that there's a THP which has buffers (this should never occur). It's the same root cause as the invalidatepage problem, just with a very different signature.