> Are the S/390 asm/unaligned.h versions broken, or is the ReiserFS code
doing
> something not planned for? It's a 16-bit member, at a 16-bit alignment
> in the structure. The structure itself need not be aligned in any
> particular manner as it is read directly from disk, and is a packed
structure.
The S/390 unaligned.h macros are just direct assignments because the
S/390 hardware normally *allows* unaligned accesses just fine.
It is only *atomic* accesses (those implemented using the S/390
compare-and-swap instruction) that need to be word aligned; this includes
the atomic bit operations that reiserfs appears to be using.
If these instructions really *need* to be atomic, then reiserfs should
ensure they are performed on properly aligned data, or else there might
be subtle bugs even on Intel, because the operations will not actually
be atomic (even though they don't trap).
If you say that reiserfs doesn't really need these operations to be
atomic because they run under other locks anyway, then they should not
be using atomic operations in the first place; this will only cause
unnecessary slowdown even on Intel.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/