linux-kernel - Re: [PATCHv5] staging: vme_user: provide DMA functionality

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] [day] [month] [year] [list]

Message-ID: <CAPk1OjGp6RJ2M3j-HFNDGBfLMUMJBnS2ZV8QxEgkBMrhq9Jzmg@mail.gmail.com>
Date:	Mon, 19 Oct 2015 11:46:23 +0200
From:	Alessio Igor Bogani <alessioigorbogani@...il.com>
To:	Dmitry Kalinkin <dmitry.kalinkin@...il.com>
Cc:	Martyn Welch <martyn@...chs.me.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Manohar Vanga <manohar.vanga@...il.com>,
	devel@...verdev.osuosl.org, LKML <linux-kernel@...r.kernel.org>,
	Igor Alekseev <igor.alekseev@...p.ru>
Subject: Re: [PATCHv5] staging: vme_user: provide DMA functionality

Hi,

On 19 October 2015 at 11:19, Dmitry Kalinkin <dmitry.kalinkin@...il.com> wrote:
[...]
> There is no optimal solution. In vanilla kernel you have just two drivers. You
> can either have 8 GE PIO2 boards or 4 GE PIO2 boards and any amount of boards
> potentially accessible through vme_user. None of this provides for the case
> when you have a crate with more than 8 GE PIO2 boards in it. Indeed, if you
> have built your little proprietary system around one or two drivers so it just
> fits using up all of the DMA resources and you somehow still need vme_user,
> this patch will surely break it for you. But if we really care about *all*
> users then there is no difference in how much resources are used by any driver,
> there is always a setup for which they won’t be enough.
>> The number of VME windows is limited, so having a user space shim either hog or limit the number of resources available either in kernel space or user space is not an optimal solution.
> How vme_user is different from proprietary driver A to deserve such discrimination?
> Would it be more optimal if proprietary driver A would take less resources that
> could have otherwise been exposed to the userspace?
>
> I agree that due to the nature of vme_user it should have some knobs to tune
> it’s resource consumption, but I don’t think these should be some special ugly
> knobs that only a userspace driver gets. The solution could have been to use
> same kind of module params as in vme_pio2. But instead of implementing that, I
> spent my time unknowingly arguing over whether mainline kernel developers
> should be denied breaking certain proprietary systems lurking in the shadow of
> the VME subsystem. Wonderful.

IMHO VME stack should handle bus resources dynamically not matter from
where the requests come from (user-space or kernel-space).

Ciao,
Alessio
--
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/