Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22 2013, Linus Torvalds wrote: > On Sun, Sep 22, 2013 at 4:12 PM, Jens Axboe wrote: > > > > Not necessarily bad quality control, but yeah, the commit messages > > could've been prettier. Those two should have been git ammended, most of > > them are directly applied byt git am fwiw. > > No, one of them was clearly *not* done with git am, because git am > uses the subject like to create that summary message. So make that a combo of git am and shitty mailer. I forget why it happens, but it does happen often for me and I (usually remember) to fix it up. > And the other one you should have edited the mbox before feeding it to > git am - or pushed back on the submitter to write email in a format > where no such editing is necessary. > > "I used git am" is not an excuse for bad formatting of commits. It's > just a tool, you need to make sure the tool is fed valid data. Sure, not disagreeing. It is my fault :-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22, 2013 at 4:12 PM, Jens Axboe wrote: > > Not necessarily bad quality control, but yeah, the commit messages > could've been prettier. Those two should have been git ammended, most of > them are directly applied byt git am fwiw. No, one of them was clearly *not* done with git am, because git am uses the subject like to create that summary message. And the other one you should have edited the mbox before feeding it to git am - or pushed back on the submitter to write email in a format where no such editing is necessary. "I used git am" is not an excuse for bad formatting of commits. It's just a tool, you need to make sure the tool is fed valid data. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22 2013, Linus Torvalds wrote: > On Sun, Sep 22, 2013 at 2:55 PM, Jens Axboe wrote: > > > > Mike Christie (1): > > If the queue is dying then we only call the rq->end_io callout. > > This leaves bios setup on the request, because the caller assumes when > > the blk_execute_rq_nowait/blk_execute_rq call has completed that the > > rq->bios have been cleaned up. > > Christ people. > > We have rules for commit messages. Those rules have things like > "one-line commit summary at the top", because without that things like > summary logs (ie "git shortlog") and "gitk" don't do a good job. > > How long have we been doing this? I'm used to seeing some odd commit > messages outside the kernel repo, but am used to kernel people getting > the trivial details right. > > That's not the only one. Look at commit 577cee1e8db6 for some other > cruddy commit messages. Just because somebody said "Hello" in email > doesn't mean that it should remain that way in a commit message. > > So out of seven commit messages, two were badly formatted. That's not > a sign of good quality control. Not necessarily bad quality control, but yeah, the commit messages could've been prettier. Those two should have been git ammended, most of them are directly applied byt git am fwiw. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22, 2013 at 2:55 PM, Jens Axboe wrote: > > Mike Christie (1): > If the queue is dying then we only call the rq->end_io callout. > This leaves bios setup on the request, because the caller assumes when > the blk_execute_rq_nowait/blk_execute_rq call has completed that the > rq->bios have been cleaned up. Christ people. We have rules for commit messages. Those rules have things like "one-line commit summary at the top", because without that things like summary logs (ie "git shortlog") and "gitk" don't do a good job. How long have we been doing this? I'm used to seeing some odd commit messages outside the kernel repo, but am used to kernel people getting the trivial details right. That's not the only one. Look at commit 577cee1e8db6 for some other cruddy commit messages. Just because somebody said "Hello" in email doesn't mean that it should remain that way in a commit message. So out of seven commit messages, two were badly formatted. That's not a sign of good quality control. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Block IO fixes for 3.12
Hi Linus, After merge window, no new stuff this time only a collection of neatly confined and simple fixes. Please pull! git://git.kernel.dk/linux-block.git for-3.12/core for you to fetch changes up to f3cff25f05f2ac29b2ee355e611b0657482f6f1d: cfq: explicitly use 64bit divide operation for 64bit arguments (2013-09-22 12:43:47 -0600) Anatol Pomozov (1): cfq: explicitly use 64bit divide operation for 64bit arguments Bjorn Helgaas (1): bio-integrity: Fix use of bs->bio_integrity_pool after free Jianpeng Ma (1): block: trace all devices plug operation Joe Perches (1): block: Convert kmalloc_node(...GFP_ZERO...) to kzalloc_node(...) Jun'ichi Nomura (1): block: Add nr_bios to block_rq_remap tracepoint Mike Christie (1): If the queue is dying then we only call the rq->end_io callout. This leaves bios setup on the request, because the caller assumes when the blk_execute_rq_nowait/blk_execute_rq call has completed that the rq->bios have been cleaned up. Tejun Heo (1): blkcg: relocate root_blkg setting and clearing block/blk-cgroup.c | 25 +++-- block/blk-core.c | 6 ++ block/blk-exec.c | 4 ++-- block/cfq-iosched.c | 4 ++-- block/deadline-iosched.c | 2 +- block/elevator.c | 2 +- block/genhd.c| 3 +-- fs/bio-integrity.c | 2 +- include/linux/blkdev.h | 11 +++ include/trace/events/block.h | 6 -- 10 files changed, 40 insertions(+), 25 deletions(-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Block IO fixes for 3.12
Hi Linus, After merge window, no new stuff this time only a collection of neatly confined and simple fixes. Please pull! git://git.kernel.dk/linux-block.git for-3.12/core for you to fetch changes up to f3cff25f05f2ac29b2ee355e611b0657482f6f1d: cfq: explicitly use 64bit divide operation for 64bit arguments (2013-09-22 12:43:47 -0600) Anatol Pomozov (1): cfq: explicitly use 64bit divide operation for 64bit arguments Bjorn Helgaas (1): bio-integrity: Fix use of bs-bio_integrity_pool after free Jianpeng Ma (1): block: trace all devices plug operation Joe Perches (1): block: Convert kmalloc_node(...GFP_ZERO...) to kzalloc_node(...) Jun'ichi Nomura (1): block: Add nr_bios to block_rq_remap tracepoint Mike Christie (1): If the queue is dying then we only call the rq-end_io callout. This leaves bios setup on the request, because the caller assumes when the blk_execute_rq_nowait/blk_execute_rq call has completed that the rq-bios have been cleaned up. Tejun Heo (1): blkcg: relocate root_blkg setting and clearing block/blk-cgroup.c | 25 +++-- block/blk-core.c | 6 ++ block/blk-exec.c | 4 ++-- block/cfq-iosched.c | 4 ++-- block/deadline-iosched.c | 2 +- block/elevator.c | 2 +- block/genhd.c| 3 +-- fs/bio-integrity.c | 2 +- include/linux/blkdev.h | 11 +++ include/trace/events/block.h | 6 -- 10 files changed, 40 insertions(+), 25 deletions(-) -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22, 2013 at 2:55 PM, Jens Axboe ax...@kernel.dk wrote: Mike Christie (1): If the queue is dying then we only call the rq-end_io callout. This leaves bios setup on the request, because the caller assumes when the blk_execute_rq_nowait/blk_execute_rq call has completed that the rq-bios have been cleaned up. Christ people. We have rules for commit messages. Those rules have things like one-line commit summary at the top, because without that things like summary logs (ie git shortlog) and gitk don't do a good job. How long have we been doing this? I'm used to seeing some odd commit messages outside the kernel repo, but am used to kernel people getting the trivial details right. That's not the only one. Look at commit 577cee1e8db6 for some other cruddy commit messages. Just because somebody said Hello in email doesn't mean that it should remain that way in a commit message. So out of seven commit messages, two were badly formatted. That's not a sign of good quality control. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22 2013, Linus Torvalds wrote: On Sun, Sep 22, 2013 at 2:55 PM, Jens Axboe ax...@kernel.dk wrote: Mike Christie (1): If the queue is dying then we only call the rq-end_io callout. This leaves bios setup on the request, because the caller assumes when the blk_execute_rq_nowait/blk_execute_rq call has completed that the rq-bios have been cleaned up. Christ people. We have rules for commit messages. Those rules have things like one-line commit summary at the top, because without that things like summary logs (ie git shortlog) and gitk don't do a good job. How long have we been doing this? I'm used to seeing some odd commit messages outside the kernel repo, but am used to kernel people getting the trivial details right. That's not the only one. Look at commit 577cee1e8db6 for some other cruddy commit messages. Just because somebody said Hello in email doesn't mean that it should remain that way in a commit message. So out of seven commit messages, two were badly formatted. That's not a sign of good quality control. Not necessarily bad quality control, but yeah, the commit messages could've been prettier. Those two should have been git ammended, most of them are directly applied byt git am fwiw. -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22, 2013 at 4:12 PM, Jens Axboe ax...@kernel.dk wrote: Not necessarily bad quality control, but yeah, the commit messages could've been prettier. Those two should have been git ammended, most of them are directly applied byt git am fwiw. No, one of them was clearly *not* done with git am, because git am uses the subject like to create that summary message. And the other one you should have edited the mbox before feeding it to git am - or pushed back on the submitter to write email in a format where no such editing is necessary. I used git am is not an excuse for bad formatting of commits. It's just a tool, you need to make sure the tool is fed valid data. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Block IO fixes for 3.12
On Sun, Sep 22 2013, Linus Torvalds wrote: On Sun, Sep 22, 2013 at 4:12 PM, Jens Axboe ax...@kernel.dk wrote: Not necessarily bad quality control, but yeah, the commit messages could've been prettier. Those two should have been git ammended, most of them are directly applied byt git am fwiw. No, one of them was clearly *not* done with git am, because git am uses the subject like to create that summary message. So make that a combo of git am and shitty mailer. I forget why it happens, but it does happen often for me and I (usually remember) to fix it up. And the other one you should have edited the mbox before feeding it to git am - or pushed back on the submitter to write email in a format where no such editing is necessary. I used git am is not an excuse for bad formatting of commits. It's just a tool, you need to make sure the tool is fed valid data. Sure, not disagreeing. It is my fault :-) -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/