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
=
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
re
On 17 Apr 2015, at 12:49, Martin Pieuchot 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
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 pointer
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 15 Apr 2015, at 19:45, Mike Belopuhov wrote:
> On 15 April 2015 at 13:29, kanonenvogel@gmail.com
> wrote:
>>
>> On 14 Apr 2015, at 18:35, Mike Belopuhov wrote:
>>>
>>> Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore
On 14 Apr 2015, at 18:35, Mike Belopuhov 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 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 lock? A dif
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. F
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
f
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 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 the
> diff context
On 08 Apr 2015, at 15:03, Ted Unangst 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
kern/kern_descrip.c, lines 576-
On 08 Apr 2015, at 02:31, Philip Guenther wrote:
> On Tue, Apr 7, 2015 at 3:57 PM, Kanonenvogel
> wrote:
>> I have idea to modify falloc() function and related logic.
>> Now, after successful faclloc call, we have half-initialized struct file
>> object, protected
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 modi
16 matches
Mail list logo
