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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAEE8C6FD20 for ; Fri, 24 Mar 2023 13:43:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24648900004; Fri, 24 Mar 2023 09:43:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F681900003; Fri, 24 Mar 2023 09:43:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C32F900004; Fri, 24 Mar 2023 09:43:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id ED2F7900003 for ; Fri, 24 Mar 2023 09:43:25 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CB98FA0961 for ; Fri, 24 Mar 2023 13:43:25 +0000 (UTC) X-FDA: 80603908770.28.3D6BD5C Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 0B88516000D for ; Fri, 24 Mar 2023 13:43:22 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b="Up80v/qu"; dmarc=none; spf=pass (imf08.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.177 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679665403; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hoPSMDIKswenyKMLwakUVFyLrEYZv6ETqG+RWnAbawk=; b=p00AIQAhCJfscDtSc8YytA1bi4gOfsB0PxZXZjTjfii6VZVIkWBjr+WQhGNBEf6VPU9s/p h/NffRQV+vJ/pCUTg5gfUeFAgr1FFd08HXNT7zz1lPvgL368kO03Y859g2n5HOHkMKIHPk NG0nK2mR7FMEhrgaO8/Ctys1hRUO4x8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b="Up80v/qu"; dmarc=none; spf=pass (imf08.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.177 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679665403; a=rsa-sha256; cv=none; b=hyrFK9k/8EKynOdrGLGM4afImAu0WGy6OlrI5uoeIH9CEcf80NP98IgJRsZlqmsPqfLWgF p5ZIaTwKLis1486Rs5NLgz6EQsUs/tK6U/2aji/9oifazBKKCgugEtA0qtyxsroebxxMKz G870i2gSqmcMbwb9RPtVOBZiVIWm250= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-544787916d9so32980147b3.13 for ; Fri, 24 Mar 2023 06:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1679665402; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hoPSMDIKswenyKMLwakUVFyLrEYZv6ETqG+RWnAbawk=; b=Up80v/qu76RAS29JlQYjbyxodFQPEq4RgpkxG2vG52kPHsVqjqEpesF/PkSR/iMNmF OVeP3AQNPJt747+mSR0WCC6pSxadZAn1NAALXCP3icqEyguIsfP4XdubLYmP60NYjYqo EZNJQz4OIXq3tWUHgP6cK4CphHRjKU5ccvZh8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679665402; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hoPSMDIKswenyKMLwakUVFyLrEYZv6ETqG+RWnAbawk=; b=657wgbe265kHyCiqLchWOsjtVacYf4L4bmuyUwRCctjCwX3eG5b3hSTzt1AF88yl0Z er8+g06E6AMhF76Re7pkb2y7HgpjfTQr35Zj5lhWEb26g94mnoMRu4SHh205BXs5VVtR SUpv50W/1AWErlqeDzsxwDLCM8xj42NleGpB2i5FBzIOmqPpBBn9ArlW0t+boZ4MHtLK G/O89fnVtdqeMjJNFSCEr+XbdrPO08oyrO+pSeyB5HwetFOgwIz8Q4xhepi/OBYlTqHH F+gSQTwFbYEXpEgT+XzWmYcIjmt+qk+ghnXpVIbhuNwkqN5JHRa3E4OLDAAd9cTtgobK VgwA== X-Gm-Message-State: AAQBX9dEO0U0I/Voz8ulF5h0K+vqdAs0xubKZhZ7InSnLfGUNZxwjsnq pa32vi6fqmdUvSkggZwwfq8R+YArGRqc5+oxwMkl1g== X-Google-Smtp-Source: AKy350YSl5ZKGqZtN91bQxYTVOy+Bl+W5kNTIeP/6xLDFMyOg8AWlTHv1+SDvKIJfn924kgfwoKzeTc0nI9z9/rGXPA= X-Received: by 2002:a81:a709:0:b0:545:4133:fc40 with SMTP id e9-20020a81a709000000b005454133fc40mr1065593ywh.9.1679665401960; Fri, 24 Mar 2023 06:43:21 -0700 (PDT) MIME-Version: 1.0 References: <20230324130530.xsmqcxapy4j2aaik@box.shutemov.name> In-Reply-To: <20230324130530.xsmqcxapy4j2aaik@box.shutemov.name> From: Joel Fernandes Date: Fri, 24 Mar 2023 09:43:10 -0400 Message-ID: Subject: Re: WARN_ON in move_normal_pmd To: "Kirill A. Shutemov" Cc: Michal Hocko , Linus Torvalds , Naresh Kamboju , Andrew Morton , linux-mm@kvack.org, LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0B88516000D X-Stat-Signature: uyz4wfmhp4xizmocq3793ot587cwxm54 X-HE-Tag: 1679665402-547156 X-HE-Meta: U2FsdGVkX1/CESATXBDDHYxhJKUDwq+IZYrK/6SIOoRYmahvJCZrbnxzttjs+CqtNR5daqJzx5m7pVNCy53NS1bl7K6U6aqw6PXAZxIiHvHbMxvObCXQ1l5t1mcbdD9kHmgDEXfDo5wNlvZZ9tqf7ri9pJPRxmCthi6tfHEWoI0diDvFygeFSu7+5yvkoJr+ELlLFFpXxjk1jhceQEysSAwx3OrnIZp3yf8NQ0wWvxgsHTOhjTtTvjq9aQUBZvFOKAAg5ffEQyplJPsr1R/WMY0XSd/UENBsXCsW2gb19I1+5P1554ry8nU37lDxAgfQ+3zVx+0GI26Jeuos+cOrX6hj0lNV3nR6xLKVRqM07/Vy5dZJE41sVqgiX1uvdPkjebAt3k/3r0zE6vurGhuK9jsL4oXX6Ox9bLNWUpx77PGVIxItVb+xgj7hChOeRvSK351PYXkqBF9NsTkFiApTS+o207wpay+Gq2OgQU6pg49tLPxRZhqnz0OSRlzyCFdvsQYdL4jHn/GDchLVWeohakmxXWoTzjl6sAl4uE7H1oaEPLURopZTBv51bq7t78V8cKp+WgTcrJq0ohLdwAGbihR1ti/8pBILVH+l5WeGoG3aYFY+hMcMhDV/pQe833yzeoUcadFKYVj6hDX23ZqtSp8Sk4SNC19hmzv7ucWh0Nu8M1b4oKQQiO44uHeuJ2O/dAzNYV5vDsz6OMKj6Bpt7JptVUfxCPNdJ4evZkeglT3/VP8Dp5E/3yyTSySH/WaKDsaJnd8t2n8AoBbyxyVwElVsBcheWNqlc43r1sCCTHCecrXnGLckehsmFzDR6YodL858DrZNVrfD44cP/zmUtvyxbp9j6wHrciW1bKILGvGM7gs/QQeU7tmrgZR5vAq9IPzGS0EUKqrnKxA8azCG3voXOieyIaJ7gG1PHd0VvaQCNphmnQcQLzskkf2B8quCw6YzpHbSpj0dgWgTjPB 08j+TA0J 9r/Dt/3pfguGzmvQq01tFrYvSAHHUukBP+UQp2pxL2VnPZVrlhV5e+BptdDTg5v0x8dxQMxol3VkcapQwkXrGIBAUunUs4046aU4tEs8oo+qsagzZYK1IyL7gAYI8tnSfzwTSUg6CBPvTfLjX1XolTYAGtnIBpwcm02Pyw5DqIfTQKUEDSzFcCqZtf8O9nzvqCp20QT3iKnLZswPktj4BMMknnCwIZqJGyLA0vJvrUlSYmRr3nnUws6UtTqaswCL6qaSvOItpoI7qWmxaGLxAJMaXb3TyvTKT5u0ajVCBoWt6JvduHRRWeGbbqM0ARH/Vopfh86PVEdBokO3Sm6zuu0Ywk4gCR9A4sTW8xsZGAlTGLbLC+642gUoF+73G3y6yu4ZZF6djsB04/UA4vdrlGyiwsQ== 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, Mar 24, 2023 at 9:05=E2=80=AFAM Kirill A. Shutemov wrote: > > On Fri, Mar 24, 2023 at 12:15:24PM +0100, Michal Hocko wrote: > > Hi, > > our QA is regularly hitting > > [ 544.198822][T20518] WARNING: CPU: 1 PID: 20518 at ../mm/mremap.c:255= move_pgt_entry+0x4c6/0x510 > > triggered by thp01 LTP test. This has been brought up in the past and > > resulted in f81fdd0c4ab7 ("mm: document warning in move_normal_pmd() an= d > > make it warn only once"). While it is good that the underlying problem > > is understood, it doesn't seem there is enough interest to fix it > > properly. Which is fair but I am wondering whether the WARN_ON gives > > us anything here. > > > > Our QA process collects all unexpected side effects of tests and a WARN= * > > in the log is certainly one of those. This trigger bugs which are mostl= y > > ignored as there is no upstream fix for them. This alone is nothing > > really critical but there are workloads which do run with panic on warn > > configured and this issue would put the system down which is unnecessar= y > > IMHO. Would it be sufficient to replace the WARN_ON_ONCE by > > pr_warn_once? > > What about relaxing the check to exclude temporary stack from the WARN > condition: > > diff --git a/mm/mremap.c b/mm/mremap.c > index 411a85682b58..eb0778b9d645 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -247,15 +247,12 @@ static bool move_normal_pmd(struct vm_area_struct *= vma, unsigned long old_addr, > * of any 4kB pages, but still there) PMD in the page table > * tree. > * > - * Warn on it once - because we really should try to figure > - * out how to do this better - but then say "I won't move > - * this pmd". > - * > - * One alternative might be to just unmap the target pmd at > - * this point, and verify that it really is empty. We'll see. > + * Warn on it once unless it is initial (temporary) stack. > */ > - if (WARN_ON_ONCE(!pmd_none(*new_pmd))) > + if (!pmd_none(*new_pmd)) { > + WARN_ON_ONCE(!vma_is_temporary_stack(vma)); > return false; > + } Wouldn't it be better to instead fix it from the caller side? Like making it non-overlapping. Reading some old threads, I had tried to fix it [1] along these lines but Linus was rightfully concerned about that fix [2]. Maybe we can revisit and fix it properly this time. Personally I feel the safest thing to do is to not do a non-overlapping mremap and get rid of the warning. Or is there a better way like unmapping the target from the caller side first, before the move? Michal, would you also mind providing the full stack you are seeing just so we know it is the same issue (i.e. triggered via exec)? thanks, - Joel [1] https://lore.kernel.org/lkml/20200712215041.GA3644504@google.com/ [2] https://lore.kernel.org/lkml/CAHk-=3DwhxP0Gj70pJN5R7Qec4qjrGr+G9Ex7FJi7= =3D_fPcdQ2ocQ@mail.gmail.com/