John Groves wrote: > From: John Groves <[email protected]> > > The new fsdev driver provides pages/folios initialized compatibly with > fsdax - normal rather than devdax-style refcounting, and starting out > with order-0 folios. > > When fsdev binds to a daxdev, it is usually (always?) switching from the > devdax mode (device.c), which pre-initializes compound folios according > to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the > folios into a fsdax-compatible state. > > A side effect of this is that raw mmap doesn't (can't?) work on an fsdev > dax instance. Accordingly, The fsdev driver does not provide raw mmap - > devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw > mmap capability. > > In this commit is just the framework, which remaps pages/folios compatibly > with fsdax. > > Enabling dax changes: > > - bus.h: add DAXDRV_FSDEV_TYPE driver type > - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs > - dax.h: prototype inode_dax(), which fsdev needs > > Suggested-by: Dan Williams <[email protected]> > Suggested-by: Gregory Price <[email protected]> > Signed-off-by: John Groves <[email protected]> > ---
[snip] > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c > index e4bd5c9f006c..562e2b06f61a 100644 > --- a/drivers/dax/bus.c > +++ b/drivers/dax/bus.c > @@ -81,6 +81,10 @@ static int dax_match_type(const struct dax_device_driver > *dax_drv, struct device > !IS_ENABLED(CONFIG_DEV_DAX_KMEM)) > return 1; > > + /* fsdev driver can also bind to device-type dax devices */ > + if (dax_drv->type == DAXDRV_FSDEV_TYPE && type == DAXDRV_DEVICE_TYPE) > + return 1; > + In building up a topic branch for this I notice that this breaks the device-dax test. 1/1 ndctl:dax / device-dax FAIL 0.19s (exit status 250 or signal 122 SIGinvalid) ... Ok: 0 Expected Fail: 0 Fail: 1 Unexpected Pass: 0 Skipped: 0 Timeout: 0 Have you run this series with all the ndctl cxl selftests? How exactly is this supposed to ensure the fsdev driver does not bind to a regular dax device? This can be fixed by reloading the fsdev module thus pushing that driver later in the driver list... So we need to come up with a more reliable method here. I'm holding off pushing a topic branch for the time being. Ira > return 0; > } > [snip]
