Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
12 个月 前同步成功

通知 152
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 9月, 2016 1 次提交
  3. 20 9月, 2016 7 次提交
  5. 19 9月, 2016 3 次提交
  7. 17 9月, 2016 7 次提交
  9. 16 9月, 2016 16 次提交
  11. 15 9月, 2016 1 次提交
    • J
      mac80211: reject TSPEC TIDs (TSIDs) for aggregation · 85d5313e
      由 Johannes Berg 提交于 
      Since mac80211 doesn't currently support TSIDs 8-15 which can
only be used after QoS TSPEC negotiation (and not even after
WMM negotiation), reject attempts to set up aggregation
sessions for them, which might confuse drivers. In mac80211
we do correctly handle that, but the TSIDs should never get
used anyway, and drivers might not be able to handle it.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      85d5313e
  13. 14 9月, 2016 3 次提交
  15. 13 9月, 2016 2 次提交
    • X
      sctp: hold the transport before using it in sctp_hash_cmp · 715f5552
      由 Xin Long 提交于 
      Since commit 4f008781 ("sctp: apply rhashtable api to send/recv
path"), sctp uses transport rhashtable with .obj_cmpfn sctp_hash_cmp,
in which it compares the members of the transport with the rhashtable
args to check if it's the right transport.

But sctp uses the transport without holding it in sctp_hash_cmp, it can
cause a use-after-free panic. As after it gets transport from hashtable,
another CPU may close the sk and free the asoc. In sctp_association_free,
it frees all the transports, meanwhile, the assoc's refcnt may be reduced
to 0, assoc can be destroyed by sctp_association_destroy.

So after that, transport->assoc is actually an unavailable memory address
in sctp_hash_cmp. Although sctp_hash_cmp is under rcu_read_lock, it still
can not avoid this, as assoc is not freed by RCU.

This patch is to hold the transport before checking it's members with
sctp_transport_hold, in which it checks the refcnt first, holds it if
it's not 0.

Fixes: 4f008781 ("sctp: apply rhashtable api to send/recv path")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      715f5552
    • B
      bnx2: Reset device during driver initialization · 3e1be7ad
      由 Baoquan He 提交于 
      When system enters into kdump kernel because of kernel panic, it won't
shutdown devices. On-flight DMA will continue transferring data until
device driver initializes. All devices are supposed to reset during
driver initialization. And this property is used to fix the kdump
failure in system with intel iommu. Other systems with hardware iommu
should be similar. Please check commit 091d42e4 ("iommu/vt-d: Copy
translation tables from old kernel") and those commits around.

But bnx2 driver doesn't reset device during driver initialization. The
device resetting is deferred to net device up stage. This will cause
hardware iommu handling failure on bnx2 device. And its resetting relies
on firmware. So in this patch move the firmware requesting code to earlier
bnx2_init_one(), then next call bnx2_reset_chip to reset device.
Signed-off-by: NBaoquan He <bhe@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e1be7ad