[ANNOUNCE] scsi patch queue tree

[ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

I'd like to announce the new scsi patch queue tree, which will pick up
any scsi core or driver patches promptly to allow easy integration and
feedback that contributors might be used to from other kernel subsystems.

There are two branches, one for the SCSI core and upper level drivers,
and one for low-level (hardware) drivers:

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

The rules for the tree are:

 - it has 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.
 - no negative review on the mailing list
 - it applies cleanly
 - it compiles cleanly (drivers for architectures I can't test excluded)
 - for core the core branch: survives a full xfstests run

I went through the linux-scsi archives for March, April and May and
applied all patches that clearly fit the above criteria, but it's fairly
like I missed some.

If I'm missing your patch(es):

 - resend it unless it was sent in the last few weeks
 - make sure all reviews are recorded in the most recent post of the
   patch(es)
 - ping the list for additional reviewers

For now the prime intent of the tree is to feed it to James, although
I'd welcome everyone interested to pull and test it.  If the scheme
proves successful I'd love to invite more core scsi contributors to help
with it and move to a shared kernel.org tree.

Re: [ANNOUNCE] scsi patch queue tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

Hi Christoph,

On Mon, 19 May 2014 07:06:14 -0700 Christoph Hellwig <hch@infradead.org> wrote:
>
> I'd like to announce the new scsi patch queue tree, which will pick up
> any scsi core or driver patches promptly to allow easy integration and
> feedback that contributors might be used to from other kernel subsystems.
> 
> There are two branches, one for the SCSI core and upper level drivers,
> and one for low-level (hardware) drivers:
> 
>   git://git.infradead.org/users/hch/scsi-queue.git core-for-3.16
>   git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.16 
> 
> The rules for the tree are:
> 
>  - it has 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.
>  - no negative review on the mailing list
>  - it applies cleanly
>  - it compiles cleanly (drivers for architectures I can't test excluded)
>  - for core the core branch: survives a full xfstests run
> 
> I went through the linux-scsi archives for March, April and May and
> applied all patches that clearly fit the above criteria, but it's fairly
> like I missed some.
> 
> If I'm missing your patch(es):
> 
>  - resend it unless it was sent in the last few weeks
>  - make sure all reviews are recorded in the most recent post of the
>    patch(es)
>  - ping the list for additional reviewers
> 
> For now the prime intent of the tree is to feed it to James, although
> I'd welcome everyone interested to pull and test it.  If the scheme
> proves successful I'd love to invite more core scsi contributors to help
> with it and move to a shared kernel.org tree.

Is this a request for inclusion of those branches into linux-next
separately from the scsi tree itself?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

On Tue, May 20, 2014 at 10:03:43AM +1000, Stephen Rothwell wrote:
> Is this a request for inclusion of those branches into linux-next
> separately from the scsi tree itself?

James said he wants to include it in the scsi tree, but given how late
we are in the cycle I'd love to see separate exposure until that happens
on a temporary basis.

Re: [ANNOUNCE] scsi patch queue tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

Hi Christoph,

On Mon, 19 May 2014 22:39:28 -0700 Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, May 20, 2014 at 10:03:43AM +1000, Stephen Rothwell wrote:
> > Is this a request for inclusion of those branches into linux-next
> > separately from the scsi tree itself?
> 
> James said he wants to include it in the scsi tree, but given how late
> we are in the cycle I'd love to see separate exposure until that happens
> on a temporary basis.

OK, I have added them from today (called scsi-core and scsi-drivers).
James, feel free to yell if that is not OK.  If these are to stay
longer term (and I have no objections given your list of requirements),
then you should rename the branches (maybe to -next instead of -3.16).

These will be merged after the scsi tree so that they effectively
disappear from my radar when they have been merged into James' tree.

Currently you are the only contact for problems - let me know if I
should add someone else (or a list).

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your branches have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to James (or ask him
to fetch).  They are allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCE] scsi patch queue tree

[James Bottomley]

On Wed, 2014-05-21 at 09:46 +1000, Stephen Rothwell wrote:
> Hi Christoph,
> 
> On Mon, 19 May 2014 22:39:28 -0700 Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, May 20, 2014 at 10:03:43AM +1000, Stephen Rothwell wrote:
> > > Is this a request for inclusion of those branches into linux-next
> > > separately from the scsi tree itself?
> > 
> > James said he wants to include it in the scsi tree, but given how late
> > we are in the cycle I'd love to see separate exposure until that happens
> > on a temporary basis.
> 
> OK, I have added them from today (called scsi-core and scsi-drivers).
> James, feel free to yell if that is not OK.

Let's try the process.

>   If these are to stay
> longer term (and I have no objections given your list of requirements),
> then you should rename the branches (maybe to -next instead of -3.16).

I'll merge it into for-next in SCSI to make it easier.

> These will be merged after the scsi tree so that they effectively
> disappear from my radar when they have been merged into James' tree.
> 
> Currently you are the only contact for problems - let me know if I
> should add someone else (or a list).

Also cc the scsi mailing list for merge problems, just in case.

Thanks,

James

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

I've pushed the following changes to the drivers-for-3.16 tree.  I've
there's anyting matching the rules that I did forget please resend
and/or ping me.


----------------------------------------------------------------
Benoit Taine (2):
      qla4xxx: Use kmemdup instead of kmalloc + memcpy
      qla2xxx: Use kmemdup instead of kmalloc + memcpy

Dan Carpenter (1):
      qla2xxx: fix incorrect debug printk

Dolev Raviv (4):
      scsi: ufs: query descriptor API
      scsi: ufs: device query status and size check
      scsi: ufs: Logical Unit (LU) command queue depth
      scsi: ufs: Fix queue depth handling for best effort cases

Finn Thain (12):
      scsi/NCR5380: remove unused BOARD_NORMAL and BOARD_NCR53C400
      scsi/NCR5380: remove redundant HOSTS_C macro tests
      scsi/NCR5380: remove old CVS keywords
      scsi/NCR5380: use NCR5380_dprint() instead of NCR5380_print()
      scsi/NCR5380: fix build failures when debugging is enabled
      scsi/NCR5380: fix dprintk macro usage and definition
      scsi/NCR5380: adopt NCR5380_dprint() and NCR5380_dprint_phase()
      scsi/NCR5380: adopt dprintk()
      scsi/NCR5380: fix and standardize NDEBUG macros
      scsi/NCR5380: remove unused macro definitions
      scsi/NCR5380: reduce depth of sun3_scsi nested includes
      scsi/NCR5380: merge sun3_scsi_vme.c into sun3_scsi.c

Jayamohan Kallickal (8):
      be2iscsi: Fix retrieving MCCQ_WRB in non-embedded Mbox path
      be2iscsi: Fix exposing Host in sysfs after adapter initialization is complete
      be2iscsi: Fix interrupt Coalescing mechanism.
      be2iscsi: Fix TCP parameters while connection offloading.
      be2iscsi: Fix memory corruption in MBX path
      be2iscsi: Fix destroy MCC-CQ before MCC-EQ is destroyed
      be2iscsi: Fix processing cqe for cxn whose endpoint is freed
      be2iscsi: Bump the driver version

Joe Handzik (1):
      hpsa: fix bad comparison of signed with unsigned in hpsa_update_scsi_devices

Matthew Wilcox (7):
      mpt3sas: Remove uses of serial_number
      mpt3sas: Remove use of DEF_SCSI_QCMD
      mpt2sas: Remove uses of serial_number
      mpt2sas: Remove use of DEF_SCSI_QCMD
      mpt2sas: Add free smids to the head, not tail of list
      fusion: Add free msg frames to the head, not tail of list
      fusion: Remove use of DEF_SCSI_QCMD

Sujit Reddy Thumma (6):
      scsi: ufs: fix endianness sparse warnings
      scsi: ufs: make undeclared functions static
      scsi: ufs: Fix broken task management command implementation
      scsi: ufs: Fix hardware race conditions while aborting a command
      scsi: ufs: Fix device and host reset methods
      scsi: ufs: Improve UFS fatal error handling

 drivers/message/fusion/mptbase.c     |    2 +-
 drivers/message/fusion/mptfc.c       |   12 +-
 drivers/message/fusion/mptsas.c      |   10 +-
 drivers/message/fusion/mptscsih.c    |    8 +-
 drivers/message/fusion/mptscsih.h    |    2 +-
 drivers/message/fusion/mptspi.c      |   12 +-
 drivers/scsi/NCR5380.c               |  137 +++--
 drivers/scsi/NCR5380.h               |   32 +-
 drivers/scsi/arm/cumana_1.c          |    3 -
 drivers/scsi/arm/oak.c               |    3 -
 drivers/scsi/atari_NCR5380.c         |  162 +++---
 drivers/scsi/atari_scsi.c            |   22 +-
 drivers/scsi/atari_scsi.h            |   93 ---
 drivers/scsi/be2iscsi/be.h           |   11 +
 drivers/scsi/be2iscsi/be_cmds.h      |   31 +-
 drivers/scsi/be2iscsi/be_iscsi.c     |   12 +-
 drivers/scsi/be2iscsi/be_main.c      |   93 ++-
 drivers/scsi/be2iscsi/be_main.h      |    7 +-
 drivers/scsi/be2iscsi/be_mgmt.c      |   64 ++-
 drivers/scsi/be2iscsi/be_mgmt.h      |    2 +
 drivers/scsi/dtc.c                   |    2 -
 drivers/scsi/g_NCR5380.c             |    4 -
 drivers/scsi/g_NCR5380.h             |    7 -
 drivers/scsi/hpsa.c                  |    2 +-
 drivers/scsi/mac_scsi.c              |   10 -
 drivers/scsi/mac_scsi.h              |   10 -
 drivers/scsi/mpt2sas/mpt2sas_base.c  |    8 +-
 drivers/scsi/mpt2sas/mpt2sas_base.h  |    2 +-
 drivers/scsi/mpt2sas/mpt2sas_ctl.c   |    2 +-
 drivers/scsi/mpt2sas/mpt2sas_scsih.c |   24 +-
 drivers/scsi/mpt3sas/mpt3sas_base.h  |    2 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |    2 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |   24 +-
 drivers/scsi/pas16.h                 |    3 -
 drivers/scsi/qla2xxx/qla_mbx.c       |    3 +-
 drivers/scsi/qla2xxx/qla_os.c        |    3 +-
 drivers/scsi/qla4xxx/ql4_os.c        |    7 +-
 drivers/scsi/sun3_NCR5380.c          |  156 +++--
 drivers/scsi/sun3_scsi.c             |  238 +++++---
 drivers/scsi/sun3_scsi.h             |  199 +------
 drivers/scsi/sun3_scsi_vme.c         |  588 +------------------
 drivers/scsi/t128.c                  |    4 -
 drivers/scsi/t128.h                  |    7 -
 drivers/scsi/ufs/ufs.h               |   74 ++-
 drivers/scsi/ufs/ufshcd.c            | 1032 +++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h            |   22 +-
 drivers/scsi/ufs/ufshci.h            |   32 +-
 47 files changed, 1462 insertions(+), 1723 deletions(-)

Re: [ANNOUNCE] scsi patch queue tree

[Mike Christie]

On 05/28/2014 05:54 AM, Christoph Hellwig wrote:
>       be2iscsi: Fix processing cqe for cxn whose endpoint is freed

I didn't look at your tree, but when this patch was posted on the list I
think it had a bug.

http://www.spinics.net/lists/linux-scsi/msg74191.html

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

On Wed, May 28, 2014 at 10:37:31AM -0500, Mike Christie wrote:
> On 05/28/2014 05:54 AM, Christoph Hellwig wrote:
> >       be2iscsi: Fix processing cqe for cxn whose endpoint is freed
> 
> I didn't look at your tree, but when this patch was posted on the list I
> think it had a bug.
> 
> http://www.spinics.net/lists/linux-scsi/msg74191.html

I read through it and saw your comment, but so far it seems the patch
and especially the series does more good than harm.  I'll ping the
author again to get a fix for the issue you pointed out - I was planning
to do that anwyay.

Re: [ANNOUNCE] scsi patch queue tree

[Sujit Reddy Thumma]

On 5/28/2014 4:24 PM, Christoph Hellwig wrote:
> I've pushed the following changes to the drivers-for-3.16 tree.  I've
> there's anyting matching the rules that I did forget please resend
> and/or ping me.
>
>
> ----------------------------------------------------------------
> Benoit Taine (2):
>        qla4xxx: Use kmemdup instead of kmalloc + memcpy
>        qla2xxx: Use kmemdup instead of kmalloc + memcpy
>
> Dan Carpenter (1):
>        qla2xxx: fix incorrect debug printk
>
> Dolev Raviv (4):
>        scsi: ufs: query descriptor API
>        scsi: ufs: device query status and size check
>        scsi: ufs: Logical Unit (LU) command queue depth
>        scsi: ufs: Fix queue depth handling for best effort cases

The above 4 patches are just posted to mailing lists with no
review/ack's yet. I believe it still went in because the sender has
modified the author name to himself and signed-off by is present by the
original author which worked as a positive review for your rules. I
have asked the sender to check why the original author name is changed.
Meanwhile, I believe these patches should get some more time for review.


-- 
Regards,
Sujit

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

On Wed, May 28, 2014 at 09:31:14PM +0530, Sujit Reddy Thumma wrote:
> The above 4 patches are just posted to mailing lists with no
> review/ack's yet. I believe it still went in because the sender has
> modified the author name to himself and signed-off by is present by the
> original author which worked as a positive review for your rules. I
> have asked the sender to check why the original author name is changed.
> Meanwhile, I believe these patches should get some more time for review.

Yes, I did count this as a positive review for now.  I can drop the
patches for now.

Re: [ANNOUNCE] scsi patch queue tree

[Mike Christie]

On 05/28/2014 10:50 AM, Christoph Hellwig wrote:
> On Wed, May 28, 2014 at 10:37:31AM -0500, Mike Christie wrote:
>> On 05/28/2014 05:54 AM, Christoph Hellwig wrote:
>>>       be2iscsi: Fix processing cqe for cxn whose endpoint is freed
>>
>> I didn't look at your tree, but when this patch was posted on the list I
>> think it had a bug.
>>
>> http://www.spinics.net/lists/linux-scsi/msg74191.html
> 
> I read through it and saw your comment, but so far it seems the patch
> and especially the series does more good than harm.

Did you see these patchsets:

[PATCH 00/10] qla4xxx: 5.04.00-k5: Updates for scsi "misc" branch
and
[PATCH 0/6] qla4xxx: 5.04.00-k6: Updates for scsi "misc" branch

? I think they should be ok for your tree if you did not see any issues
with them.

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

On Wed, May 28, 2014 at 11:04:31AM -0500, Mike Christie wrote:
> Did you see these patchsets:
> 
> [PATCH 00/10] qla4xxx: 5.04.00-k5: Updates for scsi "misc" branch
> and
> [PATCH 0/6] qla4xxx: 5.04.00-k6: Updates for scsi "misc" branch
> 
> ? I think they should be ok for your tree if you did not see any issues
> with them.

I did merge them 10 days ago.

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

After this first pull for the 3.16 merge window it seems like this
worked out fairly well - we got a large number of patches in, and all
reviewed by a second pair of eyes.

How should we go on from this?  The drivers-for-3.16-2 branch, which had
the late lpfs and hpsa updates didn't make it into the pull request for
Linus, do you intend to skip them for this window?  If not do you still
want to have another branch for the other pending smaller updates?

Re: [ANNOUNCE] scsi patch queue tree

[James Bottomley]

On Wed, 2014-06-11 at 05:01 -0700, Christoph Hellwig wrote:
> After this first pull for the 3.16 merge window it seems like this
> worked out fairly well - we got a large number of patches in, and all
> reviewed by a second pair of eyes.
> 
> How should we go on from this?  The drivers-for-3.16-2 branch, which had
> the late lpfs and hpsa updates didn't make it into the pull request for
> Linus, do you intend to skip them for this window?  If not do you still
> want to have another branch for the other pending smaller updates?

No, I was waiting to check if there was any reason to have them split,
but I think we've scope today or tomorrow.

The only other outstanding thing is the fsync bug fix, which is waiting
Jens' investigation of the block issues it may cause, but I'm inclined
to send it anyway and fix up block later if there's a problem.

James

Re: [ANNOUNCE] scsi patch queue tree

[Christoph Hellwig]

On Wed, Jun 11, 2014 at 07:17:34AM -0700, James Bottomley wrote:
> No, I was waiting to check if there was any reason to have them split,
> but I think we've scope today or tomorrow.
> 
> The only other outstanding thing is the fsync bug fix, which is waiting
> Jens' investigation of the block issues it may cause, but I'm inclined
> to send it anyway and fix up block later if there's a problem.

There's various fixes marked for stable from Paolos virtio_scsi update,
which he asked to be considered for 3.16, including a core one:

  [PATCH v3 4/6] scsi_error: fix invalid setting of host byte

also

  [PATCH] sd: bad return code of init_sd

seems like another candidate for 3.16.