1. 06 Mar, 2015 1 commit
    • James Bottomley's avatar
      libsas: Fix Kernel Crash in smp_execute_task · 6302ce4d
      James Bottomley authored
      This crash was reported:
      
      [  366.947370] sd 3:0:1:0: [sdb] Spinning up disk....
      [  368.804046] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  368.804072] IP: [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.804098] PGD 0
      [  368.804114] Oops: 0002 [#1] SMP
      [  368.804143] CPU 1
      [  368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common
      [  368.804749]
      [  368.804764] Pid: 392, comm: kworker/u:3 Tainted: P        W  O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920
      [  368.804802] RIP: 0010:[<ffffffff81358457>]  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.804827] RSP: 0018:ffff880117001cc0  EFLAGS: 00010246
      [  368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420
      [  368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4
      [  368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe
      [  368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4
      [  368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8
      [  368.804916] FS:  0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000
      [  368.804931] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0
      [  368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0)
      [  368.805009] Stack:
      [  368.805017]  ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c
      [  368.805062]  000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000
      [  368.805100]  ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac
      [  368.805135] Call Trace:
      [  368.805153]  [<ffffffff81056f7c>] ? up+0xb/0x33
      [  368.805168]  [<ffffffff813583ac>] ? mutex_lock+0x16/0x25
      [  368.805194]  [<ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas]
      [  368.805217]  [<ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas]
      [  368.805240]  [<ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas]
      [  368.805264]  [<ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas]
      [  368.805280]  [<ffffffff81355a2a>] ? printk+0x43/0x48
      [  368.805296]  [<ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd
      [  368.805318]  [<ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas]
      [  368.805336]  [<ffffffff8104e5d9>] ? process_one_work+0x151/0x27c
      [  368.805351]  [<ffffffff8104f6cd>] ? worker_thread+0xbb/0x152
      [  368.805366]  [<ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163
      [  368.805382]  [<ffffffff81052c4e>] ? kthread+0x79/0x81
      [  368.805399]  [<ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10
      [  368.805416]  [<ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9
      [  368.805431]  [<ffffffff8135fea0>] ? gs_change+0x13/0x13
      [  368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41
      [  368.805851] RIP  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.805877]  RSP <ffff880117001cc0>
      [  368.805886] CR2: 0000000000000000
      [  368.805899] ---[ end trace b720682065d8f4cc ]---
      
      It's directly caused by 89d3cf6a
      
       [SCSI] libsas: add mutex for SMP task
      execution, but shows a deeper cause: expander functions expect to be able to
      cast to and treat domain devices as expanders.  The correct fix is to only do
      expander discover when we know we've got an expander device to avoid wrongly
      casting a non-expander device.
      
      Reported-by: default avatarPraveen Murali <pmurali@logicube.com>
      Tested-by: default avatarPraveen Murali <pmurali@logicube.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      6302ce4d
  2. 10 May, 2013 1 commit
    • James Bottomley's avatar
      [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type · aa9f8328
      James Bottomley authored
      
      
      These enums have been separate since the dawn of SAS, mainly because the
      latter is a procotol only enum and the former includes additional state
      for libsas.  The dichotomy causes endless confusion about which one you
      should use where and leads to pointless warnings like this:
      
      drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
      drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between 'enum sas_device_type' and 'enum sas_dev_type' [-Wenum-compare]
      
      Fix by eliminating one of them.  The one kept is effectively the sas.h
      one, but call it sas_device_type and make sure the enums are all
      properly namespaced with the SAS_ prefix.
      
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      aa9f8328
  3. 24 Aug, 2012 1 commit
    • Dan Williams's avatar
      [SCSI] libsas: suspend / resume support · 303694ee
      Dan Williams authored
      
      
      libsas power management routines to suspend and recover the sas domain
      based on a model where the lldd is allowed and expected to be
      "forgetful".
      
      sas_suspend_ha - disable event processing allowing the lldd to take down
                       links without concern for causing hotplug events.
                       Regardless of whether the lldd actually posts link down
                       messages libsas notifies the lldd that all
                       domain_devices are gone.
      
      sas_prep_resume_ha - on the way back up before the lldd starts link
                           training clean out any spurious events that were
                           generated on the way down, and re-enable event
                           processing
      
      sas_resume_ha - after the lldd has started and decided that all phys
      		have posted link-up events this routine is called to let
      		libsas start it's own timeout of any phys that did not
      		resume.  After the timeout an lldd can cancel the
                      phy teardown by posting a link-up event.
      
      Storage for ex_change_count (u16) and phy_change_count (u8) are changed
      to int so they can be set to -1 to indicate 'invalidated'.
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: default avatarJacek Danecki <jacek.danecki@intel.com>
      Tested-by: default avatarMaciej Patelczyk <maciej.patelczyk@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      303694ee
  4. 20 Jul, 2012 3 commits
  5. 23 Apr, 2012 4 commits
    • Dan Williams's avatar
      [SCSI] libsas, libata: fix start of life for a sas ata_port · b2024459
      Dan Williams authored
      
      
      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: default avatarMichal Kosciowski <michal.kosciowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      b2024459
    • Dan Williams's avatar
      [SCSI] libsas: unify domain_device sas_rphy lifetimes · 9487669f
      Dan Williams authored
      
      
      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: default avatarTom Jackson <thomas.p.jackson@intel.com>
      Tested-by: default avatarTom Jackson <thomas.p.jackson@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      9487669f
    • Dan Williams's avatar
      [SCSI] libsas: fix sas_get_port_device regression · ec236e52
      Dan Williams authored
      Commit 899fcf40
      
       "[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: default avatarTom Jackson <thomas.p.jackson@intel.com>
      Tested-by: default avatarTom Jackson <thomas.p.jackson@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      ec236e52
    • Dan Williams's avatar
      [SCSI] libsas: introduce sas_work to fix sas_drain_work vs sas_queue_work · 22b9153f
      Dan Williams authored
      
      
      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: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      22b9153f
  6. 29 Feb, 2012 8 commits
    • Dan Williams's avatar
      [SCSI] libsas: set attached device type and target protocols for local phys · 899fcf40
      Dan Williams authored
      
      
      Before:
      $ cat /sys/class/sas_phy/phy-6\:3/device_type
      none
      $ cat /sys/class/sas_phy/phy-6\:3/target_port_protocols
      none
      
      After:
      $ cat /sys/class/sas_phy/phy-6\:3/device_type
      end device
      $ cat /sys/class/sas_phy/phy-6\:3/target_port_protocols
      sata
      
      Also downgrade the phy_list_lock to _irq instead of _irqsave since
      libsas will never call sas_get_port_device with interrupts disbled.
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      899fcf40
    • Dan Williams's avatar
      [SCSI] libsas: async ata scanning · 9508a66f
      Dan Williams authored
      
      
      libsas ata error handling is already async but this does not help the
      scan case.  Move initial link recovery out from under host->scan_mutex,
      and delay synchronization with eh until after all port probe/recovery
      work has been queued.
      
      Device ordering is maintained with scan order by still calling
      sas_rphy_add() in order of domain discovery.
      
      Since we now scan the domain list when invoking libata-eh we need to be
      careful to check for fully initialized ata ports.
      
      Acked-by: default avatarJack Wang <jack_wang@usish.com>
      Acked-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      9508a66f
    • Dan Williams's avatar
      [SCSI] libsas: restore scan order · 92625f9b
      Dan Williams authored
      
      
      ata devices are always scanned after ssp.  Prior to the ata error
      handling reworks libsas would tend to scan devices in ascending expander
      phy order.  Restore this ordering by deferring ssp discovery to a
      DISCE_PROBE event, and keep the probe order consistent with the
      discovery order, not the placement of sata devices.
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      92625f9b
    • Dan Williams's avatar
      [SCSI] libsas: let libata recover links that fail to transmit initial sig-fis · 354cf829
      Dan Williams authored
      
      
      libsas fails to discover all sata devices in the domain.  If a device fails
      negotiation and does not transmit a signature fis the link needs recovery.
      libata already understands how to manage slow to come up links, so treat these
      conditions as ata device attach events for the purposes of creating an
      ata_port.  This allows libata to manage retrying link bring up.
      
      Rediscovery is modified to be careful about checking changes in dev_type.  It
      looks like libsas leaks old devices if the sas address changes, but that's a
      fix for another patch.
      
      Acked-by: default avatarJack Wang <jack_wang@usish.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      354cf829
    • Maciej Trela's avatar
      [SCSI] libsas: kill spurious sas_put_device · fdfd9d1b
      Maciej Trela authored
      
      
      Holdover from a patch rework, prior to the addition of SAS_DEV_DESTROY
      we were holding a reference while the destruct was pending in case the
      domain was torn down before the desctruct event ran.  That case is
      covered by SAS_DEV_DESTROY, and the sas_put_device() just corrupts freed
      memory, or worse frees the memory while another agent holds a reference.
      
      Signed-off-by: default avatarMaciej Trela <maciej.trela@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      fdfd9d1b
    • Dan Williams's avatar
      [SCSI] libsas: close scsi_remove_target() vs libata-eh race · 8abda4d2
      Dan Williams authored
      
      
      ata_port lifetime in libata follows the host.  In libsas it follows the
      scsi_target.  Once scsi_remove_device() has caused all commands to be
      completed it allows scsi_remove_target() to immediately proceed to
      freeing the ata_port causing bug reports like:
      
      [  848.393333] BUG: spinlock bad magic on CPU#4, kworker/u:2/5107
      [  848.400262] general protection fault: 0000 [#1] SMP
      [  848.406244] CPU 4
      [  848.408310] Modules linked in: nls_utf8 ipv6 uinput i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ioatdma dca sg sd_mod sr_mod cdrom ahci libahci isci libsas libata scsi_transport_sas [last unloaded: scsi_wait_scan]
      [  848.432060]
      [  848.434137] Pid: 5107, comm: kworker/u:2 Not tainted 3.2.0-isci+ #8 Intel Corporation S2600CP/S2600CP
      [  848.445310] RIP: 0010:[<ffffffff8126a68c>]  [<ffffffff8126a68c>] spin_dump+0x5e/0x8c
      [  848.454787] RSP: 0018:ffff8807f868dca0  EFLAGS: 00010002
      [  848.461137] RAX: 0000000000000048 RBX: ffff8807fe86a630 RCX: ffffffff817d0be0
      [  848.469520] RDX: 0000000000000000 RSI: ffffffff814af1cf RDI: 0000000000000002
      [  848.477959] RBP: ffff8807f868dcb0 R08: 00000000ffffffff R09: 000000006b6b6b6b
      [  848.486327] R10: 000000000003fb8c R11: ffffffff81a19448 R12: 6b6b6b6b6b6b6b6b
      [  848.494699] R13: ffff8808027dc520 R14: 0000000000000000 R15: 000000000000001e
      [  848.503067] FS:  0000000000000000(0000) GS:ffff88083fd00000(0000) knlGS:0000000000000000
      [  848.512899] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  848.519710] CR2: 00007ff77d001000 CR3: 00000007f7a5d000 CR4: 00000000000406e0
      [  848.528072] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  848.536446] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  848.544831] Process kworker/u:2 (pid: 5107, threadinfo ffff8807f868c000, task ffff8807ff348000)
      [  848.555327] Stack:
      [  848.557959]  ffff8807fe86a630 ffff8807fe86a630 ffff8807f868dcd0 ffffffff8126a6e0
      [  848.567072]  ffffffff817c142f ffff8807fe86a630 ffff8807f868dcf0 ffffffff8126a703
      [  848.576190]  ffff8808027dc520 0000000000000286 ffff8807f868dd10 ffffffff814af1bb
      [  848.585281] Call Trace:
      [  848.588409]  [<ffffffff8126a6e0>] spin_bug+0x26/0x28
      [  848.594357]  [<ffffffff8126a703>] do_raw_spin_unlock+0x21/0x88
      [  848.601283]  [<ffffffff814af1bb>] _raw_spin_unlock_irqrestore+0x2c/0x65
      [  848.609089]  [<ffffffffa001c103>] ata_scsi_port_error_handler+0x548/0x557 [libata]
      [  848.618331]  [<ffffffff81061813>] ? async_schedule+0x17/0x17
      [  848.625060]  [<ffffffffa004f30f>] async_sas_ata_eh+0x45/0x69 [libsas]
      [  848.632655]  [<ffffffff810618aa>] async_run_entry_fn+0x97/0x125
      [  848.639670]  [<ffffffff81057439>] process_one_work+0x207/0x38d
      [  848.646577]  [<ffffffff8105738c>] ? process_one_work+0x15a/0x38d
      [  848.653681]  [<ffffffff810576f7>] worker_thread+0x138/0x21c
      [  848.660305]  [<ffffffff810575bf>] ? process_one_work+0x38d/0x38d
      [  848.667493]  [<ffffffff8105b098>] kthread+0x9d/0xa5
      [  848.673382]  [<ffffffff8106e1bd>] ? trace_hardirqs_on_caller+0x12f/0x166
      [  848.681304]  [<ffffffff814b7704>] kernel_thread_helper+0x4/0x10
      [  848.688324]  [<ffffffff814af534>] ? retint_restore_args+0x13/0x13
      [  848.695530]  [<ffffffff8105affb>] ? __init_kthread_worker+0x5b/0x5b
      [  848.702929]  [<ffffffff814b7700>] ? gs_change+0x13/0x13
      [  848.709155] Code: 00 00 48 8d 88 38 04 00 00 44 8b 80 84 02 00 00 31 c0 e8 cf 1b 24 00 41 83 c8 ff 44 8b 4b 08 48 c7 c1 e0 0b 7d 81 4d 85 e4 74 10 <45> 8b 84 24 84 02 00 00 49 8d 8c 24 38 04 00 00 8b 53 04 48 89
      [  848.732467] RIP  [<ffffffff8126a68c>] spin_dump+0x5e/0x8c
      [  848.738905]  RSP <ffff8807f868dca0>
      [  848.743743] ---[ end trace 143161646eee8caa ]---
      
      ...so arrange for the ata_port to have the same end of life as the domain
      device.
      
      Reported-by: default avatarMarcin Tomczak <marcin.tomczak@intel.com>
      Acked-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      8abda4d2
    • Dan Williams's avatar
      [SCSI] libsas: mark all domain devices gone if root port disappears · 7d05919a
      Dan Williams authored
      
      
      If the top level expander is hot removed, mark all child devices as gone
      before unregistration to short circuit futile recovery.
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      7d05919a
    • Dan Williams's avatar
      [SCSI] libsas: fix sas_find_local_phy(), take phy references · f41a0c44
      Dan Williams authored
      
      
      In the direct-attached case this routine returns the phy on which this
      device was first discovered.  Which is broken if we want to support
      wide-targets, as this phy reference can become stale even though the
      port is still active.
      
      In the expander-attached case this routine tries to lookup the phy by
      scanning the attached sas addresses of the parent expander, and BUG_ONs
      if it can't find it.  However since eh and the libsas workqueue run
      independently we can still be attempting device recovery via eh after
      libsas has recorded the device as detached.  This is even easier to hit
      now that eh is blocked while device domain rediscovery takes place, and
      that libata is fed more timed out commands increasing the chances that
      it will try to recover the ata device.
      
      Arrange for dev->phy to always point to a last known good phy, it may be
      stale after the port is torn down, but it will catch up for wide port
      reconfigurations, and never be NULL.
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      f41a0c44
  7. 19 Feb, 2012 7 commits
  8. 16 Oct, 2011 1 commit
  9. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  10. 02 Jan, 2009 1 commit
  11. 27 Mar, 2008 1 commit
  12. 11 Jan, 2008 1 commit
  13. 19 Oct, 2007 1 commit
  14. 26 Jul, 2007 1 commit
  15. 22 Jul, 2007 1 commit
  16. 18 Jul, 2007 4 commits
  17. 27 Jan, 2007 1 commit
    • Darrick J. Wong's avatar
      [SCSI] libsas: Clean up discovery failure handler code · 6f63caae
      Darrick J. Wong authored
      
      
      sas_rphy_delete does two things: it removes the sas_rphy from the transport
      layer and frees the sas_rphy.  This can be broken down into two functions,
      sas_rphy_remove and sas_rphy_free; sas_rphy_remove is of interest to
      sas_discover_root_expander because it calls functions that require
      sas_rphy_add as a prerequisite and can fail (namely sas_discover_expander).
      In that case, sas_discover_root_expander needs to be able to undo the effects
      of sas_rphy_add yet leave the job of freeing the sas_rphy to the caller of
      sas_discover_root_expander.
      
      This patch also removes some unnecessary code from sas_discover_end_dev
      to eliminate an unnecessary cycle of sas_notify_lldd_gone/found for SAS
      devices, thus eliminating a sas_rphy_remove call (and fixing a race condition
      where a SCSI target scan can come in between the gone and found call).
      It also moves the sas_rphy_free calls into sas_discover_domain and
      sas_ex_discover_end_dev to complement the sas_rphy_allocation via
      sas_get_port_device.
      
      This patch does not change the semantics of sas_rphy_delete.
      
      Signed-off-by: default avatarDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      6f63caae
  18. 13 Jan, 2007 2 commits