summaryrefslogtreecommitdiffstats
path: root/sys/dev/vinum/vinumlock.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused vinum files.phk2004-11-041-266/+0
|
* Use __FBSDID().obrien2003-08-241-1/+3
| | | | Also some minor style cleanups.
* Change the way the plex lock mutexes work. Previously they were partgrog2003-05-231-5/+5
| | | | | | | | | of the struct plex, which tore apart the mutex linked lists when the plex table was expanded. Now we maintain a pool of mutexes (currently 32) to be shared by all plexes. This is still a lot better than the splhigh() method used in other architectures. Approved by: re (jhb)
* Clarify comments.grog2003-05-051-2/+2
|
* #ifdef VINUMDEBUG, not #if VINUMDEBUG.grog2003-05-011-2/+2
|
* Add a new debug flag, DEBUG_LOCKREQS, which logs only lock requests.grog2001-05-221-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | Use this instead of DEBUG_LASTREQS to decide whether to log lock requests. MFS: vinumlock: Catch a potential race condition where one process is waiting for a lock, and between the time it is woken and it retries the lock, another process gets it and places it in the first entry in the table. This problem has not been observed, but it's possible, and it's easy enough to fix. Submitted by: tegge vinumunlock: Catch a real bug capable of hanging a system. When releasing a lock, vinumunlock() called wakeup_one. This caused wakeups to sometimes get lost. After due consideration, we think that this is due to the fact that you can't guarantee that some other process is also waiting on the same address. This makes wakeup_one a very dangerous function to use.
* Change and clean the mutex lock interface.bmilekic2001-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mtx_enter(lock, type) becomes: mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks) mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized) similarily, for releasing a lock, we now have: mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN. We change the caller interface for the two different types of locks because the semantics are entirely different for each case, and this makes it explicitly clear and, at the same time, it rids us of the extra `type' argument. The enter->lock and exit->unlock change has been made with the idea that we're "locking data" and not "entering locked code" in mind. Further, remove all additional "flags" previously passed to the lock acquire/release routines with the exception of two: MTX_QUIET and MTX_NOSWITCH The functionality of these flags is preserved and they can be passed to the lock/unlock routines by calling the corresponding wrappers: mtx_{lock, unlock}_flags(lock, flag(s)) and mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN locks, respectively. Re-inline some lock acq/rel code; in the sleep lock case, we only inline the _obtain_lock()s in order to ensure that the inlined code fits into a cache line. In the spin lock case, we inline recursion and actually only perform a function call if we need to spin. This change has been made with the idea that we generally tend to avoid spin locks and that also the spin locks that we do have and are heavily used (i.e. sched_lock) do recurse, and therefore in an effort to reduce function call overhead for some architectures (such as alpha), we inline recursion for this case. Create a new malloc type for the witness code and retire from using the M_DEV type. The new type is called M_WITNESS and is only declared if WITNESS is enabled. Begin cleaning up some machdep/mutex.h code - specifically updated the "optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently need those. Finally, caught up to the interface changes in all sys code. Contributors: jake, jhb, jasone (in no particular order)
* struct rangelock: Remove the field 'plex' from the entry. Range locksgrog2001-01-141-5/+2
| | | | | are accessed only via the plex, so there's never any confusion as to the plex number. This value was, as a result, unused.
* Remove obsolete functions [un]lockplex and [un]lockvol.grog2001-01-101-139/+64
| | | | | | | | | | | | | Rewrite lockrange and unlockrange. The lock table is now a fixed size, so there is no possibility for race conditions when expanding. The current size (256 locked ranges) should be large enough that it makes no sense to expand it. To do expansion right would require quiescing the plex (requiring at least 256 I/O completions), and the performance implications are horrendous. Add a mutex per plex for accessing the lock table. Based on analysis by: tegge
* lockrange: Avoid a race condition which was causing random corruption,grog2000-05-041-6/+5
| | | | | | | panics and hangs in RAID-5 plexes, particularly with ata drives. Original-code-by: Bernd Walter <ticso@cicely.de> Eagerly-awaited-by: sos
* Don't tsleep with PCATCH, it's a wonderful way to hang the system.grog2000-01-051-5/+6
| | | | Reported-by: Bernd Walter <ticso@cicely.de>
* Don't count iterations while waiting for a lock to become free.grog1999-09-281-10/+9
|
* Reverse MFC of revision 1.5.2.7:grog1999-09-031-2/+0
| | | | | | Remove a rather embarrassing race condition. Egged-on-by: alfred
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* config_plex: don't allocate a rangelock struct.grog1999-08-261-2/+3
| | | | | | | | lockrange: correctly expand rangelock struct, including expanding a null struct. Previously lockrange would attempt to lock a NULL pointer under these circumstances. Reported-by: Ian Freislich <iang@uunet.co.za>
* Change parameters of unlockrange to allow calling from revive_block,grog1999-08-241-15/+15
| | | | which doesn't use request groups.
* rewrite lockrange and unlockrange. Hopefully the current version willgrog1999-08-141-44/+105
| | | | | | | | solve some data integrity problems that have been reported with degraded RAID-5 plexes. Reported-by: Bernd Walter <ticso@cicely.de> Remy Nonnenmacher <remy@synx.com>
* Import RAID-5 code.grog1999-08-071-1/+67
| | | | | | Add Cybernet copyright. OK'd-by: Chuck Jacobus <chuck@cybernet.com>
* Modify to work with new style dev_t.grog1999-05-151-2/+2
| | | | | With_copious_input_from: peter phk
* Remove old grunge, including references to sys/disk.h (which is goinggrog1999-05-071-2/+0
| | | | | | away). Submitted-by: phk
* lockdrive: Add debug calls to catch occasional deadlocks on drives.grog1999-04-101-6/+26
| | | | | The problem is probably gone, but the debug checks remain for a while.
* lock_drive: report on and recover from an obscure situation where thegrog1999-03-131-0/+7
| | | | daemon can deadlock against itself.
* Change multiline comments to start with a lone /* and end with a */,grog1999-01-291-8/+16
| | | | | | apparently in accordance with style(9). Complained-about-by: bde
* Create functions lockdrive and unlockdrive to handle drive lockinggrog1999-01-211-2/+35
|
* Some relatively minor tweaks to enable vinum to be built into a staticpeter1998-12-281-2/+3
| | | | | | | | | | | | | | | | kernel as a pseudo-device. The changes were: - #ifdef DEBUG -> #ifdef VINUMDEBUG - opt_vinum.h for holding above config variable - Fixing up a few stray problems where DEBUG wasn't optional. - config.c -> vinumconfig.c (there's already a config.o) - Other *.c -> vinum*.c (wasn't strictly necessary, but done in case we end up with something else conflicting later on and we might have to have yet more repository copies of files). - include file paths fixups.. (ie: get them all from the kernel tree instead of partly from the kernel and partly from /usr/include/machine) I've spoken with Greg about this.. I hope this doesn't mess him around too much..
* If I've done this right, revive the vinum code in it's now home after itpeter1998-12-281-0/+137
| | | | was savaged in the blood bath a few hours ago.
* Remove LKM's depricated by modules.sos1998-12-271-137/+0
|
* Import base vinum lkm sourcesgrog1998-09-161-0/+137
OpenPOWER on IntegriCloud