* [PATCH] amd-xgbe: Fix unused suspend handlers build warning
From: Borislav Petkov @ 2016-11-26 20:53 UTC (permalink / raw)
To: LKML; +Cc: Tom Lendacky, netdev
From: Borislav Petkov <bp@suse.de>
Fix:
drivers/net/ethernet/amd/xgbe/xgbe-main.c:835:12: warning: ‘xgbe_suspend’ defined
but not used [-Wunused-function]
drivers/net/ethernet/amd/xgbe/xgbe-main.c:855:12: warning: ‘xgbe_resume’ defined
but not used [-Wunused-function]
I see it during randconfig builds here.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index e10e569c0d5f..2e8451b0a74a 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -831,7 +831,7 @@ static int xgbe_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int xgbe_suspend(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
@@ -876,7 +876,7 @@ static int xgbe_resume(struct device *dev)
return ret;
}
-#endif /* CONFIG_PM */
+#endif /* CONFIG_PM_SLEEP */
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgbe_acpi_match[] = {
--
2.10.0
^ permalink raw reply related
* Re: net: GPF in eth_header
From: Eric Dumazet @ 2016-11-26 20:34 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzkaller, Dmitry Vyukov, David Miller, Tom Herbert,
Alexander Duyck, Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca,
netdev, LKML
In-Reply-To: <CACPEyM-4dwvmEvq3uTN_8Y-YosP8qA3cYV+oxkufFOn8M+=hew@mail.gmail.com>
2016-11-26 12:05 GMT-08:00 Eric Dumazet <erdlkml@gmail.com>:
>> Hi Eric,
>>
>> The crash happens when the kernel tries to access shadow for nonmapped memory.
>>
>> The issue here is an integer overflow which happens in neigh_resolve_output().
>> skb_network_offset(skb) can return negative number, but __skb_pull()
>> accepts unsigned int as len.
>> As a result, the least significat bit in higher 32 bits of skb->data
>> gets set and we get an out-of-bounds with offset of 4 GB.
>>
>> I've attached a short reproducer, but you either need KASAN or to add
>> a BUG_ON to see the crash.
>> In this reproducer skb_network_offset() becomes negative after merging
>> two ipv6 fragments.
>>
>> I actually see multiple places where skb_network_offset() is used as
>> an argument to skb_pull().
>> So I guess every place can potentially be buggy.
>
> Well, I think the intent is to accept a negative number.
>
> This definitely was assumed by commit e1f165032c8bade authors !
>
> I guess they were using a 32bit kernel for their tests.
Correct fix would be to use
skb_push(skb, -skb_network_offset(skb));
As done in other locations...
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code
From: Bjørn Mork @ 2016-11-26 20:30 UTC (permalink / raw)
To: Daniele Palmas; +Cc: Oliver Neukum, linux-usb, netdev
In-Reply-To: <1479904606-30647-2-git-send-email-dnlplm@gmail.com>
Finally, I found my modems (or at least a number of them) again today.
But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
giving us a hard time. It does not work with your patch. The symptom is
the same as earlier: The modem returns MBIM frames with 32bit headers.
So for now, I have to NAK this patch.
I am sure we can find a good solution that makes all of these modems
work, but I cannot support a patch that breaks previously working
configurations. Sorry. I'll do a few experiments and see if there is a
simple fix for this. Otherwise we'll probably have to do the quirk
game.
Bjørn
^ permalink raw reply
* [PATCH net-next 6/6] tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch exports the sender chronograph stats via the socket
SO_TIMESTAMPING channel. Currently we can instrument how long a
particular application unit of data was queued in TCP by tracking
SOF_TIMESTAMPING_TX_SOFTWARE and SOF_TIMESTAMPING_TX_SCHED. Having
these sender chronograph stats exported simultaneously along with
these timestamps allow further breaking down the various sender
limitation. For example, a video server can tell if a particular
chunk of video on a connection takes a long time to deliver because
TCP was experiencing small receive window. It is not possible to
tell before this patch without packet traces.
To prepare these stats, the user needs to set
SOF_TIMESTAMPING_OPT_STATS and SOF_TIMESTAMPING_OPT_TSONLY flags
while requesting other SOF_TIMESTAMPING TX timestamps. When the
timestamps are available in the error queue, the stats are returned
in a separate control message of type SCM_TIMESTAMPING_OPT_STATS,
in a list of TLVs (struct nlattr) of types: TCP_NLA_BUSY_TIME,
TCP_NLA_RWND_LIMITED, TCP_NLA_SNDBUF_LIMITED. Unit is microsecond.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
Documentation/networking/timestamping.txt | 10 ++++++++++
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
include/linux/tcp.h | 2 ++
include/uapi/asm-generic/socket.h | 2 ++
include/uapi/linux/net_tstamp.h | 3 ++-
include/uapi/linux/tcp.h | 8 ++++++++
net/core/skbuff.c | 12 +++++++++---
net/core/sock.c | 7 +++++++
net/ipv4/tcp.c | 20 ++++++++++++++++++++
net/socket.c | 7 ++++++-
20 files changed, 88 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 671cccf..96f5069 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -182,6 +182,16 @@ SOF_TIMESTAMPING_OPT_TSONLY:
the timestamp even if sysctl net.core.tstamp_allow_data is 0.
This option disables SOF_TIMESTAMPING_OPT_CMSG.
+SOF_TIMESTAMPING_OPT_STATS:
+
+ Optional stats that are obtained along with the transmit timestamps.
+ It must be used together with SOF_TIMESTAMPING_OPT_TSONLY. When the
+ transmit timestamp is available, the stats are available in a
+ separate control message of type SCM_TIMESTAMPING_OPT_STATS, as a
+ list of TLVs (struct nlattr) of types. These stats allow the
+ application to associate various transport layer stats with
+ the transmit timestamps, such as how long a certain block of
+ data was limited by peer's receiver window.
New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 9e46d6e..afc901b 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index afbc98f0..81e0353 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -90,5 +90,7 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 0018fad..57feb0c 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -99,4 +99,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index 5fe42fc..5853f8e9 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -90,4 +90,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 2027240a..566ecdc 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -108,4 +108,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 5129f23..0e12527 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -90,4 +90,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 9c935d7..7a109b7 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -89,4 +89,6 @@
#define SO_CNX_ADVICE 0x402E
+#define SCM_TIMESTAMPING_OPT_STATS 0x402F
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 1672e33..44583a5 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index 41b51c2..b24a64c 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -96,4 +96,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 31aede3..a25dc32 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -86,6 +86,8 @@
#define SO_CNX_ADVICE 0x0037
+#define SCM_TIMESTAMPING_OPT_STATS 0x0038
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 81435d9..9fdbe1f 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -101,4 +101,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _XTENSA_SOCKET_H */
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index d5d3bd8..00e0ee8 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -428,4 +428,6 @@ static inline void tcp_saved_syn_free(struct tcp_sock *tp)
tp->saved_syn = NULL;
}
+struct sk_buff *tcp_get_timestamping_opt_stats(const struct sock *sk);
+
#endif /* _LINUX_TCP_H */
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 67d632f..2c748dd 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -92,4 +92,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index 264e515..464dcca 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -25,8 +25,9 @@ enum {
SOF_TIMESTAMPING_TX_ACK = (1<<9),
SOF_TIMESTAMPING_OPT_CMSG = (1<<10),
SOF_TIMESTAMPING_OPT_TSONLY = (1<<11),
+ SOF_TIMESTAMPING_OPT_STATS = (1<<12),
- SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_TSONLY,
+ SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_STATS,
SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
SOF_TIMESTAMPING_LAST
};
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index 2863b66..c53de26 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -220,6 +220,14 @@ struct tcp_info {
__u64 tcpi_sndbuf_limited; /* Time (usec) limited by send buffer */
};
+/* netlink attributes types for SCM_TIMESTAMPING_OPT_STATS */
+enum {
+ TCP_NLA_PAD,
+ TCP_NLA_BUSY, /* Time (usec) busy sending data */
+ TCP_NLA_RWND_LIMITED, /* Time (usec) limited by receive window */
+ TCP_NLA_SNDBUF_LIMITED, /* Time (usec) limited by send buffer */
+};
+
/* for TCP_MD5SIG socket option */
#define TCP_MD5SIG_MAXKEYLEN 80
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d1d1a5a..b7986c9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3839,10 +3839,16 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
if (!skb_may_tx_timestamp(sk, tsonly))
return;
- if (tsonly)
- skb = alloc_skb(0, GFP_ATOMIC);
- else
+ if (tsonly) {
+ if ((sk->sk_tsflags & SOF_TIMESTAMPING_OPT_STATS) &&
+ sk->sk_protocol == IPPROTO_TCP &&
+ sk->sk_type == SOCK_STREAM)
+ skb = tcp_get_timestamping_opt_stats(sk);
+ else
+ skb = alloc_skb(0, GFP_ATOMIC);
+ } else {
skb = skb_clone(orig_skb, GFP_ATOMIC);
+ }
if (!skb)
return;
diff --git a/net/core/sock.c b/net/core/sock.c
index 14e6145..d8c7f8c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -854,6 +854,13 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
sk->sk_tskey = 0;
}
}
+
+ if (val & SOF_TIMESTAMPING_OPT_STATS &&
+ !(val & SOF_TIMESTAMPING_OPT_TSONLY)) {
+ ret = -EINVAL;
+ break;
+ }
+
sk->sk_tsflags = val;
if (val & SOF_TIMESTAMPING_RX_SOFTWARE)
sock_enable_timestamp(sk,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index cdde20f..1149b48 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2841,6 +2841,26 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
}
EXPORT_SYMBOL_GPL(tcp_get_info);
+struct sk_buff *tcp_get_timestamping_opt_stats(const struct sock *sk)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff *stats;
+ struct tcp_info info;
+
+ stats = alloc_skb(3 * nla_total_size_64bit(sizeof(u64)), GFP_ATOMIC);
+ if (!stats)
+ return NULL;
+
+ tcp_get_info_chrono_stats(tp, &info);
+ nla_put_u64_64bit(stats, TCP_NLA_BUSY,
+ info.tcpi_busy_time, TCP_NLA_PAD);
+ nla_put_u64_64bit(stats, TCP_NLA_RWND_LIMITED,
+ info.tcpi_rwnd_limited, TCP_NLA_PAD);
+ nla_put_u64_64bit(stats, TCP_NLA_SNDBUF_LIMITED,
+ info.tcpi_sndbuf_limited, TCP_NLA_PAD);
+ return stats;
+}
+
static int do_tcp_getsockopt(struct sock *sk, int level,
int optname, char __user *optval, int __user *optlen)
{
diff --git a/net/socket.c b/net/socket.c
index e2584c5..e631894 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -693,9 +693,14 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
(sk->sk_tsflags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2))
empty = 0;
- if (!empty)
+ if (!empty) {
put_cmsg(msg, SOL_SOCKET,
SCM_TIMESTAMPING, sizeof(tss), &tss);
+
+ if (skb->len && (sk->sk_tsflags & SOF_TIMESTAMPING_OPT_STATS))
+ put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_OPT_STATS,
+ skb->len, skb->data);
+ }
}
EXPORT_SYMBOL_GPL(__sock_recv_timestamp);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 4/6] tcp: instrument how long TCP is limited by insufficient send buffer
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch measures the amount of time when TCP runs out of new data
to send to the network due to insufficient send buffer, while TCP
is still busy delivering (i.e. write queue is not empty). The goal
is to indicate either the send buffer autotuning or user SO_SNDBUF
setting has resulted network under-utilization.
The measurement starts conservatively by checking various conditions
to minimize false claims (i.e. under-estimation is more likely).
The measurement stops when the SOCK_NOSPACE flag is cleared. But it
does not account the time elapsed till the next application write.
Also the measurement only starts if the sender is still busy sending
data, s.t. the limit accounted is part of the total busy time.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp.c | 10 ++++++++--
net/ipv4/tcp_input.c | 5 ++++-
net/ipv4/tcp_output.c | 12 ++++++++++++
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 913f9bb..259ffb5 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -996,8 +996,11 @@ static ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
goto out;
out_err:
/* make sure we wake any epoll edge trigger waiter */
- if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 && err == -EAGAIN))
+ if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 &&
+ err == -EAGAIN)) {
sk->sk_write_space(sk);
+ tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED);
+ }
return sk_stream_error(sk, flags, err);
}
@@ -1331,8 +1334,11 @@ int tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
out_err:
err = sk_stream_error(sk, flags, err);
/* make sure we wake any epoll edge trigger waiter */
- if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 && err == -EAGAIN))
+ if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 &&
+ err == -EAGAIN)) {
sk->sk_write_space(sk);
+ tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED);
+ }
release_sock(sk);
return err;
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a5d1727..56fe736 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5059,8 +5059,11 @@ static void tcp_check_space(struct sock *sk)
/* pairs with tcp_poll() */
smp_mb__after_atomic();
if (sk->sk_socket &&
- test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
+ test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) {
tcp_new_space(sk);
+ if (!test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
+ tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED);
+ }
}
}
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index b74444c..d3545d0 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1514,6 +1514,18 @@ static void tcp_cwnd_validate(struct sock *sk, bool is_cwnd_limited)
if (sysctl_tcp_slow_start_after_idle &&
(s32)(tcp_time_stamp - tp->snd_cwnd_stamp) >= inet_csk(sk)->icsk_rto)
tcp_cwnd_application_limited(sk);
+
+ /* The following conditions together indicate the starvation
+ * is caused by insufficient sender buffer:
+ * 1) just sent some data (see tcp_write_xmit)
+ * 2) not cwnd limited (this else condition)
+ * 3) no more data to send (null tcp_send_head )
+ * 4) application is hitting buffer limit (SOCK_NOSPACE)
+ */
+ if (!tcp_send_head(sk) && sk->sk_socket &&
+ test_bit(SOCK_NOSPACE, &sk->sk_socket->flags) &&
+ (1 << sk->sk_state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT))
+ tcp_chrono_start(sk, TCP_CHRONO_SNDBUF_LIMITED);
}
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 5/6] tcp: export sender limits chronographs to TCP_INFO
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch exports all the sender chronograph measurements collected
in the previous patches to TCP_INFO interface. Note that busy time
exported includes all the other sending limits (rwnd-limited,
sndbuf-limited). Internally the time unit is jiffy but externally
the measurements are in microseconds for future extensions.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/uapi/linux/tcp.h | 4 ++++
net/ipv4/tcp.c | 20 ++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index 73ac0db..2863b66 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -214,6 +214,10 @@ struct tcp_info {
__u32 tcpi_data_segs_out; /* RFC4898 tcpEStatsDataSegsOut */
__u64 tcpi_delivery_rate;
+
+ __u64 tcpi_busy_time; /* Time (usec) busy sending data */
+ __u64 tcpi_rwnd_limited; /* Time (usec) limited by receive window */
+ __u64 tcpi_sndbuf_limited; /* Time (usec) limited by send buffer */
};
/* for TCP_MD5SIG socket option */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 259ffb5..cdde20f 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2708,6 +2708,25 @@ int compat_tcp_setsockopt(struct sock *sk, int level, int optname,
EXPORT_SYMBOL(compat_tcp_setsockopt);
#endif
+static void tcp_get_info_chrono_stats(const struct tcp_sock *tp,
+ struct tcp_info *info)
+{
+ u64 stats[__TCP_CHRONO_MAX], total = 0;
+ enum tcp_chrono i;
+
+ for (i = TCP_CHRONO_BUSY; i < __TCP_CHRONO_MAX; ++i) {
+ stats[i] = tp->chrono_stat[i - 1];
+ if (i == tp->chrono_type)
+ stats[i] += tcp_time_stamp - tp->chrono_start;
+ stats[i] *= USEC_PER_SEC / HZ;
+ total += stats[i];
+ }
+
+ info->tcpi_busy_time = total;
+ info->tcpi_rwnd_limited = stats[TCP_CHRONO_RWND_LIMITED];
+ info->tcpi_sndbuf_limited = stats[TCP_CHRONO_SNDBUF_LIMITED];
+}
+
/* Return information about state of tcp endpoint in API format. */
void tcp_get_info(struct sock *sk, struct tcp_info *info)
{
@@ -2800,6 +2819,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_bytes_acked = tp->bytes_acked;
info->tcpi_bytes_received = tp->bytes_received;
info->tcpi_notsent_bytes = max_t(int, 0, tp->write_seq - tp->snd_nxt);
+ tcp_get_info_chrono_stats(tp, info);
unlock_sock_fast(sk, slow);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 2/6] tcp: instrument how long TCP is busy sending
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch measures TCP busy time, which is defined as the period
of time when sender has data (or FIN) to send. The time starts when
data is buffered and stops when the write queue is flushed by ACKs
or error events.
Note the busy time does not include SYN time, unless data is
included in SYN (i.e. Fast Open). It does include FIN time even
if the FIN carries no payload. Excluding pure FIN is possible but
would incur one additional test in the fast path, which may not
be worth it.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/net/tcp.h | 6 +++++-
net/ipv4/tcp_input.c | 3 +++
net/ipv4/tcp_output.c | 19 ++++++++++++++++---
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e5ff408..3e097e3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1535,6 +1535,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
{
struct sk_buff *skb;
+ tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
sk_wmem_free_skb(sk, skb);
sk_mem_reclaim(sk);
@@ -1593,8 +1594,10 @@ static inline void tcp_advance_send_head(struct sock *sk, const struct sk_buff *
static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unlinked)
{
- if (sk->sk_send_head == skb_unlinked)
+ if (sk->sk_send_head == skb_unlinked) {
sk->sk_send_head = NULL;
+ tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
+ }
if (tcp_sk(sk)->highest_sack == skb_unlinked)
tcp_sk(sk)->highest_sack = NULL;
}
@@ -1616,6 +1619,7 @@ static inline void tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb
/* Queue it, remembering where we must start sending. */
if (sk->sk_send_head == NULL) {
sk->sk_send_head = skb;
+ tcp_chrono_start(sk, TCP_CHRONO_BUSY);
if (tcp_sk(sk)->highest_sack == NULL)
tcp_sk(sk)->highest_sack = skb;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 22e6a20..a5d1727 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3178,6 +3178,9 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
tp->lost_skb_hint = NULL;
}
+ if (!skb)
+ tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
+
if (likely(between(tp->snd_up, prior_snd_una, tp->snd_una)))
tp->snd_up = tp->snd_una;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 34f7517..e8ea584 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2096,8 +2096,8 @@ void tcp_chrono_start(struct sock *sk, const enum tcp_chrono type)
struct tcp_sock *tp = tcp_sk(sk);
/* If there are multiple conditions worthy of tracking in a
- * chronograph then the highest priority enum takes precedence over
- * the other conditions. So that if something "more interesting"
+ * chronograph then the highest priority enum takes precedence
+ * over the other conditions. So that if something "more interesting"
* starts happening, stop the previous chrono and start a new one.
*/
if (type > tp->chrono_type)
@@ -2108,7 +2108,18 @@ void tcp_chrono_stop(struct sock *sk, const enum tcp_chrono type)
{
struct tcp_sock *tp = tcp_sk(sk);
- tcp_chrono_set(tp, TCP_CHRONO_UNSPEC);
+
+ /* There are multiple conditions worthy of tracking in a
+ * chronograph, so that the highest priority enum takes
+ * precedence over the other conditions (see tcp_chrono_start).
+ * If a condition stops, we only stop chrono tracking if
+ * it's the "most interesting" or current chrono we are
+ * tracking and starts busy chrono if we have pending data.
+ */
+ if (tcp_write_queue_empty(sk))
+ tcp_chrono_set(tp, TCP_CHRONO_UNSPEC);
+ else if (type == tp->chrono_type)
+ tcp_chrono_set(tp, TCP_CHRONO_BUSY);
}
/* This routine writes packets to the network. It advances the
@@ -3328,6 +3339,8 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
fo->copied = space;
tcp_connect_queue_skb(sk, syn_data);
+ if (syn_data->len)
+ tcp_chrono_start(sk, TCP_CHRONO_BUSY);
err = tcp_transmit_skb(sk, syn_data, 1, sk->sk_allocation);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 3/6] tcp: instrument how long TCP is limited by receive window
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch measures the total time when the TCP stops sending because
the receiver's advertised window is not large enough. Note that
once the limit is lifted we are likely in the busy status if we
have data pending.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e8ea584..b74444c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2144,7 +2144,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
unsigned int tso_segs, sent_pkts;
int cwnd_quota;
int result;
- bool is_cwnd_limited = false;
+ bool is_cwnd_limited = false, is_rwnd_limited = false;
u32 max_segs;
sent_pkts = 0;
@@ -2181,8 +2181,10 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
break;
}
- if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now)))
+ if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now))) {
+ is_rwnd_limited = true;
break;
+ }
if (tso_segs == 1) {
if (unlikely(!tcp_nagle_test(tp, skb, mss_now,
@@ -2227,6 +2229,11 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
break;
}
+ if (is_rwnd_limited)
+ tcp_chrono_start(sk, TCP_CHRONO_RWND_LIMITED);
+ else
+ tcp_chrono_stop(sk, TCP_CHRONO_RWND_LIMITED);
+
if (likely(sent_pkts)) {
if (tcp_in_cwnd_reduction(sk))
tp->prr_out += sent_pkts;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 1/6] tcp: instrument tcp sender limits chronographs
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch implements the skeleton of the TCP chronograph
instrumentation on sender side limits:
1) idle (unspec)
2) busy sending data other than 3-4 below
3) rwnd-limited
4) sndbuf-limited
The limits are enumerated 'tcp_chrono'. Since a connection in
theory can idle forever, we do not track the actual length of this
uninteresting idle period. For the rest we track how long the sender
spends in each limit. At any point during the life time of a
connection, the sender must be in one of the four states.
If there are multiple conditions worthy of tracking in a chronograph
then the highest priority enum takes precedence over
the other conditions. So that if something "more interesting"
starts happening, stop the previous chrono and start a new one.
The time unit is jiffy(u32) in order to save space in tcp_sock.
This implies application must sample the stats no longer than every
49 days of 1ms jiffy.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/linux/tcp.h | 7 +++++--
include/net/tcp.h | 14 ++++++++++++++
net/ipv4/tcp_output.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 32a7c7e..d5d3bd8 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -211,8 +211,11 @@ struct tcp_sock {
u8 reord; /* reordering detected */
} rack;
u16 advmss; /* Advertised MSS */
- u8 rate_app_limited:1, /* rate_{delivered,interval_us} limited? */
- unused:7;
+ u32 chrono_start; /* Start time in jiffies of a TCP chrono */
+ u32 chrono_stat[3]; /* Time in jiffies for chrono_stat stats */
+ u8 chrono_type:2, /* current chronograph type */
+ rate_app_limited:1, /* rate_{delivered,interval_us} limited? */
+ unused:5;
u8 nonagle : 4,/* Disable Nagle algorithm? */
thin_lto : 1,/* Use linear timeouts for thin streams */
thin_dupack : 1,/* Fast retransmit on first dupack */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 7de8073..e5ff408 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1516,6 +1516,20 @@ struct tcp_fastopen_context {
struct rcu_head rcu;
};
+/* Latencies incurred by various limits for a sender. They are
+ * chronograph-like stats that are mutually exclusive.
+ */
+enum tcp_chrono {
+ TCP_CHRONO_UNSPEC,
+ TCP_CHRONO_BUSY, /* Actively sending data (non-empty write queue) */
+ TCP_CHRONO_RWND_LIMITED, /* Stalled by insufficient receive window */
+ TCP_CHRONO_SNDBUF_LIMITED, /* Stalled by insufficient send buffer */
+ __TCP_CHRONO_MAX,
+};
+
+void tcp_chrono_start(struct sock *sk, const enum tcp_chrono type);
+void tcp_chrono_stop(struct sock *sk, const enum tcp_chrono type);
+
/* write queue abstraction */
static inline void tcp_write_queue_purge(struct sock *sk)
{
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 19105b4..34f7517 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2081,6 +2081,36 @@ static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
return false;
}
+static void tcp_chrono_set(struct tcp_sock *tp, const enum tcp_chrono new)
+{
+ const u32 now = tcp_time_stamp;
+
+ if (tp->chrono_type > TCP_CHRONO_UNSPEC)
+ tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
+ tp->chrono_start = now;
+ tp->chrono_type = new;
+}
+
+void tcp_chrono_start(struct sock *sk, const enum tcp_chrono type)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ /* If there are multiple conditions worthy of tracking in a
+ * chronograph then the highest priority enum takes precedence over
+ * the other conditions. So that if something "more interesting"
+ * starts happening, stop the previous chrono and start a new one.
+ */
+ if (type > tp->chrono_type)
+ tcp_chrono_set(tp, type);
+}
+
+void tcp_chrono_stop(struct sock *sk, const enum tcp_chrono type)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ tcp_chrono_set(tp, TCP_CHRONO_UNSPEC);
+}
+
/* This routine writes packets to the network. It advances the
* send_head. This happens as incoming acks open up the remote
* window for us.
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 0/6] tcp: sender chronographs instrumentation
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
This patch set provides instrumentation on TCP sender limitations.
While developing the BBR congestion control, we noticed that TCP
sending process is often limited by factors unrelated to congestion
control: insufficient sender buffer and/or insufficient receive
window/buffer to saturate the network bandwidth. Unfortunately these
limits are not visible to the users and often the poor performance
is attributed to the congestion control of choice.
Thie patch aims to help users get the high level understanding of
where sending process is limited by, similar to the TCP_INFO design.
It is not to replace detailed kernel tracing and instrumentation
facilities.
In addition this patch set provides a new option to the timestamping
work to instrument these limits on application data unit. For exampe,
one can use SO_TIMESTAMPING and this patch set to measure the how
long a particular HTTP response is limited by small receive window.
Patch set was initially written by Francis Yan then polished
by Yuchung Cheng, with lots of help from Eric Dumazet and Soheil
Hassas Yeganeh.
Francis Yan (6):
tcp: instrument tcp sender limits chronographs
tcp: instrument how long TCP is busy sending
tcp: instrument how long TCP is limited by receive window
tcp: instrument how long TCP is limited by insufficient send buffer
tcp: export sender limits chronographs to TCP_INFO
tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING
Documentation/networking/timestamping.txt | 10 +++++
arch/alpha/include/uapi/asm/socket.h | 2 +
arch/frv/include/uapi/asm/socket.h | 2 +
arch/ia64/include/uapi/asm/socket.h | 2 +
arch/m32r/include/uapi/asm/socket.h | 2 +
arch/mips/include/uapi/asm/socket.h | 2 +
arch/mn10300/include/uapi/asm/socket.h | 2 +
arch/parisc/include/uapi/asm/socket.h | 2 +
arch/powerpc/include/uapi/asm/socket.h | 2 +
arch/s390/include/uapi/asm/socket.h | 2 +
arch/sparc/include/uapi/asm/socket.h | 2 +
arch/xtensa/include/uapi/asm/socket.h | 2 +
include/linux/tcp.h | 9 ++++-
include/net/tcp.h | 20 +++++++++-
include/uapi/asm-generic/socket.h | 2 +
include/uapi/linux/net_tstamp.h | 3 +-
include/uapi/linux/tcp.h | 12 ++++++
net/core/skbuff.c | 12 ++++--
net/core/sock.c | 7 ++++
net/ipv4/tcp.c | 50 ++++++++++++++++++++++-
net/ipv4/tcp_input.c | 8 +++-
net/ipv4/tcp_output.c | 66 ++++++++++++++++++++++++++++++-
net/socket.c | 7 +++-
23 files changed, 215 insertions(+), 13 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: net: GPF in eth_header
From: Eric Dumazet @ 2016-11-26 20:05 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzkaller, Dmitry Vyukov, David Miller, Tom Herbert,
Alexander Duyck, Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca,
netdev, LKML
In-Reply-To: <CAAeHK+x48aKLcKfN2aYA1pBPr4Y4ESUvjCTu0xGPoYZuiRbaaw@mail.gmail.com>
> Hi Eric,
>
> The crash happens when the kernel tries to access shadow for nonmapped memory.
>
> The issue here is an integer overflow which happens in neigh_resolve_output().
> skb_network_offset(skb) can return negative number, but __skb_pull()
> accepts unsigned int as len.
> As a result, the least significat bit in higher 32 bits of skb->data
> gets set and we get an out-of-bounds with offset of 4 GB.
>
> I've attached a short reproducer, but you either need KASAN or to add
> a BUG_ON to see the crash.
> In this reproducer skb_network_offset() becomes negative after merging
> two ipv6 fragments.
>
> I actually see multiple places where skb_network_offset() is used as
> an argument to skb_pull().
> So I guess every place can potentially be buggy.
Well, I think the intent is to accept a negative number.
This definitely was assumed by commit e1f165032c8bade authors !
I guess they were using a 32bit kernel for their tests.
^ permalink raw reply
* unsuscribe
From: seba @ 2016-11-26 19:55 UTC (permalink / raw)
To: netdev
unsuscribe
^ permalink raw reply
* Re: net: GPF in eth_header
From: Andrey Konovalov @ 2016-11-26 19:07 UTC (permalink / raw)
To: syzkaller
Cc: Dmitry Vyukov, David Miller, Tom Herbert, Alexander Duyck,
Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca, netdev, LKML
In-Reply-To: <CANn89iJeWV9YnOzy4eXL4Sbcyw_kj_CA8JrfGaFxMse_MUFL6Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5343 bytes --]
On Sat, Nov 26, 2016 at 7:28 PM, 'Eric Dumazet' via syzkaller
<syzkaller@googlegroups.com> wrote:
> On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> Hello,
>>
>> The following program triggers GPF in eth_header:
>>
>> https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
>>
>> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>
>> BUG: unable to handle kernel paging request at ffffed002d14d74a
>> IP: [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
>> PGD 7fff6067 [ 50.787819] PUD 7fff5067
>> PMD 0 [ 50.787819]
>> Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>> Modules linked in:
>> CPU: 2 PID: 6712 Comm: a.out Not tainted 4.9.0-rc6+ #55
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff88003a1841c0 task.stack: ffff880034d08000
>> RIP: 0010:[<ffffffff86be3295>] [<ffffffff86be3295>]
>> eth_header+0x75/0x260 net/ethernet/eth.c:88
>> RSP: 0018:ffff880034d0eb68 EFLAGS: 00010a03
>> RAX: 1ffff1002d14d74a RBX: ffff880168a6ba4a RCX: ffff88006a9c7858
>> RDX: 000000000000dd86 RSI: dffffc0000000000 RDI: ffff880168a6ba56
>> RBP: ffff880034d0eb98 R08: 0000000000000000 R09: 0000000000000031
>> R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
>> R13: ffff88006c208d80 R14: 00000000000086dd R15: ffff88006a9c7858
>> FS: 0000000001a02940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: ffffed002d14d74a CR3: 0000000037373000 CR4: 00000000000006e0
>> Stack:
>> 000000316881ab40 ffff88006a9c76c0 ffff88006881ab40 ffff88006a9c77f8
>> 0000000000000000 dffffc0000000000 ffff880034d0ee98 ffffffff86b31af9
>> ffffffff8719605c ffff880034d0f0f8 ffffffff000086dd ffffffff86be3220
>> Call Trace:
>> [< inline >] dev_hard_header ./include/linux/netdevice.h:2762
>> [<ffffffff86b31af9>] neigh_resolve_output+0x659/0xb20 net/core/neighbour.c:1302
>> [< inline >] dst_neigh_output ./include/net/dst.h:464
>> [<ffffffff8719605c>] ip6_finish_output2+0xb3c/0x2500 net/ipv6/ip6_output.c:121
>> [<ffffffff871a0b0b>] ip6_finish_output+0x2eb/0x760 net/ipv6/ip6_output.c:139
>> [< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
>> [<ffffffff871a1157>] ip6_output+0x1d7/0x9a0 net/ipv6/ip6_output.c:153
>> [< inline >] dst_output ./include/net/dst.h:501
>> [<ffffffff873312ea>] ip6_local_out+0x9a/0x180 net/ipv6/output_core.c:170
>> [<ffffffff871a3886>] ip6_send_skb+0xa6/0x340 net/ipv6/ip6_output.c:1712
>> [<ffffffff871a3bd8>] ip6_push_pending_frames+0xb8/0xe0
>> net/ipv6/ip6_output.c:1732
>> [< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
>> [<ffffffff8722acfb>] rawv6_sendmsg+0x250b/0x2c20 net/ipv6/raw.c:920
>> [<ffffffff8701c4f5>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
>> [< inline >] sock_sendmsg_nosec net/socket.c:621
>> [<ffffffff86a6ea9f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
>> [<ffffffff86a6ee0b>] sock_write_iter+0x32b/0x620 net/socket.c:829
>> [<ffffffff81a6f153>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
>> [<ffffffff81a71ba1>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
>> [<ffffffff81a726dc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
>> [<ffffffff81a72825>] do_writev+0x115/0x2d0 fs/read_write.c:944
>> [< inline >] SYSC_writev fs/read_write.c:1017
>> [<ffffffff81a75fdc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
>> [<ffffffff8814cf85>] entry_SYSCALL_64_fastpath+0x23/0xc6
>> arch/x86/entry/entry_64.S:209
>> Code: 41 83 fe 04 0f 84 aa 00 00 00 e8 17 4e b0 fa 48 8d 7b 0c 48 be
>> 00 00 00 00 00 fc ff df 44 89 f2 66 c1 c2 08 48 89 f8 48 c1 e8 03 <0f>
>> b6 0c 30 48 8d 43 0d 49 89 c0 49 c1 e8 03 41 0f b6 34 30 49
>> RIP [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
>> RSP <ffff880034d0eb68>
>> CR2: ffffed002d14d74a
>> ---[ end trace a73fedfdc11bd60c ]---
>
>
> Hi Dmitry
>
> I could not reproduce the issue. Might need some specific configuration...
>
> loopback device has proper ethernet header (all 0)
>
> Fault happens in :
>
> 0f b6 0c 30 movzbl (%rax,%rsi,1),%ecx
>
> RAX=1ffff1002d14d74a which is RDI>>3, and RSI=dffffc0000000000
>
> Could this be a KASAN problem ?
Hi Eric,
The crash happens when the kernel tries to access shadow for nonmapped memory.
The issue here is an integer overflow which happens in neigh_resolve_output().
skb_network_offset(skb) can return negative number, but __skb_pull()
accepts unsigned int as len.
As a result, the least significat bit in higher 32 bits of skb->data
gets set and we get an out-of-bounds with offset of 4 GB.
I've attached a short reproducer, but you either need KASAN or to add
a BUG_ON to see the crash.
In this reproducer skb_network_offset() becomes negative after merging
two ipv6 fragments.
I actually see multiple places where skb_network_offset() is used as
an argument to skb_pull().
So I guess every place can potentially be buggy.
Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: ipv6-poc1.c --]
[-- Type: application/octet-stream, Size: 1020 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
int main()
{
mmap(0x20000000ul, 0x28000ul, 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul);
long sock = socket(0xaul, 0x3ul, 0x2cul);
struct sockaddr_in6 addr;
memset(&addr, 0, sizeof(addr));
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(0x4242);
addr.sin6_addr = in6addr_loopback;
// addr.sin6_addr.s6_addr[1] = 42;
connect(sock, (const struct sockaddr *)&addr, sizeof(addr));
memcpy((void*)0x20025000,
"\x06\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
72);
sendto(sock, (const void *)0x20025000ul, 0x48ul, 0x4ul, 0x0ul, 0x0ul);
sendto(sock, (const void *)0x20025000ul, 0x48ul, 0x4ul, 0x0ul, 0x0ul);
return 0;
}
^ permalink raw reply
* Re: net: stmmac: Meson GXBB: attempting to execute userspace memory
From: Ben Dooks @ 2016-11-26 18:57 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Alexandre Torgue, Kevin Hilman, Giuseppe Cavallaro, lkml, netdev,
Carlo Caione, linux-amlogic, linux-arm-kernel
In-Reply-To: <c8280798-453e-bd1d-bd4d-bf0956a169cc@gmx.de>
On 2016-11-26 07:53, Heinrich Schuchardt wrote:
> For Odroid C2 I have compiled kernel
> 4.9.0-rc6-next-20161124-00001-gbf7e142
> with one additional patch
> https://github.com/xypron/kernel-odroid-c2/blob/master/patch/0001-stmmac-RTL8211F-Meson-GXBB-TX-throughput-problems.patch
>
> I repeatedly see faults like the one below:
>
> [ 2557.400796] Unhandled fault: synchronous external abort (0x92000010)
> at 0x000040001e8ee4b0
> [ 2557.952413] CPU: 0 PID: 22837 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2557.962062] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2557.966980] task: ffff80006ddb7080 task.stack: ffff80006dd9c000
> [ 2557.972846] PC is at 0x6a0d98
> [ 2557.975776] LR is at 0x6a0e54
> [ 2557.978709] pc : [<00000000006a0d98>] lr : [<00000000006a0e54>]
> pstate: 80000000
> [ 2557.986040] sp : 0000fffff3ee5f80
> [ 2557.989318] x29: 0000fffff3ee5f80 x28: 000040000b3f1240
> [ 2557.994578] x27: 00000000012a7000 x26: 000040000b3f1288
> [ 2557.999840] x25: 0000000000f58f88 x24: 000040000b3f1240
> [ 2558.005101] x23: 0000000000000000 x22: 0000000000000001
> [ 2558.010362] x21: 0000000000000001 x20: 000040000b3f1250
> [ 2558.015623] x19: 0000000000000054 x18: 0000000000000001
> [ 2558.020885] x17: 0000400008acaa10 x16: 0000000001285050
> [ 2558.026146] x15: 000040000ad96dc8 x14: 000000000000001f
> [ 2558.031407] x13: 000040000b3f1270 x12: 000040000b3f1258
> [ 2558.036668] x11: 0000000001347000 x10: 0000000000000661
> [ 2558.041930] x9 : 0000000000000005 x8 : 0000000000000003
> [ 2558.047191] x7 : 000040000b3f1240 x6 : 0000000020020033
> [ 2558.052452] x5 : 000040000b402020 x4 : 000040000b3e1aa0
> [ 2558.057713] x3 : 000000000000000c x2 : 0000000000000020
> [ 2558.062974] x1 : 0000000000f45000 x0 : 0000000000000065
> [ 2558.068235]
> [ 2558.069712] Internal error: Attempting to execute userspace memory:
> 8600000f [#7] PREEMPT SMP
> [ 2558.078155] Modules linked in: meson_rng rng_core meson_gxbb_wdt
> ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
> stmmac_platform stmmac
> [ 2558.091267] CPU: 0 PID: 22837 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2558.100925] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2558.105841] task: ffff80006ddb7080 task.stack: ffff80006dd9c000
> [ 2558.111706] PC is at 0x6a0e54
> [ 2558.114638] LR is at 0x6a0e54
> [ 2558.117571] pc : [<00000000006a0e54>] lr : [<00000000006a0e54>]
> pstate: 600003c5
> [ 2558.124902] sp : ffff80006dd9fec0
> [ 2558.128179] x29: 0000000000000000 x28: ffff80006ddb7080
> [ 2558.133441] x27: 00000000012a7000 x26: 000040000b3f1288
> [ 2558.138702] x25: 0000000000f58f88 x24: 000040000b3f1240
> [ 2558.143963] x23: 0000000080000000 x22: 00000000006a0d98
> [ 2558.149225] x21: ffffffffffffffff x20: 000080006e223000
> [ 2558.154486] x19: 0000000000000000 x18: 0000000000000010
> [ 2558.159747] x17: 0000400008acaa10 x16: 0000000001285050
> [ 2558.165008] x15: ffff000088e91f07 x14: 0000000000000006
> [ 2558.170270] x13: ffff000008e91f15 x12: 000000000000000f
> [ 2558.175531] x11: 0000000000000002 x10: 00000000000002ea
> [ 2558.180792] x9 : ffff80006dd9fb40 x8 : 0000000000010a8b
> [ 2558.186053] x7 : 0000000000000000 x6 : 000000000000020e
> [ 2558.191315] x5 : 00000000020f020e x4 : 0000000000000000
> [ 2558.196576] x3 : 0000000000000000 x2 : 000000000000020f
> [ 2558.201837] x1 : ffff80006ddb7080 x0 : 0000000000000000
> [ 2558.207098]
> [ 2558.208565] Process cc1 (pid: 22837, stack limit =
> 0xffff80006dd9c000)
> [ 2558.215035] Stack: (0xffff80006dd9fec0 to 0xffff80006dda0000)
> [ 2558.220728] fec0: 0000000000000065 0000000000f45000 0000000000000020
> 000000000000000c
> [ 2558.228490] fee0: 000040000b3e1aa0 000040000b402020 0000000020020033
> 000040000b3f1240
> [ 2558.236253] ff00: 0000000000000003 0000000000000005 0000000000000661
> 0000000001347000
> [ 2558.244015] ff20: 000040000b3f1258 000040000b3f1270 000000000000001f
> 000040000ad96dc8
> [ 2558.251778] ff40: 0000000001285050 0000400008acaa10 0000000000000001
> 0000000000000054
> [ 2558.259540] ff60: 000040000b3f1250 0000000000000001 0000000000000001
> 0000000000000000
> [ 2558.267303] ff80: 000040000b3f1240 0000000000f58f88 000040000b3f1288
> 00000000012a7000
> [ 2558.275065] ffa0: 000040000b3f1240 0000fffff3ee5f80 00000000006a0e54
> 0000fffff3ee5f80
> [ 2558.282828] ffc0: 00000000006a0d98 0000000080000000 0000000000000003
> ffffffffffffffff
> [ 2558.290590] ffe0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2558.298351] Call trace:
> [ 2558.300769] Exception stack(0xffff80006dd9fcf0 to
> 0xffff80006dd9fe20)
> [ 2558.307149] fce0: 0000000000000000
> 0001000000000000
> [ 2558.314913] fd00: ffff80006dd9fec0 00000000006a0e54 ffff800073acf500
> 0000000000000004
> [ 2558.322675] fd20: 0000000000000000 ffff000008dbbc18 ffff80006ddb7080
> 000000006dd9fdd0
> [ 2558.330438] fd40: ffff80006dd9fd90 ffff0000080ca878 ffff80006dd9fe40
> ffff80006ddb7080
> [ 2558.338200] fd60: 0000000000000004 00000000000003c0 ffff80006dd9fe40
> 000040000b3f1240
> [ 2558.345963] fd80: 0000000000f58f88 000040000b3f1288 0000000000000000
> ffff80006ddb7080
> [ 2558.353725] fda0: 000000000000020f 0000000000000000 0000000000000000
> 00000000020f020e
> [ 2558.361487] fdc0: 000000000000020e 0000000000000000 0000000000010a8b
> ffff80006dd9fb40
> [ 2558.369250] fde0: 00000000000002ea 0000000000000002 000000000000000f
> ffff000008e91f15
> [ 2558.377012] fe00: 0000000000000006 ffff000088e91f07 0000000001285050
> 0000400008acaa10
> [ 2558.384775] [<00000000006a0e54>] 0x6a0e54
> [ 2558.388743] Code: d503201f f9400280 2a1703e1 97ffff0a (aa0003f3)
> [ 2558.395241] ---[ end trace 7d280955c14d4ff1 ]---
> [ 2558.584022] Bad mode in Error handler detected on CPU0, code
> 0xbf000000 -- SError
> [ 2558.585871] CPU: 0 PID: 22867 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2558.595527] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2558.600444] task: ffff80007454d780 task.stack: ffff8000660bc000
> [ 2558.606310] PC is at 0x631928
> [ 2558.609240] LR is at 0xb59ce0
> [ 2558.612172] pc : [<0000000000631928>] lr : [<0000000000b59ce0>]
> pstate: 80000000
> [ 2558.619503] sp : 0000ffffed764d90
> [ 2558.622782] x29: 0000ffffed764d90 x28: 0000000000000028
> [ 2558.628042] x27: 000000001a1062f0 x26: 0000000001299198
> [ 2558.633303] x25: 0000000000000001 x24: 0000000000000000
> [ 2558.638564] x23: 0000000000000004 x22: 00000000013513c8
> [ 2558.643825] x21: 0000400039d43488 x20: 0000000000000000
> [ 2558.649086] x19: 0000400039d2d730 x18: 0000000000000000
> [ 2558.654348] x17: 0000400039a7c378 x16: 0000000001285138
> [ 2558.659609] x15: 0000000000000001 x14: 0000000000000000
> [ 2558.664870] x13: ffffff0000000000 x12: 0000000000000000
> [ 2558.670131] x11: 0000000000000028 x10: 000000000129b2b8
> [ 2558.675393] x9 : 0000000000000041 x8 : 0000000000000003
> [ 2558.680654] x7 : 0000000000000050 x6 : 000000000003d2c8
> [ 2558.685915] x5 : 0000000000000002 x4 : 0000000000000004
> [ 2558.691176] x3 : 0000000000000003 x2 : 0000000001349000
> [ 2558.696438] x1 : 000000000003cb90 x0 : 0000400039d45050
> [ 2558.701699]
> [ 2558.703177] Internal error: Attempting to execute userspace memory:
> 8600000f [#8] PREEMPT SMP
> [ 2558.711618] Modules linked in: meson_rng rng_core meson_gxbb_wdt
> ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
> stmmac_platform stmmac
> [ 2558.724731] CPU: 0 PID: 22867 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2558.734388] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2558.739304] task: ffff80007454d780 task.stack: ffff8000660bc000
> [ 2558.745169] PC is at 0xb59ce0
> [ 2558.748102] LR is at 0xb59ce0
> [ 2558.751035] pc : [<0000000000b59ce0>] lr : [<0000000000b59ce0>]
> pstate: 600003c5
> [ 2558.758365] sp : ffff8000660bfec0
> [ 2558.761643] x29: 0000000000000000 x28: ffff80007454d780
> [ 2558.766904] x27: 000000001a1062f0 x26: 0000000001299198
> [ 2558.772165] x25: 0000000000000001 x24: 0000000000000000
> [ 2558.777426] x23: 0000000080000000 x22: 0000000000631928
> [ 2558.782688] x21: ffffffffffffffff x20: 000080006e223000
> [ 2558.787949] x19: 0000000000000000 x18: 0000000000000010
> [ 2558.793210] x17: 0000400039a7c378 x16: 0000000001285138
> [ 2558.798471] x15: ffff000088e91f07 x14: 0000000000000006
> [ 2558.803733] x13: ffff000008e91f15 x12: 000000000000000f
> [ 2558.808994] x11: 0000000000000002 x10: 0000000000000336
> [ 2558.814255] x9 : ffff8000660bfb40 x8 : 00000000000ab503
> [ 2558.819516] x7 : 0000000000000000 x6 : 00000000000000dd
> [ 2558.824778] x5 : 0000000000de00dd x4 : 0000000000000000
> [ 2558.830039] x3 : 0000000000000000 x2 : 00000000000000de
> [ 2558.835300] x1 : ffff80007454d780 x0 : 0000000000000000
> [ 2558.840561]
> [ 2558.842029] Process cc1 (pid: 22867, stack limit =
> 0xffff8000660bc000)
> [ 2558.848498] Stack: (0xffff8000660bfec0 to 0xffff8000660c0000)
> [ 2558.854191] fec0: 0000400039d45050 000000000003cb90 0000000001349000
> 0000000000000003
> [ 2558.861953] fee0: 0000000000000004 0000000000000002 000000000003d2c8
> 0000000000000050
> [ 2558.869716] ff00: 0000000000000003 0000000000000041 000000000129b2b8
> 0000000000000028
> [ 2558.877478] ff20: 0000000000000000 ffffff0000000000 0000000000000000
> 0000000000000001
> [ 2558.885241] ff40: 0000000001285138 0000400039a7c378 0000000000000000
> 0000400039d2d730
> [ 2558.893003] ff60: 0000000000000000 0000400039d43488 00000000013513c8
> 0000000000000004
> [ 2558.900766] ff80: 0000000000000000 0000000000000001 0000000001299198
> 000000001a1062f0
> [ 2558.908529] ffa0: 0000000000000028 0000ffffed764d90 0000000000b59ce0
> 0000ffffed764d90
> [ 2558.916291] ffc0: 0000000000631928 0000000080000000 000000001a18c000
> ffffffffffffffff
> [ 2558.924053] ffe0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2558.931814] Call trace:
> [ 2558.934232] Exception stack(0xffff8000660bfcf0 to
> 0xffff8000660bfe20)
> [ 2558.940613] fce0: 0000000000000000
> 0001000000000000
> [ 2558.948376] fd00: ffff8000660bfec0 0000000000b59ce0 ffff800073acf640
> 0000000000000004
> [ 2558.956138] fd20: 0000000000000000 ffff000008dbbc18 ffff80007454d780
> 00000000660bfdd0
> [ 2558.963901] fd40: ffff8000660bfd90 ffff0000080ca878 ffff8000660bfe40
> ffff80007454d780
> [ 2558.971663] fd60: 0000000000000004 00000000000003c0 ffff8000660bfe40
> 0000000000000000
> [ 2558.979426] fd80: 0000000000000001 0000000001299198 0000000000000000
> ffff80007454d780
> [ 2558.987188] fda0: 00000000000000de 0000000000000000 0000000000000000
> 0000000000de00dd
> [ 2558.994951] fdc0: 00000000000000dd 0000000000000000 00000000000ab503
> ffff8000660bfb40
> [ 2559.002713] fde0: 0000000000000336 0000000000000002 000000000000000f
> ffff000008e91f15
> [ 2559.010476] fe00: 0000000000000006 ffff000088e91f07 0000000001285138
> 0000400039a7c378
> [ 2559.018238] [<0000000000b59ce0>] 0xb59ce0
> [ 2559.022207] Code: d2800001 d2800002 d2800500 97eb5e9d (a9007c1f)
> [ 2559.028376] ---[ end trace 7d280955c14d4ff2 ]---
> [ 2559.034397] Bad mode in Error handler detected on CPU2, code
> 0xbf000000 -- SError
> [ 2559.040235] CPU: 2 PID: 22866 Comm: gcc Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2559.049892] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2559.054808] task: ffff80007454e400 task.stack: ffff80006de9c000
> [ 2559.060674] PC is at 0x40003c0400d8
> [ 2559.064122] LR is at 0x46d4e0
> [ 2559.067055] pc : [<000040003c0400d8>] lr : [<000000000046d4e0>]
> pstate: 80000000
> [ 2559.074385] sp : 0000ffffe6387270
> [ 2559.077664] x29: 0000ffffe6387270 x28: 0000000016c0ff90
> [ 2559.082924] x27: 0000000000000002 x26: 0000000000000001
> [ 2559.088185] x25: 0000ffffe63873f4 x24: 0000ffffe63873f8
> [ 2559.093447] x23: 0000ffffe63873f4 x22: 0000ffffe63873f8
> [ 2559.098708] x21: 0000000016c104e0 x20: 0000000000005953
> [ 2559.103969] x19: 0000000000000000 [ 2559.107102] Unhandled fault:
> synchronous external abort (0x96000010) at 0xffff800000c1e000
> [ 2559.107108] Internal error: : 96000010 [#9] PREEMPT SMP
> [ 2559.107110] Modules linked in:
> [ 2559.107113] meson_rng rng_core meson_gxbb_wdt ip_tables x_tables
> ipv6 dwmac_generic realtek dwmac_meson8b stmmac_platform stmmac[
> 2559.107131] CPU: 0 PID: 1124 Comm: mmcqd/1 Tainted: G D 1
> [ 2559.107132] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2559.107135] task: ffff8000704abe80 task.stack: ffff8000734d0000
> [ 2559.107147] PC is at __memcpy+0x100/0x180
> [ 2559.107152] LR is at sg_copy_buffer+0xb0/0x110
> [ 2559.107155] pc : [<ffff00000837ee00>] lr : [<ffff00000838e928>]
> pstate: 200001c5
> [ 2559.107155] sp : ffff8000734d3bb0
> [ 2559.107157] x29: ffff8000734d3bb0
> [ 2559.107158] x28: ffff800073a14800 x27: ffff800073a14b68
> [ 2559.107162] x26: 0000000000000000 x25: 0000000000000140
> [ 2559.107165] x24: 0000000000000001 x23: 0000000000001000
> [ 2559.107168] x22: ffff8000746a2000 x21: 0000000000001000
> [ 2559.107170] x20: 0000000000000000 x19: 0000000000001000
> [ 2559.107172] x18: 0000000000000000 x17: ffffffffffffffff
> [ 2559.107175] x16: 00000000000006be x15: ffff000008c34000
> [ 2559.107178] x14: 747962342e090a34 x13: 3278302038323162
> [ 2559.107181] x12: 656c752e090a3864 x11: ffff800073866800
> [ 2559.107183] x10: ffff80006bf68eb0 x9 : 0000000000000000
> [ 2559.107186] x8 : ffff800073a94920 x7 : 0000000000000000
> [ 2559.107188] x6 : ffff8000746a2000 x5 : 0000820000000000
> [ 2559.107191] x4 : 0000000000000000 x3 : 0000000000000000
> [ 2559.107193] x2 : 0000000000000f80 x1 : ffff800000c1e000
> [ 2559.107196] x0 : ffff8000746a2000
> [ 2559.107199] Process mmcqd/1 (pid: 1124, stack limit =
> 0xffff8000734d0000)
> [ 2559.107202] Stack: (0xffff8000734d3bb0 to 0xffff8000734d4000)
> [ 2559.107205] 3ba0: ffff8000734d3c50
> ffff00000838e9bc
> [ 2559.107208] 3bc0: ffff800073a14000 ffff800073a14a30 ffff80006bf68eb0
> ffff800073a14a28
> [ 2559.107212] 3be0: ffff800073a14818 ffff800073a14800 0000000000000000
> ffff00000838e1c4
> [ 2559.107215] 3c00: ffff800073a94900 ffff7e0000030780 ffff800000c1e000
> 0000000000001000
> [ 2559.107218] 3c20: 0000000000001000 ffff800073ad0a00 0000000100000000
> 0000000000000001
> [ 2559.107221] 3c40: 0000100000000000 0000000000000005 ffff8000734d3c60
> ffff00000874c1bc
> [ 2559.107224] 3c60: ffff8000734d3c70 ffff000008748010 ffff8000734d3cd0
> ffff000008749908
> [ 2559.107228] 3c80: ffff80006bf68eb0 ffff800073a14000 ffff8000734c8000
> ffff800073a14818
> [ 2559.107231] 3ca0: ffff800073a14800 ffff800073a14800 ffff80006bf68eb0
> ffff800073a14a28
> [ 2559.107234] 3cc0: ffff80006bf68eb0 ffff000008749bc8 ffff8000734d3d70
> ffff00000874b298
> [ 2559.107237] 3ce0: ffff800073a14000 ffff800073a14818 ffff8000734c8000
> 0000000000000000
> [ 2559.107240] 3d00: ffff800073a14800 ffff800073a14800 ffff800073a13800
> 0000000000000000
> [ 2559.107243] 3d20: ffff80006bf68eb0 0000000000000000 00000000012853f0
> ffff000008c0fcb8
> [ 2559.107246] 3d40: 0000000000000000 000000000835bf14 ffff000008a05f58
> ffff800000000000
> [ 2559.107249] 3d60: ffff8000734c8000 0000000000000001 ffff8000734d3de0
> ffff00000874b6f4
> [ 2559.107252] 3d80: ffff800073a14818 ffff80006bf68eb0 ffff8000734c8000
> 0000000000000001
> [ 2559.107255] 3da0: ffff800073a14828 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107258] 3dc0: 0000000000000000 0000000000000000 ffff800073a14818
> ffff00000874b6c4
> [ 2559.107261] 3de0: ffff8000734d3e20 ffff0000080daa84 ffff800073a94980
> ffff000008e8eb08
> [ 2559.107264] 3e00: ffff000008b75b50 ffff800073a14818 ffff00000874b658
> 0000000000000000
> [ 2559.107267] 3e20: 0000000000000000 ffff000008082ec0 ffff0000080da9b8
> ffff800073a94980
> [ 2559.107270] 3e40: 0000000000000000 0000000000000000 0000000000000000
> 000003ff01893600
> [ 2559.107273] 3e60: ffff8000734d3ea0 0000000000000000 ffff0000080da9b8
> ffff800073a14818
> [ 2559.107276] 3e80: 0000000000000000 0000000000000000 ffff8000734d3e90
> ffff8000734d3e90
> [ 2559.107279] 3ea0: 0000000000000000 ffff000000000000 ffff8000734d3eb0
> ffff8000734d3eb0
> [ 2559.107281] 3ec0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107284] 3ee0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107287] 3f00: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107290] 3f20: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107293] 3f40: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107295] 3f60: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107298] 3f80: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107300] 3fa0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107303] 3fc0: 0000000000000000 0000000000000005 0000000000000000
> 0000000000000000
> [ 2559.107306] 3fe0: 0000000000000000 0000000000000000 0000001800002cba
> 26000000a01b3800
> [ 2559.107308] Call trace:
> [ 2559.107312] Exception stack(0xffff8000734d39e0 to
> 0xffff8000734d3b10)
> [ 2559.107315] 39e0: 0000000000001000 0001000000000000 ffff8000734d3bb0
> ffff00000837ee00
> [ 2559.107318] 3a00: 0000000000000007 ffff800000000000 ffff800000c1e000
> 0000000100100010
> [ 2559.107321] 3a20: ffff8000734d3ac0 ffff000008748d88 ffff8000734d3b8c
> 0000000000000001
> [ 2559.107324] 3a40: ffff8000734d3b40 ffff0000081c9dac ffff800074401d00
> ffff0000081745d8
> [ 2559.107327] 3a60: ffff7e0001b72f80 ffff80006dcbe300 00000000031fda40
> 0000000000000000
> [ 2559.107330] 3a80: ffff8000746a2000 ffff800000c1e000 0000000000000f80
> 0000000000000000
> [ 2559.107333] 3aa0: 0000000000000000 0000820000000000 ffff8000746a2000
> 0000000000000000
> [ 2559.107336] 3ac0: ffff800073a94920 0000000000000000 ffff80006bf68eb0
> ffff800073866800
> [ 2559.107339] 3ae0: 656c752e090a3864 3278302038323162 747962342e090a34
> ffff000008c34000
> [ 2559.107341] 3b00: 00000000000006be ffffffffffffffff
> [ 2559.107346] [<ffff00000837ee00>] __memcpy+0x100/0x180
> [ 2559.107349] [<ffff00000838e9bc>] sg_copy_to_buffer+0x14/0x20
> [ 2559.107357] [<ffff00000874c1bc>] mmc_queue_bounce_pre+0x34/0x40
> [ 2559.107362] [<ffff000008748010>] mmc_blk_rw_rq_prep+0x288/0x3a0
> [ 2559.107365] [<ffff000008749908>] mmc_blk_issue_rw_rq+0x3c0/0x998
> [ 2559.107368] [<ffff00000874b298>] mmc_blk_issue_rq+0x150/0x510
> [ 2559.107371] [<ffff00000874b6f4>] mmc_queue_thread+0x9c/0x140
> [ 2559.107377] [<ffff0000080daa84>] kthread+0xcc/0xe0
> [ 2559.107383] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
Looks like it died whilst processing an mmc request.
^ permalink raw reply
* Re: [PATCH net-next] cgroup, bpf: remove unnecessary #include
From: Rami Rosen @ 2016-11-26 18:40 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, Daniel Mack, Tejun Heo, Netdev
In-Reply-To: <1480145027-3524392-1-git-send-email-ast@fb.com>
Acked-by: Rami Rosen <roszenrami@gmail.com>
On 26 November 2016 at 09:23, Alexei Starovoitov <ast@fb.com> wrote:
> this #include is unnecessary and brings whole set of
> other headers into cgroup-defs.h. Remove it.
>
> Fixes: 3007098494be ("cgroup: add support for eBPF programs")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> include/linux/bpf-cgroup.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> index ec80d0c0953e..0cf1adfadd2d 100644
> --- a/include/linux/bpf-cgroup.h
> +++ b/include/linux/bpf-cgroup.h
> @@ -1,7 +1,6 @@
> #ifndef _BPF_CGROUP_H
> #define _BPF_CGROUP_H
>
> -#include <linux/bpf.h>
> #include <linux/jump_label.h>
> #include <uapi/linux/bpf.h>
>
> --
> 2.8.0
>
^ permalink raw reply
* Re: net: GPF in eth_header
From: Eric Dumazet @ 2016-11-26 18:28 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, Tom Herbert, Alexander Duyck, Hannes Frederic Sowa,
Jiri Benc, Sabrina Dubroca, netdev, LKML, syzkaller
In-Reply-To: <CACT4Y+at4Fp6i7WRggYq7M1+z1aHo=Bff63p+1DzC2SnTjuWdA@mail.gmail.com>
On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program triggers GPF in eth_header:
>
> https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
>
> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> BUG: unable to handle kernel paging request at ffffed002d14d74a
> IP: [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
> PGD 7fff6067 [ 50.787819] PUD 7fff5067
> PMD 0 [ 50.787819]
> Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 2 PID: 6712 Comm: a.out Not tainted 4.9.0-rc6+ #55
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff88003a1841c0 task.stack: ffff880034d08000
> RIP: 0010:[<ffffffff86be3295>] [<ffffffff86be3295>]
> eth_header+0x75/0x260 net/ethernet/eth.c:88
> RSP: 0018:ffff880034d0eb68 EFLAGS: 00010a03
> RAX: 1ffff1002d14d74a RBX: ffff880168a6ba4a RCX: ffff88006a9c7858
> RDX: 000000000000dd86 RSI: dffffc0000000000 RDI: ffff880168a6ba56
> RBP: ffff880034d0eb98 R08: 0000000000000000 R09: 0000000000000031
> R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff88006c208d80 R14: 00000000000086dd R15: ffff88006a9c7858
> FS: 0000000001a02940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffed002d14d74a CR3: 0000000037373000 CR4: 00000000000006e0
> Stack:
> 000000316881ab40 ffff88006a9c76c0 ffff88006881ab40 ffff88006a9c77f8
> 0000000000000000 dffffc0000000000 ffff880034d0ee98 ffffffff86b31af9
> ffffffff8719605c ffff880034d0f0f8 ffffffff000086dd ffffffff86be3220
> Call Trace:
> [< inline >] dev_hard_header ./include/linux/netdevice.h:2762
> [<ffffffff86b31af9>] neigh_resolve_output+0x659/0xb20 net/core/neighbour.c:1302
> [< inline >] dst_neigh_output ./include/net/dst.h:464
> [<ffffffff8719605c>] ip6_finish_output2+0xb3c/0x2500 net/ipv6/ip6_output.c:121
> [<ffffffff871a0b0b>] ip6_finish_output+0x2eb/0x760 net/ipv6/ip6_output.c:139
> [< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
> [<ffffffff871a1157>] ip6_output+0x1d7/0x9a0 net/ipv6/ip6_output.c:153
> [< inline >] dst_output ./include/net/dst.h:501
> [<ffffffff873312ea>] ip6_local_out+0x9a/0x180 net/ipv6/output_core.c:170
> [<ffffffff871a3886>] ip6_send_skb+0xa6/0x340 net/ipv6/ip6_output.c:1712
> [<ffffffff871a3bd8>] ip6_push_pending_frames+0xb8/0xe0
> net/ipv6/ip6_output.c:1732
> [< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
> [<ffffffff8722acfb>] rawv6_sendmsg+0x250b/0x2c20 net/ipv6/raw.c:920
> [<ffffffff8701c4f5>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
> [< inline >] sock_sendmsg_nosec net/socket.c:621
> [<ffffffff86a6ea9f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
> [<ffffffff86a6ee0b>] sock_write_iter+0x32b/0x620 net/socket.c:829
> [<ffffffff81a6f153>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
> [<ffffffff81a71ba1>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
> [<ffffffff81a726dc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
> [<ffffffff81a72825>] do_writev+0x115/0x2d0 fs/read_write.c:944
> [< inline >] SYSC_writev fs/read_write.c:1017
> [<ffffffff81a75fdc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
> [<ffffffff8814cf85>] entry_SYSCALL_64_fastpath+0x23/0xc6
> arch/x86/entry/entry_64.S:209
> Code: 41 83 fe 04 0f 84 aa 00 00 00 e8 17 4e b0 fa 48 8d 7b 0c 48 be
> 00 00 00 00 00 fc ff df 44 89 f2 66 c1 c2 08 48 89 f8 48 c1 e8 03 <0f>
> b6 0c 30 48 8d 43 0d 49 89 c0 49 c1 e8 03 41 0f b6 34 30 49
> RIP [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
> RSP <ffff880034d0eb68>
> CR2: ffffed002d14d74a
> ---[ end trace a73fedfdc11bd60c ]---
Hi Dmitry
I could not reproduce the issue. Might need some specific configuration...
loopback device has proper ethernet header (all 0)
Fault happens in :
0f b6 0c 30 movzbl (%rax,%rsi,1),%ecx
RAX=1ffff1002d14d74a which is RDI>>3, and RSI=dffffc0000000000
Could this be a KASAN problem ?
^ permalink raw reply
* net: BUG in unix_notinflight
From: Dmitry Vyukov @ 2016-11-26 18:05 UTC (permalink / raw)
To: David Miller, Hannes Frederic Sowa, Willy Tarreau, netdev, LKML,
Eric Dumazet
Cc: syzkaller
Hello,
I am hitting the following BUG while running syzkaller fuzzer:
kernel BUG at net/unix/garbage.c:149!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 23491 Comm: syz-executor Not tainted 4.9.0-rc5+ #41
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
task: ffff8801c16b06c0 task.stack: ffff8801c2928000
RIP: 0010:[<ffffffff8717ebf4>] [<ffffffff8717ebf4>]
unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
RSP: 0018:ffff8801c292ea40 EFLAGS: 00010297
RAX: ffff8801c16b06c0 RBX: 1ffff10038525d4a RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 1ffff10038525d4e RDI: ffffffff8a6e9d84
RBP: ffff8801c292eb18 R08: 0000000000000000 R09: 0000000000000000
R10: cdca594876e035a1 R11: 0000000000000005 R12: 1ffff10038525d4e
R13: ffffffff899156e0 R14: ffff8801c292eaf0 R15: ffff88018b7cd780
FS: 00007f10420fa700(0000) GS:ffff8801d9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002000a000 CR3: 00000001c2ecc000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000400 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Stack:
dffffc0000000000 ffff88019f036970 0000000041b58ab3 ffffffff894c5120
ffffffff8717e840 ffff8801c16b06c0 ffff88018b7cdcf0 ffffffff894c51e2
ffffffff81576d50 0000000000000000 ffffffff00000000 1ffff10000000000
Call Trace:
[<ffffffff8716cfbf>] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
[<ffffffff8716f6a9>] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
[<ffffffff86a90a01>] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
[<ffffffff86a9808a>] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
[<ffffffff86a980ea>] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
[<ffffffff86a98284>] kfree_skb+0x184/0x570 net/core/skbuff.c:705
[<ffffffff871789d5>] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
[<ffffffff87179039>] unix_release+0x49/0x90 net/unix/af_unix.c:836
[<ffffffff86a694b2>] sock_release+0x92/0x1f0 net/socket.c:570
[<ffffffff86a6962b>] sock_close+0x1b/0x20 net/socket.c:1017
[<ffffffff81a76b8e>] __fput+0x34e/0x910 fs/file_table.c:208
[<ffffffff81a771da>] ____fput+0x1a/0x20 fs/file_table.c:244
[<ffffffff81483ab0>] task_work_run+0x1a0/0x280 kernel/task_work.c:116
[< inline >] exit_task_work include/linux/task_work.h:21
[<ffffffff8141287a>] do_exit+0x183a/0x2640 kernel/exit.c:828
[<ffffffff8141383e>] do_group_exit+0x14e/0x420 kernel/exit.c:931
[<ffffffff814429d3>] get_signal+0x663/0x1880 kernel/signal.c:2307
[<ffffffff81239b45>] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
[<ffffffff8100666a>] exit_to_usermode_loop+0x1ea/0x2d0
arch/x86/entry/common.c:156
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81009693>] syscall_return_slowpath+0x4d3/0x570
arch/x86/entry/common.c:259
[<ffffffff881478e6>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Code: df 49 89 87 70 05 00 00 41 c6 04 14 f8 48 89 f9 48 c1 e9 03 80
3c 11 00 75 64 49 89 87 78 05 00 00 e9 65 ff ff ff e8 ac 94 56 fa <0f>
0b 48 89 d7 48 89 95 30 ff ff ff e8 bb 22 87 fa 48 8b 95 30
RIP [<ffffffff8717ebf4>] unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
RSP <ffff8801c292ea40>
---[ end trace 4cbbd52674b68dab ]---
On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
Unfortunately this is not reproducible outside of syzkaller.
But easily reproducible with syzkaller. If you need to reproduce it,
follow instructions described here:
https://github.com/google/syzkaller/wiki/How-to-execute-syzkaller-programs
With the following as the program:
mmap(&(0x7f0000000000/0xdd5000)=nil, (0xdd5000), 0x3, 0x32,
0xffffffffffffffff, 0x0)
socketpair$unix(0x1, 0x5, 0x0, &(0x7f0000dc7000-0x8)={<r0=>0x0, <r1=>0x0})
sendmmsg$unix(r1,
&(0x7f0000dbf000-0xa8)=[{&(0x7f0000dbe000)=@file={0x1, ""}, 0x2,
&(0x7f0000dbe000)=[], 0x0, &(0x7f0000dc4000)=[@rights={0x20, 0x1, 0x1,
[r0, r0, r0, r1]}, @rights={0x14, 0x1, 0x1, [0xffffffffffffffff]},
@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}, @cred={0x20, 0x1, 0x2, 0x0,
0x0, 0x0}, @cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}], 0x5, 0x800},
{&(0x7f0000dbf000-0x7d)=@file={0x1, ""}, 0x2, &(0x7f0000dbe000)=[],
0x0, &(0x7f0000dbf000-0x80)=[@rights={0x20, 0x1, 0x1,
[0xffffffffffffffff, r1, 0xffffffffffffffff, r0]}, @cred={0x20, 0x1,
0x2, 0x0, 0x0, 0x0}, @cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0},
@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}], 0x4, 0x4},
{&(0x7f0000dbf000-0x8)=@abs={0x0, 0x0, 0x8}, 0x8,
&(0x7f0000dbe000)=[{&(0x7f0000dc0000-0x27)="", 0x0},
{&(0x7f0000dc1000-0xb0)="", 0x0}, {&(0x7f0000dc2000-0xc4)="", 0x0},
{&(0x7f0000dc2000)="", 0x0}, {&(0x7f0000dc3000)="", 0x0}], 0x5,
&(0x7f0000dbe000)=[@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0},
@rights={0x14, 0x1, 0x1, [r1]}, @cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0},
@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}], 0x4, 0x4}], 0x3, 0x800)
dup3(r1, r0, 0x80000)
close(r1)
^ permalink raw reply
* net: GPF in eth_header
From: Dmitry Vyukov @ 2016-11-26 17:30 UTC (permalink / raw)
To: David Miller, Tom Herbert, aduyck, Hannes Frederic Sowa, jbenc,
Sabrina Dubroca, netdev, LKML, Eric Dumazet
Cc: syzkaller
Hello,
The following program triggers GPF in eth_header:
https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
BUG: unable to handle kernel paging request at ffffed002d14d74a
IP: [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
PGD 7fff6067 [ 50.787819] PUD 7fff5067
PMD 0 [ 50.787819]
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 6712 Comm: a.out Not tainted 4.9.0-rc6+ #55
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88003a1841c0 task.stack: ffff880034d08000
RIP: 0010:[<ffffffff86be3295>] [<ffffffff86be3295>]
eth_header+0x75/0x260 net/ethernet/eth.c:88
RSP: 0018:ffff880034d0eb68 EFLAGS: 00010a03
RAX: 1ffff1002d14d74a RBX: ffff880168a6ba4a RCX: ffff88006a9c7858
RDX: 000000000000dd86 RSI: dffffc0000000000 RDI: ffff880168a6ba56
RBP: ffff880034d0eb98 R08: 0000000000000000 R09: 0000000000000031
R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88006c208d80 R14: 00000000000086dd R15: ffff88006a9c7858
FS: 0000000001a02940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffed002d14d74a CR3: 0000000037373000 CR4: 00000000000006e0
Stack:
000000316881ab40 ffff88006a9c76c0 ffff88006881ab40 ffff88006a9c77f8
0000000000000000 dffffc0000000000 ffff880034d0ee98 ffffffff86b31af9
ffffffff8719605c ffff880034d0f0f8 ffffffff000086dd ffffffff86be3220
Call Trace:
[< inline >] dev_hard_header ./include/linux/netdevice.h:2762
[<ffffffff86b31af9>] neigh_resolve_output+0x659/0xb20 net/core/neighbour.c:1302
[< inline >] dst_neigh_output ./include/net/dst.h:464
[<ffffffff8719605c>] ip6_finish_output2+0xb3c/0x2500 net/ipv6/ip6_output.c:121
[<ffffffff871a0b0b>] ip6_finish_output+0x2eb/0x760 net/ipv6/ip6_output.c:139
[< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
[<ffffffff871a1157>] ip6_output+0x1d7/0x9a0 net/ipv6/ip6_output.c:153
[< inline >] dst_output ./include/net/dst.h:501
[<ffffffff873312ea>] ip6_local_out+0x9a/0x180 net/ipv6/output_core.c:170
[<ffffffff871a3886>] ip6_send_skb+0xa6/0x340 net/ipv6/ip6_output.c:1712
[<ffffffff871a3bd8>] ip6_push_pending_frames+0xb8/0xe0
net/ipv6/ip6_output.c:1732
[< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
[<ffffffff8722acfb>] rawv6_sendmsg+0x250b/0x2c20 net/ipv6/raw.c:920
[<ffffffff8701c4f5>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff86a6ea9f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
[<ffffffff86a6ee0b>] sock_write_iter+0x32b/0x620 net/socket.c:829
[<ffffffff81a6f153>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
[<ffffffff81a71ba1>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
[<ffffffff81a726dc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
[<ffffffff81a72825>] do_writev+0x115/0x2d0 fs/read_write.c:944
[< inline >] SYSC_writev fs/read_write.c:1017
[<ffffffff81a75fdc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
[<ffffffff8814cf85>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:209
Code: 41 83 fe 04 0f 84 aa 00 00 00 e8 17 4e b0 fa 48 8d 7b 0c 48 be
00 00 00 00 00 fc ff df 44 89 f2 66 c1 c2 08 48 89 f8 48 c1 e8 03 <0f>
b6 0c 30 48 8d 43 0d 49 89 c0 49 c1 e8 03 41 0f b6 34 30 49
RIP [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
RSP <ffff880034d0eb68>
CR2: ffffed002d14d74a
---[ end trace a73fedfdc11bd60c ]---
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-26 17:20 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Kalle Valo,
Ivaylo Dimitrov, Tony Lindgren, linux-wireless,
Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161124184601.wo4al6nyzb6rmiqs-FnsA7b+Nu9XLHDo1XOr0g3XdqJI7FyRRX3B1VOXEql0@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 671 bytes --]
On Thursday 24 November 2016 19:46:01 Aaro Koskinen wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > Proprietary, signed and closed bootloader NOLO does not support DT.
> > So for booting you need to append DTS file to kernel image.
> >
> > U-Boot is optional and can be used as intermediate bootloader
> > between NOLO and kernel. But still it has problems with reading
> > from nand, so cannot read NVS data nor MAC address.
>
> You could use kexec to pass the fixed DT.
>
> A.
IIRC it was broken for N900/omap3, no idea if somebody fixed it.
--
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pavel Machek @ 2016-11-26 17:17 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Pali Rohár, Sebastian Reichel, Michal Kazior, Kalle Valo,
Ivaylo Dimitrov, Tony Lindgren, linux-wireless,
Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161124184601.wo4al6nyzb6rmiqs-FnsA7b+Nu9XLHDo1XOr0g3XdqJI7FyRRX3B1VOXEql0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Thu 2016-11-24 20:46:01, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > Proprietary, signed and closed bootloader NOLO does not support DT. So
> > for booting you need to append DTS file to kernel image.
> >
> > U-Boot is optional and can be used as intermediate bootloader between
> > NOLO and kernel. But still it has problems with reading from nand, so
> > cannot read NVS data nor MAC address.
>
> You could use kexec to pass the fixed DT.
Yeah. You could also strap desktop PC to a USB GPRS card, and call it
phone. You could also make a pig fly.
But because you could does not mean you should. No, sorry, kexec is
not acceptable. Too hard to set up, slows boot too much.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: net: deadlock on genl_mutex
From: Eric Dumazet @ 2016-11-26 17:12 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, Matti Vaittinen, Tycho Andersen, Cong Wang,
Florian Westphal, stephen hemminger, Tom Herbert, netdev, LKML,
Richard Guy Briggs, syzkaller
In-Reply-To: <CACT4Y+ZdSNVhF2MH0=t=kBUrgNSSnCSO5uwnnc5c0KNLG+VNFQ@mail.gmail.com>
On Sat, Nov 26, 2016 at 9:04 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program triggers deadlock warnings on genl_mutex:
>
> https://gist.githubusercontent.com/dvyukov/65e33d053e507d2ab0bf6ae83d989585/raw/b3c640ec58e894b50bcbf255c471406466cfa5d0/gistfile1.txt
>
> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
> in_atomic(): 1, irqs_disabled(): 0, pid: 32289, name: syz-executor
> CPU: 0 PID: 32289 Comm: syz-executor Not tainted 4.9.0-rc5+ #54
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff88003ec06420 ffffffff834c2e39 ffffffff00000000 1ffff10007d80c17
> ffffed0007d80c0f 0000000041b58ab3 ffffffff89575550 ffffffff834c2b4b
> ffffffff8baab1a0 dffffc0000000000 0000000000000000 ffff880068f794e0
> Call Trace:
> <IRQ> [ 287.394552] [< inline >] __dump_stack lib/dump_stack.c:15
> <IRQ> [ 287.394552] [<ffffffff834c2e39>] dump_stack+0x2ee/0x3f5
> lib/dump_stack.c:51
> [<ffffffff814b6ac3>] ___might_sleep+0x483/0x660 kernel/sched/core.c:7761
> [<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
> [<ffffffff88139aaa>] mutex_lock_nested+0x1ea/0xf20 kernel/locking/mutex.c:620
> [< inline >] genl_lock net/netlink/genetlink.c:31
> [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
> [<ffffffff86ca5458>] netlink_sock_destruct+0xf8/0x400
> net/netlink/af_netlink.c:331
> [<ffffffff86a7b234>] __sk_destruct+0xf4/0x7f0 net/core/sock.c:1423
> [<ffffffff86a87d6c>] sk_destruct+0x4c/0x80 net/core/sock.c:1453
> [<ffffffff86a87dfc>] __sk_free+0x5c/0x230 net/core/sock.c:1461
> [<ffffffff86a87ff8>] sk_free+0x28/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff86ca6cd1>] deferred_put_nlk_sk+0x31/0x40 net/netlink/af_netlink.c:652
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff815cbc9d>] rcu_do_batch.isra.70+0x9ed/0xe20 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff815cc55c>] rcu_process_callbacks+0x48c/0xd70 kernel/rcu/tree.c:3024
> [<ffffffff8814d53b>] __do_softirq+0x32b/0xca8 kernel/softirq.c:284
> [< inline >] invoke_softirq kernel/softirq.c:364
> [<ffffffff8141a941>] irq_exit+0x1d1/0x210 kernel/softirq.c:405
> [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
> [<ffffffff8814ca30>] smp_apic_timer_interrupt+0x80/0xa0
> arch/x86/kernel/apic/apic.c:960
> [<ffffffff8814badc>] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:489
> <EOI> [ 287.403717] [<ffffffff8155c987>] ? lock_is_held+0x247/0x310
> [<ffffffff814b6bde>] ___might_sleep+0x59e/0x660 kernel/sched/core.c:7729
> [<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
> [<ffffffff88142d08>] down_read+0x78/0x160 kernel/locking/rwsem.c:21
> [< inline >] anon_vma_lock_read include/linux/rmap.h:127
> [<ffffffff81968295>] validate_mm+0xe5/0x880 mm/mmap.c:347
> [<ffffffff8196bf0b>] vma_link+0x11b/0x180 mm/mmap.c:605
> [<ffffffff81977f46>] mmap_region+0x1076/0x1880 mm/mmap.c:1692
> [<ffffffff81978e4f>] do_mmap+0x6ff/0xe80 mm/mmap.c:1450
> [< inline >] do_mmap_pgoff include/linux/mm.h:2039
> [<ffffffff818fd527>] vm_mmap_pgoff+0x1b7/0x210 mm/util.c:305
> [< inline >] SYSC_mmap_pgoff mm/mmap.c:1500
> [<ffffffff8196f961>] SyS_mmap_pgoff+0x231/0x5e0 mm/mmap.c:1458
> [< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
> [<ffffffff8124bf4b>] SyS_mmap+0x1b/0x30 arch/x86/kernel/sys_x86_64.c:86
> [<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
>
> =================================
> [ INFO: inconsistent lock state ]
> 4.9.0-rc5+ #54 Tainted: G W
> ---------------------------------
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> syz-executor/32289 [HC0[0]:SC1[1]:HE1:SE0] takes:
> ([ 287.580014] genl_mutex
> [< inline >] genl_lock net/netlink/genetlink.c:31
> [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
> {SOFTIRQ-ON-W} state was registered at:
> [ 287.580014] [< inline >] mark_irqflags
> kernel/locking/lockdep.c:2938
> [ 287.580014] [<ffffffff81567ad7>] __lock_acquire+0x6e7/0x3380
> kernel/locking/lockdep.c:3292
> [ 287.580014] [<ffffffff8156b642>] lock_acquire+0x2a2/0x790
> kernel/locking/lockdep.c:3746
> [ 287.580014] [< inline >] __mutex_lock_common
> kernel/locking/mutex.c:521
> [ 287.580014] [<ffffffff88139aff>] mutex_lock_nested+0x23f/0xf20
> kernel/locking/mutex.c:621
> [ 287.580014] [< inline >] genl_lock net/netlink/genetlink.c:31
> [ 287.580014] [< inline >] genl_lock_all net/netlink/genetlink.c:52
> [ 287.580014] [<ffffffff86cba52e>]
> __genl_register_family+0x2ce/0x1870 net/netlink/genetlink.c:374
> [ 287.580014] [< inline >]
> _genl_register_family_with_ops_grps include/net/genetlink.h:173
> [ 287.580014] [<ffffffff8ab90c02>] genl_init+0x11d/0x185
> net/netlink/genetlink.c:1084
> [ 287.580014] [<ffffffff8100244b>] do_one_initcall+0xfb/0x3f0 init/main.c:778
> [ 287.580014] [< inline >] do_initcall_level init/main.c:844
> [ 287.580014] [< inline >] do_initcalls init/main.c:852
> [ 287.580014] [< inline >] do_basic_setup init/main.c:870
> [ 287.580014] [<ffffffff8aa3d03d>] kernel_init_freeable+0x5c4/0x69e
> init/main.c:1017
> [ 287.580014] [<ffffffff88129c88>] kernel_init+0x18/0x180 init/main.c:943
> [ 287.580014] [<ffffffff8814a05a>] ret_from_fork+0x2a/0x40
> arch/x86/entry/entry_64.S:433
>
> [ 78.258919] [ INFO: inconsistent lock state ]
> [ 78.258919] 4.9.0-rc5+ #54 Tainted: G W
> [ 78.258919] ---------------------------------
> [ 78.258919] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> [ 78.258919] syz-fuzzer/5211 [HC0[0]:SC1[1]:HE1:SE0] takes:
> [ 78.258919] ([ 78.258919] genl_mutex
> ){+.?.+.}[ 78.258919] , at:
> [ 78.258919] [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0
> [ 78.258919] {SOFTIRQ-ON-W} state was registered at:
> [ 78.258919] [ 78.258919] [<ffffffff81567ad7>] __lock_acquire+0x6e7/0x3380
> [ 78.258919] [ 78.258919] [<ffffffff8156b642>] lock_acquire+0x2a2/0x790
> [ 78.258919] [ 78.258919] [<ffffffff88139aff>]
> mutex_lock_nested+0x23f/0xf20
> [ 78.258919] [ 78.258919] [<ffffffff86cba52e>]
> __genl_register_family+0x2ce/0x1870
> [ 78.258919] [ 78.258919] [<ffffffff8ab90c02>] genl_init+0x11d/0x185
> [ 78.258919] [ 78.258919] [<ffffffff8100244b>] do_one_initcall+0xfb/0x3f0
> [ 78.258919] [ 78.258919] [<ffffffff8aa3d03d>]
> kernel_init_freeable+0x5c4/0x69e
> [ 78.258919] [ 78.258919] [<ffffffff88129c88>] kernel_init+0x18/0x180
> [ 78.258919] [ 78.258919] [<ffffffff8814a05a>] ret_from_fork+0x2a/0x40
> [ 78.258919] irq event stamp: 149484
> [ 78.258919] hardirqs last enabled at (149484): [ 78.258919]
> [<ffffffff8814a7df>] restore_regs_and_iret+0x0/0x1d
> [ 78.258919] hardirqs last disabled at (149483): [ 78.258919]
> [<ffffffff8814bad7>] apic_timer_interrupt+0x87/0xa0
> [ 78.258919] softirqs last enabled at (149302): [ 78.258919]
> [<ffffffff8814da39>] __do_softirq+0x829/0xca8
> [ 78.258919] softirqs last disabled at (149437): [ 78.258919]
> [<ffffffff8141a941>] irq_exit+0x1d1/0x210
>
> [ 78.258919]
> [ 78.258919] other info that might help us debug this:
> [ 78.258919] Possible unsafe locking scenario:
> [ 78.258919]
> [ 78.258919] CPU0
> [ 78.258919] ----
> [ 78.258919] lock([ 78.258919] genl_mutex
> [ 78.258919] );
> [ 78.258919] <Interrupt>
> [ 78.258919] lock([ 78.258919] genl_mutex
> [ 78.258919] );
> [ 78.258919]
> [ 78.258919] *** DEADLOCK ***
> [ 78.258919]
> [ 78.258919] 1 lock held by syz-fuzzer/5211:
> [ 78.258919] #0: [ 78.258919] (
> rcu_callback[ 78.258919] ){......}
> , at: [ 78.258919] [<ffffffff815cbc43>] rcu_do_batch.isra.70+0x993/0xe20
> [ 78.258919]
> [ 78.258919] stack backtrace:
>
> CPU: 0 PID: 32289 Comm: syz-executor Tainted: G W 4.9.0-rc5+ #54
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff88003ec05db8 ffffffff834c2e39 ffffffff00000000 1ffff10007d80b4a
> ffffed0007d80b42 0000000041b58ab3 ffffffff89575550 ffffffff834c2b4b
> ffff88003948a340 ffff88003ec22cc0 ffff8800384dd280 0000000041b58ab3
> Call Trace:
> <IRQ> [ 287.580014] [< inline >] __dump_stack lib/dump_stack.c:15
> <IRQ> [ 287.580014] [<ffffffff834c2e39>] dump_stack+0x2ee/0x3f5
> lib/dump_stack.c:51
> [<ffffffff815648df>] print_usage_bug+0x3ef/0x450 kernel/locking/lockdep.c:2388
> [< inline >] valid_state kernel/locking/lockdep.c:2401
> [< inline >] mark_lock_irq kernel/locking/lockdep.c:2599
> [<ffffffff81565870>] mark_lock+0xf30/0x1410 kernel/locking/lockdep.c:3062
> [< inline >] mark_irqflags kernel/locking/lockdep.c:2920
> [<ffffffff8156811e>] __lock_acquire+0xd2e/0x3380 kernel/locking/lockdep.c:3292
> [<ffffffff8156b642>] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3746
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> [<ffffffff88139aff>] mutex_lock_nested+0x23f/0xf20 kernel/locking/mutex.c:621
> [< inline >] genl_lock net/netlink/genetlink.c:31
> [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
> [<ffffffff86ca5458>] netlink_sock_destruct+0xf8/0x400
> net/netlink/af_netlink.c:331
> [<ffffffff86a7b234>] __sk_destruct+0xf4/0x7f0 net/core/sock.c:1423
> [<ffffffff86a87d6c>] sk_destruct+0x4c/0x80 net/core/sock.c:1453
> [<ffffffff86a87dfc>] __sk_free+0x5c/0x230 net/core/sock.c:1461
> [<ffffffff86a87ff8>] sk_free+0x28/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff86ca6cd1>] deferred_put_nlk_sk+0x31/0x40 net/netlink/af_netlink.c:652
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff815cbc9d>] rcu_do_batch.isra.70+0x9ed/0xe20 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff815cc55c>] rcu_process_callbacks+0x48c/0xd70 kernel/rcu/tree.c:3024
> [<ffffffff8814d53b>] __do_softirq+0x32b/0xca8 kernel/softirq.c:284
> [< inline >] invoke_softirq kernel/softirq.c:364
> [<ffffffff8141a941>] irq_exit+0x1d1/0x210 kernel/softirq.c:405
> [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
> [<ffffffff8814ca30>] smp_apic_timer_interrupt+0x80/0xa0
> arch/x86/kernel/apic/apic.c:960
> [<ffffffff8814badc>] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:489
> <EOI> [ 287.580014] [<ffffffff8155c987>] ? lock_is_held+0x247/0x310
> [<ffffffff814b6bde>] ___might_sleep+0x59e/0x660 kernel/sched/core.c:7729
> [<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
> [<ffffffff88142d08>] down_read+0x78/0x160 kernel/locking/rwsem.c:21
> [< inline >] anon_vma_lock_read include/linux/rmap.h:127
> [<ffffffff81968295>] validate_mm+0xe5/0x880 mm/mmap.c:347
> [<ffffffff8196bf0b>] vma_link+0x11b/0x180 mm/mmap.c:605
> [<ffffffff81977f46>] mmap_region+0x1076/0x1880 mm/mmap.c:1692
> [<ffffffff81978e4f>] do_mmap+0x6ff/0xe80 mm/mmap.c:1450
> [< inline >] do_mmap_pgoff include/linux/mm.h:2039
> [<ffffffff818fd527>] vm_mmap_pgoff+0x1b7/0x210 mm/util.c:305
> [< inline >] SYSC_mmap_pgoff mm/mmap.c:1500
> [<ffffffff8196f961>] SyS_mmap_pgoff+0x231/0x5e0 mm/mmap.c:1458
> [< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
> [<ffffffff8124bf4b>] SyS_mmap+0x1b/0x30 arch/x86/kernel/sys_x86_64.c:86
> [<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
Issue was reported yesterday and is under investigation.
http://marc.info/?l=linux-netdev&m=148014004331663&w=2
Thanks !
^ permalink raw reply
* net: deadlock on genl_mutex
From: Dmitry Vyukov @ 2016-11-26 17:04 UTC (permalink / raw)
To: David Miller, Matti Vaittinen, Tycho Andersen, Cong Wang,
Florian Westphal, stephen hemminger, Tom Herbert, netdev, LKML,
Eric Dumazet, rgb
Cc: syzkaller
Hello,
The following program triggers deadlock warnings on genl_mutex:
https://gist.githubusercontent.com/dvyukov/65e33d053e507d2ab0bf6ae83d989585/raw/b3c640ec58e894b50bcbf255c471406466cfa5d0/gistfile1.txt
On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
in_atomic(): 1, irqs_disabled(): 0, pid: 32289, name: syz-executor
CPU: 0 PID: 32289 Comm: syz-executor Not tainted 4.9.0-rc5+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88003ec06420 ffffffff834c2e39 ffffffff00000000 1ffff10007d80c17
ffffed0007d80c0f 0000000041b58ab3 ffffffff89575550 ffffffff834c2b4b
ffffffff8baab1a0 dffffc0000000000 0000000000000000 ffff880068f794e0
Call Trace:
<IRQ> [ 287.394552] [< inline >] __dump_stack lib/dump_stack.c:15
<IRQ> [ 287.394552] [<ffffffff834c2e39>] dump_stack+0x2ee/0x3f5
lib/dump_stack.c:51
[<ffffffff814b6ac3>] ___might_sleep+0x483/0x660 kernel/sched/core.c:7761
[<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
[<ffffffff88139aaa>] mutex_lock_nested+0x1ea/0xf20 kernel/locking/mutex.c:620
[< inline >] genl_lock net/netlink/genetlink.c:31
[<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
[<ffffffff86ca5458>] netlink_sock_destruct+0xf8/0x400
net/netlink/af_netlink.c:331
[<ffffffff86a7b234>] __sk_destruct+0xf4/0x7f0 net/core/sock.c:1423
[<ffffffff86a87d6c>] sk_destruct+0x4c/0x80 net/core/sock.c:1453
[<ffffffff86a87dfc>] __sk_free+0x5c/0x230 net/core/sock.c:1461
[<ffffffff86a87ff8>] sk_free+0x28/0x30 net/core/sock.c:1472
[< inline >] sock_put include/net/sock.h:1591
[<ffffffff86ca6cd1>] deferred_put_nlk_sk+0x31/0x40 net/netlink/af_netlink.c:652
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[<ffffffff815cbc9d>] rcu_do_batch.isra.70+0x9ed/0xe20 kernel/rcu/tree.c:2776
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
[<ffffffff815cc55c>] rcu_process_callbacks+0x48c/0xd70 kernel/rcu/tree.c:3024
[<ffffffff8814d53b>] __do_softirq+0x32b/0xca8 kernel/softirq.c:284
[< inline >] invoke_softirq kernel/softirq.c:364
[<ffffffff8141a941>] irq_exit+0x1d1/0x210 kernel/softirq.c:405
[< inline >] exiting_irq arch/x86/include/asm/apic.h:659
[<ffffffff8814ca30>] smp_apic_timer_interrupt+0x80/0xa0
arch/x86/kernel/apic/apic.c:960
[<ffffffff8814badc>] apic_timer_interrupt+0x8c/0xa0
arch/x86/entry/entry_64.S:489
<EOI> [ 287.403717] [<ffffffff8155c987>] ? lock_is_held+0x247/0x310
[<ffffffff814b6bde>] ___might_sleep+0x59e/0x660 kernel/sched/core.c:7729
[<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
[<ffffffff88142d08>] down_read+0x78/0x160 kernel/locking/rwsem.c:21
[< inline >] anon_vma_lock_read include/linux/rmap.h:127
[<ffffffff81968295>] validate_mm+0xe5/0x880 mm/mmap.c:347
[<ffffffff8196bf0b>] vma_link+0x11b/0x180 mm/mmap.c:605
[<ffffffff81977f46>] mmap_region+0x1076/0x1880 mm/mmap.c:1692
[<ffffffff81978e4f>] do_mmap+0x6ff/0xe80 mm/mmap.c:1450
[< inline >] do_mmap_pgoff include/linux/mm.h:2039
[<ffffffff818fd527>] vm_mmap_pgoff+0x1b7/0x210 mm/util.c:305
[< inline >] SYSC_mmap_pgoff mm/mmap.c:1500
[<ffffffff8196f961>] SyS_mmap_pgoff+0x231/0x5e0 mm/mmap.c:1458
[< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
[<ffffffff8124bf4b>] SyS_mmap+0x1b/0x30 arch/x86/kernel/sys_x86_64.c:86
[<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
=================================
[ INFO: inconsistent lock state ]
4.9.0-rc5+ #54 Tainted: G W
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
syz-executor/32289 [HC0[0]:SC1[1]:HE1:SE0] takes:
([ 287.580014] genl_mutex
[< inline >] genl_lock net/netlink/genetlink.c:31
[<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
{SOFTIRQ-ON-W} state was registered at:
[ 287.580014] [< inline >] mark_irqflags
kernel/locking/lockdep.c:2938
[ 287.580014] [<ffffffff81567ad7>] __lock_acquire+0x6e7/0x3380
kernel/locking/lockdep.c:3292
[ 287.580014] [<ffffffff8156b642>] lock_acquire+0x2a2/0x790
kernel/locking/lockdep.c:3746
[ 287.580014] [< inline >] __mutex_lock_common
kernel/locking/mutex.c:521
[ 287.580014] [<ffffffff88139aff>] mutex_lock_nested+0x23f/0xf20
kernel/locking/mutex.c:621
[ 287.580014] [< inline >] genl_lock net/netlink/genetlink.c:31
[ 287.580014] [< inline >] genl_lock_all net/netlink/genetlink.c:52
[ 287.580014] [<ffffffff86cba52e>]
__genl_register_family+0x2ce/0x1870 net/netlink/genetlink.c:374
[ 287.580014] [< inline >]
_genl_register_family_with_ops_grps include/net/genetlink.h:173
[ 287.580014] [<ffffffff8ab90c02>] genl_init+0x11d/0x185
net/netlink/genetlink.c:1084
[ 287.580014] [<ffffffff8100244b>] do_one_initcall+0xfb/0x3f0 init/main.c:778
[ 287.580014] [< inline >] do_initcall_level init/main.c:844
[ 287.580014] [< inline >] do_initcalls init/main.c:852
[ 287.580014] [< inline >] do_basic_setup init/main.c:870
[ 287.580014] [<ffffffff8aa3d03d>] kernel_init_freeable+0x5c4/0x69e
init/main.c:1017
[ 287.580014] [<ffffffff88129c88>] kernel_init+0x18/0x180 init/main.c:943
[ 287.580014] [<ffffffff8814a05a>] ret_from_fork+0x2a/0x40
arch/x86/entry/entry_64.S:433
[ 78.258919] [ INFO: inconsistent lock state ]
[ 78.258919] 4.9.0-rc5+ #54 Tainted: G W
[ 78.258919] ---------------------------------
[ 78.258919] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 78.258919] syz-fuzzer/5211 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 78.258919] ([ 78.258919] genl_mutex
){+.?.+.}[ 78.258919] , at:
[ 78.258919] [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0
[ 78.258919] {SOFTIRQ-ON-W} state was registered at:
[ 78.258919] [ 78.258919] [<ffffffff81567ad7>] __lock_acquire+0x6e7/0x3380
[ 78.258919] [ 78.258919] [<ffffffff8156b642>] lock_acquire+0x2a2/0x790
[ 78.258919] [ 78.258919] [<ffffffff88139aff>]
mutex_lock_nested+0x23f/0xf20
[ 78.258919] [ 78.258919] [<ffffffff86cba52e>]
__genl_register_family+0x2ce/0x1870
[ 78.258919] [ 78.258919] [<ffffffff8ab90c02>] genl_init+0x11d/0x185
[ 78.258919] [ 78.258919] [<ffffffff8100244b>] do_one_initcall+0xfb/0x3f0
[ 78.258919] [ 78.258919] [<ffffffff8aa3d03d>]
kernel_init_freeable+0x5c4/0x69e
[ 78.258919] [ 78.258919] [<ffffffff88129c88>] kernel_init+0x18/0x180
[ 78.258919] [ 78.258919] [<ffffffff8814a05a>] ret_from_fork+0x2a/0x40
[ 78.258919] irq event stamp: 149484
[ 78.258919] hardirqs last enabled at (149484): [ 78.258919]
[<ffffffff8814a7df>] restore_regs_and_iret+0x0/0x1d
[ 78.258919] hardirqs last disabled at (149483): [ 78.258919]
[<ffffffff8814bad7>] apic_timer_interrupt+0x87/0xa0
[ 78.258919] softirqs last enabled at (149302): [ 78.258919]
[<ffffffff8814da39>] __do_softirq+0x829/0xca8
[ 78.258919] softirqs last disabled at (149437): [ 78.258919]
[<ffffffff8141a941>] irq_exit+0x1d1/0x210
[ 78.258919]
[ 78.258919] other info that might help us debug this:
[ 78.258919] Possible unsafe locking scenario:
[ 78.258919]
[ 78.258919] CPU0
[ 78.258919] ----
[ 78.258919] lock([ 78.258919] genl_mutex
[ 78.258919] );
[ 78.258919] <Interrupt>
[ 78.258919] lock([ 78.258919] genl_mutex
[ 78.258919] );
[ 78.258919]
[ 78.258919] *** DEADLOCK ***
[ 78.258919]
[ 78.258919] 1 lock held by syz-fuzzer/5211:
[ 78.258919] #0: [ 78.258919] (
rcu_callback[ 78.258919] ){......}
, at: [ 78.258919] [<ffffffff815cbc43>] rcu_do_batch.isra.70+0x993/0xe20
[ 78.258919]
[ 78.258919] stack backtrace:
CPU: 0 PID: 32289 Comm: syz-executor Tainted: G W 4.9.0-rc5+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88003ec05db8 ffffffff834c2e39 ffffffff00000000 1ffff10007d80b4a
ffffed0007d80b42 0000000041b58ab3 ffffffff89575550 ffffffff834c2b4b
ffff88003948a340 ffff88003ec22cc0 ffff8800384dd280 0000000041b58ab3
Call Trace:
<IRQ> [ 287.580014] [< inline >] __dump_stack lib/dump_stack.c:15
<IRQ> [ 287.580014] [<ffffffff834c2e39>] dump_stack+0x2ee/0x3f5
lib/dump_stack.c:51
[<ffffffff815648df>] print_usage_bug+0x3ef/0x450 kernel/locking/lockdep.c:2388
[< inline >] valid_state kernel/locking/lockdep.c:2401
[< inline >] mark_lock_irq kernel/locking/lockdep.c:2599
[<ffffffff81565870>] mark_lock+0xf30/0x1410 kernel/locking/lockdep.c:3062
[< inline >] mark_irqflags kernel/locking/lockdep.c:2920
[<ffffffff8156811e>] __lock_acquire+0xd2e/0x3380 kernel/locking/lockdep.c:3292
[<ffffffff8156b642>] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffffffff88139aff>] mutex_lock_nested+0x23f/0xf20 kernel/locking/mutex.c:621
[< inline >] genl_lock net/netlink/genetlink.c:31
[<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
[<ffffffff86ca5458>] netlink_sock_destruct+0xf8/0x400
net/netlink/af_netlink.c:331
[<ffffffff86a7b234>] __sk_destruct+0xf4/0x7f0 net/core/sock.c:1423
[<ffffffff86a87d6c>] sk_destruct+0x4c/0x80 net/core/sock.c:1453
[<ffffffff86a87dfc>] __sk_free+0x5c/0x230 net/core/sock.c:1461
[<ffffffff86a87ff8>] sk_free+0x28/0x30 net/core/sock.c:1472
[< inline >] sock_put include/net/sock.h:1591
[<ffffffff86ca6cd1>] deferred_put_nlk_sk+0x31/0x40 net/netlink/af_netlink.c:652
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[<ffffffff815cbc9d>] rcu_do_batch.isra.70+0x9ed/0xe20 kernel/rcu/tree.c:2776
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
[<ffffffff815cc55c>] rcu_process_callbacks+0x48c/0xd70 kernel/rcu/tree.c:3024
[<ffffffff8814d53b>] __do_softirq+0x32b/0xca8 kernel/softirq.c:284
[< inline >] invoke_softirq kernel/softirq.c:364
[<ffffffff8141a941>] irq_exit+0x1d1/0x210 kernel/softirq.c:405
[< inline >] exiting_irq arch/x86/include/asm/apic.h:659
[<ffffffff8814ca30>] smp_apic_timer_interrupt+0x80/0xa0
arch/x86/kernel/apic/apic.c:960
[<ffffffff8814badc>] apic_timer_interrupt+0x8c/0xa0
arch/x86/entry/entry_64.S:489
<EOI> [ 287.580014] [<ffffffff8155c987>] ? lock_is_held+0x247/0x310
[<ffffffff814b6bde>] ___might_sleep+0x59e/0x660 kernel/sched/core.c:7729
[<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
[<ffffffff88142d08>] down_read+0x78/0x160 kernel/locking/rwsem.c:21
[< inline >] anon_vma_lock_read include/linux/rmap.h:127
[<ffffffff81968295>] validate_mm+0xe5/0x880 mm/mmap.c:347
[<ffffffff8196bf0b>] vma_link+0x11b/0x180 mm/mmap.c:605
[<ffffffff81977f46>] mmap_region+0x1076/0x1880 mm/mmap.c:1692
[<ffffffff81978e4f>] do_mmap+0x6ff/0xe80 mm/mmap.c:1450
[< inline >] do_mmap_pgoff include/linux/mm.h:2039
[<ffffffff818fd527>] vm_mmap_pgoff+0x1b7/0x210 mm/util.c:305
[< inline >] SYSC_mmap_pgoff mm/mmap.c:1500
[<ffffffff8196f961>] SyS_mmap_pgoff+0x231/0x5e0 mm/mmap.c:1458
[< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
[<ffffffff8124bf4b>] SyS_mmap+0x1b/0x30 arch/x86/kernel/sys_x86_64.c:86
[<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
^ permalink raw reply
* net: GPF in rt6_get_cookie
From: Dmitry Vyukov @ 2016-11-26 16:23 UTC (permalink / raw)
To: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, LKML, Eric Dumazet
Cc: syzkaller
Hello,
I got several GPFs in rt6_get_cookie while running syzkaller:
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 2 PID: 10156 Comm: syz-executor Not tainted 4.9.0-rc5+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880016f40480 task.stack: ffff88000fc00000
RIP: 0010:[<ffffffff87a209e8>] [< inline >] rt6_get_cookie
include/net/ip6_fib.h:174
RIP: 0010:[<ffffffff87a209e8>] [<ffffffff87a209e8>]
sctp_v6_get_dst+0x7c8/0x1960 net/sctp/ipv6.c:340
RSP: 0018:ffff88000fc07298 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc900029f5000
RDX: 0000000000000015 RSI: 0000000000000001 RDI: 00000000000000a8
RBP: ffff88000fc07580 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880066cd0068
R13: 1ffff10001f80e92 R14: ffff880066cd0040 R15: ffff88005f2d2808
FS: 00007f52c41f7700(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020016000 CR3: 0000000065dd7000 CR4: 00000000000006e0
DR0: 0000000000000400 DR1: 0000000000000400 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Stack:
ffffffff87a210f6 ffffffff8701ad45 ffff88006768ec20 ffff88006768ec20
0000000000000000 0000000016f40480 ffff88000fc07450 1ffff1000cd9a017
ffff88006768ec00 ffff880066fc0730 ffff880066cd0068 1ffff10001f80e66
Call Trace:
[<ffffffff879a313d>] sctp_transport_route+0xad/0x430 net/sctp/transport.c:279
[<ffffffff8799b106>] sctp_assoc_add_peer+0x5a6/0x13e0 net/sctp/associola.c:641
[<ffffffff879e8911>] sctp_sendmsg+0x1921/0x3bc0 net/sctp/socket.c:1864
[<ffffffff8701ad45>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff86a6d54f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
[<ffffffff86a6ede0>] SYSC_sendto+0x660/0x810 net/socket.c:1656
[<ffffffff86a71dd5>] SyS_sendto+0x45/0x60 net/socket.c:1624
[<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
Code: 00 00 48 8b 84 24 88 00 00 00 48 8b 58 40 e8 80 76 cc f9 48 8d
bb a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 56 0f 00 00 48 8b 9b a8 00 00 00 45 31 ed 48
RIP [< inline >] rt6_get_cookie include/net/ip6_fib.h:174
RIP [<ffffffff87a209e8>] sctp_v6_get_dst+0x7c8/0x1960 net/sctp/ipv6.c:340
RSP <ffff88000fc07298>
---[ end trace b8d1354fa571700d ]---
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 3 PID: 22744 Comm: syz-executor Not tainted 4.9.0-rc5+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006b92a840 task.stack: ffff88006a730000
RIP: 0010:[<ffffffff87a209e8>] [< inline >] rt6_get_cookie
include/net/ip6_fib.h:174
RIP: 0010:[<ffffffff87a209e8>] [<ffffffff87a209e8>]
sctp_v6_get_dst+0x7c8/0x1960 net/sctp/ipv6.c:340
RSP: 0018:ffff88006a736b88 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90003c4f000
RDX: 0000000000000015 RSI: 0000000000000001 RDI: 00000000000000a8
RBP: ffff88006a736e68 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880064cff268
R13: 1ffff1000d4e6db0 R14: ffff880064cff240 R15: ffff88006a4b6808
FS: 00007f74f4ec9700(0000) GS:ffff88006d100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002070effc CR3: 000000003bd2f000 CR4: 00000000000006e0
DR0: 0000000000000400 DR1: 0000000000000400 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Stack:
ffffffff87a210f6 ffffffff000bbd2d ffff88006c2cd5a0 ffff88006c2cd5a0
0000000000000000 000000006ccb46c0 ffff88006a736d40 1ffff1000c99fe57
ffff88006c2cd500 ffff8800658b1f30 ffff880064cff268 1ffff1000d4e6d84
Call Trace:
[<ffffffff879a313d>] sctp_transport_route+0xad/0x430 net/sctp/transport.c:279
[<ffffffff8799b106>] sctp_assoc_add_peer+0x5a6/0x13e0 net/sctp/associola.c:641
[<ffffffff879e4358>] __sctp_connect+0x288/0xc90 net/sctp/socket.c:1178
[<ffffffff879e4f0b>] __sctp_setsockopt_connectx+0x1ab/0x200
net/sctp/socket.c:1332
[< inline >] sctp_getsockopt_connectx3 net/sctp/socket.c:1417
[<ffffffff879fd2bd>] sctp_getsockopt+0x36ed/0x6800 net/sctp/socket.c:6474
[<ffffffff86a76c0a>] sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2649
[< inline >] SYSC_getsockopt net/socket.c:1788
[<ffffffff86a724d7>] SyS_getsockopt+0x257/0x390 net/socket.c:1770
[<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
Code: 00 00 48 8b 84 24 88 00 00 00 48 8b 58 40 e8 80 76 cc f9 48 8d
bb a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 56 0f 00 00 48 8b 9b a8 00 00 00 45 31 ed 48
RIP [< inline >] rt6_get_cookie include/net/ip6_fib.h:174
RIP [<ffffffff87a209e8>] sctp_v6_get_dst+0x7c8/0x1960 net/sctp/ipv6.c:340
RSP <ffff88006a736b88>
---[ end trace f42d1c14cb6d2835 ]---
This happened on commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (Nov 13).
Unfortunately this is not reproducible.
The line is:
return rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
Can it be a data race? rt->rt6i_node != NULL, but the next moment it
is already NULL? That would explain the crash and non-reproducibility
(need ThreadSanitizer!).
This always happened when called from sctp code, but I don't know if
it is relevant or not. It happened only 3 times.
Thanks.
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Eric Dumazet @ 2016-11-26 16:17 UTC (permalink / raw)
To: Dmitry Vyukov, Richard Guy Briggs
Cc: David Miller, Johannes Berg, Florian Westphal, Cong Wang,
Herbert Xu, netdev, LKML, syzkaller
In-Reply-To: <CACT4Y+aG1+91U1PWMTwpE_6vbEuqG7CdLCM1H=3WVJWtz=F7Ug@mail.gmail.com>
CC Richard Guy Briggs <rgb@redhat.com>
On Sat, Nov 26, 2016 at 7:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program triggers GPF in sock_sndtimeo:
> https://gist.githubusercontent.com/dvyukov/c19cadd309791cf5cb9b2bf936d3f48d/raw/1743ba0211079a5465d039512b427bc6b59b1a76/gistfile1.txt
>
> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 19950 Comm: syz-executor Not tainted 4.9.0-rc5+ #54
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff88002a0d0840 task.stack: ffff880036920000
> RIP: 0010:[<ffffffff86cb35e1>] [< inline >] sock_sndtimeo
> include/net/sock.h:2075
> RIP: 0010:[<ffffffff86cb35e1>] [<ffffffff86cb35e1>]
> netlink_unicast+0xe1/0x730 net/netlink/af_netlink.c:1232
> RSP: 0018:ffff880036926f68 EFLAGS: 00010202
> RAX: 0000000000000068 RBX: ffff880036927000 RCX: ffffc900021d0000
> RDX: 0000000000000d63 RSI: 00000000024000c0 RDI: 0000000000000340
> RBP: ffff880036927028 R08: ffffed0006ea7aab R09: ffffed0006ea7aab
> R10: 0000000000000001 R11: ffffed0006ea7aaa R12: dffffc0000000000
> R13: 0000000000000000 R14: ffff880035de3400 R15: ffff880035de3400
> FS: 00007f90a2fc7700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000006de0c0 CR3: 0000000035de6000 CR4: 00000000000006e0
> Stack:
> ffff880035de3400 ffffffff819f02a1 1ffff10006d24df4 0000000000000004
> 00004db400000014 ffff880036926fd8 ffffffff00000000 0000000041b58ab3
> ffffffff89653c11 ffffffff86cb3500 ffffffff819f0345 ffff880035de3400
> Call Trace:
> [< inline >] audit_replace kernel/audit.c:817
> [<ffffffff816c34b9>] audit_receive_msg+0x22c9/0x2ce0 kernel/audit.c:894
> [< inline >] audit_receive_skb kernel/audit.c:1120
> [<ffffffff816c40ac>] audit_receive+0x1dc/0x360 kernel/audit.c:1133
> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
> [<ffffffff86cb3a14>] netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1240
> [<ffffffff86cb46d4>] netlink_sendmsg+0xaa4/0xe50 net/netlink/af_netlink.c:1786
> [< inline >] sock_sendmsg_nosec net/socket.c:621
> [<ffffffff86a6d54f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
> [<ffffffff86a6d8bb>] sock_write_iter+0x32b/0x620 net/socket.c:829
> [< inline >] new_sync_write fs/read_write.c:499
> [<ffffffff81a6f24e>] __vfs_write+0x4fe/0x830 fs/read_write.c:512
> [<ffffffff81a70cf5>] vfs_write+0x175/0x4e0 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<ffffffff81a75180>] SyS_write+0x100/0x240 fs/read_write.c:599
> [<ffffffff81009a24>] do_syscall_64+0x2f4/0x940 arch/x86/entry/common.c:280
> [<ffffffff88149e8d>] entry_SYSCALL64_slow_path+0x25/0x25
> Code: fe 4c 89 f7 e8 31 16 ff ff 8b 8d 70 ff ff ff 49 89 c7 31 c0 85
> c9 75 25 e8 7d 4a a3 fa 49 8d bd 40 03 00 00 48 89 f8 48 c1 e8 03 <42>
> 80 3c 20 00 0f 85 3a 06 00 00 49 8b 85 40 03 00 00 4c 8d 73
> RIP [< inline >] sock_sndtimeo include/net/sock.h:2075
> RIP [<ffffffff86cb35e1>] netlink_unicast+0xe1/0x730
> net/netlink/af_netlink.c:1232
> RSP <ffff880036926f68>
> ---[ end trace 8383a15fba6fdc59 ]---
Looks a bug added in commit 32a1dbaece7e37cea415e03cd426172249aa859e
("audit: try harder to send to auditd upon netlink failure")
or 133e1e5acd4a63c4a0dcc413e90d5decdbce9c4a ("audit: stop an old
auditd being starved out by a new auditd")
Richard, can you take a look ?
Thanks !
^ permalink raw reply
* Re: [PATCH v3 net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Rami Rosen @ 2016-11-26 15:48 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: devel, andrew, gregkh, linux-kernel@vger.kernel.org, liodot,
Netdev, David Miller
In-Reply-To: <1480162850-8014-2-git-send-email-LinoSanfilippo@gmx.de>
Hi, Lino,
...
> @@ -0,0 +1,28 @@
> +config NET_VENDOR_ALACRITECH
> + bool "Alacritech devices"
> + default y
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
Shouldn't it be "Alacritech devices" here, as appears earlier ?
> + the questions about Renesas devices. If you say Y, you will be asked
> + for your specific device in the following questions.
> +
...
...
...
> +struct slic_device {
> + struct pci_dev *pdev;
...
> + bool promisc;
Seems that the autoneg boolean is not used anywhere, apart from
setting it once to true in
the slic_set_link_autoneg() method. Apart from this member it is not
accessed anywhere, so it seems it should be removed.
> + bool autoneg;
> + int speed;
...
...
> +static int slic_load_rcvseq_firmware(struct slic_device *sdev)
> +{
> + const struct firmware *fw;
> + const char *file;
> + u32 codelen;
> + int idx = 0;
> + u32 instr;
> + u32 addr;
> + int err;
> +
...
> + /* Do an initial sanity check concerning firmware size now. A further
> + * check follows below.
> + */
> + if (fw->size < SLIC_FIRMWARE_MIN_SIZE) {
> + dev_err(&sdev->pdev->dev,
> + "invalid firmware size %zu (min %u expected)\n",
> + fw->size, SLIC_FIRMWARE_MIN_SIZE);
> + err = -EINVAL;
in the release label, always 0 is returned:
> + goto release;
> + }
> +
> + codelen = slic_read_dword_from_firmware(fw, &idx);
> +
> + /* do another sanity check against firmware size */
> + if ((codelen + 4) > fw->size) {
> + dev_err(&sdev->pdev->dev,
> + "invalid rcv-sequencer firmware size %zu\n", fw->size);
> + err = -EINVAL;
Again, in the release label, always 0 is returned:
> + goto release;
> + }
> +
>
> +release:
> + release_firmware(fw);
> +
> + return 0;
> +}
> +
Regards,
Rami Rosen
^ 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