[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m18vo76k28.fsf@fess.ebiederm.org>
Date: Wed, 26 Oct 2011 23:10:55 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc: konrad.wilk@...cle.com, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] x86 swiotlb: Verify we can perform the remapping requested.
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> writes:
> On Mon, 24 Oct 2011 08:07:31 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> writes:
>>
>> > On Mon, Oct 17, 2011 at 02:19:18PM -0700, Eric W. Biederman wrote:
>> >>
>> >> Recently I had a driver try with a peculiar 2G dma memory limit.
>> >> It failed in weird and strange ways because my bounce buffers were
>> >> being allocated above 2G where the driver could not reach, and
>> >> no error was reported when the mappings were setup.
>> >
>> > OK, so the overflow buffer was used instead.. which presumarily
>> > also was allocated above the 2G? That seems to point that
>> > alloc_bootmem_low_pages is not doing its job?
>>
>> I just looked alloc_bootmem_low_pages allocates memory below
>> ARCH_ADDRESS_LIMIT which for everything except s390 is 4G.
>>
>> I know I was mostly using the amd gart driver. So I may be mistaken
>> that the swiotlb driver had the same issue. However my only solution
>> at the time was to boot with mem=2G. So I believe the swiotlb did
>> have this issue.
>>
>> Mostly the patch was. Hmm. That looks stupid not wiring up the
>> swiotlb address space limit check when someone has already written it.
>
> http://www.gossamer-threads.com/lists/linux/kernel/1333685?do=post_view_threaded#1333685
>
> swiotlb isn't designed to handle hardware having odd dma mask (e.g. 2G
> or something). Such device needs the own bouncing mechanism.
I have no problem with that with not supporting weird dma masks.
There is a perfectly fine method to report an unsupported dma mask
programmatically that just needs a trivial code change to be wired up.
I just want the method to be wired up on x86 so that we fail gracefully,
instead of mysteriously.
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