I got quite upset about this last time, and I guess it's time to do it
Folks, *please* stop exporting "pure" kernel structures to userland.
Make a sanitisied, versioned structure and just copy your damn args back
and forth. 'struct ucred' should probably never have been exported to
userspace, and it *certainly* never should have been exported to
userpsace with a mutex in it!
I also asked the perpetrator of this error to do something about it
following the last debacle it caused. In the meantime, perhaps we could
ask that one of the SMPng rules of engagement mandate that no mutex
structures or structure members should ever be exported as part of a
> My nfs server now always panics when it attempts to export ufs
> filesystems. This is caused by my mount(8) being slightly out of
> date. This shouldn't be a problem, but `struct export_args' contains
> a `struct ucred' which contains a `struct mtx', so when `struct mtx'
> shrunk by 1 pointer yesterday, the out of date mount(8) started
> supplying garbage for all the export args following the ucred one.
> FreeBSD does very little checking of the export args and panics in
> the following malloc() in vfs_hang_addrlist():
> i = sizeof(struct netcred) + argp->ex_addrlen + argp->ex_masklen;
> np = (struct netcred *)malloc(i, M_NETADDR, M_WAITOK | M_ZERO);
> ISTR a PR about lack of checking of export args.
> Somehow there were few problems when `struct mtx' was added to
> `struct ucred'. The critical args were probably usually 0.
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message