Maybe clarify a bit: "reports" means "prints to the console".

I think, if such option is ever present, you should also add a logging of the sc_enxio_active = 1 event. In other words, we should clearly report that all errors are converted to ENXIO from now on and then g_report_enxio rules.

So add something like

if (sc->sc_enxio_active == 0)
    g_print("g_vfs_done() converting all future errors to ENXIO for %s", mumble);

before we set sc_enxio_active = 1? Or do it conditionally based on g_report_enxio? I think we just want to do that always on the 0->1 transition, independent of this option. There's no other place to do this only once, and UFS, the current only user of CVTENXIO doesn't report anything.

You say 'if such an option'. does that mean you'd rather not see an option and just never report ENXIO or are you saying you are just luke warm on this notion?

Yes, I think that new lines you pasted above are fine, together with existing addition to g_vfs_done() in this review. By 'if such option' I mean that the line above ("... converting ...") becomes quite useful if you also add the existing silencing change already in the review.

I do not object to or propose to abandon g_report_enxio.

Is the check for sc_enxio_reported racy? I mean, could two threads execute this condition and then assign true, simultaneously?

If yes, I do not think it is worth fixing, but at least noting it in a comment, for the reader' sake, would be useful.

I'll add a comment. It's only for a printf...

The race is tricky to trigger. Normally, we hold the periph lock during most of the completion process, but we drop it just before we call biodone(). This biodone might have a ENXIO return code. The first ENXIO error will trigger posting an AC_LOST_DEVICE to xpt_async_td, which will eventually wind up calling cam_periph_async() which will invalidate the device. That code will grab the periph lock and invalidate all the software queued I/O. These two things might race, but it's unlikely (but not impossible) they'd wind up racing each other through g_vfs_done(). If we lose the race, we'd lose the printf, which isn't the end of the world.

A simple cmpset would fix this. This would cause a flood of atomic activity (one per pending I/O when the device fails), but since this is only the error path for a dying device that happens rarely, it wouldn't be terrible. I'm torn on fixing it, though.

since it's easy enough to fix, I just fixed it (I hope)

Isn't it spelled atomic_cmpset_int ?