linux-kernel - RE: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci

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]

Message-ID: <VI1PR0502MB3008F125A4E754A1505663A1D12F0@VI1PR0502MB3008.eurprd05.prod.outlook.com>
Date:   Tue, 7 Mar 2017 03:21:24 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Bart Van Assche <bart.vanassche@...disk.com>,
        Doug Ledford <dledford@...hat.com>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sebastian Ott <sebott@...ux.vnet.ibm.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
        David Woodhouse <dwmw2@...radead.org>,
        "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Russell King <linux@...linux.org.uk>
Subject: RE: [PATCH 1/2] device: Stop requiring that struct device is embedded
 in struct pci_dev

Hi Bart,

> -----Original Message-----
> From: linux-rdma-owner@...r.kernel.org [mailto:linux-rdma-
> owner@...r.kernel.org] On Behalf Of Bart Van Assche
> Sent: Monday, March 6, 2017 6:36 PM
> To: Doug Ledford <dledford@...hat.com>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; Sebastian Ott
> <sebott@...ux.vnet.ibm.com>; Parav Pandit <parav@...lanox.com>; linux-
> rdma@...r.kernel.org; linux-kernel@...r.kernel.org; Bart Van Assche
> <bart.vanassche@...disk.com>; Bjorn Helgaas <bhelgaas@...gle.com>;
> Benjamin Herrenschmidt <benh@...nel.crashing.org>; David Woodhouse
> <dwmw2@...radead.org>; H . Peter Anvin <hpa@...or.com>; Ingo Molnar
> <mingo@...hat.com>; Russell King <linux@...linux.org.uk>
> Subject: [PATCH 1/2] device: Stop requiring that struct device is embedded in
> struct pci_dev
> 
> The dma mapping operations of several architectures and also of several I/O
> MMU implementations need to translate a struct device pointer into a struct
> pci_dev pointer. This translation is performed by to_pci_dev(). That macro
> assumes that struct device is embedded in struct pci_dev. However, that is
> not the case for the device structure in struct ib_device. Since that device

Why can't ib subsystem pass device structure that is embedded in pci_dev when it makes calls to dma_map APIs?
The whole point of clean up was to avoid an if() condition in hot datapath.
If we invoke dma_map_ and friend functions with right device, shouldn't it work?
That avoids the if() condition as well and avoids changing core of Linux like done in this bug fix.
I think ib_device should store the right struct device pointer that needs to go to dma_apis, rather than including pci_dev structure pointer in device core 
layer.

Pseudo example code:
struct ib_device {
	struct device *dma_device;
};

ib_dma_unmap_single() which had if(), that got removed with dma_unmap_single() with cleanup patch.

Instead of,
static inline void ib_dma_unmap_single(struct ib_device *dev,
                                       u64 addr, size_t size,
                                       enum dma_data_direction direction)
{
	dma_unmap_single(&dev->dev, addr, size, direction);
}

Why can't we do this?

static inline void ib_dma_unmap_single(struct ib_device *dev,
                                       u64 addr, size_t size,
                                       enum dma_data_direction direction)
{
	dma_unmap_single(dev->dma_device, addr, size, direction);
}

This avoids increasing all device size by 8 bytes in system.
It also clean approach where core device structure doesn't have to bother for pci_dev.