On Thu, Nov 07, 2019 at 01:20:30AM +0200, Jarkko Sakkinen wrote: > On Tue, Nov 05, 2019 at 02:52:23PM -0800, Sean Christopherson wrote: > > On Tue, Nov 05, 2019 at 01:20:56PM +0200, Jarkko Sakkinen wrote: > > > Add @count write the number of bytes added as there is not any good reason > > > to overwrite input parameters. > > > > I disagree, overwriting the params means userspace doesn't need to adjust > > the values to restart the ioctl(). Ditto for printing out the failing > > address if the ioctl() fails. > > There is three redundant updates. At least only @length must be > updated in order to remove this glitch. > > As far as overwriting goes, it should be only done when there is > requiring to do that. What is obvious is that the current behaviour is wrong. You have a *single value* to return and you encode the *same value* with *three encodings*: 1. offset + count 2. length - count 3. src + count And ironically none of the encodings give you the count of bytes processed in unpacked form. It is something that must be readily available as practically all common syscalls that can partially process the input give that. There is a long history of that pattern and no history at all with this weird pack of encodings. /Jarkko
