Re: UMA zinit/zctor function error returning

Brian Fundakowski Feldman wrote:
>These are the only two places that can call uz_ctor, aren't they?
>
>uma_core.c:
>                        if (zone->uz_ctor) {
>                                if (zone->uz_ctor(item, zone->uz_keg->uk_size,
>                                    udata, flags) != 0) {
>                                        uma_zfree_internal(zone, item, udata,
>                                            SKIP_DTOR);
>                                        return (NULL);
>                                }
>                        }
>                        ...
>        if (zone->uz_ctor != NULL) {
>                if (zone->uz_ctor(item, keg->uk_size, udata, flags) != 0) {
>                        uma_zfree_internal(zone, item, udata, SKIP_DTOR);
>                        return (NULL);
>                }
>        }

  Yes, I guess you're right in this case.  We have to be careful, though,
  because in some cases the ctor might bring the object to a half-ctor'd
  state, in which case the failure path needs to know how to rewind the
  state prior to returning the error, as UMA will skip the dtor on that
  free.

>Well, I only did that because there were no places that called for
>a keg init being used in the first place (no calls to the
>uma_zone_set_init() function).

[VM]->keg_init->[keg(slabs)]->zone_init->[zone(buckets)]->zone_ctor->...

  By default, when you create a zone, the init you provide is hooked
  in as the _keg_init_, not the zone_init.  The zone_init is set
  with uma_zone_set_zinit(), and the keg init by uma_zone_set_init().
  As I said, when you create the zone, the init you provide is hooked
  in as the keg_init.  If you create a secondary zone, THEN you get to
  use the zone_init if you need to/want to.  So the keg_init has the
  same behavior as the OLD pre-extended-UMA zoneinit.

  Therefore, it is important for the keg_init to know how to fail,
  even if it only seems like it's for completeness right now, it
  is the most used init out there.  Once you allow the keginit to
  fail too (and receive the how argument), then you don't need to
  split up the keginit/zoneinit types and they can stay the same.

>> - the uma_dbg.c changes call the ctor explicitly from the fini.
>>   I forget the exact reason this is, but now that we're expecting
>>   the ctor to return something, if you are ignoring the return
>>   value, please cast void explicitly here (STYLE).  Alternately,
>>   make both keg and zone inits able to fail and propagate the failure,
>>   if any, upwards.
>
>I'm not sure what you mean here.  There are no return values I see ignored,
>but a couple functions with similar names (trash_ctor()/mtrash_ctor()).

  I'm talking about mtrash_fini() explicitly calling mtrash_ctor().
  There it should cast the call (void) since it doesn't check its
  return value or, when the fini is shown how to fail, return whatever
  mtrash_ctor() returns.

-Bosko