History log of /openbsd/sys/tmpfs/tmpfs.h (Results 1 – 10 of 10)
Revision Date Author Comments
# 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 ...