On Tue, 20 Aug 2013 11:00:18 +0100 Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > 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. All code must check for needed headroom first, and copy packet if space is not available. Since excess headroom is always safe, most devices just always use the same worst case headroom. Even with your changes this will still be necessary since packets will be still in flight while features change. -- 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
