Linux Kernel 5.0-blk-mqでのシンプルブロックデバイスの書き込み

皆さん、良いニュースです！



Linuxカーネル5.0はすでにリリースされており、Arch、openSUSE Tumbleweed、Fedoraなどの実験的なディストリビューションに含まれています。







また、Ubuntu Disko DingoとRed Hat 8のRCディストリビューションを見ると、明らかになります。まもなくカーネル5.0もファンデスクトップから本格的なサーバーに移行されます。

誰かが言うだろう-だから何。 次のリリース、特別なものはありません。 それで、Linus Torvalds自身が言った：

機能ベースのリリースは行っておらず、「5.0」は4.xの数値が大きくなり始めて指が足りなくなったことを意味するものではないことを（まだ）指摘したいと思いますとつま先。



（ 私はもう一度繰り返します-私たちのリリースは特定の機能に結び付けられていないので、新しいバージョン5.0の番号は、バージョン4.xの番号付けのために十分な指とつま先がまだないことを意味します ）

ただし、フロッピーディスク用のモジュール（誰も知らない-これらは胸ポケットシャツのサイズのディスクで、容量は1.44 MB）-修正済み...

理由は次のとおりです。



それはすべてマルチキューブロックレイヤー（blk-mq）についてです。 インターネットに関する彼の紹介記事はたくさんありますので、要点を説明しましょう。 blk-mqへの移行はかなり前に開始され、ゆっくりと前進していました。 マルチキューscsi（カーネルパラメーターscsi_mod.use_blk_mq）が登場し、新しいスケジューラーmq-deadline、bfqなどが登場しました…

[root@fedora-29 sblkdev]# cat /sys/block/sda/queue/scheduler [mq-deadline] none
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、あなたは何ですか？



古い方法で動作するブロックデバイスドライバーの数が削減されました。 また、5.0では、blk_init_queue（）関数は不要なため削除されました。 そして今、2003年の古い栄光のコードlwn.net/Articles/58720は 、 行き先を失っただけでなく、関連性も失いました。 さらに、今年のリリースに向けて準備中の新しいディストリビューションは、デフォルト構成でマルチキューブロックレイヤーを使用します。 たとえば、18日のManjaroでは、カーネルはバージョン4.19ですが、デフォルトではblk-mqです。



したがって、カーネル5.0のblk-mqへの移行が完了したと想定できます。 私にとってこれは重要なイベントであり、コードの書き換えと追加のテストが必要になります。 それ自体、大小のバグ、およびいくつかのクラッシュしたサーバーの出現を約束します（Fedyaが必要です！（C））。



ちなみに、誰かがrhel8の場合、カーネルがバージョン4.18で「フラッシュ」されたので、この転換点が来ていないと思うなら、あなたは間違っています。 rhel8の新しいRCでは、5.0の新しい製品が既に移行されており、blk_init_queue（）関数も削除されました（おそらく、別のチェックインをgithub.com/torvalds/linuxからソースにドラッグしたとき）。

一般に、SUSEやRed HatなどのLinuxディストリビュータ向けの「フリーズ」バージョンのカーネルは、長い間マーケティングの概念でした。 システムは、たとえばバージョンが4.4であり、実際には機能が新しい4.8バニラのものであることを報告します。 同時に、公式ウェブサイトには、「新しいディストリビューションでは、安定した4.4カーネルが用意されています」という銘文が誇示されています。



しかし、私たちは気を取られました...



だからここに。 これがどのように機能するかを明確にするために、新しい単純なブロックデバイスドライバーが必要です。

そのため、 github.com / CodeImp / sblkdevのソース。 私は議論することを提案し、プルリクエストを行い、問題を開始します。 QAはまだテストしていません。



記事の後半で、その理由を説明します。 したがって、多くのコードがあります。

Linuxカーネルのコーディングスタイルが完全に尊重されていないことをすぐに謝ります。そうです-gotoは好きではありません。



それでは、エントリーポイントから始めましょう。

 static int __init sblkdev_init(void) { int ret = SUCCESS; _sblkdev_major = register_blkdev(_sblkdev_major, _sblkdev_name); if (_sblkdev_major <= 0){ printk(KERN_WARNING "sblkdev: unable to get major number\n"); return -EBUSY; } ret = sblkdev_add_device(); if (ret) unregister_blkdev(_sblkdev_major, _sblkdev_name); return ret; } static void __exit sblkdev_exit(void) { sblkdev_remove_device(); if (_sblkdev_major > 0) unregister_blkdev(_sblkdev_major, _sblkdev_name); } module_init(sblkdev_init); module_exit(sblkdev_exit);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、モジュールがロードされると、sblkdev_exit（）がアンロードされると、sblkdev_init（）関数が起動されます。

register_blkdev（）関数は、ブロックデバイスを登録します。 彼にはメジャー番号が割り当てられています。 unregister_blkdev（）-この番号を解放します。



モジュールの主要な構造はsblkdev_device_tです。

 // The internal representation of our device typedef struct sblkdev_device_s { sector_t capacity; // Device size in bytes u8* data; // The data aray. u8 - 8 bytes atomic_t open_counter; // How many openers struct blk_mq_tag_set tag_set; struct request_queue *queue; // For mutual exclusion struct gendisk *disk; // The gendisk structure } sblkdev_device_t;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これには、カーネルモジュールに必要なデバイスに関するすべての情報、特にブロックデバイスの容量、データ自体（単純です）、ディスクへのポインタ、キューが含まれています。



すべてのブロックデバイスの初期化は、sblkdev_add_device（）関数で実行されます。

 static int sblkdev_add_device(void) { int ret = SUCCESS; sblkdev_device_t* dev = kzalloc(sizeof(sblkdev_device_t), GFP_KERNEL); if (dev == NULL) { printk(KERN_WARNING "sblkdev: unable to allocate %ld bytes\n", sizeof(sblkdev_device_t)); return -ENOMEM; } _sblkdev_device = dev; do{ ret = sblkdev_allocate_buffer(dev); if(ret) break; #if 0 //simply variant with helper function blk_mq_init_sq_queue. It`s available from kernel 4.20 (vanilla). {//configure tag_set struct request_queue *queue; dev->tag_set.cmd_size = sizeof(sblkdev_cmd_t); dev->tag_set.driver_data = dev; queue = blk_mq_init_sq_queue(&dev->tag_set, &_mq_ops, 128, BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE); if (IS_ERR(queue)) { ret = PTR_ERR(queue); printk(KERN_WARNING "sblkdev: unable to allocate and initialize tag set\n"); break; } dev->queue = queue; } #else // more flexible variant {//configure tag_set dev->tag_set.ops = &_mq_ops; dev->tag_set.nr_hw_queues = 1; dev->tag_set.queue_depth = 128; dev->tag_set.numa_node = NUMA_NO_NODE; dev->tag_set.cmd_size = sizeof(sblkdev_cmd_t); dev->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE; dev->tag_set.driver_data = dev; ret = blk_mq_alloc_tag_set(&dev->tag_set); if (ret) { printk(KERN_WARNING "sblkdev: unable to allocate tag set\n"); break; } } {//configure queue struct request_queue *queue = blk_mq_init_queue(&dev->tag_set); if (IS_ERR(queue)) { ret = PTR_ERR(queue); printk(KERN_WARNING "sblkdev: Failed to allocate queue\n"); break; } dev->queue = queue; } #endif dev->queue->queuedata = dev; {// configure disk struct gendisk *disk = alloc_disk(1); //only one partition if (disk == NULL) { printk(KERN_WARNING "sblkdev: Failed to allocate disk\n"); ret = -ENOMEM; break; } disk->flags |= GENHD_FL_NO_PART_SCAN; //only one partition //disk->flags |= GENHD_FL_EXT_DEVT; disk->flags |= GENHD_FL_REMOVABLE; disk->major = _sblkdev_major; disk->first_minor = 0; disk->fops = &_fops; disk->private_data = dev; disk->queue = dev->queue; sprintf(disk->disk_name, "sblkdev%d", 0); set_capacity(disk, dev->capacity); dev->disk = disk; add_disk(disk); } printk(KERN_WARNING "sblkdev: simple block device was created\n"); }while(false); if (ret){ sblkdev_remove_device(); printk(KERN_WARNING "sblkdev: Failed add block device\n"); } return ret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構造にメモリを割り当て、データを保存するためのバッファを割り当てます。 ここでは特別なことは何もありません。

次に、1つの関数blk_mq_init_sq_queue（）または一度に2つの関数blk_mq_alloc_tag_set（）+ blk_mq_init_queue（）で要求処理キューを初期化します。



ところで、blk_mq_init_sq_queue（）関数のソースコードを見ると、これは4.20カーネルに登場したblk_mq_alloc_tag_set（）およびblk_mq_init_queue（）関数の単なるラッパーであることがわかります。 さらに、キューの多くのパラメーターを非表示にしますが、はるかに簡単に見えます。 どちらのオプションが優れているかを選択する必要がありますが、私はより明示的なオプションを好みます。



このコードのキーは、グローバル変数_mq_opsです。

 static struct blk_mq_ops _mq_ops = { .queue_rq = queue_rq, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、リクエスト処理を提供する関数が配置される場所ですが、それについては少し後で説明します。 主なことは、リクエストハンドラへのエントリポイントを指定したことです。



キューを作成したので、ディスクのインスタンスを作成できます。



大きな変更はありません。 ディスクが割り当てられ、パラメーターが設定され、ディスクがシステムに追加されます。 disk-> flagsパラメータについて説明したいと思います。 これにより、システムにリムーバブルドライブ、または、たとえば、パーティションが含まれておらず、そこを探す必要がないことをシステムに伝えることができます。



ディスク管理用の_fops構造があります。

 static const struct block_device_operations _fops = { .owner = THIS_MODULE, .open = _open, .release = _release, .ioctl = _ioctl, #ifdef CONFIG_COMPAT .compat_ioctl = _compat_ioctl, #endif };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

単純なブロックデバイスモジュールのエントリポイント_openと_releaseは、まだあまり興味深いものではありません。 アトミックインクリメントおよびデクリメントカウンターに加えて、何もありません。 また、64ビットカーネルと32ビットユーザー空間環境を備えたシステムのバージョンは、私には有望ではないように思えるので、compat_ioctlを実装せずに残しました。



ただし、_ioctlを使用すると、このドライブに対するシステム要求を処理できます。 ディスクが表示されると、システムはそれについてさらに学習しようとします。 自分の裁量で、いくつかのクエリに答えることができます（たとえば、新しいCDのふりをするなど）。しかし、一般的なルールは次のとおりです。興味のないクエリに答えたくない場合は、エラーコード-ENOTTYを返すだけです。 ところで、必要に応じて、この特定のドライブに関するリクエストハンドラを追加できます。



そのため、デバイスを追加しました-リソースのリリースに注意する必要があります。 さびはここにはありません。

 static void sblkdev_remove_device(void) { sblkdev_device_t* dev = _sblkdev_device; if (dev){ if (dev->disk) del_gendisk(dev->disk); if (dev->queue) { blk_cleanup_queue(dev->queue); dev->queue = NULL; } if (dev->tag_set.tags) blk_mq_free_tag_set(&dev->tag_set); if (dev->disk) { put_disk(dev->disk); dev->disk = NULL; } sblkdev_free_buffer(dev); kfree(dev); _sblkdev_device = NULL; printk(KERN_WARNING "sblkdev: simple block device was removed\n"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、すべてが明らかです。システムからディスクオブジェクトを削除し、キューを解放します。その後、バッファー（データ領域）も解放します。



そして今、最も重要なことはqueue_rq（）関数でのクエリ処理です。

 static blk_status_t queue_rq(struct blk_mq_hw_ctx *hctx, const struct blk_mq_queue_data* bd) { blk_status_t status = BLK_STS_OK; struct request *rq = bd->rq; blk_mq_start_request(rq); //we cannot use any locks that make the thread sleep { unsigned int nr_bytes = 0; if (do_simple_request(rq, &nr_bytes) != SUCCESS) status = BLK_STS_IOERR; printk(KERN_WARNING "sblkdev: request process %d bytes\n", nr_bytes); #if 0 //simply and can be called from proprietary module blk_mq_end_request(rq, status); #else //can set real processed bytes count if (blk_update_request(rq, status, nr_bytes)) //GPL-only symbol BUG(); __blk_mq_end_request(rq, status); #endif } return BLK_STS_OK;//always return ok }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、パラメーターを検討します。 最初はstruct blk_mq_hw_ctx * hctx-ハードウェアキューの状態です。 私たちのケースでは、ハードウェアキューがないため、使用されません。



2番目のパラメーターはconst struct blk_mq_queue_data * bdです。非常に簡潔な構造のパラメーターです。このパラメーター全体を注意して表示することを恐れません。

 struct blk_mq_queue_data { struct request *rq; bool last; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

本質的には、これは年代記者elixir.bootlin.comがもはや覚えていない時から私たちに届いた同じリクエストであることが判明しました。 そのため、リクエストを受け取って処理を開始し、それについてblk_mq_start_request（）を呼び出してカーネルに通知します。 リクエストの処理が完了したら、blk_mq_end_request（）関数を呼び出してこれをカーネルに通知します。



ちょっとした注意点があります：blk_mq_end_request（）関数は、実際にはblk_update_request（）+ __blk_mq_end_request（）への呼び出しのラッパーです。 blk_mq_end_request（）関数を使用する場合、実際に処理されたバイト数を指定することはできません。 すべてが処理されていると考えています。



代替オプションには別の機能があります：blk_update_request関数はGPL専用モジュールに対してのみエクスポートされます。 つまり、独自のカーネルモジュールを作成する場合（PMがこの厄介なパスからあなたを救うようにする）、blk_update_request（）を使用することはできません。 したがって、選択はあなた次第です。



バイトをリクエストからバッファへ、またはその逆に直接シフトして、do_simple_request（）関数を作成しました。

 static int do_simple_request(struct request *rq, unsigned int *nr_bytes) { int ret = SUCCESS; struct bio_vec bvec; struct req_iterator iter; sblkdev_device_t *dev = rq->q->queuedata; loff_t pos = blk_rq_pos(rq) << SECTOR_SHIFT; loff_t dev_size = (loff_t)(dev->capacity << SECTOR_SHIFT); printk(KERN_WARNING "sblkdev: request start from sector %ld \n", blk_rq_pos(rq)); rq_for_each_segment(bvec, rq, iter) { unsigned long b_len = bvec.bv_len; void* b_buf = page_address(bvec.bv_page) + bvec.bv_offset; if ((pos + b_len) > dev_size) b_len = (unsigned long)(dev_size - pos); if (rq_data_dir(rq))//WRITE memcpy(dev->data + pos, b_buf, b_len); else//READ memcpy(b_buf, dev->data + pos, b_len); pos += b_len; *nr_bytes += b_len; } return ret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいことは何もありません。rq_for_each_segmentはすべてのbioを反復処理し、すべてbio_vec構造を持っているため、リクエストデータのあるページにアクセスできます。



あなたの印象は？ すべてがシンプルに見える？ 一般的なリクエスト処理は、リクエストページと内部バッファ間でデータをコピーするだけです。 単純なブロックデバイスドライバーにふさわしいでしょうか？



しかし、問題があります： これは実際の使用のためではありません！



問題の本質は、リストからの要求を処理するループでqueue_rq（）要求処理関数が呼び出されることです。 スピンまたはRCUでこのリストのどのロックが使用されているかわかりません（嘘をつきません-誰が知っていますか、私を修正します）が、たとえば、リクエスト処理機能でミューテックスを使用しようとすると、デバッグカーネルは誓いますここでは不可能です。 つまり、プロセスがスタンバイ状態に移行できないため、従来の同期ツールまたは仮想連続メモリ（vmallocを使用して割り当てられ、暗黙的にスワップに陥る可能性があるメモリ）を使用することは不可能です。



したがって、.. \ linux \ drivers \ block \ brd.cで実装されるSpinまたはRCUのロックとページの配列の形式のバッファー、またはツリー、または..で実装される別のスレッドでの遅延処理のいずれか\ linux \ drivers \ block \ loop.c



モジュールを組み立てる方法、システムにロードする方法、アンロードする方法を説明する必要はないと思います。 この面に新製品はありません。そのために感謝します:)だから誰かがそれを試してみたいと思うなら、私はそれを理解することを確認します。 お気に入りのラップトップですぐにやらないでください！ virtualochkaを上げるか、少なくともボールをバックアップします。



ちなみに、Veeam Backup for Linux 3.0.1.1046はすでに利用可能です。 カーネル5.0以降でVAL 3.0.1.1046を実行しないでください。 veeamsnapはアセンブルされません。 また、いくつかのマルチキューの技術革新はまだテスト段階にあります。