Re: ff-core effect id handling in case of a failed effect upload

I sent a patch, see:
http://www.mail-archive.com/linux-input@vger.kernel.org/msg08572.html
("[PATCH 1/1] Input: don't modify the id of ioctl-provided ff effect
on upload failure")

Elias

On Sun, Feb 23, 2014 at 7:30 AM, Dmitry Torokhov
[off-list ref] wrote:

On Wed, Feb 19, 2014 at 11:14:18PM +0100, Elias Vanderstuyft wrote:

quoted

On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote:

quoted

(added Dmitry to CC)

19.02.2014 13:42, Elias Vanderstuyft kirjoitti:

quoted

Hi,

Hi,

quoted

In the process of reviewing the Wine DInput translation layer, I
noticed an inconvenience (in the ff-core implementation?) that can
possibly lead to confusing problems to application developers (not
only for Wine), in short:
If a new (id==-1) effect was uploaded (look at
ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL),
ff-core will have assigned a positive number to the effect id. This
can be confusing because the dev->ff->effects[] array will not contain
an element at the index of that new effect id.

I agree that this is a bit confusing, and the kernel code should
probably be modified to not clobber the ioctl-provided effect on failure
(effect->id is set to an "undefined" value, i.e. next free effect slot).

Dmitry, WDYT?

Yeah, it looks like we need to change evdev.c to read:

                error = input_ff_upload(dev, &effect, file);
                if (error)
                        return error;

                if (put_user(effect.id, &(((struct ff_effect __user *)p)->id)))
                        return -EFAULT;

                return 0;

Alright, who will create the patch?
Do I may / have to do it?

If you could create the patch that would be appreciated.

Thanks.

--
Dmitry