* KASAN: out-of-bounds Read in rds_cong_queue_updates (2)
From: syzbot @ 2018-06-13 7:51 UTC (permalink / raw)
To: davem, linux-kernel, linux-rdma, netdev, rds-devel,
santosh.shilimkar, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 0adb32858b0b Linux 4.16
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=138f2d0b800000
kernel config: https://syzkaller.appspot.com/x/.config?x=df0c336cc3b55d45
dashboard link: https://syzkaller.appspot.com/bug?extid=287843ad8a4d2870e538
compiler: gcc (GCC) 7.1.1 20170620
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+287843ad8a4d2870e538@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: out-of-bounds in __read_once_size include/linux/compiler.h:188
[inline]
BUG: KASAN: out-of-bounds in atomic_read arch/x86/include/asm/atomic.h:27
[inline]
BUG: KASAN: out-of-bounds in refcount_read include/linux/refcount.h:42
[inline]
BUG: KASAN: out-of-bounds in check_net include/net/net_namespace.h:228
[inline]
BUG: KASAN: out-of-bounds in rds_destroy_pending net/rds/rds.h:868 [inline]
BUG: KASAN: out-of-bounds in rds_cong_queue_updates+0x4d3/0x4f0
net/rds/cong.c:226
Read of size 4 at addr ffff88018d7f2204 by task kworker/u4:6/10561
CPU: 1 PID: 10561 Comm: kworker/u4:6 Not tainted 4.16.0+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
kernel msg: ebtables bug: please report to author: Wrong len argument
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23c/0x360 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
__read_once_size include/linux/compiler.h:188 [inline]
atomic_read arch/x86/include/asm/atomic.h:27 [inline]
refcount_read include/linux/refcount.h:42 [inline]
check_net include/net/net_namespace.h:228 [inline]
rds_destroy_pending net/rds/rds.h:868 [inline]
rds_cong_queue_updates+0x4d3/0x4f0 net/rds/cong.c:226
rds_recv_rcvbuf_delta.part.2+0x289/0x320 net/rds/recv.c:118
rds_recv_rcvbuf_delta net/rds/recv.c:377 [inline]
rds_recv_incoming+0xeb4/0x11d0 net/rds/recv.c:377
rds_loop_xmit+0x149/0x320 net/rds/loop.c:82
rds_send_xmit+0xbcd/0x26b0 net/rds/send.c:355
rds_send_worker+0x115/0x2a0 net/rds/threads.c:199
process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
worker_thread+0x223/0x1990 kernel/workqueue.c:2247
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
The buggy address belongs to the page:
page:ffffea000635fc80 count:3 mapcount:2 mapping:0000000000000000 index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 0000000000000000 0000000300000001
raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88018d7f2100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88018d7f2180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88018d7f2200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
ffff88018d7f2280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88018d7f2300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 10561 Comm: kworker/u4:6 Tainted: G B 4.16.0+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
kasan_end_report+0x50/0x50 mm/kasan/report.c:180
kasan_report_error mm/kasan/report.c:359 [inline]
kasan_report+0x149/0x360 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
__read_once_size include/linux/compiler.h:188 [inline]
atomic_read arch/x86/include/asm/atomic.h:27 [inline]
refcount_read include/linux/refcount.h:42 [inline]
check_net include/net/net_namespace.h:228 [inline]
rds_destroy_pending net/rds/rds.h:868 [inline]
rds_cong_queue_updates+0x4d3/0x4f0 net/rds/cong.c:226
rds_recv_rcvbuf_delta.part.2+0x289/0x320 net/rds/recv.c:118
rds_recv_rcvbuf_delta net/rds/recv.c:377 [inline]
rds_recv_incoming+0xeb4/0x11d0 net/rds/recv.c:377
rds_loop_xmit+0x149/0x320 net/rds/loop.c:82
rds_send_xmit+0xbcd/0x26b0 net/rds/send.c:355
rds_send_worker+0x115/0x2a0 net/rds/threads.c:199
process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
worker_thread+0x223/0x1990 kernel/workqueue.c:2247
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH 4/4] net: emaclite: Remove xemaclite_mdio_setup return check
From: Andrew Lunn @ 2018-06-13 7:29 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: davem, michal.simek, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-5-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:19PM +0530, Radhey Shyam Pandey wrote:
> Errors are already reported in xemaclite_mdio_setup so avoid
> reporting it again.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> index ec4608e..2a0c06e 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> @@ -1143,9 +1143,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
> xemaclite_update_address(lp, ndev->dev_addr);
>
> lp->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
> - rc = xemaclite_mdio_setup(lp, &ofdev->dev);
> - if (rc)
> - dev_warn(&ofdev->dev, "error registering MDIO bus\n");
> + xemaclite_mdio_setup(lp, &ofdev->dev);
>
> dev_info(dev, "MAC address is now %pM\n", ndev->dev_addr);
The patch itself is O.K.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
However, do you want to keep going if the MDIO bus fails? Maybe you
should failed the probe?
Andrew
^ permalink raw reply
* Re: [PATCH 3/4] net: emaclite: Remove unused 'has_mdio' flag.
From: Andrew Lunn @ 2018-06-13 7:23 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: davem, michal.simek, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-4-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:18PM +0530, Radhey Shyam Pandey wrote:
> Remove unused 'has_mdio' flag.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] net: emaclite: Fix MDIO bus unregister bug
From: Andrew Lunn @ 2018-06-13 7:23 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: davem, michal.simek, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-3-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:17PM +0530, Radhey Shyam Pandey wrote:
> Since 'has_mdio' flag is not used,sequence insmod->rmmod-> insmod
> leads to failure as MDIO unregister doesn't happen in .remove().
> Fix it by checking MII bus pointer instead.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/4] net: emaclite: Fix position of lp->mii_bus assignment
From: Andrew Lunn @ 2018-06-13 7:21 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: davem, michal.simek, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-2-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:16PM +0530, Radhey Shyam Pandey wrote:
> To ensure MDIO bus is not double freed in remove() path
> assign lp->mii_bus after MDIO bus registration.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 4/4] net: emaclite: Remove xemaclite_mdio_setup return check
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: davem, michal.simek, radhey.shyam.pandey
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Errors are already reported in xemaclite_mdio_setup so avoid
reporting it again.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index ec4608e..2a0c06e 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1143,9 +1143,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
xemaclite_update_address(lp, ndev->dev_addr);
lp->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
- rc = xemaclite_mdio_setup(lp, &ofdev->dev);
- if (rc)
- dev_warn(&ofdev->dev, "error registering MDIO bus\n");
+ xemaclite_mdio_setup(lp, &ofdev->dev);
dev_info(dev, "MAC address is now %pM\n", ndev->dev_addr);
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] net: emaclite: Remove unused 'has_mdio' flag.
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: davem, michal.simek, radhey.shyam.pandey
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Remove unused 'has_mdio' flag.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 06eb6c8..ec4608e 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -123,7 +123,6 @@
* @phy_node: pointer to the PHY device node
* @mii_bus: pointer to the MII bus
* @last_link: last link status
- * @has_mdio: indicates whether MDIO is included in the HW
*/
struct net_local {
@@ -144,7 +143,6 @@ struct net_local {
struct mii_bus *mii_bus;
int last_link;
- bool has_mdio;
};
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] net: emaclite: Fix MDIO bus unregister bug
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: davem, michal.simek, radhey.shyam.pandey
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Since 'has_mdio' flag is not used,sequence insmod->rmmod-> insmod
leads to failure as MDIO unregister doesn't happen in .remove().
Fix it by checking MII bus pointer instead.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 37989ce..06eb6c8 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1191,7 +1191,7 @@ static int xemaclite_of_remove(struct platform_device *of_dev)
struct net_local *lp = netdev_priv(ndev);
/* Un-register the mii_bus, if configured */
- if (lp->has_mdio) {
+ if (lp->mii_bus) {
mdiobus_unregister(lp->mii_bus);
mdiobus_free(lp->mii_bus);
lp->mii_bus = NULL;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/4] net: emaclite: Fix position of lp->mii_bus assignment
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: davem, michal.simek, radhey.shyam.pandey
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
To ensure MDIO bus is not double freed in remove() path
assign lp->mii_bus after MDIO bus registration.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 69e31ce..37989ce 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -863,14 +863,14 @@ static int xemaclite_mdio_setup(struct net_local *lp, struct device *dev)
bus->write = xemaclite_mdio_write;
bus->parent = dev;
- lp->mii_bus = bus;
-
rc = of_mdiobus_register(bus, np);
if (rc) {
dev_err(dev, "Failed to register mdio bus.\n");
goto err_register;
}
+ lp->mii_bus = bus;
+
return 0;
err_register:
--
1.7.1
^ permalink raw reply related
* [PATCH 0/4] emaclite bug fixes and code cleanup
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: davem, michal.simek, radhey.shyam.pandey
Cc: netdev, linux-arm-kernel, linux-kernel
This patch series fixes bug in emaclite remove and mdio_setup routines.
It does minor code cleanup.
Radhey Shyam Pandey (4):
net: emaclite: Fix position of lp->mii_bus assignment
net: emaclite: Fix MDIO bus unregister bug
net: emaclite: Remove unused 'has_mdio' flag.
net: emaclite: Remove xemaclite_mdio_setup return check
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH net] net/multicast: clean change record if add new INCLUDE group
From: Hangbin Liu @ 2018-06-13 6:32 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Paolo Abeni, Stefano Brivio, Daniel Borkmann,
WANG Cong, hideaki.yoshifuji, Hangbin Liu
Based on RFC3376 5.1 and RFC3810 6.1:
If no interface
state existed for that multicast address before the change (i.e., the
change consisted of creating a new per-interface record), or if no
state exists after the change (i.e., the change consisted of deleting
a per-interface record), then the "non-existent" state is considered
to have a filter mode of INCLUDE and an empty source list.
Which means a new multicast group should start with state IN(). That is
exactly what we did with ip_mc_join_group()/ipv6_sock_mc_join(), which
adds a group with state EX() and init crcount to mc_qrv. The kernel will
send a TO_EX() report message after adding group. This is what IGMPv3/MLDv2
ASM(Any-Source Multicast) mode should look like.
But for IGMPv3/MLDv2 SSM JOIN_SOURCE_GROUP mode, we split the group
joining into two steps. First step we join the group like ASM, i.e. via
ip_mc_join_group()/ipv6_sock_mc_join(). So the state changes from IN() to EX().
Then we add the Source-specific address with INCLUDE mode. So the state
changes from EX() to IN(A).
Before the first step sends a group change record, we finished the second step.
So we will only send the second change record. i.e. TO_IN(A)
Regarding the RFC stands, we should actually send an ALLOW(A) message for
SSM JOIN_SOURCE_GROUP as the state should mimic the 'IN() to IN(A)' transition.
The issue was exposed by commit a052517a8ff65 ("net/multicast: should not send
source list records when have filter mode change"). Before this commit we will
send both ALLOW(A) and TO_IN(A). After this commit we only send TO_IN(A).
Fix it by adding a is_new key to clean the crcount when we add a new
INCLUDE SSM group.
Fixes: a052517a8ff65 ("net/multicast: should not send source list records when have filter mode change")
Reviewed-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
include/linux/igmp.h | 2 +-
include/net/ipv6.h | 2 +-
net/ipv4/igmp.c | 27 ++++++++++++++++++++++++++-
net/ipv4/ip_sockglue.c | 8 ++++++--
net/ipv6/ipv6_sockglue.c | 4 +++-
net/ipv6/mcast.c | 25 ++++++++++++++++++++++++-
6 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index f823185..32cb02b 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -112,7 +112,7 @@ extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
extern void ip_mc_drop_socket(struct sock *sk);
extern int ip_mc_source(int add, int omode, struct sock *sk,
- struct ip_mreq_source *mreqs, int ifindex);
+ struct ip_mreq_source *mreqs, int ifindex, bool is_new);
extern int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf,int ifindex);
extern int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
struct ip_msfilter __user *optval, int __user *optlen);
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 836f31a..754c5cb 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -1065,7 +1065,7 @@ struct group_source_req;
struct group_filter;
int ip6_mc_source(int add, int omode, struct sock *sk,
- struct group_source_req *pgsr);
+ struct group_source_req *pgsr, bool is_new);
int ip6_mc_msfilter(struct sock *sk, struct group_filter *gsf);
int ip6_mc_msfget(struct sock *sk, struct group_filter *gsf,
struct group_filter __user *optval, int __user *optlen);
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b26a81a..8d6ecc3 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -2249,8 +2249,27 @@ int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr)
}
EXPORT_SYMBOL(ip_mc_leave_group);
+static void ip_mc_clear_cr(struct in_device *in_dev, __be32 pmca)
+{
+#ifdef CONFIG_IP_MULTICAST
+ struct ip_mc_list *pmc;
+
+ rcu_read_lock();
+ for_each_pmc_rcu(in_dev, pmc) {
+ if (pmca == pmc->multiaddr)
+ break;
+ }
+ if (pmc) {
+ spin_lock_bh(&pmc->lock);
+ pmc->crcount = 0;
+ spin_unlock_bh(&pmc->lock);
+ }
+ rcu_read_unlock();
+#endif
+}
+
int ip_mc_source(int add, int omode, struct sock *sk, struct
- ip_mreq_source *mreqs, int ifindex)
+ ip_mreq_source *mreqs, int ifindex, bool is_new)
{
int err;
struct ip_mreqn imr;
@@ -2301,6 +2320,12 @@ int ip_mc_source(int add, int omode, struct sock *sk, struct
ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
NULL, 0);
pmc->sfmode = omode;
+ /* Based on RFC3376 5.1, for newly added INCLUDE SSM, we should
+ * not send filter-mode change record as the mode should be
+ * from IN() to IN(A).
+ */
+ if (is_new)
+ ip_mc_clear_cr(in_dev, mreqs->imr_multiaddr);
}
psl = rtnl_dereference(pmc->sflist);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 57bbb06..8d8c0cd 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -962,6 +962,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
case IP_DROP_SOURCE_MEMBERSHIP:
{
struct ip_mreq_source mreqs;
+ bool is_new = false;
int omode, add;
if (optlen != sizeof(struct ip_mreq_source))
@@ -987,11 +988,12 @@ static int do_ip_setsockopt(struct sock *sk, int level,
break;
omode = MCAST_INCLUDE;
add = 1;
+ is_new = true;
} else /* IP_DROP_SOURCE_MEMBERSHIP */ {
omode = MCAST_INCLUDE;
add = 0;
}
- err = ip_mc_source(add, omode, sk, &mreqs, 0);
+ err = ip_mc_source(add, omode, sk, &mreqs, 0, is_new);
break;
}
case MCAST_JOIN_GROUP:
@@ -1027,6 +1029,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
struct group_source_req greqs;
struct ip_mreq_source mreqs;
struct sockaddr_in *psin;
+ bool is_new = false;
int omode, add;
if (optlen != sizeof(struct group_source_req))
@@ -1065,12 +1068,13 @@ static int do_ip_setsockopt(struct sock *sk, int level,
greqs.gsr_interface = mreq.imr_ifindex;
omode = MCAST_INCLUDE;
add = 1;
+ is_new = true;
} else /* MCAST_LEAVE_SOURCE_GROUP */ {
omode = MCAST_INCLUDE;
add = 0;
}
err = ip_mc_source(add, omode, sk, &mreqs,
- greqs.gsr_interface);
+ greqs.gsr_interface, is_new);
break;
}
case MCAST_MSFILTER:
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4d780c7..36e7c40 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -695,6 +695,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
case MCAST_UNBLOCK_SOURCE:
{
struct group_source_req greqs;
+ bool is_new = false;
int omode, add;
if (optlen < sizeof(struct group_source_req))
@@ -725,11 +726,12 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
break;
omode = MCAST_INCLUDE;
add = 1;
+ is_new = true;
} else /* MCAST_LEAVE_SOURCE_GROUP */ {
omode = MCAST_INCLUDE;
add = 0;
}
- retv = ip6_mc_source(add, omode, sk, &greqs);
+ retv = ip6_mc_source(add, omode, sk, &greqs, is_new);
break;
}
case MCAST_MSFILTER:
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 793159d..f508a1c 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -315,8 +315,25 @@ void ipv6_sock_mc_close(struct sock *sk)
rtnl_unlock();
}
+static void ip6_mc_clear_cr(struct inet6_dev *idev, const struct in6_addr *pmca)
+{
+ struct ifmcaddr6 *pmc;
+
+ read_lock_bh(&idev->lock);
+ for (pmc = idev->mc_list; pmc; pmc = pmc->next) {
+ if (ipv6_addr_equal(pmca, &pmc->mca_addr))
+ break;
+ }
+ if (pmc) {
+ spin_lock_bh(&pmc->mca_lock);
+ pmc->mca_crcount = 0;
+ spin_unlock_bh(&pmc->mca_lock);
+ }
+ read_unlock_bh(&idev->lock);
+}
+
int ip6_mc_source(int add, int omode, struct sock *sk,
- struct group_source_req *pgsr)
+ struct group_source_req *pgsr, bool is_new)
{
struct in6_addr *source, *group;
struct ipv6_mc_socklist *pmc;
@@ -365,6 +382,12 @@ int ip6_mc_source(int add, int omode, struct sock *sk,
ip6_mc_add_src(idev, group, omode, 0, NULL, 0);
ip6_mc_del_src(idev, group, pmc->sfmode, 0, NULL, 0);
pmc->sfmode = omode;
+ /* Based on RFC3810 6.1, for newly added INCLUDE SSM, we
+ * should not send filter-mode change record as the mode
+ * should be from IN() to IN(A).
+ */
+ if (is_new)
+ ip6_mc_clear_cr(idev, group);
}
write_lock(&pmc->sflock);
--
2.5.5
^ permalink raw reply related
* Re: [PATCH 03/18] rhashtable: remove nulls_base and related code.
From: Herbert Xu @ 2018-06-13 6:25 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Graf, netdev, linux-kernel
In-Reply-To: <87vaavmhuk.fsf@notabene.neil.brown.name>
On Thu, Jun 07, 2018 at 12:49:07PM +1000, NeilBrown wrote:
> On Fri, Jun 01 2018, NeilBrown wrote:
>
> > This "feature" is unused, undocumented, and untested and so
> > doesn't really belong. Next patch will introduce support
> > to detect when a search gets diverted down a different chain,
> > which the common purpose of nulls markers.
> >
> > This patch actually fixes a bug too. The table resizing allows a
> > table to grow to 2^31 buckets, but the hash is truncated to 27 bits -
> > any growth beyond 2^27 is wasteful an ineffective.
> >
> > This patch results in NULLS_MARKER(0) being used for all chains,
> > and leaves the use of rht_is_a_null() to test for it.
> >
> > Signed-off-by: NeilBrown <neilb@suse.com>
>
> Hi Herbert,
> You've acked a few patches that depends on this one, but not this
> patch itself. If you could ack this one, I could submit a collection
> of patches for inclusion (after the merge window closes I guess)
> and then have fewer outstanding.
> This assumes you are in-principle happy with the alternative approach I
> took to handling list-nulls. I got the impression that it was only
> some small details holding that back.
You can add my ack to this patch:
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/2] WAN: LMC: ensure lmc_trace is reporting return from lmc_proto_type
From: Colin King @ 2018-06-13 6:04 UTC (permalink / raw)
To: David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180613060410.735-1-colin.king@canonical.com>
From: Colin Ian King <colin.king@canonical.com>
Currently the lmc tracing is not reporting the return from function
lmc_proto_type and this tracing statement is never executed. Fix
this by returning through the end of the function. Also fix a typo
in the function name lmc_proto_type in the trace message.
Detected by CoverityScan, CID#710539 ("Structurally dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/lmc/lmc_proto.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wan/lmc/lmc_proto.c b/drivers/net/wan/lmc/lmc_proto.c
index 5a6c87bce1bf..b98c1ee860de 100644
--- a/drivers/net/wan/lmc/lmc_proto.c
+++ b/drivers/net/wan/lmc/lmc_proto.c
@@ -99,23 +99,27 @@ void lmc_proto_close(lmc_softc_t *sc)
__be16 lmc_proto_type(lmc_softc_t *sc, struct sk_buff *skb) /*FOLD00*/
{
+ __be16 ret;
+
lmc_trace(sc->lmc_device, "lmc_proto_type in");
switch (sc->if_type) {
case LMC_PPP:
- return hdlc_type_trans(skb, sc->lmc_device);
+ ret = hdlc_type_trans(skb, sc->lmc_device);
break;
case LMC_NET:
- return htons(ETH_P_802_2);
+ ret = htons(ETH_P_802_2);
break;
case LMC_RAW: /* Packet type for skbuff kind of useless */
- return htons(ETH_P_802_2);
+ ret = htons(ETH_P_802_2);
break;
default:
printk(KERN_WARNING "%s: No protocol set for this interface, assuming 802.2 (which is wrong!!)\n", sc->name);
- return htons(ETH_P_802_2);
+ ret = htons(ETH_P_802_2);
break;
}
- lmc_trace(sc->lmc_device, "lmc_proto_tye out");
+ lmc_trace(sc->lmc_device, "lmc_proto_type out");
+
+ return ret;
}
void lmc_proto_netif(lmc_softc_t *sc, struct sk_buff *skb) /*FOLD00*/
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] WAN: LMC: fix up indentations with tabs
From: Colin King @ 2018-06-13 6:04 UTC (permalink / raw)
To: David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently this source is using a mix of 4 char spaces and tabs
for indentations. Clean this up to consistently use tabs. Also
add some white spaces in switch statements.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/lmc/lmc_proto.c | 79 ++++++++++++++++-----------------
1 file changed, 39 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wan/lmc/lmc_proto.c b/drivers/net/wan/lmc/lmc_proto.c
index f600075e84a2..5a6c87bce1bf 100644
--- a/drivers/net/wan/lmc/lmc_proto.c
+++ b/drivers/net/wan/lmc/lmc_proto.c
@@ -49,17 +49,17 @@
// attach
void lmc_proto_attach(lmc_softc_t *sc) /*FOLD00*/
{
- lmc_trace(sc->lmc_device, "lmc_proto_attach in");
- if (sc->if_type == LMC_NET) {
- struct net_device *dev = sc->lmc_device;
- /*
- * They set a few basics because they don't use HDLC
- */
- dev->flags |= IFF_POINTOPOINT;
- dev->hard_header_len = 0;
- dev->addr_len = 0;
- }
- lmc_trace(sc->lmc_device, "lmc_proto_attach out");
+ lmc_trace(sc->lmc_device, "lmc_proto_attach in");
+ if (sc->if_type == LMC_NET) {
+ struct net_device *dev = sc->lmc_device;
+ /*
+ * They set a few basics because they don't use HDLC
+ */
+ dev->flags |= IFF_POINTOPOINT;
+ dev->hard_header_len = 0;
+ dev->addr_len = 0;
+ }
+ lmc_trace(sc->lmc_device, "lmc_proto_attach out");
}
int lmc_proto_ioctl(lmc_softc_t *sc, struct ifreq *ifr, int cmd)
@@ -99,37 +99,36 @@ void lmc_proto_close(lmc_softc_t *sc)
__be16 lmc_proto_type(lmc_softc_t *sc, struct sk_buff *skb) /*FOLD00*/
{
- lmc_trace(sc->lmc_device, "lmc_proto_type in");
- switch(sc->if_type){
- case LMC_PPP:
- return hdlc_type_trans(skb, sc->lmc_device);
- break;
- case LMC_NET:
- return htons(ETH_P_802_2);
- break;
- case LMC_RAW: /* Packet type for skbuff kind of useless */
- return htons(ETH_P_802_2);
- break;
- default:
- printk(KERN_WARNING "%s: No protocol set for this interface, assuming 802.2 (which is wrong!!)\n", sc->name);
- return htons(ETH_P_802_2);
- break;
- }
- lmc_trace(sc->lmc_device, "lmc_proto_tye out");
-
+ lmc_trace(sc->lmc_device, "lmc_proto_type in");
+ switch (sc->if_type) {
+ case LMC_PPP:
+ return hdlc_type_trans(skb, sc->lmc_device);
+ break;
+ case LMC_NET:
+ return htons(ETH_P_802_2);
+ break;
+ case LMC_RAW: /* Packet type for skbuff kind of useless */
+ return htons(ETH_P_802_2);
+ break;
+ default:
+ printk(KERN_WARNING "%s: No protocol set for this interface, assuming 802.2 (which is wrong!!)\n", sc->name);
+ return htons(ETH_P_802_2);
+ break;
+ }
+ lmc_trace(sc->lmc_device, "lmc_proto_tye out");
}
void lmc_proto_netif(lmc_softc_t *sc, struct sk_buff *skb) /*FOLD00*/
{
- lmc_trace(sc->lmc_device, "lmc_proto_netif in");
- switch(sc->if_type){
- case LMC_PPP:
- case LMC_NET:
- default:
- netif_rx(skb);
- break;
- case LMC_RAW:
- break;
- }
- lmc_trace(sc->lmc_device, "lmc_proto_netif out");
+ lmc_trace(sc->lmc_device, "lmc_proto_netif in");
+ switch (sc->if_type) {
+ case LMC_PPP:
+ case LMC_NET:
+ default:
+ netif_rx(skb);
+ break;
+ case LMC_RAW:
+ break;
+ }
+ lmc_trace(sc->lmc_device, "lmc_proto_netif out");
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v3] tcp: verify the checksum of the first data segment in a new connection
From: Balbir Singh @ 2018-06-13 5:10 UTC (permalink / raw)
To: Frank van der Linden; +Cc: edumazet, netdev
In-Reply-To: <5b2052b1.eyFJo5VnqmUbz/O6%fllinden@amazon.com>
On Wed, Jun 13, 2018 at 9:09 AM, Frank van der Linden
<fllinden@amazon.com> wrote:
> commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
> table") introduced an optimization for the handling of child sockets
> created for a new TCP connection.
>
> But this optimization passes any data associated with the last ACK of the
> connection handshake up the stack without verifying its checksum, because it
> calls tcp_child_process(), which in turn calls tcp_rcv_state_process()
> directly. These lower-level processing functions do not do any checksum
> verification.
>
> Insert a tcp_checksum_complete call in the TCP_NEW_SYN_RECEIVE path to
> fix this.
>
> Signed-off-by: Frank van der Linden <fllinden@amazon.com>
> ---
> net/ipv4/tcp_ipv4.c | 4 ++++
> net/ipv6/tcp_ipv6.c | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index f70586b..ef8cd0f 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1689,6 +1689,10 @@ int tcp_v4_rcv(struct sk_buff *skb)
> reqsk_put(req);
> goto discard_it;
> }
> + if (tcp_checksum_complete(skb)) {
> + reqsk_put(req);
> + goto csum_error;
> + }
> if (unlikely(sk->sk_state != TCP_LISTEN)) {
> inet_csk_reqsk_queue_drop_and_put(sk, req);
> goto lookup;
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index 6d664d8..5d4eb9d 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1475,6 +1475,10 @@ static int tcp_v6_rcv(struct sk_buff *skb)
> reqsk_put(req);
> goto discard_it;
> }
> + if (tcp_checksum_complete(skb)) {
> + reqsk_put(req);
> + goto csum_error;
> + }
> if (unlikely(sk->sk_state != TCP_LISTEN)) {
> inet_csk_reqsk_queue_drop_and_put(sk, req);
> goto lookup;
I've tested the IPv4 variant with some changes
Tested-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Balbir
^ permalink raw reply
* Re: [PATCH v2] tcp: verify the checksum of the first data segment in a new connection
From: Balbir Singh @ 2018-06-13 5:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Frank van der Linden, edumazet, netdev
In-Reply-To: <9541859a-1346-e13a-b97c-a2a63f3b19f4@gmail.com>
On Wed, Jun 13, 2018 at 7:50 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 06/12/2018 02:41 PM, Frank van der Linden wrote:
>> commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
>> table") introduced an optimization for the handling of child sockets
>> created for a new TCP connection.
>>
>> But this optimization passes any data associated with the last ACK of the
>> connection handshake up the stack without verifying its checksum, because it
>> calls tcp_child_process(), which in turn calls tcp_rcv_state_process()
>> directly. These lower-level processing functions do not do any checksum
>> verification.
>>
>> Insert a tcp_checksum_complete call in the TCP_NEW_SYN_RECEIVE path to
>> fix this.
>>
>> Signed-off-by: Frank van der Linden <fllinden@amazon.com>
>
>
> This is way too complicated.
>
> You should call tcp_checksum_complete() earlier and avoid all this mess.
>
>
> IPV4 part shown here :
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index fed3f1c6616708997f621535efe9412e4afa0a50..7b5f32aa3835b0124b0a9bd342c371df7b46f471 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1730,6 +1730,10 @@ int tcp_v4_rcv(struct sk_buff *skb)
> reqsk_put(req);
> goto discard_it;
> }
> + if (unlikely(tcp_checksum_complete(skb))) {
> + reqsk_put(req);
> + goto csum_error;
> + }
I like this variant, it is not under the sock_lock, but it skips
tcp_filter() as Frank pointed out.
I tested a variant of this patch with an increment of MIB/CSUM errors
and jump to discard_and_relse and it seemed to pass my testing
Balbir Singh.
^ permalink raw reply
* Re: [PATCH v3] tcp: verify the checksum of the first data segment in a new connection
From: Eric Dumazet @ 2018-06-13 4:45 UTC (permalink / raw)
To: Frank van der Linden, edumazet, netdev
In-Reply-To: <5b2052b1.eyFJo5VnqmUbz/O6%fllinden@amazon.com>
On 06/12/2018 04:09 PM, Frank van der Linden wrote:
> commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
> table") introduced an optimization for the handling of child sockets
> created for a new TCP connection.
>
> But this optimization passes any data associated with the last ACK of the
> connection handshake up the stack without verifying its checksum, because it
> calls tcp_child_process(), which in turn calls tcp_rcv_state_process()
> directly. These lower-level processing functions do not do any checksum
> verification.
>
> Insert a tcp_checksum_complete call in the TCP_NEW_SYN_RECEIVE path to
> fix this.
>
> Signed-off-by: Frank van der Linden <fllinden@amazon.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* [PATCH v1 net-next] stmmac: fix DMA channel hang in half-duplex mode
From: Bhadram Varka @ 2018-06-13 4:30 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu; +Cc: netdev, narayanr
HW does not support Half-duplex mode in multi-queue
scenario. Fix it by not advertising the Half-Duplex
mode if multi-queue enabled.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 11fb7c7..07e748c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -928,6 +928,7 @@ static void stmmac_check_pcs_mode(struct stmmac_priv *priv)
static int stmmac_init_phy(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
+ u32 tx_cnt = priv->plat->tx_queues_to_use;
struct phy_device *phydev;
char phy_id_fmt[MII_BUS_ID_SIZE + 3];
char bus_id[MII_BUS_ID_SIZE];
@@ -969,6 +970,15 @@ static int stmmac_init_phy(struct net_device *dev)
SUPPORTED_1000baseT_Full);
/*
+ * Half-duplex mode not supported with multiqueue
+ * half-duplex can only works with single queue
+ */
+ if (tx_cnt > 1)
+ phydev->supported &= ~(SUPPORTED_1000baseT_Half |
+ SUPPORTED_100baseT_Half |
+ SUPPORTED_10baseT_Half);
+
+ /*
* Broken HW is sometimes missing the pull-up resistor on the
* MDIO line, which results in reads to non-existent devices returning
* 0 rather than 0xffff. Catch this here and treat 0 as a non-existent
--
2.7.4
^ permalink raw reply related
* [PATCH net] neighbour: skip NTF_EXT_LEARNED entries during forced gc
From: Roopa Prabhu @ 2018-06-13 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Commit 9ce33e46531d ("neighbour: support for NTF_EXT_LEARNED flag")
added support for NTF_EXT_LEARNED for neighbour entries.
NTF_EXT_LEARNED entries are neigh entries managed by control
plane (eg: Ethernet VPN implementation in FRR routing suite).
Periodic gc already excludes these entries. This patch extends
it to forced gc which the earlier patch missed.
Fixes: 9ce33e46531d ("neighbour: support for NTF_EXT_LEARNED flag")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/core/neighbour.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index a7a9c3d..8e3fda9 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -119,13 +119,14 @@ unsigned long neigh_rand_reach_time(unsigned long base)
EXPORT_SYMBOL(neigh_rand_reach_time);
-static bool neigh_del(struct neighbour *n, __u8 state,
+static bool neigh_del(struct neighbour *n, __u8 state, __u8 flags,
struct neighbour __rcu **np, struct neigh_table *tbl)
{
bool retval = false;
write_lock(&n->lock);
- if (refcount_read(&n->refcnt) == 1 && !(n->nud_state & state)) {
+ if (refcount_read(&n->refcnt) == 1 && !(n->nud_state & state) &&
+ !(n->flags & flags)) {
struct neighbour *neigh;
neigh = rcu_dereference_protected(n->next,
@@ -157,7 +158,7 @@ bool neigh_remove_one(struct neighbour *ndel, struct neigh_table *tbl)
while ((n = rcu_dereference_protected(*np,
lockdep_is_held(&tbl->lock)))) {
if (n == ndel)
- return neigh_del(n, 0, np, tbl);
+ return neigh_del(n, 0, 0, np, tbl);
np = &n->next;
}
return false;
@@ -185,7 +186,8 @@ static int neigh_forced_gc(struct neigh_table *tbl)
* - nobody refers to it.
* - it is not permanent
*/
- if (neigh_del(n, NUD_PERMANENT, np, tbl)) {
+ if (neigh_del(n, NUD_PERMANENT, NTF_EXT_LEARNED, np,
+ tbl)) {
shrunk = 1;
continue;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH iproute2-next v2] ip-xfrm: Add support for OUTPUT_MARK
From: Stephen Hemminger @ 2018-06-13 4:24 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: Subash Abhinov Kasiviswanathan, netdev, David Ahern,
Steffen Klassert
In-Reply-To: <CAKD1Yr119qtuabrPL=MbVGeUgRykTeqCmjvCb1buAQU2yZCKjw@mail.gmail.com>
On Wed, 13 Jun 2018 12:14:53 +0900
Lorenzo Colitti <lorenzo@google.com> wrote:
> On Wed, Jun 13, 2018 at 3:48 AM Subash Abhinov Kasiviswanathan
> <subashab@codeaurora.org> wrote:
> >
> > src 192.168.1.1 dst 192.168.1.2
> > proto esp spi 0x00004321 reqid 0 mode tunnel
> > replay-window 0 flag af-unspec
> > mark 0x10000/0x3ffff
> > output-mark 0x20000
>
> Nit: I don't know what guarantees we provide (if any) that the output
> format of "ip xfrm state" does not change except to add new lines at
> the end. Personally, I feel that an app or script that depends on
> "auth-trunc" (or anything else, really) being on the line immediately
> after "mark" is brittle and should be fixed. This is particularly true
> since in general between the mark and the encryption there might be an
> auth-trunc line, or an auth line, or neither. As such, adding this
> line here seems OK to me.
Scripts should use json mode. If it ever gets added to xfrm output (hint).
^ permalink raw reply
* [iproute2 1/1] rdma: sync some IP headers with glibc
From: Hoang Le @ 2018-06-13 4:09 UTC (permalink / raw)
To: jon.maloy, maloy, ying.xue, netdev, tipc-discussion
In the commit 9a362cc71a45, new userspace header:
(i.e rdma/rdma_user_cm.h -> linux/in6.h)
is included before the kernel space header:
(i.e utils.h -> resolv.h -> netinet/in.h).
This leads to unsynchronous some IP headers and compiler got failure
with error: redefinition of some structs IP.
In this commit, just reorder this including to make them in-sync.
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
---
rdma/rdma.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/rdma/rdma.h b/rdma/rdma.h
index fcaf9e69e07c..d4b7ba1918b1 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -15,6 +15,7 @@
#include <string.h>
#include <errno.h>
#include <getopt.h>
+#include <netinet/in.h>
#include <libmnl/libmnl.h>
#include <rdma/rdma_netlink.h>
#include <rdma/rdma_user_cm.h>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH iproute2-next v2] ip-xfrm: Add support for OUTPUT_MARK
From: Lorenzo Colitti @ 2018-06-13 3:14 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: netdev, Stephen Hemminger, David Ahern, Steffen Klassert
In-Reply-To: <1528829293-23222-1-git-send-email-subashab@codeaurora.org>
On Wed, Jun 13, 2018 at 3:48 AM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> src 192.168.1.1 dst 192.168.1.2
> proto esp spi 0x00004321 reqid 0 mode tunnel
> replay-window 0 flag af-unspec
> mark 0x10000/0x3ffff
> output-mark 0x20000
Nit: I don't know what guarantees we provide (if any) that the output
format of "ip xfrm state" does not change except to add new lines at
the end. Personally, I feel that an app or script that depends on
"auth-trunc" (or anything else, really) being on the line immediately
after "mark" is brittle and should be fixed. This is particularly true
since in general between the mark and the encryption there might be an
auth-trunc line, or an auth line, or neither. As such, adding this
line here seems OK to me.
> @@ -61,6 +61,7 @@ static void usage(void)
> fprintf(stderr, " [ flag FLAG-LIST ] [ sel SELECTOR ] [ LIMIT-LIST ] [ encap ENCAP ]\n");
> fprintf(stderr, " [ coa ADDR[/PLEN] ] [ ctx CTX ] [ extra-flag EXTRA-FLAG-LIST ]\n");
> fprintf(stderr, " [ offload [dev DEV] dir DIR ]\n");
> + fprintf(stderr, " [ output-mark OUTPUT-MARK]\n");
Nit: I think you want a space between OUTPUT-MARK and ].
Other than that,
Acked-by: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [PATCH 2/2] r8169: Reinstate ASPM Support
From: Kai Heng Feng @ 2018-06-13 2:59 UTC (permalink / raw)
To: Heiner Kallweit
Cc: davem, ryankao, hayeswang, hau, romieu, bhelgaas, netdev,
linux-pci, linux-kernel
In-Reply-To: <30b033ec-2ac3-6470-be43-06044f87b81d@gmail.com>
Hi Heiner,
> On Jun 13, 2018, at 3:35 AM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 12.06.2018 11:57, Kai-Heng Feng wrote:
>> On newer Intel platforms, ASPM support in r8169 is the last missing
>> puzzle to let Package C-State achieves PC8. Without ASPM support, the
>> deepest Package C-State can hit is PC3.
>> PC8 can save additional ~3W in comparison with PC3 on my testing
>> platform.
> Maybe we should replace PC8 with "beyond PC3". My system
> (Haswell 2961Y) reaches 50% PC7 + 5% PC9 + 45% PC10 now.
> It never seems to use PC8.
My original wording are really mouthful. I'll update them in next version.
The platform in question is Coffee Lake. This patch should make systems
newer than Skylake to hit > PC3. Older systems may not see significant
change.
I'll also state these info in the next version.
>
>> The original patch is from Realtek.
> Please add a link to this original patch.
Realtek sent me the patch privately. Is it okay to upload the patch to
pastebin or gist?
Kai-Heng
>
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> ---
>> v2:
>> - Remove module parameter.
>> - Remove pci_disable_link_state().
>>
>> drivers/net/ethernet/realtek/r8169.c | 41 +++++++++++++++++++---------
>> 1 file changed, 28 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169.c
>> b/drivers/net/ethernet/realtek/r8169.c
>> index 9b55ce513a36..85f4e746b040 100644
>> --- a/drivers/net/ethernet/realtek/r8169.c
>> +++ b/drivers/net/ethernet/realtek/r8169.c
>> @@ -5289,6 +5289,18 @@ static void rtl_pcie_state_l2l3_enable(struct
>> rtl8169_private *tp, bool enable)
>> RTL_W8(tp, Config3, data);
>> }
>>
>> +static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private
>> *tp,
>> + bool enable)
>
> Do we need this hw_internal in the function name?
>
>> +{
>> + if (enable) {
>> + RTL_W8(tp, Config2, RTL_R8(tp, Config2) | ClkReqEn);
>> + RTL_W8(tp, Config5, RTL_R8(tp, Config5) | ASPM_en);
>> + } else {
>> + RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> + RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + }
>> +}
>> +
>> static void rtl_hw_start_8168bb(struct rtl8169_private *tp)
>> {
>> RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Beacon_en);
>> @@ -5645,9 +5657,9 @@ static void rtl_hw_start_8168g_1(struct
>> rtl8169_private *tp)
>> rtl_hw_start_8168g(tp);
>>
>> /* disable aspm and clock request before access ephy */
>> - RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> - RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + rtl_hw_internal_aspm_clkreq_enable(tp, false);
>> rtl_ephy_init(tp, e_info_8168g_1, ARRAY_SIZE(e_info_8168g_1));
>> + rtl_hw_internal_aspm_clkreq_enable(tp, true);
>> }
>>
>> static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
>> @@ -5680,9 +5692,9 @@ static void rtl_hw_start_8411_2(struct
>> rtl8169_private *tp)
>> rtl_hw_start_8168g(tp);
>>
>> /* disable aspm and clock request before access ephy */
>> - RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> - RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + rtl_hw_internal_aspm_clkreq_enable(tp, false);
>> rtl_ephy_init(tp, e_info_8411_2, ARRAY_SIZE(e_info_8411_2));
>> + rtl_hw_internal_aspm_clkreq_enable(tp, true);
>> }
>>
>> static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
>> @@ -5699,8 +5711,7 @@ static void rtl_hw_start_8168h_1(struct
>> rtl8169_private *tp)
>> };
>>
>> /* disable aspm and clock request before access ephy */
>> - RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> - RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + rtl_hw_internal_aspm_clkreq_enable(tp, false);
>> rtl_ephy_init(tp, e_info_8168h_1, ARRAY_SIZE(e_info_8168h_1));
>>
>> RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
>> @@ -5779,6 +5790,8 @@ static void rtl_hw_start_8168h_1(struct
>> rtl8169_private *tp)
>> r8168_mac_ocp_write(tp, 0xe63e, 0x0000);
>> r8168_mac_ocp_write(tp, 0xc094, 0x0000);
>> r8168_mac_ocp_write(tp, 0xc09e, 0x0000);
>> +
>> + rtl_hw_internal_aspm_clkreq_enable(tp, true);
>> }
>>
>> static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
>> @@ -5830,11 +5843,12 @@ static void rtl_hw_start_8168ep_1(struct
>> rtl8169_private *tp)
>> };
>>
>> /* disable aspm and clock request before access ephy */
>> - RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> - RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + rtl_hw_internal_aspm_clkreq_enable(tp, false);
>> rtl_ephy_init(tp, e_info_8168ep_1, ARRAY_SIZE(e_info_8168ep_1));
>>
>> rtl_hw_start_8168ep(tp);
>> +
>> + rtl_hw_internal_aspm_clkreq_enable(tp, true);
>> }
>>
>> static void rtl_hw_start_8168ep_2(struct rtl8169_private *tp)
>> @@ -5846,14 +5860,15 @@ static void rtl_hw_start_8168ep_2(struct
>> rtl8169_private *tp)
>> };
>>
>> /* disable aspm and clock request before access ephy */
>> - RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> - RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + rtl_hw_internal_aspm_clkreq_enable(tp, false);
>> rtl_ephy_init(tp, e_info_8168ep_2, ARRAY_SIZE(e_info_8168ep_2));
>>
>> rtl_hw_start_8168ep(tp);
>>
>> RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) & ~PFM_EN);
>> RTL_W8(tp, MISC_1, RTL_R8(tp, MISC_1) & ~PFM_D3COLD_EN);
>> +
>> + rtl_hw_internal_aspm_clkreq_enable(tp, true);
>> }
>>
>> static void rtl_hw_start_8168ep_3(struct rtl8169_private *tp)
>> @@ -5867,8 +5882,7 @@ static void rtl_hw_start_8168ep_3(struct
>> rtl8169_private *tp)
>> };
>>
>> /* disable aspm and clock request before access ephy */
>> - RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
>> - RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>> + rtl_hw_internal_aspm_clkreq_enable(tp, false);
>> rtl_ephy_init(tp, e_info_8168ep_3, ARRAY_SIZE(e_info_8168ep_3));
>>
>> rtl_hw_start_8168ep(tp);
>> @@ -5888,6 +5902,8 @@ static void rtl_hw_start_8168ep_3(struct
>> rtl8169_private *tp)
>> data = r8168_mac_ocp_read(tp, 0xe860);
>> data |= 0x0080;
>> r8168_mac_ocp_write(tp, 0xe860, data);
>> +
>> + rtl_hw_internal_aspm_clkreq_enable(tp, true);
>> }
>>
>> static void rtl_hw_start_8168(struct rtl8169_private *tp)
>> @@ -7646,7 +7662,6 @@ static int rtl_init_one(struct pci_dev *pdev,
>> const struct pci_device_id *ent)
>> mii->reg_num_mask = 0x1f;
>> mii->supports_gmii = cfg->has_gmii;
>>
>> -
>> /* enable device (incl. PCI PM wakeup and hotplug setup) */
>> rc = pcim_enable_device(pdev);
>> if (rc < 0) {
^ permalink raw reply
* Re: [PATCH 1/2] r8169: Don't disable ASPM in the driver
From: Kai Heng Feng @ 2018-06-13 2:52 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David Miller, Ryankao, Hayes Wang, Hau, romieu, bhelgaas,
Linux Netdev List, linux-pci, linux-kernel
In-Reply-To: <caa66d98-e5cc-8bcd-1052-cef4ff00c32d@gmail.com>
Hi Heiner,
> On Jun 13, 2018, at 3:30 AM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 12.06.2018 11:57, Kai-Heng Feng wrote:
>> Enable or disable ASPM should be done in PCI core instead of in the
>> device driver.
>>
>> Commit ba04c7c93bbc ("r8169: disable ASPM") uses
>> pci_disable_link_state() to disable ASPM. This is incorrect, if the
>> device really needs to disable ASPM, we should use a quirk in PCI core
>> to prevent the PCI core from setting ASPM altogether.
> I wouldn't call using pci_disable_link_state() in a driver incorrect
> (as it works), there is just a better way which is more in line with
> the PCI subsystem architecture.
Ok, I'll amend the commit log in next version.
>
>> Let's remove pci_disable_link_state() for now. Use PCI core quirks if
>> any regression happens.
> The vendor driver disables ASPM unconditionally for chip version 25
> (there it's METHOD_9), so I think ASPM support is broken in this chip
> version. I'll cook a PCI quirk.
I actually asked Ryankao about this. He said that variant is more then a
decades old and he can't find why it doesn't support ASPM.
Since METHOD_9 might be a platform issue instead, my intention was to
enable ASPM for all variants. If users hit any issue, then we can introduce
new PCI quirks.
>
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>
> Please note that netdev is closed currently. Once 4.18-RC1 is out it
> will be re-opened. Then please re-submit properly annotating PATCH
> with "net-next" (I've forgotten this often enough myself).
Will do for next version. Thanks!
Kai-Heng
>
>> ---
>> v2:
>> - Remove module parameter.
>> - Remove pci_disable_link_state().
>>
>> drivers/net/ethernet/realtek/r8169.c | 5 -----
>> 1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169.c
>> b/drivers/net/ethernet/realtek/r8169.c
>> index 75dfac0248f4..9b55ce513a36 100644
>> --- a/drivers/net/ethernet/realtek/r8169.c
>> +++ b/drivers/net/ethernet/realtek/r8169.c
>> @@ -25,7 +25,6 @@
>> #include <linux/dma-mapping.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/firmware.h>
>> -#include <linux/pci-aspm.h>
>> #include <linux/prefetch.h>
>> #include <linux/ipv6.h>
>> #include <net/ip6_checksum.h>
>> @@ -7647,10 +7646,6 @@ static int rtl_init_one(struct pci_dev *pdev,
>> const struct pci_device_id *ent)
>> mii->reg_num_mask = 0x1f;
>> mii->supports_gmii = cfg->has_gmii;
>>
>> - /* disable ASPM completely as that cause random device stop working
>> - * problems as well as full system hangs for some PCIe devices users */
>> - pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
>> - PCIE_LINK_STATE_CLKPM);
>>
>> /* enable device (incl. PCI PM wakeup and hotplug setup) */
>> rc = pcim_enable_device(pdev);
^ permalink raw reply
* Re: KASAN: use-after-free Read in rds_cong_queue_updates
From: syzbot @ 2018-06-13 2:51 UTC (permalink / raw)
To: davem, linux-kernel, linux-rdma, netdev, rds-devel,
santosh.shilimkar, syzkaller-bugs
In-Reply-To: <089e08e548431cd0f90565c9f4e5@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: f0dc7f9c6dd9 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1461f03f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=fa9c20c48788d1c1
dashboard link: https://syzkaller.appspot.com/bug?extid=4c20b3866171ce8441d2
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16cbfeaf800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=165227f7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
==================================================================
BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:42
[inline]
BUG: KASAN: use-after-free in check_net include/net/net_namespace.h:236
[inline]
BUG: KASAN: use-after-free in rds_destroy_pending net/rds/rds.h:897 [inline]
BUG: KASAN: use-after-free in rds_cong_queue_updates+0x255/0x590
net/rds/cong.c:226
Read of size 4 at addr ffff8801ab180044 by task syz-executor199/4800
CPU: 1 PID: 4800 Comm: syz-executor199 Not tainted 4.17.0+ #84
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
refcount_read include/linux/refcount.h:42 [inline]
check_net include/net/net_namespace.h:236 [inline]
rds_destroy_pending net/rds/rds.h:897 [inline]
rds_cong_queue_updates+0x255/0x590 net/rds/cong.c:226
rds_recv_rcvbuf_delta.part.3+0x211/0x350 net/rds/recv.c:126
rds_recv_rcvbuf_delta net/rds/recv.c:735 [inline]
rds_clear_recv_queue+0x2f0/0x4c0 net/rds/recv.c:735
rds_release+0x15c/0x550 net/rds/af_rds.c:72
__sock_release+0xd7/0x260 net/socket.c:603
sock_close+0x19/0x20 net/socket.c:1186
__fput+0x353/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2468
do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x2cf/0x360 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44f439
Code: e8 ac be 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 5b ff fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fc65567dcf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00000000006edadc RCX: 000000000044f439
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006edadc
RBP: 00000000006edad8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff3df31b1f R14: 00007fc65567e9c0 R15: 0000000000000061
Allocated by task 4800:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
kmem_cache_zalloc include/linux/slab.h:696 [inline]
net_alloc net/core/net_namespace.c:383 [inline]
copy_net_ns+0x159/0x4c0 net/core/net_namespace.c:423
create_new_namespaces+0x69d/0x8f0 kernel/nsproxy.c:107
unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:206
ksys_unshare+0x708/0xf90 kernel/fork.c:2411
__do_sys_unshare kernel/fork.c:2479 [inline]
__se_sys_unshare kernel/fork.c:2477 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:2477
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 746:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
net_free net/core/net_namespace.c:399 [inline]
net_drop_ns.part.14+0x11a/0x130 net/core/net_namespace.c:406
net_drop_ns net/core/net_namespace.c:405 [inline]
cleanup_net+0x6a1/0xb20 net/core/net_namespace.c:541
process_one_work+0xc64/0x1b70 kernel/workqueue.c:2153
worker_thread+0x181/0x13a0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff8801ab180040
which belongs to the cache net_namespace(17:syz0) of size 8896
The buggy address is located 4 bytes inside of
8896-byte region [ffff8801ab180040, ffff8801ab182300)
The buggy address belongs to the page:
page:ffffea0006ac6000 count:1 mapcount:0 mapping:ffff8801aeaa0080 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff8801d3827048 ffff8801d3827048 ffff8801aeaa0080
raw: 0000000000000000 ffff8801ab180040 0000000100000001 ffff8801ab7cae40
page dumped because: kasan: bad access detected
page->mem_cgroup:ffff8801ab7cae40
Memory state around the buggy address:
ffff8801ab17ff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8801ab17ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801ab180000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801ab180080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801ab180100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ 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