Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it | From | Jeff Layton <> | Date | Wed, 10 May 2017 07:29:19 -0400 |
| |
On Wed, 2017-05-10 at 08:03 +1000, NeilBrown wrote: > On Tue, May 09 2017, Jeff Layton wrote: > > > An errseq_t is a way of recording errors in one place, and allowing any > > number of "subscribers" to tell whether an error has been set again > > since a previous time. > > > > It's implemented as an unsigned 32-bit value that is managed with atomic > > operations. The low order bits are designated to hold an error code > > (max size of MAX_ERRNO). The upper bits are used as a counter. > > > > The API works with consumers sampling an errseq_t value at a particular > > point in time. Later, that value can be used to tell whether new errors > > have been set since that time. > > > > Note that there is a 1 in 512k risk of collisions here if new errors > > are being recorded frequently, since we have so few bits to use as a > > counter. To mitigate this, one bit is used as a flag to tell whether the > > value has been sampled since a new value was recorded. That allows > > us to avoid bumping the counter if no one has sampled it since it > > was last bumped. > > > > Later patches will build on this infrastructure to change how writeback > > errors are tracked in the kernel. > > > > Signed-off-by: Jeff Layton <jlayton@redhat.com> > > I like that this is a separate lib/*.c - nicely structured too. > > Reviewed-by: NeilBrown <neilb@suse.com> > >
Thanks, yeah...it occurred to me that this scheme is not really specific to writeback errors. While I can't think of another use-case for errseq_t's right offhand, I think this makes for cleaner layering and should make it easy to use in other ways should they arise.
-- Jeff Layton <jlayton@redhat.com>
| ![\](/images/icornerr.gif) |