netdev - Re: [1/3] IRDA: Create new field tx

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: <20081110163546.GA19804@ioremap.net>
Date:	Mon, 10 Nov 2008 19:35:46 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Alex Villacís Lasso 
	<avillaci@...bo.fiec.espol.edu.ec>
Cc:	irda-users@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [1/3] IRDA: Create new field tx_extra in skbuff

Hi Alex.

On Mon, Nov 10, 2008 at 11:09:33AM -0500, Alex Villacís Lasso (avillaci@...bo.fiec.espol.edu.ec) wrote:
> The previous patchsets attempt to fix the clobbering of the irda 
> information by storing it within the data payload itself, as an 
> additional header. For this, space has been allocated via skb_pull (?!) 
> and later, skb_reserve(). The problem with this approach is that  we do 
> not have a guarantee that all skbuffs that are processed in the irda 
> stack are actually allocated with functions that reserve the required 
> space for the irda metadata, especially in the tx route. In addition, 
> this approach mixes the payload data with metadata that should not be 
> transmitted at all, which is a bit disorganized.

Do all irda transfers require that additional data?
You can simply change MAX_HEADER macro to be bigger than that size
if it has to be larger than existing the biggest ax25 layer, which I
doubt it has to.

This data is always allocated for all transmitted skbs. Reserve is also
properly done in sending functions.

> This is the first of 3 patches that try a different approach. Instead of 
> allocating an additional "header" within the data buffer itself, it 
> introduces a new field within the skbuff, named tx_extra. This field 
> should be used for passing data from the higher layers that is required 
> for the drivers to transmit the packet correctly, and formalizes the 
> previous usage of the cb field by the irda stack. The only issue I see 
> is that every single skbuff carries an additional 32 bytes which are not 

I really wanted to write a joke about existing practice of shrinking skb
as much as possible sucking bits out of existing fields, but your
proposal to add 32 bytes just kicked me out of the chair, my head landed
on the keyboard and result is quite miserable: kn cgjm ncfkjn chcmujhcm.

This 32 bytes will be unused by at least half of the packets (rx ones)
and on the machines, where irda is not used, it will be just a wasted
block. Moreover, head of the skb->data is also unused for irda in this
case...

What exactly should be carried in that area?

-- 
	Evgeniy Polyakov
--
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