On 14 January 2016 at 17:23, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jan 14, 2016 at 04:58:48PM +0100, Tomeu Vizoso wrote: >> > Could you add >> > printk(KERN_ERR "i_data = %p, i_mapping = %p, flags: %lx\n", >> > &inode->i_data, >> > inode->i_mapping, >> > (unsigned long)inode->i_data.flags); >> > right before the return from nfs_get_link() and see what it prints? >> >> Here it is: >> >> [ 170.136956] i_data = ed9c1b04, i_mapping = ed9c1b04, flags: 24200c0 >> [ 170.144567] i_data = ed9de784, i_mapping = ed9de784, flags: 24200c0 >> [ 170.151457] i_data = ed9dec84, i_mapping = ed9dec84, flags: 24200c0 >> [ 170.158358] i_data = ed9c3b84, i_mapping = ed9c3b84, flags: 24200c0 >> [ 170.165253] i_data = ed9d4204, i_mapping = ed9d4204, flags: 24200c0 >> [ 170.172131] i_data = ed9df184, i_mapping = ed9df184, flags: 24200c0 >> [ 170.188804] i_data = eddbce84, i_mapping = eddbce84, flags: 24200c0 >> [ 170.196158] i_data = ec904984, i_mapping = ec904984, flags: 24200c0 >> [ 170.205133] i_data = ec906784, i_mapping = ec906784, flags: 24200c0 > > Aha. So ->i_data vs. ->i_mapping is irrelevant (as it ought to be here) > and inode_nohighmem() should've acted on the address_space we are hitting > here. What do we have in flags... ___GFP_IO | ___GFP_FS | ___GFP_HARDWALL | > ___GFP_DIRECT_RECLAIM | ___GFP_KSWAPD_RECLAIM. IOW, normal GFP_USER, no > __GFP_HIGHMEM in sight. > > So either we have a highmem page somehow ending up in i_data before we > set the flags, or __page_cache_alloc() done by read_cache_page() returns > us a highmem page on GFP_USER | __GFP_COLD (or I'm misreading the things > completely)... > > Could you slap > printk(KERN_ERR "inode: %p, pages: %ld\n", > inode, inode->i_data.nrpages); > before that read_cache_page() in nfs_get_link() and > printk(KERN_ERR "page_address: %p\n", page_address(page)); > right before the return? Here it is: [ 170.715356] inode: ec8c30b0, pages: 1 [ 170.719014] page_address: (null) https://lava.collabora.co.uk/scheduler/job/127698/log_file Regards, Tomeu -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
