[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lic3ulxj.fsf@xmission.com>
Date: Tue, 08 Jan 2013 18:31:20 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Yinghai Lu <yinghai@...nel.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Shuah Khan <shuahkhan@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Borislav Petkov <bp@...en8.de>, Jan Kiszka <jan.kiszka@....de>,
Jason Wessel <jason.wessel@...driver.com>,
linux-kernel@...r.kernel.org, Joerg Roedel <joro@...tes.org>
Subject: Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it
Yinghai Lu <yinghai@...nel.org> writes:
> On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman <ebiederm@...ssion.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists