As of 2.6.25 kobj->k_name was replaced with kobj->name. Some distros
such as RHEL5 (2.6.18) add a patch to prevent this from being a problem
but other older distros such as SLES10 (2.6.16) have not. To avoid
the whole issue I'm updating the code to use kobject_set_name() which
does what I want and has existed all the way back to 2.6.11.
With this patch applied I get the following failure 100% of the time,
I'd prefer to debug it and keep moving forward but I do not have the
time right now so I'm reverting the patch to the version which worked.
Ricardo please fix.
(gdb) bt
0 ztest_dmu_write_parallel (za=0x2aaaac898960) at
../../cmd/ztest/ztest.c:2566
1 0x0000000000405a79 in ztest_thread (arg=<value optimized out>)
at ../../cmd/ztest/ztest.c:3862
2 0x00002b2e6a7a841d in zk_thread_helper (arg=<value optimized out>)
at ../../lib/libzpool/kernel.c:131
3 0x000000379be06367 in start_thread (arg=<value optimized out>)
at pthread_create.c:297
4 0x000000379b2d30ad in clone () from /lib64/libc.so.6
This resolves previous scalabily concerns about the cost of calling
curthread which previously required a list walk. The kthread address
is now tracked as thread specific data which can be quickly returned.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
The 2.6.30 kernel build systems sets -Wframe-larger-than=2048 which causes
a warning to be generated when an individual stack frame exceeds 2048.
This caught the spa_history_log() and dmu_objset_snapshot() functions
which declared a data structure on the stack which contained a char
array of MAXPATHLEN. This in defined to be 4096 in the linux kernel
and I imagine it is quite large under Solaris as well. Regardless, the
offending data structures were moved to the heap to correctly keep the
stack depth to a minimum. We might consider setting this value even
lower to catch additional offenders because we are expecting deep stacks.
- Linux specific character device registration calls replaced with
the spl version for maximum portability between linux kernels.
- Added ZPIOS_NAME macro.
A compat ioctl handler for zpios was added which simply passes the
ioctl on to the usual handler. The IOWR macro's correctly handle
this. Additionally replace the use of 'struct timespec' which uses
longs internally and is therefore different sizes on 32-bit vs 64-bit
objects with 'struct zpios_timespec_t'. This custom structure uses
uint32_t types internally and is safe to pass through an ioctl. The
helper functions for this new type were also moved to a common place
so they may be used safely by the user or kernel code.
The intent here is to fully remove the previous Solaris thread
implementation so we don't need to simulate both Solaris kernel
and user space thread APIs. The few user space consumers of the
thread API have been updated to use the kthread API. In order
to support this we needed to more fully support the kthread API
and that means not doing crazy things like casting a thread id
to a pointer and using that as was done before. This first
implementation is not effecient but it does provide all the
corrent semantics. If/when performance becomes and issue we
can and should just natively adopt pthreads which is portable.
Let me finish by saying I'm not proud of any of this and I would
love to see it improved. However, this slow implementation does
at least provide all the correct kthread API semantics whereas
the previous method of casting the thread ID to a pointer was
dodgy at best.
Brian Behlendorf
Ricardo M. Correia