Re: [RFC PATCH] fs/hugetlb: Fix UBSAN warning reported on hugetlb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux