linux-kernel - Implementing aio cancel for SCSI/SATA devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CACK8Z6EfZw3NrHZk_HD1Qh17ZAntOaxXzRx=kpp2noNfJ6KRWg@mail.gmail.com>
Date:	Wed, 15 Jul 2015 17:24:55 -0700
From:	Rajat Jain <rajatja@...gle.com>
To:	"James E.J. Bottomley" <JBottomley@...n.com>,
	Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Theodore Tso <tytso@...gle.com>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-scsi <linux-scsi@...r.kernel.org>,
	linux-aio@...ck.org, Kent Overstreet <kent.overstreet@...il.com>
Subject: Implementing aio cancel for SCSI/SATA devices

Hello,

Currently I don't see any users of aio cancellation facility (except a
USB gadget driver).

I have a SATA controller and disk that both support the NCQ command
aborts, and I am thinking of ways to implement aio cancellation on
these devices in the kernel. The way I see it, at the time user
requests for a command to be cancelled, it could be be in one of the 2
places:

1. Sitting in block layer elevator queues, and not yet submitted it to
the SCSI subsystem (scsi_dispatch_cmd() not yet called). [I see some
solutions available to this https://lkml.org/lkml/2013/5/13/615 ]

2. Submitted to the SCSI subsystem / LLD, but pending in the LLD SW or
the HW  (scsi_done() not yet called). This part is what I am keen on
adding.

My line of thought (10000 ft view) currently is, that I should:

A) Do the necessary plumbing (through the block & scsi layers) such
that the kiocb_cancel() should eventually result in a call to the
eh_abort_handler() for the LLD for that particular command. This
should (atleast in my theory) let the LLD know that it needs to cancel
the command, and can do whatever it needs to do in order to cancel it.

B) Add a helper function in libata that allocates & initializes a new
"Queue Management - Abort (0x63)" ATA command, that the LLD's
eh_abort_handler() can choose to use in case it sees that the command
is already sent to the disk drive. It can then send this new
ata_queued_cmd to abort the pending command to the drive. This is of
course optional and to be used at LLD(s) discretion.

Comments? Thoughts?

I'd appreciate if you could please let me know if I'm on the right
track or totally off?

Thanks,

Rajat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/