>>>>> "Henrik" == Henrik Rydberg <rydberg@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
