Re: vmspace refcnt refactor patch

2020-05-16 Thread Kamil Rytarowski 
On 16.05.2020 18:52, Nick Hudson wrote:
> 
> On 16/05/2020 12:45, Kamil Rytarowski wrote:
>> On 16.05.2020 07:48, Nick Hudson wrote:
>>> On 15/05/2020 17:35, Kamil Rytarowski wrote:
 I propose the following patch:

 http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt

 Does it look good?

 Nick, does it fix the hppa locking problem?

>>> Thanks for working on this.
>>>
>>> Unfortunately, it doesn't fix all the problems...
>>>
>> Please check this:
>>
>> http://netbsd.org/~kamil/patch-00254-remove-lwp_lock_in_sstep.txt
> 
> I can run the ptrace tests now without triggering LOCKDEBUG asserts.
> 
> 
> Thanks,
> 
> Nick
> 

OK. I'm waiting now for the feedback from Andew before committing.



signature.asc
Description: OpenPGP digital signature

Re: vmspace refcnt refactor patch

2020-05-16 Thread Nick Hudson 



On 16/05/2020 12:45, Kamil Rytarowski wrote:

On 16.05.2020 07:48, Nick Hudson wrote:

On 15/05/2020 17:35, Kamil Rytarowski wrote:

I propose the following patch:

http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt

Does it look good?

Nick, does it fix the hppa locking problem?


Thanks for working on this.

Unfortunately, it doesn't fix all the problems...


Please check this:

http://netbsd.org/~kamil/patch-00254-remove-lwp_lock_in_sstep.txt


I can run the ptrace tests now without triggering LOCKDEBUG asserts.


Thanks,

Nick

Re: vmspace refcnt refactor patch

2020-05-16 Thread Kamil Rytarowski 
On 16.05.2020 07:48, Nick Hudson wrote:
> On 15/05/2020 17:35, Kamil Rytarowski wrote:
>> I propose the following patch:
>>
>> http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt
>>
>> Does it look good?
>>
>> Nick, does it fix the hppa locking problem?
>>
> 
> Thanks for working on this.
> 
> Unfortunately, it doesn't fix all the problems...
> 

Please check this:

http://netbsd.org/~kamil/patch-00254-remove-lwp_lock_in_sstep.txt

In general I don't like the locking model in ptrace(2), but this change
is not making anything worse.

> 
>     setstep1: [ 209.5497837] Mutex error: assert_sleepable,78: spin
> lock held
> 
> [ 209.5497837] lock address : 0x3ffccf00 type :  spin
> [ 209.5497837] initialized  : 0x007d6f78
> [ 209.5497837] shared holds :  0 exclusive: 1
> [ 209.5497837] shares wanted:  0 exclusive: 0
> [ 209.5497837] relevant cpu :  0 last held: 0
> [ 209.5497837] relevant lwp : 0x3fc36d00 last held:
> 0x3fc36d00
> [ 209.5497837] last locked* : 0x0084a760 unlocked :
> 0x007d5134
> [ 209.5497837] owner field  : 0xff10 wait/spin:   0/1
> 
> [ 209.5497837] panic: LOCKDEBUG: Mutex error: assert_sleepable,78: spin
> lock held
> [ 209.5497837] cpu0: Begin traceback...
> [ 209.5497837] vpanic() at netbsd:vpanic+0x1b8
> [ 209.5497837] panic() at netbsd:panic+0x38
> [ 209.5497837] lockdebug_abort1() at netbsd:lockdebug_abort1+0x170
> [ 209.5497837] lockdebug_barrier() at netbsd:lockdebug_barrier+0x114
> [ 209.5497837] assert_sleepable() at netbsd:assert_sleepable+0xa0
> [ 209.5497837] pool_cache_get_paddr() at netbsd:pool_cache_get_paddr+0x254
> [ 209.5497837] uvm_mapent_alloc() at netbsd:uvm_mapent_alloc+0x150
> [ 209.5497837] uvm_map_enter() at netbsd:uvm_map_enter+0x848
> [ 209.5497837] uvm_map() at netbsd:uvm_map+0xd4
> [ 209.5497837] uvm_map_reserve() at netbsd:uvm_map_reserve+0x240
> [ 209.5497837] uvm_map_extract() at netbsd:uvm_map_extract+0x6fc
> [ 209.5497837] uvm_io() at netbsd:uvm_io+0xf8
> [ 209.5497837] process_domem() at netbsd:process_domem+0x94
> [ 209.5497837] ss_get_value() at netbsd:ss_get_value+0x74
> [ 209.5497837] process_sstep() at netbsd:process_sstep+0x74
> [ 209.5497837] do_ptrace() at netbsd:do_ptrace+0xe00
> [ 209.5497837] sys_ptrace() at netbsd:sys_ptrace+0x4c
> [ 209.5497837] syscall() at netbsd:syscall+0x480
> [ 209.5497837] -- syscall #26(7, 141a, 1, 0, ...) (0xd3131000)
> [ 209.5497837] cpu0: End traceback...
> 
> nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
> hppa--netbsd-addr2line -e netbsd.gdb  -f 0x007d6f78
> sched_cpuattach
> /netbsd/hppa/src/sys/kern/kern_runq.c:147
> nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
> hppa--netbsd-addr2line -e netbsd.gdb  -f 0x0084a760
> lwp_lock
> /netbsd/hppa/src/sys/sys/lwp.h:412
> nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
> hppa--netbsd-addr2line -e netbsd.gdb  -f 0x007d5134
> calcru
> /netbsd/hppa/src/sys/kern/kern_resource.c:506 (discriminator 2)
> nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
> 
> Nick





signature.asc
Description: OpenPGP digital signature

Re: vmspace refcnt refactor patch

2020-05-15 Thread Nick Hudson 

On 15/05/2020 17:35, Kamil Rytarowski wrote:

I propose the following patch:

http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt

Does it look good?

Nick, does it fix the hppa locking problem?



Thanks for working on this.

Unfortunately, it doesn't fix all the problems...


setstep1: [ 209.5497837] Mutex error: assert_sleepable,78: spin
lock held

[ 209.5497837] lock address : 0x3ffccf00 type :  spin
[ 209.5497837] initialized  : 0x007d6f78
[ 209.5497837] shared holds :  0 exclusive: 1
[ 209.5497837] shares wanted:  0 exclusive: 0
[ 209.5497837] relevant cpu :  0 last held: 0
[ 209.5497837] relevant lwp : 0x3fc36d00 last held:
0x3fc36d00
[ 209.5497837] last locked* : 0x0084a760 unlocked :
0x007d5134
[ 209.5497837] owner field  : 0xff10 wait/spin:   0/1

[ 209.5497837] panic: LOCKDEBUG: Mutex error: assert_sleepable,78: spin
lock held
[ 209.5497837] cpu0: Begin traceback...
[ 209.5497837] vpanic() at netbsd:vpanic+0x1b8
[ 209.5497837] panic() at netbsd:panic+0x38
[ 209.5497837] lockdebug_abort1() at netbsd:lockdebug_abort1+0x170
[ 209.5497837] lockdebug_barrier() at netbsd:lockdebug_barrier+0x114
[ 209.5497837] assert_sleepable() at netbsd:assert_sleepable+0xa0
[ 209.5497837] pool_cache_get_paddr() at netbsd:pool_cache_get_paddr+0x254
[ 209.5497837] uvm_mapent_alloc() at netbsd:uvm_mapent_alloc+0x150
[ 209.5497837] uvm_map_enter() at netbsd:uvm_map_enter+0x848
[ 209.5497837] uvm_map() at netbsd:uvm_map+0xd4
[ 209.5497837] uvm_map_reserve() at netbsd:uvm_map_reserve+0x240
[ 209.5497837] uvm_map_extract() at netbsd:uvm_map_extract+0x6fc
[ 209.5497837] uvm_io() at netbsd:uvm_io+0xf8
[ 209.5497837] process_domem() at netbsd:process_domem+0x94
[ 209.5497837] ss_get_value() at netbsd:ss_get_value+0x74
[ 209.5497837] process_sstep() at netbsd:process_sstep+0x74
[ 209.5497837] do_ptrace() at netbsd:do_ptrace+0xe00
[ 209.5497837] sys_ptrace() at netbsd:sys_ptrace+0x4c
[ 209.5497837] syscall() at netbsd:syscall+0x480
[ 209.5497837] -- syscall #26(7, 141a, 1, 0, ...) (0xd3131000)
[ 209.5497837] cpu0: End traceback...

nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
hppa--netbsd-addr2line -e netbsd.gdb  -f 0x007d6f78
sched_cpuattach
/netbsd/hppa/src/sys/kern/kern_runq.c:147
nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
hppa--netbsd-addr2line -e netbsd.gdb  -f 0x0084a760
lwp_lock
/netbsd/hppa/src/sys/sys/lwp.h:412
nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$
hppa--netbsd-addr2line -e netbsd.gdb  -f 0x007d5134
calcru
/netbsd/hppa/src/sys/kern/kern_resource.c:506 (discriminator 2)
nick@zoom:/netbsd/hppa/obj.hppa/sys/arch/hppa/compile/GENERIC$

Nick

vmspace refcnt refactor patch

2020-05-15 Thread Kamil Rytarowski 
I propose the following patch:

http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt

Does it look good?

Nick, does it fix the hppa locking problem?



signature.asc
Description: OpenPGP digital signature