io_submit with silly values/pointers

[Dr. David Alan Gilbert]

* 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?

For reference I'm running this with:

../strace-code/strace -ostrace.log -f ./trinity -c io_submit

then grepping the strace.log for io_submit - watch out some of the lines
are huge.

(With networking off, and in a directory I don't care about!)

Dave


-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/