Project

General

Profile

Bug #5244

zio pipeline callers should explicitly invoke next stage

Added by Matthew Ahrens about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Category:
zfs - Zettabyte File System
Start date:
2014-10-18
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

The zio pipeline relies on ZIO_PIPELINE_STOP and ZIO_PIPELINE_CONTINUE to
direct the pipeline into the next stage. Unfortunately the pipeline can call
into the vdev layer which also uses these same directives without knowledge of
whether or not the zio going through the pipeline has changed.

This can lead to programming errors because at the lowest level of the issue
pipeline the zio may change because of our queuing logic:

static int
zio_vdev_io_start(zio_t *zio) {
<snip>

if ((zio = vdev_queue_io(zio)) == NULL)
return (ZIO_PIPELINE_STOP);
if (!vdev_accessible(vd, zio)) {
zio->io_error = SET_ERROR(ENXIO);
zio_interrupt(zio);
return (ZIO_PIPELINE_STOP);
}
}
return (vd->vdev_ops->vdev_op_io_start(zio));
}

In the code above the zio that is used to call into the vdev layer may not be
the same zio that entered this pipeline stage. If the vdev layer continues the
pipeline then it will result in an old zio moving into the next stage without
being issued.

History

#1

Updated by Electric Monk about 5 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit 738f37bc3dcd61e8a893af0f2d466d76690b70ec

commit  738f37bc3dcd61e8a893af0f2d466d76690b70ec
Author: George Wilson <george.wilson@delphix.com>
Date:   2014-11-06T19:37:25.000Z

    5244 zio pipeline callers should explicitly invoke next stage
    Reviewed by: Adam Leventhal <ahl@delphix.com>
    Reviewed by: Alex Reece <alex.reece@delphix.com>
    Reviewed by: Christopher Siden <christopher.siden@delphix.com>
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Reviewed by: Richard Elling <richard.elling@gmail.com>
    Reviewed by: Dan McDonald <danmcd@omniti.com>
    Reviewed by: Steven Hartland <killing@multiplay.co.uk>
    Approved by: Gordon Ross <gwr@nexenta.com>

Also available in: Atom PDF