linux-kernel - Re: [PATCH 02/20] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22fb47eb-9f51-90ca-907d-bf8252424fce@prevas.dk>
Date:   Tue, 8 Dec 2020 21:12:55 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Li Yang <leoyang.li@....com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Zhao Qiang <qiang.zhao@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Netdev <netdev@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 02/20] ethernet: ucc_geth: fix definition and size of
 ucc_geth_tx_global_pram

On 08/12/2020 20.14, Li Yang wrote:
> On Sat, Dec 5, 2020 at 1:21 PM Rasmus Villemoes
> <rasmus.villemoes@...vas.dk> wrote:
>>
>> Table 8-53 in the QUICC Engine Reference manual shows definitions of
>> fields up to a size of 192 bytes, not just 128. But in table 8-111,
>> one does find the text
>>
>>   Base Address of the Global Transmitter Parameter RAM Page. [...]
>>   The user needs to allocate 128 bytes for this page. The address must
>>   be aligned to the page size.
>>
>> I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
>> they both have this inconsistency (and the table numbers are the
>> same).
> 
> This does seem to be an inconsistency.  I will try to see if I can
> find someone who is familiar with this as this is really an old IP.
> 
> Figure 8-61 does mention that size = 128 byte + 64 byte if ....    But
> this part is not clear also.

Hm, indeed, that sentence is simply cut short, it literally says
"Additional 64 bytes are needed if". The next line contains
"Hierarchical Scheduler, or IP" in a smaller font, but that seems to be
a label for the arrow.

> 
> The overlapping does seem to be a problem.  Maybe these global
> parameters are not sampled at runtime or the parameter RAM is really
> only using 128byte depending on the operation mode.

Yes, I'm thinking something like that is likely to be the case, since
this hasn't seemed to ever cause any problems. But who knows, maybe a
few frames just get fragmented very occasionally becauces the MTU0 field
spuriously has some random small value.

> 
> Are you getting useful information by reading from the additional 64
> bytes, 

AFAICT, after the additional allocation, the extra 64 bytes stay at 0,
but that's to be expected; they are supposed to be written by the CPU
and read by the engine AFAIU.

or getting changed behavior for setting these bytes after your
> changes?

No, as I said:

>> I haven't observed any failure that could be attributed to this,

I haven't played around with explicitly writing to those 64 bytes after
initialization. This whole series started because I searched for the
string "MTU" in the manual, but at the end, it didn't seem that I
actually needed to modify those MTU fields.

Rasmus