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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ