bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]