我在WIFI Marvell PCIe驱动程序的insmod上崩溃。我在ARCH = arc OS = linux和little endian上运行WIFI驱动程序。崩溃回溯表示未对齐的地址访问会导致崩溃。我做了一些调查，发现了崩溃的地方，下面是代码片段。
case NullPktPeriod_i:
/** keep alive null data pkt interval in full power mode */
psnmp_mib->oid = wlan_cpu_to_le16((t_u16)NullPktPeriod_i);
if (cmd_action == HostCmd_ACT_GEN_SET) {
psnmp_mib->query_type =
wlan_cpu_to_le16(HostCmd_ACT_GEN_SET);
psnmp_mib->buf_size = wlan_cpu_to_le16(sizeof(t_u32));
ul_temp = *((t_u32 *)pdata_buf);
*((t_u32 *)(psnmp_mib->value)) =
wlan_cpu_to_le32((t_u32)ul_temp);
cmd->size += sizeof(t_u32);
}
break;
*((t_u32 *)(psnmp_mib->value)) = wlan_cpu_to_le32((t_u32)ul_temp);由于psnmp_mib->value未签名的char和类型转换为，崩溃在线了unsigned long int。但是我们从中分配的pdata_buf值仅是1个字节的值ul_temp = *((t_u32 *)pdata_buf);。
奇怪的行为是，如果将初始化ul_temp (unsigned long int variable)为零（任何值），并且运行，则不会看到崩溃。但是PCI命令超时发生在获取get_hardware_spec命令时，内核挂起。
我没有解决此问题的线索。请提供一些输入以进一步进行操作。
打击是我的崩溃日志，
[ 29.920000] Path: (null)
[ 29.930000] CPU: 0 PID: 1047 Comm: kworker/u3:1 Tainted: P O 3.12.0 #103
[ 29.930000] Workqueue: MOAL_WORK_QUEUE woal_main_work_queue [pcie8xxx]
[ 29.940000] task: 9f0e02c0 ti: 9d192000 task.ti: 9d192000
[ 29.940000]
[ECR ]: 0x00230400 => Misaligned r/w from 0x9d451072
[ 29.950000] [EFA ]: 0x9d451072
[ 29.950000] [BLINK ]: wlan_prepare_cmd+0x1be/0x478 [mlan]
[ 29.950000] [ERET ]: wlan_ops_sta_prepare_cmd+0x1fe0/0x37dc [mlan]
[ 29.950000] [STAT32]: 0x00000a06 : E2 E1
[ 29.970000] BTA: 0x78571ccc SP: 0x9d193c34 FP: 0x00000000
[ 29.980000] LPS: 0x982de26c LPE: 0x982de270 LPC: 0x00000000
[ 29.980000] r00: 0x00000000 r01: 0x00000016 r02: 0x00000012
r03: 0x0000001e r04: 0x00000000 r05: 0x9d193cb4
r06: 0x9d451064 r07: 0x7857129c r08: 0xfffffffe
r09: 0x00000000 r10: 0x000004cf r11: 0x00000002
r12: 0x00000000
[ 29.990000]
[ 29.990000] Stack Trace:
请帮忙。
简单。做正确的事。在一般情况下，可以使用memcpy：
t_u32 value = wlan_cpu_to_le32((t_u32)ul_temp);
memcpy(psnmp_mib->value, &value, sizeof (t_u32));
如0andriy所指出，put_unaligned可以在此处使用：
put_unaligned(wlan_cpu_to_le32((t_u32)ul_temp), (t_u32*)psnmp_mib->value);
但是，这非常令人担忧，因为C标准确实在以下情况下声明行为未定义：
两种指针类型之间的转换会产生错误对齐的结果（6.3.2.3）。
因此，即使仅仅是强制转换的存在，(t_u32*) 也可能导致编译器“意识到”指针psnmp_mib->value始终与对齐要求对齐t_u32。
即使在“应该”允许“无处不在”的情况下，未对齐的访问-甚至将指针转换为未对齐的结构-仍具有未定义的行为。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句