> -Original Message-
> From: Willem de Bruijn [mailto:willemdebruijn.ker...@gmail.com]
> Sent: Wednesday, May 23, 2018 9:37 AM
> To: Jon Rosen (jrosen)
> Cc: David S. Miller ; Willem de Bruijn
> ; Eric Dumazet
> ; Kees Cook ; David Windsor
> ; Rosen,
&
> > For the ring, there is no requirement to allocate exactly the amount
> > specified by the user request. Safer than relying on shared memory
> > and simpler than the extra allocation in this patch would be to allocate
> > extra shadow memory at the end of the ring (and not mmap that).
> >
> > Th
> >>> I think the bigger issues as you've pointed out are the cost of
> >>> the additional spin lock and should the additional state be
> >>> stored in-band (fewer cache lines) or out-of band (less risk of
> >>> breaking due to unpredictable application behavior).
> >>
> >> We don't need the spinlo
On Monday, May 21, 2018 2:17 PM, Jon Rosen (jrosen) wrote:
> On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
> wrote:
>> On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
...snip...
>>
>> A setsockopt for userspace to signal a stricter interpretation of
&
On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
wrote:
>On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
>> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
>> wrote:
>>> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
>>> wrote:
>>>&g
On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
wrote:
> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
> wrote:
>> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
>>> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
>>> casues the rin
Forward link to a new proposed patch at:
https://www.mail-archive.com/netdev@vger.kernel.org/msg236629.html
x27;s fully filled in, passed to user space, and then
eventually passed back to the kernel for use with a new packet.
Signed-off-by: Jon Rosen
---
There is a bug in net/packet/af_packet.c:tpacket_rcv in how it manages
the PACKET_RX_RING for versions TPACKET_V1 and TPACKET_V2. This bug makes
it pos
> >> >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_KERN
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
> > t
> > 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 (po->stats.st
work properly. More discussion on this
change can be found in the additional comments section titled
"3. Discussion on packet_mmap ownership semantics:".
Signed-off-by: Jon Rosen
---
Additional Comments Section
---
1. Descripti
12 matches
Mail list logo
