linux-kernel - Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO

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:	Thu, 4 Aug 2016 18:05:01 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mauricio Faria de Oliveira <mauricfo@...ux.vnet.ibm.com>
Cc:	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-nvme@...ts.infradead.org, corbet@....net,
	rmk+kernel@....linux.org.uk, keith.busch@...el.com, axboe@...com,
	benh@...nel.crashing.org, mpe@...erman.id.au,
	k.kozlowski@...sung.com
Subject: Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the
 DMA_ATTR_NO_WARN attribute

On Thu, 4 Aug 2016 21:17:27 -0300 Mauricio Faria de Oliveira <mauricfo@...ux.vnet.ibm.com> wrote:

> > [snip] An alternative (and more idiomatic) fix would be to
> > change the blk_rq_map_sg() interface to permit passing down some
> > foo_NOWARN flag and propagating that down the stack into
> > ppc_iommu_map_sg().  Was this approach evaluated?  I suspect it might
> > be messy.
> 
> I see; I haven't evaluated that, but agree with you it might be messy.
> 
> As far as I can see, in order to pass something to blk_rq_map_sg() and
> have it eventually make into ppc_iommu_map_sg(), that something should
> be present in the scatterlist -- which seems to be what's common/passed
> to both blk_rq_map_sg() (the interface point proposed) and dma_map_sg() 
> (which is the function which reaches ppc_iommu_map_sg() down the chain).
> 
> It seems a bit hidden, and (if I got the suggestion right), it doesn't
> seem to be in the scope of scatterlist to contain such a flag.
> 
> One point of the patches is make the attribute visible/explicit; I see
> it can be inconvenient sometimes, but it allows for a clear / evident
> difference between dma_map_sg() calls which are (not) OK with failures.
> 
> (for example, the 2 calls in nvme_map_data() - they can return either
> BLK_MQ_RQ_QUEUE_BUSY or BLK_MQ_RQ_QUEUE_ERROR - so the former is OK.)

Of course, the alternative is to just delete the damn warnings from
ppc_iommu_map_sg().  Imagine that!  Have they ever been of any use to
anyone?