[PATCH 3/4] Introduce syscall fault injection feature

[Nahim El Atmani]

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" <ldv at altlinux.org>
> To: strace-devel at lists.sourceforge.net
> Subject: Re: [PATCH 3/4] Introduce syscall fault injection feature
> Message-ID: <20160811024252.GE22091 at altlinux.org>
> In-Reply-To: <20160810203148.snk4jm6pd3h35cf6 at 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+dev at naam.me>
http://naam.me/