Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756930AbcDHG4d (ORCPT ); Fri, 8 Apr 2016 02:56:33 -0400 Received: from foss.arm.com ([217.140.101.70]:37968 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751957AbcDHG4c (ORCPT ); Fri, 8 Apr 2016 02:56:32 -0400 Date: Fri, 8 Apr 2016 08:56:27 +0200 From: John Einar Reitan To: Laura Abbott Cc: gregkh@linuxfoundation.org, arve@android.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ion: scatterlist offset not used for buffer map Message-ID: <20160408065626.GA25580@e106921-lin.trondheim.arm.com> Mail-Followup-To: Laura Abbott , gregkh@linuxfoundation.org, arve@android.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org References: <1460028599-22356-1-git-send-email-john.reitan@foss.arm.com> <5706B70E.4040004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5706B70E.4040004@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1006 Lines: 21 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); 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.