From: sashiko-bot@kernel.org
To: "Muchun Song" <songmuchun@bytedance.com>
Cc: linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH v2 2/2] dax/bus: fix Device DAX range alignment validation
Date: Tue, 22 Sep 2026 08:37:12 +0000 [thread overview]
Message-ID: <20260922083712.A89111F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260922082551.874901-3-songmuchun@bytedance.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dax: TOCTOU race in size_store causes partial shrink failure
--
commit 519db297333e73581e0bbd5524e7d6959d7610a7
Author: Muchun Song <muchun.song@linux.dev>
dax/bus: fix Device DAX range alignment validation
dev_dax->align describes the page size used by a Device DAX mapping.
Both the start and size of every range must therefore be aligned to it;
otherwise the starting PFN cannot represent a naturally aligned page of
that size.
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index e40c25401cf06..277c3ce23b831 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
[ ... ]
> @@ -923,6 +964,9 @@ static int adjust_dev_dax_range(struct dev_dax *dev_dax, struct resource *res, r
> if (dev_WARN_ONCE(dev, !size, "deletion is handled by dev_dax_shrink\n"))
> return -EINVAL;
>
> + if (!range_is_aligned(dev_dax, range->start, size))
> + return -EINVAL;
> +
[Severity: Medium]
Does this new strict alignment check introduce a regression where partial
shrink fails if the device alignment changes concurrently?
In the sysfs interface, size_store validates the size alignment before
acquiring dax_region_rwsem. If a root user concurrently writes to align_store
and changes the alignment requirement under lock, the shrink path proceeds
with an outdated alignment assumption.
During a shrink, dev_dax_shrink irreversibly deletes fully trailing ranges by
calling trim_dev_dax_range. When it reaches the final range to be partially
shrunk, it calls adjust_dev_dax_range.
If the concurrently updated alignment causes this new range_is_aligned check
to fail, it returns an error mid-operation after trailing ranges have already
been deleted.
Since sysfs writes require root privileges, can this time-of-check to
time-of-use race leave the local resource state corrupted, with the device
configuration permanently broken due to missing ranges and an inconsistent
size?
> rc = adjust_resource(res, range->start, size);
> if (rc)
> return rc;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260922082551.874901-1-songmuchun@bytedance.com?part=2
next prev parent reply other threads:[~2026-09-22 8:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 8:25 [PATCH v2 0/2] dax: Fix Device DAX range allocation validation Muchun Song
2026-09-22 8:25 ` [PATCH v2 1/2] dax/bus: fix mapping attribute error reporting Muchun Song
2026-09-22 17:28 ` Dave Jiang
2026-09-22 8:25 ` [PATCH v2 2/2] dax/bus: fix Device DAX range alignment validation Muchun Song
2026-09-22 8:37 ` sashiko-bot [this message]
2026-09-23 6:00 ` Muchun Song
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=20260922083712.A89111F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=songmuchun@bytedance.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 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.