io_submit with silly values/pointers

[Denys Vlasenko]

On 11/08/2013 09:10 PM, Dr. David Alan Gilbert wrote:
> * Denys Vlasenko (dvlasenk at redhat.com) wrote:
>> On 11/06/2013 08:55 PM, Dr. David Alan Gilbert wrote:
>>> Hi,
>>>   'trinity' generated an io_submit call with a ludicrous large
>>> 'nr' of requests, the result being strace sat there just printing out
>>> {...}, for nearly ever since the data didn't exist.
>>>
>>>   Is the right thing to 'break' rather than 'continue' if either
>>> of the umove calls fail?     The alternative way is to break 
>>> if the iocbs read fails but allow individualy broken iocb reads.
>>> I'm not sure which is more sane - you could have a real call
>>> that fails for another reason before hitting the bad iocb.
>>
>> Please try attached patch.
> 
> Thanks, hmm it's surviving but I'm not sure it's giving the
> expected output in all cases; most of them look believable, but:
> 
> 5347  io_submit(18446744073709551615, 127, {0xffffffff81000000}) = -1 EFAULT (Bad address)
> 
> What's happened to that one - my reading of your patch would be that it
> would print an address without the {}'s if it failed on the iocbs read,
> so why is there only one entry?

It *is* failure to read iocbs[0]. Success (with subsequent failure
to read iocbs[0][0]) would look like this:

io_submit(18446744073709551615, 127, {{0xffffffsomehex}, ... })