From: Neil Horman <nhorman@xxxxxxxxxxxxx> Date: Mon, 29 Oct 2012 14:59:32 -0400 > I don't think thats whats going on at all. The problem, as commit > 19c7e9eef503dc1ae926f3d26c56f88bee568d7b describes it, is that ia64 was > speculatively loading a value from memory of type sctp_arg_t. If the > initialization step set the value of one of the smaller members of the union > (say a short), then the load stage may still load a larger amount of data (given > that the union is larger than its smallest members). That results in part of > the load being uninitalized, and ia64 declaring it Not A Thing, and consequently > trapping out. Agreed. > The fix previously was to just initazlie the unsigned long member zero in that > union before setting the actuall type member that was requried so as to ensure > all the data was initalized. That works well enough, but it presumes that > unsigned long is the largest member of the union, which is risky. Its better to > memset the union to 0 for sizeof bytes to ensure future proofing. Also agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
