> On Mar 15, 2019, at 2:48 PM, Robert Elz wrote:
> Upon reflection, there is no hurry to fix this one, unlike the previous
> one which was screwing up the b5 tests - we (at least currently) have no
> tests which do anything as crazy as the code sequence to trigger this, so
> we can take our
> On Mar 15, 2019, at 2:56 PM, Robert Elz wrote:
>
> Actually, on a bit more reflection, perhaps the best way forward
> is to work out a better method of implementing the shm() stuff
> puerly out of uvm facilities (with minimal, less than is there now,
> extra data structs) - so
Actually, on a bit more reflection, perhaps the best way forward
is to work out a better method of implementing the shm() stuff
puerly out of uvm facilities (with minimal, less than is there now,
extra data structs) - so shmctl(SHM_LOCK) is just mlock() but perhaps
with an extra parameter to the
Date:Fri, 15 Mar 2019 13:28:32 -0700
From:Jason Thorpe
Message-ID:
| Careful, Robert, you're going to end up the designated maintainer
| of UVM at this rate :-)
Not if I can find someone else to palm it off onto ...
Upon reflection, there is no hurry to fix
> On Mar 15, 2019, at 1:28 PM, Jason Thorpe wrote:
>
> bool
> uvm_map_entry_wiring_changed(
Minor nit... in retrospect, this function should be called
uvm_map_entry_wiring_will_change().
-- thorpej
Careful, Robert, you're going to end up the designated maintainer of UVM at
this rate :-)
> On Mar 15, 2019, at 12:11 PM, Robert Elz wrote:
>
> However, the relationship between the shm() functions and the uvm
> (m*() functions) looks to be something of a mess - we really cannot keep
> a state
Kamil sent me a pointer to this ...
https://syzkaller.appspot.com/bug?id=71f9271d761f5b6ed517a18030dc04f0135e6179
That's a syzkaller generated test that is triggering the new KASSERT()
added to detect the (lower layer) wired count on a pmap entry underflowing
(going from 0 to 65535).
They also
