Segmentation fault on null and filestat ioengine when pre_read option is true

[Martins3]

1. what's the bug?

null engine and filestat only have io_ops::open_file hook, when pre_read option is true, in function pre_read_file

if(did_open)
  td->io_ops->close_file(td, f)

Using io_ops::close_file cause the segfault

2. environment

It should work for every platform, tested on Arch Linux with 4.14 kernel version

3. fio version

3.21

Compiled with commit hash code d13596b

4. how to reproduce

1. add pre_read=1 to example/filestat-ioengine.fio
2. fio example/filestat-ioengine.fio

[Martins3]

May add an empty close_file hook to null or filestat engine is enough.

[sitsofe]

Hmm, if I am an ioengine that fakes I/O (FIO_FAKEIO) does pre-reading ever make sense? I guess it does in the filestat case...

At any rate, @Martins3 would you like to submit a diff to fix this one?

[sitsofe]

I'd also argue that

• fio/engines/http.c

  Line 651 in f09a777

  .open_file = fio_http_open,

• fio/engines/nbd.c

  Line 347 in f09a777

  .open_file = nbd_open_file,

• fio/engines/rados.c

  Line 456 in f09a777

  .open_file = fio_rados_open,

• fio/engines/rbd.c

  Line 680 in f09a777

  .open_file = fio_rbd_open,

and perhaps

fio/engines/skeleton_external.c

Line 140 in f09a777

* Hook for opening the given file. Unless the engine has special

need a some wording saying that it is paired with fio_skeleton_close() to hint that if you implement the first you ought to implement the later too...

(engines/cpu.c gets off the hook because it's FIO_NOIO but I suppose it could be fixed up too)

[Martins3]

There is another solution, do some check for pre_read, if the io engine doesn't support pre_read, just show the error and exit.

Maybe there are more elegant solutions for this bug.

[sitsofe]

There is another solution, do some check for pre_read, if the io engine doesn't support pre_read, just show the error and exit.

@Martins3 indeed but how to know without yet another new flag? That's why I was philosophising about FIO_FAKEIO... Having said that I still think if open is being overridden it's not unfair to expect close to also be overridden...