netdev - RE: Regression: Recent networking (qdisc?) patches break irda_get_next

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: <F169D4F5E1F1974DBFAFABF47F60C10A069DFD1F@orsmsx507.amr.corp.intel.com>
Date:	Thu, 23 Oct 2008 15:13:02 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	Alex Villacís Lasso 
	<avillaci@...bo.fiec.espol.edu.ec>,
	"irda-users@...ts.sourceforge.net" <irda-users@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: RE: Regression: Recent networking (qdisc?) patches break
 irda_get_next_speed()

Alex Villacís Lasso wrote:
<snip>

>> The SKB control block is not aliased.
>> 

...
>> IRDA cannot depend upon the SKB control block not changing across
>> the dev_queue_xmit() call. 
>> 
>> 
> Let me see if I understood. So the particular illegal thing the IRDA
> stack is doing is the access of the control block in the middle of the
> driver transmit routine (via irda_get_next_speed() and friends). This
> information should be stored somewhere else. Exactly *where* to store
> it is the main problem to solve.
> 
> What is the proper way (if any) to store per-packet parameters (other
> than the payload itself) which are specific to a particular layer
> (IrDA in this case) and which are needed by drivers in order to work
> correctly? The control block gets overwritten by the time the driver
> proc (hard_start_xmit) is called, so this approach is now ruled out. I
> was thinking about storing a copy of the parameters (struct
> irda_skb_cb) as a header within the payload itself (skb->data[]), but
> I am not sure about whether this approach is a good design decision.
> I am open to suggestions on where to place the parameters.

Isn't this what the data that is skb_reserve'd at the beginning of skb's allocated by netdev_alloc_skb is for?  If you take an extra reference to the skb and/or use a destructor hook you should be good, right?

you should just be able to push ->data using skb_reserve(sizeof your private data) in the beginning of the skb, or is that a horrible idea Dave?
--
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