Re: [REGRESSION?] scsi: sas: wildcard user scan may iterate over huge max_id

[Li Lingfeng]

Hi,

I have one more question after looking at the SAS scan paths a bit more.

What caught my attention is that sas_rphy_add() and the old
sas_user_scan() seemed to follow the same scanning model:

  - scan via channel 0
  - use rphy->scsi_target_id as the target id

For example, sas_rphy_add() does:

  scsi_scan_target(&rphy->dev, 0, rphy->scsi_target_id, lun,
                   SCSI_SCAN_INITIAL);

So before this change, these two paths looked consistent to me.

Now sas_user_scan() has moved to a different model for the extra channels,
while sas_rphy_add() still uses the original one. This makes me wonder
whether these two paths are expected to stay consistent, and if so, which
direction is actually intended.

Should sas_rphy_add() also be changed to follow the new sas_user_scan()
behavior? Or is sas_rphy_add() a hint that sas_user_scan() should remain
aligned with the original rphy-based scan model instead?

I am not very familiar with the intended SCSI/SAS scanning design here,
so this may be a naive question. I just wanted to check whether the
current inconsistency between sas_rphy_add() and sas_user_scan() is
expected, or whether one of them should be adjusted so that both follow
the same model again.

Any clarification would be greatly appreciated.

Thanks,
Lingfeng.

在 2026/3/28 10:28, Li Lingfeng 写道:
> Hi,
>
> I think commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle 
> wildcard
> and multi-channel scans") may introduce a regression for wildcard 
> scans on
> some SAS hosts.
>
> Userspace trigger:
>
>   echo "- - -" > /sys/class/scsi_host/host0/scan
>
> results in:
>
>   channel = SCAN_WILD_CARD
>   id      = SCAN_WILD_CARD
>   lun     = SCAN_WILD_CARD
>
> Before this commit, sas_user_scan() iterated sas_host->rphy_list and 
> called
> scsi_scan_target() for matching rphys. In effect, scanning was limited to
> channel 0 and to target ids present in sas_host->rphy_list.
>
> After this commit, sas_user_scan() does:
>
>   - scan channel 0 via scan_channel_zero()
>   - scan channels 1..shost->max_channel via scsi_scan_host_selected()
>
> When id == SCAN_WILD_CARD, the latter path goes through
> scsi_scan_channel(), which iterates ids from 0 to shost->max_id.
>
> This looks problematic for drivers that use a very large max_id. For
> example, smartpqi sets:
>
>   shost->max_id = ~0;
>
> In that case, a wildcard scan may end up iterating from id 0 to ~0 in
> scsi_scan_channel(). In my testing/analysis, this makes the scan take a
> very long time, and the id-space walk itself does not seem meaningful for
> this SAS transport scan path.
>
> So while the commit fixes incomplete wildcard channel handling, it also
> appears to expand the id scan range from:
>
>   sas_host->rphy_list target ids
>
> to:
>
>   0..shost->max_id
>
> for the additional channels.
>
> It seems to me that wildcard SAS scans should probably remain bounded by
> transport-discovered SAS targets, instead of falling back to a host-wide
> id enumeration for the extra channels. One possible direction may be to
> avoid calling scsi_scan_host_selected() with id == SCAN_WILD_CARD from
> sas_user_scan(), or otherwise constrain the id range in a transport-aware
> way.
>
> Am I understanding this correctly? If so, what would be the preferred way
> to address this? I would appreciate feedback on whether this is 
> considered
> a real regression, and on the best fix direction.
>
> Thanks,
> Lingfeng.