linux-kernel - Re: [PATCH 02/19] dax: Pass dax_dev to dax_writeback_mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Jan 2020 13:43:17 -0500
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>, virtio-fs@...hat.com,
        Miklos Szeredi <miklos@...redi.hu>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 02/19] dax: Pass dax_dev to dax_writeback_mapping_range()

On Fri, Jan 03, 2020 at 10:18:22AM -0800, Dan Williams wrote:

> I'll also circle back to your question about
> partitions on patch1.

Hi Dan,

I was playing with having sector information in dax device (and not having
to look back at bdev). I was thinking of something as follows.

- Create a new structure/handle which also contains offset into dax device
  in sectors. Say.

  struct dax_handle {
  	sector_t start_sect;
  	struct dax_device *dax_dev;
  }

 This handle will have pointer to the actual dax device.

- Modify dax_get_by_bdev(struct block_device *bdev) to return dax_handle
  (instead of dax device).

  struct dax_handle *dax_get_by_bdev(struct block_device *bdev);

  This will create dax_handle. Find dax_device from hash table and
  initialize dax_handle.

  dax_handle->start_sect = get_start_sect(bdev);
  dax_handle->dax_dev = dax_dev;

  Now filesystem and stacked block devices can get pointer to dax_handle
  using block device and they can use this handle to refer to underlying
  dax device partition.

- Now dax_handle can be passed around and hopefully we can get rid of
  passing around bdev in many of the dax interfaces. And partition offset
  information has now moved into dax_handle.

- For the use cases which don't have a bdev (like virtiofs), we can
  provide another helper to get dax_handle with offset 0. And then
  we should not need a bdev to be able to use dax API.

Does this sound like a reasonable step in the direction of getting rid
of this assumption that every dax_device has associated block_device.

Thanks
Vivek