On Thu, 11 Aug 2016 05:42:52 +0300, Dmitry V. Levin wrote:
> Date: Thu, 11 Aug 2016 05:42:52 +0300
> From: "Dmitry V. Levin" <l...@altlinux.org>
> To: strace-devel@lists.sourceforge.net
> Subject: Re: [PATCH 3/4] Introduce syscall fault injection feature
> Message-ID: <20160811024252.ge22...@altlinux.org>
> In-Reply-To: <20160810203148.snk4jm6pd3h35cf6@Bane>
> List-Id: strace development list <strace-devel.lists.sourceforge.net>
> 
> > > > --- a/syscall.c
> > > > +++ b/syscall.c
> > > > @@ -266,6 +266,14 @@ enum {
> > > >         MIN_QUALS = MAX_NSYSCALLS > 255 ? MAX_NSYSCALLS : 255
> > > >  };
> > > >  
> > > > +#if ENABLE_FAULT_INJECTION
> > > > +#include "fault.h"
> > > > +struct fault_opts *faults_vec[SUPPORTED_PERSONALITIES];
> > > > +#define syscall_failed(tcp)                                    \
> > > > +       (((tcp)->qual_flg & QUAL_FAULT) &&                      \
> > > > +        (faults_vec[current_personality][(tcp)->scno].flag & 
> > > > FAULT_ENTER))
> > > > +#endif
> > > 
> > > This is wrong: faults_vec[current_personality][(tcp)->scno].flag
> > > is a global flag, it cannot be used as a state of syscall parsing
> > > for a tracee.
> > > 
> > > Use tcp->flags to store this information.
> > 
> > True, I moved all accounting informations in a pointer to an array of
> > struct fault_opts in struct tcb. To reduce memory footprint the array is
> > not lacunar anymore and only contains relevant syscalls informations. We 
> > don't
> > have O(1) access anymore but since the array size can not exceed nsyscalls
> > I'll go for a binary search to retrieve fault informations.
> 
> Still, the code for sparse arrays is simpler, it works faster,
> and the memory cost in negligible.

The thing is this time I need a copy of the global sparse array by tcb. I was
thinking about reusing the design of the v1 (i.e filling the global array
while parsing arguments), then doing some copy-on-write when a new tcb appear
to get a thread local array. This design gets rid of the wrong state checking
you mentioned earlier and another problem: if we have more than one tracee we
get race conditions while consumming the faults. Does this design suit you?

Thanks,

-- 
Nahim El Atmani <nahim+...@naam.me>
http://naam.me/

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Reply via email to