* Re: AF_VSOCK unimplemented sockopts
From: Stefan Hajnoczi @ 2017-08-15 8:36 UTC (permalink / raw)
To: Jorgen S. Hansen; +Cc: netdev@vger.kernel.org
In-Reply-To: <9D465B5B-5A07-4250-8AB3-DEC80CCC45B7@vmware.com>
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
On Fri, Aug 11, 2017 at 09:23:17AM +0000, Jorgen S. Hansen wrote:
> > On Aug 3, 2017, at 12:41 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > Hi Jorgen,
> > There are 3 sockopts defined in include/uapi/linux/vm_sockets.h that are
> > currently not implemented in net/vmw_vsock/af_vsock.c:
> >
> > * SO_VM_SOCKETS_PEER_HOST_VM_ID
> > * SO_VM_SOCKETS_TRUSTED
> > * SO_VM_SOCKETS_NONBLOCK_TXRX
> >
> > I noticed this because SO_VM_SOCKETS_TRUSTED is interesting for
> > virtio-vsock. Services listening on AF_VSOCK inside the guest may not
> > want arbitrary unprivileged host processes to connect. Instead of
> > inventing a new solution I wanted to look into SO_VM_SOCKETS_TRUSTED but
> > found it is not implemented in linux.git.
> >
> > What is the status of these sockets?
>
> These options were only implemented for ESX host endpoints, so were never part of the Linux host side support. It looks like they could have been omitted from vm_sockets.h, when the initial upstreaming was performed.
>
> On ESX, the equivalent of SO_VM_SOCKETS_TRUSTED, is used for retrieving the value of s->trusted of a VMCI socket. It cannot be used to mark a socket as trusted. On Linux, trusted is tied to the CAP_NET_ADMIN capability of the socket creator. VMCI based vSockets will per default only allow host side sockets that are trusted, or are created by the same user as the VM, to communicate with a given VM. This is achieved by per default creating VMs with the VMCI privilege flag VMCI_PRIVILEGE_FLAG_RESTRICTED. It is possible to create a VM that isn’t restricted, in which case any host process will be able to communicate with the VM.
>
> So it should be straight forward to implement the getsockopt part of SO_VM_SOCKETS_TRUSTED, since it just needs to return s->trusted.
Currently virtio-vsock does not implement the 'restricted' mode but I'm
evaluating using it by default for stronger security. Thanks for your
response!
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* iproute2 invalid argument mpls labels
From: Алексей Болдырев @ 2017-08-15 8:17 UTC (permalink / raw)
To: netdev
I updated the kernel 4.12.6. When the mote is hung on the route more than 8 mpls of marks through iproute2, I get the following:
root@ne-vlezay80:~# ip route add 10.10.10.0/24 encap mpls 50/60/70/80/90/100/110/120/130 dev lo
RTNETLINK answers: Invalid argument
root@ne-vlezay80:~# ip route add 10.10.10.0/24 encap mpls 50/60/70/80/90/100/110/120 dev lo
root@ne-vlezay80:~#
root@ne-vlezay80:~# ip r
default via 10.247.0.1 dev ic-br0 proto zebra metric 20
10.10.10.0/24 encap mpls ///////120 dev lo scope link
root@ne-vlezay80:~# cat /usr/src/linux-4.12.6/net/mpls/internal.h|grep MAX_NEW
#define MAX_NEW_LABELS 30
root@ne-vlezay80:~#
What is the problem, and how can more than 8 MPLS markers be hung on through iproute2?
root@ne-vlezay80:~# uname -r
4.12.6
root@ne-vlezay80:~#
^ permalink raw reply
* Re: general protection fault in fib_dump_info
From: Dmitry Vyukov @ 2017-08-15 8:21 UTC (permalink / raw)
To: idaifish
Cc: Eric Dumazet, David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netdev, syzkaller
In-Reply-To: <CACT4Y+bnZxac87Bz6VYLhAzpn5JG-bmm7kzPefoYzDP7z9rftw@mail.gmail.com>
That must be in https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
Which one should we test?
On Tue, Aug 15, 2017 at 8:51 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Eric, what's the "David Miller net tree"? Is it
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git? I
> don't see 2c87d63ac853550e734edfd45e1be5e5aa44fbcc there.
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git is
> what we are testing and the last commit on which we saw this bug is:
>
> commit cb44a8606f063099991242ada4b8fa2fb26769b3
> Merge: 54161ed4eede a656d34a6e5a
> Author: David S. Miller
> Date: Mon Aug 14 11:18:16 2017 -0700
> Merge branch 'mlnx-i2c'
>
>
>
> On Tue, Aug 15, 2017 at 8:42 AM, idaifish <idaifish@gmail.com> wrote:
>> The bug still looks like reproducible after applying the patch [
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=2c87d63ac853550e734edfd45e1be5e5aa44fbcc
>> ]
>>
>>
>>
>> 2017-08-15 11:33 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
>>> On Tue, 2017-08-15 at 10:49 +0800, idaifish wrote:
>>>> Syzkaller hit 'general protection fault in fib_dump_info' bug on
>>>> commit 4.13-rc5..
>>>>
>>>> Guilty file: net/ipv4/fib_semantics.c
>>>>
>>>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>>>> general protection fault: 0000 [#1] SMP KASAN
>>>> Modules linked in:
>>>> CPU: 0 PID: 2808 Comm: syz-executor0 Not tainted 4.13.0-rc5 #1
>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>>> Ubuntu-1.8.2-1ubuntu1 04/01/2014
>>>> task: ffff880078562700 task.stack: ffff880078110000
>>>> RIP: 0010:fib_dump_info+0x388/0x1170 net/ipv4/fib_semantics.c:1314
>>>> RSP: 0018:ffff880078117010 EFLAGS: 00010206
>>>> RAX: dffffc0000000000 RBX: 00000000000000fe RCX: 0000000000000002
>>>> RDX: 0000000000000006 RSI: ffff880078117084 RDI: 0000000000000030
>>>> RBP: ffff880078117268 R08: 000000000000000c R09: ffff8800780d80c8
>>>> R10: 0000000058d629b4 R11: 0000000067fce681 R12: 0000000000000000
>>>> R13: ffff8800784bd540 R14: ffff8800780d80b5 R15: ffff8800780d80a4
>>>> FS: 00000000022fa940(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 00000000004387d0 CR3: 0000000079135000 CR4: 00000000000006f0
>>>> Call Trace:
>>>> inet_rtm_getroute+0xc89/0x1f50 net/ipv4/route.c:2766
>>>> rtnetlink_rcv_msg+0x288/0x680 net/core/rtnetlink.c:4217
>>>> netlink_rcv_skb+0x340/0x470 net/netlink/af_netlink.c:2397
>>>> rtnetlink_rcv+0x28/0x30 net/core/rtnetlink.c:4223
>>>> netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline]
>>>> netlink_unicast+0x4c4/0x6e0 net/netlink/af_netlink.c:1291
>>>> netlink_sendmsg+0x8c4/0xca0 net/netlink/af_netlink.c:1854
>>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>>> ___sys_sendmsg+0x779/0x8d0 net/socket.c:2035
>>>> __sys_sendmsg+0xd1/0x170 net/socket.c:2069
>>>> SYSC_sendmsg net/socket.c:2080 [inline]
>>>> SyS_sendmsg+0x2d/0x50 net/socket.c:2076
>>>> entry_SYSCALL_64_fastpath+0x1a/0xa5
>>>> RIP: 0033:0x4512e9
>>>> RSP: 002b:00007ffc75584cc8 EFLAGS: 00000216 ORIG_RAX: 000000000000002e
>>>> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00000000004512e9
>>>> RDX: 0000000000000000 RSI: 0000000020f2cfc8 RDI: 0000000000000003
>>>> RBP: 000000000000000e R08: 0000000000000000 R09: 0000000000000000
>>>> R10: 0000000000000000 R11: 0000000000000216 R12: fffffffffffffffe
>>>> R13: 0000000000718000 R14: 0000000020c44ff0 R15: 0000000000000000
>>>> Code: 00 0f b6 8d ec fd ff ff 48 8b 85 f0 fd ff ff 88 48 17 48 8b 45
>>>> 28 48 8d 78 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f>
>>>> b6 04 02 84 c0 74 08 3c 03 0f 8e cb 0c 00 00 48 8b 45 28 44
>>>> RIP: fib_dump_info+0x388/0x1170 net/ipv4/fib_semantics.c:1314 RSP:
>>>> ffff880078117010
>>>> ---[ end trace 254a7af28348f88b ]---
>>>> Kernel panic - not syncing: Fatal exception
>>>> Kernel Offset: disabled
>>>> Rebooting in 86400 seconds..
>>>>
>>>> ---------------------
>>>>
>>>> .config and reproducer.prog are attached. Unfortunately the extracted
>>>> C program can't work.
>>>> Maybe you can follow the instruction
>>>> [https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md]
>>>> to reproduce the bug.
>>>>
>>>>
>>>
>>> Probably fixed by commit 2c87d63ac853550e734edfd45e1be5e5aa44fbcc
>>> ("ipv4: route: fix inet_rtm_getroute induced crash")
>>> (In David Miller net tree)
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> idaifish
>>
>> --
>> 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.
^ permalink raw reply
* Re: [PATCH] netfilter: fix indent on in statements
From: walter harms @ 2017-08-15 7:26 UTC (permalink / raw)
To: Colin King
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Stephen Hemminger, David S . Miller, netfilter-devel, coreteam,
bridge, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170815065025.18471-1-colin.king@canonical.com>
Am 15.08.2017 08:50, schrieb Colin King:
> From: Colin Ian King <colin.king@canonical.com>
>
> The returns on some if statements are not indented correctly,
> add in the missing tab.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/bridge/netfilter/ebt_ip.c | 4 ++--
> net/bridge/netfilter/ebt_ip6.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bridge/netfilter/ebt_ip.c b/net/bridge/netfilter/ebt_ip.c
> index d06968bdf5ec..2b46c50abce0 100644
> --- a/net/bridge/netfilter/ebt_ip.c
> +++ b/net/bridge/netfilter/ebt_ip.c
> @@ -64,14 +64,14 @@ ebt_ip_mt(const struct sk_buff *skb, struct xt_action_param *par)
> if (NF_INVF(info, EBT_IP_DPORT,
> dst < info->dport[0] ||
> dst > info->dport[1]))
> - return false;
> + return false;
This is hard to read, perhaps it gets better when the result is stored in a tmp-var.
something like:
int isbetween=dst < info->dport[0] ||dst > info->dport[1] ;
int state=NF_INVF(info, EBT_IP_DPORT, isbetween );
if ( state )
return false;
just my 2 cents,
re,
wh
> }
> if (info->bitmask & EBT_IP_SPORT) {
> u32 src = ntohs(pptr->src);
> if (NF_INVF(info, EBT_IP_SPORT,
> src < info->sport[0] ||
> src > info->sport[1]))
> - return false;
> + return false;
> }
> }
> return true;
> diff --git a/net/bridge/netfilter/ebt_ip6.c b/net/bridge/netfilter/ebt_ip6.c
> index 4617491be41e..2a5a52a53ec4 100644
> --- a/net/bridge/netfilter/ebt_ip6.c
> +++ b/net/bridge/netfilter/ebt_ip6.c
> @@ -89,7 +89,7 @@ ebt_ip6_mt(const struct sk_buff *skb, struct xt_action_param *par)
> if (NF_INVF(info, EBT_IP6_SPORT,
> src < info->sport[0] ||
> src > info->sport[1]))
> - return false;
> + return false;
> }
> if ((info->bitmask & EBT_IP6_ICMP6) &&
> NF_INVF(info, EBT_IP6_ICMP6,
^ permalink raw reply
* Re: [PATCH net-next] liquidio: update debug console logging mechanism
From: Leon Romanovsky @ 2017-08-15 7:22 UTC (permalink / raw)
To: Ricardo Farrington
Cc: Manlunas, Felix, davem@davemloft.net, netdev@vger.kernel.org,
Vatsavayi, Raghu, Chickles, Derek, Burla, Satananda
In-Reply-To: <CY1PR0701MB1961883A407496B03A8FD870EC8C0@CY1PR0701MB1961.namprd07.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
On Mon, Aug 14, 2017 at 04:28:50PM +0000, Ricardo Farrington wrote:
> Hi Leon - the code to which this patch applies handles a data stream from our card's firmware to the host (over PCI).
> There are device-specific registers which are accessed to transfer log data from our firmware to the host.
> I don't think there is kernel code that we could use to perform this; this is not general purpose host driver logging.
I see, it is not really clear form the name "console".
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] mlx4: remove unnecessary pci_set_drvdata()
From: Leon Romanovsky @ 2017-08-15 7:13 UTC (permalink / raw)
To: Zhu Yanjun; +Cc: saeedm, matanb, netdev, linux-rdma, yuval.shaia
In-Reply-To: <1502778786-14738-1-git-send-email-yanjun.zhu@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
On Tue, Aug 15, 2017 at 02:33:05AM -0400, Zhu Yanjun wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not necessary to manually clear the
> device driver data to NULL.
>
It makes sense and I'm pretty sure that you are right, but I'm failing
to find the function in device core which sets it to NULL. Can you help
me and present the actual call stack to that code place?
Thanks,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [patch net-next] mlxsw: spectrum_router: Use correct config option
From: Jiri Pirko @ 2017-08-15 7:10 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, mlxsw
From: Ido Schimmel <idosch@mellanox.com>
I made an embarrassing mistake and used 'IPV6' instead of 'CONFIG_IPV6'
around the function that updates the kernel about IPv6 neighbours
activity. This can be a problem if the kernel has more neighbours than a
certain threshold and it starts deleting those that are supposedly
inactive.
Fixes: b5f3e0d43012 ("mlxsw: spectrum_router: Fix build when IPv6 isn't enabled")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 4895d5b..a0a9728 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -1042,7 +1042,7 @@ static void mlxsw_sp_router_neigh_ent_ipv4_process(struct mlxsw_sp *mlxsw_sp,
neigh_release(n);
}
-#if IS_ENABLED(IPV6)
+#if IS_ENABLED(CONFIG_IPV6)
static void mlxsw_sp_router_neigh_ent_ipv6_process(struct mlxsw_sp *mlxsw_sp,
char *rauhtd_pl,
int rec_index)
--
2.9.3
^ permalink raw reply related
* [patch net-next] ipv6: fib: Provide offload indication using nexthop flags
From: Jiri Pirko @ 2017-08-15 7:09 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, mlxsw, dsahern, roopa, nikolay, hannes, yoshfuji,
kuznet
From: Ido Schimmel <idosch@mellanox.com>
IPv6 routes currently lack nexthop flags as in IPv4. This has several
implications.
In the forwarding path, it requires us to check the carrier state of the
nexthop device and potentially ignore a linkdown route, instead of
checking for RTNH_F_LINKDOWN.
It also requires capable drivers to use the user facing IPv6-specific
route flags to provide offload indication, instead of using the nexthop
flags as in IPv4.
Add nexthop flags to IPv6 routes in the 40 bytes hole and use it to
provide offload indication instead of the RTF_OFFLOAD flag, which is
removed while it's still not part of any official kernel release.
In the near future we would like to use the field for the
RTNH_F_{LINKDOWN,DEAD} flags, but this change is more involved and might
not be ready in time for the current cycle.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 8 ++++----
include/net/ip6_fib.h | 2 ++
include/uapi/linux/ipv6_route.h | 1 -
net/ipv6/route.c | 7 +------
4 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 16676ff..4895d5b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -2397,7 +2397,7 @@ mlxsw_sp_fib6_entry_offload_set(struct mlxsw_sp_fib_entry *fib_entry)
if (fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_LOCAL) {
list_first_entry(&fib6_entry->rt6_list, struct mlxsw_sp_rt6,
- list)->rt->rt6i_flags |= RTF_OFFLOAD;
+ list)->rt->rt6i_nh_flags |= RTNH_F_OFFLOAD;
return;
}
@@ -2407,9 +2407,9 @@ mlxsw_sp_fib6_entry_offload_set(struct mlxsw_sp_fib_entry *fib_entry)
nh = mlxsw_sp_rt6_nexthop(nh_grp, mlxsw_sp_rt6);
if (nh && nh->offloaded)
- mlxsw_sp_rt6->rt->rt6i_flags |= RTF_OFFLOAD;
+ mlxsw_sp_rt6->rt->rt6i_nh_flags |= RTNH_F_OFFLOAD;
else
- mlxsw_sp_rt6->rt->rt6i_flags &= ~RTF_OFFLOAD;
+ mlxsw_sp_rt6->rt->rt6i_nh_flags &= ~RTNH_F_OFFLOAD;
}
}
@@ -2424,7 +2424,7 @@ mlxsw_sp_fib6_entry_offload_unset(struct mlxsw_sp_fib_entry *fib_entry)
list_for_each_entry(mlxsw_sp_rt6, &fib6_entry->rt6_list, list) {
struct rt6_info *rt = mlxsw_sp_rt6->rt;
- rt->rt6i_flags &= ~RTF_OFFLOAD;
+ rt->rt6i_nh_flags &= ~RTNH_F_OFFLOAD;
}
}
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 1d790ea..71c1646 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -120,6 +120,8 @@ struct rt6_info {
atomic_t rt6i_ref;
+ unsigned int rt6i_nh_flags;
+
/* These are in a separate cache line. */
struct rt6key rt6i_dst ____cacheline_aligned_in_smp;
u32 rt6i_flags;
diff --git a/include/uapi/linux/ipv6_route.h b/include/uapi/linux/ipv6_route.h
index 33e2a57..d496c02 100644
--- a/include/uapi/linux/ipv6_route.h
+++ b/include/uapi/linux/ipv6_route.h
@@ -35,7 +35,6 @@
#define RTF_PREF(pref) ((pref) << 27)
#define RTF_PREF_MASK 0x18000000
-#define RTF_OFFLOAD 0x20000000 /* offloaded route */
#define RTF_PCPU 0x40000000 /* read-only: can not be set by user */
#define RTF_LOCAL 0x80000000
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 035762f..6793135 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1820,11 +1820,6 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg,
goto out;
}
- if (cfg->fc_flags & RTF_OFFLOAD) {
- NL_SET_ERR_MSG(extack, "Userspace can not set RTF_OFFLOAD");
- goto out;
- }
-
if (cfg->fc_dst_len > 128) {
NL_SET_ERR_MSG(extack, "Invalid prefix length");
goto out;
@@ -3335,7 +3330,7 @@ static int rt6_nexthop_info(struct sk_buff *skb, struct rt6_info *rt,
goto nla_put_failure;
}
- if (rt->rt6i_flags & RTF_OFFLOAD)
+ if (rt->rt6i_nh_flags & RTNH_F_OFFLOAD)
*flags |= RTNH_F_OFFLOAD;
/* not needed for multipath encoding b/c it has a rtnexthop struct */
--
2.9.3
^ permalink raw reply related
* Re: general protection fault in fib_dump_info
From: Dmitry Vyukov @ 2017-08-15 6:51 UTC (permalink / raw)
To: idaifish
Cc: Eric Dumazet, David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netdev, syzkaller
In-Reply-To: <CADUsjNmyusiq+fCChitacZwzHYJVO3_8a60A5=G=Ga2x4Y6xqw@mail.gmail.com>
Eric, what's the "David Miller net tree"? Is it
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git? I
don't see 2c87d63ac853550e734edfd45e1be5e5aa44fbcc there.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git is
what we are testing and the last commit on which we saw this bug is:
commit cb44a8606f063099991242ada4b8fa2fb26769b3
Merge: 54161ed4eede a656d34a6e5a
Author: David S. Miller
Date: Mon Aug 14 11:18:16 2017 -0700
Merge branch 'mlnx-i2c'
On Tue, Aug 15, 2017 at 8:42 AM, idaifish <idaifish@gmail.com> wrote:
> The bug still looks like reproducible after applying the patch [
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=2c87d63ac853550e734edfd45e1be5e5aa44fbcc
> ]
>
>
>
> 2017-08-15 11:33 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
>> On Tue, 2017-08-15 at 10:49 +0800, idaifish wrote:
>>> Syzkaller hit 'general protection fault in fib_dump_info' bug on
>>> commit 4.13-rc5..
>>>
>>> Guilty file: net/ipv4/fib_semantics.c
>>>
>>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>>> general protection fault: 0000 [#1] SMP KASAN
>>> Modules linked in:
>>> CPU: 0 PID: 2808 Comm: syz-executor0 Not tainted 4.13.0-rc5 #1
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> Ubuntu-1.8.2-1ubuntu1 04/01/2014
>>> task: ffff880078562700 task.stack: ffff880078110000
>>> RIP: 0010:fib_dump_info+0x388/0x1170 net/ipv4/fib_semantics.c:1314
>>> RSP: 0018:ffff880078117010 EFLAGS: 00010206
>>> RAX: dffffc0000000000 RBX: 00000000000000fe RCX: 0000000000000002
>>> RDX: 0000000000000006 RSI: ffff880078117084 RDI: 0000000000000030
>>> RBP: ffff880078117268 R08: 000000000000000c R09: ffff8800780d80c8
>>> R10: 0000000058d629b4 R11: 0000000067fce681 R12: 0000000000000000
>>> R13: ffff8800784bd540 R14: ffff8800780d80b5 R15: ffff8800780d80a4
>>> FS: 00000000022fa940(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 00000000004387d0 CR3: 0000000079135000 CR4: 00000000000006f0
>>> Call Trace:
>>> inet_rtm_getroute+0xc89/0x1f50 net/ipv4/route.c:2766
>>> rtnetlink_rcv_msg+0x288/0x680 net/core/rtnetlink.c:4217
>>> netlink_rcv_skb+0x340/0x470 net/netlink/af_netlink.c:2397
>>> rtnetlink_rcv+0x28/0x30 net/core/rtnetlink.c:4223
>>> netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline]
>>> netlink_unicast+0x4c4/0x6e0 net/netlink/af_netlink.c:1291
>>> netlink_sendmsg+0x8c4/0xca0 net/netlink/af_netlink.c:1854
>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>> ___sys_sendmsg+0x779/0x8d0 net/socket.c:2035
>>> __sys_sendmsg+0xd1/0x170 net/socket.c:2069
>>> SYSC_sendmsg net/socket.c:2080 [inline]
>>> SyS_sendmsg+0x2d/0x50 net/socket.c:2076
>>> entry_SYSCALL_64_fastpath+0x1a/0xa5
>>> RIP: 0033:0x4512e9
>>> RSP: 002b:00007ffc75584cc8 EFLAGS: 00000216 ORIG_RAX: 000000000000002e
>>> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00000000004512e9
>>> RDX: 0000000000000000 RSI: 0000000020f2cfc8 RDI: 0000000000000003
>>> RBP: 000000000000000e R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000216 R12: fffffffffffffffe
>>> R13: 0000000000718000 R14: 0000000020c44ff0 R15: 0000000000000000
>>> Code: 00 0f b6 8d ec fd ff ff 48 8b 85 f0 fd ff ff 88 48 17 48 8b 45
>>> 28 48 8d 78 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f>
>>> b6 04 02 84 c0 74 08 3c 03 0f 8e cb 0c 00 00 48 8b 45 28 44
>>> RIP: fib_dump_info+0x388/0x1170 net/ipv4/fib_semantics.c:1314 RSP:
>>> ffff880078117010
>>> ---[ end trace 254a7af28348f88b ]---
>>> Kernel panic - not syncing: Fatal exception
>>> Kernel Offset: disabled
>>> Rebooting in 86400 seconds..
>>>
>>> ---------------------
>>>
>>> .config and reproducer.prog are attached. Unfortunately the extracted
>>> C program can't work.
>>> Maybe you can follow the instruction
>>> [https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md]
>>> to reproduce the bug.
>>>
>>>
>>
>> Probably fixed by commit 2c87d63ac853550e734edfd45e1be5e5aa44fbcc
>> ("ipv4: route: fix inet_rtm_getroute induced crash")
>> (In David Miller net tree)
>>
>>
>
>
>
> --
> Regards,
> idaifish
>
> --
> 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.
^ permalink raw reply
* [PATCH] netfilter: fix indent on in statements
From: Colin King @ 2017-08-15 6:50 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Stephen Hemminger, David S . Miller, netfilter-devel, coreteam,
bridge, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The returns on some if statements are not indented correctly,
add in the missing tab.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/bridge/netfilter/ebt_ip.c | 4 ++--
net/bridge/netfilter/ebt_ip6.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/netfilter/ebt_ip.c b/net/bridge/netfilter/ebt_ip.c
index d06968bdf5ec..2b46c50abce0 100644
--- a/net/bridge/netfilter/ebt_ip.c
+++ b/net/bridge/netfilter/ebt_ip.c
@@ -64,14 +64,14 @@ ebt_ip_mt(const struct sk_buff *skb, struct xt_action_param *par)
if (NF_INVF(info, EBT_IP_DPORT,
dst < info->dport[0] ||
dst > info->dport[1]))
- return false;
+ return false;
}
if (info->bitmask & EBT_IP_SPORT) {
u32 src = ntohs(pptr->src);
if (NF_INVF(info, EBT_IP_SPORT,
src < info->sport[0] ||
src > info->sport[1]))
- return false;
+ return false;
}
}
return true;
diff --git a/net/bridge/netfilter/ebt_ip6.c b/net/bridge/netfilter/ebt_ip6.c
index 4617491be41e..2a5a52a53ec4 100644
--- a/net/bridge/netfilter/ebt_ip6.c
+++ b/net/bridge/netfilter/ebt_ip6.c
@@ -89,7 +89,7 @@ ebt_ip6_mt(const struct sk_buff *skb, struct xt_action_param *par)
if (NF_INVF(info, EBT_IP6_SPORT,
src < info->sport[0] ||
src > info->sport[1]))
- return false;
+ return false;
}
if ((info->bitmask & EBT_IP6_ICMP6) &&
NF_INVF(info, EBT_IP6_ICMP6,
--
2.11.0
^ permalink raw reply related
* Re: general protection fault in fib_dump_info
From: idaifish @ 2017-08-15 6:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, Alexey Kuznetsov, yoshfuji, netdev, syzkaller
In-Reply-To: <1502767994.4936.47.camel@edumazet-glaptop3.roam.corp.google.com>
The bug still looks like reproducible after applying the patch [
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=2c87d63ac853550e734edfd45e1be5e5aa44fbcc
]
2017-08-15 11:33 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
> On Tue, 2017-08-15 at 10:49 +0800, idaifish wrote:
>> Syzkaller hit 'general protection fault in fib_dump_info' bug on
>> commit 4.13-rc5..
>>
>> Guilty file: net/ipv4/fib_semantics.c
>>
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP KASAN
>> Modules linked in:
>> CPU: 0 PID: 2808 Comm: syz-executor0 Not tainted 4.13.0-rc5 #1
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> Ubuntu-1.8.2-1ubuntu1 04/01/2014
>> task: ffff880078562700 task.stack: ffff880078110000
>> RIP: 0010:fib_dump_info+0x388/0x1170 net/ipv4/fib_semantics.c:1314
>> RSP: 0018:ffff880078117010 EFLAGS: 00010206
>> RAX: dffffc0000000000 RBX: 00000000000000fe RCX: 0000000000000002
>> RDX: 0000000000000006 RSI: ffff880078117084 RDI: 0000000000000030
>> RBP: ffff880078117268 R08: 000000000000000c R09: ffff8800780d80c8
>> R10: 0000000058d629b4 R11: 0000000067fce681 R12: 0000000000000000
>> R13: ffff8800784bd540 R14: ffff8800780d80b5 R15: ffff8800780d80a4
>> FS: 00000000022fa940(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00000000004387d0 CR3: 0000000079135000 CR4: 00000000000006f0
>> Call Trace:
>> inet_rtm_getroute+0xc89/0x1f50 net/ipv4/route.c:2766
>> rtnetlink_rcv_msg+0x288/0x680 net/core/rtnetlink.c:4217
>> netlink_rcv_skb+0x340/0x470 net/netlink/af_netlink.c:2397
>> rtnetlink_rcv+0x28/0x30 net/core/rtnetlink.c:4223
>> netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline]
>> netlink_unicast+0x4c4/0x6e0 net/netlink/af_netlink.c:1291
>> netlink_sendmsg+0x8c4/0xca0 net/netlink/af_netlink.c:1854
>> sock_sendmsg_nosec net/socket.c:633 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:643
>> ___sys_sendmsg+0x779/0x8d0 net/socket.c:2035
>> __sys_sendmsg+0xd1/0x170 net/socket.c:2069
>> SYSC_sendmsg net/socket.c:2080 [inline]
>> SyS_sendmsg+0x2d/0x50 net/socket.c:2076
>> entry_SYSCALL_64_fastpath+0x1a/0xa5
>> RIP: 0033:0x4512e9
>> RSP: 002b:00007ffc75584cc8 EFLAGS: 00000216 ORIG_RAX: 000000000000002e
>> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00000000004512e9
>> RDX: 0000000000000000 RSI: 0000000020f2cfc8 RDI: 0000000000000003
>> RBP: 000000000000000e R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000216 R12: fffffffffffffffe
>> R13: 0000000000718000 R14: 0000000020c44ff0 R15: 0000000000000000
>> Code: 00 0f b6 8d ec fd ff ff 48 8b 85 f0 fd ff ff 88 48 17 48 8b 45
>> 28 48 8d 78 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f>
>> b6 04 02 84 c0 74 08 3c 03 0f 8e cb 0c 00 00 48 8b 45 28 44
>> RIP: fib_dump_info+0x388/0x1170 net/ipv4/fib_semantics.c:1314 RSP:
>> ffff880078117010
>> ---[ end trace 254a7af28348f88b ]---
>> Kernel panic - not syncing: Fatal exception
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>> ---------------------
>>
>> .config and reproducer.prog are attached. Unfortunately the extracted
>> C program can't work.
>> Maybe you can follow the instruction
>> [https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md]
>> to reproduce the bug.
>>
>>
>
> Probably fixed by commit 2c87d63ac853550e734edfd45e1be5e5aa44fbcc
> ("ipv4: route: fix inet_rtm_getroute induced crash")
> (In David Miller net tree)
>
>
--
Regards,
idaifish
^ permalink raw reply
* [PATCH 2/2] mlx5: remove unnecessary pci_set_drvdata()
From: Zhu Yanjun @ 2017-08-15 6:33 UTC (permalink / raw)
To: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA
In-Reply-To: <1502778786-14738-1-git-send-email-yanjun.zhu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not necessary to manually clear the
device driver data to NULL.
Cc: Joe Jin <joe.jin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: Junxiao Bi <junxiao.bi-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Zhu Yanjun <yanjun.zhu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index c065132..2cafbdc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1407,7 +1407,6 @@ static int init_one(struct pci_dev *pdev,
cleanup_srcu_struct(&priv->pfault_srcu);
clean_dev:
#endif
- pci_set_drvdata(pdev, NULL);
devlink_free(devlink);
return err;
@@ -1434,7 +1433,6 @@ static void remove_one(struct pci_dev *pdev)
#ifdef CONFIG_INFINIBAND_ON_DEMAND_PAGING
cleanup_srcu_struct(&priv->pfault_srcu);
#endif
- pci_set_drvdata(pdev, NULL);
devlink_free(devlink);
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] mlx4: remove unnecessary pci_set_drvdata()
From: Zhu Yanjun @ 2017-08-15 6:33 UTC (permalink / raw)
To: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not necessary to manually clear the
device driver data to NULL.
Cc: Joe Jin <joe.jin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: Junxiao Bi <junxiao.bi-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Zhu Yanjun <yanjun.zhu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 09b9bc1..df9b0ef 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -3782,7 +3782,6 @@ static int __mlx4_init_one(struct pci_dev *pdev, int pci_dev_data,
err_disable_pdev:
mlx4_pci_disable_device(&priv->dev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -3997,7 +3996,6 @@ static void mlx4_remove_one(struct pci_dev *pdev)
devlink_unregister(devlink);
kfree(dev->persist);
devlink_free(devlink);
- pci_set_drvdata(pdev, NULL);
}
static int restore_current_port_types(struct mlx4_dev *dev,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net repost] nfp: do not update MTU from BH in flower app
From: Simon Horman @ 2017-08-15 6:13 UTC (permalink / raw)
To: David Miller; +Cc: jakub.kicinski, netdev, oss-drivers
In-Reply-To: <20170811.145107.1539668262080149471.davem@davemloft.net>
On Fri, Aug 11, 2017 at 02:51:07PM -0700, David Miller wrote:
> From: Simon Horman <simon.horman@netronome.com>
> Date: Fri, 11 Aug 2017 10:18:20 +0200
>
> > The Flower app may receive a request to update the MTU of a representor
> > netdev upon receipt of a control message from the firmware. This requires
> > the RTNL lock which needs to be taken outside of the packet processing
> > path.
> >
> > As a handling of this correctly seems a little to invasive for a fix simply
> > skip setting the MTU for now.
> >
> > Relevant backtrace:
> ...
> > Fixes: 948faa46c05b ("nfp: add support for control messages for flower app")
> > Signed-off-by: Simon Horman <simon.horman@netronome.com>
> > Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> Applied.
Thanks.
Could you pull net into net-next? I'd like to send up a follow-up
for net-next to allow processing of the MTU.
^ permalink raw reply
* Re: [PATCH net] openvswitch: fix skb_panic due to the incorrect actions attrlen
From: Liping Zhang @ 2017-08-15 6:02 UTC (permalink / raw)
To: Pravin Shelar
Cc: Liping Zhang, Pravin Shelar, David S. Miller,
Linux Kernel Network Developers, Neil McKee
In-Reply-To: <CAOrHB_Cy-bxRABSR4keg43U7tj4riVAdFd8So1GUHkNzYXA7bg@mail.gmail.com>
2017-08-15 13:01 GMT+08:00 Pravin Shelar <pshelar@ovn.org>:
[...]
>> net/openvswitch/actions.c | 39 +++++++++++++++++++++++++--------------
>> net/openvswitch/datapath.c | 2 +-
>> net/openvswitch/datapath.h | 1 +
>> 3 files changed, 27 insertions(+), 15 deletions(-)
>>
>> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
>> index e4610676299b..799a22dfb89e 100644
>> --- a/net/openvswitch/actions.c
>> +++ b/net/openvswitch/actions.c
>> @@ -48,6 +48,7 @@ struct deferred_action {
>> struct sk_buff *skb;
>> const struct nlattr *actions;
>> int actions_len;
>> + int actions_attrlen;
>>
> Have you considered passing this value using struct ovs_skb_cb? That
> would save passing this parameter in all these functions.
Thanks for your reviewing.
Right, this will make codes more clean, I will send V2 later.
^ permalink raw reply
* Re: [PATCH net] tcp: fix possible deadlock in TCP stack vs BPF filter
From: David Miller @ 2017-08-15 5:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, fengc
In-Reply-To: <1502757883.4936.41.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Aug 2017 17:44:43 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Filtering the ACK packet was not put at the right place.
>
> At this place, we already allocated a child and put it
> into accept queue.
>
> We absolutely need to call tcp_child_process() to release
> its spinlock, or we will deadlock at accept() or close() time.
>
> Found by syzkaller team (Thanks a lot !)
>
> Fixes: 8fac365f63c8 ("tcp: Add a tcp_filter hook before handle ack packet")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] dccp: purge write queue in dccp_destroy_sock()
From: David Miller @ 2017-08-15 5:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, gerrit
In-Reply-To: <1502745025.4936.34.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Aug 2017 14:10:25 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> syzkaller reported that DCCP could have a non empty
> write queue at dismantle time.
>
> WARNING: CPU: 1 PID: 2953 at net/core/stream.c:199 sk_stream_kill_queues+0x3ce/0x520 net/core/stream.c:199
> Kernel panic - not syncing: panic_on_warn set ...
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] udp: fix linear skb reception with PEEK_OFF
From: David Miller @ 2017-08-15 5:27 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet, alexander.levin, viro
In-Reply-To: <18c1b112032a685518548760890547fdbf292b85.1502739025.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Mon, 14 Aug 2017 21:31:38 +0200
> From: Al Viro <viro@ZenIV.linux.org.uk>
>
> copy_linear_skb() is broken; both of its callers actually
> expect 'len' to be the amount we are trying to copy,
> not the offset of the end.
> Fix it keeping the meanings of arguments in sync with what the
> callers (both of them) expect.
> Also restore a saner behavior on EFAULT (i.e. preserving
> the iov_iter position in case of failure):
>
> The commit fd851ba9caa9 ("udp: harden copy_linear_skb()")
> avoids the more destructive effect of the buggy
> copy_linear_skb(), e.g. no more invalid memory access, but
> said function still behaves incorrectly: when peeking with
> offset it can fail with EINVAL instead of copying the
> appropriate amount of memory.
>
> Reported-by: Sasha Levin <alexander.levin@verizon.com>
> Fixes: b65ac44674dd ("udp: try to avoid 2 cache miss on dequeue")
> Fixes: fd851ba9caa9 ("udp: harden copy_linear_skb()")
> Signed-off-by: Al Viro <viro@ZenIV.linux.org.uk>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
> Tested-by: Sasha Levin <alexander.levin@verizon.com>
> ---
> This patch has been buried in a private email exchange for some
> time.
> I'm posting it on behalf of Al Viro, to avoid loosing this merge
> window, since he is busy elsewhere.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: fix issues with fw_type module parameter
From: David Miller @ 2017-08-15 5:25 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20170814191756.GA1371@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Mon, 14 Aug 2017 12:17:56 -0700
> From: Derek Chickles <derek.chickles@cavium.com>
>
> The fw_type module parameter isn't showing up in the
> /sys/module/liquidio/parameters directory. Fix it by setting the read
> permission bits for user, group, other in module_param_string(). Revise
> the description of fw_type. Initialize the fw_type static char array with
> the default value to conform to the module parameter description.
>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next 0/2] mlxsw: Add support for nexthop group consolidation for IPv6
From: David Miller @ 2017-08-15 5:24 UTC (permalink / raw)
To: jiri; +Cc: netdev, arkadis, idosch, mlxsw
In-Reply-To: <20170814190920.9576-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 14 Aug 2017 21:09:18 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Arkadi says:
>
> Due to limited ASIC resources the maximum number of routes is limited by
> the nexthop resource. In order to improve the routing scale nexthop
> consolidation should be performed.
>
> In case of IPv4, the kernel does the consolidation of nexthops in the form
> of the fib_info struct. In that case, the driver uses the fib_info's
> address as a key for the internal nexthop group representative struct
> lookup. In case of IPv6, the kernel doesn't do consolidation, thus the
> driver should implement it by itself.
>
> The hash value is calculated based on the nexthop set, by performing
> bitwise xor on the ifindexs of the nexthops, in a similar way to IPV4's
> kernel implementation. In case of collision a full match is performed
> between the sets which include address and ifindex comparison.
>
> In order to use the same hash table in both cases (IPv4/6), the rhashtable
> is changed to operate on variable length key.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH V2 net-next 0/8] liquidio: adding support for ethtool --set-ring feature
From: David Miller @ 2017-08-15 5:21 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20170814190034.GA1219@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Mon, 14 Aug 2017 12:00:34 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> Code reorganization is required for adding ethtool --set-ring feature.
> First seven patches are for code reorganization. The last patch is for
> adding this feature.
>
> Change Log:
> V1 -> V2
> Only patch #8 was changed: unnecessary parentheses were removed in two
> if-statements in lio_ethtool_set_ringparam().
Series applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: release rt6->rt6i_idev properly during ifdown
From: David Miller @ 2017-08-15 5:19 UTC (permalink / raw)
To: weiwan; +Cc: netdev, kafai, dsahern
In-Reply-To: <20170814174459.3569-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Mon, 14 Aug 2017 10:44:59 -0700
> From: Wei Wang <weiwan@google.com>
>
> When a dst is created by addrconf_dst_alloc() for a host route or an
> anycast route, dst->dev points to loopback dev while rt6->rt6i_idev
> points to a real device.
> When the real device goes down, the current cleanup code only checks for
> dst->dev and assumes rt6->rt6i_idev->dev is the same. This causes the
> refcount leak on the real device in the above situation.
> This patch makes sure to always release the refcount taken on
> rt6->rt6i_idev during dst_dev_put().
>
> Fixes: 587fea741134 ("ipv6: mark DST_NOGC and remove the operation of
> dst_free()")
> Reported-by: John Stultz <john.stultz@linaro.org>
> Tested-by: John Stultz <john.stultz@linaro.org>
> Tested-by: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] af_key: do not use GFP_KERNEL in atomic contexts
From: David Miller @ 2017-08-15 5:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dsa
In-Reply-To: <1502731005.4936.29.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Aug 2017 10:16:45 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> pfkey_broadcast() might be called from non process contexts,
> we can not use GFP_KERNEL in these cases [1].
>
> This patch partially reverts commit ba51b6be38c1 ("net: Fix RCU splat in
> af_key"), only keeping the GFP_ATOMIC forcing under rcu_read_lock()
> section.
>
> [1] : syzkaller reported :
...
> Fixes: ba51b6be38c1 ("net: Fix RCU splat in af_key")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] tcp: ulp: avoid module refcnt leak in tcp_set_ulp
From: David Miller @ 2017-08-15 5:17 UTC (permalink / raw)
To: sd; +Cc: netdev, davejwatson, borisp, tom, hannes
In-Reply-To: <776711b75a664f4a61da8d32eab15d3e794cabe7.1502725540.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon, 14 Aug 2017 18:04:24 +0200
> __tcp_ulp_find_autoload returns tcp_ulp_ops after taking a reference on
> the module. Then, if ->init fails, tcp_set_ulp propagates the error but
> nothing releases that reference.
>
> Fixes: 734942cc4ea6 ("tcp: ULP infrastructure")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: David Miller @ 2017-08-15 5:15 UTC (permalink / raw)
To: dingtianhong
Cc: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr,
asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw,
l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel, linuxarm
In-Reply-To: <1502767407-6812-1-git-send-email-dingtianhong@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Tue, 15 Aug 2017 11:23:22 +0800
> Some devices have problems with Transaction Layer Packets with the Relaxed
> Ordering Attribute set. This patch set adds a new PCIe Device Flag,
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
> devices with Relaxed Ordering issues, and a use of this new flag by the
> cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
> Ports.
...
Series applied, thanks.
^ 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