Re: [RFC] avoid (theoretical) conflicts of input device file names
From: Dmitry Torokhov
Date: Wed Oct 08 2014 - 17:30:24 EST
On Wed, Oct 08, 2014 at 10:49:29PM +0200, Richard Leitner wrote:
> currently I discovered the possibility that device file numbers of the input
> subsystem could go negative when the signed int "border" is passed. To fix
> this behaviour I sent a patch a few minutes ago.
> But as the subject says there is currently the (theoretical) possibility that
> the same input device file name is given out twice. This can happen if the
> "input_no" variable had an overflow (due to the fact this is at least at 2^32
> I call the issue theoretical). If such a case occurs a -EEXISTS is returned at
> the creation of the file.
> IMHO it would be a good idea to check if the chosen input device file name
> is valid at the point it is created (which is currently input_allocate_device).
> So you can just increment and check it again until there's a valid number/name
> found for it.
> I'm pretty new to the input subsystem, so what do you think about it?
> Any comments/ideas? Would there be a better place to do such checking?
I do not think it is worth checking. Yes, theoretically you can wrap
around, but practically instantiating at least 2^32 devices will take
too long. If ever it becomes a concern my very distant future relatives
will move the counter to 64 or 128 bit and call it a day.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/