#
99ef5f49 |
| 12-Oct-2020 |
visa <visa@openbsd.org> |
Fix build of tmpfs
The breakage was caused by the removal of #include <sys/systm.h> from <uvm/uvm_map.h>.
OK deraadt@, mpi@, beck@
|
#
6bd4f7ca |
| 21-Jan-2019 |
anton <anton@openbsd.org> |
Introduce a dedicated entry point data structure for file locks. This new data structure allows for better tracking of pending lock operations which is essential in order to prevent a use-after-free
Introduce a dedicated entry point data structure for file locks. This new data structure allows for better tracking of pending lock operations which is essential in order to prevent a use-after-free once the underlying vnode is gone.
Inspired by the lockf implementation in FreeBSD.
ok visa@
Reported-by: syzbot+d5540a236382f50f1dac@syzkaller.appspotmail.com
show more ...
|
#
26b8ec94 |
| 19-Jun-2016 |
natano <natano@openbsd.org> |
Remove the lockmgr() API. It is only used by filesystems, where it is a trivial change to use rrw locks instead. All it needs is LK_* defines for the RW_* flags.
tested by naddy and sthen on package
Remove the lockmgr() API. It is only used by filesystems, where it is a trivial change to use rrw locks instead. All it needs is LK_* defines for the RW_* flags.
tested by naddy and sthen on package building infrastructure input and ok jmc mpi tedu
show more ...
|
#
03d1830d |
| 17-Dec-2014 |
tedu <tedu@openbsd.org> |
remove lock.h from uvm_extern.h. another holdover from the simpletonlock era. fix uvm including c files to include lock.h or atomic.h as necessary. ok deraadt
|
#
fde894e5 |
| 16-Dec-2014 |
tedu <tedu@openbsd.org> |
primary change: move uvm_vnode out of vnode, keeping only a pointer. objective: vnode.h doesn't include uvm_extern.h anymore. followup changes: include uvm_extern.h or lock.h where necessary. ok and
primary change: move uvm_vnode out of vnode, keeping only a pointer. objective: vnode.h doesn't include uvm_extern.h anymore. followup changes: include uvm_extern.h or lock.h where necessary. ok and help from deraadt
show more ...
|
#
57331246 |
| 14-Dec-2013 |
espie <espie@openbsd.org> |
bring in a few improvements from pedro, guenther, me...
thanks to krw@ for the original cherry-picking, millert@ for useful comment.
so: - no longer expose internal kernel addresses, uses seq numbe
bring in a few improvements from pedro, guenther, me...
thanks to krw@ for the original cherry-picking, millert@ for useful comment.
so: - no longer expose internal kernel addresses, uses seq numbers instead - make sure the numbers don't overflow (millert@ UINT64_MAX)... a conservative estimate is that tmpfs will run out of seqs in >600 years... - don't malloc dents, put them on the stack and zero them - gc whiteout code - gc getpage/putpage code (shrink uvm instead)
okay krw@, millert@
show more ...
|
#
3544b002 |
| 22-Sep-2013 |
guenther <guenther@openbsd.org> |
The readdir vop should set uio_offset to the cookie of the entry after the last entry that fit, but I had it setting it to the cookier of the entry after that, so it would skip one entry for each blo
The readdir vop should set uio_offset to the cookie of the entry after the last entry that fit, but I had it setting it to the cookier of the entry after that, so it would skip one entry for each block required.
Remove the no-longer-needed cnt/cntp variable while we're touching things.
prodding and testing by espie@
show more ...
|
#
9d2ad5b0 |
| 04-Jun-2013 |
espie <espie@openbsd.org> |
fix include guard locations (from pedro)
|
#
5b25c3e7 |
| 03-Jun-2013 |
espie <espie@openbsd.org> |
sprinkle $OpenBSD$, pointed out by pedro
|
#
7013b092 |
| 01-Jun-2013 |
espie <espie@openbsd.org> |
import tmpfs code, originally from netbsd. heavy lifting by Pedro Martelletto, timestamp fixes by me.
THIS IS NOT ENABLED YET, AND REQUIRES UVM CHANGES AND REVIEW. Imported, so that working on it ca
import tmpfs code, originally from netbsd. heavy lifting by Pedro Martelletto, timestamp fixes by me.
THIS IS NOT ENABLED YET, AND REQUIRES UVM CHANGES AND REVIEW. Imported, so that working on it can be mostly done in tree with less painful diff exchanges, and that we have history of further changes.
okay tedu@, deraadt@
show more ...
|