RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-05-19 Thread Jon Rosen (jrosen)
Forward link to a new proposed patch at: https://www.mail-archive.com/netdev@vger.kernel.org/msg236629.html

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-05-19 Thread Jon Rosen (jrosen)
Forward link to a new proposed patch at: https://www.mail-archive.com/netdev@vger.kernel.org/msg236629.html

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Jon Rosen (jrosen)
> >> >One issue with the above proposed change to use TP_STATUS_IN_PROGRESS > >> >is that the documentation of the tp_status field is somewhat > >> >inconsistent. In some places it's described as TP_STATUS_KERNEL(0) > >> >meaning the entry is owned by the kernel and

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Jon Rosen (jrosen)
> >> >One issue with the above proposed change to use TP_STATUS_IN_PROGRESS > >> >is that the documentation of the tp_status field is somewhat > >> >inconsistent. In some places it's described as TP_STATUS_KERNEL(0) > >> >meaning the entry is owned by the kernel and

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Willem de Bruijn
>> >One issue with the above proposed change to use TP_STATUS_IN_PROGRESS >> >is that the documentation of the tp_status field is somewhat >> >inconsistent. In some places it's described as TP_STATUS_KERNEL(0) >> >meaning the entry is owned by the kernel and !TP_STATUS_KERNEL(0)

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Willem de Bruijn
>> >One issue with the above proposed change to use TP_STATUS_IN_PROGRESS >> >is that the documentation of the tp_status field is somewhat >> >inconsistent. In some places it's described as TP_STATUS_KERNEL(0) >> >meaning the entry is owned by the kernel and !TP_STATUS_KERNEL(0)

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Jon Rosen (jrosen)
On Wednesday, April 04, 2018 9:49 AM, Willem de Bruijn wrote: > > On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen wrote: > > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > > casues the ring to get corrupted by allowing multiple kernel

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Jon Rosen (jrosen)
On Wednesday, April 04, 2018 9:49 AM, Willem de Bruijn wrote: > > On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen wrote: > > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > > casues the ring to get corrupted by allowing multiple kernel threads > > to claim ownership of the

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Jon Rosen (jrosen)
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c > > index e0f3f4a..264d7b2 100644 > > --- a/net/packet/af_packet.c > > +++ b/net/packet/af_packet.c > > @@ -2287,6 +2287,15 @@ static int tpacket_rcv(struct sk_buff *skb, struct > > net_device *dev, > > if

RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Jon Rosen (jrosen)
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c > > index e0f3f4a..264d7b2 100644 > > --- a/net/packet/af_packet.c > > +++ b/net/packet/af_packet.c > > @@ -2287,6 +2287,15 @@ static int tpacket_rcv(struct sk_buff *skb, struct > > net_device *dev, > > if

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Willem de Bruijn
On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen wrote: > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > casues the ring to get corrupted by allowing multiple kernel threads > to claim ownership of the same ring entry, Mark the ring entry as > already being used

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-04 Thread Willem de Bruijn
On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen wrote: > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > casues the ring to get corrupted by allowing multiple kernel threads > to claim ownership of the same ring entry, Mark the ring entry as > already being used within the

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-03 Thread Stephen Hemminger
On Tue, 3 Apr 2018 17:55:25 -0400 Jon Rosen wrote: > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > casues the ring to get corrupted by allowing multiple kernel threads > to claim ownership of the same ring entry, Mark the ring entry as > already being

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-03 Thread Stephen Hemminger
On Tue, 3 Apr 2018 17:55:25 -0400 Jon Rosen wrote: > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > casues the ring to get corrupted by allowing multiple kernel threads > to claim ownership of the same ring entry, Mark the ring entry as > already being used within the

[RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-03 Thread Jon Rosen
Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which casues the ring to get corrupted by allowing multiple kernel threads to claim ownership of the same ring entry, Mark the ring entry as already being used within the spin_lock to prevent other kernel threads from reusing the same

[RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

2018-04-03 Thread Jon Rosen
Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which casues the ring to get corrupted by allowing multiple kernel threads to claim ownership of the same ring entry, Mark the ring entry as already being used within the spin_lock to prevent other kernel threads from reusing the same