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 D3AABC433FE for ; Wed, 26 Oct 2022 14:50:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CBCE8E0002; Wed, 26 Oct 2022 10:50:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 654828E0001; Wed, 26 Oct 2022 10:50:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51DC78E0002; Wed, 26 Oct 2022 10:50:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 445688E0001 for ; Wed, 26 Oct 2022 10:50:50 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 14293A094D for ; Wed, 26 Oct 2022 14:50:50 +0000 (UTC) X-FDA: 80063387460.23.45806DD Received: from lobo.ruivo.org (lobo.ruivo.org [173.14.175.98]) by imf18.hostedemail.com (Postfix) with ESMTP id 8180A1C0043 for ; Wed, 26 Oct 2022 14:50:48 +0000 (UTC) Received: by lobo.ruivo.org (Postfix, from userid 1011) id 6C61952E5C; Wed, 26 Oct 2022 10:50:47 -0400 (EDT) Received: from jake.ruivo.org (bob.qemu.ruivo [192.168.72.19]) by lobo.ruivo.org (Postfix) with ESMTPA id 81027529B6; Wed, 26 Oct 2022 10:50:29 -0400 (EDT) Received: by jake.ruivo.org (Postfix, from userid 1000) id 7E93D220062; Wed, 26 Oct 2022 10:50:29 -0400 (EDT) Date: Wed, 26 Oct 2022 10:50:29 -0400 From: Aristeu Rozanski To: Aneesh Kumar K V Cc: Matthew Wilcox , linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, linux-mm@kvack.org, akpm@linux-foundation.org, David Howells , linux-fsdevel@vger.kernel.org, Al Viro Subject: Re: [RFC PATCH] fs/hugetlb: Fix UBSAN warning reported on hugetlb Message-ID: References: <20220908072659.259324-1-aneesh.kumar@linux.ibm.com> <6e8246ae-c420-df00-c1d1-03c49c0ab1f1@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e8246ae-c420-df00-c1d1-03c49c0ab1f1@linux.ibm.com> User-Agent: Mutt/2.2.3 (2022-04-12) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666795848; a=rsa-sha256; cv=none; b=an69Z1/XsDiKomwSWXv9xWvHQKWCPbsmqNzAfVkWfAUHlmX9gYql72Ah4GOjLsf5QJNgvV L8uX/ssLI2SxAp2GrcLppGALThMQiJTtC6V8e56GjeGWhG8RWKCOtYtxaMdXetYqtDFKeL YL+JmSxXe/NgWKfo1Mv9wCe+wKTZqYY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=none; spf=none (imf18.hostedemail.com: domain of aris@ruivo.org has no SPF policy when checking 173.14.175.98) smtp.mailfrom=aris@ruivo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666795848; 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; bh=QYGhIOkTe6X7njUVpIkMbW2T5jMIhqmtOno5XQSQMNE=; b=wAkb/DloEHEl4w8M2rQ2Sljj7Z9fvpWQ2teOw24/EE15c1lQLe7BAsSD9NKNgvOZHxXFM+ fkK5DXr9/yqT+Jcslu4/smQ89v+KWPg0NfYTqRnAL63VAheMRdqlKlejZ7//0gmbHmnAFw 37vf+IBOCSqzYMvgKHXm4Xf7tDdOix8= X-Stat-Signature: jax71mgsi14uhtfyk4w81xa1kos4kssa X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8180A1C0043 Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=none; spf=none (imf18.hostedemail.com: domain of aris@ruivo.org has no SPF policy when checking 173.14.175.98) smtp.mailfrom=aris@ruivo.org X-HE-Tag: 1666795848-547913 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: On Thu, Sep 08, 2022 at 10:29:59PM +0530, Aneesh Kumar K V wrote: > On 9/8/22 10:23 PM, Matthew Wilcox wrote: > > On Thu, Sep 08, 2022 at 12:56:59PM +0530, Aneesh Kumar K.V wrote: > >> +++ b/fs/dax.c > >> @@ -1304,7 +1304,7 @@ EXPORT_SYMBOL_GPL(dax_zero_range); > >> int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero, > >> const struct iomap_ops *ops) > >> { > >> - unsigned int blocksize = i_blocksize(inode); > >> + size_t blocksize = i_blocksize(inode); > >> unsigned int off = pos & (blocksize - 1); > > > > If blocksize is larger than 4GB, then off also needs to be size_t. > > > >> +++ b/fs/iomap/buffered-io.c > >> @@ -955,7 +955,7 @@ int > >> iomap_truncate_page(struct inode *inode, loff_t pos, bool *did_zero, > >> const struct iomap_ops *ops) > >> { > >> - unsigned int blocksize = i_blocksize(inode); > >> + size_t blocksize = i_blocksize(inode); > >> unsigned int off = pos & (blocksize - 1); > > > > Ditto. > > > > (maybe there are others; I didn't check closely) > > Thanks. will check those. > > Any feedback on statx? Should we really fix that? > > I am still not clear why we chose to set blocksize = pagesize for hugetlbfs. > Was that done to enable application find the hugetlb pagesize via stat()? I'd like to know that as well. It'd be easier to just limit the hugetlbfs max blocksize to 4GB. It's very unlikely anything else will use such large blocksizes and having to introduce new user interfaces for it doesn't sound right. -- Aristeu