From: Jens Axboe <axboe@kernel.dk>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: zlang@kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] fsstress: add support for RWF_DONTCACHE
Date: Mon, 6 Jan 2025 19:16:17 -0700 [thread overview]
Message-ID: <32edc8e2-f338-44d3-9070-4be4b5fc99a2@kernel.dk> (raw)
In-Reply-To: <20250107021102.GO6160@frogsfrogsfrogs>
On 1/6/25 7:11 PM, Darrick J. Wong wrote:
>> +void
>> +read_dontcache_f(opnum_t opno, long r)
>> +{
>> + int e;
>> + pathname_t f;
>> + int fd;
>> + int64_t lr;
>> + off64_t off;
>> + struct stat64 stb;
>> + int v;
>> + char st[1024];
>> + struct iovec iov;
>> + int flags;
>> +
>> + init_pathname(&f);
>> + if (!get_fname(FT_REGFILE, r, &f, NULL, NULL, &v)) {
>> + if (v)
>> + printf("%d/%lld: read - no filename\n", procid, opno);
>> + free_pathname(&f);
>> + return;
>> + }
>> + fd = open_path(&f, O_RDONLY);
>> + e = fd < 0 ? errno : 0;
>> + check_cwd();
>> + if (fd < 0) {
>> + if (v)
>> + printf("%d/%lld: read - open %s failed %d\n",
>> + procid, opno, f.path, e);
>> + free_pathname(&f);
>> + return;
>> + }
>> + if (fstat64(fd, &stb) < 0) {
>> + if (v)
>> + printf("%d/%lld: read - fstat64 %s failed %d\n",
>> + procid, opno, f.path, errno);
>> + free_pathname(&f);
>> + close(fd);
>> + return;
>> + }
>> + inode_info(st, sizeof(st), &stb, v);
>> + if (stb.st_size == 0) {
>> + if (v)
>> + printf("%d/%lld: read - %s%s zero size\n", procid, opno,
>> + f.path, st);
>> + free_pathname(&f);
>> + close(fd);
>> + return;
>> + }
>> + lr = ((int64_t)random() << 32) + random();
>> + off = (off64_t)(lr % stb.st_size);
>> + iov.iov_len = (random() % FILELEN_MAX) + 1;
>> + iov.iov_base = malloc(iov.iov_len);
>
> Should there be a check for null iov_base after the allocation?
Nothing else in fsstress seems to bother with malloc() failures, which
at least on Linux, is probably fair game.
>> + flags = have_rwf_dontcache ? RWF_DONTCACHE : 0;
>> + e = preadv2(fd, &iov, 1, off, flags) < 0 ? errno : 0;
>> + if (have_rwf_dontcache && e == EOPNOTSUPP)
>
> ...and should this set have_rwf_dontcache = 0?
I don't think so? If we get EOPNOTSUPP and we don't have dontcache, then
it's a fatal condition. fsstress defaults to it being available, so we
may very well run into EOPNOTSUPP and then just do a regular read or
write for that case. We could probably do:
if (have_rwf_dontcache && e == EOPNOTSUPP) {
have_rwf_dontcache = 0;
e = preadv2(fd, &iov, 1, off, 0) < 0 ? errno : 0;
}
here and on the write side, at least then we won't repeatedly try
RWF_DONTCACHE if we hit EOPNOTSUPP. But in terms of logic, it should be
correct as-is.
--
Jens Axboe
next prev parent reply other threads:[~2025-01-07 2:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 17:48 [PATCHSET 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-06 17:48 ` [PATCH 1/2] fsstress: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 2:11 ` Darrick J. Wong
2025-01-07 2:16 ` Jens Axboe [this message]
2025-01-07 17:30 ` Darrick J. Wong
2025-01-06 17:48 ` [PATCH 2/2] fsx: " Jens Axboe
2025-01-07 2:09 ` Darrick J. Wong
2025-01-07 2:12 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2025-01-07 16:05 [PATCHSET v2 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-07 16:05 ` [PATCH 1/2] fsstress: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 17:31 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32edc8e2-f338-44d3-9070-4be4b5fc99a2@kernel.dk \
--to=axboe@kernel.dk \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.