Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3554159imd; Mon, 29 Oct 2018 08:49:31 -0700 (PDT) X-Google-Smtp-Source: AJdET5cJy6gS332HbWXkgMAxJNMVjSmBvcRWvPySLSw43WjqjZhf8Luc/Jyqx9LJlXUvphSIIbgl X-Received: by 2002:a63:8948:: with SMTP id v69mr14407943pgd.39.1540828171433; Mon, 29 Oct 2018 08:49:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540828171; cv=none; d=google.com; s=arc-20160816; b=m112AiPLiXVbVVNZT1zq0EhBvAGVRVv9ZKEBDQhJyiv82SkpWOT/SGnN622tX7o93/ G1fY7LxYTA6TxAPF1fRveQ+VW2Ql8OuoQe8I13eQBgm+8i8s3QPKN2KCOfq3NaQLL7Ie ms8Tb445aXXC0Ks2o5ZBT+KswrvhzElblgwgki1HKcwLAM2RyTNAhTofBe9yPS1IlsYn N+M8K9y/JcfztdLwaydK7k0GKTeZ2F7DU4J+3zdjXJ6pblLSaFTHUmoKuBQHpVTd9pnC RsVCAGVKKAB1OITIaSnLSkTROXKO/O2zZzWEOnpBdCmMSFvTxLfICjs/bjUnhVOBkDA/ Eomw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:cc:to :subject:from; bh=8MjpUICpdYZDwCnt5nrhYyFSN71ycAJ4iTpg0p1Qeq0=; b=RYJnlTB0c8ahquWk5ad3oLOi+kncbToZ4kAsXnrGjkIcULdxasmaneKZXmDFwwpBzo Dv3adKCFeo1s97nTK3BybUVlwnaORi2M281oYSkk6XyOBGtIGD5bytuQzttzUIZoGJI7 I764xus/HugyTz8nE6iUpQs3nkZkVB7ubUndpWt2uL1h14c/K47aGj84Y49M6GEDz7Hm kVLbC2YmRqOPriF4dyNfsmpK6gmwsFSyIYeShgX2pdq2rO5UznWnx8oEazoed7whn2pA DFMRLSoV72KKlnHjitoSFLmfRryB//TOo8FMxVgaWehiVXbP9qOWZ1MpqLkHaO9dIbJg OAEw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h3-v6si21608390pfd.228.2018.10.29.08.49.15; Mon, 29 Oct 2018 08:49:31 -0700 (PDT) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727784AbeJ3AhH (ORCPT + 99 others); Mon, 29 Oct 2018 20:37:07 -0400 Received: from relay.sw.ru ([185.231.240.75]:46108 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727744AbeJ3AhG (ORCPT ); Mon, 29 Oct 2018 20:37:06 -0400 Received: from [172.16.24.21] by relay.sw.ru with esmtp (Exim 4.90_1) (envelope-from ) id 1gH9PX-0006bV-DT; Mon, 29 Oct 2018 18:24:59 +0300 From: Vasily Averin Subject: [PATCH 0/7] ext4 resize long-lived errors To: linux-ext4@vger.kernel.org, Theodore Ts'o Cc: Andreas Dilger , linux-kernel@vger.kernel.org Message-ID: <9cba7f49-64bb-b7cd-fac0-5be8301ccd17@virtuozzo.com> Date: Mon, 29 Oct 2018 18:24:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Last week I've investigated the reason of ext4 resize troubles on RHEL6 and RHEL7 based OpenVZ kernels. Failed resize generated lot of "access beyond end of device" messages followed by warning in __brelse. EXT4-fs (dm-3): resizing filesystem from 2620416 to 4096256 blocks attempt to access beyond end of device dm-3: rw=1, want=32770056, limit=32770048 attempt to access beyond end of device dm-3: rw=1, want=32770064, limit=32770048 ... attempt to access beyond end of device dm-3: rw=1, want=32776216, limit=32770048 EXT4-fs (dm-3): resized filesystem to 4096256 WARNING: CPU: 2 PID: 113370 at fs/buffer.c:1171 __brelse+0x2e/0x50 VFS: brelse: Trying to free free buffer "access beyond end of device" was fixed in mainline by recent commit f0a459dec5495a ("ext4: fix online resize's handling of a too-small final block group") However fixed error did not affected bh accounting and should not lead to warning in __brelse. Then I've reviewed fs/ext4/resize.c and found a number of long-lived errors, earliest of them was imported from ext3 in 2.6.19. First patch in this patch-set fixes the observed problem: sb_issue_zeroout() failed during attempt to write beyond end of device rollback switched to "goto end" and called brelse(bh). however bh was not assigned yet in current iteration, the pointer was not cleaned properly and was inherited from previous iteration. To fix the problem I've moved brelse() calls in body of the cycle to avoid having to call him on rollback. Other patches fixes visually-found mistakes. Vasily Averin (7): ext4 resise: extra brelse in setup_new_flex_group_blocks() ext4 resize: missing brelse() after errors in set_flexbg_block_bitmap() ext4 resize: missing brelse() in case success in add_new_gdb() ext4 resize: brelse() cleanup in add_new_gdb_meta_bg() ext4 resize: lost brelse() in update_backups() ext4 resize: lost rollback in ext4_resize_fs() ext4 resize: lost resize_inode cleanup before retry in ext4_resize_fs() fs/ext4/resize.c | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) -- 2.17.1