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:   Thu, 7 Jun 2018 13:59:49 -0700
From:   Joe Jin <joe.jin@...cle.com>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        John Sobecki <john.sobecki@...cle.com>,
        Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for
 xen_swiotlb_free_coherent

On 6/7/18 1:28 PM, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Joe Jin <joe.jin@...cle.com>
>>
>> commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
>>
>> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
>> but Dom Heap is increased by the same size. Tracing raidconfig we found
>> that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
>> to apply memory. If the memory allocated by Dom0 is not in the DMA area,
>> it will exchange memory with Xen to meet the requiment. Later drivers
>> call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
>> the check condition (dev_addr + size - 1 <= dma_mask) is always false,
> 
> I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.

Hi Ben,

Yes you are right, sorry I made the mistake, thanks for catch it.
Is there any way to fix description from git repo?

Regards,
Joe

> the condition that is replaced by this commit.  If that's always false,
> the new condition (the logical inverse) must always be true.
> 
> [...]
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotlb-xen.c
>> @@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
>>  	 * physical address */
>>  	phys = xen_bus_to_phys(dev_addr);
>>  
>> -	if (((dev_addr + size - 1 > dma_mask)) ||
>> +	if (((dev_addr + size - 1 <= dma_mask)) ||
>>  	    range_straddles_page_boundary(phys, size))
>>  		xen_destroy_contiguous_region(phys, order);
>>  
> 
> So now we will always call xen_destroy_contiguous_region(), whether or
> not xen_create_contiguous_region() was called during allocation.  Is
> that really the intent?  If so, the entire condition could be removed
> to make this clear.
> 
> Alternately, if the commit message is correct, the condition could be
> simplified to range_straddles_page_boundary(...).
> 
> But I'm not at all convinced that either of these is correct.  It seems
> like you need to either find a way of distinguishing between memory
> allocated with or without the use of xen_create_contiguous_region(), or
> to use it unconditionally.
> 
> Ben.
> 


-- 
Oracle <http://www.oracle.com>
Joe Jin | IT Director 
ORACLE | Production Engineering and Operations
600 Oracle Parkway Redwood City, CA US 94065

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ