[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PATCH: Small fix in gnumach
From: |
gfleury |
Subject: |
Re: PATCH: Small fix in gnumach |
Date: |
Sat, 14 Mar 2020 17:36:52 +0000 |
14 mars 2020 17:54 "Samuel Thibault" <samuel.thibault@gnu.org> a écrit:
> Hello,
>
> 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.
>
This sound reasonable.
> Did you actually see it happen, or was it found just while reading the
> code?
i found it while reading code!
>
> Samuel