parse: handle comma-separated options Option parser does not properly handle 'sync_file_range' option with multiple flags. It was due to opt_len() only use ':' as delimiter, so only last flag in comma-separated list have effect. This patch adds ',' as a delimiter. All flags are correctly ORed now. Fixes: https://github.com/axboe/fio/issues/1234 Signed-off-by: Oleg Latin <oleglatin@yandex-team.ru>
zbd: support 'z' suffix for zone granularity Allow users to pass some options with zone granularity which is natural for ZBD workloads. This is nifty for writing quick tests and when firmware guys change zone sizes. Converted options are io_size= offset= offset_increment= size= zoneskip= Example: rw=write numjobs=2 offset=1z offset_increment=10z size=5z io_size=6z Thread 1 will write zones 1, 2, 3, 4, 5, 1. Thread 2 will write zones 11, 12, 13, 14, 15, 11. Note: zonemode=strided doesn't create ZBD zone structure but requires value recalculation. This is why 2 functions are split. Signed-off-by: Alexey Dobriyan (SK hynix) <adobriyan@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
options: fix buffer overrun Google's OSS-fuzz turned up a buffer overrun with value of the filename option due to an overrun in a MAX_PATH sized buffer. To reproduce compile fio with address sanitizer options like the following LDFLAGS="-fsanitize=address" ./configure --disable-optimizations \ --extra-cflags="-fsanitize=address" The issue is demonstrated by the following job: % COUNT=$(getconf PATH_MAX /); printf "[t]\nfilename=%${COUNT}s" \ | sed 's/ /@/g' | fio --parse-only - ================================================================= ==45748==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee8e35780 at pc 0x00010735a343 bp 0x7ffee8e35270 sp 0x7ffee8e34a08 WRITE of size 1025 at 0x7ffee8e35780 thread T0 #0 0x10735a342 in wrap_vsprintf (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x22342) #1 0x10735a9ac in wrap_sprintf (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x229ac) #2 0x106e83b01 in add_file filesetup.c:1656 #3 0x106ee8c87 in str_filename_cb options.c:1320 #4 0x106ee1b44 in __handle_option parse.c:792 #5 0x106ed99ad in handle_option parse.c:1014 #6 0x106eda07d in parse_option parse.c:1184 #7 0x106ef10ea in fio_options_parse options.c:5199 #8 0x106e27684 in __parse_jobs_ini init.c:2076 #9 0x106e25377 in parse_jobs_ini init.c:2127 #10 0x106e2c971 in parse_options init.c:2989 #11 0x106ffc884 in main fio.c:42 #12 0x7fff702f1cc8 in start (libdyld.dylib:x86_64+0x1acc8) Address 0x7ffee8e35780 is located in stack of thread T0 at offset 1056 in frame #0 0x106e836ef in add_file filesetup.c:1644 This frame has 1 object(s): [32, 1056) 'file_name' (line 1646) <== Memory access at offset 1056 overflows this variable Return an error message to the user by doing the following: - Allow "regular" string options to have a maxlen parameter - Set the filename option to have a maxlen of MAX_PATH Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Use fallthrough attribute Fio currently triggers a bunch of fall through errors on clang 10, since it doesn't work with the /* fall through */ method of indicating fallthrough. Normalize this a bit and use the correct compiler attribute for this. Signed-off-by: Jens Axboe <axboe@kernel.dk>
parse: Silence discard-const warning on OpenBSD This might be overkill just to silence the warnings, but having a common function for const and non-const version makes it discard const pointer at some point. -- CC parse.o parse.c: In function 'find_option_c': parse.c:1051: warning: passing argument 1 of 'find_option' discards qualifiers from pointer target type parse.c: In function 'get_option': parse.c:1051: warning: passing argument 1 of 'find_option' discards qualifiers from pointer target type parse.c:1051: warning: passing argument 1 of 'find_option' discards qualifiers from pointer target type parse.c: In function 'parse_cmd_option': parse.c:1051: warning: passing argument 1 of 'find_option' discards qualifiers from pointer target type Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
Optimize the code that copies strings Using strncpy() to copy strings is suboptimal because strncpy writes a bunch of additional unnecessary null bytes. Use snprintf() instead of strncpy(). An additional advantage of snprintf() is that it guarantees that the output string is '\0'-terminated. This patch is an improvement for commit 32e31c8c5f7b ("Fix string copy compilation warnings"). Cc: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>