On Tue, Jul 21, 2026 at 05:41:05PM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
>
> Pre-existing issues:
> - [Critical] Writing to poisoned memory without clearing it first can trigger
> a Machine Check Exception (MCE) leading to a kernel panic.
> --
I feel pretty good about refuting this one after investigating, but welcome
confirmation from others familiar w this code.
The point is that's not how poison works on the write path here. A store
never consumes poison, so there's no synchronous MCE.
memcpy_flushcache() reads from @buf (a clean kernel buffer) and writes to
the poisoned destination. It never loads the poisoned line. An MCE requires
consuming poison via a load, here a store just overwrites it.
Note that writing over poison isn't accidental on this stack, it's the
intended clear mechanism. See:
- pmem_do_write()/pmem_recovery_write() in drivers/nvdimm/pmem.c
- commit 0a370d261c80 ("libnvdimm, pmem: clarify the write+clear_poison+write
flow")
The -EIO isn't swallowed either. It's returned to the caller and the
badblocks stay set for the uncleared media, so a later read still fails
cleanly. nsio_rw_bytes() does fall through to the store where pmem_do_write()
returns early, but that's cosmetic. The store can't panic and can't clear
poison in hardware.
--Alison
>
> --- Patch [1]: [PATCH 1/2] libnvdimm: nd.h: clean up kernel-doc warnings ---
> commit e89a1ebc4ad5020678df8e74422e59aff926ae52
> Author: Randy Dunlap <[email protected]>
>
> libnvdimm: nd.h: clean up kernel-doc warnings
>
> This commit resolves kernel-doc warnings in include/linux/nd.h by adding
> missing struct member, function parameter, and function return descriptions.
>
> > diff --git a/include/linux/nd.h b/include/linux/nd.h
> > index fa099e295f780..62988000e7a7e 100644
> > --- a/include/linux/nd.h
> > +++ b/include/linux/nd.h
>
> [ ... ]
>
> > @@ -174,11 +177,14 @@ static inline int nvdimm_read_bytes(struct
> > nd_namespace_common *ndns,
> > * @offset: namespace-relative starting offset
> > * @buf: buffer to drain
> > * @size: transfer length
> > + * @flags: process (0) or atomic (1) context
> > *
> > * NVDIMM Namepaces disks do not implement sectors internally. Depending
> > on
> > * the @ndns, the contents of @buf may be in cpu cache, platform buffers,
> > * or on backing memory media upon return from this routine. Flushing
> > * to media is handled internal to the @ndns driver, if at all.
> > + *
> > + * Returns: %0 on success or a negative error code on failure
> > */
> > static inline int nvdimm_write_bytes(struct nd_namespace_common *ndns,
> > resource_size_t offset, void *buf, size_t size,
>
> [Severity: Critical]
> This is a pre-existing issue, but while reviewing this documentation update
> for nvdimm_write_bytes(), I noticed a potential problem in its underlying
> implementation in drivers/nvdimm/claim.c:nsio_rw_bytes().
>
> When a write is performed on a poisoned PMEM block and clearing the poison
> fails (for instance, when unaligned or in atomic context), the code sets
> the error code but appears to fall through to execute the write anyway:
>
> drivers/nvdimm/claim.c:nsio_rw_bytes() {
> ...
> if (cleared < size)
> rc = -EIO;
> // ...
> } else
> rc = -EIO;
> }
>
> memcpy_flushcache(nsio->addr + offset, buf, size);
> ...
> }
>
> Can a read-for-ownership of a poisoned cacheline during this fallback write
> trigger a synchronous Machine Check Exception and panic the kernel?
>
> Would it be safer to return early or skip the memcpy_flushcache call when
> rc is set to -EIO?
>
> --
> Sashiko AI review ยท
> https://sashiko.dev/#/patchset/[email protected]?part=1
>
