On Fri 07-08-20 15:55:07, Vivek Goyal wrote: > virtiofs does not have a block device but it has dax device. > Modify bdev_dax_pgoff() to be able to handle that. > > If there is no bdev, that means dax offset is 0. (It can't be a partition > block device starting at an offset in dax device). > > This is little hackish. There have been discussions about getting rid > of dax not supporting partitions. > > https://lore.kernel.org/linux-fsdevel/20200107125159.GA15745@xxxxxxxxxxxxx/ > > IMHO, this path can easily break exisitng users. For example > ioctl(BLKPG_ADD_PARTITION) will start breaking on block devices > supporting DAX. Also, I personally find it very useful to be able to > partition dax devices and still be able to use DAX. > > Alternatively, I tried to store offset into dax device information in iomap > interface, but that got NACKed. > > https://lore.kernel.org/linux-fsdevel/20200217133117.GB20444@xxxxxxxxxxxxx/ > > I can't think of a good path to solve this issue properly. So to make > progress, it seems this patch is least bad option for now and I hope > we can take it. > > Signed-off-by: Stefan Hajnoczi <stefanha@xxxxxxxxxx> > Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx> > Cc: Dan Williams <dan.j.williams@xxxxxxxxx> > Cc: linux-nvdimm@xxxxxxxxxxxx This patch looks OK to me. You can add: Reviewed-by: Jan Kara <jack@xxxxxxx> Honza > --- > drivers/dax/super.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 8e32345be0f7..c4bec437e88b 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -46,7 +46,8 @@ EXPORT_SYMBOL_GPL(dax_read_unlock); > int bdev_dax_pgoff(struct block_device *bdev, sector_t sector, size_t size, > pgoff_t *pgoff) > { > - phys_addr_t phys_off = (get_start_sect(bdev) + sector) * 512; > + sector_t start_sect = bdev ? get_start_sect(bdev) : 0; > + phys_addr_t phys_off = (start_sect + sector) * 512; > > if (pgoff) > *pgoff = PHYS_PFN(phys_off); > -- > 2.25.4 > -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
