Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)
From: Masami Hiramatsu <mhiramat@kernel.org>
Date: 2018-05-07 15:56:58
Also in:
linux-mm, lkml
On Mon, 7 May 2018 13:51:21 +0530 Ravi Bangoria [off-list ref] wrote:
Hi Masami, On 05/04/2018 07:51 PM, Ravi Bangoria wrote:quoted
quoted
quoted
+} + +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 [off-list ref] -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html