- 31 Jan, 2017 13 commits
-
-
Christoph Hellwig authored
Currently the legacy ide driver defines several request types of it's own, which is in the way of removing that field entirely. Instead add a type field to struct ide_request and use that to distinguish the different types of IDE-internal requests. It's a bit of a mess, but so is the surrounding code.. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Jens Axboe <axboe@fb.com>
-
Christoph Hellwig authored
This can be used to check for fs vs non-fs requests and basically removes all knowledge of BLOCK_PC specific from the block layer, as well as preparing for removing the cmd_type field in struct request. Signed-off-by:
-
Christoph Hellwig authored
This is where we do the rest of the request handling, which will become much simpler soon, too. Signed-off-by:
-
Christoph Hellwig authored
Disconnects don't use block layer requests these days, so all handling of private requests is dead code. Signed-off-by:
-
Christoph Hellwig authored
This driver will never see non-fs requests, and doesn't do anything else in the prep_fn. Signed-off-by:
-
Christoph Hellwig authored
This driver will never see non-fs requests, and doesn't do anything else in the prep_fn. Signed-off-by:
-
Christoph Hellwig authored
The block layer won't send requests the driver isn't asking for, so remove this check. Signed-off-by:
-
Christoph Hellwig authored
->done can only be called for fs requests, so no need to check again here. Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
The SCSI passthrough idea was a a bad idea to start with (guess who came up with it?), and has been removed from the virtio 1.O spec, and is not enabled by defauly by any host I know of. Add a separate config option for it so that we don't need to enable it for most setups. That way any bugs related to it (like the one recently fixed for vmapped stacks) do not affect other users, and the size of the virtblk_req structure also shrinks significantly. Signed-off-by:
-
Christoph Hellwig authored
We can simply use blk_mq_rq_from_pdu to get back at the request at I/O completion time. Signed-off-by:
-
Christoph Hellwig authored
We only need this code to support scsi, ide, cciss and virtio. And at least for virtio it's a deprecated feature to start with. This should shrink the kernel size for embedded device that only use, say eMMC a bit. Signed-off-by:
-
Christoph Hellwig authored
This way there is no need to drag in a dependency on the BLOCK_PC code, which is going to become optional. Signed-off-by:
-
- 30 Jan, 2017 2 commits
-
-
Christoph Hellwig authored
The NVMe SCSI emulation doesn't use BLOCK_PC requests, so BLK_MAX_CDB doesn't have a meaning for it. Instead opencode the value of 16 and refactor the code a bit so that related checks are next to each other and we only need to use the value in one place. Signed-off-by:
-
Jens Axboe authored
Since we moved the cdb parts and define out of the block proper, we need to include scsi/scsi_request.h for the nvme scsi layer. Fixes: 82ed4db4 ("block: split scsi_request out of struct request") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 27 Jan, 2017 25 commits
-
-
Christoph Hellwig authored
These days we have the proper flags set since request allocation time. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Christoph Hellwig authored
And require all drivers that want to support BLOCK_PC to allocate it as the first thing of their private data. To support this the legacy IDE and BSG code is switched to set cmd_size on their queues to let the block layer allocate the additional space. Signed-off-by:
-
Christoph Hellwig authored
Simply the boilerplate code needed for bsg nodes a bit. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Christoph Hellwig authored
Rely on the new block layer functionality to allocate additional driver specific data behind struct request instead of implementing it in SCSI itѕelf. Signed-off-by:
-
Christoph Hellwig authored
Instead do an internal export of __scsi_init_queue for the transport classes that export BSG nodes. Signed-off-by:
-
Christoph Hellwig authored
There is no need for GFP_DMA allocations of the scsi_cmnd structures themselves, all that might be DMAed to or from is the actual payload, or the sense buffers. Signed-off-by:
-
Christoph Hellwig authored
Currently blk-mq always allocates the sense buffer using normal GFP_KERNEL allocation. Refactor the cmd pool code to split the cmd and sense allocation and share the code to allocate the sense buffers as well as the sense buffer slab caches between the legacy and blk-mq path. Note that this switches to lazy allocation of the sense slab caches - the slab caches (not the actual allocations) won't be destroy until the scsi module is unloaded instead of keeping track of hosts using them. Signed-off-by:
-
Christoph Hellwig authored
When using the slab allocator we already decide at cache creation time if an allocation comes from a GFP_DMA pool using the SLAB_CACHE_DMA flag, and there is no point passing the kmalloc-family only GFP_DMA flag to kmem_cache_alloc. Drop all the infrastructure for doing so. Signed-off-by:
-
Hannes Reinecke authored
Switch to scsi_execute_req_flags() instead of using the block interface directly. This will set REQ_QUIET and REQ_PREEMPT, but this is okay as we're evaluating the errors anyway and should be able to send the command even if the device is quiesced. Signed-off-by:
-
Hannes Reinecke authored
Switch to scsi_execute_req_flags() and scsi_get_vpd_page() instead of open-coding it. Using scsi_execute_req_flags() will set REQ_QUIET and REQ_PREEMPT, but this is okay as we're evaluating the errors anyway and should be able to send the command even if the device is quiesced. Signed-off-by:
-
Hannes Reinecke authored
Switch to scsi_execute_req_flags() and scsi_get_vpd_page() instead of open-coding it. Using scsi_execute_req_flags() will set REQ_QUIET and REQ_PREEMPT, but this is okay as we're evaluating the errors anyway and should be able to send the command even if the device is quiesced. Signed-off-by:
-
Christoph Hellwig authored
DM already calls blk_mq_alloc_request on the request_queue of the underlying device if it is a blk-mq device. But now that we allow drivers to allocate additional data and initialize it ahead of time we need to do the same for all drivers. Doing so and using the new cmd_size infrastructure in the block layer greatly simplifies the dm-rq and mpath code, and should also make arbitrary combinations of SQ and MQ devices with SQ or MQ device mapper tables easily possible as a further step. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
DM tries to copy a few fields around for BLOCK_PC requests, but given that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually be sent to dm. Signed-off-by:
-
Christoph Hellwig authored
A couple tweaks to the tracing code: - trace the request size for all requests - trace request sector and nr_sectors only for fs requests, enforced by helpers - drop SCSI CDB tracing - we have SCSI tracing for this and are going to me the CDB out of the generic struct request soon. With this the tracing code stops to know about BLOCK_PC requests entirely, it's just FS vs passthrough requests now, where the latter includes any driver-private requests. Signed-off-by:
-
Christoph Hellwig authored
This mirrors the blk-mq capabilities to allocate extra drivers-specific data behind struct request by setting a cmd_size field, as well as having a constructor / destructor for it. Signed-off-by:
-
Christoph Hellwig authored
Return an errno value instead of the passed in queue so that the callers don't have to keep track of two queues, and move the assignment of the request_fn and lock to the caller as passing them as argument doesn't simplify anything. While we're at it also remove two pointless NULL assignments, given that the request structure is zeroed on allocation. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
-
Christoph Hellwig authored
We can't initalize the elevator fields for flushes as flush share space in struct request with the elevator data. But currently we can't communicate that a request is a flush through blk_get_request as we can only pass READ or WRITE, and the low-level code looks at the possible NULL bio to check for a flush. Fix this by allowing to pass any block op and flags, and by checking for the flush flags in __get_request. Signed-off-by:
-
Christoph Hellwig authored
No need for the local variables, the bio is still live and we can just assign the bits we want directly. Make me wonder why we can't assign all the bio flags to start with. Signed-off-by:
-
Jens Axboe authored
Signed-off-by: -
Omar Sandoval authored
This fixes a couple of problems: 1. In the !CONFIG_DEBUG_FS case, the stub definitions were bogus. 2. In the !CONFIG_BLOCK case, blk-mq-debugfs.c shouldn't be compiled at all. Fix the stub definitions and add a CONFIG_BLK_DEBUG_FS Kconfig option. Fixes: 07e4fead ("blk-mq: create debugfs directory tree") Signed-off-by:
Omar Sandoval <osandov@fb.com> Augment Kconfig description. Signed-off-by:
-
Jens Axboe authored
Use op_is_flush() where applicable. Signed-off-by: -
Jens Axboe authored
Instead of letting the caller check this and handle the details of inserting a flush request, put the logic in the scheduler insertion function. This fixes direct flush insertion outside of the usual make_request_fn calls, like from dm via blk_insert_cloned_request(). Signed-off-by: -
Christoph Hellwig authored
This centralizes the checks for bios that needs to be go into the flush state machine. Signed-off-by:
-
Jens Axboe authored
When we invoke dispatch_requests(), the scheduler empties everything into the passed in list. This isn't always a good thing, since it means that we remove items that we could have potentially merged with. Change the function to dispatch single requests at the time. If we do that, we can backoff exactly at the point where the device can't consume more IO, and leave the rest with the scheduler for better merging and future dispatch decision making. Signed-off-by:
-
Jens Axboe authored
If we have both multiple hardware queues and shared tag map between devices, we need to ensure that we propagate the hardware queue restart bit higher up. This is because we can get into a situation where we don't have any IO pending on a hardware queue, yet we fail getting a tag to start new IO. If that happens, it's not enough to mark the hardware queue as needing a restart, we need to bubble that up to the higher level queue as well. Signed-off-by:
-
