L2TP RX Bytes Counter Probleme

[Tim Niemeyer]

Am Samstag, den 12.03.2016, 01:08 +0100 schrieb Dominik Heidler:
> ich glaube, dass das Problem durch eine Konvertierung
> von atomic_long_t (signed 32Bit) nach __64 (unsigned 64Bit)
Ich denke weniger die Konvertierung, als mehr das der Überlauf im signed
ist das Problem. Wenn unsigned überläuft gehts mit 0 wieder los. Bei
signed eben mit -2^32..

> hervorgerufen wird.
> http://lxr.free-electrons.com/source/net/l2tp/l2tp_core.h#L38
> http://lxr.free-electrons.com/source/net/core/dev.c#L6976
> http://lxr.free-electrons.com/source/include/uapi/linux/if_link.h#L41
> 
> Patch, der es kaputtmacht:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b7c0719cd7afee725b920d75ec6a500b76107e6
Letztlich ist es eine Limitierung der 32 bit Platform. Man könnte, wie
er schreibt 64 Bit nehmen, diese müsste man dann aber synchronisieren.
Das wiederum macht viel Overhead und damit wird alles langsam.

Eine 32 bit Hardware kann eben nur bis 32 bit zählen, wenn es synchron
und schnell sein soll. :P

Der Fehler steckt also mMn nur im kaputten Überlauf. Die Lösung könnte
sein ein atomic_ulong_t zu nehmen, was wohl auch der native Datentyp
hinter dem atomic eigentlich ist.

Ich weiß nicht, ob es so gut ist den Patch auf einer 32 bit Platform
einfach zu reverten, immerhin muss die 64 bit Variable ja vermutlich in
mehreren Schritten geschrieben werden. Da könnte es zu race's und
Unschönheiten kommen.

Tim
> 
> Grüße,
> Dominik

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160312/9c2a8317/attachment-0002.sig>