Most recent kernel where this bug did *NOT* occur: 2.6.19 Distribution: FC6 (64bit) Hardware Environment: Single AMD64 3500+, 1GB RAM Software Environment: Stock FC6 with latest updates gcc-4.1.1-51.fc6 binutils-2.17.50.0.6-2.fc6 Problem Description: After some time of activity I get BUG: at /home/andrew/src/linux-2.6/mm/truncate.c:425 invalidate_inode_pages2_range() Call Trace: [<ffffffff8024c335>] invalidate_inode_pages2_range+0x2a5/0x2d0 [<ffffffff802d551f>] nfs_revalidate_mapping+0xaf/0x160 [<ffffffff802d3ac5>] nfs_file_read+0x65/0xe0 [<ffffffff80263e5f>] do_sync_read+0xcf/0x120 [<ffffffff802d38d0>] nfs_file_open+0x0/0x80 [<ffffffff802394c0>] autoremove_wake_function+0x0/0x30 [<ffffffff8026255d>] do_filp_open+0x2d/0x40 [<ffffffff804fbda9>] mutex_lock+0x9/0x20 [<ffffffff802647ba>] vfs_read+0xba/0x180 [<ffffffff80264c03>] sys_read+0x53/0x90 [<ffffffff80209a0e>] system_call+0x7e/0x83 In dmesg. Steps to reproduce: I have some NFS mounted fileystems including my home dir /dev/sda1 on / type ext3 (rw) /dev/proc on /proc type proc (rw) /dev/sys on /sys type sysfs (rw) /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/shm on /dev/shm type tmpfs (rw) homes.systems.pccl.info:/home/andrew on /home/andrew type nfs (rw,nfsvers=3,hard,intr,rsize=16384,wsize=16384,addr=192.168.1.5) homes.systems.pccl.info:/home/storage/apps on /mnt/autofs/apps type nfs (ro,nfsvers=3,hard,intr,rsize=16384,addr=192.168.1.5) I was last using 2.6.19 where this didn't occur. I then updated to 2.6.20-rc4 where I noticed this BUG. This morning I updated to 2.6.20-rc5. It seemed to take a bit longer for this BUG to happen, before it seemed to happen with sylpheed-claws where its mail files are stored in my NFS mounted home dir, this time I noticed it after I had started mplayer on an ogg vorbis file out of my NFS mounted home dir. Cheers,
Not a bug! It is perfectly legal and acceptable for the user to ^C out of a hanging process. In that case, the NFS client will also abandon the attempt to invalidate the page cache, and just defer doing so until the next process needs to access that data. That WARN_ON crap that Andrew merged into invalidate_inode_pages2_range() needs to be thrown out.
Agreed, this is not a bug if the callers handle it correctly. Can we send a patch to remove the WARN_ON_ONCE, and close this?
we already did, I think.