[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whxf0zqutExPr_j1A625Z3gcL6k_ABzKo1BtzN4F93hkA@mail.gmail.com>
Date: Thu, 22 Nov 2018 09:55:25 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: robin.murphy@....com
Cc: linux@...linux.org.uk, Christoph Hellwig <hch@....de>,
linux-arch@...r.kernel.org, linux-alpha@...r.kernel.org,
linux-ia64@...r.kernel.org, linux-parisc@...r.kernel.org,
David Woodhouse <dwmw2@...radead.org>, joro@...tes.org,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
iommu@...ts.linux-foundation.org, jdmason@...zu.us,
xen-devel@...ts.xenproject.org,
linux-arm-kernel@...ts.infradead.org, m.szyprowski@...sung.com
Subject: Re: remove the ->mapping_error method from dma_map_ops V2
On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy <robin.murphy@....com> wrote:
>
> Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> systems in general, "the top 4095" values may well still be valid
> addresses -
Ugh.
> The only immediate benefit I can see is that we could distinguish cases
> like the first which can never possibly succeed, and thus callers could
> actually give up instead of doing what various subsystems currently do
> and retry the exact same mapping indefinitely on the apparent assumption
> that errors must be transient.
No, the big immediate benefit of allowing "return -EINVAL" etc is
simply legibility and error avoidance.
It's basically how pretty much all the rest of the kernel returns
errors, so not only is it very obvious, it's also what people do
without even thinking.. So it would be good to work.
Linus
Powered by blists - more mailing lists