what is the . (dot) and + (plus) after the lock name in the kernel crash (task hung)?

I’ve found that there are dot and plus signs in the kernel crash when the kernel detected 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

What is the dot and plus signs between the brackets after the lock name?

Answer

Self-answered:

There is an answer in 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

The bit position indicates STATE, STATE-read, for each of the states listed above, and the character displayed in each indicates:

‘.’ acquired while irqs disabled and not in irq context ‘-‘ acquired in irq context ‘+’ acquired with irqs enabled ‘?’ acquired in irq context with irqs enabled.

Unused mutexes cannot be part of the cause of an error.

But the difference between the kernel document and the crash log is there were only four bits in the crash log, but 6 bits in the document.
Is is because, for somewhat reason, reclaim_fs in kernel/locking/lockdep_states.h of the linux source tree (v4.16).