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.
gfle...@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 code? Samuel
