From: Dan Williams <dan.j.williams@intel.com>
To: "Jane Chu" <jane.chu@oracle.com>,
"Dave Jiang" <dave.jiang@intel.com>,
"Cao, Quanquan/曹 全全" <caoqq@fujitsu.com>,
linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev
Cc: <vishal.l.verma@intel.com>
Subject: Re: Question about forcing 'disable-memdev'
Date: Thu, 7 Mar 2024 12:55:33 -0800 [thread overview]
Message-ID: <65ea29c566197_127132943@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <353efab5-ee59-4bb7-abc1-b602db3306c6@oracle.com>
Jane Chu wrote:
> On 2/27/2024 12:28 PM, Dave Jiang wrote:
>
> >
> > On 2/27/24 1:24 PM, Jane Chu wrote:
> >> On 2/27/2024 8:40 AM, Dave Jiang wrote:
> >>
> >>> On 2/26/24 10:32 PM, Cao, Quanquan/曹 全全 wrote:
> >>>> Hi, Dave
> >>>>
> >>>> On the basis of this patch, I conducted some tests and encountered unexpected errors. I would like to inquire whether the design here is reasonable? Below are the steps of my testing:
> >>>>
> >>>> Link: https://lore.kernel.org/linux-cxl/170138109724.2882696.123294980050048623.stgit@djiang5-mobl3/
> >>>>
> >>>>
> >>>> Problem description: after creating a region, directly forcing 'disable-memdev' and then consuming memory leads to a kernel panic.
> >>> If you are forcing memory disable when the memory cannot be
> >>> offlined, then this behavior is expected. You are ripping the
> >>> memory away from underneath kernel mm. The reason the check was
> >>> added is to prevent the users from doing exactly that.
> >> Since user is doing the illegal thing, shouldn't that lead to
> >> SIGBUS or SIGKILL ?
> > The behavior is unpredictable once the CXL memory is ripped away. If
> > the memory only backed user memory then you may see SIGBUS. But if
> > the memory backed kernel data then kernel OOPs is not out of
> > question.
>
> Make sense, thanks for the clarification.
I will just add consider the case of a technician physically removing a
card without shutting down the kernel's usage of it. That event is
indistinguishable from "cxl disable-memdev --force" at the driver level
since the driver just gets the same ->remove() callback with no
opportunity to return an error.
So this is a case of trusting the system administrator to know best, and
is why --force is documented as:
-f, --force
DANGEROUS: Override the safety measure that blocks attempts
to disable a device if the tool determines the memdev is in active
usage. Recall that CXL memory ranges might have been established by
platform firmware and disabling an active device is akin to force
removing memory from a running system.
prev parent reply other threads:[~2024-03-07 20:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 5:32 Question about forcing 'disable-memdev' Cao, Quanquan/曹 全全
2024-02-27 16:40 ` Dave Jiang
2024-02-27 20:24 ` Jane Chu
2024-02-27 20:28 ` Dave Jiang
2024-02-28 20:17 ` Jane Chu
2024-03-07 20:55 ` Dan Williams [this message]
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=65ea29c566197_127132943@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=caoqq@fujitsu.com \
--cc=dave.jiang@intel.com \
--cc=jane.chu@oracle.com \
--cc=linux-cxl@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).