Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1221207pxj; Fri, 4 Jun 2021 08:56:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaWfC0pQf5kQOTZSNDOX7geKvm8DBncdnzkEpFXspMiDOv8QxxZTXnxuPq9DKaopFdiWBz X-Received: by 2002:a05:6402:3546:: with SMTP id f6mr5235771edd.191.1622822174052; Fri, 04 Jun 2021 08:56:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622822174; cv=none; d=google.com; s=arc-20160816; b=XfLL/yyyLQl2wSvvfTCUn7tSML8ffSPoIhwKhSte9t0EByhUZEBGPu474Cp9p4YlpU wMef389sB+twxXEAzL39cnN+aftioI5FYPfwZGFrbFbH0lDnOID0MgXQyH4FalCgqnmE uSCo2iHQPmLhg/VkR7AZX8joDvoW8lofyIX5EmPe3+KSw/Hb+d6YLLlwtZVVm6c0rjrP vipV74j/hW10ME3dytKJhkWXlVLfEiB7gogZY5uF4xOxFDYHz4ikx5uqeSbgzRMNpO89 MKgHPtax1HArCPicG0zP33aWWN0j6e/xXB4GUDkNeMSF/kt5JhepKi1GqUFi6ksUiUUM KqIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TnKirRT8gUEaS+Q1ln2ecqpD/vhYk0/SWSmMzyGGPnI=; b=W0Q3qqZM/g858yS2E5RCYDmUp2K5Yz0po5/0XZua2sG965jUfRlcLYk7C2FBUbEbUh CO+PSYszLYx+iY2M5/2o+0ZiP7EkUeNujOPRZ5fqnr4ggdp0TpsfEM5Dr+sF2g5qvAjN zNtXCDvcIbo1GwnhCEHq66es4+nkSepBOHp6YJm1TFHhyhkxRBo/QDeANLG2AB9ki7+1 mQvEu3BkJNCLDAaQeOVme9f4sx9MKhWLFUEmUjB0jtvIOxosQxFKdX5Ewsg22g0hPDJb bdY/QC6RorsGEcHOTKzzZtioopVM1GPKoljRKAuTzwYOJGxq8GJycP4nlM1ZYJ2WW6be E6+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Bx6EQYG0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b19si4908927edr.225.2021.06.04.08.55.50; Fri, 04 Jun 2021 08:56:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Bx6EQYG0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230467AbhFDPy7 (ORCPT + 99 others); Fri, 4 Jun 2021 11:54:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229809AbhFDPy7 (ORCPT ); Fri, 4 Jun 2021 11:54:59 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2569C061766 for ; Fri, 4 Jun 2021 08:53:12 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id r198so11448528lff.11 for ; Fri, 04 Jun 2021 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TnKirRT8gUEaS+Q1ln2ecqpD/vhYk0/SWSmMzyGGPnI=; b=Bx6EQYG0JsnQygCUhJjF4HE+jUEbqyPIRXPnHb3R5iPs3ls1JEjfMZSUnfaWTG12QQ ubC4QWKeQDhQf1j78hWZxDnVzH3CUGJEaCUaRAAFx1j10MaWeUdP157tggM5GfwRvZdy FIdREU/RcJW27IUalfqcRDkYxo8U0T+XJEoV6bN171QHk/9JeO38Ip8qguof4zeq45Ta 149/x1ok9HpP/xrRMcOPCZZYewCa+SqGTqqZsVCuvYwnaRx0bGbZRNmoeNBdC5Tq6xup o6q9TIh/cI5zfxZI0/2jrhTmtBnV1uZ+okgyqGqOLipGAitiAL+cKjbPy02qE7eVqhg9 P2tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TnKirRT8gUEaS+Q1ln2ecqpD/vhYk0/SWSmMzyGGPnI=; b=ojqrI3bSgNSkcQkjxUxF3q3HLi17pX092lA3R8Bpd0qIjCFYVOeSH72V6oSfaiA2n7 A4gf5uFx9jiQcrHcpqP4k1va4oIt1qgd3Rrs275fjJqYC3yzPG/B3JD5Cq5suraqziVk yfCn+NPCvTl87lDU1HRMZm9bLjFm9tjiT/cs7UMZKt5L5LXgUBsLVS7V8gHVMuUjxl3M 4lCN5U19PLjtkkOIu5knwCJ5SzllT4qqknUpjDqOn8cTEf3zT9VPmeOd+1QhazVa/R66 ieVooKCfq1MLaUPmiOhHzsMzgW7Ce+Hv8j3hOth0v0c7tW+7Ptn2F/LhUyf2uxd5cJA8 cCtQ== X-Gm-Message-State: AOAM532ysUMAG8fmLwooa9TAD1WkOXaKXALkF4qJh8aJu/xXx3iplVr8 ryNgjSv6uqEHVoLJLljHBtcG2A== X-Received: by 2002:ac2:519a:: with SMTP id u26mr3213934lfi.639.1622821991157; Fri, 04 Jun 2021 08:53:11 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id r22sm742329ljp.129.2021.06.04.08.53.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 08:53:10 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id EC1251027A9; Fri, 4 Jun 2021 18:53:22 +0300 (+03) Date: Fri, 4 Jun 2021 18:53:22 +0300 From: "Kirill A. Shutemov" To: Hugh Dickins Cc: Andrew Morton , Matthew Wilcox , "Kirill A. Shutemov" , Yang Shi , Wang Yugui , Naoya Horiguchi , Alistair Popple , Ralph Campbell , Zi Yan , Miaohe Lin , Minchan Kim , Jue Wang , Peter Xu , Jan Kara , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/7] mm/thp: fix vma_address() if virtual address below file offset Message-ID: <20210604155322.vl6wcen4fmngg27r@box.shutemov.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 03, 2021 at 02:40:30PM -0700, Hugh Dickins wrote: > Running certain tests with a DEBUG_VM kernel would crash within hours, > on the total_mapcount BUG() in split_huge_page_to_list(), while trying > to free up some memory by punching a hole in a shmem huge page: split's > try_to_unmap() was unable to find all the mappings of the page (which, > on a !DEBUG_VM kernel, would then keep the huge page pinned in memory). > > When that BUG() was changed to a WARN(), it would later crash on the > VM_BUG_ON_VMA(end < vma->vm_start || start >= vma->vm_end, vma) in > mm/internal.h:vma_address(), used by rmap_walk_file() for try_to_unmap(). > > vma_address() is usually correct, but there's a wraparound case when the > vm_start address is unusually low, but vm_pgoff not so low: vma_address() > chooses max(start, vma->vm_start), but that decides on the wrong address, > because start has become almost ULONG_MAX. > > Rewrite vma_address() to be more careful about vm_pgoff; move the > VM_BUG_ON_VMA() out of it, returning -EFAULT for errors, so that it can > be safely used from page_mapped_in_vma() and page_address_in_vma() too. > > Add vma_address_end() to apply similar care to end address calculation, > in page_vma_mapped_walk() and page_mkclean_one() and try_to_unmap_one(); > though it raises a question of whether callers would do better to supply > pvmw->end to page_vma_mapped_walk() - I chose not, for a smaller patch. > > An irritation is that their apparent generality breaks down on KSM pages, > which cannot be located by the page->index that page_to_pgoff() uses: as > 4b0ece6fa016 ("mm: migrate: fix remove_migration_pte() for ksm pages") > once discovered. I dithered over the best thing to do about that, and > have ended up with a VM_BUG_ON_PAGE(PageKsm) in both vma_address() and > vma_address_end(); though the only place in danger of using it on them > was try_to_unmap_one(). > > Sidenote: vma_address() and vma_address_end() now use compound_nr() on > a head page, instead of thp_size(): to make the right calculation on a > hugetlbfs page, whether or not THPs are configured. try_to_unmap() is > used on hugetlbfs pages, but perhaps the wrong calculation never mattered. > > Fixes: a8fa41ad2f6f ("mm, rmap: check all VMAs that PTE-mapped THP can be part of") > Signed-off-by: Hugh Dickins > Cc: Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov