Re: NOMMU bogus syscall return values
On 02 Mar 2016 20:28, Rich Felker wrote: > On Thu, Mar 03, 2016 at 04:01:21AM +0300, Dmitry V. Levin wrote: > > On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote: > > > On 29 Feb 2016 15:56, Rich Felker wrote: > > [...] > > > > The attached (very hackish at the moment) patch makes it work for me > > > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone() > > > > with CLONE_VM and a new stack for the child, instead of vfork. I see > > > > some potential issues that need to be addressed before this could be > > > > made into a proper solution, though: > > > > > > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If > > > >so, I think vfork could be dropped completely and this used > > > >instead. > > > > > > uClibc has long required clone, so seems safe to assume it exists > > > > strace assumes that PTRACE_SETOPTIONS works, which essentially means that > > linux kernel >= 2.6 is required. On some architectures, newer kernel is > > required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support). I don't > > know for sure whether all supported NOMMU systems have CLONE_VM, but > > I agree with Mike it seems safe to assume they do. > > I was merely unaware whether strace supported any non-Linux systems. > Linux has had clone/CLONE_VM since basically forever (2.0, maybe > earlier) so if strace is Linux-only this is a non-issue. Should I try > to prepare a patch converting all the forks to clone so that NOMMU is > not a special case? What should be done about daemonized tracer mode? strace used to support more than Linux, but i think since no one has been keeping up other OS's, we just wait for someone to step up. not sure how Dmitry feels about it. we certainly don't do any build/run tests :). -mike signature.asc Description: Digital signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
[GSOC-2016]-Interested to participate.
Hi All, I have been a user of strace since I started my career and I have reaped a lot of benefits from the same. I wanted to contribute to the community as part of GSOC-16. I am interested in working on *Fault injection for syscalls Suggested by: Gabriel Laskar* Background: I am currently doing Masters program in Computer Science at Stony Brook University, USA with focus on Operating Systems and Computer Architecture. Before that, I was working on Network Operating Systems at several companies(4 years). As part of academics/professional work, I have written drivers, Linux Kernel Modules, Stackable File System and Distributed Logging/debug infrastructures. I have also contributed bug-fixes to Tahoe-LAFS(Least Authority File System). Expertise: C, C++ and Python. Github: https://github.com/basukaladagi Can anyone please help me to get started. I wanted to start with a simple bug-fix to get initiated with, but could not find any bug's list. Thank you, Basu -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: NOMMU bogus syscall return values
On Thu, Mar 03, 2016 at 05:16:18AM +0300, Dmitry V. Levin wrote: > On Wed, Mar 02, 2016 at 08:28:30PM -0500, Rich Felker wrote: > > On Thu, Mar 03, 2016 at 04:01:21AM +0300, Dmitry V. Levin wrote: > > > On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote: > > > > On 29 Feb 2016 15:56, Rich Felker wrote: > > > [...] > > > > > The attached (very hackish at the moment) patch makes it work for me > > > > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone() > > > > > with CLONE_VM and a new stack for the child, instead of vfork. I see > > > > > some potential issues that need to be addressed before this could be > > > > > made into a proper solution, though: > > > > > > > > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If > > > > >so, I think vfork could be dropped completely and this used > > > > >instead. > > > > > > > > uClibc has long required clone, so seems safe to assume it exists > > > > > > strace assumes that PTRACE_SETOPTIONS works, which essentially means that > > > linux kernel >= 2.6 is required. On some architectures, newer kernel is > > > required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support). I don't > > > know for sure whether all supported NOMMU systems have CLONE_VM, but > > > I agree with Mike it seems safe to assume they do. > > > > I was merely unaware whether strace supported any non-Linux systems. > > Linux has had clone/CLONE_VM since basically forever (2.0, maybe > > earlier) so if strace is Linux-only this is a non-issue. Should I try > > to prepare a patch converting all the forks to clone so that NOMMU is > > not a special case? > > Yes, the less NOMMU workarounds the better. Sounds good. :) Although I wouldn't call it fewer NOMMU workarounds, just fewer (no) special cases. This technique is still a NOMMU workaround, but one that happens to work without any reduced functionality on normal systems with MMU as well. > > What should be done about daemonized tracer mode? > > If we could switch stack before clone and then switch stack back in the > child process, it would be a relatively simple change. > Otherwise I don't see any simple options. I think it's possible to switch stack in the parent via sigaltstack and raise, after which the cloned child can longjmp back to the stack that was the parent's. Alternatively the child could just re-enter main() on a new stack with a global var set to indicate that it's the tracer child. Rich -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: NOMMU bogus syscall return values
On Wed, Mar 02, 2016 at 08:28:30PM -0500, Rich Felker wrote: > On Thu, Mar 03, 2016 at 04:01:21AM +0300, Dmitry V. Levin wrote: > > On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote: > > > On 29 Feb 2016 15:56, Rich Felker wrote: > > [...] > > > > The attached (very hackish at the moment) patch makes it work for me > > > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone() > > > > with CLONE_VM and a new stack for the child, instead of vfork. I see > > > > some potential issues that need to be addressed before this could be > > > > made into a proper solution, though: > > > > > > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If > > > >so, I think vfork could be dropped completely and this used > > > >instead. > > > > > > uClibc has long required clone, so seems safe to assume it exists > > > > strace assumes that PTRACE_SETOPTIONS works, which essentially means that > > linux kernel >= 2.6 is required. On some architectures, newer kernel is > > required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support). I don't > > know for sure whether all supported NOMMU systems have CLONE_VM, but > > I agree with Mike it seems safe to assume they do. > > I was merely unaware whether strace supported any non-Linux systems. > Linux has had clone/CLONE_VM since basically forever (2.0, maybe > earlier) so if strace is Linux-only this is a non-issue. Should I try > to prepare a patch converting all the forks to clone so that NOMMU is > not a special case? Yes, the less NOMMU workarounds the better. > What should be done about daemonized tracer mode? If we could switch stack before clone and then switch stack back in the child process, it would be a relatively simple change. Otherwise I don't see any simple options. -- ldv pgpiVbPiUECXm.pgp Description: PGP signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: NOMMU bogus syscall return values
On Thu, Mar 03, 2016 at 04:01:21AM +0300, Dmitry V. Levin wrote: > On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote: > > On 29 Feb 2016 15:56, Rich Felker wrote: > [...] > > > The attached (very hackish at the moment) patch makes it work for me > > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone() > > > with CLONE_VM and a new stack for the child, instead of vfork. I see > > > some potential issues that need to be addressed before this could be > > > made into a proper solution, though: > > > > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If > > >so, I think vfork could be dropped completely and this used > > >instead. > > > > uClibc has long required clone, so seems safe to assume it exists > > strace assumes that PTRACE_SETOPTIONS works, which essentially means that > linux kernel >= 2.6 is required. On some architectures, newer kernel is > required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support). I don't > know for sure whether all supported NOMMU systems have CLONE_VM, but > I agree with Mike it seems safe to assume they do. I was merely unaware whether strace supported any non-Linux systems. Linux has had clone/CLONE_VM since basically forever (2.0, maybe earlier) so if strace is Linux-only this is a non-issue. Should I try to prepare a patch converting all the forks to clone so that NOMMU is not a special case? What should be done about daemonized tracer mode? Rich -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH 1/3] tests: add uname.test
On Tue, Mar 01, 2016 at 04:55:25PM +0800, Fei, Jie/费 杰 wrote: > Hi! > > Thanks a lot for your comments. I have modified the patches to V2. Thanks, applied. -- ldv pgprIvQqpygxE.pgp Description: PGP signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: NOMMU bogus syscall return values
On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote: > On 29 Feb 2016 15:56, Rich Felker wrote: [...] > > The attached (very hackish at the moment) patch makes it work for me > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone() > > with CLONE_VM and a new stack for the child, instead of vfork. I see > > some potential issues that need to be addressed before this could be > > made into a proper solution, though: > > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If > >so, I think vfork could be dropped completely and this used > >instead. > > uClibc has long required clone, so seems safe to assume it exists strace assumes that PTRACE_SETOPTIONS works, which essentially means that linux kernel >= 2.6 is required. On some architectures, newer kernel is required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support). I don't know for sure whether all supported NOMMU systems have CLONE_VM, but I agree with Mike it seems safe to assume they do. -- ldv pgpg2oE82hw4f.pgp Description: PGP signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: Working on -e trace
On Wed, Mar 02, 2016 at 10:45:53AM +0530, haris iqbal wrote: [...] > A little help is needed here. I could understand that for the -e > option, one uses the combination of sysent_vec[][].sys_flags and the > macros TRACE_FILE and others, which sets the proper flag in qual_vec. > Now that qual_vec is used by qual_flg in the tcb struct (correct me if > something is wrong). > > But what I could not find is where those flag is used to print only > the syscalls that are needed (like only file related). I searched and > followed the flow of execution and found trace_syscall_entering() > through trace_syscall() in trace(). There is a function calles > get_scno(), I guess its where this syscall filtering is happening but > not sure. Can someone please point me in the right direction. tcp->qual_flg is initialized from qual_flags[tcp->scno] in get_scno() and later tested for QUAL_TRACE flag in trace_syscall_entering(). > NOTE: > > 1) I am looking at the -e option closely to come up with a POC for the > idea "Fault injection for syscalls". > > 2) Waiting for a reply for the naming policy so that I can start > working to add the sched_* and the *uid *gid ones to the -e option. You can start with some naming policy, e.g. %sched, %uid, and %gid. I suppose a patch might attract more comments than a general discussion on the subject. -- ldv pgpv_z1nWsZwT.pgp Description: PGP signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: A potential bug to squeeze extra memory through command line arguments
On Tue, Mar 01, 2016 at 03:46:12PM +0530, haris iqbal wrote: > On Tue, Mar 1, 2016 at 2:01 PM, Dmitry V. Levin wrote: > > On Tue, Mar 01, 2016 at 10:08:16AM +0530, haris iqbal wrote: > >> On Tue, Mar 1, 2016 at 5:09 AM, Dmitry V. Levin wrote: > >> > > >> > On Wed, Feb 24, 2016 at 06:02:01PM +0530, haris iqbal wrote: > >> > [...] > >> > > Ok. I have come up with a separate memory model for tcbtab. In this > >> > > model, we will use a linked list instead of a global array of pointers > >> > > tcbtab. > >> > > > >> > > The structure > >> > > > >> > > struct s_tcbtab > >> > > { > >> > > struct tcb* data; > >> > > struct s_tcbtab* next; > >> > > } > >> > > > >> > > And a global head of the linked list. > >> > > > >> > > struct s_tcbtab* head_tcbtab = NULL; > >> > > >> > I suppose this memory model is better for some use cases and worse for > >> > some other use cases. > >> > What kind of strace usage would win/lose from this change? > >> > >> quick question. How many pids can we give with the -p option? > > > > It depends on the maximum length of the arguments to execve(2), > > which varies between systems. > > One disadvantage I can think of in when there are a substantial number > of pids with the -p option. Then the new proposed model would iterate > over the linked list till the end while allocating a struct for every > pid. Thus the time taken for n pids would be (n * ( n + 1)) / 2. > > The same case would happen with the older model also. But the > difference would be, the older one using an array (thus branch > prediction would help, and linear access of memory being an > advantage), and the newer model would be using linked list thus would > be slower. But I think there won't be a visible time difference for a > few pids with the -p option. > > Is there any other disadvantage for the newer model that I missed? The only advantage of the linked list model seems to be memory footprint since it doesn't allocate memory in advance, however, memory fragmentation might easily negate this effect. Iteration is going to be slower, and strace iterates a lot via pid2tcb(), so a switch to this model would result to a measurable performance regression. -- ldv pgpj4VCRA7PLM.pgp Description: PGP signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: [PATCH v3] Reduce memory waste while managing tcbs
On Tue, Mar 01, 2016 at 07:38:00PM +0100, Nahim El Atmani wrote: > * strace.c: alloctcb() when no tcbs are available (first call and subsequent > calls when tcbtab is full) call expand_tcbtab(). Now, expand_tcbtab() allocate > the minimum required amount of memory to create the tcbtab if needed and > expend > otherwise instead of relying on the preallocation of a large amount of tcbs > and expand if needed. Now that the patch is almost ready, it's time to comment this commit message. The requirement is that after a summary and optional few lines of text describing the change goes a ChangeLog-style entry (described in detail e.g. at https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html) For example, a ChangeLog-style entry might be something like this: * strace.c (expand_tcbtab): Do initial memory allocation when tcbtabsize == 0. (init): Remove initial memory allocation for tcbtab. > - unsigned int i = tcbtabsize; > - struct tcb *newtcbs = xcalloc(tcbtabsize, sizeof(newtcbs[0])); > - struct tcb **newtab = xreallocarray(tcbtab, tcbtabsize * 2, > - sizeof(tcbtab[0])); > - tcbtabsize *= 2; > + unsigned int i, new_tcbtabsize, alloc_tcbtabsize; > + struct tcb *newtcbs; > + struct tcb **newtab; > + > + if (tcbtabsize) { > + alloc_tcbtabsize = tcbtabsize; > + new_tcbtabsize = tcbtabsize * 2; > + } else { > + new_tcbtabsize = alloc_tcbtabsize = 1; > + } > + > + i = tcbtabsize; > + newtcbs = xcalloc(alloc_tcbtabsize, sizeof(newtcbs[0])); > + newtab = xreallocarray(tcbtab, new_tcbtabsize, sizeof(tcbtab[0])); > + tcbtabsize = new_tcbtabsize; > tcbtab = newtab; > while (i < tcbtabsize) > tcbtab[i++] = newtcbs++; You can safely get rid of newtab, it is no longer needed after commit v4.10-75-g3e9d71f. Unfortunately, I missed the opportunity to eliminate it along with that commit. You can also write this code without using "i" if you like, e.g. newtcbs = xcalloc(alloc_tcbtabsize, sizeof(newtcbs[0])); tcbtab = xreallocarray(tcbtab, new_tcbtabsize, sizeof(tcbtab[0])); while (tcbtabsize < new_tcbtabsize) tcbtab[tcbtabsize++] = newtcbs++; -- ldv pgpTUP7SDWUIK.pgp Description: PGP signature -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: GSOC 2016 - Comprehensive test suite Project
Hi, On Wed, 02 Mar 2016 22:53:44 +0300 Anchit Jain wrote: > I was hoping if anyone could please guide me and suggest material to > read/ issues to fix. You can start by sending a small fix, for example add a test for an untested syscall. -- Gabriel Laskar -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
GSOC 2016 - Comprehensive test suite Project
Hi everyone, I am Anchit Jain, Computer Science undergraduate from BITS PILANI, India. I am interested in pursuing **Comprehensive test suite** project. I am fluent in C and Python. Some of my previous work could be seen at [https://github.com/anchitjain1234](https://link.nylas.com/link/ezhvubksgc7dhi 29sglp2mpvq/70dde818a7724fb2b1bd012bf27e0442/0?redirect=https%3A%2F%2Fgithub.c om%2Fanchitjain1234). I am very much interested in this project as it would really help me in getting to know about internals of various syscalls, decide and differentiate between them and which to prefer where. I was hoping if anyone could please guide me and suggest material to read/ issues to fix. Thanks, Anchit Jain [](https://link.nylas.com/link/ezhvubksgc7dhi29sglp2mpvq/70dde818a7724fb2b1bd0 12bf27e0442/1?redirect=https%3A%2F%2Fgithub.com%2Fanchitjain1234) ![](https://link.nylas.com/open/ezhvubksgc7dhi29sglp2mpvq/8623fdeef7504da2b7bb c39e27e2062c) -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
GSOC - Introducing myself.
Hi I’m I’m looking forward to contributing to strace development. I’m familiar with systems programming, syscalls, and OS, esp. linux so I was wondering where would I begin if I were to start by familiarising my self with the codebase, fixing a few bugs, etc. My GitHub is at http://github.com/5hubh4m if anyone wants to see my past projects. Thank you. ~Shubham -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
Re: GSOC information regarding project
On Tue, Mar 1, 2016 at 8:45 PM, Naveen Kumar wrote: > my name is naveen, i am good at system programming and have decent > knowledge of kernel , i would like to contribute in Netlink socket > parsers Suggested by: Gabriel Laskar Hi Naveen and welcome to strace! I assume that you are talking about a contribution in the context of the Google Summer of Code, right? So tell us what you have in mind there. How would you go about it? Do you have some public code of yours on some public repos that show some of your code? -- Cordially Philippe Ombredanne -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel