netdev - [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-next>] [day] [month] [year] [list]

Date:	Mon, 10 Nov 2008 11:09:33 -0500
From:	Alex Villacís Lasso 
	<avillaci@...bo.fiec.espol.edu.ec>
To:	irda-users@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: [1/3] IRDA: Create new field tx_extra in skbuff

For background, see regression report at 
http://bugzilla.kernel.org/show_bug.cgi?id=11795

This patchset attempts to fix a regression that broke the irda stack as 
a result of the qdisc patches merged in 2.6.27.

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.

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 
put to any use in other stacks (for now). I was thinking about a pointer 
field to on-the-fly allocated data, but that means messing around with 
the skbuff allocation functions, the cloning functions (involving 
deciding how to behave on cloning), etc. This way is simpler to understand.

This patch and the other two that follow fix the issue for me under 
2.6.28-rc3. Please comment on this, as I am messing around with the 
skbuff structure, which potentially affects all network stacks.

Signed-off-by: Alex Villacís Lasso <a_villacis@...osanto.com>

-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

View attachment "0001-irda-Introduce_skbuff_tx_extra.patch" of type "text/x-patch" (1238 bytes)