All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Groves <John@groves.net>
To: Dave Jiang <dave.jiang@intel.com>
Cc: John Groves <john@jagalactic.com>, Dan Williams <djbw@kernel.org>,
	 John Groves <jgroves@micron.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	 Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	 Miklos Szeredi <miklos@szeredi.hu>,
	Alison Schofield <alison.schofield@intel.com>,
	 Ira Weiny <iweiny@kernel.org>,
	Jonathan Cameron <jic23@kernel.org>,
	 "nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
	"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH V2 3/7] dax/fsdev: fix kaddr for multi-range and fail probe on invalid pgmap offset
Date: Fri, 29 May 2026 19:04:30 -0500	[thread overview]
Message-ID: <ahopdHYhO2x9E5-_@groves.net> (raw)
In-Reply-To: <1aa37178-4d36-4a4c-8b36-bf2789ce9655@intel.com>

On 26/05/26 04:31PM, Dave Jiang wrote:
> 
> 
> On 5/22/26 12:19 PM, John Groves wrote:
> > From: John Groves <John@Groves.net>
> > 
> > Two fixes for virtual address handling in fsdev:
> > 
> > 1. Use __va(phys) instead of virt_addr + linear_offset for the kaddr
> >    return in __fsdev_dax_direct_access(). The previous code added a
> >    device-linear byte offset to virt_addr (which is __va of ranges[0]),
> >    but for multi-range devices with physical gaps between ranges, this
> >    linear arithmetic crosses the gap and produces a wrong kernel virtual
> >    address. Using __va(phys) where phys comes from dax_pgoff_to_phys()
> >    is correct for any range layout because the direct map translates
> >    each physical address independently.
> > 
> > 2. Convert the WARN_ON to a fatal error when pgmap_phys > phys. This
> >    condition means the remapped region starts after the device's data
> >    region, which is an impossible state. Previously the probe continued
> >    with data_offset=0, leaving virt_addr silently misaligned. Now probe
> >    returns -EINVAL with a diagnostic message.
> 
> Split to 2 different patches I'd say.
> 
> DJ

Agree - done. Thanks!

John

<snip>


  reply	other threads:[~2026-05-30  0:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260522191804.79088-1-john@jagalactic.com>
2026-05-22 19:18 ` [PATCH V2 0/7] Fixes to the previously-merged drivers/dax/fsdev series John Groves
2026-05-22 19:18   ` [PATCH V2 1/7] dax: fix misleading comment about share/index union in dax_folio_reset_order() John Groves
2026-05-26 23:07     ` Dave Jiang
2026-05-29 23:41       ` John Groves
2026-05-22 19:18   ` [PATCH V2 2/7] dax/fsdev: fix multi-range offset, vmemmap_shift leak, and probe error cleanup John Groves
2026-05-26 23:22     ` Dave Jiang
2026-05-29 23:59       ` John Groves
2026-05-22 19:19   ` [PATCH V2 3/7] dax/fsdev: fix kaddr for multi-range and fail probe on invalid pgmap offset John Groves
2026-05-26 23:31     ` Dave Jiang
2026-05-30  0:04       ` John Groves [this message]
2026-05-22 19:19   ` [PATCH V2 4/7] dax/fsdev: clamp direct_access return to current physical range John Groves
2026-05-27  0:00     ` Dave Jiang
2026-05-30 13:06       ` John Groves
2026-05-22 19:19   ` [PATCH V2 5/7] dax: fix holder_ops race in fs_put_dax() John Groves
2026-05-27  0:16     ` Dave Jiang
2026-05-30 14:02       ` John Groves
2026-05-30 14:32         ` John Groves
2026-05-22 19:19   ` [PATCH V2 6/7] dax: replace exported dax_dev_get() with non-allocating dax_dev_find() John Groves
2026-05-27  0:28     ` Dave Jiang
2026-05-30 14:19       ` John Groves
2026-05-22 19:19   ` [PATCH V2 7/7] dax: fsdev.c minor formatting cleanup John Groves
2026-05-27  0:31     ` Dave Jiang

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=ahopdHYhO2x9E5-_@groves.net \
    --to=john@groves.net \
    --cc=alison.schofield@intel.com \
    --cc=brauner@kernel.org \
    --cc=dave.jiang@intel.com \
    --cc=djbw@kernel.org \
    --cc=iweiny@kernel.org \
    --cc=jack@suse.cz \
    --cc=jgroves@micron.com \
    --cc=jic23@kernel.org \
    --cc=john@jagalactic.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=nvdimm@lists.linux.dev \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    /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.