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 3BF59C4332F for ; Thu, 26 May 2022 14:28:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB5248D0003; Thu, 26 May 2022 10:28:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3B5F8D0002; Thu, 26 May 2022 10:28:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D92C8D0003; Thu, 26 May 2022 10:28:54 -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 7A4448D0002 for ; Thu, 26 May 2022 10:28:54 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4A29820663 for ; Thu, 26 May 2022 14:28:54 +0000 (UTC) X-FDA: 79508125788.24.1147E81 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id F237218001B for ; Thu, 26 May 2022 14:28:49 +0000 (UTC) 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=k7apNoi1g1YhGHKMlKvo5ejDwWGQrfqPL3Ty5xTWm5Q=; b=jt2D3c7xgVZUKhGsBafhmm2sFE 7iHXpIRdAmkRqKCTrByt8vvIu4Y3EGktUCpnmPTFxq5LEtvIgLU7neTQ7C/IsI99LeEY7HaXKuYy7 5ZrEicxpMCl0i/enkPZwHxhNQ3wSCLz0PWMpopuxkJst9ua3Mey2ATEpeisJ/smtNzknhVcxsQdkT dSKtJhfNJpH19fcWEk13NeBfTP6RD6LPE68nShdvuaPUklK12w19DAh/i1OVAzpUZ0A5rCLZKasUp WeWqziAdu0JgzoPn8WlmbMtIWF1JBvKksSw7KZdNfdrklRu0O6zxydJrgJF+gvKG7sfmTWPCyIS6G yc+jDrmg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nuETR-001JAt-Fo; Thu, 26 May 2022 14:28:25 +0000 Date: Thu, 26 May 2022 15:28:25 +0100 From: Matthew Wilcox To: Dan Carpenter Cc: Andrew Morton , Jessica Clarke , kernel test robot , virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-staging@lists.linux.dev, linux-riscv@lists.infradead.org, linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, linux-parport@lists.infradead.org, linux-omap@vger.kernel.org, linux-mm@kvack.org, linux-fbdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, dri-devel@lists.freedesktop.org, bpf@vger.kernel.org, amd-gfx@lists.freedesktop.org, alsa-devel@alsa-project.org Subject: Re: [linux-next:master] BUILD REGRESSION 8cb8311e95e3bb58bd84d6350365f14a718faa6d Message-ID: References: <628ea118.wJYf60YnZco0hs9o%lkp@intel.com> <20220525145056.953631743a4c494aabf000dc@linux-foundation.org> <20220525152006.e87d3fa50aca58fdc1b43b6a@linux-foundation.org> <20220526084832.GC2146@kadam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220526084832.GC2146@kadam> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F237218001B X-Stat-Signature: wfmwkycqa8ykxg4zoq134r874w8z8xbn X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=jt2D3c7x; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1653575329-275471 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, May 26, 2022 at 11:48:32AM +0300, Dan Carpenter wrote: > On Thu, May 26, 2022 at 02:16:34AM +0100, Matthew Wilcox wrote: > > Bizarre this started showing up now. The recent patch was: > > > > - info->alloced += compound_nr(page); > > - inode->i_blocks += BLOCKS_PER_PAGE << compound_order(page); > > + info->alloced += folio_nr_pages(folio); > > + inode->i_blocks += BLOCKS_PER_PAGE << folio_order(folio); > > > > so it could tell that compound_order() was small, but folio_order() > > might be large? > > The old code also generates a warning on my test system. Smatch thinks > both compound_order() and folio_order() are 0-255. I guess because of > the "unsigned char compound_order;" in the struct page. It'd be nice if we could annotate that as "contains a value between 1 and BITS_PER_LONG - PAGE_SHIFT". Then be able to optionally enable a checker that ensures that's true on loads/stores. Maybe we need a language that isn't C :-P Ada can do this ... I don't think Rust can.