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=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 9EC6BC76188 for ; Fri, 19 Jul 2019 03:43:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6201421851 for ; Fri, 19 Jul 2019 03:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563507803; bh=HrhZEcSQN51KrMKglwqRrsI7E3xr0hfIM76XucbZx14=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=HD+rbtJixCFKebLTJqXGPWbEe5tkUBQo4taJNXgnEOTHjqljgkmPKWmEdtOIkpd2z XvR1dGny+qbz+1Q0HrDMB+VYgY0MhEMsSfDeYYIlZt158TaJqbYuCaglDAzSvNzAvv egB8WGb+NtWQebbyhTGM/ozcVPfhfXHYsWk/nOlI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726067AbfGSDnW (ORCPT ); Thu, 18 Jul 2019 23:43:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:53956 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbfGSDnW (ORCPT ); Thu, 18 Jul 2019 23:43:22 -0400 Received: from localhost (p91006-ipngnfx01marunouchi.tokyo.ocn.ne.jp [153.156.43.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C959F2184E; Fri, 19 Jul 2019 03:43:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563507801; bh=HrhZEcSQN51KrMKglwqRrsI7E3xr0hfIM76XucbZx14=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ONSgg6eG0qjUubfHx/upW/n7ZzF0rISIrx3M1JZezpE4qOCH/Lf0l4vUANH5zTV3j H6KAhSFBU/qvFzAJbfVnIEgME7//1ByAI1I8+SiwNAKmx+FmrLmO8pPulV3xNHJvUy Cezf9XIDjEsLNGSrrF/1dS85E8+n7shWLJfyruHU= Date: Fri, 19 Jul 2019 12:43:18 +0900 From: Greg KH To: Dan Williams Cc: Liu Bo , stable , Linux MM , linux-fsdevel , Jan Kara , Matthew Wilcox , Peng Tao , Sasha Levin Subject: Re: [PATCH] mm: fix livelock caused by iterating multi order entry Message-ID: <20190719034318.GA7886@kroah.com> References: <1563495160-25647-1-git-send-email-bo.liu@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Jul 18, 2019 at 07:53:42PM -0700, Dan Williams wrote: > [ add Sasha for -stable advice ] > > On Thu, Jul 18, 2019 at 5:13 PM Liu Bo wrote: > > > > The livelock can be triggerred in the following pattern, > > > > while (index < end && pagevec_lookup_entries(&pvec, mapping, index, > > min(end - index, (pgoff_t)PAGEVEC_SIZE), > > indices)) { > > ... > > for (i = 0; i < pagevec_count(&pvec); i++) { > > index = indices[i]; > > ... > > } > > index++; /* BUG */ > > } > > > > multi order exceptional entry is not specially considered in > > invalidate_inode_pages2_range() and it ended up with a livelock because > > both index 0 and index 1 finds the same pmd, but this pmd is binded to > > index 0, so index is set to 0 again. > > > > This introduces a helper to take the pmd entry's length into account when > > deciding the next index. > > > > Note that there're other users of the above pattern which doesn't need to > > fix, > > > > - dax_layout_busy_page > > It's been fixed in commit d7782145e1ad > > ("filesystem-dax: Fix dax_layout_busy_page() livelock") > > > > - truncate_inode_pages_range > > This won't loop forever since the exceptional entries are immediately > > removed from radix tree after the search. > > > > Fixes: 642261a ("dax: add struct iomap based DAX PMD support") > > Cc: since 4.9 to 4.19 > > Signed-off-by: Liu Bo > > --- > > > > The problem is gone after commit f280bf092d48 ("page cache: Convert > > find_get_entries to XArray"), but since xarray seems too new to backport > > to 4.19, I made this fix based on radix tree implementation. > > I think in this situation, since mainline does not need this change > and the bug has been buried under a major refactoring, is to send a > backport directly against the v4.19 kernel. Include notes about how it > replaces the fix that was inadvertently contained in f280bf092d48 > ("page cache: Convert find_get_entries to XArray"). Do you have a test > case that you can include in the changelog? Yes, I need a _TON_ of documentation, and signed off by from all of the developers involved in this part of the kernel, before I can take this not-in-mainline patch. thanks, greg k-h