src/sys/kern/subr_taskqueue.c, branch releng/7.3

MFC 198411:

2010-01-21T19:17:42Z

- Fix several off-by-one errors when using MAXCOMLEN. The p_comm[] and td_name[] arrays are actually MAXCOMLEN + 1 in size and a few places that created shadow copies of these arrays were just using MAXCOMLEN. - Prefer using sizeof() of an array type to explicit constants for the array length in a few places. - Ensure that all of p_comm[] is always zero'd during execve() to guard against any possible information leaks. Previously trailing garbage in p_comm[] could be leaked to userland in ktrace record headers.

MFC several ZFS related commits:

2010-01-06T08:18:49Z

- taskq changes - fixes for race conditions - locking fixes - bug fixes - ... r185310: ---snip--- Remove unused variable. Found with: Coverity Prevent(tm) CID: 3669,3671 ---snip--- r185319: ---snip--- Fix locking (file descriptor table and Giant around VFS). Most submitted by: kib Reviewed by: kib ---snip--- r192689: ---snip--- Fix comment. ---snip--- r193110: ---snip--- work around snapshot shutdown race reported by Henri Hennebert ---snip--- r193440: ---snip--- Support shared vnode locks for write operations when the offset is provided on filesystems that support it. This really improves mysql + innodb performance on ZFS. Reviewed by: jhb, kmacy, jeffr ---snip--- ATTENTION: this commit to releng7 does not allow shared vnode locks (there are some VFS changes needed before it can be enabled), it only provides the infrastructure and serves mostly as a diff reduction in the ZFS code. A comment has been added to the locking part to explain why no shared locks are used. r195627: ---snip--- In nvpair_native_embedded_array(), meaningless pointers are zeroed. The programmer was aware that alignment was not guaranteed in the packed structure and used bzero() to NULL out the pointers. However, on ia64, the compiler is quite agressive in finding ILP and calls to bzero() are often replaced by simple assignments (i.e. stores). Especially when the width or size in question corresponds with a store instruction (i.e. st1, st2, st4 or st8). The problem here is not a compiler bug. The address of the memory to zero-out was given by '&packed->nvl_priv' and given the type of the 'packed' pointer the compiler could assume proper alignment for the replacement of bzero() with an 8-byte wide store to be valid. The problem is with the programmer. The programmer knew that the address did not have the alignment guarantees needed for a regular assignment, but failed to inform the compiler of that fact. In fact, the programmer told the compiler the opposite: alignment is guaranteed. The fix is to avoid using a pointer of type "nvlist_t *" and instead use a "char *" pointer as the basis for calculating the address. This tells the compiler that only 1-byte alignment can be assumed and the compiler will either keep the bzero() call or instead replace it with a sequence of byte-wise stores. Both are valid. ---snip--- r195822: ---snip--- Fix extattr_list_file(2) on ZFS in case the attribute directory doesn't exist and user doesn't have write access to the file. Without this fix, it returns bogus value instead of 0. For some reason this didn't manifest on my kernel compiled with -O0. PR: kern/136601 Submitted by: Jaakko Heinonen ---snip--- r195909 ---snip--- We don't support ephemeral IDs in FreeBSD and without this fix ZFS can panic when in zfs_fuid_create_cred() when userid is negative. It is converted to unsigned value which makes IS_EPHEMERAL() macro to incorrectly report that this is ephemeral ID. The most reasonable solution for now is to always report that the given ID is not ephemeral. PR: kern/132337 Submitted by: Matthew West Tested by: Thomas Backman , Michael Reifenberger ---snip--- r196291: ---snip--- - Fix a race where /dev/zfs control device is created before ZFS is fully initialized. Also destroy /dev/zfs before doing other deinitializations. - Initialization through taskq is no longer needed and there is a race where one of the zpool/zfs command loads zfs.ko and tries to do some work immediately, but /dev/zfs is not there yet. Reported by: pav ---snip--- r196269: ---snip--- Fix misalignment in nvpair_native_embedded() caused by the compiler replacing the bzero(). See also revision 195627, which fixed the misalignment in nvpair_native_embedded_array(). ---snip--- r196295: ---snip--- Remove OpenSolaris taskq port (it performs very poorly in our kernel) and replace it with wrappers around our taskqueue(9). To make it possible implement taskqueue_member() function which returns 1 if the given thread was created by the given taskqueue. ---snip--- The taskqueue_member() function is different due to kproc/kthread changes in releng8 and head, the function was... Revieved by: jhb r196297: ---snip--- Fix panic in zfs recv code. The last vnode (mountpoint's vnode) can have 0 usecount. Reported by: Thomas Backman ---snip--- r196299: ---snip--- - We need to recycle vnode instead of freeing znode. Submitted by: avg - Add missing vnode interlock unlock. - Remove redundant znode locking. ---snip--- r196301: ---snip--- If z_buf is NULL, we should free znode immediately. Noticed by: avg ---snip--- r196307: ---snip--- Manage asynchronous vnode release just like Solaris. Discussed with: kmacy ---snip---

MFC r188548

2009-03-11T00:58:22Z

Check the exit flag at the start of the taskqueue loop rather than the end. It is possible to tear down the taskqueue before the thread has run and the taskqueue loop would sleep forever.

Merge rev 1.41, 1.18: Implement taskqueue_block, taskqueue_unblock.

2008-08-03T14:28:26Z

Commit 14/14 of sched_lock decomposition.

2007-06-05T00:00:57Z

- Use thread_lock() rather than sched_lock for per-thread scheduling sychronization. - Use the per-process spinlock rather than the sched_lock for per-process scheduling synchronization. Tested by: kris, current@ Tested on: i386, amd64, ULE, 4BSD, libthr, libkse, PREEMPTION, etc. Discussed with: kris, attilio, kmacy, jhb, julian, bde (small parts each)

- Remove setrunqueue and replace it with direct calls to sched_add().

2007-01-23T08:46:51Z

setrunqueue() was mostly empty. The few asserts and thread state setting were moved to the individual schedulers. sched_add() was chosen to displace it for naming consistency reasons. - Remove adjustrunqueue, it was 4 lines of code that was ifdef'd to be different on all three schedulers where it was only called in one place each. - Remove the long ifdef'd out remrunqueue code. - Remove the now redundant ts_state. Inspect the thread state directly. - Don't set TSF_* flags from kern_switch.c, we were only doing this to support a feature in one scheduler. - Change sched_choose() to return a thread rather than a td_sched. Also, rely on the schedulers to return the idlethread. This simplifies the logic in choosethread(). Aside from the run queue links kern_switch.c mostly does not care about the contents of td_sched. Discussed with: julian - Move the idle thread loop into the per scheduler area. ULE wants to do something different from the other schedulers. Suggested by: jhb Tested on: x86/amd64 sched_{4BSD, ULE, CORE}.

When starting up threads in taskqueue_start_threads create them

2006-05-24T22:11:07Z

stopped before adjusting their priority and setting them on the run q so they cannot race for resources (pointed out by njl). While here add a console printf on thread create fails; otherwise noone may notice (e.g. return value is always 0 and caller has no way to verify). Reviewed by: jhb, scottl MFC after: 2 weeks

Change msleep() and tsleep() to not alter the calling thread's priority

2006-04-17T18:20:38Z

if the specified priority is zero. This avoids a race where the calling thread could read a snapshot of it's current priority, then a different thread could change the first thread's priority, then the original thread would call sched_prio() inside msleep() undoing the change made by the second thread. I used a priority of zero as no thread that calls msleep() or tsleep() should be specifying a priority of zero anyway. The various places that passed 'curthread->td_priority' or some variant as the priority now pass 0.

fixup error handling in taskqueue_start_threads: check for kthread_create

2006-03-30T23:06:59Z

failing, print a message when we fail for some reason as most callers do not check the return value (e.g. 'cuz they're called from SYSINIT) Reviewed by: scottl MFC after: 1 week

Add the following to the taskqueue api:

2006-01-14T01:55:24Z

taskqueue_start_threads(struct taskqueue **, int count, int pri, const char *name, ...); This allows the creation of 1 or more threads that will service a single taskqueue. Also rework the taskqueue_create() API to remove the API change that was introduced a while back. Creating a taskqueue doesn't rely on the presence of a process structure, and the proc mechanics are much better encapsulated in taskqueue_start_threads(). Also clean up the taskqueue_terminate() and taskqueue_free() functions to safely drain pending tasks and remove all associated threads. The TASKQUEUE_DEFINE and TASKQUEUE_DEFINE_THREAD macros have been changed to use the new API, but drivers compiled against the old definitions will still work. Thus, recompiling drivers is not a strict requirement.