Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759304AbcDHXLF (ORCPT ); Fri, 8 Apr 2016 19:11:05 -0400 Received: from mail-vk0-f42.google.com ([209.85.213.42]:35514 "EHLO mail-vk0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759281AbcDHXLE (ORCPT ); Fri, 8 Apr 2016 19:11:04 -0400 MIME-Version: 1.0 In-Reply-To: <20160408065626.GA25580@e106921-lin.trondheim.arm.com> References: <1460028599-22356-1-git-send-email-john.reitan@foss.arm.com> <5706B70E.4040004@redhat.com> <20160408065626.GA25580@e106921-lin.trondheim.arm.com> Date: Fri, 8 Apr 2016 16:11:01 -0700 Message-ID: Subject: Re: [PATCH] ion: scatterlist offset not used for buffer map From: Colin Cross To: Laura Abbott , Greg KH , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "devel@driverdev.osuosl.org" , lkml Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1380 Lines: 28 On Thu, Apr 7, 2016 at 11:56 PM, John Einar Reitan wrote: > On Thu, Apr 07, 2016 at 12:37:50PM -0700, Laura Abbott wrote: >> On 04/07/2016 04:29 AM, John Einar Reitan wrote: >> > ion's default user/kernel page mapping code don't honor the offset >> > option for scatterlists. It uses sg_page and expect the whole page to be >> > mapped, while the offset could dictate an offset within a large page. >> > >> > sg_phys correctly accounts for the offset, so should be used instead. >> > >> >> Can you be more specific about which heap and which allocation pattern >> is exposing this bug? > > The heap that exposed the bug is one I'm developing and will be posting > as a RFC soon. It uses compound pages and an sub-divides it into surface > buffers. The ion buffers are configured to hold sgl's with the compound > page and the correct offset of the buffer, via > sg_set_page(.., compound_page, .., offset_of_logical_buffer); I don't think this is right. A compound_page still has a page struct for every page, you should be passing the page struct where your data starts. Using an offset > PAGE_SIZE is going to break lots of places, for example anywhere that uses kmap(sg_page(sg)). > sg_phys/sg_virt includes this offset, but if you poke the sg and extract > the page with sg_page yourself you must include this offset in your > calculations too.