On Mon, 7 May 2018 13:51:21 +0530 Ravi Bangoria <ravi.bangoria@xxxxxxxxxxxxx> wrote: > Hi Masami, > > On 05/04/2018 07:51 PM, Ravi Bangoria wrote: > > > >>> +} > >>> + > >>> +static void sdt_increment_ref_ctr(struct trace_uprobe *tu) > >>> +{ > >>> + struct uprobe_map_info *info; > >>> + > >>> + uprobe_down_write_dup_mmap(); > >>> + info = uprobe_build_map_info(tu->inode->i_mapping, > >>> + tu->ref_ctr_offset, false); > >>> + if (IS_ERR(info)) > >>> + goto out; > >>> + > >>> + while (info) { > >>> + down_write(&info->mm->mmap_sem); > >>> + > >>> + if (sdt_find_vma(tu, info->mm, info->vaddr)) > >>> + sdt_update_ref_ctr(info->mm, info->vaddr, 1); > >> Don't you have to handle the error to map pages here? > > Correct.. I think, I've to feedback error code to probe_event_{enable|disable} > > and handler failure there. > > I looked at this. Actually, It looks difficult to feedback errors to > probe_event_{enable|disable}, esp. in the mmap() case. Hmm, can't you roll that back if sdt_increment_ref_ctr() fails? If so, how does sdt_decrement_ref_ctr() work in that case? > Is it fine if we just warn sdt_update_ref_ctr() failures in dmesg? I'm > doing this in [PATCH 7]. (Though, it makes more sense to do that in > [PATCH 6], will change it in next version). Of course we need to warn it at least, but the best is rejecting to enable it. > > Any better ideas? > > BTW, same issue exists for normal uprobe. If uprobe_mmap() fails, > there is no feedback to trace_uprobe and no warnigns in dmesg as > well !! There was a patch by Naveen to warn such failures in dmesg > but that didn't go in: https://lkml.org/lkml/2017/9/22/155 Oops, that's a real bug. It seems the ball is in Naveen's hand. Naveen, could you update it according to Oleg's comment, and resend it? > > Also, I'll add a check in sdt_update_ref_ctr() to make sure reference > counter never goes to negative incase increment fails but decrement > succeeds. OTOH, if increment succeeds but decrement fails, the > counter remains >0 but there is no harm as such, except we will > execute some unnecessary code. I see. Please carefully clarify whether such case is kernel's bug or not. I would like to know what the condition causes that uneven behavior. Thank you, > > Thanks, > Ravi > -- Masami Hiramatsu <mhiramat@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html