Under the latest Gentoo (2.6.34-gentoo-r2) the interlibrary
dependencies must be made explicit. This is likely due to
the --as-needed linker option which is commonly used under
Gentoo. This option requires that the linker only include
the minimum set of symbols required by the binary. Without
the full dependency tree the linker would need to bring in
all the symbols from dependent libraries.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
When probing /dev/ for validing ZFS devices to import skip floppy
block devices. There's no reason to waste time checking these
devices even though they are valid block devices. Plus, we had
one system get stuck on I/O errors probing the device.
end_request: I/O error, dev fd0, sector 0
Buffer I/O error on device fd0p120, logical block 0
end_request: I/O error, dev fd0, sector 8
Buffer I/O error on device fd0p120, logical block 1
This reverts commit 421d95b3ea.
Ricardo correctly pointed out that there is more going on here than
typecasting. By removing the locals we are actually causing LEFT and
RIGHT to be evaluated twice which can potentially lead to some
strange side effects as:
1) VERIFY3*() causing a panic but in the panic message the values
look correct such that the assertion shouldn't fail, or:
2) if LEFT or RIGHT are expressions with side-effects (e.g. a call
to a function which changes some state), then when we panic and
examine the crash dump, it may lead to an unexpected state because
we are not expecting certain things to change during the panic,
after the expressions inside VERIFY3*(...) have been evaluated.
3) Also, it may lead to double-panics or deadlocks during panics,
like for example, if the expressions inside VERIFY3*(...) only expect
to be called once (e.g. because they acquire a mutex).
commit 421d95b3ea introduced a compiler
warning on 32-bit systems about casting a pointer to an integer of a
different size. This commit removes the warning by casting the arguments
to snprintf in the same manner as the original VERIFY3_IMPL macro.
This has a minor impact on stack usage of individual functions, but the
VERIFY macros are used so frequently that their overhead may add up.
This macro declared two new local variables to cast its argument types.
Doing the typecast inline eliminates the need for these variables.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
With the update to onnv_141 how minor devices were created and
removed for ZVOL was substantially changed. The updated system
is much more tightly integrated with Solaris's /dev/ filesystem.
This is great for Solaris but bad for Linux.
This patch keeps as much of those changes as possible which as
useful for Linux. But it also reverts back to use the old system
of explicit minor node creation via a decicated ioctl(). This
worked well in zfs-0.4.9 and it should continue to work well.
Some buggy NPTL threading implementations include the guard area within
the stack size allocations. In this case we need to allocate an extra
page to account for the guard area since we only have two pages of usable
stack on Linux. Added an autoconf test that detects such implementations
by running a test program designed to segfault if the bug is present.
Set a flag NPTL_GUARD_WITHIN_STACK that is tested to decide if extra
stack space must be allocated for the guard area.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
See commit f16dec7e67fe86f3c3556a67865ee715a2964d70 for full
details of this change. But in summary -fstack-check is being
restricted in usage only to locations which must already have
small stack frames.
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
To use the -fstack-check gcc option each stack frame must be
keep reasonably small. In this case the path local is moved
from the stack to the heap to keep us under the limit.
warning: frame size too large for reliable stack checking
warning: try reducing the number of local variables
Brian Behlendorf
Sebastian Pipping
Ned Bass