linux-kernel - Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1528460647.2289.85.camel@codethink.co.uk>
Date:   Fri, 08 Jun 2018 13:24:07 +0100
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Joe Jin <joe.jin@...cle.com>,
        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 Thu, 2018-06-07 at 13:59 -0700, Joe Jin wrote:
> 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?

No there isn't, but that wasn't my main point.  Please address the rest
of my message.

Ben.

> 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.
> > 
> 
> 
-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom