bug-hurd
[Top][All Lists]
Advanced

[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" <address@hidden> 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.
> 
> address@hidden, 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



reply via email to

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