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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD00A24FC@AcuExch.aculab.com>
Date:   Wed, 25 Oct 2017 09:36:37 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Jim Quinlan' <jim2101024@...il.com>
CC:     Christoph Hellwig <hch@....de>,
        Robin Murphy <robin.murphy@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Linux-MIPS <linux-mips@...ux-mips.org>,
        "Florian Fainelli" <f.fainelli@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        "Kevin Cernekee" <cernekee@...il.com>,
        Will Deacon <will.deacon@....com>,
        "Ralf Baechle" <ralf@...ux-mips.org>,
        Rob Herring <robh+dt@...nel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        "Gregory Fong" <gregory.0xf0@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Brian Norris <computersforpeace@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound
 traffic

From: Jim Quinla
> Sent: 24 October 2017 19:08
...
> Hi David,  Christoph was also concerned about this:
> 
> "For the block world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment.  You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer."
> 
> Do you consider this a non-issue as well or can this happen and span
> memory regions?

Probably easiest to have an architecture limit on the addresses that
can be merged.

My guess is that this code only really ever merges pages that were
allocated contiguously, but have got converted to a list of VA.
So stopping merging over even 1MB boundaries would have minimal effect
(even if done unconditionally).

I even wonder if the merging is actually worthwhile at all?
Maybe if any code has limits on the SG list length.
(or reducing the number of cache lines the get dirtied...)

	David



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ