Re: Question regarding SLAB corruption

[Keir Fraser <keir@xensource.com>]

On 9/7/07 18:42, "Lukas Hejtmanek" <xhejtman@ics.muni.cz> wrote:

> On Mon, Jul 09, 2007 at 06:21:24PM +0100, Keir Fraser wrote:
>> By my understanding, the infiniband driver is doing an order-6 allocation,
>> then stuffing that multi-page region into a single element of a scatterlist.
>> It is then calling dma_map_sg(), which [on Xen] calls swiotlb_map_sg(),
>> which calls map_single() on that multi-page extent. Am I misunderstanding
>> something?
> 
> Not exactly.
> 
> IB driver does alloc_pages (order-6). Then it calls pci_map_sg() which is
> basically dma_map_sg(). This one invokes swiotlb_map_sg() which possibly calls
> map_single() (right now I'm not sure, I must check it, but if yes, it creates
> index 3328).
> 
> Then later, IB driver invokes dma_sync_single on the first page from that
> order-6 allocation via dma_handle. And in __sync_single it crashes because
> sync_single picks up index 3332 instead of 3328.
> 
> Btw, please, keep Roland in Cc.

Oh! I take it then that the infiniband driver will call sync_single() on
subsections of a mapped region? I haven't seen that behaviour before and it
will kill lib/swiotlb.c (the generic Linux swiotlb implementation) just as
surely as it does the Xen-specific swiotlb!

We could make the swiotlb robust to this treatment, I guess. It will involve
initialising all covered io_tlb_orig_addr[] slots rather than just the
first. You could even have a go at this yourself if you like: rather than
initialising a single slot at the end of map_single(), you'd have a for-loop
to iterate over each allocated swiotlb slab.

 -- Keir