History log of /freebsd/sys/kern/kern_rwlock.c (Results 176 – 200 of 299)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2287aa04 27-Mar-2010 Bjoern A. Zeeb <bz@FreeBSD.org>

MFC r205626:

Print the pointer to the lock with the panic message. The previous
panic: rw lock not unlocked
was not really helpful for debugging. Now one can at least call
show l

MFC r205626:

Print the pointer to the lock with the panic message. The previous
panic: rw lock not unlocked
was not really helpful for debugging. Now one can at least call
show lock <ptr>
form ddb to learn more about the lock.

show more ...


# 2430ab46 24-Mar-2010 Bjoern A. Zeeb <bz@FreeBSD.org>

Print the pointer to the lock with the panic message. The previous
panic: rw lock not unlocked
was not really helpful for debugging. Now one can at least call
show lock <ptr>
form ddb to learn more

Print the pointer to the lock with the panic message. The previous
panic: rw lock not unlocked
was not really helpful for debugging. Now one can at least call
show lock <ptr>
form ddb to learn more about the lock.

MFC after: 3 days

show more ...


Revision tags: release/7.3.0_cvs, release/7.3.0
# 1a0fda2b 04-Mar-2010 Dag-Erling Smørgrav <des@FreeBSD.org>

IFH@204581


Revision tags: release/8.0.0_cvs, release/8.0.0
# 3f4609ac 12-Oct-2009 Attilio Rao <attilio@FreeBSD.org>

MFC r197643, r197735:
When releasing a read/shared lock we need to use a write memory barrier
in order to avoid, on architectures which doesn't have strong ordered
writes, CPU instructions reordering

MFC r197643, r197735:
When releasing a read/shared lock we need to use a write memory barrier
in order to avoid, on architectures which doesn't have strong ordered
writes, CPU instructions reordering.

Approved by: re (kib)

show more ...


# 1ee774f6 02-Oct-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC


# ddce63ca 30-Sep-2009 Attilio Rao <attilio@FreeBSD.org>

When releasing a read/shared lock we need to use a write memory barrier
in order to avoid, on architectures which doesn't have strong ordered
writes, CPU instructions reordering.

Diagnosed by: fabio

When releasing a read/shared lock we need to use a write memory barrier
in order to avoid, on architectures which doesn't have strong ordered
writes, CPU instructions reordering.

Diagnosed by: fabio
Reviewed by: jhb
Tested by: Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>

show more ...


# 10b3b545 17-Sep-2009 Dag-Erling Smørgrav <des@FreeBSD.org>

Merge from head


# 7d4b968b 17-Sep-2009 Dag-Erling Smørgrav <des@FreeBSD.org>

Merge from head up to r188941 (last revision before the USB stack switch)


# c90c9ddd 09-Sep-2009 Attilio Rao <attilio@FreeBSD.org>

Adaptive spinning for locking primitives, in read-mode, have some tuning
SYSCTLs which are inappropriate for a daily use of the machine (mostly
useful only by a developer which wants to run benchmark

Adaptive spinning for locking primitives, in read-mode, have some tuning
SYSCTLs which are inappropriate for a daily use of the machine (mostly
useful only by a developer which wants to run benchmarks on it).
Remove them before the release as long as we do not want to ship with
them in.

Now that the SYSCTLs are gone, instead than use static storage for some
constants, use real numeric constants in order to avoid eventual compiler
dumbiness and the risk to share a storage (and then a cache-line) among
CPUs when doing adaptive spinning together.

Pleasse note that the sys/linker_set.h inclusion in lockmgr and sx lock
support could have been gone, but re@ preferred them to be in order to
minimize the risk of problems on future merging.

Please note that this patch is not a MFC, but an 'edge case' as commit
directly to stable/8, which creates a diverging from HEAD.

Tested by: Giovanni Trematerra <giovanni dot trematerra at gmail dot com>
Approved by: re (kib)

show more ...


# cbd59a4f 08-Sep-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC from head@196987


# 7e2d0af9 17-Aug-2009 Attilio Rao <attilio@FreeBSD.org>

MFC r196334:

* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to
a pointer-fetching specific operation check. Consequently, rename the
operation ASSERT_ATOMIC_LOAD_PTR().
* Fi

MFC r196334:

* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to
a pointer-fetching specific operation check. Consequently, rename the
operation ASSERT_ATOMIC_LOAD_PTR().
* Fix the implementation of ASSERT_ATOMIC_LOAD_PTR() by checking
directly alignment on the word boundry, for all the given specific
architectures. That's a bit too strict for some common case, but it
assures safety.
* Add a comment explaining the scope of the macro
* Add a new stub in the lockmgr specific implementation

Tested by: marcel (initial version), marius
Reviewed by: rwatson, jhb (comment specific review)
Approved by: re (kib)

show more ...


# 353998ac 17-Aug-2009 Attilio Rao <attilio@FreeBSD.org>

* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to
a pointer-fetching specific operation check. Consequently, rename the
operation ASSERT_ATOMIC_LOAD_PTR().
* Fix the implemen

* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to
a pointer-fetching specific operation check. Consequently, rename the
operation ASSERT_ATOMIC_LOAD_PTR().
* Fix the implementation of ASSERT_ATOMIC_LOAD_PTR() by checking
directly alignment on the word boundry, for all the given specific
architectures. That's a bit too strict for some common case, but it
assures safety.
* Add a comment explaining the scope of the macro
* Add a new stub in the lockmgr specific implementation

Tested by: marcel (initial version), marius
Reviewed by: rwatson, jhb (comment specific review)
Approved by: re (kib)

show more ...


# 21845eba 14-Aug-2009 Bjoern A. Zeeb <bz@FreeBSD.org>

MFC r196226:

Add a new macro to test that a variable could be loaded atomically.
Check that the given variable is at most uintptr_t in size and that
it is aligned.

Note: ASSERT_ATOMIC_LOAD(

MFC r196226:

Add a new macro to test that a variable could be loaded atomically.
Check that the given variable is at most uintptr_t in size and that
it is aligned.

Note: ASSERT_ATOMIC_LOAD() uses ALIGN() to check for adequate
alignment -- however, the function of ALIGN() is to guarantee
alignment, and therefore may lead to stronger alignment
enforcement than necessary for types that are smaller than
sizeof(uintptr_t).

Add checks to mtx, rw and sx locks init functions to detect possible
breakage. This was used during debugging of the problem fixed with
r196118 where a pointer was on an un-aligned address in the dpcpu area.

In collaboration with: rwatson
Reviewed by: rwatson

Approved by: re (kib)

show more ...


# 8d518523 14-Aug-2009 Bjoern A. Zeeb <bz@FreeBSD.org>

Add a new macro to test that a variable could be loaded atomically.
Check that the given variable is at most uintptr_t in size and that
it is aligned.

Note: ASSERT_ATOMIC_LOAD() uses ALIGN() to chec

Add a new macro to test that a variable could be loaded atomically.
Check that the given variable is at most uintptr_t in size and that
it is aligned.

Note: ASSERT_ATOMIC_LOAD() uses ALIGN() to check for adequate
alignment -- however, the function of ALIGN() is to guarantee
alignment, and therefore may lead to stronger alignment
enforcement than necessary for types that are smaller than
sizeof(uintptr_t).

Add checks to mtx, rw and sx locks init functions to detect possible
breakage. This was used during debugging of the problem fixed with
r196118 where a pointer was on an un-aligned address in the dpcpu area.

In collaboration with: rwatson
Reviewed by: rwatson
Approved by: re (kib)

show more ...


# 7e857dd1 12-Jun-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Merge from HEAD


# 2e03f452 04-Jun-2009 Jung-uk Kim <jkim@FreeBSD.org>

Resync with head.


# f0830182 02-Jun-2009 Attilio Rao <attilio@FreeBSD.org>

Handle lock recursion differenty by always checking against LO_RECURSABLE
instead the lock own flag itself.

Tested by: pho


# a571ad41 29-May-2009 John Baldwin <jhb@FreeBSD.org>

Remove extra cpu_spinwait() invocations. This should really only be used
in tight spin loops, not in these edge cases where we restart a much
larger loop only a few times.

Reviewed by: attilio


# fa29f023 29-May-2009 John Baldwin <jhb@FreeBSD.org>

Tweak a few comments on adaptive spinning.


# a5aedd68 26-May-2009 Stacey Son <sson@FreeBSD.org>

Add the OpenSolaris dtrace lockstat provider. The lockstat provider
adds probes for mutexes, reader/writer and shared/exclusive locks to
gather contention statistics and other locking information fo

Add the OpenSolaris dtrace lockstat provider. The lockstat provider
adds probes for mutexes, reader/writer and shared/exclusive locks to
gather contention statistics and other locking information for
dtrace scripts, the lockstat(1M) command and other potential
consumers.

Reviewed by: attilio jhb jb
Approved by: gnn (mentor)

show more ...


Revision tags: release/7.2.0_cvs, release/7.2.0
# 9c797940 13-Apr-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Merge from HEAD


# 1723a064 15-Mar-2009 Jeff Roberson <jeff@FreeBSD.org>

- Wrap lock profiling state variables in #ifdef LOCK_PROFILING blocks.


# 1829d5da 12-Mar-2009 Warner Losh <imp@FreeBSD.org>

Update the projects tree to a newer FreeBSD current.


# c90c9021 26-Feb-2009 Ed Schouten <ed@FreeBSD.org>

Remove even more unneeded variable assignments.

kern_time.c:
- Unused variable `p'.

kern_thr.c:
- Variable `error' is always caught immediately, so no reason to
initialize it. There is no way tha

Remove even more unneeded variable assignments.

kern_time.c:
- Unused variable `p'.

kern_thr.c:
- Variable `error' is always caught immediately, so no reason to
initialize it. There is no way that error != 0 at the end of
create_thread().

kern_sig.c:
- Unused variable `code'.

kern_synch.c:
- `rval' is always assigned in all different cases.

kern_rwlock.c:
- `v' is always overwritten with RW_UNLOCKED further on.

kern_malloc.c:
- `size' is always initialized with the proper value before being used.

kern_exit.c:
- `error' is always caught and returned immediately. abort2() never
returns a non-zero value.

kern_exec.c:
- `len' is always assigned inside the if-statement right below it.

tty_info.c:
- `td' is always overwritten by FOREACH_THREAD_IN_PROC().

Found by: LLVM's scan-build

show more ...


Revision tags: release/7.1.0_cvs, release/7.1.0
# e1d881ba 08-Dec-2008 Kip Macy <kmacy@FreeBSD.org>

add RW_SYSINIT_FLAGS macro and rw_sysinit_flags initialization function


12345678910>>...12