On Mon, Jul 13, 2015 at 11:54:47AM +0300, Konstantin Khlebnikov wrote:
>
> I don't think that recv path should care about shared skb -- skb can be
> delivered into only one socket anyway.
The fact is that this is how the original code worked and was
expected to do. The broadcast side would gener
On 13.07.2015 10:23, Herbert Xu wrote:
On Fri, Jul 10, 2015 at 02:51:41PM +0300, Konstantin Khlebnikov wrote:
This fixes race between non-atomic updates of adjacent bit-fields:
skb->cloned could be lost because netlink broadcast clones skb after
sending it to the first listener who sets skb->pee
On Mon, Jul 13, 2015 at 10:28:19AM +0200, Eric Dumazet wrote:
>
> Except that udp checksum are checked outside of spinlock protection.
Good point. I wonder when this got broken. I'll do some digging.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://
On Mon, Jul 13, 2015 at 10:25 AM, Herbert Xu
wrote:
> On Mon, Jul 13, 2015 at 10:22:34AM +0200, Eric Dumazet wrote:
>>
>> It should worry, in case multiple threads are using MSG_PEEK on same udp
>> socket ;)
>
> That should be fine because we already hold a spinlock on the
> queue.
>
Except that
On Mon, Jul 13, 2015 at 10:22:34AM +0200, Eric Dumazet wrote:
>
> It should worry, in case multiple threads are using MSG_PEEK on same udp
> socket ;)
That should be fine because we already hold a spinlock on the
queue.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert
On Mon, 2015-07-13 at 16:10 +0800, Herbert Xu wrote:
> On Mon, Jul 13, 2015 at 10:05:42AM +0200, Eric Dumazet wrote:
> >
> > Herbert, UDP peek support is very buggy anyway, because of deferred
> > checksums
> >
> > __skb_checksum_complete() will happily manipulate csum, ip_summed,
> > csum_complet
On Mon, Jul 13, 2015 at 10:05:42AM +0200, Eric Dumazet wrote:
>
> Herbert, UDP peek support is very buggy anyway, because of deferred
> checksums
>
> __skb_checksum_complete() will happily manipulate csum, ip_summed,
> csum_complete_sw & csum_valid
>
> Ideally, peek should never touch skb (but sk
On Mon, 2015-07-13 at 15:23 +0800, Herbert Xu wrote:
> The real issue here is that the recv path no longer handles shared
> skbs. So either we need to fix the recv path to not touch skbs
> without cloning them, or we need to get rid of the use of shared
> skbs in netlink.
>
> In fact it looks I
On Fri, Jul 10, 2015 at 02:51:41PM +0300, Konstantin Khlebnikov wrote:
> This fixes race between non-atomic updates of adjacent bit-fields:
> skb->cloned could be lost because netlink broadcast clones skb after
> sending it to the first listener who sets skb->peeked at the same skb.
> As a result a
On 10.07.2015 16:49, Eric Dumazet wrote:
On Fri, 2015-07-10 at 14:51 +0300, Konstantin Khlebnikov wrote:
This fixes race between non-atomic updates of adjacent bit-fields:
skb->cloned could be lost because netlink broadcast clones skb after
sending it to the first listener who sets skb->peeked a
On Fri, 2015-07-10 at 14:51 +0300, Konstantin Khlebnikov wrote:
> This fixes race between non-atomic updates of adjacent bit-fields:
> skb->cloned could be lost because netlink broadcast clones skb after
> sending it to the first listener who sets skb->peeked at the same skb.
> As a result atomic r
This fixes race between non-atomic updates of adjacent bit-fields:
skb->cloned could be lost because netlink broadcast clones skb after
sending it to the first listener who sets skb->peeked at the same skb.
As a result atomic refcounting of skb header stays disabled and
skb_release_data() frees it
12 matches
Mail list logo
