* Re: [PATCH 06/31] netfilter: nf_tables: add xfrm expression
From: Eyal Birger @ 2018-10-10 11:39 UTC (permalink / raw)
To: fw; +Cc: Pablo Neira Ayuso, netfilter-devel, netdev
In-Reply-To: <20181008230125.2330-7-pablo@netfilter.org>
Hi Florian,
On Tue, 9 Oct 2018 01:01:00 +0200
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> From: Florian Westphal <fw@strlen.de>
>
> supports fetching saddr/daddr of tunnel mode states, request id and
> spi. If direction is 'in', use inbound skb secpath, else dst->xfrm.
>
> Joint work with Máté Eckl.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
<snip>
> +
> +/* Return true if key asks for daddr/saddr and current
> + * state does have a valid address (BEET, TUNNEL).
> + */
> +static bool xfrm_state_addr_ok(enum nft_xfrm_keys k, u8 family, u8
> mode) +{
> + switch (k) {
> + case NFT_XFRM_KEY_DADDR_IP4:
> + case NFT_XFRM_KEY_SADDR_IP4:
> + if (family == NFPROTO_IPV4)
> + break;
> + return false;
> + case NFT_XFRM_KEY_DADDR_IP6:
> + case NFT_XFRM_KEY_SADDR_IP6:
> + if (family == NFPROTO_IPV6)
> + break;
> + return false;
> + default:
> + return true;
> + }
> +
> + return mode == XFRM_MODE_BEET || mode == XFRM_MODE_TUNNEL;
> +}
> +
> +static void nft_xfrm_state_get_key(const struct nft_xfrm *priv,
> + struct nft_regs *regs,
> + const struct xfrm_state *state,
> + u8 family)
> +{
> + u32 *dest = ®s->data[priv->dreg];
> +
> + if (!xfrm_state_addr_ok(priv->key, family,
> state->props.mode)) {
> + regs->verdict.code = NFT_BREAK;
> + return;
> + }
> +
> + switch (priv->key) {
> + case NFT_XFRM_KEY_UNSPEC:
> + case __NFT_XFRM_KEY_MAX:
> + WARN_ON_ONCE(1);
> + break;
> + case NFT_XFRM_KEY_DADDR_IP4:
> + *dest = state->id.daddr.a4;
> + return;
> + case NFT_XFRM_KEY_DADDR_IP6:
> + memcpy(dest, &state->id.daddr.in6, sizeof(struct
> in6_addr));
> + return;
> + case NFT_XFRM_KEY_SADDR_IP4:
> + *dest = state->props.saddr.a4;
> + return;
> + case NFT_XFRM_KEY_SADDR_IP6:
> + memcpy(dest, &state->props.saddr.in6, sizeof(struct
> in6_addr));
> + return;
> + case NFT_XFRM_KEY_REQID:
> + *dest = state->props.reqid;
> + return;
> + case NFT_XFRM_KEY_SPI:
> + *dest = state->id.spi;
> + return;
> + }
> +
> + regs->verdict.code = NFT_BREAK;
> +}
> +
> +static void nft_xfrm_get_eval_in(const struct nft_xfrm *priv,
> + struct nft_regs *regs,
> + const struct nft_pktinfo *pkt)
> +{
> + const struct sec_path *sp = pkt->skb->sp;
> + const struct xfrm_state *state;
> +
> + if (sp == NULL || sp->len <= priv->spnum) {
> + regs->verdict.code = NFT_BREAK;
> + return;
> + }
> +
> + state = sp->xvec[priv->spnum];
> + nft_xfrm_state_get_key(priv, regs, state, nft_pf(pkt));
I'm not familiar enough with nftables to be sure, but doesn't the use
of nft_pf(pkt) in this context limit the matching of encapsulated
packets to the same family?
IIUC when an e.g. IPv6-in-IPv4 packet is matched, the nft_pf(pkt) will
be the decapsulated packet family - IPv6 - whereas the state may be
IPv4. So this check would not allow matching the 'underlay' address in
such cases.
I know this was a limitation in xt_policy. but is this intentional in
this matcher? or is it possible to use state->props.family when
validating the match instead of nft_pf(pkt)?
Eyal.
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_id2assoc
From: Marcelo Ricardo Leitner @ 2018-10-10 18:40 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Miller, LKML, linux-sctp, netdev, Neil Horman,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <CACT4Y+YYpjjvW-UCkHEXWZA50F==7JC1cnMvoAZHKmOqq=9vAw@mail.gmail.com>
On Wed, Oct 10, 2018 at 08:28:22PM +0200, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 8:13 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Wed, Oct 10, 2018 at 05:28:12PM +0200, Dmitry Vyukov wrote:
> >> On Fri, Oct 5, 2018 at 4:58 PM, Marcelo Ricardo Leitner
> >> <marcelo.leitner@gmail.com> wrote:
> >> > On Thu, Oct 04, 2018 at 01:48:03AM -0700, syzbot wrote:
> >> >> Hello,
> >> >>
> >> >> syzbot found the following crash on:
> >> >>
> >> >> HEAD commit: 4e6d47206c32 tls: Add support for inplace records encryption
> >> >> git tree: net-next
> >> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13834b81400000
> >> >> kernel config: https://syzkaller.appspot.com/x/.config?x=e569aa5632ebd436
> >> >> dashboard link: https://syzkaller.appspot.com/bug?extid=c7dd55d7aec49d48e49a
> >> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >> >>
> >> >> Unfortunately, I don't have any reproducer for this crash yet.
> >> >>
> >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> >> Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
> >> >>
> >> >> netlink: 'syz-executor1': attribute type 1 has an invalid length.
> >> >> ==================================================================
> >> >> BUG: KASAN: use-after-free in sctp_id2assoc+0x3a7/0x3e0
> >> >> net/sctp/socket.c:276
> >> >> Read of size 8 at addr ffff880195b3eb20 by task syz-executor2/15454
> >> >>
> >> >> CPU: 1 PID: 15454 Comm: syz-executor2 Not tainted 4.19.0-rc5+ #242
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> >> Google 01/01/2011
> >> >> Call Trace:
> >> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> >> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> >> >> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> >> >> kasan_report_error mm/kasan/report.c:354 [inline]
> >> >> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> >> >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> >> >> sctp_id2assoc+0x3a7/0x3e0 net/sctp/socket.c:276
> >> >
> >> > I'm not seeing yet how this could happen.
> >> > All sockopts here are serialized by sock_lock.
> >> > do_peeloff here would create another socket, but the issue was
> >> > triggered before that.
> >> > The same function that freed this memory, also removes the entry from
> >> > idr mapping, so this entry shouldn't be there anymore.
> >> >
> >> > I have only two theories so far:
> >> > - an issue with IDR/RCU.
> >> > - something else happened that just the call stacks are not revealing.
> >>
> >> The "asoc->base.sk != sk" check after idr_find suggests that we don't
> >> actually know what sock it belongs to. And if we don't know then
> >
> > Right. The check is more because the IDR is global and not per socket
> > (and we don't want sockets accessing asocs from other sockets), and not
> > that the asoc may move to another socket in between, but it also
> > protects from such cases, yes.
> >
> >> locking this sock can't help keeping another sock association alive.
> >> Am I missing something obvious here? Should we take assoc ref while we
> >
> > Not sure. Maybe I am. Thanks for looking into this, btw.
> >
> >> are still holding sctp_assocs_id_lock?
> >
> > Shouldn't be needed.
> >
> > Solely by the call stacks:
> > - we tried to establish a new asoc from a sctp_connect() call,
> > blocking one.
> > - it slept waiting for the connect
> > - (something closed the asoc in between the sleeps, because it freed
> > the asoc right when waking up on sctp_wait_for_connect())
> > - it freed the asoc after sleeping on it on sctp_wait_for_connect [A]
> > - another thread tried to peeloff that asoc [B]
> >
> > For [B] to access the asoc in question, it had to take the same sock
> > lock [A] had taken, and then the idr should not return an asoc in
> > sctp_i2asoc(). Note that we can't peeloff an asoc twice, thus why
> > the certainty here.
> >
> > If [B] actually kicked in before the sleep resumed, that should have
> > been fine because it took the same sock lock [A] would have to
> > re-take. In this case an asoc would have been returned by
> > sctp_id2asoc(), the asoc would have been moved to a new socket, but
> > all while holding the original socket sock lock.
>
> But why A and B use the same lock?
>
> sctp_assocs_id is global, so it contains asocs from all sockets, right?
> assoc id comes straight from userspaces.
> So isn't it possible that B uses completely different sock but passes
> assoc id from the A sock? Then B should find assoc in sctp_assocs_id,
> and at the point of "asoc->base.sk != sk" check the assoc can be
> already freed.
That explains it. Somehow I was thinking the issue was for reading
->dead instead. Now it's pretty clear. Then this should be the patch
we want. Can you please give it a spin? (only compile tested)
While holding the spinlock, an entry cannot be removed from the idr
and thus it cannot be freed. So even if the app uses an id from
another socket, it will still be there.
---8<---
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index f73e9d38d5ba..a7722f43aa69 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -271,11 +271,10 @@ struct sctp_association *sctp_id2assoc(struct sock *sk, sctp_assoc_t id)
spin_lock_bh(&sctp_assocs_id_lock);
asoc = (struct sctp_association *)idr_find(&sctp_assocs_id, (int)id);
+ if (asoc && (asoc->base.sk != sk || asoc->base.dead))
+ asoc = NULL;
spin_unlock_bh(&sctp_assocs_id_lock);
- if (!asoc || (asoc->base.sk != sk) || asoc->base.dead)
- return NULL;
-
return asoc;
}
^ permalink raw reply related
* Re: KASAN: use-after-free Read in sctp_id2assoc
From: Dmitry Vyukov @ 2018-10-10 18:28 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, David Miller, LKML, linux-sctp, netdev, Neil Horman,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <20181010181325.GD6761@localhost.localdomain>
On Wed, Oct 10, 2018 at 8:13 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Oct 10, 2018 at 05:28:12PM +0200, Dmitry Vyukov wrote:
>> On Fri, Oct 5, 2018 at 4:58 PM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > On Thu, Oct 04, 2018 at 01:48:03AM -0700, syzbot wrote:
>> >> Hello,
>> >>
>> >> syzbot found the following crash on:
>> >>
>> >> HEAD commit: 4e6d47206c32 tls: Add support for inplace records encryption
>> >> git tree: net-next
>> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13834b81400000
>> >> kernel config: https://syzkaller.appspot.com/x/.config?x=e569aa5632ebd436
>> >> dashboard link: https://syzkaller.appspot.com/bug?extid=c7dd55d7aec49d48e49a
>> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> >>
>> >> Unfortunately, I don't have any reproducer for this crash yet.
>> >>
>> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> >> Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
>> >>
>> >> netlink: 'syz-executor1': attribute type 1 has an invalid length.
>> >> ==================================================================
>> >> BUG: KASAN: use-after-free in sctp_id2assoc+0x3a7/0x3e0
>> >> net/sctp/socket.c:276
>> >> Read of size 8 at addr ffff880195b3eb20 by task syz-executor2/15454
>> >>
>> >> CPU: 1 PID: 15454 Comm: syz-executor2 Not tainted 4.19.0-rc5+ #242
>> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> >> Google 01/01/2011
>> >> Call Trace:
>> >> __dump_stack lib/dump_stack.c:77 [inline]
>> >> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
>> >> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
>> >> kasan_report_error mm/kasan/report.c:354 [inline]
>> >> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
>> >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>> >> sctp_id2assoc+0x3a7/0x3e0 net/sctp/socket.c:276
>> >
>> > I'm not seeing yet how this could happen.
>> > All sockopts here are serialized by sock_lock.
>> > do_peeloff here would create another socket, but the issue was
>> > triggered before that.
>> > The same function that freed this memory, also removes the entry from
>> > idr mapping, so this entry shouldn't be there anymore.
>> >
>> > I have only two theories so far:
>> > - an issue with IDR/RCU.
>> > - something else happened that just the call stacks are not revealing.
>>
>> The "asoc->base.sk != sk" check after idr_find suggests that we don't
>> actually know what sock it belongs to. And if we don't know then
>
> Right. The check is more because the IDR is global and not per socket
> (and we don't want sockets accessing asocs from other sockets), and not
> that the asoc may move to another socket in between, but it also
> protects from such cases, yes.
>
>> locking this sock can't help keeping another sock association alive.
>> Am I missing something obvious here? Should we take assoc ref while we
>
> Not sure. Maybe I am. Thanks for looking into this, btw.
>
>> are still holding sctp_assocs_id_lock?
>
> Shouldn't be needed.
>
> Solely by the call stacks:
> - we tried to establish a new asoc from a sctp_connect() call,
> blocking one.
> - it slept waiting for the connect
> - (something closed the asoc in between the sleeps, because it freed
> the asoc right when waking up on sctp_wait_for_connect())
> - it freed the asoc after sleeping on it on sctp_wait_for_connect [A]
> - another thread tried to peeloff that asoc [B]
>
> For [B] to access the asoc in question, it had to take the same sock
> lock [A] had taken, and then the idr should not return an asoc in
> sctp_i2asoc(). Note that we can't peeloff an asoc twice, thus why
> the certainty here.
>
> If [B] actually kicked in before the sleep resumed, that should have
> been fine because it took the same sock lock [A] would have to
> re-take. In this case an asoc would have been returned by
> sctp_id2asoc(), the asoc would have been moved to a new socket, but
> all while holding the original socket sock lock.
But why A and B use the same lock?
sctp_assocs_id is global, so it contains asocs from all sockets, right?
assoc id comes straight from userspaces.
So isn't it possible that B uses completely different sock but passes
assoc id from the A sock? Then B should find assoc in sctp_assocs_id,
and at the point of "asoc->base.sk != sk" check the assoc can be
already freed.
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_id2assoc
From: Marcelo Ricardo Leitner @ 2018-10-10 18:13 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Miller, LKML, linux-sctp, netdev, Neil Horman,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <CACT4Y+YVRWSF+VyoBB1vwDevt0gwZYz69bSAivmZDG6r4J-kaA@mail.gmail.com>
On Wed, Oct 10, 2018 at 05:28:12PM +0200, Dmitry Vyukov wrote:
> On Fri, Oct 5, 2018 at 4:58 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Thu, Oct 04, 2018 at 01:48:03AM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: 4e6d47206c32 tls: Add support for inplace records encryption
> >> git tree: net-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13834b81400000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=e569aa5632ebd436
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=c7dd55d7aec49d48e49a
> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >>
> >> Unfortunately, I don't have any reproducer for this crash yet.
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
> >>
> >> netlink: 'syz-executor1': attribute type 1 has an invalid length.
> >> ==================================================================
> >> BUG: KASAN: use-after-free in sctp_id2assoc+0x3a7/0x3e0
> >> net/sctp/socket.c:276
> >> Read of size 8 at addr ffff880195b3eb20 by task syz-executor2/15454
> >>
> >> CPU: 1 PID: 15454 Comm: syz-executor2 Not tainted 4.19.0-rc5+ #242
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> >> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> >> kasan_report_error mm/kasan/report.c:354 [inline]
> >> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> >> sctp_id2assoc+0x3a7/0x3e0 net/sctp/socket.c:276
> >
> > I'm not seeing yet how this could happen.
> > All sockopts here are serialized by sock_lock.
> > do_peeloff here would create another socket, but the issue was
> > triggered before that.
> > The same function that freed this memory, also removes the entry from
> > idr mapping, so this entry shouldn't be there anymore.
> >
> > I have only two theories so far:
> > - an issue with IDR/RCU.
> > - something else happened that just the call stacks are not revealing.
>
> The "asoc->base.sk != sk" check after idr_find suggests that we don't
> actually know what sock it belongs to. And if we don't know then
Right. The check is more because the IDR is global and not per socket
(and we don't want sockets accessing asocs from other sockets), and not
that the asoc may move to another socket in between, but it also
protects from such cases, yes.
> locking this sock can't help keeping another sock association alive.
> Am I missing something obvious here? Should we take assoc ref while we
Not sure. Maybe I am. Thanks for looking into this, btw.
> are still holding sctp_assocs_id_lock?
Shouldn't be needed.
Solely by the call stacks:
- we tried to establish a new asoc from a sctp_connect() call,
blocking one.
- it slept waiting for the connect
- (something closed the asoc in between the sleeps, because it freed
the asoc right when waking up on sctp_wait_for_connect())
- it freed the asoc after sleeping on it on sctp_wait_for_connect [A]
- another thread tried to peeloff that asoc [B]
For [B] to access the asoc in question, it had to take the same sock
lock [A] had taken, and then the idr should not return an asoc in
sctp_i2asoc(). Note that we can't peeloff an asoc twice, thus why
the certainty here.
If [B] actually kicked in before the sleep resumed, that should have
been fine because it took the same sock lock [A] would have to
re-take. In this case an asoc would have been returned by
sctp_id2asoc(), the asoc would have been moved to a new socket, but
all while holding the original socket sock lock.
^ permalink raw reply
* [BUG] Bluetooth 4.14.74-v7+: hci_connect_le_scan_cleanup() crash NULL deref Raspberry Pi 3B+
From: Andreas Mohr @ 2018-10-10 18:00 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S. Miller
Cc: linux-bluetooth, netdev, linux-kernel
Hello all,
[long time no see, good to be back!]
just newly got the following crash with a new setup:
[ 6.234357] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 7.114565] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 7.114582] brcmfmac: power management disabled
[ 7.522803] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 9.102052] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[ 11.887650] Bluetooth: HCI UART driver ver 2.3
[ 11.887660] Bluetooth: HCI UART protocol H4 registered
[ 11.887663] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 11.887811] Bluetooth: HCI UART protocol Broadcom registered
[ 13.399873] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[ 13.402896] Bridge firewalling registered
[ 13.424852] nf_conntrack version 0.5.0 (15360 buckets, 61440 max)
[ 14.284667] Netfilter messages via NETLINK v0.30.
[ 14.290169] ctnetlink v0.93: registering with nfnetlink.
[ 14.405316] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
[ 33.422932] NET: Registered protocol family 38
[75215.105699] Unable to handle kernel NULL pointer dereference at virtual address 00000012
[75215.109883] pgd = 80004000
[75215.112020] [00000012] *pgd=00000000
[75215.114129] Internal error: Oops: 17 [#1] SMP ARM
[75215.116262] Modules linked in: aes_arm_bs crypto_simd cryptd algif_skcipher af_alg ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc overlay hci_uart serdev rfcomm cmac bnep brcmfmac brcmutil cfg80211 snd_bcm2835(C) snd_pcm snd_timer snd uio_pdrv_genirq uio fixed ftdi_sio usbserial btusb btrtl btintel btbcm bluetooth ecdh_generic rfkill i2c_dev ip_tables x_tables ipv6
[75215.133930] CPU: 2 PID: 167 Comm: kworker/u9:2 Tainted: G C 4.14.74-v7+ #1149
[75215.139286] Hardware name: BCM2835
[75215.142121] Workqueue: hci0 hci_rx_work [bluetooth]
[75215.144853] task: b9315a00 task.stack: b71f8000
[75215.147707] PC is at hci_connect_le_scan_cleanup+0x14/0x124 [bluetooth]
[75215.150642] LR is at create_le_conn_complete+0xcc/0xd8 [bluetooth]
[75215.153455] pc : [<7f0dd0cc>] lr : [<7f0df4d4>] psr: 60000013
[75215.156326] sp : b71f9df0 ip : b71f9e10 fp : b71f9e0c
[75215.159124] r10: b2e86180 r9 : 00000088 r8 : b924b780
[75215.161834] r7 : b9da97e8 r6 : b9da9008 r5 : 00000000 r4 : b9da98b4
[75215.164616] r3 : 00200400 r2 : b9da98b4 r1 : 00000000 r0 : 00000000
[75215.167400] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[75215.170254] Control: 10c5383d Table: 195ac06a DAC: 00000055
[75215.173069] Process kworker/u9:2 (pid: 167, stack limit = 0xb71f8210)
[75215.175869] Stack: (0xb71f9df0 to 0xb71fa000)
[75215.178574] 9de0: b9da98b4 00000000 b9da9008 b9da97e8
[75215.183810] 9e00: b71f9e2c b71f9e10 7f0df4d4 7f0dd0c4 7f0df408 b9da9000 b2e86180 0000000e
[75215.188960] 9e20: b71f9ebc b71f9e30 7f0e57bc 7f0df414 b71f9e70 b71f9e74 b9315a80 b9315a00
[75215.194193] 9e40: ba372d78 00000000 b9315e60 80b8ed40 b71f9e8c 80b8ed40 a72136c0 b9da97f4
[75215.199699] 9e60: 60000013 00000000 00da97e8 b9da200d 7f0df408 00000000 b71f9e9c b71f9e88
[75215.205455] 9e80: 807a3eec 801ee19c b9da97e8 b2e86180 b71f9ebc b9da9708 b9da98b4 b9da9000
[75215.211367] 9ea0: b9da97e8 b9da9008 00000088 b2e86180 b71f9efc b71f9ec0 7f0d8b3c 7f0e54f4
[75215.217508] 9ec0: b9da9718 b9da901c b908c300 80137520 b71f9efc b9092580 b9da9708 b70dae00
[75215.223972] 9ee0: b908c300 00000000 00000088 00000000 b71f9f34 b71f9f00 801376f0 7f0d89d0
[75215.230596] 9f00: b70dae18 80c02d00 00000088 b70dae00 b9092598 b70dae00 b70dae18 80c02d00
[75215.237352] 9f20: 00000088 b9092580 b71f9f7c b71f9f38 80137a50 801375a4 b71f9f5c b71f8000
[75215.244292] 9f40: 00000000 80c02d00 80c88562 b71f8038 b979b01c b979b000 00000000 b722f300
[75215.251303] 9f60: b9092580 801379ec b979b01c b732fe80 b71f9fac b71f9f80 8013dad4 801379f8
[75215.258312] 9f80: 80102d94 b722f300 8013d998 00000000 00000000 00000000 00000000 00000000
[75215.265319] 9fa0: 00000000 b71f9fb0 8010810c 8013d9a4 00000000 00000000 00000000 00000000
[75215.272327] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[75215.279336] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[75215.286614] [<7f0dd0cc>] (hci_connect_le_scan_cleanup [bluetooth]) from [<7f0df4d4>] (create_le_conn_complete+0xcc/0xd8 [bluetooth])
[75215.293988] [<7f0df4d4>] (create_le_conn_complete [bluetooth]) from [<7f0e57bc>] (hci_event_packet+0x2d4/0x2de8 [bluetooth])
[75215.301354] [<7f0e57bc>] (hci_event_packet [bluetooth]) from [<7f0d8b3c>] (hci_rx_work+0x178/0x250 [bluetooth])
[75215.308585] [<7f0d8b3c>] (hci_rx_work [bluetooth]) from [<801376f0>] (process_one_work+0x158/0x454)
[75215.315681] [<801376f0>] (process_one_work) from [<80137a50>] (worker_thread+0x64/0x5b8)
[75215.322757] [<80137a50>] (worker_thread) from [<8013dad4>] (kthread+0x13c/0x16c)
[75215.329829] [<8013dad4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[75215.333466] Code: e92dd8f0 e24cb004 e52de004 e8bd4000 (e5d04012)
[75215.337146] ---[ end trace f3a6771e5232874d ]---
Context notes:
- Raspberry Pi 3B (not 3B+), Raspbian
- Linux [HOSTNAME] 4.14.74-v7+ #1149 SMP Mon Oct 8 17:39:42 BST 2018 armv7l GNU/Linux
- updated to *custom* manual setup (very newish kernel) yesterday (via rpi-update), rebooted
- builtin Bluetooth (hci0)
- external Bluetooth (hci1, CSR I believe)
- FHEM, with various modules regularly polling various Bluetooth clients, via hci0 only
- very newly erected wiring (relocated to different location, new external Bluetooth, etc., yesterday) setup
Returned to the location today, merely to
find external Bluetooth LED blinking *very* rapidly, then
fumbled the stick, at which moment LED went solid.
I returned a couple seconds later, LED had gone dark.
Few minutes later, connected to box, only to find this crash dump trace there.
It seems quite obvious that
this crash may have happened due to
implementation stack mis-handling a (temporary??) connector disconnect/power-loss issue.
Ran
git log v4.14..master -- net/bluetooth/hci_conn.c
, did not immediately see (m)any obviously relevant items.
Thus now reporting here (get_maintainer.pl...).
Thank you!
Greetings,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
^ permalink raw reply
* Re: [PATCH v2 lora-next 1/4] net: lora: sx1301: convert burst spi functions to regmap raw
From: Mark Brown @ 2018-10-10 10:19 UTC (permalink / raw)
To: Andreas Färber
Cc: Ben Whitten, starnight, hasnain.virk, netdev, liuxuenetmail,
shess, Ben Whitten, linux-spi@vger.kernel.org, Stefan Popa
In-Reply-To: <3959c93b-edb5-c6ff-ec36-57f84ab8623f@suse.de>
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
On Wed, Oct 10, 2018 at 09:59:29AM +0200, Andreas Färber wrote:
> Am 09.10.18 um 14:52 schrieb Ben Whitten:
> > - return spi_sync_transfer(priv->spi, xfr, 2);
> > + return regmap_raw_write(priv->regmap, reg, val, len);
> ... Which would mean we are lacking a noinc API for write here!
> @Mark/Stefan, any reason noinc was not implemented symmetrically?
Nobody wanted it enough to do the work of implementing it, there's
nothing stopping someone doing that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH V1 net-next 00/12] Improving performance and reducing latencies, by using latest capabilities exposed in ENA device
From: Jesper Dangaard Brouer @ 2018-10-10 10:15 UTC (permalink / raw)
To: Bshara, Saeed
Cc: Bshara, Nafea, Kiyanovski, Arthur, davem@davemloft.net,
netdev@vger.kernel.org, Woodhouse, David, Machulsky, Zorik,
Matushevsky, Alexander, Wilson, Matt, Liguori, Anthony,
Tzalik, Guy, Belgazal, Netanel, Saidi, Ali, Björn Töpel,
brouer
In-Reply-To: <1539119909353.25034@amazon.com>
On Tue, 9 Oct 2018 21:18:30 +0000 "Bshara, Saeed" <saeedb@amazon.com> wrote:
> Currently the driver allocate page per rx buffer, but we are
> considering to support mode where page split to 2 buffers in order to
> overcome memory fragmentation issue on low memory systems. but, this
> won't work with XDP, right?
> what's your advice?
XDP is easiest to implement with 1-page per rx buffer, but given ixgbe
and i40e violated this, it is possible to use a page-split approach
with 2 frames per page, like they do. Do notice that you have to
deviate from the standard 256 bytes headroom for that to fit (which
basically killed my idea of placing the SKB in this headroom).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
> From: Bshara, Nafea
> Sent: Tuesday, October 9, 2018 10:33 PM
> To: Jesper Dangaard Brouer; Kiyanovski, Arthur
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Woodhouse, David; Machulsky, Zorik; Matushevsky, Alexander; Bshara, Saeed; Wilson, Matt; Liguori, Anthony; Tzalik, Guy; Belgazal, Netanel; Saidi, Ali; Björn Töpel
> Subject: Re: [PATCH V1 net-next 00/12] Improving performance and reducing latencies, by using latest capabilities exposed in ENA device
>
> It is high priority for us right after this major release get merged.
>
> On 10/9/18, 12:31 PM, "Jesper Dangaard Brouer" <brouer@redhat.com> wrote:
>
>
> On Tue, 9 Oct 2018 21:44:57 +0300 <akiyano@amazon.com> wrote:
>
> > From: Arthur Kiyanovski <akiyano@amazon.com>
> >
> > This patchset introduces the following:
> > 1. A new placement policy of Tx headers and descriptors, which takes
> > advantage of an option to place headers + descriptors in device memory
> > space. This is sometimes referred to as LLQ - low latency queue.
> > The patch set defines the admin capability, maps the device memory as
> > write-combined, and adds a mode in transmit datapath to do header +
> > descriptor placement on the device.
> > 2. Support for RX checksum offloading
> > 3. Miscelaneous small improvements and code cleanups
>
> What are your plans for XDP?
>
> You are unsure ask your-colleague David Woodhouse, who I've discussed
> this with when he attended my talk at Kernel-Recipes[1], slide[2].
>
> [1] https://kernel-recipes.org/en/2018/talks/xdp-a-new-programmable-network-layer/
> [2] http://people.netfilter.org/hawk/presentations/KernelRecipes2018/XDP_Kernel_Recipes_2018.pdf
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: mscc: allow extracting the FCS into the skb
From: David Miller @ 2018-10-10 17:26 UTC (permalink / raw)
To: f.fainelli
Cc: antoine.tenart, andrew, netdev, linux-kernel, thomas.petazzoni,
alexandre.belloni, quentin.schulz, allan.nielsen
In-Reply-To: <28179B83-2C71-47FA-9D9C-49237E4A07AE@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 10 Oct 2018 09:25:01 -0700
>
>
> On October 10, 2018 7:46:31 AM PDT, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
>>Hi all,
>>
>>On Tue, Oct 02, 2018 at 02:43:23PM +0200, Andrew Lunn wrote:
>>> > The question could be "do we need len += ETH_FCS_LEN" to account
>>for the
>>> > FCS when NETIF_F_RXFCS is used", but I looked at other drivers and
>>it
>>> > seemed to me the FCS is not accounted in the stats. Should it be?
>>>
>>> There does not appear to be a good answer to that. I submitted a
>>patch
>>> to a driver i'm using to not count it, so that the stats counters we
>>> consistent with another driver. The patch was rejected.
>>>
>>> I think the best you can do is flip a coin, and then document it
>>using
>>> a comment about if it is/is not included.
>>
>>I'll leave it as-is then :)
>>
>>@Dave, Florian: it seems to me no modification was requested after
>>discussing those changes. Where do we stand regarding the patch?
>
> Silence means agreement, thanks for your explanation, no more questions or concerns on my side.
You'll probably need to resubmit the patch anew though.
^ permalink raw reply
* Re: [PATCH net 0/3] devlink param type string fixes
From: David Miller @ 2018-10-10 17:20 UTC (permalink / raw)
To: moshe; +Cc: jiri, netdev, linux-kernel
In-Reply-To: <1539176967-22172-1-git-send-email-moshe@mellanox.com>
From: Moshe Shemesh <moshe@mellanox.com>
Date: Wed, 10 Oct 2018 16:09:24 +0300
> This patchset fixes devlink param infrastructure for string param type.
>
> The devlink param infrastructure doesn't handle copying the string data
> correctly. The first two patches fix it and the third patch adds helper
> function to safely copy string value without exceeding
> DEVLINK_PARAM_MAX_STRING_VALUE.
Series applied, thank you.
^ permalink raw reply
* RE: [PATCH v2 lora-next 1/4] net: lora: sx1301: convert burst spi functions to regmap raw
From: Ben Whitten @ 2018-10-10 9:22 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten, Mark Brown
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org, liuxuenetmail@gmail.com,
shess@hessware.de, linux-spi@vger.kernel.org, Stefan Popa
In-Reply-To: <3959c93b-edb5-c6ff-ec36-57f84ab8623f@suse.de>
> Subject: Re: [PATCH v2 lora-next 1/4] net: lora: sx1301:
> convert burst spi functions to regmap raw
>
> Hi Ben and Mark,
>
> Am 09.10.18 um 14:52 schrieb Ben Whitten:
> > As we have caching disabled we can access the regmap
> using raw for our
> > firmware reading and writing bursts.
> > We also remove the now defunct spi element from the
> structure as this
> > completes the move to regmap.
> >
> > Signed-off-by: Ben Whitten
> <ben.whitten@lairdtech.com>
> > ---
> > drivers/net/lora/sx1301.c | 26 +++++++++++++++++------
> ---
> > drivers/net/lora/sx1301.h | 2 --
> > 2 files changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/lora/sx1301.c
> b/drivers/net/lora/sx1301.c
> > index fd29258..5ab0e2d 100644
> > --- a/drivers/net/lora/sx1301.c
> > +++ b/drivers/net/lora/sx1301.c
> > @@ -76,19 +76,28 @@ static struct regmap_config
> sx1301_regmap_config = {
> >
> > static int sx1301_read_burst(struct sx1301_priv *priv, u8
> reg, u8 *val, size_t len)
> > {
> > - u8 addr = reg & 0x7f;
> > - return spi_write_then_read(priv->spi, &addr, 1, val,
> len);
> > + size_t max;
> > +
> > + max = regmap_get_raw_read_max(priv->regmap);
> > + if (max && max < len) {
> > + dev_err(priv->dev, "Burst greater then max
> raw read\n");
> > + return -EINVAL;
> > + }
> > +
> > + return regmap_raw_read(priv->regmap, reg, val,
> len);
>
> I believe the way we are using it with a single register needs
> regmap_noinc_read() instead, in case we ever want to
> enable caching? ...
Certainly, the noinc was introduced in 4.19 lets rebase lora-next
and use this API instead.
>
> > }
> >
> > static int sx1301_write_burst(struct sx1301_priv *priv, u8
> reg, const u8 *val, size_t len)
> > {
> > - u8 addr = reg | BIT(7);
> > - struct spi_transfer xfr[2] = {
> > - { .tx_buf = &addr, .len = 1 },
> > - { .tx_buf = val, .len = len },
> > - };
> > + size_t max;
> > +
> > + max = regmap_get_raw_write_max(priv->regmap);
> > + if (max && max < len) {
> > + dev_err(priv->dev, "Burst greater then max
> raw write\n");
> > + return -EINVAL;
> > + }
> >
> > - return spi_sync_transfer(priv->spi, xfr, 2);
> > + return regmap_raw_write(priv->regmap, reg, val,
> len);
>
> ... Which would mean we are lacking a noinc API for write
> here!
>
> @Mark/Stefan, any reason noinc was not implemented
> symmetrically?
>
> For sx1276 I have local regmap conversion patches, but I
> kept getting
> -EINVAL for bursts and haven't figured out why yet. Need to
> compare to
> your code - I assume you successfully tested this, Ben.
Yes I was able to load and verify/run the firmware using this
patch on my Sentrius RG1xx board.
Thanks,
Ben
^ permalink raw reply
* Re: BUG: corrupted list in p9_read_work
From: syzbot @ 2018-10-10 16:29 UTC (permalink / raw)
To: asmadeus, davem, dvyukov, ericvh, linux-kernel, lucho, netdev,
rminnich, syzkaller-bugs, v9fs-developer
In-Reply-To: <20181010161003.GA5371@nautica>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com
Tested on:
commit: e4ca13f7d075 9p/trans_fd: abort p9_read_work if req status..
git tree: git://github.com/martinetd/linux.git for-syzbot
kernel config: https://syzkaller.appspot.com/x/.config?x=fada1c387645ed03
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* Re: [PATCH net-next] net: mscc: allow extracting the FCS into the skb
From: Florian Fainelli @ 2018-10-10 16:25 UTC (permalink / raw)
To: Antoine Tenart, Andrew Lunn
Cc: davem, netdev, linux-kernel, thomas.petazzoni, alexandre.belloni,
quentin.schulz, allan.nielsen
In-Reply-To: <20181010144631.GE3368@kwain>
On October 10, 2018 7:46:31 AM PDT, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
>Hi all,
>
>On Tue, Oct 02, 2018 at 02:43:23PM +0200, Andrew Lunn wrote:
>> > The question could be "do we need len += ETH_FCS_LEN" to account
>for the
>> > FCS when NETIF_F_RXFCS is used", but I looked at other drivers and
>it
>> > seemed to me the FCS is not accounted in the stats. Should it be?
>>
>> There does not appear to be a good answer to that. I submitted a
>patch
>> to a driver i'm using to not count it, so that the stats counters we
>> consistent with another driver. The patch was rejected.
>>
>> I think the best you can do is flip a coin, and then document it
>using
>> a comment about if it is/is not included.
>
>I'll leave it as-is then :)
>
>@Dave, Florian: it seems to me no modification was requested after
>discussing those changes. Where do we stand regarding the patch?
Silence means agreement, thanks for your explanation, no more questions or concerns on my side.
--
Florian
^ permalink raw reply
* RE: [PATCH net-next v2] net: core: change bool members of struct net_device to bitfield members
From: David Laight @ 2018-10-10 8:59 UTC (permalink / raw)
To: 'Eric Dumazet', Heiner Kallweit, David Ahern,
David Miller
Cc: netdev@vger.kernel.org
In-Reply-To: <a7286ffb-0de5-bb9c-7dc4-7d88d952bb2f@gmail.com>
From: Eric Dumazet
> Sent: 09 October 2018 21:52
>
> On 10/09/2018 01:24 PM, Heiner Kallweit wrote:
>
> > Reordering the struct members to fill the holes could be a little tricky
> > and could have side effects because it may make a performance difference
> > whether certain members are in one cacheline or not.
> > And whether it's worth to spend this effort (incl. the related risks)
> > just to save a few bytes (also considering that typically we have quite
> > few instances of struct net_device)?
>
> Not really.
>
> In fact we probably should spend time reordering fields for performance,
> since some new fields were added a bit randomly, breaking the goal of data locality.
>
> Some fields are used in control path only can could be moved out of the cache lines
> needed in data path (fast path).
Interesting thought....
The memory allocator rounds sizes up to a power of 2 and gives out memory
aligned to that value.
This means that the cache lines just above powers of 2 are used far
more frequently than those below one.
This will be made worse because the commonly used fields are normally at
the start of a structure.
This ought to be measurable?
Has anyone tried randomly splitting the padding between the start
and end of the allocation (while maintaining cache alignment)?
(Not sure how this would affect kfree().)
Or splitting pages (or small groups of pages) into non-power of 2
size blocks?
For instance you get three 1344 (21*64) byte blocks and five 768 byte
blocks into a 4k page.
These could give a significant footprint reduction as well as
balancing out cache line usage.
I also wonder whether it is right to add a lot of padding to cache-line
align structure members on systems with large cache lines.
The intention is probably to get a few fields into the same cache line
not to add padding that may be larger than aggregate size of the fields.
Oh - and it is somewhat pointless because kmalloc() isn't guaranteed
to give out cache-line aligned buffers.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: Re: BUG: corrupted list in p9_read_work
From: Dominique Martinet @ 2018-10-10 16:10 UTC (permalink / raw)
To: syzbot
Cc: davem, dvyukov, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <20181010160022.GD20918@nautica>
Dominique Martinet wrote on Wed, Oct 10, 2018:
> It works though, is it just picky because I didn't end it in .git? let's
> try again, sorry for the noise...
>
> #syz test: git://github.com/martinetd/linux.git e4ca13f7d075e551dc158df6af18fb412a1dba0a
And I guess the commit hash needs to be in the default clone branch to
work ?
('git fetch <repo> <hash>' happily fetches the commit in a new clone for
me... But that feels like a github specific behaviour maybe)
Oh, well; made a branch for it, last try for me.
#syz test: git://github.com/martinetd/linux.git for-syzbot
--
Dominique
^ permalink raw reply
* Re: [PATCH] selftests: bpf: install script with_addr.sh
From: Song Liu @ 2018-10-10 16:07 UTC (permalink / raw)
To: Anders Roxell
Cc: Alexei Starovoitov, Daniel Borkmann, shuah, Networking, open list,
linux-kselftest
In-Reply-To: <20181010142704.26990-1-anders.roxell@linaro.org>
On Wed, Oct 10, 2018 at 7:28 AM Anders Roxell <anders.roxell@linaro.org> wrote:
>
> When test_flow_dissector.sh runs it complains that it can't find script
> with_addr.sh:
>
> ./test_flow_dissector.sh: line 81: ./with_addr.sh: No such file or
> directory
>
> Rework so that with_addr.sh gets installed, add it to
> TEST_PROGS_EXTENDED variable.
>
> Fixes: 50b3ed57dee9 ("selftests/bpf: test bpf flow dissection")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/testing/selftests/bpf/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 1381ab81099c..efd108ff737d 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -51,6 +51,8 @@ TEST_PROGS := test_kmod.sh \
> test_skb_cgroup_id.sh \
> test_flow_dissector.sh
>
> +TEST_PROGS_EXTENDED := with_addr.sh
> +
> # Compile but not part of 'make run_tests'
> TEST_GEN_PROGS_EXTENDED = test_libbpf_open test_sock_addr test_skb_cgroup_id_user \
> flow_dissector_load test_flow_dissector
> --
> 2.19.1
>
^ permalink raw reply
* Re: [PATCH] selftests: bpf: add config fragment LWTUNNEL
From: Song Liu @ 2018-10-10 16:06 UTC (permalink / raw)
To: Anders Roxell
Cc: Alexei Starovoitov, Daniel Borkmann, shuah, Networking, open list,
linux-kselftest
In-Reply-To: <20181010092123.26218-1-anders.roxell@linaro.org>
On Wed, Oct 10, 2018 at 2:23 AM Anders Roxell <anders.roxell@linaro.org> wrote:
>
> When test_lwt_seg6local.sh was added commit c99a84eac026
> ("selftests/bpf: test for seg6local End.BPF action") config fragment
> wasn't added, and without CONFIG_LWTUNNEL enabled we see this:
> Error: CONFIG_LWTUNNEL is not enabled in this kernel.
> selftests: test_lwt_seg6local [FAILED]
>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/testing/selftests/bpf/config | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
> index 3655508f95fd..dd49df5e2df4 100644
> --- a/tools/testing/selftests/bpf/config
> +++ b/tools/testing/selftests/bpf/config
> @@ -19,3 +19,4 @@ CONFIG_CRYPTO_SHA256=m
> CONFIG_VXLAN=y
> CONFIG_GENEVE=y
> CONFIG_NET_CLS_FLOWER=m
> +CONFIG_LWTUNNEL=y
> --
> 2.19.1
>
^ permalink raw reply
* Re: BUG: corrupted list in p9_read_work
From: syzbot @ 2018-10-10 16:02 UTC (permalink / raw)
To: asmadeus, davem, dvyukov, ericvh, linux-kernel, lucho, netdev,
rminnich, syzkaller-bugs, v9fs-developer
In-Reply-To: <20181010160022.GD20918@nautica>
Hello,
syzbot tried to test the proposed patch but build/boot failed:
failed to checkout kernel repo git://github.com/martinetd/linux.git on
commit e4ca13f7d075e551dc158df6af18fb412a1dba0a: failed to run
["git" "checkout" "e4ca13f7d075e551dc158df6af18fb412a1dba0a"]: exit status
128
fatal: reference is not a tree: e4ca13f7d075e551dc158df6af18fb412a1dba0a
Tested on:
commit: [unknown]
git tree: git://github.com/martinetd/linux.git
e4ca13f7d075e551dc158df6af18fb412a1dba0a
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
^ permalink raw reply
* Re: Re: BUG: corrupted list in p9_read_work
From: Dominique Martinet @ 2018-10-10 16:00 UTC (permalink / raw)
To: syzbot
Cc: davem, dvyukov, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <00000000000010889e0577e0f5f2@google.com>
syzbot wrote on Wed, Oct 10, 2018:
>>> But note that syzbot can test fixes itself on request. It boils down
>>> to just giving it the patch and the base tree:
>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
>
>> .. and for clarifying that bit, let's try that! :)
>
>> #syz test: git://github.com/martinetd/linux
>> e4ca13f7d075e551dc158df6af18fb412a1dba0a
>
> "git://github.com/martinetd/linux" does not look like a valid git
> repo address.
It works though, is it just picky because I didn't end it in .git? let's
try again, sorry for the noise...
#syz test: git://github.com/martinetd/linux.git e4ca13f7d075e551dc158df6af18fb412a1dba0a
--
Dominique
^ permalink raw reply
* Re: BUG: corrupted list in p9_read_work
From: Dominique Martinet @ 2018-10-10 15:58 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Leon Romanovsky, syzbot, David Miller, Eric Van Hensbergen, LKML,
Latchesar Ionkov, netdev, Ron Minnich, syzkaller-bugs,
v9fs-developer
In-Reply-To: <CACT4Y+Zx5nDN-H8WfC4WtgK7YeAWZig9WsDr1J4DXZBZb+vgWQ@mail.gmail.com>
Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> > The problem is that you can't just give the client a file like trans fd;
> > you'd need to open an ""rdma socket"" (simplifying wording a bit), and
> > afaik there is no standard tool for it ; or rather, the problem is that
> > RDMA is packet based so even if there were you can't just write stuff
> > in a fd and hope it'll work, so you need a server.
> >
> > If you're interested, 9p is trivial enough that I could provide you with
> > a trivial server that works like your file (just need to reimplement
> > something that parses header to packetize it properly; so you could
> > write to its stdin for example) ; that'd require some setup in the VM
> > (configure rxe and install that tool), but it would definitely be
> > possible.
> > What do you think ?
>
> I would like to hear more details.
> Opening a socket is not a problem. Why do we need a tool for this?
Sorry, that's my head thinking unixy and piping things :)
> I don't understand the problem with "packet-based" and what does it
> mean to have a separate server? Any why?
Packet-based means you can't just read/write in a fd and expect the
other side to know where to cut the packets to send it to the client,
but if we do it internally there's no problem. We know where to cut.
> We definitely don't want to involve a separate third-party server,
> that's very problematic for multiple reasons. But we can have a chunk
> of custom C code inside of syzkaller.
> What exactly setup we need?
The setup itself isn't that bad, it's actually pretty much trivial - on
a fedora VM I just had to run 'rxe_cfg start ens3' (virtio interface
name) and then the infiniband tools are happy e.g. ibv_devinfo should
list an interface if you have the userspace library that should have
come with rxe_cfg.
(specifically, my VM uses /etc/libibverbs.d/rxe.driver to point to the
lib, and /usr/lib64/libibverbs/librxe-rdmav16.so the lib itself)
Once tools like ibv_devinfo list the interface, it means syzkaller can
use it, and very probably means the kernel can as well; that's it.
> I guess it will make things simpler if you provide some kind of "hello
> world" C program that mounts 9p/rdma. I don't need exact messages
> (they will be same as with pipe transport, right?) nor actual server
> implementation, but just the place where to inject these packets.
That's still the tricky part, I'm afraid... Making a separate server
would have been easy because I could have reused some of my junk for the
actual connection handling (some rdma helper library I wrote ages
ago[1]), but if you're going to just embed C code you'll probably want
something lower level? I've never seen syzkaller use any library call
but I'm not even sure I would know how to create a qp without
libibverbs, would standard stuff be OK ?
I think the interface improved quite a bit since I last looked at it so
I'll need a bit of time to figure it out again but I'll send you a
simple conection with a few messages soonish™
[1] https://github.com/cea-hpc/mooshika
--
Dominique
^ permalink raw reply
* Re: [PATCH v2 lora-next 1/4] net: lora: sx1301: convert burst spi functions to regmap raw
From: Andreas Färber @ 2018-10-10 7:59 UTC (permalink / raw)
To: Ben Whitten, Mark Brown
Cc: starnight, hasnain.virk, netdev, liuxuenetmail, shess,
Ben Whitten, linux-spi@vger.kernel.org, Stefan Popa
In-Reply-To: <1539089532-2481-2-git-send-email-ben.whitten@lairdtech.com>
Hi Ben and Mark,
Am 09.10.18 um 14:52 schrieb Ben Whitten:
> As we have caching disabled we can access the regmap using raw for our
> firmware reading and writing bursts.
> We also remove the now defunct spi element from the structure as this
> completes the move to regmap.
>
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> drivers/net/lora/sx1301.c | 26 +++++++++++++++++---------
> drivers/net/lora/sx1301.h | 2 --
> 2 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
> index fd29258..5ab0e2d 100644
> --- a/drivers/net/lora/sx1301.c
> +++ b/drivers/net/lora/sx1301.c
> @@ -76,19 +76,28 @@ static struct regmap_config sx1301_regmap_config = {
>
> static int sx1301_read_burst(struct sx1301_priv *priv, u8 reg, u8 *val, size_t len)
> {
> - u8 addr = reg & 0x7f;
> - return spi_write_then_read(priv->spi, &addr, 1, val, len);
> + size_t max;
> +
> + max = regmap_get_raw_read_max(priv->regmap);
> + if (max && max < len) {
> + dev_err(priv->dev, "Burst greater then max raw read\n");
> + return -EINVAL;
> + }
> +
> + return regmap_raw_read(priv->regmap, reg, val, len);
I believe the way we are using it with a single register needs
regmap_noinc_read() instead, in case we ever want to enable caching? ...
> }
>
> static int sx1301_write_burst(struct sx1301_priv *priv, u8 reg, const u8 *val, size_t len)
> {
> - u8 addr = reg | BIT(7);
> - struct spi_transfer xfr[2] = {
> - { .tx_buf = &addr, .len = 1 },
> - { .tx_buf = val, .len = len },
> - };
> + size_t max;
> +
> + max = regmap_get_raw_write_max(priv->regmap);
> + if (max && max < len) {
> + dev_err(priv->dev, "Burst greater then max raw write\n");
> + return -EINVAL;
> + }
>
> - return spi_sync_transfer(priv->spi, xfr, 2);
> + return regmap_raw_write(priv->regmap, reg, val, len);
... Which would mean we are lacking a noinc API for write here!
@Mark/Stefan, any reason noinc was not implemented symmetrically?
For sx1276 I have local regmap conversion patches, but I kept getting
-EINVAL for bursts and haven't figured out why yet. Need to compare to
your code - I assume you successfully tested this, Ben.
Regards,
Andreas
> }
>
> static int sx1301_soft_reset(struct sx1301_priv *priv)
> @@ -566,7 +575,6 @@ static int sx1301_probe(struct spi_device *spi)
>
> spi_set_drvdata(spi, netdev);
> priv->dev = &spi->dev;
> - priv->spi = spi;
>
> priv->regmap = devm_regmap_init_spi(spi, &sx1301_regmap_config);
> if (IS_ERR(priv->regmap)) {
> diff --git a/drivers/net/lora/sx1301.h b/drivers/net/lora/sx1301.h
> index e939c02..e6400f8 100644
> --- a/drivers/net/lora/sx1301.h
> +++ b/drivers/net/lora/sx1301.h
> @@ -12,7 +12,6 @@
> #include <linux/regmap.h>
> #include <linux/gpio/consumer.h>
> #include <linux/lora/dev.h>
> -#include <linux/spi/spi.h>
>
> #define SX1301_CHIP_VERSION 103
>
> @@ -64,7 +63,6 @@
> struct sx1301_priv {
> struct lora_dev_priv lora;
> struct device *dev;
> - struct spi_device *spi;
> struct gpio_desc *rst_gpio;
> struct regmap *regmap;
> };
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v8 10/15] octeontx2-af: Reconfig MSIX base with IOVA
From: Arnd Bergmann @ 2018-10-10 7:58 UTC (permalink / raw)
To: Sunil Kovvuri; +Cc: Networking, David Miller, linux-soc, gakula, sgoutham
In-Reply-To: <CA+sq2CcknQ1W+KjdXwSagv2O8=XEH6qm1ssj-8D1wy+3FuVuJw@mail.gmail.com>
On Wed, Oct 10, 2018 at 9:36 AM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> On Tue, Oct 9, 2018 at 5:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Oct 9, 2018 at 11:20 AM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> > > On Tue, Oct 9, 2018 at 1:27 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Oct 9, 2018 at 9:03 AM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> > > > > On Mon, Oct 8, 2018 at 5:38 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > > On Sun, Oct 7, 2018 at 5:01 PM <sunil.kovvuri@gmail.com> wrote:
> > > > I think if you enable CONFIG_DEBUG_VIRTUAL, the virt_to_page()
> > > > above should trigger a warning in
> > > >
> > > > phys_addr_t __virt_to_phys(unsigned long x)
> > > > {
> > > > WARN(!__is_lm_address(x),
> > > > "virt_to_phys used for non-linear address: %pK (%pS)\n",
> > > > (void *)x,
> > > > (void *)x);
> > > >
> > > > return __virt_to_phys_nodebug(x);
> > > > }
> > > >
> > > > Can you verify that?
> > >
> > > No, it isn't, as for 64bit systems CONFIG_SPARSEMEM_VMEMMAP is enabled.
> >
> > But that is also user-selectable, right? It still seems to be really
> > fragile to rely on non-documented behavior of virt_to_phys()
> > here, if that only works for some configurations.
> >
> > > But is there any alternative to what is being done ?
> >
> > I'm not completely sure, but there may be a way to do this correctly
> > using the iommu API instead of the dma-mapping API. What you do
> > here is fairly rare, but not unprecedented.
>
> After further checking the only way i found is using dma_map_resource() which
> accepts physical address and creates a mapping. Will test and submit next series
> with the changes.
Ah, perfect. I remember having seen this in the past, but forgot about
it when commenting here. This should be the correct way to do it. If
it doesn't work, we need to fix the implementation.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 05/19] net: usb: aqc111: Introduce PHY access
From: Igor Russkikh @ 2018-10-10 7:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181010005852.GA20147@lunn.ch>
On 10.10.2018 03:58, Andrew Lunn wrote:
>
> I just discovered driver_priv.
>
> https://elixir.bootlin.com/linux/v4.19-rc7/source/include/linux/usb/usbnet.h#L33
>
> It would be good to use that, to avoid the casts.
Looks good to me, thanks.
Regards,
Igor
^ permalink raw reply
* Re: [PATCH v8 10/15] octeontx2-af: Reconfig MSIX base with IOVA
From: Sunil Kovvuri @ 2018-10-10 7:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Netdev List, David S. Miller, linux-soc, Geetha sowjanya,
Sunil Goutham
In-Reply-To: <CAK8P3a21m8Uw6JkjU2-eG9p4yzcpiqgR5PcFeATX9+SbUMqGSg@mail.gmail.com>
On Tue, Oct 9, 2018 at 5:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Oct 9, 2018 at 11:20 AM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> >
> > On Tue, Oct 9, 2018 at 1:27 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Tue, Oct 9, 2018 at 9:03 AM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> > > > On Mon, Oct 8, 2018 at 5:38 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Sun, Oct 7, 2018 at 5:01 PM <sunil.kovvuri@gmail.com> wrote:
> > > I think if you enable CONFIG_DEBUG_VIRTUAL, the virt_to_page()
> > > above should trigger a warning in
> > >
> > > phys_addr_t __virt_to_phys(unsigned long x)
> > > {
> > > WARN(!__is_lm_address(x),
> > > "virt_to_phys used for non-linear address: %pK (%pS)\n",
> > > (void *)x,
> > > (void *)x);
> > >
> > > return __virt_to_phys_nodebug(x);
> > > }
> > >
> > > Can you verify that?
> > >
> > > Arnd
> >
> > No, it isn't, as for 64bit systems CONFIG_SPARSEMEM_VMEMMAP is enabled.
>
> But that is also user-selectable, right? It still seems to be really
> fragile to rely on non-documented behavior of virt_to_phys()
> here, if that only works for some configurations.
>
> > But is there any alternative to what is being done ?
>
> I'm not completely sure, but there may be a way to do this correctly
> using the iommu API instead of the dma-mapping API. What you do
> here is fairly rare, but not unprecedented.
>
> Arnd
After further checking the only way i found is using dma_map_resource() which
accepts physical address and creates a mapping. Will test and submit next series
with the changes.
Thanks,
Sunil.
^ permalink raw reply
* Re: [PATCH] qtnfmac: avoid uninitialized variable access
From: Sergey Matyukevich @ 2018-10-10 14:56 UTC (permalink / raw)
To: Kalle Valo
Cc: Igor Mitsyanko, Arnd Bergmann, Igor Mitsyanko, Avinash Patil,
Sergey Matyukevich, Kalle Valo, David S. Miller,
Andrey Shevchenko, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20181009202507.xs5bcaq5pi4zcps3@bars>
> > When qtnf_trans_send_cmd_with_resp() fails, we have not yet initialized
> > 'resp', as pointed out by a valid gcc warning:
> >
> > drivers/net/wireless/quantenna/qtnfmac/commands.c: In function 'qtnf_cmd_send_with_reply':
> > drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: error: 'resp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > Since 'resp_skb' is also not set here, we can skip all further
> > processing and just print the warning and return the failure code.
> >
> > Fixes: c6ed298ffe09 ("qtnfmac: cleanup and unify command error handling")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for the patch! And for reminding me that I forgot to enable
> gcc warnings in CI builds in addition to sparse checks.
>
> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Hi Kalle,
Could you please hold back applying this patch for now. We have got
another report for the same function, this time static analysis tool
warning. It looks like the patch from Arnd does not cover both cases.
So we will take a closer look and send a combined fix later.
Regards,
Sergey
^ permalink raw reply
* Re: Re: BUG: corrupted list in p9_read_work
From: syzbot @ 2018-10-10 14:49 UTC (permalink / raw)
To: Dominique Martinet
Cc: asmadeus, davem, dvyukov, ericvh, linux-kernel, lucho, netdev,
rminnich, syzkaller-bugs, v9fs-developer
In-Reply-To: <20181010144855.GB20918@nautica>
> Dmitry Vyukov wrote on Wed, Oct 10, 2018:
>> > Back to the current patch, since as I said I am not confident this is a
>> > good enough fix for the current bug, will I get notified if the bug
>> > happens again once the patch hits linux-next with the Reported-by tag ?
>> > (I don't have the setup necessary to run a syz repro as there is no C
>> > repro, and won't have much time to do that setup sorry)
>> Yes, the bug will be reported again if it still happens after the
>> patch is merged (not just into linux-next, but into all tested trees,
>> but it does not matter much). So marking bugs as fixed tentatively is
>> fine if that's our best guess.
> Ok, thanks for confirming...
>> But note that syzbot can test fixes itself on request. It boils down
>> to just giving it the patch and the base tree:
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
> .. and for clarifying that bit, let's try that! :)
> #syz test: git://github.com/martinetd/linux
> e4ca13f7d075e551dc158df6af18fb412a1dba0a
"git://github.com/martinetd/linux" does not look like a valid git repo
address.
> --
> Dominique
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox