On Thu, Jul 20, 2023 at 01:35:37PM -0400, Gabriel Krisman Bertazi wrote:
> Eric Biggers writes:
>
> >> Another problem exists when turning a negative dentry to positive. If
> >> the negative dentry has a different case than what is currently being
> >> used for lookup, the dentry cannot be reuse
Eric Biggers writes:
>> Another problem exists when turning a negative dentry to positive. If
>> the negative dentry has a different case than what is currently being
>> used for lookup, the dentry cannot be reused without changing its name,
>> in order to guarantee filename-preserving semantics
On 7/20/23 14:06, Christoph Hellwig wrote:
On Fri, May 19, 2023 at 04:22:01PM +0200, Hannes Reinecke wrote:
I'm hitting this during booting:
[5.016324]
[5.030256] iomap_iter+0x11a/0x350
[5.030264] iomap_readahead+0x1eb/0x2c0
[5.030272] read_pages+0x5d/0x220
[5.030279] p
On Wed, May 24, 2023 at 02:33:13PM +0100, Matthew Wilcox wrote:
> As you can see, do_page_cache_ra() does limit readahead to i_size.
> Is ractl->mapping->host the correct way to find the inode? I always
> get confused.
As far as I can tell it is the right inode, the indirection through
file->f_ma
On Fri, May 19, 2023 at 04:22:01PM +0200, Hannes Reinecke wrote:
> I'm hitting this during booting:
> [5.016324]
> [5.030256] iomap_iter+0x11a/0x350
> [5.030264] iomap_readahead+0x1eb/0x2c0
> [5.030272] read_pages+0x5d/0x220
> [5.030279] page_cache_ra_unbounded+0x131/0x180
syzbot reports a f2fs bug as below:
UBSAN: array-index-out-of-bounds in fs/f2fs/f2fs.h:3275:19
index 1409 is out of range for type '__le32[923]' (aka 'unsigned int[923]')
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubs
Sorry, one more thing...
On Wed, Jul 19, 2023 at 06:19:11PM -0400, Gabriel Krisman Bertazi wrote:
>
> Another problem exists when turning a negative dentry to positive. If
> the negative dentry has a different case than what is currently being
> used for lookup, the dentry cannot be reused witho
