GSOC 2017: Project Proposal

[Dmitry V. Levin]

On Wed, Apr 05, 2017 at 10:07:22AM +0530, sandhya bankar wrote:
> On Mon, Apr 3, 2017 at 9:43 PM, Eugene Syromiatnikov <esyr at redhat.com> wrote:
> > On Mon, Apr 03, 2017 at 09:26:59PM +0530, sandhya bankar wrote:
> >> On Mon, Apr 3, 2017 at 9:10 PM, Eugene Syromiatnikov <esyr at redhat.com> wrote:
> >> > On Mon, Apr 03, 2017 at 08:51:34PM +0530, sandhya bankar wrote:
> >> >> To deal with code coverage, I will run individual test cases to find
> >> >> out why the coverage is below 100%.
> >> >
> >> > OK, let's be more specific: what are your suggestions in regards of
> >> > increasing coverage of dm.c up to 100%?
> >>
> >> First I will check  https://codecov.io/gh/strace/strace/src/master/dm.c
> >>
> >> This will give us information about which lines are hit, lines are
> >> missed  by testcase. So according to this data, we can add more tests
> >> to hit all missed lines. On dashboard this lines highlighted by Red
> >> color so It is easy to write test cases around those lines.
> > So, how do you expect to write test that checks dm_decode_dm_target_deps
> > function, for example?
> 
> Hi,
> 
>  I have checked the test case. The test case to check
> dm_decode_dm_target_deps is already present in ioctl_dm.c.
> 
> I am suspecting that, it seems there is problem in below case
> 
> case DM_TABLE_DEPS:
>                 if (entering(tcp) || syserror(tcp))
>                       break;
>                 dm_decode_dm_target_deps(tcp, arg, ioc);
>                 break;
> 
> When we come to check the dm_decode_dm_target_deps(). The switch case
> is breaking before calling it.
> 
> I have not debug it completely but both the cases of the if()
> statement somehow becoming true and that's why we are not able to call
> the dm_decode_dm_target_deps(). (I am not sure whether It is correct
> behavior )
> 
> I did one hack to traverse the dm_decode_dm_target_deps() code path. I
> have commented the both lines of switch case as below. Now the code
> can check the dm_decode_dm_target_deps().
> 
> I know it is not the right way to fix this problem, but after more
> debugging I can find the reason and fix it.

I cannot imagine anything as remote as this.  Very much surprised to hear
this from a person with experience of patching kernel drivers.

> diff --git a/dm.c b/dm.c
> index a69077b..7e3fb53 100644
> --- a/dm.c
> +++ b/dm.c
> @@ -516,8 +518,8 @@ dm_known_ioctl(struct tcb *const tcp, const
> unsigned int code,
>                 dm_decode_dm_target_spec(tcp, arg, ioc);
>                 break;
>         case DM_TABLE_DEPS:
> -               if (entering(tcp) || syserror(tcp))
> -                       break;
> +               //if (entering(tcp) || syserror(tcp))
> +               //      break;
>                 dm_decode_dm_target_deps(tcp, arg, ioc);
>                 break;
>         case DM_LIST_DEVICES:
> 
> Please suggest on it.

The most simple way to test the exiting part of DM_TABLE_DEPS
is to run a virtual machine with a proper dm setup inside.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170407/6a9ffb2d/attachment.bin>