Do not panic on an uninitialized VOP_xxx() call. This was meant as a

sanity check, but it is too easy to run into, eg: making an ACL syscall
when no filesystems have the ACL implementation enabled.

The original reason for the panic was that the VOP_ vector had not been
assigned and therefor could not be passed down the stack.. and there
was no point passing it down since nothing implemented it anyway.
vop_defaultop entries could not pass it on because it had a zero (unknown)
vector that was indistinguishable from another unknown VOP vector.

Anyway, we can do something reasonable in this case, we shouldn't need
to panic here as there is a reasonable recovery option (return EOPNOTSUPP
and dont pass it down the stack).

Requested by: rwatson
This commit is contained in:
peter 2000-09-06 17:51:54 +00:00
parent 57baa5ad71
commit 9b21fca483

View File

@ -130,9 +130,9 @@ vfs_opv_recalc(void)
panic("no memory for vop_t ** vector");
bzero(*opv_desc_vector_p, vfs_opv_numops * sizeof(vop_t *));
/* Fill in, with slot 0 being panic */
/* Fill in, with slot 0 being to return EOPNOTSUPP */
opv_desc_vector = *opv_desc_vector_p;
opv_desc_vector[0] = (vop_t *)vop_panic;
opv_desc_vector[0] = (vop_t *)vop_eopnotsupp;
for (j = 0; opv->opv_desc_ops[j].opve_op; j++) {
opve_descp = &(opv->opv_desc_ops[j]);
opv_desc_vector[opve_descp->opve_op->vdesc_offset] =