On 08/11/17 11:30, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
>
>> Recovery is simpler to understand if it is only used for errors. Create a
>> separate function for card polling.
>>
>> Signed-off-by: Adrian Hunter
>
> This looks good but I can't see why it's no
On 08/11/17 11:38, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
>
>> There are only a few things the recovery needs to do. Primarily, it just
>> needs to:
>> Determine the number of bytes transferred
>> Get the card back to transfer state
>>
On Thu, Nov 09, 2017 at 04:20:36PM +0900, Byungchul Park wrote:
> Changes from v1
> - Run several tools checking english spell and grammar over the text.
> - Simplify the document more.
Checker tools also reported other words e.g. crosslock, crossrelease,
lockdep, mutex, lockless, and so on, but I
On 08/11/17 11:28, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
>
>> For blk-mq, add support for completing requests directly in the ->done
>> callback. That means that error handling and urgent background operations
>> must be handled by recovery_work in that case.
Changes from v1
- Run several tools checking english spell and grammar over the text.
- Simplify the document more.
-8<-
>From 412bc9eb0d22791f70f7364bda189feb41899ff9 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Thu, 9 Nov 2017 16:12:23 +0900
Subject: [PATCH v2] locking/lockdep: R
On 08/11/17 11:24, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
>
>> Add CQHCI initialization and implement CQHCI operations for Intel GLK.
>>
>> Signed-off-by: Adrian Hunter
>
> This patch seems OK in context, but it merely illustrates the
> weirdness of .[runtim
Initialize the seq_zones_bitmap, seq_zones_wlock and nr_zones fields of
the disk request queue on disk revalidate. As the seq_zones_bitmap
and seq_zones_wlock allocations are identical, introduce the helper
sd_zbc_alloc_zone_bitmap(). Using this helper, reallocate the bitmaps
whenever the disk capa
Avoid directly referencing the next_rq and fifo_list arrays using the
helper functions deadline_next_request() and deadline_fifo_request() to
facilitate changes in the dispatch request selection in
__dd_dispatch_request() for zoned block devices.
Signed-off-by: Damien Le Moal
Reviewed-by: Bart Va
From: Christoph Hellwig
Components relying only on the request_queue structure for accessing
block devices (e.g. I/O schedulers) have a limited knowledged of the
device characteristics. In particular, the device capacity cannot be
easily discovered, which for a zoned block device also result in t
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
The block layer now handles zone write locking.
Signed-off-by: Damien Le Moal
Reviewed-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
drivers/scsi/sd.c| 41 +++-
drivers/scsi/sd.h| 11 ---
drivers/scsi/sd_zbc.c| 83
Avoid directly referencing the next_rq and fifo_list arrays using the
helper functions deadline_next_request() and deadline_fifo_request() to
facilitate changes in the dispatch request selection in
deadline_dispatch_requests() for zoned block devices.
While at it, also remove the unnecessary forwa
This series, formerly titled "scsi-mq support for ZBC disks", implements
support for ZBC disks for system using the scsi-mq I/O path.
The current scsi level support of ZBC disks guarantees write request ordering
using a per-zone write lock which prevents issuing simultaneously multiple
write comma
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
Bart,
is this something known to you, or it is just my fault applying this series to
v4.13? Except having this warning, suspend/resume works for me:
===
[ 27.383846] sd 0:0:0:0: [sda] Starting disk
[ 27.383976] sd 1:0:0:0: [sdb] Starting disk
[ 27.451218] sdb: Attempt to allocate non-preem
On Wed, Nov 08, 2017 at 10:57:23AM -0700, Jens Axboe wrote:
> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> > On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> >> At this point, I have no idea what Bart's setup looks like. Bart, it
> >> would be REALLY helpful if you could tell us how you a
On Wed, Nov 08, 2017 at 03:48:51PM -0700, Jens Axboe wrote:
> This patch attempts to make the case of hctx re-running on driver tag
> failure more robust. Without this patch, it's pretty easy to trigger a
> stall condition with shared tags. An example is using null_blk like
> this:
>
> modprobe nu
On Wed, Nov 08, 2017 at 04:41:35PM +, Bart Van Assche wrote:
> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> > At this point, I have no idea what Bart's setup looks like. Bart, it
> > would be REALLY helpful if you could tell us how you are reproducing
> > your hang. I don't know why t
On Wed, Nov 08, 2017 at 10:34:38AM +0100, Ingo Molnar wrote:
>
> * Byungchul Park wrote:
>
> > I'm afraid the revision is not perfect yet. Of course, the document can
> > have got much better english by others than me.
> >
> > But,
> >
> > I think I should enhance it as much as I can, before t
On Wed, Nov 08, 2017 at 05:29:44PM +0100, David Disseldorp wrote:
> null_alloc_dev() allocates memory for dev->badblocks, but cleanup
> currently only occurs in the configfs release codepath, missing a number
> of other places.
>
> This bug was found running the blktests block/010 test, alongside
Martin,
On 11/9/17 08:41, Martin K. Petersen wrote:
>
> Damien,
>
>> wait for the disk capacity and number of zones to stabilize on the
>> second revalidation pass to allocate and initialize the bitmaps.
>
> Stabilize how?
If RC_BASIS is 0, the capacity changes after the first report zones...
Damien,
> Make sure that the device request queue zone information (number of
> zones and zone bitmaps) are reinitialized if the number of zones
> changes (e.g. on a drive capacity change on revalidate).
This should probably be part of patch 6.
Reviewed-by: Martin K. Petersen
--
Martin K. Pe
Damien,
> The block layer now handles zone write locking.
Looks OK.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
On Wed, 2017-11-08 at 15:48 -0700, Jens Axboe wrote:
> + * We got a tag, remove outselves from the wait queue to ensure
^
ourselves?
Anyway, since this patch fixes a SCSI queue stall I ran into recently
(see also
https:/
Damien,
> wait for the disk capacity and number of zones to stabilize on the
> second revalidation pass to allocate and initialize the bitmaps.
Stabilize how?
--
Martin K. Petersen Oracle Linux Engineering
Damien,
> Introduce zone write locking to avoid write request reordering with
> zoned block devices. This is achieved using a finer selection of the
> next request to dispatch:
> 1) Any non-write request is always allowed to proceed.
> 2) Any write to a conventional zone is always allowed to proc
Damien,
> Avoid directly referencing the next_rq and fifo_list arrays using the
> helper functions deadline_next_request() and deadline_fifo_request() to
> facilitate changes in the dispatch request selection in
> deadline_dispatch_requests() for zoned block devices.
>
> While at it, also remove
Damien,
> Introduce zone write locking to avoid write request reordering with
> zoned block devices. This is achieved using a finer selection of the
> next request to dispatch:
> 1) Any non-write request is always allowed to proceed.
> 2) Any write to a conventional zone is always allowed to proc
Damien,
> Avoid directly referencing the next_rq and fifo_list arrays using the
> helper functions deadline_next_request() and deadline_fifo_request()
> to facilitate changes in the dispatch request selection in
> __dd_dispatch_request() for zoned block devices.
Reviewed-by: Martin K. Petersen
Damien,
> + * Zoned block device information for request dispatch control.
> + * nr_zones is the total number of zones of the device. This is always
> + * 0 for regular block devices. seq_zones_bitmap is a bitmap of nr_zones
> + * bits which indicates if a zone is conventional
This patch attempts to make the case of hctx re-running on driver tag
failure more robust. Without this patch, it's pretty easy to trigger a
stall condition with shared tags. An example is using null_blk like
this:
modprobe null_blk queue_mode=2 nr_devices=4 shared_tags=1 submit_queues=1
hw_queue
On 11/08/2017 11:23 AM, Bart Van Assche wrote:
> Avoid that removal of a request queue sporadically triggers the
> following warning:
>
> list_del corruption. next->prev should be 8807d649b970, but was
> 6b6b6b6b6b6b6b6b
> WARNING: CPU: 3 PID: 342 at lib/list_debug.c:56
> __list_del_entry_va
On 11/08/2017 11:22 AM, Laurence Oberman wrote:
> On Wed, 2017-11-08 at 10:57 -0700, Jens Axboe wrote:
>> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
>>> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
At this point, I have no idea what Bart's setup looks like. Bart,
it
would
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
A bit of duplication vs the existing ZBC code here, but it seems the
old code is going away later in the series, so:
Reviewed-by: Christoph Hellwig
Avoid that removal of a request queue sporadically triggers the
following warning:
list_del corruption. next->prev should be 8807d649b970, but was
6b6b6b6b6b6b6b6b
WARNING: CPU: 3 PID: 342 at lib/list_debug.c:56 __list_del_entry_valid+0x92/0xa0
Call Trace:
process_one_work+0x11b/0x660
worke
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On 11/08/2017 08:59 AM, Ming Lei wrote:
> On Wed, Nov 08, 2017 at 02:20:41PM +0800, Ming Lei wrote:
>> On Tue, Nov 07, 2017 at 08:17:59PM -0700, Jens Axboe wrote:
>>> On 11/07/2017 08:12 PM, Ming Lei wrote:
On Tue, Nov 07, 2017 at 08:01:48PM -0700, Jens Axboe wrote:
> On 11/07/2017 06:03 P
Except for a bit of mis-spelling in the Subject this looks fine
to me:
Reviewed-by: Christoph Hellwig
FYI, I would just simplify the subject to
mq-deadline: Introduce dispatch helpers
and similar in the other patches.
On Wed, 2017-11-08 at 10:57 -0700, Jens Axboe wrote:
> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> > On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> > > At this point, I have no idea what Bart's setup looks like. Bart,
> > > it
> > > would be REALLY helpful if you could tell us how you
Thanks,
applied both patches to nvme-4.15.
On 11/07/2017 06:11 PM, Ming Lei wrote:
> We have to put the driver tag if dispatch budget can't be got, otherwise
> it might cause IO deadlock, especially in case that size of tags is very
> small.
Applied, thanks.
--
Jens Axboe
On 11/05/2017 01:36 AM, Christoph Hellwig wrote:
> Use the obvious calling convention.
Applied, thanks.
--
Jens Axboe
This helper doesn't buy us much over calling kmap_atomic directly.
In fact in the only caller it does a bit of useless work as the
caller already has the bvec at hand, and said caller would even
buggy for a multi-segment bio due to the use of this helper.
So just remove it.
Signed-off-by: Christo
On 11/08/2017 11:13 AM, Christoph Hellwig wrote:
> This helper doesn't buy us much over calling kmap_atomic directly.
> In fact in the only caller it does a bit of useless work as the
> caller already has the bvec at hand, and said caller would even
> buggy for a multi-segment bio due to the use of
On Wed, Nov 08, 2017 at 11:08:13AM -0700, Jens Axboe wrote:
> On 11/08/2017 11:03 AM, Christoph Hellwig wrote:
> > On Wed, Nov 08, 2017 at 08:36:25AM -0700, Jens Axboe wrote:
> >> On 11/08/2017 08:34 AM, Christoph Hellwig wrote:
> >>> On Wed, Nov 08, 2017 at 08:20:58AM -0700, Jens Axboe wrote:
> >>
On 11/08/2017 11:03 AM, Christoph Hellwig wrote:
> On Wed, Nov 08, 2017 at 08:36:25AM -0700, Jens Axboe wrote:
>> On 11/08/2017 08:34 AM, Christoph Hellwig wrote:
>>> On Wed, Nov 08, 2017 at 08:20:58AM -0700, Jens Axboe wrote:
On top of that, there are no users of it at all...
>>>
>>> But Miku
On Wed, Nov 08, 2017 at 08:36:25AM -0700, Jens Axboe wrote:
> On 11/08/2017 08:34 AM, Christoph Hellwig wrote:
> > On Wed, Nov 08, 2017 at 08:20:58AM -0700, Jens Axboe wrote:
> >> On top of that, there are no users of it at all...
> >
> > But Mikulas wants to add one :)
>
> I know...
>
> > Note
On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
>> At this point, I have no idea what Bart's setup looks like. Bart, it
>> would be REALLY helpful if you could tell us how you are reproducing
>> your hang. I don't know why this has to be dragged
On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> At this point, I have no idea what Bart's setup looks like. Bart, it
> would be REALLY helpful if you could tell us how you are reproducing
> your hang. I don't know why this has to be dragged out.
Hello Jens,
It is a disappointment to me tha
null_alloc_dev() allocates memory for dev->badblocks, but cleanup
currently only occurs in the configfs release codepath, missing a number
of other places.
This bug was found running the blktests block/010 test, alongside
kmemleak:
rapido1:/blktests# ./check block/010
...
rapido1:/blktests# echo s
On Wed, Nov 08, 2017 at 08:01:08AM -0800, James Bottomley wrote:
> On Wed, 2017-11-08 at 21:21 +0800, Ming Lei wrote:
> > cmd->cmnd can be allocated/freed dynamically in case of
> > T10_PI_TYPE2_PROTECTION,
> > so we should check it in scsi_show_rq() because this request may have
> > been freed in
On Wed, 2017-11-08 at 21:21 +0800, Ming Lei wrote:
> cmd->cmnd can be allocated/freed dynamically in case of
> T10_PI_TYPE2_PROTECTION,
> so we should check it in scsi_show_rq() because this request may have
> been freed in scsi_show_rq().
>
> This patch fixs the following kernel crash when dumpin
On Wed, Nov 08, 2017 at 02:20:41PM +0800, Ming Lei wrote:
> On Tue, Nov 07, 2017 at 08:17:59PM -0700, Jens Axboe wrote:
> > On 11/07/2017 08:12 PM, Ming Lei wrote:
> > > On Tue, Nov 07, 2017 at 08:01:48PM -0700, Jens Axboe wrote:
> > >> On 11/07/2017 06:03 PM, Ming Lei wrote:
> > >>> On Tue, Nov 07
On 11/08/2017 08:34 AM, Christoph Hellwig wrote:
> On Wed, Nov 08, 2017 at 08:20:58AM -0700, Jens Axboe wrote:
>> On top of that, there are no users of it at all...
>
> But Mikulas wants to add one :)
I know...
> Note that __bio_kmap_atomic has the same issues, only has a single
> users either a
On Wed, Nov 08, 2017 at 08:20:58AM -0700, Jens Axboe wrote:
> On top of that, there are no users of it at all...
But Mikulas wants to add one :)
Note that __bio_kmap_atomic has the same issues, only has a single
users either and would be cleaner if opencoded there as it already
has the current bv
On 11/08/2017 08:05 AM, Christoph Hellwig wrote:
> On Wed, Nov 08, 2017 at 07:38:44AM -0500, Mikulas Patocka wrote:
>>> To be honest I think we should just remove bio_kmap_irq. It is currently
>>> unused and assumes there is only a single bvec to map.
>>
>> It could be removed from include/linux/b
On Wed, Nov 08, 2017 at 07:38:44AM -0500, Mikulas Patocka wrote:
> > To be honest I think we should just remove bio_kmap_irq. It is currently
> > unused and assumes there is only a single bvec to map.
>
> It could be removed from include/linux/bio.h and moved to my driver. But
> if we leave it i
On 08/11/17 11:22, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
>
>> From: Venkat Gopalakrishnan
>>
>> This patch adds CMDQ support for command-queue compatible
>> hosts.
>>
>> Command queue is added in eMMC-5.1 specification. This
>> enables the controller to proc
cmd->cmnd can be allocated/freed dynamically in case of T10_PI_TYPE2_PROTECTION,
so we should check it in scsi_show_rq() because this request may have
been freed in scsi_show_rq().
This patch fixs the following kernel crash when dumping request via block's
debugfs interface:
[ 252.962045] BUG: u
On 08/11/17 11:00, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
>
>> @@ -2188,11 +2327,18 @@ enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue
>> *mq, struct request *req)
>> return MMC_REQ_FAILED_TO_START;
>> }
>>
On Wed, 8 Nov 2017, Christoph Hellwig wrote:
> On Tue, Nov 07, 2017 at 04:45:17PM -0500, Mikulas Patocka wrote:
> > Hi
> >
> > I need the function bio_kmap_irq in the driver that I am developing, but
> > it doesn't return the size of the mapped data. I've made this patch to fix
> > it.
>
> T
On 11/08/2017 09:54 AM, Christoph Hellwig wrote:
> Can I get a review for this one? The only changes vs the previously
> reviewed versions is that we don't use the multipath code at all for
> subsystems that aren't multiported, and that there is an explicit
> opt-out at compile and module load tim
On Mon, 2017-11-06 at 08:10 +0100, Hannes Reinecke wrote:
> On 11/03/2017 11:23 PM, Bart Van Assche wrote:
> > Use the sgl_alloc_order() and sgl_free() functions instead of open
> > coding these functions.
> >
> > Signed-off-by: Bart Van Assche
> > Cc: Nicholas A. Bellinger
> > Cc: Christoph Hel
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
From: Javier González
Fix print formatting, but keep the original output to prevent user
breakage as suggested by Joe Perches.
Change since v1:
- Maintain the original output format printing spaces instead of dashes
Signed-off-by: Javier González
Reviewed-by: Keith Busch
---
drivers/nvme/h
From: Javier González
Copy subnqns using NVMF_NQN_SIZE as it is < 256
Changes since V1:
- Fix commit message to indicate that it is a copy and not a comparison.
Signed-off-by: Javier González
Reviewed-by: Christoph Hellwig
---
drivers/nvme/host/core.c | 2 +-
1 file changed, 1 insertion(+)
On Tue, Nov 07, 2017 at 04:45:17PM -0500, Mikulas Patocka wrote:
> Hi
>
> I need the function bio_kmap_irq in the driver that I am developing, but
> it doesn't return the size of the mapped data. I've made this patch to fix
> it.
To be honest I think we should just remove bio_kmap_irq. It is c
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> There are only a few things the recovery needs to do. Primarily, it just
> needs to:
> Determine the number of bytes transferred
> Get the card back to transfer state
> Determine whether to retry
>
> There are also a c
* Byungchul Park wrote:
> I'm afraid the revision is not perfect yet. Of course, the document can
> have got much better english by others than me.
>
> But,
>
> I think I should enhance it as much as I can, before they can help it
> starting with a better one.
>
> In addition, I removed verbo
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> Recovery is simpler to understand if it is only used for errors. Create a
> separate function for card polling.
>
> Signed-off-by: Adrian Hunter
This looks good but I can't see why it's not folded into
patch 3 already. This error handling i
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> For blk-mq, add support for completing requests directly in the ->done
> callback. That means that error handling and urgent background operations
> must be handled by recovery_work in that case.
>
> Signed-off-by: Adrian Hunter
I tried ena
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> Add CQHCI initialization and implement CQHCI operations for Intel GLK.
>
> Signed-off-by: Adrian Hunter
This patch seems OK in context, but it merely illustrates the
weirdness of .[runtime]_suspend/resume calling into CQE-specific
APIs rath
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> From: Venkat Gopalakrishnan
>
> This patch adds CMDQ support for command-queue compatible
> hosts.
>
> Command queue is added in eMMC-5.1 specification. This
> enables the controller to process upto 32 requests at
> a time.
>
> Adrian Hunter
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> @@ -2188,11 +2327,18 @@ enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue
> *mq, struct request *req)
> return MMC_REQ_FAILED_TO_START;
> }
> return MMC_REQ_FINISHED;
> + case
Can I get a review for this one? The only changes vs the previously
reviewed versions is that we don't use the multipath code at all for
subsystems that aren't multiported, and that there is an explicit
opt-out at compile and module load time, so it shouldn't be that hard
to review for those who r
On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote:
> Define and use a blk-mq queue. Discards and flushes are processed
> synchronously, but reads and writes asynchronously. In order to support
> slow DMA unmapping, DMA unmapping is not done until after the next request
> is started. That means
Initialize the seq_zone_bitmap and nr_zones fields of the disk request
queue on disk revalidate. As the seq_zone_bitmap allocation is
identical to the allocation of the zone write lock bitmap, introduce
the helper sd_zbc_alloc_zone_bitmap(). Using this helper, wait for the
disk capacity and number
From: Christoph Hellwig
Components relying only on the request_queue structure for accessing
block devices (e.g. I/O schedulers) have a limited knowledged of the
device characteristics. In particular, the device capacity cannot be
easily discovered, which for a zoned block device also result in t
Make sure that the device request queue zone information (number of
zones and zone bitmaps) are reinitialized if the number of zones
changes (e.g. on a drive capacity change on revalidate).
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd_zbc.c | 36 ++--
1 file
The block layer now handles zone write locking.
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd.c| 41 +++---
drivers/scsi/sd.h| 11 -
drivers/scsi/sd_zbc.c| 105 +++
include/scsi/scsi_cmnd.h | 3 +-
4 files ch
Avoid directly referencing the next_rq and fifo_list arrays using the
helper functions deadline_next_request() and deadline_fifo_request() to
facilitate changes in the dispatch request selection in
__dd_dispatch_request() for zoned block devices.
Signed-off-by: Damien Le Moal
Reviewed-by: Bart Va
This series, formerly titled "scsi-mq support for ZBC disks", implements
support for ZBC disks for system using the scsi-mq I/O path.
The current scsi level support of ZBC disks guarantees write request ordering
using a per-zone write lock which prevents issuing simultaneously multiple
write comma
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
Avoid directly referencing the next_rq and fifo_list arrays using the
helper functions deadline_next_request() and deadline_fifo_request() to
facilitate changes in the dispatch request selection in
deadline_dispatch_requests() for zoned block devices.
While at it, also remove the unnecessary forwa
90 matches
Mail list logo
