The FRELE() macro described in file(9) as void FRELE(), but actually
it has return value and it's return value is used by closef().
Index: share/man/man9/file.9
===
RCS file: /home/cvsync/openbsd-cvs/src/share/man/man9/file.9,v
FREF() and FRELE() should be used for modify file reference count, so
direct f_count modification replaced by their calls. Only one direct f_count
decrement was kept in closef() since FRELE() call looks inapplicable here.
Index: kern/kern_descrip.c
On 17 Apr 2015, at 12:49, Martin Pieuchot m...@openbsd.org wrote:
On 16/04/15(Thu) 15:24, kanonenvogel@gmail.com wrote:
Well, lets begin.
In the future, I wish to have fd_getfile() returning acquired fp instance.
The goal is to not to have pointer to destroyed fp instance
in FREF
Well, lets begin.
In the future, I wish to have fd_getfile() returning acquired fp instance.
The goal is to not to have pointer to destroyed fp instance
in FREF()/FRELE()/fd_getfile() races. This one requres modification of
getsock(), getvnode() and dupfdopen() functions, they must receive
On 15 Apr 2015, at 19:45, Mike Belopuhov m...@belopuhov.com wrote:
On 15 April 2015 at 13:29, kanonenvogel@gmail.com
kanonenvogel@gmail.com wrote:
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put
Well, I’ve put /usr/src/sys subtree from 5.7 with my patches on guthub.
I would really like to get it more traction on that.
https://github.com/Kanonenvogel/openbsd-sys-5.7-smp
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe and not protected by KERNEL_LOCK() calls.
On 12 Apr 2015, at 21:02, Martin Pieuchot m...@openbsd.org wrote:
It's only PoF just for to show my hypothetical roadmap.
Can you explain what need to be protected from what?
1. Filelist, nfiles and operations with them are protected by rwlock.
Why not, could you describe why they need a
This is the second attempt of struct file protection.
1. Filelist, nfiles and operations with them are protected by rwlock.
2. Garbage collector's flags FIF_MARK and FIF_DEFER moved from f_iflags to
new field f_gc_flags (compatibility with pstat was kept).
3. Operations over f_iflags are atomic.
Struct file again.
f_flag isn’t modified often, so it’s modifacation can be atomic.
f_msgcount and f_rxfer, f_wxfer, f_seek, f_rbytes, f_wbytes can be protected by
rwlock.
f_offset protection is actual for vnodes only.
FIF_MARK and FIF_DEFER flags are used only by unpc garbage collector. This
On 08 Apr 2015, at 02:31, Philip Guenther guent...@gmail.com wrote:
On Tue, Apr 7, 2015 at 3:57 PM, Kanonenvogel kanonenvogel@gmail.com
wrote:
I have idea to modify falloc() function and related logic.
Now, after successful faclloc call, we have half-initialized struct file
object
On 08 Apr 2015, at 17:33, kanonenvogel@gmail.com wrote:
Is it a good idea?
bad idea because of sys_pread
On 08 Apr 2015, at 17:33, kanonenvogel@gmail.com wrote:
Is it a good idea?
bad idea because of sys_pread/sys_pwrite
On 08 Apr 2015, at 15:03, Ted Unangst t...@tedunangst.com wrote:
The atomic functions are quite expensive on
some architectures, so we don't want to just use them everywhere.
So, rwlock is better here?
Also, can you explain this lines from finishdup() function (openbsd-5., file
On 08 Apr 2015, at 15:03, Ted Unangst t...@tedunangst.com wrote:
Also, this only helps if you're sure that the code reading the flag will do so
in an smp safe way. In many cases, the reading code will also need to acquire
a lock in order to correctly do something after reading the flag. From
Hello.
I have idea to modify falloc() function and related logic.
Now, after successful faclloc call, we have half-initialized struct file
object, protected by FIF_LARVAL flag.
I want to initialise struct file object within falloc() and then put it to
fd_ofiles array and filehead list. This
16 matches
Mail list logo
