mbuf_dup/mbuf_freem with mbufs containing aux data
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SFqdj6ML5nQypomwgZHKnz0zNWJCTXgZKYTzlAVuZST9ZRW+/4UjFmo/qxOKUwtSNx3HDTYO8qiKg0YbXc+3oKYq9adTrDtFyLFpV5KFgVIjOXKtw/L79ZR8TK1ILLcQGeRtsE/X7do91KrNkqRQh6/IfrGxOkmY/62v0RcSKM8= I noticed when my interface filter output method gets called for IPV6 packets (in particular ICMP6 echo replies), that the mbuf contains an aux data pointer in its m_pkthdr. Browsing the xnu-792.13.8 code, it looks like when you mbuf_dup() an mbuf, the pkthdr of the new mbuf is a copy of the pkthdr of the source mbuf, which means that the new mbuf's pkthdr's aux field points to the same piece of data as the original mbuf. Then when mbuf_freem() is called, it unconditionally frees this aux data if there was any on the mbuf chain that you're freeing. Without reference counting the aux field, this is really bad. "freeing free mbufs" panics ensue from this. What's my workaround? Thanks! -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com
participants (1)
-
Bhavesh Davda