From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934368AbcHDWD6 (ORCPT ); Thu, 4 Aug 2016 18:03:58 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:51771 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758987AbcHDWD4 (ORCPT ); Thu, 4 Aug 2016 18:03:56 -0400 Date: Thu, 4 Aug 2016 15:01:45 -0700 From: Andrew Morton To: Mauricio Faria de Oliveira Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, corbet@lwn.net, rmk+kernel@arm.linux.org.uk, keith.busch@intel.com, axboe@fb.com, benh@kernel.crashing.org, mpe@ellerman.id.au, k.kozlowski@samsung.com Subject: Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute Message-Id: <20160804150145.fb5690e9a873121db1dfa0b1@linux-foundation.org> In-Reply-To: <1470092390-25451-1-git-send-email-mauricfo@linux.vnet.ibm.com> References: <1470092390-25451-1-git-send-email-mauricfo@linux.vnet.ibm.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Aug 2016 19:59:47 -0300 Mauricio Faria de Oliveira wrote: > This patchset introduces dma_attr DMA_ATTR_NO_WARN (just like __GFP_NOWARN), > which tells the DMA-mapping subsystem to suppress allocation failure reports. > > On some architectures allocation failures are reported with error messages > to the system logs. Although this can help to identify and debug problems, > drivers which handle failures (eg, retry later) have no problems with them, > and can actually flood the system logs with error messages that aren't any > problem at all, depending on the implementation of the retry mechanism. It would help to have seen an example of the error message - please always quote such things when fixing bugs. I assume the warnings are coming via nvme_map_data()'s call to blk_rq_map_sg()? 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.