From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756629Ab3AICbb (ORCPT ); Tue, 8 Jan 2013 21:31:31 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:41972 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755853Ab3AICba (ORCPT ); Tue, 8 Jan 2013 21:31:30 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Yinghai Lu Cc: Konrad Rzeszutek Wilk , Shuah Khan , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Morton , Borislav Petkov , Jan Kiszka , Jason Wessel , linux-kernel@vger.kernel.org, Joerg Roedel References: <20130107152622.GD3219@phenom.dumpdata.com> <8762382z2c.fsf@xmission.com> <87y5g4z7rp.fsf@xmission.com> <20130109004340.GA12234@konrad-lan.dumpdata.com> <87txqruq8p.fsf@xmission.com> Date: Tue, 08 Jan 2013 18:31:20 -0800 In-Reply-To: (Yinghai Lu's message of "Tue, 8 Jan 2013 17:12:02 -0800") Message-ID: <87lic3ulxj.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+432dWVuRTXVI8cTUo7Sn8/huOo9KLC2Y= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 2.9 KHOP_BIG_TO_CC Sent to 10+ recipients instaed of Bcc or a list * 3.0 XMDrug1234561 Drug references * 0.1 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Yinghai Lu X-Spam-Relay-Country: Subject: Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yinghai Lu writes: > On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu wrote: >> On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman wrote: >> >>> >>> So instead we need to say? >>> >>> + if (no_iotlb_memory) >>> + panic("Cannot allocate SWIOTLB buffer"); >>> + >>> >>> Which is just making the panic a little later than it used to be and >>> seems completely reasonable. >> >> yes, looks some driver just use map_single without checking results. > > update one. > > later could have another patch to shrink size... It does look better. Reading the code I am still left with the question why do the nopanic handling at all? Since the code effectively moves the panic to later. Why can't other architectures use the same panic handling as x86? Eric