[GIT PULL] target: Updates for v3.3-rc1 (round 1)

[GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Nicholas A. Bellinger]

Hi Linus,

The following are the v3.3-rc1 merge window updates for the target
subsystem.  The series has been in linux-next since before the holiday
break, and can be pulled directly from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next-merge

The series has been cut against the following mainline commit:

commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Dec 9 15:09:32 2011 -0800

    Linux 3.2-rc5

The main highlights include:

*) Initial merge for the SRP target (ib_srpt) fabric module (bart)
*) Restructuring of target private + public target headers (hch)
*) Addition of target_submit_cmd() for fabrics (hch + nab)
*) Conversion of tcm_fc to use target_submit_cmd() (nab)
*) Remove legacy se_device TCQ depth handling (nab)
*) Remove extra se_device->execute_task_lock is fast path (nab)
*) Set missing additional sense length field (roland)

Please let us know if you have any questions.

Thanks!

--nab

Bart Van Assche (1):
  ib_srpt: Initial SRP Target merge for v3.3-rc1

Christoph Hellwig (7):
  target: reshuffle headers
  target: header reshuffle, part2
  target: fold se_task.task_sense into task_flags
  target: remove the se_task task_error_status field
  target: make the se_task task_state_active a normal bool
  tcm_loop: bump max_sectors
  target: remove overagressive ____cacheline_aligned annoations

Jörn Engel (3):
  target: Move core_scsi3_check_cdb_abort_and_preempt
  target: simplify target_check_cdb_and_preempt
  target: remove useless casts

Nicholas Bellinger (11):
  iscsi-target: fix chap identifier simple_strtoul usage
  Documentation/target: Fix tcm_mod_builder.py build breakage
  target: Make target_put_sess_cmd use target_release_cmd_kref
  target: Add target_submit_cmd() for process context fabric submission
  tcm_fc: Convert ft_send_work to use target_submit_cmd
  target: Remove TFO->check_release_cmd() fabric API caller
  target: Fix possible NULL pointer with __transport_execute_tasks
  target: Drop se_device TCQ queue_depth usage from I/O path
  target: Remove extra se_device->execute_task_lock access in fast path
  target: Remove __transport_execute_tasks() for each processing
    context
  target: Remove legacy device status check from
    transport_execute_tasks

Roland Dreier (2):
  target: Set response format in INQUIRY response
  target: Set additional sense length field in sense data

Sebastian Andrzej Siewior (3):
  target: use \n as a separator for configuration
  target/configs: remove trailing newline from udev_path and alias
  target: tcm_mod_builder: small fixups

 Documentation/target/tcm_mod_builder.py        |   60 +-
 drivers/infiniband/Kconfig                     |    1 +
 drivers/infiniband/Makefile                    |    1 +
 drivers/infiniband/ulp/srpt/Kconfig            |   12 +
 drivers/infiniband/ulp/srpt/Makefile           |    2 +
 drivers/infiniband/ulp/srpt/ib_dm_mad.h        |  139 +
 drivers/infiniband/ulp/srpt/ib_srpt.c          | 4073 ++++++++++++++++++++++++
 drivers/infiniband/ulp/srpt/ib_srpt.h          |  444 +++
 drivers/target/iscsi/iscsi_target.c            |   19 +-
 drivers/target/iscsi/iscsi_target_auth.c       |   36 +-
 drivers/target/iscsi/iscsi_target_configfs.c   |   11 +-
 drivers/target/iscsi/iscsi_target_device.c     |    3 +-
 drivers/target/iscsi/iscsi_target_erl0.c       |    2 +-
 drivers/target/iscsi/iscsi_target_erl1.c       |    2 +-
 drivers/target/iscsi/iscsi_target_erl2.c       |    2 +-
 drivers/target/iscsi/iscsi_target_login.c      |   23 +-
 drivers/target/iscsi/iscsi_target_nego.c       |    4 +-
 drivers/target/iscsi/iscsi_target_nodeattrib.c |    3 +-
 drivers/target/iscsi/iscsi_target_stat.c       |   17 +-
 drivers/target/iscsi/iscsi_target_tmr.c        |    2 +-
 drivers/target/iscsi/iscsi_target_tpg.c        |    6 +-
 drivers/target/iscsi/iscsi_target_util.c       |    8 +-
 drivers/target/loopback/tcm_loop.c             |   33 +-
 drivers/target/loopback/tcm_loop.h             |   11 +-
 drivers/target/target_core_alua.c              |    7 +-
 drivers/target/target_core_cdb.c               |   39 +-
 drivers/target/target_core_cdb.h               |   14 -
 drivers/target/target_core_configfs.c          |   34 +-
 drivers/target/target_core_device.c            |   15 +-
 drivers/target/target_core_fabric_configfs.c   |    8 +-
 drivers/target/target_core_fabric_lib.c        |   13 +-
 drivers/target/target_core_file.c              |   15 +-
 drivers/target/target_core_hba.c               |    7 +-
 drivers/target/target_core_hba.h               |    7 -
 drivers/target/target_core_iblock.c            |    7 +-
 drivers/target/target_core_internal.h          |  123 +
 drivers/target/target_core_pr.c                |   24 +-
 drivers/target/target_core_pr.h                |    2 -
 drivers/target/target_core_pscsi.c             |   20 +-
 drivers/target/target_core_rd.c                |    6 +-
 drivers/target/target_core_stat.c              |    9 +-
 drivers/target/target_core_stat.h              |    8 -
 drivers/target/target_core_tmr.c               |   36 +-
 drivers/target/target_core_tpg.c               |    9 +-
 drivers/target/target_core_transport.c         |  343 ++-
 drivers/target/target_core_ua.c                |    6 +-
 drivers/target/tcm_fc/tfc_cmd.c                |   57 +-
 drivers/target/tcm_fc/tfc_conf.c               |    6 +-
 drivers/target/tcm_fc/tfc_io.c                 |    5 +-
 drivers/target/tcm_fc/tfc_sess.c               |    5 +-
 include/target/target_core_backend.h           |   65 +
 include/target/target_core_base.h              |  169 +-
 include/target/target_core_device.h            |   63 -
 include/target/target_core_fabric.h            |  187 ++
 include/target/target_core_fabric_lib.h        |   28 -
 include/target/target_core_fabric_ops.h        |  105 -
 include/target/target_core_tmr.h               |   35 -
 include/target/target_core_tpg.h               |   35 -
 include/target/target_core_transport.h         |  287 --
 59 files changed, 5600 insertions(+), 1113 deletions(-)
 create mode 100644 drivers/infiniband/ulp/srpt/Kconfig
 create mode 100644 drivers/infiniband/ulp/srpt/Makefile
 create mode 100644 drivers/infiniband/ulp/srpt/ib_dm_mad.h
 create mode 100644 drivers/infiniband/ulp/srpt/ib_srpt.c
 create mode 100644 drivers/infiniband/ulp/srpt/ib_srpt.h
 delete mode 100644 drivers/target/target_core_cdb.h
 delete mode 100644 drivers/target/target_core_hba.h
 create mode 100644 drivers/target/target_core_internal.h
 delete mode 100644 drivers/target/target_core_stat.h
 create mode 100644 include/target/target_core_backend.h
 delete mode 100644 include/target/target_core_device.h
 create mode 100644 include/target/target_core_fabric.h
 delete mode 100644 include/target/target_core_fabric_lib.h
 delete mode 100644 include/target/target_core_fabric_ops.h
 delete mode 100644 include/target/target_core_tmr.h
 delete mode 100644 include/target/target_core_tpg.h
 delete mode 100644 include/target/target_core_transport.h

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Bart Van Assche]

2012/1/10 Nicholas A. Bellinger <nab@linux-iscsi.org>
> *) Initial merge for the SRP target (ib_srpt) fabric module (bart)

As far as I know the last time that patch was posted for review is
November 4 (http://permalink.gmane.org/gmane.linux.scsi.target.devel/420).
The date of the ib_srpt commit is December 16
(http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=a42d985bd5b234da8b61347a78dc3057bf7bb94d).
The two patches aren't identical. That makes me wonder whether that
patch should have been reposted for review ?

Thanks,

Bart.

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Nicholas A. Bellinger]

On Tue, 2012-01-10 at 19:19 +0000, Bart Van Assche wrote:
> 2012/1/10 Nicholas A. Bellinger <nab@linux-iscsi.org>
> > *) Initial merge for the SRP target (ib_srpt) fabric module (bart)
> 
> As far as I know the last time that patch was posted for review is
> November 4 (http://permalink.gmane.org/gmane.linux.scsi.target.devel/420).
> The date of the ib_srpt commit is December 16
> (http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=a42d985bd5b234da8b61347a78dc3057bf7bb94d).
> The two patches aren't identical. That makes me wonder whether that
> patch should have been reposted for review ?
> 

Hi Bart,

The changes since the Nov 4 RFC are listed in the patch commit log:

ib_srpt: Make compilation with BUG=n proceed`
ib_srpt: Use new target_core_fabric.h include
ib_srpt: Check hex2bin() return code to silence build warning

These are all very minor and did not warrant another full RFC posting.

--nab

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[James Bottomley]

On Tue, 2012-01-10 at 11:33 -0800, Nicholas A. Bellinger wrote:
> On Tue, 2012-01-10 at 19:19 +0000, Bart Van Assche wrote:
> > 2012/1/10 Nicholas A. Bellinger <nab@linux-iscsi.org>
> > > *) Initial merge for the SRP target (ib_srpt) fabric module (bart)
> > 
> > As far as I know the last time that patch was posted for review is
> > November 4 (http://permalink.gmane.org/gmane.linux.scsi.target.devel/420).
> > The date of the ib_srpt commit is December 16
> > (http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=a42d985bd5b234da8b61347a78dc3057bf7bb94d).
> > The two patches aren't identical. That makes me wonder whether that
> > patch should have been reposted for review ?
> > 
> 
> Hi Bart,
> 
> The changes since the Nov 4 RFC are listed in the patch commit log:
> 
> ib_srpt: Make compilation with BUG=n proceed`
> ib_srpt: Use new target_core_fabric.h include
> ib_srpt: Check hex2bin() return code to silence build warning
> 
> These are all very minor and did not warrant another full RFC posting.

They might not warrant a full RFC reposting, but individually they
should have been posted to the list, so Bart is right.

As a maintainer, there shouldn't be a patch in your tree that hasn't
been over the mailing list once.  This is for three reasons

     1. Git is a great source control tool, bit it doesn't hugely
        facilitate review.  Even virtuoso git users find it easier to
        read and reply to emailed patches for this purpose
     2. Not everyone in our community is a wholesale git user.  For
        them, email might be the only way they get to see a patch, so
        using git alone lowers our pool of reviewers (and reviewers are
        the species we most need to encourage)
     3. Enforcing the rule that everything is emailed first can save you
        from the maintainers curse:  the temptation to bung in that last
        little "obvious" fix just before you send your tree to Linus
        which later turns out to cause huge regressions and much
        heartache.

You don't have to endlessly repost patch series, just make sure that
small updates get posted for review and comment before they get applied.

James

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Nicholas A. Bellinger]

On Tue, 2012-01-10 at 13:51 -0600, James Bottomley wrote:
> On Tue, 2012-01-10 at 11:33 -0800, Nicholas A. Bellinger wrote:
> > On Tue, 2012-01-10 at 19:19 +0000, Bart Van Assche wrote:
> > > 2012/1/10 Nicholas A. Bellinger <nab@linux-iscsi.org>
> > > > *) Initial merge for the SRP target (ib_srpt) fabric module (bart)
> > > 
> > > As far as I know the last time that patch was posted for review is
> > > November 4 (http://permalink.gmane.org/gmane.linux.scsi.target.devel/420).
> > > The date of the ib_srpt commit is December 16
> > > (http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=a42d985bd5b234da8b61347a78dc3057bf7bb94d).
> > > The two patches aren't identical. That makes me wonder whether that
> > > patch should have been reposted for review ?
> > > 
> > 
> > Hi Bart,
> > 
> > The changes since the Nov 4 RFC are listed in the patch commit log:
> > 
> > ib_srpt: Make compilation with BUG=n proceed`
> > ib_srpt: Use new target_core_fabric.h include
> > ib_srpt: Check hex2bin() return code to silence build warning
> > 
> > These are all very minor and did not warrant another full RFC posting.
> 
> They might not warrant a full RFC reposting, but individually they
> should have been posted to the list, so Bart is right.
> 

Thanks for your input here, but the last two where reported to
linux-next / target-devel and fixed weeks ago.  The first one was from
Bart himself.

> As a maintainer, there shouldn't be a patch in your tree that hasn't
> been over the mailing list once.  This is for three reasons
> 
>      1. Git is a great source control tool, bit it doesn't hugely
>         facilitate review.  Even virtuoso git users find it easier to
>         read and reply to emailed patches for this purpose
>      2. Not everyone in our community is a wholesale git user.  For
>         them, email might be the only way they get to see a patch, so
>         using git alone lowers our pool of reviewers (and reviewers are
>         the species we most need to encourage)
>      3. Enforcing the rule that everything is emailed first can save you
>         from the maintainers curse:  the temptation to bung in that last
>         little "obvious" fix just before you send your tree to Linus
>         which later turns out to cause huge regressions and much
>         heartache.
> 
> You don't have to endlessly repost patch series, just make sure that
> small updates get posted for review and comment before they get applied.
> 

Yes, yes and yes.  :)

--nab

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Bart Van Assche]

2012/1/10 Nicholas A. Bellinger <nab@linux-iscsi.org>:
> These are all very minor and did not warrant another full RFC posting.

There is a reason why the ib_srpt patch should have been reposted:
Last WQE handling is still wrong, despite a patch being available
(http://www.spinics.net/lists/linux-rdma/msg09982.html).

Bart.

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Christoph Hellwig]

On Tue, Jan 10, 2012 at 01:51:07PM -0600, James Bottomley wrote:
> > The changes since the Nov 4 RFC are listed in the patch commit log:
> > 
> > ib_srpt: Make compilation with BUG=n proceed`
> > ib_srpt: Use new target_core_fabric.h include
> > ib_srpt: Check hex2bin() return code to silence build warning
> > 
> > These are all very minor and did not warrant another full RFC posting.
> 
> They might not warrant a full RFC reposting, but individually they
> should have been posted to the list, so Bart is right.

At least 2 and 3 list, just not as global patches against the
target tree, not ib_srpt specificly:

2 is from: [PATCH] target: header reshuffle, part2
3 is from: [PATCH 5/5] target: check hex2bin result

Not sure about 1.

I'm really getting tired of this bickering. It's a brand new driver and
doesn't have to be perfect.  While Bart generally has technically good
points there's really no reason to put his remaining fixups in after
the driver has been merged and available to a wieder audience.

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Nicholas A. Bellinger]

On Wed, 2012-01-11 at 07:57 +0100, Bart Van Assche wrote:
> 2012/1/10 Nicholas A. Bellinger <nab@linux-iscsi.org>:
> > These are all very minor and did not warrant another full RFC posting.
> 
> There is a reason why the ib_srpt patch should have been reposted:
> Last WQE handling is still wrong, despite a patch being available
> (http://www.spinics.net/lists/linux-rdma/msg09982.html).
> 

This patch was applied to lio-core.git, but considering that I've
received zero testing feedback on this I elected not to include it in
target-pending for the initial merge.

Once it can get some real testing it will be included into rc-fixes
along with the rest of the post merge-window updates.  So please, lets
not try to delay the merging of this driver (again) over bits that will
be addressed post -rc1.

Thanks,

--nab

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[Nicholas A. Bellinger]

On Tue, 2012-01-10 at 10:56 -0800, Nicholas A. Bellinger wrote:
> Hi Linus,
> 
> The following are the v3.3-rc1 merge window updates for the target
> subsystem.  The series has been in linux-next since before the holiday
> break, and can be pulled directly from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next-merge
> 
> The series has been cut against the following mainline commit:
> 
> commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Fri Dec 9 15:09:32 2011 -0800
> 
>     Linux 3.2-rc5
> 
> The main highlights include:
> 
> *) Initial merge for the SRP target (ib_srpt) fabric module (bart)
> *) Restructuring of target private + public target headers (hch)
> *) Addition of target_submit_cmd() for fabrics (hch + nab)
> *) Conversion of tcm_fc to use target_submit_cmd() (nab)
> *) Remove legacy se_device TCQ depth handling (nab)
> *) Remove extra se_device->execute_task_lock is fast path (nab)
> *) Set missing additional sense length field (roland)
> 
> Please let us know if you have any questions.
> 

Hi Linus,

Just a friendly ping on this pull request for -rc1.  Please go ahead and
pull at your earliest convenience, and let us know if you have any
questions or concerns.

Thank you,

--nab

Re: [GIT PULL] target: Updates for v3.3-rc1 (round 1)

[James Bottomley]

On Wed, 2012-01-11 at 05:49 -0500, Christoph Hellwig wrote:
> On Tue, Jan 10, 2012 at 01:51:07PM -0600, James Bottomley wrote:
> > > The changes since the Nov 4 RFC are listed in the patch commit log:
> > > 
> > > ib_srpt: Make compilation with BUG=n proceed`
> > > ib_srpt: Use new target_core_fabric.h include
> > > ib_srpt: Check hex2bin() return code to silence build warning
> > > 
> > > These are all very minor and did not warrant another full RFC posting.
> > 
> > They might not warrant a full RFC reposting, but individually they
> > should have been posted to the list, so Bart is right.
> 
> At least 2 and 3 list, just not as global patches against the
> target tree, not ib_srpt specificly:
> 
> 2 is from: [PATCH] target: header reshuffle, part2
> 3 is from: [PATCH 5/5] target: check hex2bin result
> 
> Not sure about 1.
> 
> I'm really getting tired of this bickering. It's a brand new driver and
> doesn't have to be perfect.  While Bart generally has technically good
> points there's really no reason to put his remaining fixups in after
> the driver has been merged and available to a wieder audience.

Absolutely.  I was just reminding about git best practises, not NAKing a
pull.  Putting this in the kernel and sorting out the rough edges later
is fine by me ... just make sure the rough edges go over the list ...

James