LinuxカーネルHack: git commitからgit send-emailでGMailアカウントを用いたパッチ送信まで

はじめてBtrfsにパッチを投げてみました。修正は単純で、メモリー確保後のチェックをより厳密にしただけです。Btrfsの開発コミュニティはBUG_ON撲滅に向けて動いているのに、BUG_ONを増やしてしまいました。http://www.mail-archive.com/[email protected]/msg08420.html 現時点ではコードが取り込まれるかどうかはわかりません。リジェクトされるかもしれません。btrfs-unstableで取り込まれたら、メインラインへのマージはほぼ確実なので、今からワクワクです。リジェクトされたとしても、パッチ送信までの手順を踏めたのは大きいです。

で、今回は、参考までにパッチ送信までの流れを記録として残しておきます。

コミット

まず、修正したコードをコミットする。

fixme@xr:~/btrfs-unstable$ git commit -a

コミットログを書いておく。

To make Btrfs code more robust, several return value checks where memory
allocation can fail are introduced. I use BUG_ON where I don't know how
to handle the error properly, which increases the number of using the
notorious BUG_ON, though.

パッチの作成

git format-patchコマンドでパッチを生成する。コミットした直後のコードのパッチを作成したいので、「-r HEAD~」を指定。「-s」で「Signed-off-by」を付与するように指定。「-o」でパッチの出力ディレクトリを指定。今回は「--numbered」は不要だった。特に意味は無さそうだけど、リネームしておいた。

fixme@xr:~/btrfs-unstable$ git format-patch -r HEAD~ --numbered -s -o ~/btrfs_patch
fixme@xr:~/btrfs_patch$ mv 0001-To-make-Btrfs-code-more-robust-several-return-value-.patch fix-uncheck-memory-allocations.patch

生成されたパッチを見ると、Subjectにコミットログが侵食してたので修正した。

fixme@xr:~/btrfs_patch$ mv 0001-To-make-Btrfs-code-more-robust-several-return-value-.patch fix-uncheck-memory-allocations.patch
fixme@xr:~/btrfs_patch$ emacs fix-uncheck-memory-allocations.patch
----------------------
From d94d7f73323de012d4fe9f85736ae59a32513c5a Mon Sep 17 00:00:00 2001
From: Yoshinori Sano <[email protected]>
Date: Sat, 12 Feb 2011 19:36:17 +0900
Subject: [PATCH] fix uncheck memory allocations

To make Btrfs code more robust, several return value checks where memory
allocation can fail are introduced.  I use BUG_ON where I don't know how
to handle the error properly, which increases the number of using the
notorious BUG_ON, though.

Signed-off-by: Yoshinori Sano <[email protected]>
---
 fs/btrfs/compression.c |    6 ++++++
 fs/btrfs/extent-tree.c |    2 ++
 fs/btrfs/file.c        |    8 ++++++--
 fs/btrfs/inode.c       |    5 +++++
 4 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 4d2110e..f596554 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -340,6 +340,8 @@ int btrfs_submit_compressed_write(struct inode *inode, u64 start,
 
 	WARN_ON(start & ((u64)PAGE_CACHE_SIZE - 1));
 	cb = kmalloc(compressed_bio_size(root, compressed_len), GFP_NOFS);
+	if (!cb)
+		return -ENOMEM;
 	atomic_set(&cb->pending_bios, 0);
 	cb->errors = 0;
 	cb->inode = inode;
@@ -354,6 +356,10 @@ int btrfs_submit_compressed_write(struct inode *inode, u64 start,
 	bdev = BTRFS_I(inode)->root->fs_info->fs_devices->latest_bdev;
 
 	bio = compressed_bio_alloc(bdev, first_byte, GFP_NOFS);
+	if (!bio) {
+		kfree(cb);
+		return -ENOMEM;
+	}
 	bio->bi_private = cb;
 	bio->bi_end_io = end_compressed_bio_write;
 	atomic_inc(&cb->pending_bios);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 565e22d..aed16f4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6931,6 +6931,8 @@ static noinline int get_new_locations(struct inode *reloc_inode,
 			struct disk_extent *old = exts;
 			max *= 2;
 			exts = kzalloc(sizeof(*exts) * max, GFP_NOFS);
+			if (!exts)
+				goto out;
 			memcpy(exts, old, sizeof(*exts) * nr);
 			if (old != *extents)
 				kfree(old);
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index b0ff34b..4895ad2 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -181,10 +181,14 @@ int btrfs_drop_extent_cache(struct inode *inode, u64 start, u64 end,
 		testend = 0;
 	}
 	while (1) {
-		if (!split)
+		if (!split) {
 			split = alloc_extent_map(GFP_NOFS);
-		if (!split2)
+			BUG_ON(!split || IS_ERR(split));
+		}
+		if (!split2) {
 			split2 = alloc_extent_map(GFP_NOFS);
+			BUG_ON(!split2 || IS_ERR(split2));
+		}
 
 		write_lock(&em_tree->lock);
 		em = lookup_extent_mapping(em_tree, start, len);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c9bc0af..40bbe00 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -287,6 +287,7 @@ static noinline int add_async_extent(struct async_cow *cow,
 	struct async_extent *async_extent;
 
 	async_extent = kmalloc(sizeof(*async_extent), GFP_NOFS);
+	BUG_ON(!async_extent);
 	async_extent->start = start;
 	async_extent->ram_size = ram_size;
 	async_extent->compressed_size = compressed_size;
@@ -384,6 +385,7 @@ again:
 	     (BTRFS_I(inode)->force_compress))) {
 		WARN_ON(pages);
 		pages = kzalloc(sizeof(struct page *) * nr_pages, GFP_NOFS);
+		BUG_ON(!pages);
 
 		if (BTRFS_I(inode)->force_compress)
 			compress_type = BTRFS_I(inode)->force_compress;
@@ -644,6 +646,7 @@ retry:
 					async_extent->ram_size - 1, 0);
 
 		em = alloc_extent_map(GFP_NOFS);
+		BUG_ON(!em || IS_ERR(em));
 		em->start = async_extent->start;
 		em->len = async_extent->ram_size;
 		em->orig_start = em->start;
@@ -820,6 +823,7 @@ static noinline int cow_file_range(struct inode *inode,
 		BUG_ON(ret);
 
 		em = alloc_extent_map(GFP_NOFS);
+		BUG_ON(!em || IS_ERR(em));
 		em->start = start;
 		em->orig_start = em->start;
 		ram_size = ins.offset;
@@ -1169,6 +1173,7 @@ out_check:
 			struct extent_map_tree *em_tree;
 			em_tree = &BTRFS_I(inode)->extent_tree;
 			em = alloc_extent_map(GFP_NOFS);
+			BUG_ON(!em || IS_ERR(em));
 			em->start = cur_offset;
 			em->orig_start = em->start;
 			em->len = num_bytes;
-- 
1.7.1

メール送信の準備

以下を参考にコマンドラインからGMailのアカウントでパッチ送信できるように準備した。

• http://www.omappedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails#GIT_patch_creation
• http://d.hatena.ne.jp/janus_wel/20090120/1232481948

fixme@xr:~/btrfs-unstable$ sudo apt-get install git-email
fixme@xr:~/btrfs-unstable$ sudo apt-get install msmtp
fixme@xr:~/btrfs-unstable$ sudo apt-get install ca-certificates
fixme@xr:~/btrfs-unstable$ cat ~/.gitconfig
[user]
        name = Yoshinori Sano
        email = [email protected]

[sendemail]
        smtpserver = /usr/bin/msmtp

fixme@xr:~/btrfs-unstable$ cat ~/.msmtprc
# Example for a user configuration file
# Set default values for all following accounts.
defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
# My email service
account gmail
host smtp.gmail.com
port 587
from [email protected]
auth on
user [email protected]
password secret
# Set a default account
account default : gmail
fixme@xr:~/btrfs-unstable$ chmod 600 ~/.msmtprc 

メールの送信

git send-emailコマンドでメールを送信。しばらくして、特に問題なくメール送信完了。メーリングリストへの投稿を確認。http://www.mail-archive.com/[email protected]/msg08420.html

fixme@xr:~/btrfs-unstable$ git send-email --from "Yoshinori Sano <[email protected]>" --envelope-sender "Yoshinori Sano <[email protected]>" --to [email protected] --smtp-debug ~/btrfs_patch
/home/fixme/btrfs_patch/fix-uncheck-memory-allocations.patch
(mbox) Adding cc: Yoshinori Sano <[email protected]> from line 'From: Yoshinori Sano <[email protected]>'
(body) Adding cc: Yoshinori Sano <[email protected]> from line 'Signed-off-by: Yoshinori Sano <[email protected]>'

From: Yoshinori Sano <[email protected]>
To: [email protected]
Cc: Yoshinori Sano <[email protected]>
Subject: [PATCH] fix uncheck memory allocations
Date: Sat, 12 Feb 2011 20:17:13 +0900
Message-Id: <[email protected]>
X-Mailer: git-send-email 1.7.1

    The Cc list above has been expanded by additional
    addresses found in the patch commit message. By default
    send-email prompts before sending whenever this occurs.
    This behavior is controlled by the sendemail.confirm
    configuration setting.

    For additional information, run 'git send-email --help'.
    To retain the current behavior, but squelch this message,
    run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
OK. Log says:
Sendmail: /usr/bin/msmtp -f [email protected] -i [email protected] [email protected]
From: Yoshinori Sano <[email protected]>
To: [email protected]
Cc: Yoshinori Sano <[email protected]>
Subject: [PATCH] fix uncheck memory allocations
Date: Sat, 12 Feb 2011 20:17:13 +0900
Message-Id: <[email protected]>
X-Mailer: git-send-email 1.7.1

Result: OK
In git 1.7.0, the default has changed to --no-chain-reply-to
Set sendemail.chainreplyto configuration variable to true if
you want to keep --chain-reply-to as your default.

追記(2011/02/15)

メールでのパッチ投稿時のフォーマットについては、これが参考になる。
http://linux.yyz.us/patch-format.html