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

[Daniel Phillips <phillips@google.com>]

David Miller wrote:
> From: Daniel Phillips <phillips@google.com>
> > David Miller wrote:
> >
> > > 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.
>
> What if the packet is originally received on the device in question,
> and then gets redirected to another device by a packet scheduler
> traffic classifier action or a netfilter rule?
>
> It is necessary to handle the case where the device changes on the
> skb, and the skb gets freed up in a context and assosciation different
> from when the skb was allocated (for example, different from the
> device attached to the virtual block device).

This aspect of the patch became moot because of the change to a single
reserve for all layer 2 delivery in Peter's more recent revisions.

*However* maybe it is worth mentioning that I intended to provide a
pointer from each sk_buff to a common accounting struct.  This pointer
is set by the device driver.  If the driver knows nothing about memory
accounting then the pointer is null, no accounting is done, and block
IO over the interface will be dangerous.  Otherwise, if the system is
in reclaim (which we currently detect crudely when a normal allocation
fails) then atomic ops will be done on the accounting structure.

I planned to use the (struct sock *)sk_buff->sk field for this, which
is unused during layer 2 delivery as far as I can see.  The accounting
struct can look somewhat like a struct sock if we like, size doesn't
really matter, and it might make the code more robust.  Or the field
could become a union.

Anyway, this bit doesn't matter any more, the single global packet
delivery reserve is better and simpler.

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/