From: Aristeu Rozanski <aris@ruivo.org>
To: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
Cc: Matthew Wilcox <willy@infradead.org>,
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 <dhowells@redhat.com>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC PATCH] fs/hugetlb: Fix UBSAN warning reported on hugetlb
Date: Wed, 26 Oct 2022 10:50:29 -0400 [thread overview]
Message-ID: <Y1lJNepa22oMZ3tR@cathedrallabs.org> (raw)
In-Reply-To: <6e8246ae-c420-df00-c1d1-03c49c0ab1f1@linux.ibm.com>
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
next prev parent reply other threads:[~2022-10-26 14:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 7:26 Aneesh Kumar K.V
2022-09-08 16:53 ` Matthew Wilcox
2022-09-08 16:59 ` Aneesh Kumar K V
2022-10-26 14:50 ` Aristeu Rozanski [this message]
2022-10-26 18:11 ` Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1lJNepa22oMZ3tR@cathedrallabs.org \
--to=aris@ruivo.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox