From: Jason Gunthorpe <jgg@nvidia.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-cxl@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vishal L Verma <vishal.l.verma@intel.com>,
"Weiny, Ira" <ira.weiny@intel.com>,
"Schofield, Alison" <alison.schofield@intel.com>
Subject: Re: [PATCH v2 2/4] cxl/mem: Fix synchronization mechanism for device removal vs ioctl operations
Date: Tue, 30 Mar 2021 19:09:40 -0300 [thread overview]
Message-ID: <20210330220940.GB2356281@nvidia.com> (raw)
In-Reply-To: <CAPcyv4gwha+fgLbW_LCqRhRtC+N6Ws2Cnmv==C661ccv5GoOdQ@mail.gmail.com>
On Tue, Mar 30, 2021 at 02:00:43PM -0700, Dan Williams wrote:
> Ok, so another case where I agree the instability exists but does not
> matter in practice in this case because the cxl_memdev_ioctl() read
> side is prepared for the state change to leak into the down_read()
> section. There's no meaningful publish/unpublish race that READ_ONCE()
> resolves here.
Generally READ_ONCE is about protecting the control flow after the
*compiler*
Say, I have
if (a) {
do_x();
do_y();
}
The compiler *might* transform it so I get:
if (a)
do_x()
if (a)
do_y()
Now if 'a' is an unstable data race I have a crazy problem: the basic
invarient that x and y are always done together is broken and I can
have x done without y. (or y done without x if the CPU runs it out of
order!)
But I can't see this at all from the code, it just runs wrong under
certain races with certain compilers.
READ_ONCE prevents this kinds of compiler transform, this is what it
is for. It is why in modern times it has become expected to always
mark unlocked unstable data access with these helpers, or the RCU
specific variants.
It is not reasoning about happens before/happens after kind of ideas,
it is about "the compiler assumes the memory doesn't change and if we
break that assumption the compiled result might not work sanely"
> down_write(&cxl_memdev_rwsem);
> cxlmd->cxlm = cxlm;
> up_write(&cxl_memdev_rwsem);
> cdev_device_del(...);
> ...and then no unstable state of the ->cxlm reference leaks into the
> read-side that does:
>
> down_read(&cxl_memdev_rwsem);
> if (!cxlmd->cxlm) {
> up_read(&cxl_memdev_rwsem)
> return -ENXIO;
> }
> ...
> up_read(&cxl_memdev_rwsem);
Sure this construction is easy to understand and validate, if a rwsem
is OK performance wise. We can do it after the cdev_device_del. Here
the cxlm is the protected data and it is always accessed under
lock.
The rwsem can be transformed to SRCU by marking cxlm with the __rcu
type annotation and using srcu_dereference (as a READ_ONCE wrapper)
and rcu_assign_pointer (as a WRITE_ONCE wrapper) to manipulte the cxlm
Jason
next prev parent reply other threads:[~2021-03-30 22:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 2:47 [PATCH v2 0/4] cxl/mem: Fix memdev device setup Dan Williams
2021-03-30 2:47 ` [PATCH v2 1/4] cxl/mem: Use sysfs_emit() for attribute show routines Dan Williams
2021-03-30 2:47 ` [PATCH v2 2/4] cxl/mem: Fix synchronization mechanism for device removal vs ioctl operations Dan Williams
2021-03-30 11:16 ` Jason Gunthorpe
2021-03-30 15:37 ` Dan Williams
2021-03-30 15:47 ` Jason Gunthorpe
2021-03-30 16:05 ` Dan Williams
2021-03-30 17:02 ` Jason Gunthorpe
2021-03-30 17:31 ` Dan Williams
2021-03-30 17:54 ` Jason Gunthorpe
2021-03-30 19:00 ` Dan Williams
2021-03-30 19:26 ` Jason Gunthorpe
2021-03-30 19:43 ` Dan Williams
2021-03-30 19:51 ` Jason Gunthorpe
2021-03-30 21:00 ` Dan Williams
2021-03-30 22:09 ` Jason Gunthorpe [this message]
2021-03-30 2:47 ` [PATCH v2 3/4] cxl/mem: Do not rely on device_add() side effects for dev_set_name() failures Dan Williams
2021-03-30 2:48 ` [PATCH v2 4/4] cxl/mem: Disable cxl device power management Dan Williams
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=20210330220940.GB2356281@nvidia.com \
--to=jgg@nvidia.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
/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