2013/8/5 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: > On Fri, 2013-08-02 at 06:11 -0700, Eric Dumazet wrote: >> On Fri, 2013-08-02 at 10:55 +0200, Ben Hutchings wrote: >> >> > I don't think this is safe when the interface is running (even if >> > carrier is off). Some functions may read dev->needed_headroom twice and >> > rely on getting the same value each time. >> >> It should be no problem. Remaining unsafe places should be fixed. > > Most interesting would be stack devs, which I hadn't even considered. In > any case, since I can't completely _rely_ on it, it's an optimisation, > the only bugs would be around the double-access and then running > over/under the SKB or so? As far as I could test this with an Ethernet driver which adjusted its needed_headroom by 64 bytes whenever some hardware feature was enabled/disabled, this expectedly broke bridge and vlans at least. Bridge code does not use the slave ports needed_headroom values, and VLAN devices get the parent device needed_headroom only when creating the vlan device. The good thing is since the needed_headroom space you need is most likely fixed for a given configuration type, you should see a pretty "stable" corruption of your SKB head. > >> We already had this discussion in the past, and some patches were >> issued. Check commit ae641949df01b85117845bec45328eab6d6fada1 >> ("net: Remove all uses of LL_ALLOCATED_SPACE") > > That would have addressed some of that, I guess. > > > I'm asking because some of the crypto stuff we do has fairly large > head/tailroom requirements and it seems I may need to add more. But if > you don't have crypto, it would be much smaller, so I figured we could > switch it. We could probably do it via a pair of new NETDEV_* notify event to signal new needed_headroom/tailroom values to stacked devices. Would that be acceptable? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html