From: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Subject: Re: [PATCH v3] block: annotate lockless task ioprio accesses
Date: Fri, 23 Oct 2026 18:56:09 +0700 [thread overview]
Message-ID: <20261023115609.12244-1-ngocthang2710.1999@gmail.com> (raw)
In-Reply-To: <20261020125233.9820-1-ngocthang2710.1999@gmail.com>
Hi Damien,
Title: agreed, I'll change it (v4 below).
On the pairing: a release store pairs with any load that is ordered after
the pointer load, and here the ordering comes from the address dependency,
not from an acquire. The only thing the reader does with the loaded
pointer is dereference it (ioc->ioprio), and the kernel memory model orders
a dependent load after the READ_ONCE() that produced its address. This is
the same pairing as rcu_assign_pointer()/rcu_dereference() (see "ADDRESS
DEPENDENCY" in Documentation/memory-barriers.txt); READ_ONCE() also carries
the extra barrier Alpha needs (arch/alpha/include/asm/rwonce.h).
smp_load_acquire() would only be needed if the reader looked at data not
dependent on the pointer, and would add a barrier on arm64/powerpc for
nothing.
Why not plain WRITE_ONCE(): it would silence KCSAN, but it does not order
the initialization of the new io_context (alloc_io_context() runs before
task_lock(), and spin_lock() is only an acquire, so those stores may be
reordered after the pointer store on weakly ordered CPUs). A reader could
then see the pointer without seeing the initialized ioc. The release is
what makes the publication safe.
If you'd rather keep this minimal, I can drop the release and use
WRITE_ONCE(), but I think the release is the correct thing to have.
v4 follows with the new title and a comment/commit-message paragraph
explaining the above.
Thanks,
Nguyen Ngoc Thang
next prev parent reply other threads:[~2026-10-23 11:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 7:16 [PATCH] block: annotate lockless task ioprio accesses Nguyen Ngoc Thang
2026-10-19 11:59 ` Damien Le Moal
2026-10-19 12:18 ` Nguyen Ngoc Thang
2026-10-19 12:28 ` Damien Le Moal
2026-10-19 12:58 ` [PATCH v2] " Nguyen Ngoc Thang
2026-10-19 15:47 ` Damien Le Moal
2026-10-20 12:52 ` [PATCH v3] " Nguyen Ngoc Thang
2026-10-22 7:34 ` Damien Le Moal
2026-10-23 11:56 ` Nguyen Ngoc Thang [this message]
2026-10-23 11:56 ` [PATCH v4] block: use READ_ONCE() to access the task io_context ioprio Nguyen Ngoc Thang
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=20261023115609.12244-1-ngocthang2710.1999@gmail.com \
--to=ngocthang2710.1999@gmail.com \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox