2011/1/13 Jiri Slaby <jirislaby@xxxxxxxxx>: > On 01/13/2011 10:52 AM, Jiri Slaby wrote: >> On 01/07/2011 12:41 AM, akpm@xxxxxxxxxxxxxxxxxxxx wrote: >>> The mm-of-the-moment snapshot 2011-01-06-15-41 has been uploaded to >> >> Hi, after some uptime and several suspend/resume cycles, I got: >> WARNING: at fs/dcache.c:1359 d_set_d_op+0x82/0xb0() >> Hardware name: To Be Filled By O.E.M. >> Modules linked in: dvb_usb_af9015 tda18271 af9013 dvb_usb dvb_core >> Pid: 3474, comm: automount Tainted: G W 2.6.37-mm1_64+ #1344 >> Call Trace: >> [<ffffffff8106bd2a>] ? warn_slowpath_common+0x7a/0xb0 >> [<ffffffff8106bd75>] ? warn_slowpath_null+0x15/0x20 >> [<ffffffff81125a32>] ? d_set_d_op+0x82/0xb0 >> [<ffffffff8120d829>] ? autofs4_dir_mkdir+0x169/0x180 >> [<ffffffff8111caa8>] ? vfs_mkdir+0x78/0xa0 >> [<ffffffff811209e6>] ? sys_mkdirat+0xf6/0x110 >> [<ffffffff81120a13>] ? sys_mkdir+0x13/0x20 >> [<ffffffff81030dbb>] ? system_call_fastpath+0x16/0x1b > > Note that even the second WARN was trigerred too: > WARNING: at fs/dcache.c:1365 d_set_d_op+0x9e/0xb0() > Hardware name: To Be Filled By O.E.M. > flags=00004000 > Modules linked in: dvb_usb_af9015 tda18271 af9013 dvb_usb dvb_core > Pid: 3474, comm: automount Tainted: G W 2.6.37-mm1_64+ #1344 > Call Trace: > [<ffffffff8106bd2a>] ? warn_slowpath_common+0x7a/0xb0 > [<ffffffff8106be01>] ? warn_slowpath_fmt+0x41/0x50 > [<ffffffff81125a4e>] ? d_set_d_op+0x9e/0xb0 > [<ffffffff8120d829>] ? autofs4_dir_mkdir+0x169/0x180 > [<ffffffff8111caa8>] ? vfs_mkdir+0x78/0xa0 > [<ffffffff811209e6>] ? sys_mkdirat+0xf6/0x110 > [<ffffffff81120a13>] ? sys_mkdir+0x13/0x20 > [<ffffffff81030dbb>] ? system_call_fastpath+0x16/0x1b > > My d_set_d_op looks like: > WARN_ON(dentry->d_op); > if (WARN(dentry->d_flags & (DCACHE_OP_HASH | > DCACHE_OP_COMPARE | > DCACHE_OP_REVALIDATE | > DCACHE_OP_REVALIDATE_RCU| > DCACHE_OP_DELETE), > "flags=%.8x", dentry->d_flags)) { > dentry->d_flags &= ~(DCACHE_OP_HASH | DCACHE_OP_COMPARE | > DCACHE_OP_REVALIDATE | DCACHE_OP_REVALIDATE_RCU | > DCACHE_OP_DELETE); > } > > So DCACHE_OP_REVALIDATE remained set. > >> I changed those BUG_ONs to WARN_ONs intentionally because I had problems >> with that previously -- I had to: >> dentry->d_flags &= ~(DCACHE_OP_HASH | DCACHE_OP_COMPARE | >> DCACHE_OP_REVALIDATE | DCACHE_OP_REVALIDATE_RCU | >> DCACHE_OP_DELETE); >> >> in d_set_d_op to not oops when calling NULLish op->d_delete later. Thanks for reporting. I was a little over-optimistic in my assumption that filesysystems would be doing sane things with dentry->d_op. Al has audited these guys and has a pull request pending. In the meantime, avoiding the bug and flipping the bits off will work fine. Thanks, Nick -- 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