NCR5380_abort(9)

📦 version 7.3.1, in nixpkgs unstable

NCR5380_abort(9)

okay so bestie, welcome to the Kernel API Manual 💖 this page is all about NCR5380_abort(9), and it's giving “SCSI host abort-handler” main character energy. Let's get into it, fr fr.

💖 NAME 💖

NCR5380_abort — scsi host eh_abort_handler() method

✨ SYNOPSIS ✨

int NCR5380_abort (struct scsi_cmnd *cmd );

🎀 ARGUMENTS 🎀

  • cmd — the command to be aborted

🦋 DESCRIPTION 🦋

The mission, bestie: try to abort the command cmd by removing it from queues and/or sending the target an abort message. This may not succeed in causing a target to abort the command — no cap, it might just not land. Nonetheless, the low-level driver must forget about the command, because the mid-layer reclaims it and it may be re-issued. Periodt.

The normal path taken by a command is as follows. For EH we trace this same path to locate and abort the command. Iconic little route, honestly:

unissued -> selecting -> [unissued -> selecting ->]... connected ->
[disconnected -> connected ->]...  [autosense -> connected ->] done

If cmd was not found at all then presumably it has already been completed, in which case return SUCCESS to try to avoid further EH measures. Slay, goodbye, no extra drama.

If the command has not completed yet, we must not fail to find it. We have no option but to forget the aborted command (even if it still lacks sense data). The mid-layer may re-issue a command that is in error recovery (see scsi_send_eh_cmnd), but the logic and data structures in this driver are such that a command can appear on one queue only. That's the rule, iykyk.

The lock protects driver data structures, but EH handlers also use it to serialize their own execution and prevent their own re-entry. Lock lore 💅.

🌸 SEE ALSO 🌸

Kernel file ./drivers/scsi/NCR5380.c — and the whole SEE ALSO squad, no cap:

kisses from ./drivers/scsi, October 2026 — NCR5380_abort(9) out 💖✨

📦 where this page comes from