linux-kernel - Re: question regarding cacheline size

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

Message-ID: <20060907131034.GC29532@flint.arm.linux.org.uk>
Date:	Thu, 7 Sep 2006 14:10:34 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Tejun Heo <htejun@...il.com>
Cc:	Matthew Wilcox <matthew@....cx>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pci@...ey.karlin.mff.cuni.cz, Greg KH <greg@...ah.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: question regarding cacheline size

On Thu, Sep 07, 2006 at 02:53:57PM +0200, Tejun Heo wrote:
> Matthew Wilcox wrote:
> >On Thu, Sep 07, 2006 at 02:33:25PM +0200, Arjan van de Ven wrote:
> >>>So I think we should redo the PCI subsystem to set cacheline size during
> >>>the buswalk rather than waiting for drivers to ask for it to be set.
> >>... while allowing for quirks for devices that go puke when this
> >>register gets written ;)
> >>
> >>(afaik there are a few)
> >
> >So you want:
> >
> >	unsigned int no_cls:1;	/* Device pukes on write to Cacheline Size */
> >
> >in struct pci_dev?
> 
> The spec says that devices can put additional restriction on supported 
> cacheline size (IIRC, the example was something like power of two >= or 
> <= certain size) and should ignore (treat as zero) if unsupported value 
> is written.  So, there might be need for more low level driver 
> involvement which knows device restrictions, but I don't know whether 
> such devices exist.

The problem is that both ends of the bus need to know the cache line
size for some of these commands to work correctly.

Consider, as in Matthew's case, a read command which wraps at the cache
line boundary.  Unless both the master and slave are programmed with the
same cache line size, it's entirely possible for the wrong memory
locations to be read.

Eg, the device might expect 0x118, 0x11c, 0x100, 0x104, but it actually
gets 0x118, 0x11c, 0x120, 0x124 because the target got programmed with
64 while the master was set to 32.

This is, of course, supposing that the memory read command is used in
the cache line wrap mode.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/