Received: by 10.223.185.116 with SMTP id b49csp7496948wrg; Thu, 1 Mar 2018 06:31:31 -0800 (PST) X-Google-Smtp-Source: AG47ELs0xsyGpFXdhqEXZRF8AoHBv8FKlJbB8PPqTUXN2yrwU1c3yV+Yhq5lbf2hJAxTPUn1P1+p X-Received: by 2002:a17:902:b2c6:: with SMTP id x6-v6mr2075517plw.285.1519914691569; Thu, 01 Mar 2018 06:31:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519914691; cv=none; d=google.com; s=arc-20160816; b=ObnpdgruC3o2eeFz9Ujq70ucb0/72ghEi7314DjQFxYuxIeE47qo2klxNF+pzT8lIv P/bx8QzYjcOjMrBcBoYNAIPKCKS2Uw5iwKlNeAuOI0H9OXoD2egur5zxVJlrBZaw6ENX oB6IqqtVcU5EcS+wlAGedKEX32i5qlglh+1G70Oq+59wpehJwJqUCAJbuJRL/88SD2oD UPLsKfDJ/PKP0q4Wl9SZMZHFMxBFuSxE2LpOrKBDnRrPBm0/eBaMOC+OhEGbhgt4X3UI 7tY9zzwEsXcbL+atNoVfOI4ELzrc2g6Ph0uWz90M8eqz1WxncIex0x5iTB2eZA1jdQ4o LNdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=BWkCLrAhWXHGvbXEb+LuRpJgr2hggY/32jL4eGUNUps=; b=NLnbzvmjzz0SEg12POJN8qceqx1ezA2yzkCnzn5scmDrxa7rpDWEtA7jwseRfUmB4R XJGAvCiNZkms3PekfiEOZXpAz6xBYiHrWsbBqAjK1r5TW64be/da4UIUTlUKhjtckPMT 94Ul9ASjI28L4BBnVlSApV9V4wpeRY5znGljCJkTSCe2C75qYLKlF76caGaXEO4w02zQ 3WtC3HHMW4ANabH7rVAyWpdAoPvQjrSeu36vmDjHuDuP2S3FVChwNZikYhBiT5Ad5m0I EMfkZ0cFNVhFBVKIcY3EnfLArfE1K6QRqnQ6VYkr6/PorWS+/4uowCjxPtBPWQe0QcPW Ua0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=SuO7/b36; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 61-v6si3145684plz.507.2018.03.01.06.31.14; Thu, 01 Mar 2018 06:31:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=SuO7/b36; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031575AbeCAO3K (ORCPT + 99 others); Thu, 1 Mar 2018 09:29:10 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:51807 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031397AbeCAO3H (ORCPT ); Thu, 1 Mar 2018 09:29:07 -0500 Received: by mail-wm0-f68.google.com with SMTP id h21so12196398wmd.1 for ; Thu, 01 Mar 2018 06:29:07 -0800 (PST) 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:user-agent; bh=BWkCLrAhWXHGvbXEb+LuRpJgr2hggY/32jL4eGUNUps=; b=SuO7/b36TZxNyV1t+/ZySzmAYpq4eB+9XGtzOPctbJFgUJ5MjJ1Fp6G2bgnZTO5RUB VHt6hd9VJMbL4XaFLW9dZB52cgCMUB/cVhitGjh1UKLBuKd/tBzHDfOU8IxcrVcTQ7Rv 8If4a9zCokj0QRLUqdSGGgfAZnrYrT/nsLkOMbcTB5i0a1ijw2e+twCduaTWDZU/gxqa 9cSvtwHj53/ylGTk7fWbMor3sKzW3SvzXkwfRuyloOyr3wsFNcD8J+6WjmetMuW17QzG 59PxJVyhvQGNO+1zrCb422RuA5uj7D/v72/jaFpuLPU3cfUtKhC/y0HcIeXWMxbw8LXn YkPg== 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:user-agent; bh=BWkCLrAhWXHGvbXEb+LuRpJgr2hggY/32jL4eGUNUps=; b=qDEia5f2dy4Gibl2tJEB5mICihQHO9qUuA0YIRfdJZIoE0UlHSCJj4aDxqB2GPbdad ky88LZf5WugRoQAbNCvBVqObPmO3m6Winvaf4oSWX1WYiZK16fesX7YcuJEsKhNPCrtv mILIrA9KVTzdLmpUgdnu7avZwM2PZGGC+OXvtSWAnQFv9qPz5hEJS9u5CP0xkcnBNxbF tcEzCnmhCZVKpG2ByJZjQjwg33M1VJ4EzzEYq6NL2JMK8m+7kL5mKYKRegQMcEd09/fa VaAB4CVz5qYxLzD4JdB+1Tasb0qXxQulsrQuxVQapwUbs28vyanh4lb8IiShd34Ez275 AYUg== X-Gm-Message-State: APf1xPDktLNvlGK/8H+EoanzBXOXgqv4xxrbM+STZILpp1wwplbVHDhk NW6HB+yoA5AxizT9/giFKTBhJ49a X-Received: by 10.80.240.94 with SMTP id u30mr3093699edl.276.1519914546572; Thu, 01 Mar 2018 06:29:06 -0800 (PST) Received: from node.shutemov.name ([178.121.199.127]) by smtp.gmail.com with ESMTPSA id g31sm3999893edd.44.2018.03.01.06.29.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 06:29:05 -0800 (PST) Received: by node.shutemov.name (Postfix, from userid 1000) id 50FB4648D520; Thu, 1 Mar 2018 17:28:55 +0300 (+03) Date: Thu, 1 Mar 2018 17:28:55 +0300 From: "Kirill A. Shutemov" To: Martin Schwidefsky Cc: Matthew Wilcox , linux-mm@kvack.org, Matthew Wilcox , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/4] s390: Use _refcount for pgtables Message-ID: <20180301142855.emaa5x65oj2hkwsm@node.shutemov.name> References: <20180228223157.9281-1-willy@infradead.org> <20180228223157.9281-2-willy@infradead.org> <20180301125310.jx6c5dypk5axrmum@node.shutemov.name> <20180301150420.19a14fd3@mschwideX1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180301150420.19a14fd3@mschwideX1> User-Agent: NeoMutt/20180223 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 01, 2018 at 03:04:20PM +0100, Martin Schwidefsky wrote: > On Thu, 1 Mar 2018 15:53:10 +0300 > "Kirill A. Shutemov" wrote: > > > On Wed, Feb 28, 2018 at 02:31:54PM -0800, Matthew Wilcox wrote: > > > From: Matthew Wilcox > > > > > > s390 borrows the storage used for _mapcount in struct page in order to > > > account whether the bottom or top half is being used for 2kB page > > > tables. I want to use that for something else, so use the top byte of > > > _refcount instead of the bottom byte of _mapcount. _refcount may > > > temporarily be incremented by other CPUs that see a stale pointer to > > > this page in the page cache, but each CPU can only increment it by one, > > > and there are no systems with 2^24 CPUs today, so they will not change > > > the upper byte of _refcount. We do have to be a little careful not to > > > lose any of their writes (as they will subsequently decrement the > > > counter). > > > > Hm. I'm more worried about false-negative put_page_testzero(). > > Are you sure it won't lead to leaks. I cannot say from the code changes. > > > > And for page-table pages should have planty space in other fields. > > IIRC page->mapping is unused there. > > 2^^24 put_page_testzero calls for page table pages? I don't think so. No, I mean oposite: we don't free the page when we should. 2^24 is not zero and page won't be freed if the acctual refcount (without the flag in upper bits) drops to zero. -- Kirill A. Shutemov