linux-kernel之通过清除高位来保持内核地址平衡_编程设计

Linux中是否有某种机制通过将高16位清零来毒化地址？

我正在调试Intel x86-64计算机上的内核崩溃。导致崩溃的指令尝试访问0x880139f3da00的地址:

crash> bt 
R10: 0000000000000001  R11: 0000000000000001  R12: 0000880139f3da00 
                                              ~~~~~~~~~~~~~~~~~~~~~ 
 
crash> p arp_tbl.nht->hash_buckets[255] 
$66 = (struct neighbour *) 0x880139f3da00 
 
crash> p *arp_tbl.nht->hash_buckets[255] 
Cannot access memory at address 0x880139f3da00

hash_buckets表有效:

crash> p arp_tbl.nht->hash_buckets[253] 
$70 = (struct neighbour *) 0xffff88007325ae00 
$71 = { 
  next = 0x0,  
  tbl = 0xffffffff81abbf20 <arp_tbl>,

将高位字设置为 0xffff将使地址有效并返回有效的数据结构:

crash> p *((struct neighbour *)0xffff880139f3da00) 
$73 = { 
  next = 0xffff88006de69a00,  
  tbl = 0xffffffff81abbf20 <arp_tbl>,  
  ... rest looks reasonable too ...

结构是通过RCU操作(例如，很有可能通过 neigh_flush_dev()中的操作)进行更新的。那么，地址以这种方式变为无效的原因可能是什么？

我可以排除硬件缺陷(在两台计算机上使用不同的地址看到)。系统运行的CentOS 7内核为3.10.0-514.6.1.el7.centos.plus.x86_64，直到3.10.0-514.21.2.el7.centos.plus.x86_64。

更新资料

在另一个故障转储中，我看到了一个IPv6数据包的 skb

crash> p *((struct sk_buff *)0xffff880070e25e00) 
$57 = { 
  transport_header = 54,  
  network_header = 14,  
  mac_header = 0,  
  ... 
  head = 0xffff880138e28000 "",  
  data = 0xffff880138e2800e "`",  
  ... 
}

在写入前0x8字节时崩溃

#define HH_DATA_MOD 16 
 
static inline int neigh_hh_output(const struct hh_cache *hh, struct sk_buff *skb) 
{ 
                if (likely(hh_len <= HH_DATA_MOD)) { 
                        memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);   <<<<<

这可以解释为什么两个字节被覆盖(16-14)。

请您参考如下方法:

您可以检查读取该地址的存储位置吗？通常，此类“部分零”读取是在该区域上运行memset的结果。在此CPU触发崩溃后，可能有足够的时间供其他任何人修改该区域以完成归零，甚至可能用其他数据填充该区域。

到目前为止，没有理由怀疑rcu在这里发挥了作用

这绝对不是内核完成的“中毒”操作(用这种方式做是很奇怪的)。但是，如果崩溃是可重现的(您说它是在至少2台不同的机器上发生的？)，则运行调试内核可能会有所帮助，尤其是在启用了平板调试的情况下。