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 9FE6AEEAA6E for ; Thu, 14 Sep 2023 20:01:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C83CA6B028F; Thu, 14 Sep 2023 16:01:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C33916B02B4; Thu, 14 Sep 2023 16:01:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFB706B02C8; Thu, 14 Sep 2023 16:01:02 -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 A05186B028F for ; Thu, 14 Sep 2023 16:01:02 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 67517B3E1C for ; Thu, 14 Sep 2023 20:01:02 +0000 (UTC) X-FDA: 81236271564.28.75EA749 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) by imf07.hostedemail.com (Postfix) with ESMTP id 48C4940022 for ; Thu, 14 Sep 2023 20:00:59 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2qGyX0p5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.210.54 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694721659; 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=Lb/CMKCE21GbjlUYU65iP3ZBpMrzy3WpMR7I9tPJHKc=; b=dYoqVAlpBfbUdJPU99Vmi+c83bTmGLa4t3Iew4mqs1tmTEggO2X4ou/YBd9+pD4VBQVRoS 9WbSLS19Kqfqnbkm/e6wXpNin+pK5o5QLrhhHPPKu40eG8RBDLOvX9+MlYI7y8DsCsEGEZ hCISpwIKohr3yiyDMWMw0FColouGHNQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2qGyX0p5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.210.54 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694721659; a=rsa-sha256; cv=none; b=cJA2pdZ5qYNlu/bmc2eLMJC73M0ubobXUekoc8msBg9/+PFyb9PaQJxmiLubDKsvg1AyFu Kiy/JuvCgcEhioou+eEMXuAhjA8TIoIrhMsi9ucs+hXFj3stlm56giU9F03zG/s1vh2ifk ab1up4KtAP2OyWZXB2V9w5iVED+wdqQ= Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-6c0b8f42409so752333a34.0 for ; Thu, 14 Sep 2023 13:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694721658; x=1695326458; darn=kvack.org; 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=Lb/CMKCE21GbjlUYU65iP3ZBpMrzy3WpMR7I9tPJHKc=; b=2qGyX0p5SIvVZaPgmjh+IXqX1vlT7s+No7Ud1/n7MoWN3dqk5lnpKh35ueIRDdTJZQ s2zwA5iJFbuKFoM24IfbaB/m2XACe5N6YPCQZYntVaFUw0OuvSdE4FN5iIDYMgGIOLKK oeGLQ+nENYMWkHyS8nVpuY6MsrXqIO6ukK7eUwF0LyhXILDpuzNWPlHmVaIRE5lH8YCW i4d0cDZf3mOh9b1QHpx0K4Nu1oWv7yoi7sn2ae2TvapmyR+yz09EQwTyQtYbEOPsrqqA Ui08cm66M/b5psiEjgnsUFbdbhtqX+5vZj87i5z3VDz18LXslBPaFIucWhsraAD/I+NN 0F6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694721658; x=1695326458; 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=Lb/CMKCE21GbjlUYU65iP3ZBpMrzy3WpMR7I9tPJHKc=; b=m5hHtdERrtQtlRnG172tELcF/Os+K618yEo1TjNHiYlVi1vj/DTijAd/tWI2vYfHH9 z8vp4a48kqsoV2Cj2louWUfNpXAAkmWQJ0T8Ys1J6HHX4Vor9dH8QLZhrsdmgkj242pL 0tSeOlj2r9zzgpPcvu3fTn7izsLzGfhd8OEULviyS5PW0fjBXJOkPJTN/UgutgTpzKca dYneZtqDikgY/lczsB/rJSIhnMJEar25GMcsQMvtPiTcRuoD8LVRnjuB3dex+c5OrkYo WrGUI721j8ZdI/JWkWz25+od83nvgxFJzUqJJFmG+wXzFN6z0yJzxtT36oAtEtDVm1xE vhVQ== X-Gm-Message-State: AOJu0YxryQM9npqN1EKClUQk+EhGxTR3NqCWGBvW4cslWYWp7rF5+ano JrSTDjjPRSYeEQyTa+PhJDDGSeN0oS1kocuU0pPDWQ== X-Google-Smtp-Source: AGHT+IHvfdYyltmAKPaJ3EMcnOv2Vgsan85cKtIyJ3zr2EyhbA9TT5S7py2VsiSTfs0auAsW5sUHMOUITwApT2T6FAo= X-Received: by 2002:a05:6830:195:b0:6b9:bf1e:c141 with SMTP id q21-20020a056830019500b006b9bf1ec141mr6884165ota.23.1694721658164; Thu, 14 Sep 2023 13:00:58 -0700 (PDT) MIME-Version: 1.0 References: <000000000000f392a60604a65085@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 14 Sep 2023 20:00:45 +0000 Message-ID: Subject: Re: [syzbot] [mm?] kernel BUG in vma_replace_policy To: Matthew Wilcox Cc: syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48C4940022 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 99xsxr74qyb8wgmed3sawbgra9w5qfii X-HE-Tag: 1694721659-815029 X-HE-Meta: U2FsdGVkX1/CEjgvKNvuPw7LrQi1C0P/LA1xompBQW3mA5qGmlRda9cmZS78HUtExB1L3p32FmyXJSg1AuzgMPHTPaWfxri1oekx0N8ff36jLTNU15GpnFjRsqUDwKaRM7w7WfVQ4Xn3NlpUI4fJsSzStXN/VGp7vIUXFqNbR8HVnS+JyK18ZhPc8iFpeinb8QOMXPW2jgxOX8zgg810PeoT7HNfm7tlhdI5UaUVLrF/5wdkmI2kjYc/TDZRhD2bg4IsRgIy3JpyqfubxonjLTzo7zPdAn39TrnEcyjsWLglnUsL9ecJvevnTO+WvrTYcEHpfyOoGD0sFeVDedOAbqAKkz+insS8vajsQjKOm038fRe56svKIBUQ3FTAYhDu5sOiEXPVHqFKrMWjCgemoe0qZ9Bh57ef1KnLf788mafWOp2zFb9lvQetDUIwOLlws8dJy5O+xVtRNful9xx0JjBAOcaEXUrnb1LRz6JWIY8wWy+zXlRmduYzzn8ewNpflYLvHXw1XnSTSf0sI7Y7rtQOtLrsDnkveLkhI8m/01+Eis1ucpSGqHdGid+ezc7C135R4GpDfqqwBti8NdXdzjfEBwOb+rxcOE6xwPb0S+NFAuggK/hDkcpVE+DJ5M8G8tTLq8chaXDMcxl4OeKyrXbhtWcn4BURqS0W93SzEwN9lgiPBiGo0zNqiI4cPl8/fbnPYmBtu9LgJRfSqsXzZ6WO36+9Hh99u7m8uRt9h1P1MUAVpw1SehFOq2LE0HsG/+fTrJaoyAp/wYetrTyQ2Bfpum3lMrk8bKPTS3WPPwL3hQ5TS4TqAqA3y3I20cBvWu48isnWsuT9qONgSXAzlWDSOA1Zyp9PpnXoNMMNB87YSd2dX6kJZyQ/ywTii64fo+Gwsl2WYTazO+oGkAFDPSCAwa5M3vyqj4qxpHPWQp+jvj1vQGNnGXf1V5DaC2e1R2Fhdle9EyVDwk1SUZi s8+VlnWm Yruq3u+hBrwiQ7BBYi9bZjt7JOhIgrof7LOZzF0a6iXIk+s6nn7u9bpARTTfykVgJDVAt1F64O2NbVVagnVc75UuonE9HBTXyD0T/ssX1EinI3+xraJQBfxazYuEZaPhKYUzKmCNGIR/DdeGErEF8BxyA91V8cyinBIUeHe4bqkdqgFj8HX9TXScYEIOlmAnAdyzD6ETLJC2hjDZ/zpq6M3i//eGM1tUsH4WF3buPk1P+M0feph4hGFzti0udO4k26o2vTgomoHrqG94g68WM4fHR6QlD1UFHG4+S6WRgjUj6fLsg2a1/OqHMXocgBwIXl2C/KLkJIsxj/DyC9dOLdjOtqF998dgnWpHaUZSOG+XlTUERDx8FwrDqjJRgTaWoG5mBK0aqHfxErK/e1mJGmKiIYkFt0NwQEkCi+Y20w/l994KTEA5Fl98MBFKfEGa2cQsqbclvjqVPtK5QXrG35eJcNg== 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 Thu, Sep 14, 2023 at 7:09=E2=80=AFPM Matthew Wilcox wrote: > > On Thu, Sep 14, 2023 at 06:20:56PM +0000, Suren Baghdasaryan wrote: > > I think I found the problem and the explanation is much simpler. While > > walking the page range, queue_folios_pte_range() encounters an > > unmovable page and queue_folios_pte_range() returns 1. That causes a > > break from the loop inside walk_page_range() and no more VMAs get > > locked. After that the loop calling mbind_range() walks over all VMAs, > > even the ones which were skipped by queue_folios_pte_range() and that > > causes this BUG assertion. > > > > Thinking what's the right way to handle this situation (what's the > > expected behavior here)... > > I think the safest way would be to modify walk_page_range() and make > > it continue calling process_vma_walk_lock() for all VMAs in the range > > even when __walk_page_range() returns a positive err. Any objection or > > alternative suggestions? > > So we only return 1 here if MPOL_MF_MOVE* & MPOL_MF_STRICT were > specified. That means we're going to return an error, no matter what, > and there's no point in calling mbind_range(). Right? > > +++ b/mm/mempolicy.c > @@ -1334,6 +1334,8 @@ static long do_mbind(unsigned long start, unsigned = long len, > ret =3D queue_pages_range(mm, start, end, nmask, > flags | MPOL_MF_INVERT, &pagelist, true); > > + if (ret =3D=3D 1) > + ret =3D -EIO; > if (ret < 0) { > err =3D ret; > goto up_out; > > (I don't really understand this code, so it can't be this simple, can > it? Why don't we just return -EIO from queue_folios_pte_range() if > this is the right answer?) Yeah, I'm trying to understand the expected behavior of this function to make sure we are not missing anything. I tried a simple fix that I suggested in my previous email and it works but I want to understand a bit more about this function's logic before posting the fix.