quoted

quoted

quoted

quoted

"Henrik" == Henrik Rydberg [off-list ref] writes:

 Henrik> I won't argue against this case (with < 0) being frequent, but one
 Henrik> should really check "n < len" to be safe. Hopefully Dmitry has some
 Henrik> more input.
 >> 
 >> No, the point is that write (and read) can consume less data than
 >> requested, without it being an error. Robust userspace code should
 >> adjust buffer address / size and redo the work until all data is
 >> transferred or an error occurs.

 Henrik> Shouldn't the error be on (!len || len % smallest_acceptable_chunk),
 Henrik> then? Which makes me wonder about regressions - perhaps accumulating
 Henrik> partial writes in evdev is more safe from that perspective.

No, writing more than 1 complete struct should just consume the full
structs and return the number of bytes consumed, similar to all other
cases in the kernel where we return a length < count.

No sane userspace will write anything else than a multiple of
sizeof(input_event) though.

I doubt this will introduce any regressions (but you never know). The
only situation I can see is if userspace would fill out a proper struct
input_dev but use a wrong (too small) length in the write call. We used
to accept these, but with the patch here it will -EINVAL.

-- 
Bye, Peter Korsgaard