From patchwork Thu Jun 22 19:33:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bill O'Donnell X-Patchwork-Id: 9805247 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A55C760329 for ; Thu, 22 Jun 2017 19:33:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 90A9127F17 for ; Thu, 22 Jun 2017 19:33:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8357B28653; Thu, 22 Jun 2017 19:33:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1AD3127F17 for ; Thu, 22 Jun 2017 19:33:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751202AbdFVTdz (ORCPT ); Thu, 22 Jun 2017 15:33:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50682 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbdFVTdz (ORCPT ); Thu, 22 Jun 2017 15:33:55 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 756457C832; Thu, 22 Jun 2017 19:33:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 756457C832 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=billodo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 756457C832 Received: from localhost.localdomain.com (ovpn-120-226.rdu2.redhat.com [10.10.120.226]) by smtp.corp.redhat.com (Postfix) with ESMTP id D521F60604; Thu, 22 Jun 2017 19:33:53 +0000 (UTC) From: Bill O'Donnell To: linux-xfs@vger.kernel.org Cc: sandeen@sandeen.net Subject: [PATCH] xfs_db: update sector size when type is set Date: Thu, 22 Jun 2017 14:33:52 -0500 Message-Id: <20170622193352.22346-1-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 22 Jun 2017 19:33:54 +0000 (UTC) Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP xfs_db doesn't take sector size into account when setting type. This can result in an errant crc. For example, with a sector size of 4096: xfs_db> agi 0 xfs_db> p crc crc = 0xab85043e (correct) xfs_db> daddr current daddr is 16 xfs_db> daddr 42 xfs_db> daddr 16 xfs_db> type agi Metadata CRC error detected at xfs_agi block 0x10/0x200 xfs_db> p crc crc = 0xab85043e (bad) When xfs_db sets the new daddr in daddr_f, it does so with one BBSIZE sector (512). Changing the type doesn't change the size of the current buffer in iocur_top, so the checksum is calculated on the wrong length for the type (when the actual sector size > BBSIZE (512). For types with fields, reread the buffer to pick up the correct size for the new type when it gets set. Facilitate the reread by setting the cursor with set_cur(). Signed-off-by: Bill O'Donnell --- db/io.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/db/io.c b/db/io.c index 9918a51..7e6d330 100644 --- a/db/io.c +++ b/db/io.c @@ -616,6 +616,12 @@ set_iocur_type( { struct xfs_buf *bp = iocur_top->bp; + if (t->fields) + set_cur(t, + iocur_top->bb, + fsize(t->fields, iocur_top->data, + 0, 0) / mp->m_sb.sb_blocksize, + DB_RING_IGN, NULL); iocur_top->typ = t; /* verify the buffer if the type has one. */