Re: [PATCH 1/2] libnvdimm: nd.h: clean up kernel-doc warnings

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
>