Re: Strange things wirh NFS on 2.6.8.1 kernel
Kars de Jong <jongk@linux-m68k.org> writes:
> Adding a "memory" constraint to the assembly in ip_fast_csum() solved
> it. I don't really understand why it's needed, since the code in
> ip_fast_csum() does not modify memory...
The problem is that gcc only sees that the assembly uses the _pointer_,
but it has no clue that the _contents_ are being read. So it assumes that
the first store is dead.
> There was also a problem with the constraints of csum_tcpudp_nofold(),
> they were inconsistent (I think). I also noticed a rather strange
> difference between us and other big-endian arches: they all use len +
> (proto<<16) as an input, we use len + proto. I don't really understand
> why.
Both result in the same (16-bit) sum, but the latter saves a shift.
> I propose the following changes, but I'd like someone else to look at
> them first before committing them.
Apart from the point above your changes look ok.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply to: