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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3A40C48260 for ; Tue, 13 Feb 2024 21:48:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 462498D0018; Tue, 13 Feb 2024 16:48:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EC558D0017; Tue, 13 Feb 2024 16:48:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28C1C8D0018; Tue, 13 Feb 2024 16:48:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 135238D0017 for ; Tue, 13 Feb 2024 16:48:27 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DC8C51A0B93 for ; Tue, 13 Feb 2024 21:48:26 +0000 (UTC) X-FDA: 81788119812.30.B257568 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by imf08.hostedemail.com (Postfix) with ESMTP id E6649160005 for ; Tue, 13 Feb 2024 21:48:24 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=HqlWUR4g; spf=pass (imf08.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707860905; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ykCSvbVtFiBVrhtTjWwOXRXS55nDdON2NLoOZ7/jR0k=; b=yvMlzQCIo0Mu96RTbgHLxrcDZUqSh6FIABjdSlFmbKbF8VtwA7Z1IEomh9nJeyculaooAw qrbPaohdkRnEZ203EcmSuOjUY0mWEiODMW8ptWOW9lOslmco4trs4igaH0Zk6ClpjyzmKv qBaBkcyCKARjNAOAsCAxEydSyev+hXM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=HqlWUR4g; spf=pass (imf08.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707860905; a=rsa-sha256; cv=none; b=axL/Co5gg49rUByraYbffeP20BkxCLRCyJCnP88uHgCIYpLmy3Q/mTqRueA2QT6cQ5cRrC xXM63+sxNIoY3mDkFs/h3OtsD5IgkE/gVm/ivIGsi/59tcF1euuxxBdiOe37LGGY8b7Vwf Sxv5InaS2msFfglFFook8vAqhYLrqUk= Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4TZFLr2xxcz9sqN; Tue, 13 Feb 2024 22:48:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1707860900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ykCSvbVtFiBVrhtTjWwOXRXS55nDdON2NLoOZ7/jR0k=; b=HqlWUR4gmP/sxc5ye4ZUTrM2ExyOkJkm3RuSuV1a77+pECRbnN/ZT1pTS4qIRA+rt5Zz7p mJZFFe3c293kPAzY1SO+qtu+iBCAoRSb3zRsUNPAXgAli0xwBYd7WySIyesvDcToHAtPle UuMchaXNerqQ051JhHBe3qAvyZJiaTv6dVgkyFjkUgBJlZDiP1gn6SJQHvfOuW+Vyv86+6 g2BJr7UxqDb9xKPp5ZxVDuEWuwYXuzUezcmKMc4PCUSca5Ygzta2DWXlyq7Nf8Wi7lOS0/ GjZov4SgAG0ybT0iS1jv4Tskpmdawpi9smZXcWOfLxZZFAWizWijGBEKOMz7UQ== Date: Tue, 13 Feb 2024 22:48:17 +0100 From: "Pankaj Raghav (Samsung)" To: "Darrick J. Wong" Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, mcgrof@kernel.org, gost.dev@samsung.com, akpm@linux-foundation.org, kbusch@kernel.org, chandan.babu@oracle.com, p.raghav@samsung.com, linux-kernel@vger.kernel.org, hare@suse.de, willy@infradead.org, linux-mm@kvack.org, david@fromorbit.com Subject: Re: [RFC v2 12/14] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Message-ID: References: <20240213093713.1753368-1-kernel@pankajraghav.com> <20240213093713.1753368-13-kernel@pankajraghav.com> <20240213162611.GP6184@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240213162611.GP6184@frogsfrogsfrogs> X-Rspamd-Queue-Id: E6649160005 X-Rspam-User: X-Stat-Signature: uk6efbk8cagscr81to1st7n3m35u6yi5 X-Rspamd-Server: rspam01 X-HE-Tag: 1707860904-785165 X-HE-Meta: U2FsdGVkX1+aEkGqtCa96gpi6Nxlzpg6342aebGriRAo4FmAATuPIXki759Nl12WBLb/4yW4I/k4PK3Y/G6PZPCNNthBHHEwdq5EUwgb06pGujm/2Ie4tgEslRHpgCHSXeMKz/yPXv3zghmcRb3vPkC9tZm4RVgzqqwI2IxBe7EVvyjYpTWfy0T/+o9okfnTN3XKn8gFa/I+ram1a/cz/JBleSLUd/T7QpJhBgSU4IPIXqmf1WWs3tLjFCc8fE4Q/9HJv2GSSArGWvDPrA0bdKR7gt+L6YcoDYoGFqorpf8HOnLYI903Vc1VEH/lK63S+lKJ8S5RUJGogOAAMnhiW14MaTEbAGDq+O3FeUihqSADkCnD55m9Dm9kUR+KD689GxQX9KToxcTOktXrBMSvkN3m4B21ipdUL/0EYUICjEq6LIUe0lSlRBMJfLvpW7AcowlmUr3O+g/L8w/nGX4YR20M2MW3DjV0Uax0MA2DJQMvq1eZ1dqIFyfFW0pspjwDWos3wf2FS4eCw/1g9lbAQ07sVC31j0pmA+v3WElGHSpRTQCqLeEW/LZ8SmmYrhGXNCNfAAQS7LiYIpaDCaO7SgB7Ec3CHruu217PgxgVG1LVv9IA74AUrDm8K/L6u2YWh8Nds6njH2MIc42Ft7k3We+E4WLBwccKDBF7+HLpNRBbHycpbu2qwX+Sv7AdVkOUfqgOqle5+MMQFm2e1/MBTwvDeiuzJOOGkxjOIeLFyXh57EM4yDnLVJGXrkSztshAcQV/5Uheh5SPXjCf0Bo+avlhd8g996TvoHHXtCOGlUv2opTBMT+oBo9Y+SWcDYveqpSf0QLD3XsU+IWS5JP8+JWu/xPFYjd882Prv2IQxsIvQpvF/uEZehhsK6emvOngGMsNU3YR30s= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 13, 2024 at 08:26:11AM -0800, Darrick J. Wong wrote: > On Tue, Feb 13, 2024 at 10:37:11AM +0100, Pankaj Raghav (Samsung) wrote: > > From: Pankaj Raghav > > > > Instead of assuming that PAGE_SHIFT is always higher than the blocklog, > > make the calculation generic so that page cache count can be calculated > > correctly for LBS. > > > > Signed-off-by: Pankaj Raghav > > --- > > fs/xfs/xfs_mount.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > > index aabb25dc3efa..bfbaaecaf668 100644 > > --- a/fs/xfs/xfs_mount.c > > +++ b/fs/xfs/xfs_mount.c > > @@ -133,9 +133,13 @@ xfs_sb_validate_fsb_count( > > { > > ASSERT(PAGE_SHIFT >= sbp->sb_blocklog); > > ASSERT(sbp->sb_blocklog >= BBSHIFT); > > + unsigned long mapping_count; > > Nit: indenting > > unsigned long mapping_count; I will add this in the next revision. > > > + uint64_t bytes = nblocks << sbp->sb_blocklog; > > What happens if someone feeds us a garbage fs with sb_blocklog > 64? > Or did we check that previously, so an overflow isn't possible? > I was thinking of possibility of an overflow but at the moment the blocklog is capped at 16 (65536 bytes) right? mkfs refuses any block sizes more than 64k. And we have check for this in xfs_validate_sb_common() in the kernel, which will catch it before this happens? > > + > > + mapping_count = bytes >> PAGE_SHIFT; > > Does this result in truncation when unsigned long is 32 bits? Ah, good point. So it is better to use uint64_t for mapping_count as well to be on the safe side? > > --D > > > > > /* Limited by ULONG_MAX of page cache index */ > > - if (nblocks >> (PAGE_SHIFT - sbp->sb_blocklog) > ULONG_MAX) > > + if (mapping_count > ULONG_MAX) > > return -EFBIG; > > return 0; > > } > > -- > > 2.43.0 > > > >