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

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.
--

--- 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