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=-7.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED 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 62B53C4360F for ; Thu, 21 Feb 2019 08:43:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2477820880 for ; Thu, 21 Feb 2019 08:43:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="COOzo5jJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727440AbfBUInH (ORCPT ); Thu, 21 Feb 2019 03:43:07 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:40738 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726287AbfBUInG (ORCPT ); Thu, 21 Feb 2019 03:43:06 -0500 Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20190221084303euoutp02ddd134506cf95dcf2cf4e652e0914619~FVIZ_nfPt3022230222euoutp02P; Thu, 21 Feb 2019 08:43:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190221084303euoutp02ddd134506cf95dcf2cf4e652e0914619~FVIZ_nfPt3022230222euoutp02P DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1550738583; bh=s4vQCFfJNgY7j1aVVCvYRzsum15lWTDFGJKVaSmae3w=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=COOzo5jJLzwHx6jWmWKILSClrZcztSg4PeFThqqkw5CCvGoaYOCGS8CE/wrReH8y4 83IodjO9QoB3w/2tHg7vAMrNJze7Kdzgic8Zkj5bm32nhKK89X4/IadA/P7KK+Qma3 ousHB3KJhPE+W8uHoIXHmKgyOQ5kM6sXIcb+NRgU= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20190221084302eucas1p197a7a79faffba146d2bf752202ea7bbb~FVIZdWvpr0898408984eucas1p1h; Thu, 21 Feb 2019 08:43:02 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id F2.2A.04441.6946E6C5; Thu, 21 Feb 2019 08:43:02 +0000 (GMT) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20190221084301eucas1p11e8841a62b4b1da3cccca661b6f4c29d~FVIYatHfU0667606676eucas1p1S; Thu, 21 Feb 2019 08:43:01 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20190221084301eusmtrp1b37465228ad54751317eb5c596caa0f6~FVIYIE7zD1535615356eusmtrp1E; Thu, 21 Feb 2019 08:43:01 +0000 (GMT) X-AuditID: cbfec7f2-5c9ff70000001159-b3-5c6e6496b067 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id C3.18.04284.5946E6C5; Thu, 21 Feb 2019 08:43:01 +0000 (GMT) Received: from [106.116.147.30] (unknown [106.116.147.30]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20190221084259eusmtip1354f4555199188cc1528f683f2250d71~FVIWvPy6o0274402744eusmtip1z; Thu, 21 Feb 2019 08:42:59 +0000 (GMT) Subject: Re: [PATCH V15 14/18] block: enable multipage bvecs To: Ming Lei , Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o , Omar Sandoval , Sagi Grimberg , Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, linux-raid@vger.kernel.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , Christoph Hellwig , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com, Ulf Hansson , "linux-mmc@vger.kernel.org" , 'Linux Samsung SOC' , Krzysztof Kozlowski , Adrian Hunter , Bartlomiej Zolnierkiewicz From: Marek Szyprowski Message-ID: <6c9ae4de-c56f-a2b3-2542-da7d8b95601d@samsung.com> Date: Thu, 21 Feb 2019 09:42:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190215111324.30129-15-ming.lei@redhat.com> Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUxbZRTee79p1nm5zHAcM4s1I+oiSPTHGyUMv7L3hybG6KYOJ53cFAot pHdsbvvDqAxoiNVtCpTNaRYdArZA+BorGFmhqYV1gF0mFkIGDimByqcS3ebauyn/nuc5zznn OckRaGmS2ybkmQ/JFrO+QMdpmI6B9cDTX+SYs55x3dqOfdNNHG4ct3O4pcbFYl/jFIerTwR4 PB7pZPFQ+ByPexbqWHztrxMUXrkTZPF3jf0U9pQew4FAM48HOq5TuGdsFx6Zqudx7ZchDrt7 fAwe7T7L4Ymmuyz23LUjXH6+G+GaQC+Fu//p4nHfaSuFf59Lxlcmggy21ZVx2DkXYfDJllWE y6rWeez9fh8O3PaymY8R50oNSz6zLvDkkmOcJ4GJFoZ87JlnyQX3LEVGh4pJa0MlR1qXTvEk dN3Nkcu/lHCkdLCfJou/jTEk0hvkyCdtDYi42oLMGwnvadJz5IK8w7IlNSNbk/vHTx1U0d/p H7mm2qkSNJhmQ3ECiM/Bn7511oY0giTWIxhva6ZUsoJgdt6DVLKMYMHjQg9a/NWd910XEfi/ +ZxTSQSBd3aJi7oSxHS4+W1TrGOrmAnOSEVsFC1OCFDmtscKnJgGtnnbvQZB0IoZ8MNMelRm xJ0w0FjFRvHDYhacuerho1grxoOvdpqJ4jjxebDPBGNjaHEHWNvraBUnwtj0eUpN2hkHnQu8 il+B8lE7q+IECHvb7uvbwX+6iolmA9GKoLzGwaukCkH72S5Odb0AV7zDbDQoLT4Jru5UVX4R vu5xxWQQt8CN+Xg1wxY41VFNq7IWKk5KqjsZHF7nf2t/vDZCf4p0jg2XOTZc49hwjeP/vV8h pgElysWKySAraWb5SIqiNynFZkPKh4WmVnTv7/13vEtdaHXkYB8SBaTbrG1+x5QlsfrDylFT HwKB1m3VStnmLEmboz96TLYUfmApLpCVPpQkMLpE7fFNk/sl0aA/JOfLcpFseVClhLhtJSgp vHg7/2Vm52jGo8urSehIbfabTuX1A6/FP75i3DO0O2T/1TA3WB/KGza+apwreLf+7Zdszwp7 2c3G8Pt1a4R6pPlGzlRqaX/8sOd4mWY9t6XyoT0XpSdKNiX7rSF3/u79DZOFa70HjEUVKUWL w5nVlYYzmT/vWNt382p4ZjnhlvSWjlFy9WlP0RZF/y/8vHyT8wMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUxTZxTH89x3jI3XgvERlzhvfEk2rV4QOZhCSBbN4yfNTJw6Nmzkjhpp i72tEf1S6dCtURkqCsXBNnyZlIEwRGBFTXmzQ1YDKVGkfLAsOBGKm8vGBB2FLeHbL/9zfic5 yV+gtS/ZeOGg2aZYzYYciVvAdL/pCq0vzjJnbPQ8WQz+4WoOPKFCDupKalnwe8IcXDoR4CEU uc1Cz/OveWgdL2Ph4d8nKHj1JsjCDU8HBe35xyAQuMlDZ2M/Ba0D70Nv+HseSssHOfC2+hno a7nMwVD1Wxba3xYiOFXRgqAkcIeClqkmHnznnRQ8G10DbUNBBlxlBRzUjEYYOFn3J4KC05M8 dP3wEQSmu9j0laTmVQlLipzjPGl2h3gSGKpjyOftYyyp9P5Gkb4eO6mv+pIj9b+f48lgv5cj Pz12cCT/QQdNXv46wJDInSBHzjZUIVLbEGR2xu7T6a0Wu01512hRbanSxzIk6OQU0CVsStHJ icmfbElIkjak6bOUnINHFOuGtP0648TPjVTua/3R2vAtyoEeyC4UI2BxE+6+dJtyoQWCVryK 8HcTg9zc4B3sv+hg5zgWT/W7uLmlMYTPX63mo4NYUY+fXqtGUY4T03FN5AsUXaLFpwK+cqp4 1taKRtz96PIsc6KMXWPRS4KgEdPw3RF9NGbE1bjTc5qNxkvEDBz8ZfakRlyM/aXDTJRjxC24 cCQ4m9PiWjxV3kvP8QrsvFX2Hy/FA8MV1FdI656nu+cp7nmKe57yDWKqUJxiV03ZJlXWqQaT ajdn6w5YTPVopm6NnZM/NqHeul0+JApIWqi5uceUoWUNR9Q8kw9hgZbiNNr95gytJsuQd0yx WjKt9hxF9aGkmd+K6PglBywz5TXbMuUkORlS5OTE5MTNIC3VBDbm7dOK2QabckhRchXr/x4l xMQ70F7HlTP3InQ43fnMeW6d0NVDFu3+Z1XHhbEhN33o2/FRJdSy4/WFFbAu7DU+XLmw2XX8 j0XLFX95z/1CX9P6NW0vtiWNfFgsxX3wqXeSLytKPbzs5NaGs7ml+uurputTeq9Lg5nFT7bH 38g5U5KtVBZMNLfl6fMvpk47tvbd++uzyj6JUY0G+T3aqhr+BeGZ066EAwAA X-CMS-MailID: 20190221084301eucas1p11e8841a62b4b1da3cccca661b6f4c29d X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20190221084301eucas1p11e8841a62b4b1da3cccca661b6f4c29d X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20190221084301eucas1p11e8841a62b4b1da3cccca661b6f4c29d References: <20190215111324.30129-1-ming.lei@redhat.com> <20190215111324.30129-15-ming.lei@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear All, On 2019-02-15 12:13, Ming Lei wrote: > This patch pulls the trigger for multi-page bvecs. > > Reviewed-by: Omar Sandoval > Signed-off-by: Ming Lei Since Linux next-20190218 I've observed problems with block layer on one of my test devices (Odroid U3 with EXT4 rootfs on SD card). Bisecting this issue led me to this change. This is also the first linux-next release with this change merged. The issue is fully reproducible and can be observed in the following kernel log: sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2 (100000000 Hz) s3c-sdhci 12530000.sdhci: Got CD GPIO mmc0: SDHCI controller on samsung-hsmmc [12530000.sdhci] using ADMA mmc0: new high speed SDHC card at address aaaa mmcblk0: mmc0:aaaa SL16G 14.8 GiB ... EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem EXT4-fs (mmcblk0p2): write access will be enabled during recovery EXT4-fs (mmcblk0p2): recovery complete EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) readonly on device 179:2. devtmpfs: mounted Freeing unused kernel memory: 1024K hub 1-3:1.0: USB hub found Run /sbin/init as init process hub 1-3:1.0: 3 ports detected *** stack smashing detected ***: terminated Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 1 PID: 1 Comm: init Not tainted 5.0.0-rc6-next-20190218 #1546 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x90/0xc8) [] (dump_stack) from [] (panic+0xfc/0x304) [] (panic) from [] (do_exit+0xabc/0xc6c) [] (do_exit) from [] (do_group_exit+0x3c/0xbc) [] (do_group_exit) from [] (get_signal+0x130/0xbf4) [] (get_signal) from [] (do_work_pending+0x130/0x618) [] (do_work_pending) from [] (slow_work_pending+0xc/0x20) Exception stack(0xe88c3fb0 to 0xe88c3ff8) 3fa0:                                     00000000 bea7787c 00000005 b6e8d0b8 3fc0: bea77a18 b6f92010 b6e8d0b8 00000001 b6e8d0c8 00000001 b6e8c000 bea77b60 3fe0: 00000020 bea77998 ffffffff b6d52368 60000050 ffffffff CPU3: stopping I would like to help debugging and fixing this issue, but I don't really have idea where to start. Here are some more detailed information about my test system: 1. Board: ARM 32bit Samsung Exynos4412-based Odroid U3 (device tree source: arch/arm/boot/dts/exynos4412-odroidu3.dts) 2. Block device: MMC/SDHCI/SDHCI-S3C with SD card (drivers/mmc/host/sdhci-s3c.c driver, sdhci_2 device node in the device tree) 3. Rootfs: Ext4 4. Kernel config: arch/arm/configs/exynos_defconfig I can gather more logs if needed, just let me which kernel option to enable. Reverting this commit on top of next-20190218 as well as current linux-next (tested with next-20190221) fixes this issue and makes the system bootable again. > --- > block/bio.c | 22 +++++++++++++++------- > fs/iomap.c | 4 ++-- > fs/xfs/xfs_aops.c | 4 ++-- > include/linux/bio.h | 2 +- > 4 files changed, 20 insertions(+), 12 deletions(-) > > diff --git a/block/bio.c b/block/bio.c > index 968b12fea564..83a2dfa417ca 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -753,6 +753,8 @@ EXPORT_SYMBOL(bio_add_pc_page); > * @page: page to add > * @len: length of the data to add > * @off: offset of the data in @page > + * @same_page: if %true only merge if the new data is in the same physical > + * page as the last segment of the bio. > * > * Try to add the data at @page + @off to the last bvec of @bio. This is a > * a useful optimisation for file systems with a block size smaller than the > @@ -761,19 +763,25 @@ EXPORT_SYMBOL(bio_add_pc_page); > * Return %true on success or %false on failure. > */ > bool __bio_try_merge_page(struct bio *bio, struct page *page, > - unsigned int len, unsigned int off) > + unsigned int len, unsigned int off, bool same_page) > { > if (WARN_ON_ONCE(bio_flagged(bio, BIO_CLONED))) > return false; > > if (bio->bi_vcnt > 0) { > struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt - 1]; > + phys_addr_t vec_end_addr = page_to_phys(bv->bv_page) + > + bv->bv_offset + bv->bv_len - 1; > + phys_addr_t page_addr = page_to_phys(page); > > - if (page == bv->bv_page && off == bv->bv_offset + bv->bv_len) { > - bv->bv_len += len; > - bio->bi_iter.bi_size += len; > - return true; > - } > + if (vec_end_addr + 1 != page_addr + off) > + return false; > + if (same_page && (vec_end_addr & PAGE_MASK) != page_addr) > + return false; > + > + bv->bv_len += len; > + bio->bi_iter.bi_size += len; > + return true; > } > return false; > } > @@ -819,7 +827,7 @@ EXPORT_SYMBOL_GPL(__bio_add_page); > int bio_add_page(struct bio *bio, struct page *page, > unsigned int len, unsigned int offset) > { > - if (!__bio_try_merge_page(bio, page, len, offset)) { > + if (!__bio_try_merge_page(bio, page, len, offset, false)) { > if (bio_full(bio)) > return 0; > __bio_add_page(bio, page, len, offset); > diff --git a/fs/iomap.c b/fs/iomap.c > index af736acd9006..0c350e658b7f 100644 > --- a/fs/iomap.c > +++ b/fs/iomap.c > @@ -318,7 +318,7 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data, > */ > sector = iomap_sector(iomap, pos); > if (ctx->bio && bio_end_sector(ctx->bio) == sector) { > - if (__bio_try_merge_page(ctx->bio, page, plen, poff)) > + if (__bio_try_merge_page(ctx->bio, page, plen, poff, true)) > goto done; > is_contig = true; > } > @@ -349,7 +349,7 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data, > ctx->bio->bi_end_io = iomap_read_end_io; > } > > - __bio_add_page(ctx->bio, page, plen, poff); > + bio_add_page(ctx->bio, page, plen, poff); > done: > /* > * Move the caller beyond our range so that it keeps making progress. > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c > index 1f1829e506e8..b9fd44168f61 100644 > --- a/fs/xfs/xfs_aops.c > +++ b/fs/xfs/xfs_aops.c > @@ -616,12 +616,12 @@ xfs_add_to_ioend( > bdev, sector); > } > > - if (!__bio_try_merge_page(wpc->ioend->io_bio, page, len, poff)) { > + if (!__bio_try_merge_page(wpc->ioend->io_bio, page, len, poff, true)) { > if (iop) > atomic_inc(&iop->write_count); > if (bio_full(wpc->ioend->io_bio)) > xfs_chain_bio(wpc->ioend, wbc, bdev, sector); > - __bio_add_page(wpc->ioend->io_bio, page, len, poff); > + bio_add_page(wpc->ioend->io_bio, page, len, poff); > } > > wpc->ioend->io_size += len; > diff --git a/include/linux/bio.h b/include/linux/bio.h > index 089370eb84d9..9f77adcfde82 100644 > --- a/include/linux/bio.h > +++ b/include/linux/bio.h > @@ -441,7 +441,7 @@ extern int bio_add_page(struct bio *, struct page *, unsigned int,unsigned int); > extern int bio_add_pc_page(struct request_queue *, struct bio *, struct page *, > unsigned int, unsigned int); > bool __bio_try_merge_page(struct bio *bio, struct page *page, > - unsigned int len, unsigned int off); > + unsigned int len, unsigned int off, bool same_page); > void __bio_add_page(struct bio *bio, struct page *page, > unsigned int len, unsigned int off); > int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland