Re: Bug using new ntfs3 file system driver (5.15.2 on Arch Linux)

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

 



On Tue, Dec 28, 2021 at 10:00:53PM +0100, August Wikerfors wrote:
> (resending from gmail due to bounce with outlook)
> 
> Hi, I ran into a bug with a very similar call trace, also when copying files
> with rsync from a filesystem mounted using ntfs3. I was able to reproduce it
> on both the default Arch Linux kernel (5.15.11-arch2-1) and on mainline
> 5.16-rc7.

Hi August!  This is very helpful; thank you for putting in the work to
figure this out.  I am still a little baffled:

> [  486.361177] RIP: 0010:0xffffff8306d925ff
> [  486.361192] Code: Unable to access opcode bytes at RIP 0xffffff8306d925d5.
> [  486.361214] RSP: 0018:ffffaa9ec0f8fb37 EFLAGS: 00010246
> [  486.361232] RAX: 0000000000000000 RBX: 00000000000002ab RCX: 0000000000000000
> [  486.361255] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> [  486.361279] RBP: ffaa9ec0f8fbf800 R08: 0000000000000000 R09: 0000000000000000
> [  486.361302] R10: 0000000000000000 R11: 0000000000000000 R12: ff99687f5746e000
> [  486.361324] R13: 00000001112ccaff R14: fffcbb8097368000 R15: 00000000000001ff
> [  486.361349]  ? page_cache_ra_unbounded+0x1c5/0x250
> [  486.361369]  ? filemap_get_pages+0x117/0x730
> [  486.361386]  ? make_kuid+0xf/0x20
> [  486.361401]  ? generic_permission+0x27/0x210
> [  486.361419]  ? walk_component+0x11d/0x1c0
> [  486.361435]  ? filemap_read+0xb9/0x360
> [  486.361451]  ? new_sync_read+0x159/0x1f0
> [  486.361467]  ? vfs_read+0xff/0x1a0
> [  486.361489]  ? ksys_read+0x67/0xf0
> [  486.361503]  ? do_syscall_64+0x5c/0x90
> 
> $ scripts/faddr2line vmlinux.5.15.11-arch2-1 page_cache_ra_unbounded+0x1c5/0x250
> page_cache_ra_unbounded+0x1c5/0x250:
> filemap_invalidate_unlock_shared at include/linux/fs.h:853
> (inlined by) page_cache_ra_unbounded at mm/readahead.c:240

So ... Jan added this code in commit 730633f0b7f9, but I don't see how
it could be buggy:

        filemap_invalidate_lock_shared(mapping);
... things that don't change mapping ...
        filemap_invalidate_unlock_shared(mapping);
and the _unlock_ appears to have a bad pointer.  Which makes no sense
to me.  Jan, any ideas?





[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux