On Fri, Feb 04, 2022 at 01:37:41PM -0300, Martin Pieuchot wrote:
> On 04/02/22(Fri) 03:39, Klemens Nanni wrote:
> > [...]
> > ... with the lock grabbed in uvm_map_teardown() that is, otherwise
> > the first call path can lock against itself (regress/misc/posixtestsuite
> > is a reproduce for this)
On 04/02/22(Fri) 03:39, Klemens Nanni wrote:
> [...]
> ... with the lock grabbed in uvm_map_teardown() that is, otherwise
> the first call path can lock against itself (regress/misc/posixtestsuite
> is a reproduce for this):
>
> vm_map_lock_read_ln+0x38
> uvm_fault_unwire+0x58
>
On Thu, Feb 03, 2022 at 04:49:26PM +, Klemens Nanni wrote:
> On Mon, Jan 31, 2022 at 11:11:25AM -0300, Martin Pieuchot wrote:
> > On 31/01/22(Mon) 10:24, Klemens Nanni wrote:
> > > Running with my uvm assert diff showed that uvm_fault_unwire_locked()
> > > was called without any locks held.
> >
On Mon, Jan 31, 2022 at 11:11:25AM -0300, Martin Pieuchot wrote:
> On 31/01/22(Mon) 10:24, Klemens Nanni wrote:
> > Running with my uvm assert diff showed that uvm_fault_unwire_locked()
> > was called without any locks held.
> >
> > This happened when I rebooted my machine:
> >
> > uvm_fault_
On 31/01/22(Mon) 10:24, Klemens Nanni wrote:
> Running with my uvm assert diff showed that uvm_fault_unwire_locked()
> was called without any locks held.
>
> This happened when I rebooted my machine:
>
> uvm_fault_unwire_locked()
> uvm_unmap_kill_entry_withlock()
> uvm_unmap_kil
Running with my uvm assert diff showed that uvm_fault_unwire_locked()
was called without any locks held.
This happened when I rebooted my machine:
uvm_fault_unwire_locked()
uvm_unmap_kill_entry_withlock()
uvm_unmap_kill_entry()
uvm_map_teardown()
uvmspace_f
