lookup_bdev() の核心

kernel

今から bd_acquire() 手続きを掘ります。気づきを以下にメモるかも。

bd_acquire() 手続き

渡された inode オブジェクトが指す i_bdev 属性が NULL ではなくって igrab() な手続きの戻りも NULL でなければ、i_bdev 属性を戻す模様。
igrab() 手続きに渡されるのは、block_device なオブジェクトを指す i_bdev 属性の bd_inode 属性。3rd Edition には

bdev ファイルシステムのブロック型デバイスに対応するファイルの i ノードへのポインタ


との説明がある。ちょっとややこしい。ただ、igrab() 手続きの核心は

	if (!(inode->i_state & I_FREEING))
		__iget(inode);

で、上記な条件が偽なケースでは NULL が戻ります。bd_aquire() 手続きで言うと以下なナニ。

	if (bdev && igrab(bdev->bd_inode)) {
		spin_unlock(&bdev_lock);
		return bdev;
	}

inode オブジェクトの i_state 属性とか I_FREEING ってマクロとか不明点多い。

む

i_state 属性については 3rd Edition 12.2.2 に詳細な説明あり。でも、I_FREEING な状態の説明が

i ノードオブジェクトの解放処理が行われている状態


とあるんですが、どーゆー意味なのか。

と、ゆーコトで

grep してみたんですが、fs/inode.c な模様。曰く

 * I_FREEING is set so that no-one will take a new reference to the inode while
 * it is being deleted.

との事。これは generic_delete_inode() 手続きなコメント。
あるいは __wait_on_freeint_inode() 手続きなコメントが以下。

	 * I_FREEING and I_CLEAR are cleared in process context under
	 * inode_lock, so we have to give the tasks who would clear them
	 * a chance to run and acquire inode_lock.

これ、状態遷移を確認したいですな。