linux-kernel - Re: [PATCH 1/2] x86 swiotlb: Verify we can perform the remapping requested.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/