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=-14.1 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=ham 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 EB057C43603 for ; Fri, 20 Dec 2019 19:18:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 998EB206D3 for ; Fri, 20 Dec 2019 19:18:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rd4oin3B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 998EB206D3 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 155E98E01CF; Fri, 20 Dec 2019 14:18:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DFD18E019D; Fri, 20 Dec 2019 14:18:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F11818E01CF; Fri, 20 Dec 2019 14:18:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id D844F8E019D for ; Fri, 20 Dec 2019 14:18:48 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id A4A4C180AD830 for ; Fri, 20 Dec 2019 19:18:48 +0000 (UTC) X-FDA: 76286481936.19.wood56_4cdb5e8a54948 X-HE-Tag: wood56_4cdb5e8a54948 X-Filterd-Recvd-Size: 6456 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Dec 2019 19:18:48 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id 195so4860617pfw.11 for ; Fri, 20 Dec 2019 11:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fnOGUKBJZVwObRr27GsLKSAK6e29jiTSmn4200DZJaM=; b=rd4oin3BnuSW4K/bPLja90SsGMJ2MyHp8WX2y6MUiG+803M0/G5fYHVd2mDU+J34vX FTi1J1FkZIEwIAk0z139P+zpr8P3Lq3KP3QUfTx8biVXJNtoI0txmTbSdA4laNrvlR0X 9hHOThFsCl51kcGqdnnhqG0SEX635NIfFff3dvqF7GQAxGu4bNuyualJNkRTpCNOVDGr t7bERkdkqaDvlptBZn5g0t9KZ8akn+n1csZdKzgZsKPi0F+4n24aMgPeCe7IQfDE4+r7 QMB0+uVnnvyvE808h+TrRq6v19vc4h7fDgG712k+DYNUAGYigdLMIFvU7zCYiS3smyQ7 Ivrw== 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=fnOGUKBJZVwObRr27GsLKSAK6e29jiTSmn4200DZJaM=; b=DFP95/ONuK1fG7zRQagFFk/svwLje187XL9bSkffERXPoFScaM5YOdx+p8+PV7GmfL AZA2sE8ZkUCy1UhF0Xk4sKkX0Wa/y1rNZ/XD96ZfMq1aoHsTrlJQSdRx1lmgCxzlx5uK QryZ6P6pw61ymgWbvnREO1Y6Mp0AF1+ESR2yvxDsdKLjxBqiyPYPBzXDI6DHuwG2R0p8 S86H1w6sIOF4LRFr7i2oIzfptSdcKKN9oqoWIPsd6vttZFwxyI+HKwN50oT8h1ErmHtq EvuWNbBVajntKJqCkRXwiweo9IsnSNyFblVmhjzMikNdfUJi6SgkF2tTYhaiVAm0EkZN GQmA== X-Gm-Message-State: APjAAAWOhCLez5zBFU5w+U1my6Mmcf/Zr4oj52uBdUgSCkd/hyh312rW 6FRoxgDbzt9LWXBU966Wlwm9XA== X-Google-Smtp-Source: APXvYqynnu3KZo8Fy81UqHS+8NHAovUZ6QXpxFlUhY5Bnsa9Nw+G+hrpwAo9Hfr2ouIjNu0Wp/6kuw== X-Received: by 2002:a63:114a:: with SMTP id 10mr16541484pgr.250.1576869526611; Fri, 20 Dec 2019 11:18:46 -0800 (PST) Received: from google.com ([2620:15c:201:2:765b:31cb:30c4:166]) by smtp.gmail.com with ESMTPSA id h11sm12142832pgv.38.2019.12.20.11.18.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2019 11:18:45 -0800 (PST) Date: Fri, 20 Dec 2019 11:18:40 -0800 From: Eric Biggers To: glider@google.com Cc: Theodore Ts'o , Andreas Dilger , Vegard Nossum , Dmitry Vyukov , Marco Elver , Andrey Konovalov , linux-mm@kvack.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, aryabinin@virtuozzo.com, luto@kernel.org, ard.biesheuvel@linaro.org, arnd@arndb.de, hch@infradead.org, hch@lst.de, darrick.wong@oracle.com, davem@davemloft.net, dmitry.torokhov@gmail.com, edumazet@google.com, ericvh@gmail.com, gregkh@linuxfoundation.org, harry.wentland@amd.com, herbert@gondor.apana.org.au, iii@linux.ibm.com, mingo@elte.hu, jasowang@redhat.com, axboe@kernel.dk, m.szyprowski@samsung.com, mark.rutland@arm.com, martin.petersen@oracle.com, schwidefsky@de.ibm.com, willy@infradead.org, mst@redhat.com, mhocko@suse.com, monstr@monstr.eu, pmladek@suse.com, cai@lca.pw, rdunlap@infradead.org, robin.murphy@arm.com, sergey.senozhatsky@gmail.com, rostedt@goodmis.org, tiwai@suse.com, tglx@linutronix.de, gor@linux.ibm.com, wsa@the-dreams.de Subject: Re: [PATCH RFC v4 40/42] kmsan: ext4: skip block merging logic in ext4_mpage_readpages for KMSAN Message-ID: <20191220191840.GA11160@google.com> References: <20191220184955.223741-1-glider@google.com> <20191220184955.223741-41-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191220184955.223741-41-glider@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Fri, Dec 20, 2019 at 07:49:53PM +0100, glider@google.com wrote: > KMSAN doesn't allow treating adjacent memory pages as such, if they were > allocated by different alloc_pages() calls. > ext4_mpage_readpages() however does so: adjacent pages end up being passed > together to dma_direct_map_sg(). > To prevent this, jump directly to the buffer_head-based read function in > KMSAN builds. > > Signed-off-by: Alexander Potapenko > Cc: "Theodore Ts'o" > Cc: Andreas Dilger > Cc: Vegard Nossum > Cc: Dmitry Vyukov > Cc: Marco Elver > Cc: Andrey Konovalov > Cc: linux-mm@kvack.org > --- > > v4: > - use IS_ENABLED, as requested by Marco Elver > > Change-Id: I54ae8af536626a988e6398ff18a06c179b0ce034 > --- > fs/ext4/readpage.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c > index fef7755300c3..1e46ddf7a854 100644 > --- a/fs/ext4/readpage.c > +++ b/fs/ext4/readpage.c > @@ -252,6 +252,16 @@ int ext4_mpage_readpages(struct address_space *mapping, > if (page_has_buffers(page)) > goto confused; > > + /* > + * The following code may treat adjacent pages allocated > + * separately as a bigger contiguous allocation. > + * KMSAN doesn't allow this, as the corresponding metadata > + * pages may be separated. > + * Skip this complex logic for KMSAN builds. > + */ > + if (IS_ENABLED(CONFIG_KMSAN)) > + goto confused; > + > block_in_file = (sector_t)page->index << (PAGE_SHIFT - blkbits); > last_block = block_in_file + nr_pages * blocks_per_page; > last_block_in_file = (ext4_readpage_limit(inode) + > -- Why is ext4 special here? Wouldn't other filesystems need this too? Is it possible the problem is the page merging logic in bio_add_page()? Maybe we need something like: diff --git a/block/bio.c b/block/bio.c index a5d75f6bf4c7e..9449a1e571ee7 100644 --- a/block/bio.c +++ b/block/bio.c @@ -646,6 +646,8 @@ static inline bool page_is_mergeable(const struct bio_vec *bv, *same_page = ((vec_end_addr & PAGE_MASK) == page_addr); if (!*same_page && pfn_to_page(PFN_DOWN(vec_end_addr)) + 1 != page) return false; + if (!*same_page && IS_ENABLED(CONFIG_KMSAN)) + return false; return true; }