[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3 gnumach] vm_map: Fix deadlock in vm code
From: |
Samuel Thibault |
Subject: |
Re: [PATCH 1/3 gnumach] vm_map: Fix deadlock in vm code |
Date: |
Sun, 17 Mar 2024 15:34:26 +0100 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Hello,
Thanks for your answers,
Sergey Bugaev, le mer. 21 févr. 2024 22:22:32 +0300, a ecrit:
> On Wed, Feb 21, 2024 at 9:44 PM Samuel Thibault <samuel.thibault@gnu.org>
> wrote:
> > > + *
> > > * HACK HACK HACK HACK
> > > */
> > > if (vm_map_pmap(map) == kernel_pmap) {
> > > + /*
> > > + * TODO: Support wiring more than one entry
> > > + * in the kernel map at a time.
> > > + */
> > > + assert(start->vme_next == end);
> >
> > Are we sure that this currently is never to happen?
>
> Not really. I don't expect the kernel to do this anywhere, but I don't
> know for sure. Please try running some complex workloads with this
> patch, and see if you catch this being not so?
>
> There isn't anything fundamentally incompatible with supporting
> multi-entry wiring here, I just didn't want to do an alloca.
IIRC it was discussed on IRC that there can be two entries, so it'd need
to be improved at least a bit anyway?
Alloca by itself is not a problem, provided that we know that the
possible sizes are bounded.
(I'm still waiting for this before being able to add an -smp variant
package in Debian for people to try it out at least a bit)
Samuel
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 1/3 gnumach] vm_map: Fix deadlock in vm code,
Samuel Thibault <=