Subject: Re: [RFC][PATCH 2/9] deadlock prevention core

From: Daniel Phillips <[email-masked]>
Date: Sun, 13 Aug 2006 14:22:31 -0700

David Miller wrote:
> From: Peter Zijlstra <[email-masked]>
>>Hmm, what does sk_buff::input_dev do? That seems to store the initial
>>device?
> 
> You can run grep on the tree just as easily as I can which is what I
> did to answer this question.  It only takes a few seconds of your
> time to grep the source tree for things like "skb->input_dev", so
> would you please do that before asking more questions like this?
> 
> It does store the initial device, but as Thomas tried so hard to
> explain to you guys these device pointers in the skb are transient and
> you cannot refer to them outside of packet receive processing.

Thomas did a great job of explaining and without any flaming or ad
hominem attacks.

We have now formed a decent plan for doing the accounting in a stable
way without adding new fields to sk_buff, thankyou for the catch.

> The reason is that there is no refcounting performed on these devices
> when they are attached to the skb, for performance reasons, and thus
> the device can be downed, the module for it removed, etc. long before
> the skb is freed up.

The virtual block device can refcount the network device on virtual
device create and un-refcount on virtual device delete.  We need to
add that to the core patch and maybe package it nicely so the memalloc
reserve/unreserve happens at the same time, in a tidy little library
function to share with other virtual devices like iSCSI that also need
some anti-deadlock lovin.

Regards,

Daniel