linux-kernel - RE: [PATCH] xhci: Cope with VIA VL805 readahead

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: <063D6719AE5E284EB5DD2968C1650D6DD0091748@AcuExch.aculab.com>
Date:   Wed, 11 Oct 2017 15:46:00 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Mathias Nyman' <mathias.nyman@...ux.intel.com>,
        Robin Murphy <robin.murphy@....com>,
        "mathias.nyman@...el.com" <mathias.nyman@...el.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "angelsl@...4.sg" <angelsl@...4.sg>
Subject: RE: [PATCH] xhci: Cope with VIA VL805 readahead

From: Mathias Nyman
> Sent: 11 October 2017 15:41
..
> If possible I'd like to try and find some other solution before chopping the Segment
> size to smaller than 256.
> I think that your first proposal of adding the guard page to the segment pool could be an option.

Would be a waste of a page - which could be used for a lot of extra TRB.
IIRC the rings used to have 16 TRB - that caused some serious problems,
but I can't quite remember all of them.
I don't remember anything that made 256 'good' - except that it was a 4k page.

Did you add something to copy badly fragmented buffers to get around the
problem with misaligned LINKs.  ISTR my original fix didn't work for requests
for very long disk transfers.

> other things that could be checked:
> - check if we can avoid prefetching over segment by altering the link TRB chain or ioc bits.
> - check if we prefetch only over mid-ring link TRBs or also over last link TRB with cycle change.
>    If only mid ring then we could try to allocate two consecutive pages for the segments.
> - check if prefething over segment is related to manually setting the TR dequeue command.
>    Set TR deq ponter command fushes xHC chached TRBs and might be the cause for the prefetch.

I'd guess that it is reading multiple TRB and can't know one is a LINK.

> - does VIA VL805 have some odd xhci page size (xhci PAGEZISE register), does it affect anything.

It is 'funny' that this device will try to prefetch TRB across 64k boundaries
but data buffers aren't allowed to cross them.

	David