On Thu, Feb 15, 2018 at 09:43:06AM -0800, Eric Dumazet wrote:
> On Thu, 2018-02-15 at 09:24 -0800, Eric Dumazet wrote:
> >
> > I will send something more suited to original intent of these commits :
> >
> > 90e33d45940793def6f773b2d528e9f3c84ffdc7 tun: enable napi_gro_frags()
> > for TUN/TAP
On Thu, 2018-02-15 at 09:24 -0800, Eric Dumazet wrote:
>
> I will send something more suited to original intent of these commits :
>
> 90e33d45940793def6f773b2d528e9f3c84ffdc7 tun: enable napi_gro_frags()
> for TUN/TAP driver
> 943170998b200190f99d3fe7e771437e2c51f319 tun: enable NAPI for
On Thu, Feb 15, 2018 at 09:24:36AM -0800, Eric Dumazet wrote:
> On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet wrote:
> >
> > Yes, it seems tun.c breaks the assumptions.
> >
> > If it really wants to provide arbitrary fragments and alignments, it
> > should use a separate
>
>
On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet wrote:
>
> Yes, it seems tun.c breaks the assumptions.
>
> If it really wants to provide arbitrary fragments and alignments, it
> should use a separate
Sorry, I have sent the message to soon.
tun.c should use a private 'struct
On Thu, Feb 15, 2018 at 9:04 AM, Mark Rutland wrote:
> Hi,
>
> While fuzzing arm64 v4.16-rc1 with Syzkaller, I've been hitting a
> misaligned atomic in __skb_clone:
>
> atomic_inc(&(skb_shinfo(skb)->dataref));
>
> .. where dataref doesn't have the required natural
Hi,
While fuzzing arm64 v4.16-rc1 with Syzkaller, I've been hitting a
misaligned atomic in __skb_clone:
atomic_inc(&(skb_shinfo(skb)->dataref));
.. where dataref doesn't have the required natural alignment, and the
atomic operation faults. e.g. i often see it aligned to a single byte