[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+1xoqd0JJ-Z+hmwgdZkBiu1anEh6iz1jJboULPp-drUzO37Ew@mail.gmail.com>
Date: Wed, 11 Apr 2012 14:20:40 +0200
From: Sasha Levin <levinsasha928@...il.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: garlick@...l.gov, ericvh@...il.com, oleg@...hat.com,
eric.dumazet@...il.com, davem@...emloft.net, kuznet@....inr.ac.ru,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
davej@...hat.com
Subject: Re: ipv6: tunnel: hang when destroying ipv6 tunnel
>> Yes but in the unlikely event that this happens, the effect is a small
>> memory leak for the duration of the mount. On the other hand if the
>> fid is destroyed without successfully informing the server, then
>> subsequent operations that involve new file references will fail
>> when that fid number is reused, and the mount becomes unusable.
>
> I don't know whether Sasha's problem is caused by this patch or not.
> But p9_client_clunk() is called from many functions in fs/9p/ directory.
> They are assuming that p9_client_clunk() will call p9_fid_destroy() but
> this patch is breaking that assumption. I think this is the cause of hang which
> Sasha is experiencing because Sasha's trace shows that call_usermodehelper() is
> blocked by functions in fs/9p/ directory. Seems inconsistency state problem.
I'd be happy to try out any other patches or help debugging this issue.
Which behavior did this patch fix exactly? can I just revert it and
try running without it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists