netdev - Re: Who's allowed to set a skb destructor?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <p733b032mec.fsf@bingen.suse.de>
Date:	05 Jul 2007 12:08:27 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Brice Goglin <Brice.Goglin@...-lyon.org>
Cc:	netdev@...r.kernel.org
Subject: Re: Who's allowed to set a skb destructor?

Brice Goglin <Brice.Goglin@...-lyon.org> writes:

> I am trying to understand whether I can setup a skb destructor in my
> code (which is basically a protocol above dev_queue_xmit() and co). From
> what I see in many parts in the current kernel code, the "protocol" (I
> mean, the one who actually creates the skb) may setup a destructor.

The socket layer generally needs it for its own accounting.
Unless you never pass it up you can't use it.

> However, I also see some places where some low-level drivers might be
> using a destructor too , without apparently checking whether an upper
> layer already uses one. For instance, write_ofld_wr() in cxgb3/sge.c.

Likely a bug. Normally that should not slip past code review.

> found some old threads about adding support for multiple destructors but
> I don't see anything like this in the current kernel.
> 
> So, I'd like to have a clear statement about who's allowed to use a
> destructor :)

The traditional standpoint was that having your own large skb pools 
is not recommended because you won't interact well with the 
rest of the system running low on memory and you tieing up 
memory.

Essentially you would recreate all the problems traditional Unix
systems have with fixed size mbuf pools. Linux always used a more
dynamic and flexible allocate-only-as-you-need approach even when it
can have a little more overhead in managing IOMMUs etc.

These days there are shrinker callbacks that would in theory
allow you to handle this, but it would be likely still hard to implement
correctly.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html