On Sat, Jun 13, 2015 at 1:48 AM, Dmitry V. Levin <ldv@xxxxxxxxxxxx> wrote:
> On Thu, Jun 11, 2015 at 03:34:14PM +0200, Patrik Jakobsson wrote:
>> On Thu, Jun 11, 2015 at 02:27:12AM +0300, Dmitry V. Levin wrote:
>> > On Wed, Jun 10, 2015 at 02:45:24PM +0200, Patrik Jakobsson wrote:
>> > > On Wed, Jun 10, 2015 at 01:35:35AM +0300, Dmitry V. Levin wrote:
>> > > > On Tue, Jun 09, 2015 at 01:26:43PM +0200, Patrik Jakobsson wrote:
>> > [...]
>> > > > > +static int i915_setparam(struct tcb *tcp, const unsigned int code, long arg)
>> > > > > +{
>> > > > > + struct drm_i915_setparam param;
>> > > > > +
>> > > > > + if (exiting(tcp) || umove(tcp, arg, ¶m))
>> > > > > + return 0;
>> > > >
>> > > > In this and other ioctl printers that unconditionally return 0 on exit,
>> > > > wouldn't the caller treat it as an ioctl that hasn't been printed?
>> > >
>> > > Yes, seems like the exiting phase should return 1 if already handled in the
>> > > entering phase. But changing it produces the same output for some reason. Not
>> > > sure what's going on here.
>> >
>> > Isn't tcp->u_arg[2] printed twice, the first time decoded,
>> > and the second time in hex?
>>
>> My mistake, it does print u_arg[2] in hex as well. Luckily they could all be
>> moved to the exiting phase instead. Fixed in v2.
>
> The common rule is to decode as early as possible, consequently, all
> syscall arguments that could be decoded on entering syscall should be
> decoded on entering rather than on exiting. All syscall arguments
> of _IOW ioctl commands could be fully decoded on entering syscall.
>
Yes, that makes sense. I'll rework it for v2 of the patch set.
>
> --
> ldv
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
