14 mars 2020 17:54 "Samuel Thibault" <samuel.thiba...@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. > > 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. > 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
