linux-kernel - Re: [PATCHv3 00/16] vme DMA and user space driver improvements

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: <20150531030611.GA10021@kroah.com>
Date:	Sun, 31 May 2015 12:06:11 +0900
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Dmitry Kalinkin <dmitry.kalinkin@...il.com>
Cc:	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	Martyn Welch <martyn.welch@...com>,
	Manohar Vanga <manohar.vanga@...il.com>,
	Igor Alekseev <igor.alekseev@...p.ru>
Subject: Re: [PATCHv3 00/16]  vme DMA and user space driver improvements

On Thu, May 28, 2015 at 03:06:57PM +0300, Dmitry Kalinkin wrote:
> The first item in this submission documents previously introduced
> vme_master_mmap() call. Following, there are three fixes for the tsi148
> driver's DMA.  There was one bug that rendered it imposible to use DMA
> lists with more than one item. The other was related to the place where
> dma_map_single was called on the first DMA descriptor in the DMA list. The     
> last bug was about DMA transfer not stopping at interruption by signal,        
> which is a possible DoS attack vector. I also made an attempt to fix the
> same issue in the ca91cx42 driver. I don't have access to this hardware to
> test, so this is based only on my understanding of the datasheet (checked      
> ca91c042's errata as well).
> 
> A new /sys/bus/vme/dma0 device with a new ioctl for making DMA transfers
> was introduced in vme_user driver. The logic of the function is similar to     
> the one found in existing drivers.
> 
> One question that I had while implementing this feature was whether we         
> should keep vme_dma_attr objects until vme_dma_list_exec() call. API
> doesn't specify this, the existing vme bridge drivers copy all information
> from attributes during vme_dma_list_add(). So for simplicity this              
> implementation frees vme_dma_attr's before vme_dma_list_exec() is done.        
> 
> A simple test against AVM16 board displays speeds around 45 MiB/s for
> A32/D32 reads for both BLT and MBLT (with MBLT being slightly faster).         
>  
> Changes in v2 [patches 1-6, now 1-5 and 8]:
>  * vme_addr check for vme_user DMA                                             
>  * limit on DMA operation length in vme_user
>  * reorder dma_op ioctl struct to omit __packed attribute                     
>  * change dma_op->write into dma_op->dir                                       
>  * use vme_check_window assure DMA operation correctness                       
> 
> New changes include vme_user code cleanup, a couple of ca91cx42 fixes
> (again, tested for compilation only).
> 
> I also propose a change to export some of VME subsytem related constants
> to the user space. These can be useful if vme_user is to go into the kernel.
> Also, email
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2012-July/029084.html
> mentions that we probably can now get rid of this comment:
> > /* XXX  We do not want to push aspace, cycle and width
> >  *      to userspace as they are
> >  */
> 
> v3 adresses code style problems

I need an ack from the VME maintainer before I can take these...

thanks,

greg k-h
--
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/