linux-kernel - Re: [PATCH v4 1/3] USB: use genalloc for USB HCs with local memory

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: <20190521102835.GA1973@lst.de>
Date:   Tue, 21 May 2019 12:28:35 +0200
From:   Christoph Hellwig <hch@....de>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     laurentiu.tudor@....com, hch@....de, stern@...land.harvard.edu,
        linux-usb@...r.kernel.org, marex@...x.de, leoyang.li@....com,
        linux-kernel@...r.kernel.org, robin.murphy@....com,
        noring@...rew.org, JuergenUrban@....de
Subject: Re: [PATCH v4 1/3] USB: use genalloc for USB HCs with local memory

On Tue, May 21, 2019 at 10:16:57AM +0200, Greg KH wrote:
> > +	if (hcd->driver->flags & HCD_LOCAL_MEM)
> > +		return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
> 
> Does this patch now break things?  hcd->localmem_pool at this point in
> time is NULL, so this call will fail.  There's no chance for any host
> controller driver to actually set up this pool in this patch, so is
> bisection broken?
> 
> I think you fix this up in later patches, right?
> 
> And if so, why do we even need HCD_LOCAL_MEM anymore?  Can't we just
> test for the presence of hcd->localmem_pool in order to determine which
> allocation method to use?

True.  And that also sound like a good bisectability strategy:

 - first add hcd->localmem_pool and test for it
 - convert drivers over to it
 - remove HCD_LOCAL_MEM