sysbench压测directio+fsync时的问题

来源：互联网发布：电机控制算法书籍编辑：程序博客网时间：2024/05/22 10:22

最近准备release一个新版本的kernel，里面收了一些优化的patch和bugfix，在regression 的时候，在dom0上用sysbench压测磁盘IO, 在多台VM上用ltp压测networkstress时，出现了kernel panic的问题，加一些warning的日志

kernel BUG at kernel/workqueue.c:287!invalid opcode: 0000 [#1] SMP

kernel BUG at kernel/workqueue.c:191!invalid opcode: 0000 [#2] SMP

有两个workqueue相关的BUG，对应到BUG_ON(get_wq_data(work) != cwq); BUG_ON(!list_empty(&work->entry));

还有几个list_add corruption

WARNING: at lib/list_debug.c:30 __list_add+0x6e/0x87()Hardware name: XS23-TY35list_add corruption. prev->next should be next (ffff8801e71913b0), but was ffff8801e7193bb0. (prev=ffff8801e7193bb0).

 [<ffffffff8118d92f>] ext4_end_io_dio+0x71/0x82 [<ffffffff81139d48>] dio_complete+0x73/0xb4 [<ffffffff81139e11>] dio_bio_end_aio+0x88/0xb8 [<ffffffff81136334>] bio_endio+0x144/0x14d [<ffffffff812081c4>] req_bio_endio+0x9f/0xbe [<ffffffff8120838b>] blk_update_request+0x1a8/0x308 [<ffffffff8120850b>] blk_update_bidi_request+0x20/0x5c [<ffffffff81208fb2>] blk_end_bidi_request+0x1f/0x5e [<ffffffff81209001>] blk_end_request+0x10/0x15 [<ffffffff812df285>] scsi_io_completion+0x1b5/0x400

由于之前对于workqueue的实现不熟悉，为了学习下，就先从workqueue代码开始分析，从实现上来说，insert_work和run_workqueue都有cwq->lock保护着，并且work还有一个Pending位来表示状态，单从肉眼上看，找不出问题。

接着拿list_add开刀，由于几个corruption都在ext4_end_io_dio的地方，基本上可以定位到里面的list_add_tail有问题，大致有两处list_del_init的地方，一个在work func（ext4_end_aio_dio_work)里面，还有一个在ext4_sync_file调用的flush_aio_dio_completed_IO里面，看到这里就很明显地发现，这几处地方都没有加锁，除了list_del的地方有inode->mutex。好吧，问题找到了，看了下upstream的代码，的确多了一个list的spinlock，在每次list操作的地方都用加个spin_lock_irqsave，不得不感叹下我们的ext4版本真的太原始了

话说，打上patch之前，另外一台机器也出现问题了，栈和之前不太一样，但是也有list_add corruption。

 [<ffffffff8118a0f8>] ext4_free_io_end+0x2b/0x2f [<ffffffff8100f902>] ? check_events+0x12/0x20 [<ffffffff8118d8ec>] ext4_end_io_dio+0x2e/0x82

这次问题出在BUG_ON(!io); 更加证实滴上述的想法，list操作有误导致引发后续一系列的问题，对于workqueue这个stack来说，个人认为合理的解释就是work这个结构已经被修改了（maybe free之后被指向其他地方）

加上spinlock之后，测试跑了2天，暂时没发现panic的问题