linux-kernel - IDE, packet commands and REQ_TYPE

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>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 02 Apr 2009 05:31:44 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linux IDE mailing list <linux-ide@...r.kernel.org>
CC:	Jens Axboe <jens.axboe@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: IDE, packet commands and REQ_TYPE_SENSE?

Looking at REQ_TYPE_*, I see that REQ_TYPE_SENSE is only used once in an 
assignment, and appears to never be tested anywhere.

Furthermore, the use of REQ_TYPE_SENSE immediately follows a previous 
assignment rq->cmd_type assignment:

cdrom_queue_request_sense():
[...]
         /* stuff the sense request in front of our current request */
         blk_rq_init(NULL, rq);
         rq->cmd_type = REQ_TYPE_ATA_PC;
         rq->rq_disk = info->disk;

         rq->data = sense;
         rq->cmd[0] = GPCMD_REQUEST_SENSE;
         rq->cmd[4] = 18;
         rq->data_len = 18;

         rq->cmd_type = REQ_TYPE_SENSE;
         rq->cmd_flags |= REQ_PREEMPT;
[...]

First, the code assigns REQ_TYPE_ATA_PC, then without any intervening 
tests or branches, it assigns REQ_TYPE_SENSE.

So, some questions...

Is REQ_TYPE_ATA_PC sufficient (i.e. the first assignment)?

Can we get rid of REQ_TYPE_SENSE?

What are the differences between REQ_TYPE_ATA_PC and REQ_TYPE_BLOCK_PC? 
  Would it be possible to eliminate REQ_TYPE_ATA_PC after some work, as 
well?

	Jeff

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