Patchwork [GIT,PULL] libsas fixes for 3.4-rc4

login
register
mail settings
Submitter Dan Williams
Date April 20, 2012, 10:29 p.m.
Message ID <1334960945.21447.19.camel@ultramagnus.opencreations.com>
Download mbox
Permalink /patch/154168/
State Not Applicable
Delegated to: David Miller
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/djbw/isci.git tags/libsas-fixes

Comments

Dan Williams - April 20, 2012, 10:29 p.m.
Linus,

The following changes since commit cd8df932d894f3128c884e3ae1b2b484540513db:

  [SCSI] qla4xxx: Update driver version to 5.02.00-k15 (2012-02-29 17:03:03 -0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/djbw/isci.git tags/libsas-fixes

for you to fetch changes up to 3385b6baa9f3bbf69d4c1fc58342936e75d095b1:

  Revert "[SCSI] libsas: fix sas port naming" (2012-04-19 23:48:12 -0700)

----------------------------------------------------------------
libsas-fixes for 3.4-rc4

Regression fixes to stabilize the new workqueue and ata asynchronous
error handling implementation that was merged for v3.4-rc1.

1/ fix regression in sas_drain_work() which was stomping on 'work'
   entries while the workqueue was manipulating them.  User sees
   random crashes when trying to use scsi_transport_sas attributes for
   resets, or during discovery.

2/ (2) longstanding bugs related to the fact that libata (inventor and
   primary host_eh_scheduled user) had built-in assumptions of 1:1
   Scsi_Host-to-ata_port relationship.  The libsas 1:N arrangement
   magnified these problems when it gained async eh and began scheduling
   eh in more scenarios (sas-transports resets) in 3.4-rc1.

3/ lifetime fixes for the rphy since code that has a domain_device
   reference expects to be able to de-reference rphy parameters.

4/ (3) fixes for expander discovery bugs, one a recent regression with
   ata-eh clobbering expander-phy data as it polled leading to system
   crashes, a long standing bug that caused libsas to be
   incompatible with expanders that advertised "PHY_VACANT" in low order
   phy indexes, and a quirk for expanders that sometimes fail to zero
   the sas address when no device is attached.

5/ fix for a long-standing bug whereby hotunplug events during initial
   host scan can cause a system crash

6/ fix for a mvsas regression caused by the new end-device naming in
   libsas making the incorrect assumption that at all phy ids
   exported by an lldd are unique.

----------------------------------------------------------------

These patches, save for the new "scsi: fix eh wakeup (scsi_schedule_eh
vs scsi_restart_operations)" and "Revert "[SCSI] libsas: fix sas port
naming", were all originally posted before the merge
window opened, and have also appeared in -next for the same timeframe.

The commit dates are not that aged (9 days old) because they were
rebased out of larger set of updates that were pending for 3.4.

There is a mix of pure regression fixes and fixes for long-standing bugs
in libsas.  Some of the long-standing bug fixes are made worse / easier
to trigger by the new async error handling scheme.

The largest patch in the series is "libata, libsas: introduce sched_eh
and end_eh port ops" it has been on the list since March 10th.

Jack Wang has independently tested this set with pm8001 and reports
success. [1]

Apologies if scsi-rc-fixes was in the process of picking these up.  With
-rc4 looming I lost my nerve and pulled the trigger.

--
Dan


[1]: http://www.spinics.net/lists/linux-scsi/msg58761.html

Dan Williams (11):
      libsas: introduce sas_work to fix sas_drain_work vs sas_queue_work
      libata, libsas: introduce sched_eh and end_eh port ops
      libsas: fix sas_get_port_device regression
      libsas: unify domain_device sas_rphy lifetimes
      libsas: fix ata_eh clobbering ex_phys via smp_ata_check_ready
      libata: make ata_print_id atomic
      libsas, libata: fix start of life for a sas ata_port
      scsi: fix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)
      libsas: fix false positive 'device attached' conditions
      scsi_transport_sas: fix delete vs scan race
      Revert "[SCSI] libsas: fix sas port naming"

Maciej Trela (1):
      libsas: cleanup spurious calls to scsi_schedule_eh

Thomas Jackson (1):
      libsas: fix sas_find_bcast_phy() in the presence of 'vacant' phys

 drivers/ata/libata-core.c           |    8 +++-
 drivers/ata/libata-eh.c             |   57 +++++++++++++++++++++------
 drivers/ata/libata-scsi.c           |   35 +++++++++--------
 drivers/ata/libata.h                |    2 +-
 drivers/scsi/ipr.c                  |    6 ++-
 drivers/scsi/libsas/sas_ata.c       |   72 +++++++++++++++++++++--------------
 drivers/scsi/libsas/sas_discover.c  |   67 ++++++++++++++++++--------------
 drivers/scsi/libsas/sas_event.c     |   36 +++++++++---------
 drivers/scsi/libsas/sas_expander.c  |   56 +++++++++++++++++++++------
 drivers/scsi/libsas/sas_init.c      |   25 ++++++------
 drivers/scsi/libsas/sas_internal.h  |    6 +--
 drivers/scsi/libsas/sas_phy.c       |   21 ++++------
 drivers/scsi/libsas/sas_port.c      |   17 +++------
 drivers/scsi/libsas/sas_scsi_host.c |   28 ++++++++++----
 drivers/scsi/scsi_error.c           |   14 +++++++
 drivers/scsi/scsi_transport_sas.c   |    6 ++-
 include/linux/libata.h              |    7 +++-
 include/scsi/libsas.h               |   44 ++++++++++++++++++---
 include/scsi/sas_ata.h              |    9 ++++-
 19 files changed, 344 insertions(+), 172 deletions(-)


commit 3385b6baa9f3bbf69d4c1fc58342936e75d095b1
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Apr 19 23:48:12 2012 -0700

    Revert "[SCSI] libsas: fix sas port naming"
    
    This reverts commit a692b0eec5efae382dfa800e8b4b083f172921a7.
    
    Tom reports:
    
    [    8.741033] ------------[ cut here ]------------
    [    8.741038] WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0xc1/0xf0()
    [    8.741040] Hardware name: To Be Filled By O.E.M.
    [    8.741041] sysfs: cannot create duplicate filename
    
    ...and missing 2 out of 4 drives connected to mvsas.  Commit a692b0ee
    made the assumption that all the phy ids an lldd registers to libsas are
    unique.  However, in the "multi-chip" case mvsas does a rather annoying
    duplication of phy ids in the array passed to libsas.  So, for example,
    chip0 has phy0-3 at ha phy index 0-3 and chip1 has its phy0-3 at ha phy
    index 4-7.  The more natural model would be to create a scsi_host (and
    sas_ha) per chip (controller), but for now revert the naming fix which
    unfortunately means dealing with unpredictable end-device names for a
    bit longer.
    
    Cc: Xiangliang Yu <yuxiangl@marvell.com>
    Cc: Patrick Thomson <patrick.s.thomson@intel.com>
    Reported-by: Tom Rini <trini@ti.com>
    Tested-by: Tom Rini <trini@ti.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit e81dcce46fdbb2c968d7314c2f19da3c2bba24d1
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Mar 20 10:58:38 2012 -0700

    scsi_transport_sas: fix delete vs scan race
    
    The following crash results from cases where the end_device has been
    removed before scsi_sysfs_add_sdev has had a chance to run.
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
     IP: [<ffffffff8115e100>] sysfs_create_dir+0x32/0xb6
     ...
     Call Trace:
      [<ffffffff8125e4a8>] kobject_add_internal+0x120/0x1e3
      [<ffffffff81075149>] ? trace_hardirqs_on+0xd/0xf
      [<ffffffff8125e641>] kobject_add_varg+0x41/0x50
      [<ffffffff8125e70b>] kobject_add+0x64/0x66
      [<ffffffff8131122b>] device_add+0x12d/0x63a
      [<ffffffff814b65ea>] ? _raw_spin_unlock_irqrestore+0x47/0x56
      [<ffffffff8107de15>] ? module_refcount+0x89/0xa0
      [<ffffffff8132f348>] scsi_sysfs_add_sdev+0x4e/0x28a
      [<ffffffff8132dcbb>] do_scan_async+0x9c/0x145
    
    ...teach sas_rphy_remove to wait for async scanning to quiesce before
    removing the end_device.  It seems this is a more general problem [1],
    but this patch only addresses sas transport.
    
    [1]: 23edb6e [SCSI] mpt2sas: Do not set sas_device->starget to NULL from
    the slave_destroy callback when all the LUNS have been deleted
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 55c53f6aed389e9e789df8d8e65d728ac125dba1
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Mar 20 10:50:27 2012 -0700

    libsas: fix false positive 'device attached' conditions
    
    Normalize phy->attached_sas_addr to return a zero-address in the case
    when device-type == NO_DEVICE or the linkrate is invalid to handle
    expanders that put non-zero sas addresses in the discovery response:
    
     sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device)
     sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device)
     sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device)
     sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device)
    
    Reported-by: Andrzej Jakowski <andrzej.jakowski@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit fcc1ce20ffbc553b25b6c635f4bb838940f58d2d
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Apr 6 16:35:36 2012 -0700

    scsi: fix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)
    
    Rapid ata hotplug on a libsas controller results in cases where libsas
    is waiting indefinitely on eh to perform an ata probe.
    
    A race exists between scsi_schedule_eh() and scsi_restart_operations()
    in the case when scsi_restart_operations() issues i/o to other devices
    in the sas domain.  When this happens the host state transitions from
    SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
    ->host_busy is non-zero so we put the eh thread to sleep even though
    ->host_eh_scheduled is active.
    
    Before putting the error handler to sleep we need to check if the
    host_state needs to return to SHOST_RECOVERY for another trip through
    eh.
    
    Cc: Tejun Heo <tj@kernel.org>
    Reported-by: Tom Jackson <thomas.p.jackson@intel.com>
    Tested-by: Tom Jackson <thomas.p.jackson@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit fcf62bdd26101fe6ae8760c5e9eb4d5e49e0a5ec
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Mar 21 21:09:07 2012 -0700

    libsas, libata: fix start of life for a sas ata_port
    
    This changes the ordering of initialization and probing events from:
      1/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN
      2/ allocate ata_port and schedule port probe in DISCE_PROBE
    ...to:
      1/ allocate ata_port in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN
      2/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN
      3/ schedule port probe in DISCE_PROBE
    
    This ordering prevents PHYE_SIGNAL_LOSS_EVENTS from sneaking in to
    destrory ata devices before they have been fully initialized:
    
      BUG: unable to handle kernel paging request at 0000000000003b10
      IP: [<ffffffffa0053d7e>] sas_ata_end_eh+0x12/0x5e [libsas]
      ...
      [<ffffffffa004d1af>] sas_unregister_common_dev+0x78/0xc9 [libsas]
      [<ffffffffa004d4d4>] sas_unregister_dev+0x4f/0xad [libsas]
      [<ffffffffa004d5b1>] sas_unregister_domain_devices+0x7f/0xbf [libsas]
      [<ffffffffa004c487>] sas_deform_port+0x61/0x1b8 [libsas]
      [<ffffffffa004bed0>] sas_phye_loss_of_signal+0x29/0x2b [libsas]
    
    ...and kills the awkward "sata domain_device briefly existing in the
    domain without an ata_port" state.
    
    Reported-by: Michal Kosciowski <michal.kosciowski@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit cb7e940b56fc8a67a6a17bc7935268f7b128f90d
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Mar 21 21:09:05 2012 -0700

    libata: make ata_print_id atomic
    
    This variable is incremented from multiple contexts (module_init via
    libata-lldds and the libsas discovery thread).  Make it atomic to head
    off any chance of libsas and libata creating duplicate ids.
    
    Acked-by: Jacek Danecki <jacek.danecki@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 6ec4dacc7c11b5999abe78f9a7e0125062b1d660
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Mar 20 13:24:29 2012 -0700

    libsas: fix ata_eh clobbering ex_phys via smp_ata_check_ready
    
    The check_ready implementation in the expander-attached ata device case
    polls on sas_ex_phy_discover().  The effect is that the ex_phy fields
    (critically ->attached_sas_addr) can change.  When ata_eh ends and
    libsas comes along to revalidate the domain
    sas_unregister_devs_sas_addr() can fail to lookup devices to remove, or
    fail to re-add an ata device that ata_eh marked as disabled.  So change
    the code to skip the sas_address and change count updates when ata_eh is
    active.
    
    Cc: Jack Wang <jack_wang@usish.com>
    Tested-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
    Tested-by: Bartek Nowakowski <bartek.nowakowski@intel.com>
    Tested-by: Jacek Danecki <jacek.danecki@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit db25a56d901cfc259240d6b6cf999170d7f35fff
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Mar 20 10:53:24 2012 -0700

    libsas: unify domain_device sas_rphy lifetimes
    
    Since the domain_device can out live the scsi_target we need the rphy to
    follow suit otherwise we run into issues like:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      IP: [<ffffffffa011561b>] sas_ata_printk+0x43/0x6f [libsas]
      PGD 0
      Oops: 0000 [#1] SMP
      CPU 1
      Modules linked in: ses enclosure isci libsas scsi_transport_sas fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf microcode pcspkr igb joydev iTCO_wdt ioatdma iTCO_vendor_support i2c_i801 i2c_core dca wmi hed ipv6 pata_acpi ata_generic [last unloaded: scsi_wait_scan]
    
      Pid: 129, comm: kworker/u:3 Not tainted 3.3.0-rc5-isci+ #1 Intel Corporation SandyBridge Platform/To be filled by O.E.M.
      RIP: 0010:[<ffffffffa011561b>] [<ffffffffa011561b>] sas_ata_printk+0x43/0x6f [libsas]
      RSP: 0018:ffff88042232dd70 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff8804283165b8 RCX: ffff88042232dda0
      RDX: ffff88042232dd78 RSI: ffff8804283165b8 RDI: ffffffffa01188d7
      RBP: ffff88042232ddd0 R08: ffff880388454000 R09: ffff8803edfde1f8
      R10: ffff8803edfde1f8 R11: ffff8803edfde1f8 R12: ffff880428316750
      R13: ffff880388454000 R14: ffff8803f88b31d0 R15: ffff8803f8b21d50
      FS: 0000000000000000(0000) GS:ffff88042ee20000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000050 CR3: 0000000001a05000 CR4: 00000000000406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kworker/u:3 (pid: 129, threadinfo ffff88042232c000, task ffff88042230c920)
      Stack:
      0000000000000000 ffff880400000018 ffff88042232dde0 ffff88042232dda0
      ffffffffa01188c4 ffff88042ee93af0 ffff88042232ddb0 ffffffff8100e047
      ffff88042232de10 ffff880420e5a2c8 ffff8803f8b21d50 ffff8803edfde1f8
      Call Trace:
      [<ffffffff8100e047>] ? load_TLS+0xb/0xf
      [<ffffffffa01156ad>] async_sas_ata_eh+0x66/0x95 [libsas]
      [<ffffffff810655e1>] async_run_entry_fn+0x9e/0x131
    
    Reported-by: Tom Jackson <thomas.p.jackson@intel.com>
    Tested-by: Tom Jackson <thomas.p.jackson@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 6be254f019fd8dadc63cc63ded75d2422e2057b7
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Mar 12 11:38:26 2012 -0700

    libsas: fix sas_get_port_device regression
    
    Commit 899fcf4 "[SCSI] libsas: set attached device type and target
    protocols for local phys" setup 'phy' to be dereferenced after
    list_for_each_entry(phy, &port->phy_list, port_phy_el) (i.e. phy ==
    &port->phy_list) resulting in reports like:
    
      BUG: unable to handle kernel NULL pointer dereference at 00000000000002b0
      IP: [<ffffffffa00ce948>] sas_discover_domain+0x29e/0x4fb [libsas]
    
    ...fix by deferring sas_phy_set_target() to the end of
    sas_get_port_device().
    
    Reported-by: Tom Jackson <thomas.p.jackson@intel.com>
    Tested-by: Tom Jackson <thomas.p.jackson@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 71cb71d183256fbe77f35558606989c8f47c4ff0
Author: Thomas Jackson <thomas.p.jackson@intel.com>
Date:   Fri Feb 17 18:33:10 2012 -0800

    libsas: fix sas_find_bcast_phy() in the presence of 'vacant' phys
    
    If an expander reports 'PHY VACANT' for a phy index prior to the one
    that generated a BCN libsas fails rediscovery.  Since a vacant phy is
    defined as a valid phy index that will never have an attached device
    just continue the search.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Thomas Jackson <thomas.p.jackson@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 705885cb7b906ebddafbaedd693c355f8350ac4e
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Mar 1 18:44:25 2012 -0800

    libata, libsas: introduce sched_eh and end_eh port ops
    
    When managing shost->host_eh_scheduled libata assumes that there is a
    1:1 shost-to-ata_port relationship.  libsas creates a 1:N relationship
    so it needs to manage host_eh_scheduled cumulatively at the host level.
    The sched_eh and end_eh port port ops allow libsas to track when domain
    devices enter/leave the "eh-pending" state under ha->lock (previously
    named ha->state_lock, but it is no longer just a lock for ha->state
    changes).
    
    Since host_eh_scheduled indicates eh without backing commands pinning
    the device it can be deallocated at any time.  Move the taking of the
    domain_device reference under the port_lock to guarantee that the
    ata_port stays around for the duration of eh.
    
    Cc: Tejun Heo <tj@kernel.org>
    Acked-by: Jacek Danecki <jacek.danecki@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 3c1dbbd2529c659745c047c449037e4f94d326cb
Author: Maciej Trela <maciej.trela@intel.com>
Date:   Sun Mar 4 17:58:55 2012 -0800

    libsas: cleanup spurious calls to scsi_schedule_eh
    
    eh is woken up automatically by the presence of failed commands,
    scsi_schedule_eh is reserved for cases where there are no failed
    commands.  This guarantees that host_eh_sceduled is only incremented
    when an explicit eh request is made.
    
    Reviewed-by: Jacek Danecki <jacek.danecki@intel.com>
    Signed-off-by: Maciej Trela <maciej.trela@intel.com>
    [fixed spurious delete of sas_ata_task_abort]
    Signed-off-by: Artur Wojcik <artur.wojcik@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 63494f1cc2022fd9271c0af3399df3bc7dbec55c
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Mar 9 11:00:06 2012 -0800

    libsas: introduce sas_work to fix sas_drain_work vs sas_queue_work
    
    When requeuing work to a draining workqueue the last work instance may
    not be idle, so sas_queue_work() must not touch work->entry.  Introduce
    sas_work with a drain_node list_head to have a private list for
    collecting work deferred due to drain collision.
    
    Fixes reports like:
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810410d4>] process_one_work+0x2e/0x338
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
James Bottomley - April 21, 2012, 12:28 p.m.
On Fri, 2012-04-20 at 15:29 -0700, Dan Williams wrote:
> These patches, save for the new "scsi: fix eh wakeup (scsi_schedule_eh
> vs scsi_restart_operations)" and "Revert "[SCSI] libsas: fix sas port
> naming", were all originally posted before the merge
> window opened, and have also appeared in -next for the same timeframe.
> 
> The commit dates are not that aged (9 days old) because they were
> rebased out of larger set of updates that were pending for 3.4.
> 
> There is a mix of pure regression fixes and fixes for long-standing bugs
> in libsas.  Some of the long-standing bug fixes are made worse / easier
> to trigger by the new async error handling scheme.
> 
> The largest patch in the series is "libata, libsas: introduce sched_eh
> and end_eh port ops" it has been on the list since March 10th.
> 
> Jack Wang has independently tested this set with pm8001 and reports
> success. [1]
> 
> Apologies if scsi-rc-fixes was in the process of picking these up.  With
> -rc4 looming I lost my nerve and pulled the trigger.

Right, so as a point of process, these are SCSI fixes and are supposed
to be going through the SCSI tree.  The only urgent one is the revert; I
still have outstanding questions about some of the others.

We're at least 3 weeks away from 3.4 (and that's only if -rc6 is final),
so there's time to address all of this via the usual process.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dan Williams - April 21, 2012, 7:57 p.m.
On Sat, Apr 21, 2012 at 5:28 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Fri, 2012-04-20 at 15:29 -0700, Dan Williams wrote:
>> These patches, save for the new "scsi: fix eh wakeup (scsi_schedule_eh
>> vs scsi_restart_operations)" and "Revert "[SCSI] libsas: fix sas port
>> naming", were all originally posted before the merge
>> window opened, and have also appeared in -next for the same timeframe.
>>
>> The commit dates are not that aged (9 days old) because they were
>> rebased out of larger set of updates that were pending for 3.4.
>>
>> There is a mix of pure regression fixes and fixes for long-standing bugs
>> in libsas.  Some of the long-standing bug fixes are made worse / easier
>> to trigger by the new async error handling scheme.
>>
>> The largest patch in the series is "libata, libsas: introduce sched_eh
>> and end_eh port ops" it has been on the list since March 10th.
>>
>> Jack Wang has independently tested this set with pm8001 and reports
>> success. [1]
>>
>> Apologies if scsi-rc-fixes was in the process of picking these up.  With
>> -rc4 looming I lost my nerve and pulled the trigger.
>
> Right, so as a point of process, these are SCSI fixes and are supposed
> to be going through the SCSI tree.  The only urgent one is the revert; I
> still have outstanding questions about some of the others.

Up until this feedback I thought the branch was going to be pulled
intact.  So, not trying to subvert process, just thought this request
would be seen as helpful since you seem to have been rather busy of
late.  Yes, I'd much rather these go through the SCSI tree.

> We're at least 3 weeks away from 3.4 (and that's only if -rc6 is final),
> so there's time to address all of this via the usual process.

My concern is that:

 19 files changed, 344 insertions(+), 172 deletions(-)

...is something that should have went in at -rc2.  Waiting longer
likely means cutting down the list even more and either turning it
into something nobody has given serious test time to, or leaving known
bugs un-addressed for 3.4-final.  Some of these we have lived with for
a while, but are worse with the 3.4-rc1 reworked libsas workqueue and
new async error handling changes.  For grey area "is this a pure
regression fix vs old bug that could maybe wait" I thought the earlier
the rc the better.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeff Garzik - April 21, 2012, 11:39 p.m.
On 04/21/2012 03:57 PM, Dan Williams wrote:
> On Sat, Apr 21, 2012 at 5:28 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com>  wrote:
>> On Fri, 2012-04-20 at 15:29 -0700, Dan Williams wrote:
>>> These patches, save for the new "scsi: fix eh wakeup (scsi_schedule_eh
>>> vs scsi_restart_operations)" and "Revert "[SCSI] libsas: fix sas port
>>> naming", were all originally posted before the merge
>>> window opened, and have also appeared in -next for the same timeframe.
>>>
>>> The commit dates are not that aged (9 days old) because they were
>>> rebased out of larger set of updates that were pending for 3.4.
>>>
>>> There is a mix of pure regression fixes and fixes for long-standing bugs
>>> in libsas.  Some of the long-standing bug fixes are made worse / easier
>>> to trigger by the new async error handling scheme.
>>>
>>> The largest patch in the series is "libata, libsas: introduce sched_eh
>>> and end_eh port ops" it has been on the list since March 10th.
>>>
>>> Jack Wang has independently tested this set with pm8001 and reports
>>> success. [1]
>>>
>>> Apologies if scsi-rc-fixes was in the process of picking these up.  With
>>> -rc4 looming I lost my nerve and pulled the trigger.
>>
>> Right, so as a point of process, these are SCSI fixes and are supposed
>> to be going through the SCSI tree.  The only urgent one is the revert; I
>> still have outstanding questions about some of the others.
>
> Up until this feedback I thought the branch was going to be pulled
> intact.  So, not trying to subvert process, just thought this request
> would be seen as helpful since you seem to have been rather busy of
> late.  Yes, I'd much rather these go through the SCSI tree.

[thread semi-hijacking]

Busy-ness++  :/   I'm a bit disappointed that these one-liner bug fixes 
for SCSI have not been applied, despite repeated pings:

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

Over a month has passed with zero comments (or objections), and we've 
now missed -rc4.

Unless I hear soon, I'll throw them into libata-dev (thus, linux-next) 
and kick them upstairs.

James has been replying to other stuff on the lists, so I'm not really 
sure how these basic, one-liner fixes keep slipping by.

	Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html