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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBFDCC433E1 for ; Tue, 25 Aug 2020 00:22:36 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AB1FD2074D for ; Tue, 25 Aug 2020 00:22:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="LyTZV8+t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AB1FD2074D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 69462137D88F9; Mon, 24 Aug 2020 17:22:36 -0700 (PDT) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=willy@infradead.org; receiver= Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 08043124DA503 for ; Mon, 24 Aug 2020 17:22:28 -0700 (PDT) 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=ocdvple/oAl8JiYXsLS1fSxRCYZy5ArHDZ1pVwX0Pes=; b=LyTZV8+tXrOESAyilTthffk4xE LofZU3dPW7vG+qsKdlHZFJTMq+FV7VgX33/L7fGz5bPdCMwrUSgzkvvfSpEH/oyBqOdpF7V+vSUha fu34jWEPjBeRQ36+kTPx38qQGGiVPEOCq2VLeSfGr3JLjSEcN46SOZCcx95+Bi0jbLPKThm6cgOlY N+6OvCpPXtOYDyFqnhPQIqlcPo772tdExSn2PHfWkUDnqzH5nhUw9a+BUdUdGDrvlX6an66aKVpeA tkySVcAbuXWtbl1nd3pPU4TRiyoJ6u1LlaYLK3U3pXA7lW7qkr7/8zFsOYVPg8pVNYnUWyAXAa2Jn f+yg40Pg==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAMjB-0005WV-ID; Tue, 25 Aug 2020 00:22:18 +0000 Date: Tue, 25 Aug 2020 01:22:17 +0100 From: Matthew Wilcox To: Dave Chinner Subject: Re: [PATCH 5/9] iomap: Support arbitrarily many blocks per page Message-ID: <20200825002217.GI17456@casper.infradead.org> References: <20200824145511.10500-1-willy@infradead.org> <20200824145511.10500-6-willy@infradead.org> <20200824235918.GF12131@dread.disaster.area> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200824235918.GF12131@dread.disaster.area> Message-ID-Hash: EKV43NS6DYT4IZQ7ORFT7T6GTIS6LQV7 X-Message-ID-Hash: EKV43NS6DYT4IZQ7ORFT7T6GTIS6LQV7 X-MailFrom: willy@infradead.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" , linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Aug 25, 2020 at 09:59:18AM +1000, Dave Chinner wrote: > On Mon, Aug 24, 2020 at 03:55:06PM +0100, Matthew Wilcox (Oracle) wrote: > > static inline struct iomap_page *to_iomap_page(struct page *page) > > { > > + VM_BUG_ON_PGFLAGS(PageTail(page), page); > > if (page_has_private(page)) > > return (struct iomap_page *)page_private(page); > > return NULL; > > Just to confirm: this vm bug check is to needed becuse we only > attach the iomap_page to the head page of a compound page? > > Assuming that I've understood the above correctly: That's correct. If we get a tail page in this path, something's gone wrong somewhere upstream of us, and the stack trace should tell us where. It's PGFLAGS so it's usually compiled out by distro kernels (you need to enable CONFIG_DEBUG_VM_PGFLAGS for it to be active). It was definitely useful in development; probably not so useful for a distro kernel to assert. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org