From patchwork Fri Jun 21 13:32:51 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Szyprowski X-Patchwork-Id: 1120300 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=samsung.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=samsung.com header.i=@samsung.com header.b="kqk0jiiU"; dkim-atps=neutral Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 45Vg0h2HzLz9sP6 for ; Fri, 21 Jun 2019 23:44:52 +1000 (AEST) Received: by lists.denx.de (Postfix, from userid 105) id F38D4C21EC2; Fri, 21 Jun 2019 13:36:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 9173CC21E1B; Fri, 21 Jun 2019 13:35:58 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id 313EBC21EBF; Fri, 21 Jun 2019 13:33:25 +0000 (UTC) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by lists.denx.de (Postfix) with ESMTPS id 6D545C21E26 for ; Fri, 21 Jun 2019 13:33:21 +0000 (UTC) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20190621133317euoutp025b62fbf9399cbf731fe98744549fd60a~qOgE-NAJp3069530695euoutp02V; Fri, 21 Jun 2019 13:33:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190621133317euoutp025b62fbf9399cbf731fe98744549fd60a~qOgE-NAJp3069530695euoutp02V DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1561123997; bh=V9E+2MPtsAjTB3HdqtkauNKqO7G+MIuZp/HB3aZGadY=; h=From:To:Cc:Subject:Date:References:From; b=kqk0jiiU+qj3g6SU0ffooJ//qP+AzN8cgqmCk3QuWRN2cm+s9uY9EnR3DPSHIR6xh Tf7aHOEw5pRPHQUNf2aXFXMWeFS4G0WGnasGF4tnqZVbovhRp1wg4g3PMS8DKeiE59 mSm0nhcw62Z5md8XStcK85nREArSdGC4vHnQcXTE= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20190621133317eucas1p156967ab1598b92a028a3e4230f792eaa~qOgEUkZ-Z1354213542eucas1p1O; Fri, 21 Jun 2019 13:33:17 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id B9.CB.04325.C9CDC0D5; Fri, 21 Jun 2019 14:33:16 +0100 (BST) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20190621133316eucas1p2dc0538511904be2f0efe8fceccb823bb~qOgDnwJCc0309403094eucas1p2M; Fri, 21 Jun 2019 13:33:16 +0000 (GMT) X-AuditID: cbfec7f5-b8fff700000010e5-6a-5d0cdc9cc1ac Received: from eusync4.samsung.com ( [203.254.199.214]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 8A.A3.04140.C9CDC0D5; Fri, 21 Jun 2019 14:33:16 +0100 (BST) Received: from AMDC2765.DIGITAL.local ([106.120.51.73]) by eusync4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0PTG00EWPAZCJ330@eusync4.samsung.com>; Fri, 21 Jun 2019 14:33:16 +0100 (BST) From: Marek Szyprowski To: u-boot@lists.denx.de Date: Fri, 21 Jun 2019 15:32:51 +0200 Message-id: <20190621133251.451-1-m.szyprowski@samsung.com> X-Mailer: git-send-email 2.17.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42LZduzned05d3hiDba9NLLYOGM9q8XBH3vY LG78amO1WHvkLrvFjMkvgdzpLawWb/d2sjuwe5y9s4PRo7f5HZvHvpU7mDz6tqxiDGCJ4rJJ Sc3JLEst0rdL4Mq4fWUre8EBgYpz03gbGK/zdjFyckgImEjsOfeFqYuRi0NIYAWjxOM9O1lB EkICnxklljz1him6u/I1I0TRMkaJTe/vskI4/xkldnbMZwepYhMwlOh628UGYosISEj86r8K 1sEsMJFJ4uzmhSwgCWGBSIlJrQuAijg4WARUJZ4t8QcxeQWsJb7dj4NYJi+xesMBZpBWCYGH rBKvDhxgh0i4SDQ/vs8GYctIXJ7czQJR1Mwo8fDcWnYIp4dR4nLTDEaIKmuJw8cvgv3DLMAn MWnbdGaQbRICvBIdbUIQJR4Suw48ZYR4OVbi9IUTTBMYxRcwMqxiFE8tLc5NTy02zkst1ytO zC0uzUvXS87P3cQIjKLT/45/3cG470/SIUYBDkYlHt4Ds7hjhVgTy4orcw8xSnAwK4nw8uTw xArxpiRWVqUW5ccXleakFh9ilOZgURLnrWZ4EC0kkJ5YkpqdmlqQWgSTZeLglGpg3DVdcJ7Y 3BdlC3t/SlwPtWCJ5GPkbFt9n3/VP4WOn0r/tm67eE7bduklf/4VjD2Xvk4yz2q59z1WQ1Us cQKLtd0REWGPBOVjUTvdefn7VbZvMJnL9HR6bOXPG7+Evuyb01/1aOK64xu3zhPefzhjpT3z 9MKEe+XrLpjOV5FcKLhM86WS4/OFn5RYijMSDbWYi4oTAWrNZAyeAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJJMWRmVeSWpSXmKPExsVy+t/xa7pz7vDEGpw4x2mxccZ6VouDP/aw Wdz41cZqsfbIXXaLGZNfArnTW1gt3u7tZHdg9zh7ZwejR2/zOzaPfSt3MHn0bVnFGMASxWWT kpqTWZZapG+XwJVx+8pW9oIDAhXnpvE2MF7n7WLk5JAQMJG4u/I1YxcjF4eQwBJGif+rJ7NB OI1MEg0/JjCBVLEJGEp0ve1iA7FFBCQkfvVfBetgFpjMJPHv91awImGBSIlJrQuAijg4WARU JZ4t8QcxeQWsJb7dj4NYJi+xesMB5gmMXAsYGVYxiqSWFuem5xYb6RUn5haX5qXrJefnbmIE BsC2Yz+37GDsehd8iFGAg1GJh/fALO5YIdbEsuLK3EOMEhzMSiK8PDk8sUK8KYmVValF+fFF pTmpxYcYpTlYlMR5OwQOxggJpCeWpGanphakFsFkmTg4pRoYjaVevC2s/6Ugm9KmYhLetPPH KtOlHitZvsv80bks/fvb0Rez915uPvtV//I6Kbc3Lx6JdOfcMzcQmnm+VnV7zTo2XsaKGQ+V Nk2dG3F9fcEOxfdCvJ9MNsZU/vN1s7DPTftxYaciT8tEtsXKrPwzPrF/rd+mWP1bu2dJorKa 2G91RYcq2zBRJZbijERDLeai4kQAVEPlmPwBAAA= X-CMS-MailID: 20190621133316eucas1p2dc0538511904be2f0efe8fceccb823bb CMS-TYPE: 201P X-CMS-RootMailID: 20190621133316eucas1p2dc0538511904be2f0efe8fceccb823bb References: Cc: Stephen Warren , Bartlomiej Zolnierkiewicz , Gero Schumacher , Marek Szyprowski Subject: [U-Boot] [PATCH] ext4: fix calculating inode blkcount for non-512 blocksize filesystems X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" The block count entry in the EXT4 filesystem disk structures uses standard 512-bytes units for most of the typical files. The only exception are HUGE files, which use the filesystem block size, but those are not supported by uboot's EXT4 implementation anyway. This patch fixes the EXT4 code to use proper unit count for inode block count. This fixes errors reported by fsck.ext4 on disks with non-standard (i.e. 4KiB, in case of new flash drives) PHYSICAL block size after using 'ext4write' uboot's command. Signed-off-by: Marek Szyprowski Reviewed-by: Lukasz Majewski --- fs/ext4/ext4_common.c | 2 +- fs/ext4/ext4_write.c | 2 +- include/ext_common.h | 1 + 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c index 464c33d0d74..8a142e2e6a1 100644 --- a/fs/ext4/ext4_common.c +++ b/fs/ext4/ext4_common.c @@ -570,7 +570,7 @@ restart_read: g_parent_inode->size = cpu_to_le32(new_size); new_blockcnt = le32_to_cpu(g_parent_inode->blockcnt); - new_blockcnt += fs->sect_perblk; + new_blockcnt += fs->blksz >> LOG2_SECTOR_SIZE; g_parent_inode->blockcnt = cpu_to_le32(new_blockcnt); if (ext4fs_put_metadata diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c index 504d23a8956..3368bd8c005 100644 --- a/fs/ext4/ext4_write.c +++ b/fs/ext4/ext4_write.c @@ -957,7 +957,7 @@ int ext4fs_write(const char *fname, const char *buffer, ext4fs_allocate_blocks(file_inode, blocks_remaining, &blks_reqd_for_file); file_inode->blockcnt = cpu_to_le32((blks_reqd_for_file * fs->blksz) >> - fs->dev_desc->log2blksz); + LOG2_SECTOR_SIZE); temp_ptr = zalloc(fs->blksz); if (!temp_ptr) diff --git a/include/ext_common.h b/include/ext_common.h index 17c92f1750b..1c10c504748 100644 --- a/include/ext_common.h +++ b/include/ext_common.h @@ -21,6 +21,7 @@ #define __EXT_COMMON__ #include #define SECTOR_SIZE 0x200 +#define LOG2_SECTOR_SIZE 9 /* Magic value used to identify an ext2 filesystem. */ #define EXT2_MAGIC 0xEF53