Searched hist:ca1d2f657ac8942f180f7d1ab328400ae8524bf0 (Results 1 – 3 of 3) sorted by relevance
| /freebsd/sys/sys/ |
| H A D | msgbuf.h | diff ca1d2f657ac8942f180f7d1ab328400ae8524bf0 Tue Nov 03 22:06:19 CET 2009 Ed Schouten <ed@FreeBSD.org> Make /dev/klog and kern.msgbuf* MPSAFE.
Normally msgbufp is locked using Giant. Switch it to use the
msgbuf_lock. Instead of changing the tsleep() calls to msleep(), just
convert it to condvar(9).
In my opinion the locking around msgbuf_peekbytes() still remains
questionable. It looks like locks are dropped while performing copies of
multiple blocks to userspace, which may cause the msgbuf to be reset in
the mean time. At least getting it underneath from Giant should make it
a little easier for us to figure out how to solve that.
Reminded by: rdivacky
diff ca1d2f657ac8942f180f7d1ab328400ae8524bf0 Tue Nov 03 22:06:19 CET 2009 Ed Schouten <ed@FreeBSD.org> Make /dev/klog and kern.msgbuf* MPSAFE.
Normally msgbufp is locked using Giant. Switch it to use the
msgbuf_lock. Instead of changing the tsleep() calls to msleep(), just
convert it to condvar(9).
In my opinion the locking around msgbuf_peekbytes() still remains
questionable. It looks like locks are dropped while performing copies of
multiple blocks to userspace, which may cause the msgbuf to be reset in
the mean time. At least getting it underneath from Giant should make it
a little easier for us to figure out how to solve that.
Reminded by: rdivacky
|
| /freebsd/sys/kern/ |
| H A D | subr_log.c | diff ca1d2f657ac8942f180f7d1ab328400ae8524bf0 Tue Nov 03 22:06:19 CET 2009 Ed Schouten <ed@FreeBSD.org> Make /dev/klog and kern.msgbuf* MPSAFE.
Normally msgbufp is locked using Giant. Switch it to use the
msgbuf_lock. Instead of changing the tsleep() calls to msleep(), just
convert it to condvar(9).
In my opinion the locking around msgbuf_peekbytes() still remains
questionable. It looks like locks are dropped while performing copies of
multiple blocks to userspace, which may cause the msgbuf to be reset in
the mean time. At least getting it underneath from Giant should make it
a little easier for us to figure out how to solve that.
Reminded by: rdivacky
diff ca1d2f657ac8942f180f7d1ab328400ae8524bf0 Tue Nov 03 22:06:19 CET 2009 Ed Schouten <ed@FreeBSD.org> Make /dev/klog and kern.msgbuf* MPSAFE.
Normally msgbufp is locked using Giant. Switch it to use the
msgbuf_lock. Instead of changing the tsleep() calls to msleep(), just
convert it to condvar(9).
In my opinion the locking around msgbuf_peekbytes() still remains
questionable. It looks like locks are dropped while performing copies of
multiple blocks to userspace, which may cause the msgbuf to be reset in
the mean time. At least getting it underneath from Giant should make it
a little easier for us to figure out how to solve that.
Reminded by: rdivacky
|
| H A D | subr_prf.c | diff ca1d2f657ac8942f180f7d1ab328400ae8524bf0 Tue Nov 03 22:06:19 CET 2009 Ed Schouten <ed@FreeBSD.org> Make /dev/klog and kern.msgbuf* MPSAFE.
Normally msgbufp is locked using Giant. Switch it to use the
msgbuf_lock. Instead of changing the tsleep() calls to msleep(), just
convert it to condvar(9).
In my opinion the locking around msgbuf_peekbytes() still remains
questionable. It looks like locks are dropped while performing copies of
multiple blocks to userspace, which may cause the msgbuf to be reset in
the mean time. At least getting it underneath from Giant should make it
a little easier for us to figure out how to solve that.
Reminded by: rdivacky
diff ca1d2f657ac8942f180f7d1ab328400ae8524bf0 Tue Nov 03 22:06:19 CET 2009 Ed Schouten <ed@FreeBSD.org> Make /dev/klog and kern.msgbuf* MPSAFE.
Normally msgbufp is locked using Giant. Switch it to use the
msgbuf_lock. Instead of changing the tsleep() calls to msleep(), just
convert it to condvar(9).
In my opinion the locking around msgbuf_peekbytes() still remains
questionable. It looks like locks are dropped while performing copies of
multiple blocks to userspace, which may cause the msgbuf to be reset in
the mean time. At least getting it underneath from Giant should make it
a little easier for us to figure out how to solve that.
Reminded by: rdivacky
|