scsi patch queue tree updated

I've pushed out new version of the for-3.17 core and drivers trees:

git://git.infradead.org/users/hch/scsi-queue.git core-for-3.17
git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.17

In the core tree the biggest news is the old target infrastructure removal, in addition a few warnings due to 64-bit LUNs have been fixed, and the tree has been rebased to 3.16-rc4 to pick up all updates that went into the Linux 3.16 release candidates.

The drivers-for-3.17 tree is new, and I should have picked up all properly reviewed patches.

Most notably missing from the drivers tree are the mpt2sas and mpt3sas series and the scsi_debug update which need a review, and the megaraid and pm8001 uptdates which need a resend. Missing from the core tree is the scsi-mq work that still needs a proper review.

Also notably absent is the flush error handling fix, which still needs a signoff from James and a proper review. As far as I'm concerned that fix should still go into 3.16.

I've pushed out updates to both the core-for-3.17 and drivers-for-3.17 branches. I think we're in a good shape for the merge window, but I'd still like to get reviewers attention for a few driver updates that I'd love to get in still:

- my eata patch to remove the driver_lock
- the partially reviewed megaraid series
- the arcmsr series

So I'm afraid we missed the last -next build on these, so they can't go in with the early SCSI pull. I'm open to doing one mid merge window, but Linus tends not to like that.

James

I don't think there are any hard and fast rules.

The core-for-3.17 commit is a trivial printk specifier regression fix for something introduced in the 3.17 merge window, so pulling it in is an absolute non-brainer.

The drivers side are a bunch of smaller fixes for iscsi and pm8001 which never have been a problem to put in near the end of the merge window, especially if they have a few more days linux-next exposure in Linux-next even after the 3.16 release. They absolutely would be candidates for a second pull even if they'd miss the first pull.

Hi Christoph,

You realise that neither of these in linux-next as the scsi-core and scsi-drivers trees had for-3.16 branches in the last round. I assume I should just drop these trees completely from linux-next?

Cheers,
Stephen Rothwell                    [email protected]

Well, they get pulled in through James, so you can drop them for now.

I mostly put you on Cc so you could comment wether there are any hard rules on how long even those simple fixes should be in linux-next. I know you've put up stats for a few of the last merge windows about patches that weren't in linux-next, so there's been some tracking of it for sure.

Hi Christoph,

Will do.

If they are simple, clear fixes, then maybe a day or two just for build coverage, but it is very much up to the maintainer. There are always a few poatches that get through late (quote a few of which I suspect have been "in train", just not yet published in the maintainer's tree).

And, of course, real fixes go in just about anytime ...

I don't think we believe in hard rules for anything :-)

Cheers,
Stephen Rothwell                    [email protected]

True, but the hardest of our semi-liquid rules is nothing in the merge window that wasn't in -next first.

OK, since I have to do a second pull anyway we might as well follow the rules.

James

Ok, new tree is out, the core-for-3.17 has the one 64-bit lun format string fix that didn't make it into the first pull request, the queuecommand device busy regression fix, and the cmd_pool fix.

The drivers-for-3.17 just has the driver updates I pushed earlier that didn't make the cut.

So this is a bit late to get through linux-next and into a pull request. I was planning on sending the final pull tomorrow (in case Linus planned a surprise early release). Can we redo some of these as bug fixes and send them in for -rc1?

James

core-for-3.17 is entirely bug fixes, the drivers side is all except for 4 tiny patches, and even Linus isn't that anal I think.

You rebased the tree before doing it ... that's the one thing that excites his process gene. I can't send a rebased tree in on the last day of merging.

I'll send in the unrebased tree which has been sitting in linux-next for the past week. The two additional changes in core-for-3.17 can be picked out and sent as eligible bug fixes for -rc1. The only addition in drivers-for-3.17 is eata: remove driver_lock ... I'm in two minds about whether we treat that as a bug fix or not.

James

Christoph,

Can we get someone to finish reviewing the megaraid_sas patch series ?
Or let me know if anything else needs to be corrected ?

I know it has been reviewed by yourself and Martin Petersen so far, however, I could not find the patch series in:

http://git.infradead.org/users/hch/scsi-queue.git/shortlog/refs/heads/drivers-for-3.18

-Adam

I think I'm missing an ACK from Martin on one of the patches.

Christoph> I think I'm missing an ACK from Martin on one of the patches.

Looks like I missed the updated version of these during my vacation. I'll finish reviewing megaraid_sas (and mptNsas) today.

Martin K. Petersen	Oracle Linux Engineering

Christoph> I think I'm missing an ACK from Martin on one of the patches.

3/5 and 4/5 look good to me.

Martin K. Petersen	Oracle Linux Engineering

Thanks Martin,

I'll pull in the megaraid_sas patches for the next branch update.

Hi James,

I've pushed two updates to the core-for-3.17 branch of

git://git.infradead.org/users/hch/scsi-queue.git

which should go to Linus before the next rc.

One is a regression fix for drivers using block layer tagging when not using blk-mq introduced in the blk-mq series, and the other fixes a potential buffer overrun in the iscsi initiator.

Updates of the for-3.18 trees will follow soon.

core-for-3.17 has grown another fix from Daniel for bidi support.

core-for-3.18 has got the autopm fix to balance the calls and thus
handle LUNs without attached ULD

drivers-for-3.18 has the megaraid, mpt and arcmsr updates as well as a
bnx fix

OK, I've pushed this to -next. If nothing bad turns up I'll send it to Linus on Friday.

James

It turnd out while the scsi-queue tree in general worked very well the split into core and drivers branches was rather cumbersome.

For the 3.19 merge window updates and the 3.20 window I've switched to a single branch instead:

git://git.infradead.org/users/hch/scsi-queue.git scsi-for-3.19
git://git.infradead.org/users/hch/scsi-queue.git scsi-for-3.20

So far there 3.20 tree is still rather small, but there are a couple of series that need a resend or review and should go in.

The rules from the original scsi-queue tree have worked well, so they still apply with a minor change. These rules are:

- the patch needs at least two positive reviews (non-author signoff,
reviewed-by or acked-by tags). In practice this means it had at
least one and I added another one.
As an exception I also take trivial and important fixes if they only have a Tested-by: instead of a second review.
- the patch has no negative review on the mailing list
- the patch applies cleanly
- the patch compiles (drivers for architectures I can't test excluded)
- for core the core branch: the patch survives a full xfstests run