[PATCH v3] brcmfmac: Make skb header writable before use

. This patch depends on brcmfmac: Ensure pointer correctly set if skb data location changes Signed-off-by: James Hughes Acked-by: Arend van Spriel --- Changes in v2 Makes the _cow_ call at the entry point of the skb in to the stack, means only needs to be done once, and error handling

[PATCH v2] brcmfmac: Make skb header writable before use

: Ensure pointer correctly set if skb data location changes Signed-off-by: James Hughes --- Changes in v2 Makes the _cow_ call at the entry point of the skb in to the stack, means only needs to be done once, and error handling is easier. Split a separate minor bug fix off to a separate patch

[PATCH v2] brcmfmac: Ensure pointer correctly set if skb data location changes

The incoming skb header may be resized if header space is insufficient, which might change the data adddress in the skb. Ensure that a cached pointer to that data is correctly set by moving assignment to after any possible changes. Signed-off-by: James Hughes Acked-by: Arend van Spriel

[PATCH] brcmfmac: Ensure pointer correctly set if skb data location changes

The incoming skb header may be resized if header space is insufficient, which might change the data adddress in the skb. Ensure that a cached pointer to that data is correctly set by moving assignment to after any possible changes. Signed-off-by: James Hughes --- drivers/net/wireless/broadcom

Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

On 23 April 2017 at 20:34, Arend Van Spriel wrote: > On 21-4-2017 11:22, James Hughes wrote: >> On 20 April 2017 at 20:48, Arend van Spriel >> wrote: >>> + linux-wireless >>> >>> On 4/20/2017 1:16 PM, James Hughes wrote: >>>> >>

Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

On 20 April 2017 at 20:48, Arend van Spriel wrote: > + linux-wireless > > On 4/20/2017 1:16 PM, James Hughes wrote: >> >> The driver was adding header information to incoming skb >> without ensuring the head was uncloned and hence writable. >> >> skb_co

Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

On 20 April 2017 at 12:31, Kalle Valo wrote: > + linux-wireless > > James Hughes writes: > >> The driver was adding header information to incoming skb >> without ensuring the head was uncloned and hence writable. >> >> skb_cow_head has been used to ensure

[PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

needs to be reviewed by someone who is more familiar with this code base to ensure any deallocation of skb's is still correct. Signed-off-by: James Hughes --- .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c| 15 -- .../wireless/broadcom/brcm80211/brcmfmac/core.c

[PATCH v4] smsc95xx: Use skb_cow_head to deal with cloned skbs

The driver was failing to check that the SKB wasn't cloned before adding checksum data. Replace existing handling to extend/copy the header buffer with skb_cow_head. Signed-off-by: James Hughes --- Changes v3 - Added the dev_kfree_skb_any call to ensure skb is deallocated as

[PATCH v3] smsc95xx: Use skb_cow_head to deal with cloned skbs

The driver was failing to check that the SKB wasn't cloned before adding checksum data. Replace existing handling to extend/copy the header buffer with skb_cow_head. Signed-off-by: James Hughes --- Change for V3 - Added the dev_kfree_skb_any, otherwise the skb would not be deallocated d

Re: [PATCH v2] smsc95xx: Use skb_cow_head to deal with cloned skbs

On 19 April 2017 at 09:33, James Hughes wrote: > On 18 April 2017 at 23:46, Eric Dumazet wrote: >> On Tue, 2017-04-18 at 22:09 +, woojung@microchip.com wrote: >>> > > @@ -2067,13 +2067,9 @@ static struct sk_buff *smsc95xx_tx_fixup(struct >>> >

Re: [PATCH v2] smsc95xx: Use skb_cow_head to deal with cloned skbs

On 18 April 2017 at 23:46, Eric Dumazet wrote: > On Tue, 2017-04-18 at 22:09 +, woojung@microchip.com wrote: >> > > @@ -2067,13 +2067,9 @@ static struct sk_buff *smsc95xx_tx_fixup(struct >> > usbnet *dev, >> > > /* We do not advertise SG, so skbs should be already linearized */ >> > >

[PATCH v2] smsc95xx: Use skb_cow_head to deal with cloned skbs

The driver was failing to check that the SKB wasn't cloned before adding checksum data. Replace existing handling to extend/copy the header buffer with skb_cow_head. Signed-off-by: James Hughes --- Changes in v2 - Changed skb_cow to skb_cow_head as suggested by netdev list drivers/ne

Re: [PATCH] smsc95xx: Use skb_cow to deal with cloned skbs

On 18 April 2017 at 17:52, Eric Dumazet wrote: > On Tue, 2017-04-18 at 17:16 +0100, James Hughes wrote: >> On 18 April 2017 at 16:55, David Miller wrote: >> > From: Eric Dumazet >> > Date: Tue, 18 Apr 2017 08:51:51 -0700 >> > >> >> On Tu

Re: Use of skb_unclone in drivers

On 18 April 2017 at 17:34, Florian Fainelli wrote: > On 04/18/2017 01:34 AM, James Hughes wrote: >> Thanks, > > (please don't top-post on netdev) > Trying not to! New to this. >> >> Quick check on that function - very similar to unclone which we know >

Re: [PATCH] smsc95xx: Use skb_cow to deal with cloned skbs

On 18 April 2017 at 16:55, David Miller wrote: > From: Eric Dumazet > Date: Tue, 18 Apr 2017 08:51:51 -0700 > >> On Tue, 2017-04-18 at 15:48 +0100, James Hughes wrote: >>> The driver was failing to check that the SKB wasn't cloned >>> before addi

[PATCH] smsc95xx: Use skb_cow to deal with cloned skbs

The driver was failing to check that the SKB wasn't cloned before adding checksum data or adding header data. Replace existing handling to extend the buffer with skb_cow. Don't use skb_cow_head as the sw checksum code modifies the data portion. Signed-off-by: James Hughes --- drive

Re: Use of skb_unclone in drivers

at 16:02 +0100, James Hughes wrote: >> Netdevs, >> >> We have recently got to the bottom of an issue which we have been >> encountering on a Raspberry Pi being used as an access point, and we >> need a bit of advice on the correct way of fixing the issue. >> &g

Use of skb_unclone in drivers

tiple recipients? Thanks James Hughes Raspberry Pi