Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935454AbeAIUEn (ORCPT + 1 other); Tue, 9 Jan 2018 15:04:43 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:57470 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbeAIUEm (ORCPT ); Tue, 9 Jan 2018 15:04:42 -0500 Date: Tue, 9 Jan 2018 15:04:17 -0500 From: Konrad Rzeszutek Wilk To: Christoph Hellwig Cc: christian.koenig@amd.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5 Message-ID: <20180109200417.GB19756@char.us.oracle.com> References: <20180104132419.24536-1-christian.koenig@amd.com> <20180104132919.GA7213@infradead.org> <7e470dfb-563f-2de4-7247-2949a528c6f6@gmail.com> <20180109194755.GA7283@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20180109194755.GA7283@infradead.org> User-Agent: Mutt/1.8.3 (2017-05-23) Content-Transfer-Encoding: 8BIT X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8769 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=921 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801090273 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 09, 2018 at 11:47:55AM -0800, Christoph Hellwig wrote: > On Thu, Jan 04, 2018 at 02:49:21PM +0100, Christian K?nig wrote: > > I perfectly agree on that, but this is for stable kernel backports. Because > > of this I want to keep the footprint as low as possible. > > > > When your patchset to clean that up lands for 4.16 I have no problem > > changing that. > > > > But till then I think we should just work on suppress the warning for now. > > Oh well. If Konrad is fine with that I'll stick it in front of my > swiotlb series (the next post is going to be split) with a stable tag, > so everything is well integrated. Totally. Thanks for taking care of it - been slammed with x86 architecture craziness.