Diff below brings back the fix for the deadlock between uvn_io() and
uvn_flush() (uvm/uvm_vnode.c r1.110) that doesn't introduces a lock
ordering issue with the inode lock.
This solution makes a thread return VM_PAGER_AGAIN and restart the fault
if there's some contention on the underlying vnode.
> but please wait with putting in further diffs until Theo has started
> building snaps
That is very important: continual community testing of snapshot kernels
is incredibly important, otherwise layers of related commits can happen,
and it becomes harder to diagnose introduced problems.
> Date: Fri, 1 Oct 2021 20:07:20 +0200
> From: Martin Pieuchot
>
> amaps operation are already serialized by their own lock so it is
> possible to free them w/o holding the KERNEL_LOCK(). This has been
> tested by many as part of the UVM unlocking diff.
>
> ok?
ok kettenis@
but please wait wi
> Date: Fri, 1 Oct 2021 20:10:35 +0200
> From: Martin Pieuchot
>
> Diff below turns i386's pmap_collect() into a noop like it is on
> amd64/arm64/powerpc64... This is part of the UVM unlocking diff and
> might no longer be necessary now that pmap_extract() has been fixed.
I think it is no longe
Diff below turns i386's pmap_collect() into a noop like it is on
amd64/arm64/powerpc64... This is part of the UVM unlocking diff and
might no longer be necessary now that pmap_extract() has been fixed.
So I'd like to know if we want to align i386's behavior with other
archs, which should help us
amaps operation are already serialized by their own lock so it is
possible to free them w/o holding the KERNEL_LOCK(). This has been
tested by many as part of the UVM unlocking diff.
ok?
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/s
Dear Chicken Little -
We would appreciate if you learn to actually read before yelling about
the sky falling.
The alert is not about spectre, meltdown, or foreshadow.
The report is not about hurricanes, forest fires, salmonena in the spinach,
or cancer-causing chemicals in the chicken-feed eithe
Hello tech@,
After spectre, meltdown and foreshadow, sounds like speculative attacks
are to come in a next future. Today i just came through that bulletin from
AMD:
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1009
Details of the Attack there :
https://zeroperil.co.uk/wp-conten
Right now ober_oid_cmp has inverted logic compared to other *cmp
functions. Specifically values greater than 0 are returned when
a is smaller than b.
Additionally, the value of 2 is only used b is a child of a, but
-1 is returned when a is a child of b.
This makes it harder than needed to use it w
On Fri, Oct 1, 2021, at 09:44, Stuart Henderson wrote:
> On 2021/10/01 14:43, Stuart Henderson wrote:
>> On 2021/10/01 09:29, abyx...@mnetic.ch wrote:
>> > I'm getting a daily crash (call to fatalx). No clue what triggers it and
>> > the logging is really sparse. I couldn't follow what the code in
On 2021/10/01 14:43, Stuart Henderson wrote:
> On 2021/10/01 09:29, abyx...@mnetic.ch wrote:
> > I'm getting a daily crash (call to fatalx). No clue what triggers it and
> > the logging is really sparse. I couldn't follow what the code in ca.c is
> > actually doing (what the hash belongs to that
On 2021/10/01 09:29, abyx...@mnetic.ch wrote:
> I'm getting a daily crash (call to fatalx). No clue what triggers it and the
> logging is really sparse. I couldn't follow what the code in ca.c is actually
> doing (what the hash belongs to that is triggering the crash). A snip from
> /var/log/dae
I'm getting a daily crash (call to fatalx). No clue what triggers it and the
logging is really sparse. I couldn't follow what the code in ca.c is actually
doing (what the hash belongs to that is triggering the crash). A snip from
/var/log/daemon is reproduced below. There are no other log messag
13 matches
Mail list logo
