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
| ||
|
Message-ID: <98026867-fce0-da60-6b66-e50dfcf884b4@arm.com> Date: Tue, 4 Oct 2022 12:10:22 +0100 From: Robin Murphy <robin.murphy@....com> To: Rob Herring <robh@...nel.org> Cc: linux-arm-kernel@...ts.infradead.org, robh+dt@...nel.org, frowand.list@...il.com, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Serge Semin <Sergey.Semin@...kalelectronics.ru> Subject: Re: [PATCH v2] of: Fix "dma-ranges" handling for bus controllers On 2022-09-30 20:39, Rob Herring wrote: > On Thu, 29 Sep 2022 13:48:38 +0100, Robin Murphy wrote: >> Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes") >> relaxed the handling of "dma-ranges" for any leaf node on the assumption >> that it would still represent a usage error for the property to be >> present on a non-bus leaf node. However there turns out to be a fiddly >> case where a bus also represents a DMA-capable device in its own right, >> such as a PCIe root complex with an integrated DMA engine on its >> platform side. In such cases, "dma-ranges" translation is entirely valid >> for devices discovered behind the bus, but should not be erroneously >> applied to the bus controller device itself which operates in its >> parent's address space. Fix this by restoring the previous behaviour for >> the specific case where a device is configured via its own OF node, >> since it is logical to assume that a device should never represent its >> own parent bus. >> >> Reported-by: Serge Semin <Sergey.Semin@...kalelectronics.ru> >> Signed-off-by: Robin Murphy <robin.murphy@....com> >> --- >> >> v2: Fix !HAS_DMA build error >> >> drivers/of/address.c | 4 +++- >> drivers/of/device.c | 9 ++++++++- >> drivers/of/of_private.h | 5 +++++ >> 3 files changed, 16 insertions(+), 2 deletions(-) >> > > Applied, thanks! > > I assume this was not tagged with Fixes or stable because there is not > yet a user that needs it? I didn't add it either because I'm a bit > worried about regressions and applying this just before the merge > window. So send it to stable later if anyone cares. Indeed this was only brought to light by a patch series that Serge is working on, so although it's technically a fix I don't believe it's affecting any in-tree users yet, thus doesn't warrant backporting. Cheers, Robin.
Powered by blists - more mailing lists