On Thu, May 16, 2013 at 07:34:15PM +0800, majianpeng wrote:
> Thanks very much! I'll take times to understand.
> Can you send a patch about this?
You mean the below or something else?
---
Subject: f2fs, lockdep: Annotate mutex_lock_all()
Majianpeng reported a lockdep splat for f2fs. It turns ou
On 05/16/2013 04:41 PM, Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 09:16:45AM +0800, majianpeng wrote:
>
>>> There isn't. What you typically want to do is annotate the lock site.
>>> In particular it looks like mutex_lock_all() is the offensive piece of
>>> code (horrible function name though;
On Thu, May 16, 2013 at 09:16:45AM +0800, majianpeng wrote:
> > There isn't. What you typically want to do is annotate the lock site.
> > In particular it looks like mutex_lock_all() is the offensive piece of
> > code (horrible function name though; the only redeeming thing being that
> > f2fs.h i
On 05/15/2013 04:28 PM, Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 02:58:53PM +0800, majianpeng wrote:
>> When mounted the f2fs, kernel will print the following messages:
>>
>> [ 105.533038] =
>> [ 105.533065] [ INFO: possible recursive locking det
On Wed, May 15, 2013 at 02:58:53PM +0800, majianpeng wrote:
> When mounted the f2fs, kernel will print the following messages:
>
> [ 105.533038] =
> [ 105.533065] [ INFO: possible recursive locking detected ]
> [ 105.533088] 3.10.0-rc1+ #101 Not taint
On 05/15/2013 03:21 PM, Libo Chen wrote:
> On 2013/5/15 14:58, majianpeng wrote:
>> By adding some messages, i found this problem because the gcc
>> optimizing. For those codes:
for (i = 0; i < NR_GLOBAL_LOCKS; i++)
mutex_init(&sbi->fs_lock[i]);
>> The defination of
On 2013/5/15 14:58, majianpeng wrote:
> By adding some messages, i found this problem because the gcc
> optimizing. For those codes:
>> >for (i = 0; i < NR_GLOBAL_LOCKS; i++)
>> >mutex_init(&sbi->fs_lock[i]);
> The defination of mutex_init is:
>> > #define mutex_init(mutex)
7 matches
Mail list logo
