Re: WARNING: at fs/dcache.c:1359 d_set_d_op [was: mmotm 2011-01-06-15-41 uploaded]

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

 



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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux