linux-kernel - Re: [PATCH 1/9] xen: make sure swiotlb allocation is physically contigious

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]

Message-ID: <4A0871A2.9050502@goop.org>
Date:	Mon, 11 May 2009 11:42:42 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Joerg Roedel <joro@...tes.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: [PATCH 1/9] xen: make sure swiotlb allocation is physically	contigious

Joerg Roedel wrote:
>> +}
>> +
>> +void *swiotlb_alloc(unsigned order, unsigned long nslabs)
>> +{
>> +	/* Never called on x86.  Warn, just in case. */
>>     
>
> Can't this function be removed completly then?
>   

The swiotlb code contains a static call, which never ends up being 
executed, so there has to be something to be called.  But you're right 
that there's no particular reason for this warning unless someone starts 
to call swiotlb_alloc in the future.

I'd briefly discussed the idea of eliminating the distinction between 
boot and post-boot swiotlb allocation, but it looks tricky to implement.

>> +
>> +	if (xen_create_contiguous_region((unsigned long)buf,
>> +					 order, 0xffffffff))
>>     
>                                                 DMA_32BIT_MASK?
>   

OK (ditto other mentions).

    J
--
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/