All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Willem de Bruijn'" <willemdebruijn.kernel@gmail.com>,
	Wei Wei <dotweiba@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	"David Miller" <davem@davemloft.net>,
	Willem de Bruijn <willemb@google.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: RE: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()
Date: Thu, 26 Oct 2017 15:24:29 +0000	[thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD00A59B0@AcuExch.aculab.com> (raw)
In-Reply-To: <CAF=yD-Lw2E7T12sA-dgMK5kn=L0TLGQE+v68s1X8HMHLq9hGBA@mail.gmail.com>

From: Willem de Bruijn
> Sent: 25 October 2017 19:50
...
> From skb->dev and netdev_priv, the tun device has flags 0x1002 ==
> IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for
> IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened
> in tun_build_skb from current->task_frag. It would be a previous
> allocation that left alloc_frag->offset unaligned. But perhaps this code
> needs to perform alignment before setting skb->head.
>
> At least on platforms where atomic on dataref must be aligned.

Isn't that true of almost everything?
I'm not even sure x86 always (ever?) manages locked cycles on
misaligned addresses.

	David

WARNING: multiple messages have this Message-ID (diff)
From: David.Laight@ACULAB.COM (David Laight)
To: linux-arm-kernel@lists.infradead.org
Subject: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()
Date: Thu, 26 Oct 2017 15:24:29 +0000	[thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD00A59B0@AcuExch.aculab.com> (raw)
In-Reply-To: <CAF=yD-Lw2E7T12sA-dgMK5kn=L0TLGQE+v68s1X8HMHLq9hGBA@mail.gmail.com>

From: Willem de Bruijn
> Sent: 25 October 2017 19:50
...
> From skb->dev and netdev_priv, the tun device has flags 0x1002 ==
> IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for
> IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened
> in tun_build_skb from current->task_frag. It would be a previous
> allocation that left alloc_frag->offset unaligned. But perhaps this code
> needs to perform alignment before setting skb->head.
>
> At least on platforms where atomic on dataref must be aligned.

Isn't that true of almost everything?
I'm not even sure x86 always (ever?) manages locked cycles on
misaligned addresses.

	David

  parent reply	other threads:[~2017-10-26 15:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-20  2:16 v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() Wei Wei
2017-10-20  2:16 ` Wei Wei
2017-10-20  2:53 ` Eric Dumazet
2017-10-20  2:53   ` Eric Dumazet
2017-10-20  3:13   ` Wei Wei
2017-10-20  3:13     ` Wei Wei
2017-10-20  5:34     ` Eric Dumazet
2017-10-20  5:34       ` Eric Dumazet
2017-10-20  9:18       ` Will Deacon
2017-10-20  9:18         ` Will Deacon
2017-10-20 11:14 ` Mark Rutland
2017-10-20 11:14   ` Mark Rutland
2017-10-20 14:40   ` Wei Wei
2017-10-20 14:40     ` Wei Wei
2017-10-20 15:11     ` Mark Rutland
2017-10-20 15:11       ` Mark Rutland
2017-10-20 15:14     ` Dmitry Vyukov
2017-10-20 15:14       ` Dmitry Vyukov
2017-10-20 15:39       ` Willem de Bruijn
2017-10-20 15:39         ` Willem de Bruijn
2017-10-22  1:56         ` Wei Wei
2017-10-22  1:56           ` Wei Wei
2017-10-25 18:24           ` Willem de Bruijn
2017-10-25 18:24             ` Willem de Bruijn
2017-10-25 18:49             ` Willem de Bruijn
2017-10-25 18:49               ` Willem de Bruijn
2017-10-25 19:01               ` Eric Dumazet
2017-10-25 19:01                 ` Eric Dumazet
2017-10-26  5:38                 ` Jason Wang
2017-10-26  5:38                   ` Jason Wang
2017-10-26 15:24               ` David Laight [this message]
2017-10-26 15:24                 ` David Laight
2017-10-26 15:24                 ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=063D6719AE5E284EB5DD2968C1650D6DD00A59B0@AcuExch.aculab.com \
    --to=david.laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=dotweiba@gmail.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.