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]

Date:	Wed, 10 Jun 2015 16:09:19 +0300
From:	Dmitry Kalinkin <dmitry.kalinkin@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 Sun, May 31, 2015 at 6:06 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> 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.
>>
>> 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

Greg,

I don't know how to make this happen. I could resend patches CC'ing
previous contributors to linux VME subsystem, and maybe get some
feedback that way.

Also, there are some patches that IMO don't need any special VME
subsystem expertise, namely:
  Documentation: mention vme_master_mmap() in VME API
  vme: ca91cx42: return error code on DMA error
  staging: vme_user: remove unused counters
  staging: vme_user: remove forward declarations
  staging: vme_user: remove open/release
  staging: vme_user: remove buf_unalloc helper
  vme: tsi148: depend on HAS_DMA for Kconfig

Thanks,

Dmitry
--
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/