fuse try to freeze with lock held

fuse try to freeze with lock held

[Liu, Chuansheng]

Hit the below warning when enabling the CONFIG_DEBUG_LOCK_ALLOC,
__fuse_request_send == >
request_wait_answer == >
wait_event_freezable == >
try_to_freeze()

But here the inode->i_mutex is hold yet in vfs_readdir().

Could anyone give some help? Thanks.


[ 3148.552435] Freezing user space processes ... [ 3148.557781]
[ 3148.559505] =====================================
[ 3148.564803] [ BUG: du/21716 still has locks held! ]
[ 3148.570319] 3.10.16-261493-g1308ae2 #8 Tainted: G        W  O

[ 3148.586082]  #0:  (&type->i_mutex_dir_key#3){......}, at: [<c1341dc6>] vfs_readdir+0x66/0xd0
[ 3148.595967]
[ 3148.595967] stack backtrace:
[ 3148.600875] CPU: 2 PID: 21716 Comm: du Tainted: G        W  O 3.10.16-261493-g1308ae2 #8
[ 3148.609973]  d7e494e0 d7e494e0 cca6be78 c1b0fccb cca6be90 c12913f1 c1db2cc5 d7e497e4
[ 3148.618872]  000054d4 cca6beac cca6becc c1440d8b d7e494e0 f2557800 f12acedc 00000000
[ 3148.627747]  00000000 00000000 d7e494e0 c125f100 cca6beb8 cca6beb8 f12ace40 f2557800
[ 3148.636614] Call Trace:
[ 3148.639395]  [<c1b0fccb>] dump_stack+0x16/0x18
[ 3148.644375]  [<c12913f1>] debug_check_no_locks_held+0x91/0xa0
[ 3148.650862]  [<c1440d8b>] __fuse_request_send+0x14b/0x320
[ 3148.656961]  [<c125f100>] ? wake_up_bit+0x30/0x30
[ 3148.662242]  [<c1440f71>] fuse_request_send+0x11/0x20
[ 3148.667941]  [<c14455a9>] fuse_readdir+0x109/0x690
[ 3148.673327]  [<c1341dc6>] ? vfs_readdir+0x66/0xd0
[ 3148.678636]  [<c1b1bec5>] ? sub_preempt_count+0x45/0x60
[ 3148.684503]  [<c1b15694>] ? mutex_lock_killable_nested+0x214/0x300
[ 3148.691457]  [<c1341b60>] ? SyS_ioctl+0x90/0x90
[ 3148.696553]  [<c1341dc6>] ? vfs_readdir+0x66/0xd0
[ 3148.701857]  [<c1341b60>] ? SyS_ioctl+0x90/0x90

Re: [fuse-devel] fuse try to freeze with lock held

[Miklos Szeredi]

On Wed, Nov 27, 2013 at 3:19 AM, Liu, Chuansheng
<chuansheng.liu@intel.com> wrote:
> Hit the below warning when enabling the CONFIG_DEBUG_LOCK_ALLOC,
> __fuse_request_send == >
> request_wait_answer == >
> wait_event_freezable == >
> try_to_freeze()
>
> But here the inode->i_mutex is hold yet in vfs_readdir().
>
> Could anyone give some help? Thanks.
>

Mainline doesn't have wait_event_freezable() in fuse.  What kernel
variant is this?

Thanks,
Miklos



>
> [ 3148.552435] Freezing user space processes ... [ 3148.557781]
> [ 3148.559505] =====================================
> [ 3148.564803] [ BUG: du/21716 still has locks held! ]
> [ 3148.570319] 3.10.16-261493-g1308ae2 #8 Tainted: G        W  O
>
> [ 3148.586082]  #0:  (&type->i_mutex_dir_key#3){......}, at: [<c1341dc6>] vfs_readdir+0x66/0xd0
> [ 3148.595967]
> [ 3148.595967] stack backtrace:
> [ 3148.600875] CPU: 2 PID: 21716 Comm: du Tainted: G        W  O 3.10.16-261493-g1308ae2 #8
> [ 3148.609973]  d7e494e0 d7e494e0 cca6be78 c1b0fccb cca6be90 c12913f1 c1db2cc5 d7e497e4
> [ 3148.618872]  000054d4 cca6beac cca6becc c1440d8b d7e494e0 f2557800 f12acedc 00000000
> [ 3148.627747]  00000000 00000000 d7e494e0 c125f100 cca6beb8 cca6beb8 f12ace40 f2557800
> [ 3148.636614] Call Trace:
> [ 3148.639395]  [<c1b0fccb>] dump_stack+0x16/0x18
> [ 3148.644375]  [<c12913f1>] debug_check_no_locks_held+0x91/0xa0
> [ 3148.650862]  [<c1440d8b>] __fuse_request_send+0x14b/0x320
> [ 3148.656961]  [<c125f100>] ? wake_up_bit+0x30/0x30
> [ 3148.662242]  [<c1440f71>] fuse_request_send+0x11/0x20
> [ 3148.667941]  [<c14455a9>] fuse_readdir+0x109/0x690
> [ 3148.673327]  [<c1341dc6>] ? vfs_readdir+0x66/0xd0
> [ 3148.678636]  [<c1b1bec5>] ? sub_preempt_count+0x45/0x60
> [ 3148.684503]  [<c1b15694>] ? mutex_lock_killable_nested+0x214/0x300
> [ 3148.691457]  [<c1341b60>] ? SyS_ioctl+0x90/0x90
> [ 3148.696553]  [<c1341dc6>] ? vfs_readdir+0x66/0xd0
> [ 3148.701857]  [<c1341b60>] ? SyS_ioctl+0x90/0x90
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> fuse-devel mailing list
> fuse-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fuse-devel

RE: [fuse-devel] fuse try to freeze with lock held

[Liu, Chuansheng]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1016 bytes --]

Hello Miklos,

> -----Original Message-----
> From: Miklos Szeredi [mailto:miklos@szeredi.hu]
> Sent: Wednesday, December 11, 2013 11:35 PM
> To: Liu, Chuansheng
> Cc: mszeredi@suse.cz; fuse-devel@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [fuse-devel] fuse try to freeze with lock held
> 
> On Wed, Nov 27, 2013 at 3:19 AM, Liu, Chuansheng
> <chuansheng.liu@intel.com> wrote:
> > Hit the below warning when enabling the CONFIG_DEBUG_LOCK_ALLOC,
> > __fuse_request_send == >
> > request_wait_answer == >
> > wait_event_freezable == >
> > try_to_freeze()
> >
> > But here the inode->i_mutex is hold yet in vfs_readdir().
> >
> > Could anyone give some help? Thanks.
> >
> 
> Mainline doesn't have wait_event_freezable() in fuse.  What kernel
> variant is this?
> 
Thanks your pointing out, it is my fault since it is not mainline.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥