From patchwork Tue Jan 1 02:08:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 10745579 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B165E13A4 for ; Tue, 1 Jan 2019 02:08:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9B88128A75 for ; Tue, 1 Jan 2019 02:08:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8FCEE28A9B; Tue, 1 Jan 2019 02:08:40 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY 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 0C8A228A75 for ; Tue, 1 Jan 2019 02:08:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727142AbfAACIb (ORCPT ); Mon, 31 Dec 2018 21:08:31 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:59460 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726686AbfAACIb (ORCPT ); Mon, 31 Dec 2018 21:08:31 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0125YXN168652 for ; Tue, 1 Jan 2019 02:08:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : cc : date : message-id : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=r7U1rk52AluplMfHMpIJteqaNAUCqzshJqkCsWs6ZF4=; b=WxnR4cFdN3NzEO+SUN/Af2lyp+GQDqg1eZH8CDDvGK0mt66PbxpZvytrCXczzw4dPFUq HIKC6IMqMRKMZp0GNJgMFUiYF28nmQInxuvTLfsE8PIP04udNzx86r8fI0lrmmPIAMJG zXYzW0nCgbeQOOG5jXSqWD4+APvz/Ba1T3w4iIdSOzVG8FvyAByU/2vV6fDITzb2Qcxu ds37QoW5OEM/VKQ8kExO5XNefEWAU0rWnOO7ZDPIYmgGl4GA2OnW20d7kYDgHaSZirmz ZxP8lT5iOBAUJYn1EMxrMye6oBEoRNEEkCjGoBP5FCOjEDqQYgFKLT6TqK6VWNZVj7Ia TQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2pp1jqx3s1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 01 Jan 2019 02:08:30 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0128Tcb013430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 1 Jan 2019 02:08:29 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x0128Ser002563 for ; Tue, 1 Jan 2019 02:08:29 GMT Received: from localhost (/10.159.150.85) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 Dec 2018 18:08:28 -0800 Subject: [PATCH 0/8] xfs: inode scrubber fixes From: "Darrick J. Wong" To: darrick.wong@oracle.com Cc: linux-xfs@vger.kernel.org Date: Mon, 31 Dec 2018 18:08:27 -0800 Message-ID: <154630850739.14372.14000129432637481206.stgit@magnolia> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9123 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901010017 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 Hi all, Here are fixes for some problems with the inode btree scrub code, namely that the existing code does not handle the case where a single inode cluster is mapped by multiple inobt records. Patch 1 corrects a condition where we needed to clamp the number of inodes checked for a given inobt record to the inode chunk size. Patches 2-3 move the inobt record alignment checks to a separate function and enhance the function to check that when we have more than one inobt record per cluster we actually check that *all* of the necessary records are present and in the correct order. This patch includes fixes for the finobt alignment false positives recently reported by Chandan. Patches 4-6 reorganize the inobt free data checks to deal with the "multiple inobt records per icluster" situation. In restructuring the code to do so, we also rename variables and functions to be less confusing about what they're there for. We also fix the 'is the inode free?' check to calculate dinode buffer offsets correctly in the "multiple inobt records per icluster" situation. Patch 7 aborts the xattr scrub loop if there are pending fatal signals. Patch 8 checks that for any directory or attr fork there are no extent maps that stretch beyond what a xfs_dablk_t can map. If you're going to start using this mess, you probably ought to just pull from my git trees. The kernel patches[1] should apply against 4.20. Comments and questions are, as always, welcome. --D