From: Christoph Hellwig <hch@lst.de>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
x86@kernel.org, Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: remove NULL struct device support in the DMA API
Date: Wed, 3 Apr 2019 21:42:20 +0200 [thread overview]
Message-ID: <20190403194220.GA30376@lst.de> (raw)
In-Reply-To: <20190403182640.2ca6w2hngjqp35mt@shell.armlinux.org.uk>
On Wed, Apr 03, 2019 at 07:26:40PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> > We still have a few drivers which pass a NULL struct device pointer
> > to DMA API functions, which generally is a bad idea as the API
> > implementations rely on the device not only for ops selection, but
> > also the dma mask and various other attributes, and many implementations
> > have been broken for NULL device support for a while.
>
> I think I must be missing something, but...
>
> My understanding is that ISA DMA is normally limited to 24 bits of
> address
Yes.
> - indeed, the x86 version only programs 24 bits of DMA address.
> Looking through this series, it appears that the conversions mean that
> the DMA mask for ISA becomes the full all-ones DMA mask, which would
> of course lead to memory corruption if only 24 bits of the address end
> up being programmed into the hardware.
In the generic dma mapping code no struct device has always meant a
32-bit DMA mask - take a look at the dma_get_mask() function.
> Maybe you could say why you think this series is safe in regard to ISA
> DMA?
ISA DMA has always been rather painful in a myriad of ways, and the
DMA API so far hasn't helped, given that we don't do bounce buffering
for the 24-bit limit, but just the higher limits. So far even if you
do use the DMA API and pass a device ISA DMA so far always meant
that the higher layers had to assure things are addressable, either
by using GFP_DMA allocation in the drivers, or mid-layer hacks like
the unchecked_isa_dma flag in SCSI and/or BLK_BOUNCE_ISA in the
block layer.
This series doesn't change those facts at all. I have some half
started series to clean some of this up but it isn't high up on
the priority list.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
x86@kernel.org, Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: remove NULL struct device support in the DMA API
Date: Wed, 03 Apr 2019 19:42:20 +0000 [thread overview]
Message-ID: <20190403194220.GA30376@lst.de> (raw)
In-Reply-To: <20190403182640.2ca6w2hngjqp35mt@shell.armlinux.org.uk>
On Wed, Apr 03, 2019 at 07:26:40PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> > We still have a few drivers which pass a NULL struct device pointer
> > to DMA API functions, which generally is a bad idea as the API
> > implementations rely on the device not only for ops selection, but
> > also the dma mask and various other attributes, and many implementations
> > have been broken for NULL device support for a while.
>
> I think I must be missing something, but...
>
> My understanding is that ISA DMA is normally limited to 24 bits of
> address
Yes.
> - indeed, the x86 version only programs 24 bits of DMA address.
> Looking through this series, it appears that the conversions mean that
> the DMA mask for ISA becomes the full all-ones DMA mask, which would
> of course lead to memory corruption if only 24 bits of the address end
> up being programmed into the hardware.
In the generic dma mapping code no struct device has always meant a
32-bit DMA mask - take a look at the dma_get_mask() function.
> Maybe you could say why you think this series is safe in regard to ISA
> DMA?
ISA DMA has always been rather painful in a myriad of ways, and the
DMA API so far hasn't helped, given that we don't do bounce buffering
for the 24-bit limit, but just the higher limits. So far even if you
do use the DMA API and pass a device ISA DMA so far always meant
that the higher layers had to assure things are addressable, either
by using GFP_DMA allocation in the drivers, or mid-layer hacks like
the unchecked_isa_dma flag in SCSI and/or BLK_BOUNCE_ISA in the
block layer.
This series doesn't change those facts at all. I have some half
started series to clean some of this up but it isn't high up on
the priority list.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: linux-fbdev@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
iommu@lists.linux-foundation.org, Christoph Hellwig <hch@lst.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: remove NULL struct device support in the DMA API
Date: Wed, 3 Apr 2019 21:42:20 +0200 [thread overview]
Message-ID: <20190403194220.GA30376@lst.de> (raw)
In-Reply-To: <20190403182640.2ca6w2hngjqp35mt@shell.armlinux.org.uk>
On Wed, Apr 03, 2019 at 07:26:40PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> > We still have a few drivers which pass a NULL struct device pointer
> > to DMA API functions, which generally is a bad idea as the API
> > implementations rely on the device not only for ops selection, but
> > also the dma mask and various other attributes, and many implementations
> > have been broken for NULL device support for a while.
>
> I think I must be missing something, but...
>
> My understanding is that ISA DMA is normally limited to 24 bits of
> address
Yes.
> - indeed, the x86 version only programs 24 bits of DMA address.
> Looking through this series, it appears that the conversions mean that
> the DMA mask for ISA becomes the full all-ones DMA mask, which would
> of course lead to memory corruption if only 24 bits of the address end
> up being programmed into the hardware.
In the generic dma mapping code no struct device has always meant a
32-bit DMA mask - take a look at the dma_get_mask() function.
> Maybe you could say why you think this series is safe in regard to ISA
> DMA?
ISA DMA has always been rather painful in a myriad of ways, and the
DMA API so far hasn't helped, given that we don't do bounce buffering
for the 24-bit limit, but just the higher limits. So far even if you
do use the DMA API and pass a device ISA DMA so far always meant
that the higher layers had to assure things are addressable, either
by using GFP_DMA allocation in the drivers, or mid-layer hacks like
the unchecked_isa_dma flag in SCSI and/or BLK_BOUNCE_ISA in the
block layer.
This series doesn't change those facts at all. I have some half
started series to clean some of this up but it isn't high up on
the priority list.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-03 19:42 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 22:52 remove NULL struct device support in the DMA API Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` [PATCH 1/7] parport_ip32: pass struct device to DMA API functions Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` [PATCH 2/7] da8xx-fb: " Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-04-03 15:42 ` Bartlomiej Zolnierkiewicz
2019-04-03 15:42 ` Bartlomiej Zolnierkiewicz
2019-04-03 15:42 ` Bartlomiej Zolnierkiewicz
2019-03-21 22:52 ` [PATCH 3/7] gbefb: switch to managed version of the DMA allocator Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-04-01 15:38 ` Bartlomiej Zolnierkiewicz
2019-04-01 15:38 ` Bartlomiej Zolnierkiewicz
2019-04-01 15:38 ` Bartlomiej Zolnierkiewicz
2019-03-21 22:52 ` [PATCH 4/7] pxa3xx-gcu: pass struct device to dma_mmap_coherent Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-04-03 15:43 ` Bartlomiej Zolnierkiewicz
2019-04-03 15:43 ` Bartlomiej Zolnierkiewicz
2019-04-03 15:43 ` Bartlomiej Zolnierkiewicz
2019-03-21 22:52 ` [PATCH 5/7] arm: use a dummy struct device for ISA DMA use of the DMA API Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` [PATCH 6/7] dma-mapping: remove leftover NULL device support Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` [PATCH 7/7] x86: remove the x86_dma_fallback_dev hack Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-21 22:52 ` Christoph Hellwig
2019-03-23 11:28 ` Thomas Gleixner
2019-03-23 11:28 ` Thomas Gleixner
2019-03-23 11:28 ` Thomas Gleixner
2019-04-03 15:35 ` remove NULL struct device support in the DMA API Christoph Hellwig
2019-04-03 15:35 ` Christoph Hellwig
2019-04-03 15:35 ` Christoph Hellwig
2019-04-03 15:35 ` Christoph Hellwig
2019-04-03 18:26 ` Russell King - ARM Linux admin
2019-04-03 18:26 ` Russell King - ARM Linux admin
2019-04-03 18:26 ` Russell King - ARM Linux admin
2019-04-03 19:42 ` Christoph Hellwig [this message]
2019-04-03 19:42 ` Christoph Hellwig
2019-04-03 19:42 ` Christoph Hellwig
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=20190403194220.GA30376@lst.de \
--to=hch@lst.de \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=sudipm.mukherjee@gmail.com \
--cc=x86@kernel.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.