linux-kernel - Re: USB transfer_buffer allocations on 64bit systems

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]

Message-ID: <20100412125421.GX30801@buzzloop.caiaq.de>
Date:	Mon, 12 Apr 2010 14:54:21 +0200
From:	Daniel Mack <daniel@...aq.de>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Pedro Ribeiro <pedrib@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Greg KH <gregkh@...e.de>, alsa-devel@...a-project.org,
	linux-usb@...r.kernel.org
Subject: Re: USB transfer_buffer allocations on 64bit systems

On Mon, Apr 12, 2010 at 02:47:08PM +0200, Andi Kleen wrote:
> On Mon, Apr 12, 2010 at 02:32:38PM +0200, Daniel Mack wrote:
> > Another detail I can't explain is that on his machine, the kernel oopses
> > when kmalloc() with GFP_DMA32 is used. The patch to try this also only
> > touched the allocation in sound/usb/caiaq/audio.c.
> 
> Where did it oops?

Pedro sent me an image:

  http://caiaq.de/download/tmp/GFP_DMA32.JPG

The patch I sent him for testing and that lead to this Oops was:

> diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c                                                                              
> index 4328cad..26013be 100644                                                                                                               
> --- a/sound/usb/caiaq/audio.c                                                                                                               
> +++ b/sound/usb/caiaq/audio.c                                                                                                               
> @@ -560,7 +560,7 @@ static struct urb **alloc_urbs(struct snd_usb_caiaqdev *dev, int dir, int *ret)                                         
>                }                                                                                                                            
>                                                                                                                                             
>                urbs[i]->transfer_buffer =                                                                                                   
> -                       kmalloc(FRAMES_PER_URB * BYTES_PER_FRAME, GFP_KERNEL);                                                              
> +                       kmalloc(FRAMES_PER_URB * BYTES_PER_FRAME, GFP_KERNEL | GFP_DMA32);                                                  
>                if (!urbs[i]->transfer_buffer) {                                                                                             
>                        log("unable to kmalloc() transfer buffer, OOM!?\n");                                                                 
>                        *ret = -ENOMEM;                                                                                                      
>                                                                                                                                             


> >   http://caiaq.de/download/tmp/pedro-dmesg
> 
> The system seems to set up the soft iotlb correctly.
> 
> [    0.468472] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [    0.468539] Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000
> [    0.468610] software IO TLB at phys 0x20000000 - 0x24000000
> 
> Also if that was wrong a lot more things would go wrong.
> 
> I would suspect the driver. Are you sure:
> 
> - it sets up it's dma_masks correctly?
> - it uses pci_map_single/sg correctly for all transferred data?

Well, the sound driver itself doesn't care for any of those things, just
like any other USB driver doesn't. The USB core itself of the host
controller driver should do, and as far as I can see, it does that, yes.

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/