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  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:	Sat, 17 Mar 2012 08:39:08 +0200
From:	Ohad Ben-Cohen <>
	Brian Swetland <>,
	Iliyan Malchev <>,
	Arnd Bergmann <>,
	Grant Likely <>,
	Rusty Russell <>,
	Mark Grosen <>,
	John Williams <>,
	Loic PALLARDY <>,
	Ludovic BARRE <>,
	Omar Ramirez Luna <>,
	Guzman Lugo Fernando <>,
	Anna Suman <>, Clark Rob <>,
	Stephen Boyd <>,
	Saravana Kannan <>,
	David Brown <>,
	Kieran Bingham <>,
	Tony Lindgren <>
Subject: Re: [PATCH 1/7] remoteproc: resource table overhaul

Hi Michal,

On Fri, Mar 16, 2012 at 4:57 PM, Michal Simek <> wrote:
> In previous version I had carverout first which means that code was copyied
> to physical address 0x0 and then vrigns were allocated. Current code
> allocate vring first and then RTOS is not able to run from zero address.

In general, depending on specific allocation ordering is error prone
and you shouldn't do it.

For a given device, we treat memory allocated with
dma_alloc_coherent() as homogeneous. We care about its utilization and
alignments of allocations rather than their specific location in the
total region.

If that's not the case, and there's special memory you want assigned
with a specific purpose, than it's recommended to let the code make
sure it happens explicitly, and not rely on implicit order of

Today there's no way to assign several memory regions with a specific
device, but a reasonable workaround that's being used is creating
several sub-devices with the special memory, and then looking them up
with stuff like device_for_each_child() or device_find_child().

About your specific issue: the current allocation scheme was chosen
for simplicity, but I do plan to change it back by postponing the
vring dma allocation until a remote processor is really powered on.
It's not a lot of memory, but this way we'd only allocate it when
really needed (so if it's CMA, others could use it).

IOW: you can probably just wait a bit until this patch is ready and
take it into your tree. It will most likely bring back the behavior you
need :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists