The stack check implementation in older versions of gcc has
a fairly low default limit on STACK_CHECK_MAX_FRAME_SIZE of
roughly 4096. This results in numerous warning when it is
used with code which was designed to run in user space and
thus may be relatively stack heavy. The avoid these warnings,
which are fatal with -Werror, this patch targets the use of
-fstack-check to libraries which are compiled in both user
space and kernel space. The only utility which uses this
flag is ztest which is designed to simulate running in the
kernel and must meet the -fstack-check requirements. All
other user space utilities do not use -fstack-check.
warning: frame size too large for reliable stack checking
warning: try reducing the number of local variables
The ZFS update to onnv_141 brought with it support for a
security label attribute called mlslabel. This feature
depends on zones to work correctly and thus I am disabling
it under Linux. Equivilant functionality could be added
at some point in the future.
The ZFS update to onnv_141 brought with it support for a
security label attribute called mlslabel. This feature
depends on zones to work correctly and while I originally
added minimal support for this in libspl that was a mistake.
Supporting this under Linux is not required and this is
just additional troublesome code to support. Long term
something like this could be supported under Linux but it
will need to be clearly thought through them an implemented.
We should just make a best effort when removing zvol minors
from the system during destroy. Failure here should never
prevent the pool from being destroyed. For example, if a
pool is so heavily damaged it cannot be opened (part of the
minor removal) we still want to be able to destroy it. The
worst case here is we may orphan a few minors but even that
is unlikely and not particularly harmful.
This was done because there are now lots of resource.fs.zfs.statechange
events being posted but they do not include the state. For the moment
the state must always be healthy but there's no harm in making this
explicit.
Previously I was adding the FM_EREPORT_TIME time when the nvlist
was constructed. However, with the update to onnv_141 these
ereport nvlists are now constructed in several places and it
doesn't make sense for each of them to have to add this common
bit of info. To handle this the FM_EREPORT_TIME is now only
added once when the event is posted.
Brian Behlendorf