[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: Small fix in gnumach

From: Samuel Thibault
Subject: Re: PATCH: Small fix in gnumach
Date: Sat, 14 Mar 2020 16:54:33 +0100
User-agent: NeoMutt/20170609 (1.8.3)


BTW it seems your mailer attaches .patch files as
application/octet-stream, you should teach it to attach it as plain
text so it shows up as such in readers' mailers.

gfleury@disroot.org, le sam. 14 mars 2020 08:11:33 +0000, a ecrit:
> > In the case of failure, you also need to release the new_memory_object
> > allocated above. I guess that the src_object->ref_count taken above
> > needs to be released as well.
> >
> see update patch does make sense. 

It makes sense but there are still an issue: ref_count++ has to be
protected somehow against concurrency. I guess vm_object_lock needs to
be held on src_object around it.

That being said, KERN_FAILURE is not very talkative for users, so I
looked for what conditions would lead to a failure here. vm_object_enter
only returns VM_OBJECT_NULL when the passed object is not a VM object.
I happens that it's not supposed to happen: vm_object_enter's parameter
is the new_memory_object, which was created just above, so can't
actually not have the proper type. So instead of trying to cope with
it silently and propagate an undecipherable error to userland, it'd be
better to add an assert(new_object) object here, so that in case it does
happen, we get to have an idea where the issue comes from exactly.

Did you actually see it happen, or was it found just while reading the


reply via email to

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