2017-10-19 94 views
3

我遇到了insmod的WIFI Marvell pcie驱动程序崩溃。 我在ARCH = arc OS = linux和little endian上运行WIFI驱动程序。 死机回溯表示错位的地址访问导致崩溃。 我已经做了一些调查,发现崩溃的地方,下面是代码片段。错误的地址访问崩溃在arc平台上的linux 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是无符号的字符和typecast'd到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: 

请帮助。

+0

*“我不知道解决这个问题的方法......”* - 您可能必须将其带到内核邮件列表才能解决问题。 [Linux Kernel Newbies](https://kernelnewbies.org/)是一个很好的地方,因为内核开发者在那里挂着并且相对温和。该网站还有[发现错误]部分(https://kernelnewbies.org/FoundBug)。您的下一步可能是在适当的邮件列表上报告。 – jww

回答

3

简单。正确的做。在一般情况下,人们会使用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标准确实状态的behaviour is undefined when

两种指针类型之间的转换会产生不正确对齐的结果(6.3.2.3)。

因此,即使仅仅存在铸造(t_u32*)可以导致编译器“实现”指针psnmp_mib->value无论如何对准的t_u32对齐要求的


对齐访问 - 甚至转换指针未对齐的结构 - 已不确定偶的平台上"supposedly" allow unaligned access "everywhere"行为。

+1

我们在内核中有* get_unaligned()*和* put_unaligned()*助手。最好使用它们并向上游发送补丁。 – 0andriy

+0

我再次阅读帖子,现在甚至可以说* memcpy()*方法是开销。 – 0andriy

+0

@ 0andriy我看了一下“put_unaligned”API ......非常*令人担忧的是它*太*(在https://www.kernel.org/doc/Documentation/unaligned-memory-access。txt)有未定义的行为; 'put_unaligned(value,(u32 *)data);' - 当'data'未对齐时,转换无效。无论如何, –