LWN: Comments on "An introduction to KProbes" https://lwn.net/Articles/132196/ This is a special feed containing comments posted to the individual LWN article titled "An introduction to KProbes". en-us Fri, 24 Oct 2025 12:31:11 +0000 Fri, 24 Oct 2025 12:31:11 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net An introduction to KProbes https://lwn.net/Articles/843546/ https://lwn.net/Articles/843546/ SandeshKa <div class="FormattedComment"> A great article.<br> </div> Fri, 22 Jan 2021 11:59:29 +0000 An introduction to KProbes https://lwn.net/Articles/772536/ https://lwn.net/Articles/772536/ rkv <div class="FormattedComment"> Are you able to copy_from_user within a jprobe entry handler (where you have access to the system call's arguments)? If not, are there any techniques to bypass this restriction (ie. disabling interrupts) or another way to get memory from userspace while in this context?<br> </div> Mon, 19 Nov 2018 19:22:45 +0000 An introduction to KProbes https://lwn.net/Articles/702472/ https://lwn.net/Articles/702472/ rvk <div class="FormattedComment"> Great article! Regarding "To avoid this problem, preemption is disabled when probes are handled.", to save the function parameters from a jprobe handler and use them in a kretprobe does this mean that the kretprobe handle is guaranteed to always be called right after the jprobe handler, without any interruption? Ie. Register a jprobe(sys_symlink) -&gt; handle_pre_symlink and a kretprobe(sys_symlink) -&gt; handle_post_symlink. If not, is it possible to match a jprobe handler to a kretprobe handler?<br> <p> jprobe 1<br> jprobe 2<br> kretprobe 2<br> kretprobe 1<br> </div> Mon, 03 Oct 2016 16:59:20 +0000 Too long... https://lwn.net/Articles/133644/ https://lwn.net/Articles/133644/ daniel "Thorough as it might be, this article is simply too long for LWN"<br> <p> I don't agree. If an article needs to be long in order to cover the subject in the depth LWN readers have come to expect and appreciate, then so be it. If your attention span is shorter than the article, just move on to the next article, it's your choice.<br> <p> Regards,<br> <p> Daniel<br> Tue, 26 Apr 2005 18:57:46 +0000 Too long... https://lwn.net/Articles/133365/ https://lwn.net/Articles/133365/ pkolloch I don't agree. I think that is a question of personal preference. I am not familiar with the kernel (and least not with implementation details). Still, I very much prefer to superificially glance over an in-depth article than reading a superficial article in depth.<br> Sun, 24 Apr 2005 11:50:50 +0000 Too long... https://lwn.net/Articles/133296/ https://lwn.net/Articles/133296/ lolster On the one hand I have to agree with you. On the other hand LWN's kernel page usually assumes the reader is quite familiar with the Linux kernel's source - just without saying so.<br> Fri, 22 Apr 2005 23:30:47 +0000 Too long... https://lwn.net/Articles/133233/ https://lwn.net/Articles/133233/ mmutz Thorough as it might be, this article is simply too long for LWN. It would <br> have been better placed on developerworks. An article that starts with <br> "This is article assumes that you are familiar with..." doesn't belong in <br> LWN, IMO. <br> <br> Note: I didn't say the article was bad or something. All I say is that it <br> appeared in the wrong publication. <br> <br> Marc <br> <br> Fri, 22 Apr 2005 16:16:38 +0000 An introduction to KProbes https://lwn.net/Articles/133231/ https://lwn.net/Articles/133231/ melevittfl So, which part of SCO's SVR4 was this taken from then? (JOKE)<br> <p> <p> Fri, 22 Apr 2005 16:11:23 +0000 Wow. https://lwn.net/Articles/133112/ https://lwn.net/Articles/133112/ munozga I second that Wow. Great article, especially considering it's Sudhanshu's first tech article.<br> Thu, 21 Apr 2005 22:12:12 +0000 Wow. https://lwn.net/Articles/133104/ https://lwn.net/Articles/133104/ ncm What a remarkably thorough article.<br> Thu, 21 Apr 2005 20:35:02 +0000