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: <CAPTm99UUA0Oe40uH73Rj8_hvyMYwuxcKhFvU_KVZxmKpR1jn2Q@mail.gmail.com>
Date:	Wed, 5 Nov 2014 18:25:51 +0530
From:	Ankit Jindal <ankit.jindal@...aro.org>
To:	Kumar Gala <galak@...eaurora.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"patches@....com" <patches@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>,
	Tushar Jagad <tushar.jagad@...aro.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Varka Bhadram <varkabhadram@...il.com>
Subject: Re: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

Hi Kumar,

On 31 October 2014 19:09, Kumar Gala <galak@...eaurora.org> wrote:
>
> On Oct 31, 2014, at 4:30 AM, Ankit Jindal <ankit.jindal@...aro.org> wrote:
>
>> Hi Kumar,
>>
>> On 21 October 2014 12:08, Kumar Gala <galak@...eaurora.org> wrote:
>>>
>>> On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@...aro.org> wrote:
>>>
>>>> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
>>>> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
>>>> UIO driver export physcial memory to user space as non-cacheable
>>>> user memory. Typcially memory-mapped registers of a device are exported
>>>> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
>>>> is not efficient if dma-capable devices are capable of maintaining coherency
>>>> with CPU caches.
>>>>
>>>> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
>>>> cacheable access to physical memory from user space.
>>>>
>>>> Signed-off-by: Ankit Jindal <ankit.jindal@...aro.org>
>>>> Signed-off-by: Tushar Jagad <tushar.jagad@...aro.org>
>>>> ---
>>>> drivers/uio/uio.c          |   11 ++++++++---
>>>> include/linux/uio_driver.h |    1 +
>>>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don’t need to keep adding types for various different cache attributions in the future.
>>
>> Do you mean to add a new field pgprot_t in the memtype structure and
>> uio_mmap_physical will set vma->vm_page_prot to this value provided by
>> driver ? If this is the case then we will need to change all the
>> current uio based drivers which was the reason I preferred to have a
>> new mem type.
>>
>> Please let me know if I have misunderstood anything.
>
> I’m suggeting in uio_mmap_physical to do something like:
>
> if (idev->info->set_pgprot)
>         idev->info->set_pgprot(vma->vm_page_prot)
> else
>         vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> And add a set_prprot callback to 'struct uio_info’.
>
> Here’s patch from several years ago:
>
> http://patchwork.ozlabs.org/patch/119224/

The suggested solution looks okey but not sure whether there is any
available drivers using different combinations. Also, I looked at the
available pgprot routines, looks like only pgprot_noncached and
pgprot_writecombine are the available ones. So if we are not going to
use these pgprot routines then driver might have architecture
dependent switches, which we should avoid.

Thanks,
Ankit
>
> - k
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ