bio-linux分区,linux磁盘写操作submit_bio

小鱼儿 2023-01-20 09:42 28阅读 0赞

系统挂起的日志就这样，我怀疑是某个锁没有释放，但是代码里面检查又没问题。

Oct 15 20:29:21 test-KVM kernel: \[  673.005765\] rcu: INFO: rcu\_sched self-detected stall on CPU

Oct 15 20:29:21 test-KVM kernel: \[  673.005772\] rcu:     0-....: (15293 ticks this GP) idle=08a/1/0x4000000000000002 softirq=99921/99922 fqs=6382

Oct 15 20:29:21 test-KVM kernel: \[  673.005775\]     (t=15000 jiffies g=85089 q=15217)

Oct 15 20:29:21 test-KVM kernel: \[  673.005776\] NMI backtrace for cpu 0

Oct 15 20:29:21 test-KVM kernel: \[  673.005779\] CPU: 0 PID: 9 Comm: ksoftirqd/0 Kdump: loaded Tainted: G           OEL    5.4.0-48-generic \#52~18.04.1-Ubuntu

Oct 15 20:29:21 test-KVM kernel: \[  673.005780\] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011

Oct 15 20:29:21 test-KVM kernel: \[  673.005781\] Call Trace:

Oct 15 20:29:21 test-KVM kernel: \[  673.005784\]

Oct 15 20:29:21 test-KVM kernel: \[  673.005791\]  dump\_stack+0x6d/0x95

Oct 15 20:29:21 test-KVM kernel: \[  673.005795\]  nmi\_cpu\_backtrace+0x94/0xa0

Oct 15 20:29:21 test-KVM kernel: \[  673.005798\]  ? lapic\_can\_unplug\_cpu+0xb0/0xb0

Oct 15 20:29:21 test-KVM kernel: \[  673.005801\]  nmi\_trigger\_cpumask\_backtrace+0xe7/0x130

Oct 15 20:29:21 test-KVM kernel: \[  673.005803\]  arch\_trigger\_cpumask\_backtrace+0x19/0x20

Oct 15 20:29:21 test-KVM kernel: \[  673.005808\]  rcu\_dump\_cpu\_stacks+0x9e/0xd6

Oct 15 20:29:21 test-KVM kernel: \[  673.005811\]  rcu\_sched\_clock\_irq+0x508/0x770

Oct 15 20:29:21 test-KVM kernel: \[  673.005815\]  ? tick\_sched\_do\_timer+0x60/0x60

Oct 15 20:29:21 test-KVM kernel: \[  673.005817\]  update\_process\_times+0x28/0x60

Oct 15 20:29:21 test-KVM kernel: \[  673.005820\]  tick\_sched\_handle+0x25/0x70

Oct 15 20:29:21 test-KVM kernel: \[  673.005822\]  ? tick\_sched\_do\_timer+0x58/0x60

Oct 15 20:29:21 test-KVM kernel: \[  673.005824\]  tick\_sched\_timer+0x3c/0x80

Oct 15 20:29:21 test-KVM kernel: \[  673.005827\]  \_\_hrtimer\_run\_queues+0x10f/0x280

Oct 15 20:29:21 test-KVM kernel: \[  673.005829\]  hrtimer\_interrupt+0xe7/0x240

Oct 15 20:29:21 test-KVM kernel: \[  673.005834\]  smp\_apic\_timer\_interrupt+0x6f/0x130

Oct 15 20:29:21 test-KVM kernel: \[  673.005836\]  apic\_timer\_interrupt+0xf/0x20

Oct 15 20:29:21 test-KVM kernel: \[  673.005837\]

Oct 15 20:31:40 test-KVM kernel: \[  812.084138\] watchdog: BUG: soft lockup - CPU\#0 stuck for 23s! \[ksoftirqd/0:9\]

Oct 15 20:31:40 test-KVM kernel: \[  812.084142\] Modules linked in: intel\_rapl\_msr intel\_rapl\_common crct10dif\_pclmul crc32\_pclmul ghash\_clmulni\_intel aesni\_intel crypto\_simd cryptd glue\_helper snd\_hda\_codec\_generic ledtrig\_audio snd\_hda\_intel snd\_intel\_dspcfg snd\_hda\_codec snd\_hda\_core snd\_hwdep snd\_pcm snd\_seq\_midi snd\_seq\_midi\_event snd\_rawmidi snd\_seq snd\_seq\_device snd\_timer joydev snd input\_leds serio\_raw soundcore mac\_hid qemu\_fw\_cfg sch\_fq\_codel cloudisk(OE) blkagent(OE) cdptrans(OE) parport\_pc ppdev lp parport ip\_tables x\_tables autofs4 qxl ttm drm\_kms\_helper syscopyarea sysfillrect 8139too sysimgblt fb\_sys\_fops drm psmouse 8139cp pata\_acpi mii i2c\_piix4 floppy

Oct 15 20:31:40 test-KVM kernel: \[  812.084171\] CPU: 0 PID: 9 Comm: ksoftirqd/0 Kdump: loaded Tainted: G           OEL    5.4.0-48-generic \#52~18.04.1-Ubuntu

Oct 15 20:31:40 test-KVM kernel: \[  812.084173\] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011

Oct 15 20:31:40 test-KVM kernel: \[  812.084178\] RIP: 0010:\_raw\_spin\_unlock\_irqrestore+0x15/0x20

Oct 15 20:31:40 test-KVM kernel: \[  812.084181\] Code: e8 60 85 60 ff 4c 29 e0 4c 39 f0 76 cf 80 0b 08 eb 8a 90 90 90 0f 1f 44 00 00 55 48 89 e5 e8 f6 e5 62 ff 66 90 48 89 f7 57 9d <0f> 1f 44 00 00 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5 c6 07

Oct 15 20:31:40 test-KVM kernel: \[  812.084182\] RSP: 0018:ffffb85c80053d50 EFLAGS: 00000202 ORIG\_RAX: ffffffffffffff13

Oct 15 20:31:40 test-KVM kernel: \[  812.084185\] RAX: 0000000000000001 RBX: ffff99a26e5028d8 RCX: ffffb85c80035000

Oct 15 20:31:40 test-KVM kernel: \[  812.084186\] RDX: ffffb85c800380ff RSI: 0000000000000202 RDI: 0000000000000202

Oct 15 20:31:40 test-KVM kernel: \[  812.084187\] RBP: ffffb85c80053d50 R08: 0000000000000138 R09: 0000000000000100

Oct 15 20:31:40 test-KVM kernel: \[  812.084188\] R10: 0000000000000028 R11: ffff99a1d071a800 R12: ffff99a26e5028d0

Oct 15 20:31:40 test-KVM kernel: \[  812.084189\] R13: ffff99a279103280 R14: 0000000000000280 R15: 0000000000000028

Oct 15 20:31:40 test-KVM kernel: \[  812.084191\] FS:  0000000000000000(0000) GS:ffff99a27ba00000(0000) knlGS:0000000000000000

Oct 15 20:31:40 test-KVM kernel: \[  812.084192\] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

Oct 15 20:31:40 test-KVM kernel: \[  812.084193\] CR2: 00007fa389de87a0 CR3: 000000012ec38004 CR4: 00000000003606f0

Oct 15 20:31:40 test-KVM kernel: \[  812.084198\] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

Oct 15 20:31:40 test-KVM kernel: \[  812.084199\] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Oct 15 20:31:40 test-KVM kernel: \[  812.084200\] Call Trace:

Oct 15 20:31:40 test-KVM kernel: \[  812.084208\]  cp\_rx\_poll+0x4bf/0x590 \[8139cp\]

Oct 15 20:31:40 test-KVM kernel: \[  812.084212\]  ? dev\_cpu\_dead+0x190/0x190

Oct 15 20:31:40 test-KVM kernel: \[  812.084216\]  ? free\_compound\_page+0x2a/0x30

Oct 15 20:31:40 test-KVM kernel: \[  812.084220\]  net\_rx\_action+0x140/0x3c0

Oct 15 20:31:40 test-KVM kernel: \[  812.084224\]  \_\_do\_softirq+0xe4/0x2da

Oct 15 20:31:40 test-KVM kernel: \[  812.084228\]  run\_ksoftirqd+0x2b/0x40

Oct 15 20:31:40 test-KVM kernel: \[  812.084231\]  smpboot\_thread\_fn+0xfc/0x170

Oct 15 20:31:40 test-KVM kernel: \[  812.084235\]  kthread+0x121/0x140

Oct 15 20:31:40 test-KVM kernel: \[  812.084237\]  ? sort\_range+0x30/0x30

Oct 15 20:31:40 test-KVM kernel: \[  812.084239\]  ? kthread\_park+0x90/0x90

Oct 15 20:31:40 test-KVM kernel: \[  812.084241\]  ret\_from\_fork+0x35/0x40

【 在 colyli 的大作中提到: 】

: 最简单的处理方式，你可以在驱动里设置一个队列然后uninterruptible的睡在这个队列里。然后在bi\_end\_io的中断上下文里将这个队列唤醒。然后在那个被唤醒的任务的work queue上下文里，你就可以判断bi\_status然后做后面的处理了。  (估计上面这些您都了解，我有些班门弄斧了)