是什么 。 （点）和 +（加号）在内核崩溃（任务挂起）中的锁名称之后？
what is the . (dot) and + (plus) after the lock name in the kernel crash (task hung)?
我发现内核检测到task hung时内核崩溃有点号和加号。
Showing all locks held in the system:
2 locks held by khungtaskd/737:
#0: (rcu_read_lock){....}, at: [<00000000eaa2e968>] check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: (rcu_read_lock){....}, at: [<00000000eaa2e968>] watchdog+0x1c5/0xd60 kernel/hung_task.c:249
#1: (tasklist_lock){.+.+}, at: [<000000005ed461f9>] debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4464
锁名称后括号中的点号和加号是什么？
自我回答：
the linux document 中有答案。
State
The validator tracks lock-class usage history into 4n + 1 separate
state bits:
- 'ever held in STATE context'
- 'ever held as readlock in STATE context'
- 'ever held with STATE enabled'
- 'ever held as readlock with STATE enabled'
Where STATE can be either one of (kernel/locking/lockdep_states.h)
- hardirq
- softirq
- reclaim_fs
- 'ever used' [ == !unused ]
When locking rules are violated, these state bits are presented in the
locking error messages, inside curlies. A contrived example:
modprobe/2287 is trying to acquire lock:
(&sio_locks[i].lock){-.-...}, at: [] mutex_lock+0x21/0x24
but task is already holding lock:
(&sio_locks[i].lock){-.-...}, at: [] mutex_lock+0x21/0x24
位位置表示每个状态的STATE，STATE-read
上面列出的，每个显示的字符表示：
'.'在禁用 irq 且不在 irq 上下文“-”中时获取
在 irq 上下文中获取 '+' 在启用 irq 的情况下获取 '?'
在启用 irq 的 irq 上下文中获取。
未使用的互斥锁不能是错误原因的一部分。
但是内核文件和崩溃日志的区别在于崩溃日志只有四位，而文件中有六位。
是因为，出于某种原因，linux 源代码树 (v4.16) 的 kernel/locking/lockdep_states.h 中的 reclaim_fs。
我发现内核检测到task hung时内核崩溃有点号和加号。
Showing all locks held in the system: 2 locks held by khungtaskd/737: #0: (rcu_read_lock){....}, at: [<00000000eaa2e968>] check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline] #0: (rcu_read_lock){....}, at: [<00000000eaa2e968>] watchdog+0x1c5/0xd60 kernel/hung_task.c:249 #1: (tasklist_lock){.+.+}, at: [<000000005ed461f9>] debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4464
锁名称后括号中的点号和加号是什么？
自我回答：
the linux document 中有答案。
State
The validator tracks lock-class usage history into 4n + 1 separate state bits:
- 'ever held in STATE context'
- 'ever held as readlock in STATE context'
- 'ever held with STATE enabled'
- 'ever held as readlock with STATE enabled'
Where STATE can be either one of (kernel/locking/lockdep_states.h) - hardirq - softirq - reclaim_fs
- 'ever used' [ == !unused ]
When locking rules are violated, these state bits are presented in the locking error messages, inside curlies. A contrived example:
modprobe/2287 is trying to acquire lock:
(&sio_locks[i].lock){-.-...}, at: [] mutex_lock+0x21/0x24but task is already holding lock:
(&sio_locks[i].lock){-.-...}, at: [] mutex_lock+0x21/0x24位位置表示每个状态的STATE，STATE-read 上面列出的，每个显示的字符表示：
'.'在禁用 irq 且不在 irq 上下文“-”中时获取 在 irq 上下文中获取 '+' 在启用 irq 的情况下获取 '?' 在启用 irq 的 irq 上下文中获取。
未使用的互斥锁不能是错误原因的一部分。
但是内核文件和崩溃日志的区别在于崩溃日志只有四位，而文件中有六位。
是因为，出于某种原因，linux 源代码树 (v4.16) 的 kernel/locking/lockdep_states.h 中的 reclaim_fs。