Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5540586pxb; Wed, 26 Jan 2022 14:32:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxd5AMJXzs+OLz8uzScvoXmLL36gmJ1X4mRfMHE7xJWyiRVHci/0u/ATyMTq+4nIRq3s62x X-Received: by 2002:a17:907:d0d:: with SMTP id gn13mr757714ejc.266.1643236377730; Wed, 26 Jan 2022 14:32:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643236377; cv=none; d=google.com; s=arc-20160816; b=06/bnqV8V9ztW32Jzu/Ex6kMNbXXEhC6LsanZHXQeEXWQSZ0SEUperKX6+zj8UaEs+ mg1yuaiqkIIZ4+btjEXegGDTcp8+9tKEWkPAU0DMr79OI8KdzDCn8x8cYbRHeSVa6nxN GHl7cekl8IP8PMIRMmlCZUyNh/zMmTxrfYd4tL/YBibQ8yFLFr2V7v090NzeVlFgue0n 8TcjuD3NqOd+ScswQ54bKNDRfAJzDAnsS/Vp0q4qzb23hvSQs0Lc2KMPt+YNjKi/F7iL +7o0afO+qQJuX9brjgu8XCpS/i3nUhV8PSpGYnwjRoHIdEEI1kvpjJQIivtxb7Kgs0tw Y2tQ== 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=RpL+rxhAhlZQJ9/uSU/qLylpB6hdYn8xv5qg2QKDxL0=; b=FXPQmSRPpWYWWc6VaFmhjOXZySp2M8r+Jg1bUFHDO4Qsz1b/4R0EbwN+/BDNeOpVip RRJ1kXClJK9rXayzDs71UGA6WCpe2RKpl253ZCtpLcCGTDAG9YwZZ8m/oKtrAB+deCgO tCB1joCkdN+iWjkImWDsVp5PCaQuOjczVruBm21jIWWmHS7VkZjwOZX8gvuXgKARdIiY VZ3yrOHFhyttsPnhek0LSaCXx1JEZ3tCVUwocLzfILq9+EzS/EF4DCa9ohkNfrbh0jW0 b/M9bdytrK2zvlHY0uJBHiB4YiAMMPCZtCvABJtReakPYNvKqrsP3zCw8UUpdJiraIWv 2SFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=i5kUzxOG; 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 hq13si311784ejc.651.2022.01.26.14.32.32; Wed, 26 Jan 2022 14:32:57 -0800 (PST) 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=@infradead.org header.s=casper.20170209 header.b=i5kUzxOG; 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 S243262AbiAZS7Z (ORCPT + 99 others); Wed, 26 Jan 2022 13:59:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230349AbiAZS7V (ORCPT ); Wed, 26 Jan 2022 13:59:21 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56F2EC06161C; Wed, 26 Jan 2022 10:59:21 -0800 (PST) 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=RpL+rxhAhlZQJ9/uSU/qLylpB6hdYn8xv5qg2QKDxL0=; b=i5kUzxOGZ4MkbrV0H9kNy8JeC8 eJ6XSbef0LQFUFaxdLeZOeHLtOiEjMQCzGtWkMAj4YduJF7cxoOS6SgQqWDGgFlYgQGxliaQRKdvX TNkjIgZclQ6binDZ8OIBlI670KSAEglYme75yekdyiSm55Ws3NtiyRuUksSs4hR8Qgkx2qvxVetNd aBdU9f1IX4PAc2ymQNrJ8fnO7QTjA56nd3r9fN3BPP8hvnbImC9UpuKTWqVPd93JXWSLuEdvMwmW5 PKIgMDv+UORATCAvgLBbZlZH/c7L3y06XHeyL+4WlWoCl8GEYmXP1liMmJ+DZXhdyYca5WCgl2JPr KAYLXe2g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCnVf-004LUW-CH; Wed, 26 Jan 2022 18:59:11 +0000 Date: Wed, 26 Jan 2022 18:59:11 +0000 From: Matthew Wilcox To: Pasha Tatashin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-m68k@lists.linux-m68k.org, anshuman.khandual@arm.com, akpm@linux-foundation.org, william.kucharski@oracle.com, mike.kravetz@oracle.com, vbabka@suse.cz, geert@linux-m68k.org, schmitzmic@gmail.com, rostedt@goodmis.org, mingo@redhat.com, hannes@cmpxchg.org, guro@fb.com, songmuchun@bytedance.com, weixugc@google.com, gthelen@google.com, rientjes@google.com, pjt@google.com, hughd@google.com Subject: Re: [PATCH v3 1/9] mm: add overflow and underflow checks for page->_refcount Message-ID: References: <20220126183429.1840447-1-pasha.tatashin@soleen.com> <20220126183429.1840447-2-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126183429.1840447-2-pasha.tatashin@soleen.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 26, 2022 at 06:34:21PM +0000, Pasha Tatashin wrote: > The problems with page->_refcount are hard to debug, because usually > when they are detected, the damage has occurred a long time ago. Yet, > the problems with invalid page refcount may be catastrophic and lead to > memory corruptions. > > Reduce the scope of when the _refcount problems manifest themselves by > adding checks for underflows and overflows into functions that modify > _refcount. If you're chasing a bug like this, presumably you turn on page tracepoints. So could we reduce the cost of this by putting the VM_BUG_ON_PAGE parts into __page_ref_mod() et al? Yes, we'd need to change the arguments to those functions to pass in old & new, but that should be a cheap change compared to embedding the VM_BUG_ON_PAGE. > static inline void page_ref_add(struct page *page, int nr) > { > - atomic_add(nr, &page->_refcount); > + int old_val = atomic_fetch_add(nr, &page->_refcount); > + int new_val = old_val + nr; > + > + VM_BUG_ON_PAGE((unsigned int)new_val < (unsigned int)old_val, page); > if (page_ref_tracepoint_active(page_ref_mod)) > __page_ref_mod(page, nr); > }