Re: [PATCH net] l2tp: fix missing print session offset info

2017-12-21 Thread David Miller
From: Hangbin Liu Date: Thu, 21 Dec 2017 14:45:30 +0800 > + (session->offset && > + nla_put_u16(skb, L2TP_ATTR_OFFSET, session->offset) || It really discourages people from reviewing your changes when they don't even compile. net/l2tp/l2tp_netlink.c: In

Re: [bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept

2017-12-21 Thread Jesper Dangaard Brouer
On Mon, 18 Dec 2017 11:55:01 +0100 Jesper Dangaard Brouer wrote: > On Wed, 13 Dec 2017 19:34:40 -0700 > David Ahern wrote: > > > On 12/13/17 4:19 AM, Jesper Dangaard Brouer wrote: > > > + > > > +void xdp_rxq_info_unreg(struct xdp_rxq_info *xdp_rxq) > > >

[PATCH net] l2tp: fix missing print session offset info

2017-12-20 Thread Hangbin Liu
Fixes: 309795f4bec ("l2tp: Add netlink control API for L2TP") Reported-by: Jianlin Shi Signed-off-by: Hangbin Liu --- net/l2tp/l2tp_netlink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c index

[PATCH bpf-next 8/8] selftests/bpf: test device info reporting for bound progs

2017-12-19 Thread Jakub Kicinski
Check if bound programs report correct device info. Test in local namespace, in remote one, back to the local ns, remove the device and check that information is cleared. Signed-off-by: Jakub Kicinski <jakub.kicin...@netronome.com> Reviewed-by: Quentin Monnet <quentin.mon...@netr

Re: INFO: task hung in bpf_exit_net

2017-12-19 Thread David Ahern
gt;> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default >> minimum of 512 >> INFO: task kworker/u4:0:5 blocked for more than 120 seconds. >> Not tainted 4.15.0-rc2-next-20171205+ #59 >> "echo 0 > /proc/sys/kernel/hung_task_timeout

Re: INFO: task hung in cleanup_net

2017-12-19 Thread David Ahern
gt;> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default >> minimum of 512 >> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default >> minimum of 512 >> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default

Re: INFO: task hung in bpf_exit_net

2017-12-19 Thread Xin Long
er for this bug yet. >> >> >> sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default >> minimum of 512 >> INFO: task kworker/u4:0:5 blocked for more than 120 seconds. >> Not tainted 4.15.0-rc2-next-20171205+ #59 >> "echo 0

Re: INFO: task hung in bpf_exit_net

2017-12-19 Thread Dmitry Vyukov
git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet. > > > sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default > minimum of 512 >

Re: INFO: task hung in cleanup_net

2017-12-19 Thread Dmitry Vyukov
sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default > minimum of 512 > sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default > minimum of 512 > INFO: task kworker/u4:11:3785 blocked for more than 120 seconds. > Not

Re: [bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept

2017-12-18 Thread Jesper Dangaard Brouer
On Mon, 18 Dec 2017 06:23:40 -0700 David Ahern wrote: > On 12/18/17 3:55 AM, Jesper Dangaard Brouer wrote: > > > > Handling return-errors in the drivers complicated the driver code, as it > > involves unraveling and deallocating other RX-rings etc (that were > > already

[PATCH RESEND] Bluetooth: Prevent stack info leak from the EFS element.

2017-12-18 Thread Greg Kroah-Hartman
From: Ben Seri In the function l2cap_parse_conf_rsp and in the function l2cap_parse_conf_req the following variable is declared without initialization: struct l2cap_conf_efs efs; In addition, when parsing input configuration parameters in both of these functions, the switch

Re: [bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept

2017-12-18 Thread David Ahern
On 12/18/17 3:55 AM, Jesper Dangaard Brouer wrote: > > Handling return-errors in the drivers complicated the driver code, as it > involves unraveling and deallocating other RX-rings etc (that were > already allocated) if the reg fails. (Also notice next patch will allow > dev == NULL, if right

Re: [bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept

2017-12-18 Thread Jesper Dangaard Brouer
On Wed, 13 Dec 2017 19:34:40 -0700 David Ahern wrote: > On 12/13/17 4:19 AM, Jesper Dangaard Brouer wrote: > > + > > +void xdp_rxq_info_unreg(struct xdp_rxq_info *xdp_rxq) > > +{ > > + xdp_rxq->reg_state = REG_STATE_UNREGISTRED; > > +} > >

[PATCH iproute] ip: validate vlan value for vlan info

2017-12-14 Thread Stephen Hemminger
The VLAN tag must be 0..4095 to be valid. Better to trap it here. Signed-off-by: Stephen Hemminger --- ip/iplink.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ip/iplink.c b/ip/iplink.c index e83f1477e7bc..1e685cc23805 100644 ---

Re: [bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept

2017-12-13 Thread David Ahern
On 12/13/17 4:19 AM, Jesper Dangaard Brouer wrote: > + > +void xdp_rxq_info_unreg(struct xdp_rxq_info *xdp_rxq) > +{ > + xdp_rxq->reg_state = REG_STATE_UNREGISTRED; > +} > +EXPORT_SYMBOL_GPL(xdp_rxq_info_unreg); > + > +void xdp_rxq_info_init(struct xdp_rxq_info *xdp_rxq) > +{ > + if

[bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept

2017-12-13 Thread Jesper Dangaard Brouer
This patch only introduce the core data structures and API functions. All XDP enabled drivers must use the API before this info can used. There is a need for XDP to know more about the RX-queue a given XDP frames have arrived on. For both the XDP bpf-prog and kernel side. Instead of extending

[bpf-next V1-RFC PATCH 00/14] xdp: new XDP rx-queue info concept

2017-12-13 Thread Jesper Dangaard Brouer
on. For both the XDP bpf-prog and kernel side. Instead of extending struct xdp_buff each time new info is needed, this patchset takes a different approach. Struct xdp_buff is only extended with a pointer to a struct xdp_rxq_info (allowing for easier extending this later). This xdp_rxq_info contains

[PATCH] Bluetooth: Prevent stack info leak from the EFS element.

2017-12-08 Thread Greg Kroah-Hartman
From: Ben Seri In the function l2cap_parse_conf_rsp and in the function l2cap_parse_conf_req the following variable is declared without initialization: struct l2cap_conf_efs efs; In addition, when parsing input configuration parameters in both of these functions, the switch

Re: [PATCH net-next] flow_dissector: dissect tunnel info outside __skb_flow_dissect()

2017-12-05 Thread David Miller
From: Simon Horman <simon.hor...@netronome.com> Date: Mon, 4 Dec 2017 11:31:48 +0100 > Move dissection of tunnel info to outside of the main flow dissection > function, __skb_flow_dissect(). The sole user of this feature, the flower > classifier, is updated to call tunnel

[PATCH net-next] flow_dissector: dissect tunnel info outside __skb_flow_dissect()

2017-12-04 Thread Simon Horman
Move dissection of tunnel info to outside of the main flow dissection function, __skb_flow_dissect(). The sole user of this feature, the flower classifier, is updated to call tunnel info dissection directly, using skb_flow_dissect_tunnel_info(). This results in a slightly less complex

[PATCH net-next 2/7] bpf: print liveness info to verifier log

2017-11-30 Thread Alexei Starovoitov
let verifier print register and stack liveness information into verifier log Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Daniel Borkmann --- kernel/bpf/verifier.c | 24 1 file

Re: [PATCH net] sit: update frag_off info

2017-11-30 Thread David Miller
From: Hangbin Liu <liuhang...@gmail.com> Date: Thu, 30 Nov 2017 10:41:14 +0800 > After parsing the sit netlink change info, we forget to update frag_off in > ipip6_tunnel_update(). Fix it by assigning frag_off with new value. > > Fixes: f37234160233 ("sit: add support of

Re: [PATCH net] sit: update frag_off info

2017-11-30 Thread Hangbin Liu
On Thu, Nov 30, 2017 at 03:08:51PM +0100, Nicolas Dichtel wrote: > Le 30/11/2017 à 03:41, Hangbin Liu a écrit : > > After parsing the sit netlink change info, we forget to update frag_off in > > ipip6_tunnel_update(). Fix it by assigning frag_off with new value. > > > >

Re: [PATCH net] sit: update frag_off info

2017-11-30 Thread Nicolas Dichtel
Le 30/11/2017 à 03:41, Hangbin Liu a écrit : > After parsing the sit netlink change info, we forget to update frag_off in > ipip6_tunnel_update(). Fix it by assigning frag_off with new value. > > Fixes: f37234160233 ("sit: add support of link creation via rtnl") I think it's

[PATCH net] sit: update frag_off info

2017-11-29 Thread Hangbin Liu
After parsing the sit netlink change info, we forget to update frag_off in ipip6_tunnel_update(). Fix it by assigning frag_off with new value. Fixes: f37234160233 ("sit: add support of link creation via rtnl") Reported-by: Jianlin Shi <ji...@redhat.com> Signed-off-by: Hang

Re: [test_rht_init] INFO: task swapper/0:1 blocked for more than 120 seconds.

2017-11-27 Thread Linus Torvalds
On Tue, Nov 21, 2017 at 3:52 AM, Fengguang Wu <fengguang...@intel.com> wrote: > Here is a different call trace related to rhashtable. > > It occurs in 17 out of 90 boots. > > [ 342.666234] Writes: Total: 4 Max/Min: 0/0 Fail: 0 > [ 381.918047] INFO: task swapper/0:1 b

Re: [PATCH net] geneve: only configure or fill UDP_ZERO_CSUM6_RX/TX info when CONFIG_IPV6

2017-11-23 Thread David Miller
From: Hangbin Liu <liuhang...@gmail.com> Date: Thu, 23 Nov 2017 11:27:24 +0800 > Stefano pointed that configure or show UDP_ZERO_CSUM6_RX/TX info doesn't > make sense if we haven't enabled CONFIG_IPV6. Fix it by adding > if IS_ENABLED(CONFIG_IPV6) check. > > Signed-off-by:

Re: [PATCH net] geneve: only configure or fill UDP_ZERO_CSUM6_RX/TX info when CONFIG_IPV6

2017-11-23 Thread Hangbin Liu
On Thu, Nov 23, 2017 at 01:35:26PM +0100, Stefano Brivio wrote: > On Thu, 23 Nov 2017 11:27:24 +0800 > Hangbin Liu <liuhang...@gmail.com> wrote: > > > Stefano pointed that configure or show UDP_ZERO_CSUM6_RX/TX info doesn't > > make sense if we haven't enabled CO

Re: [PATCH net] geneve: only configure or fill UDP_ZERO_CSUM6_RX/TX info when CONFIG_IPV6

2017-11-23 Thread Stefano Brivio
On Thu, 23 Nov 2017 11:27:24 +0800 Hangbin Liu <liuhang...@gmail.com> wrote: > Stefano pointed that configure or show UDP_ZERO_CSUM6_RX/TX info doesn't > make sense if we haven't enabled CONFIG_IPV6. Fix it by adding > if IS_ENABLED(CONFIG_IPV6) check. Thanks for fixing th

[PATCH net] geneve: only configure or fill UDP_ZERO_CSUM6_RX/TX info when CONFIG_IPV6

2017-11-22 Thread Hangbin Liu
Stefano pointed that configure or show UDP_ZERO_CSUM6_RX/TX info doesn't make sense if we haven't enabled CONFIG_IPV6. Fix it by adding if IS_ENABLED(CONFIG_IPV6) check. Signed-off-by: Hangbin Liu <liuhang...@gmail.com> --- drivers/net/geneve.c | 16 +++- 1 file chang

[PATCH net v2 08/10] bpftool: revert printing program device bound info

2017-11-20 Thread Jakub Kicinski
This reverts commit 928631e05495 ("bpftool: print program device bound info"). We will remove this API and redo it right in -next. Signed-off-by: Jakub Kicinski <jakub.kicin...@netronome.com> --- tools/bpf/bpftool/prog.c | 31 --- tools/include/

[PATCH net v2 09/10] bpf: revert report offload info to user space

2017-11-20 Thread Jakub Kicinski
This reverts commit bd601b6ada11 ("bpf: report offload info to user space"). The ifindex by itself is not sufficient, we should provide information on which network namespace this ifindex belongs to. After considering some options we concluded that it's best to just remove this A

[PATCH net 08/10] bpftool: revert printing program device bound info

2017-11-19 Thread Jakub Kicinski
This reverts commit 928631e05495 ("bpftool: print program device bound info"). We will remove this API and redo it right in -next. Signed-off-by: Jakub Kicinski <jakub.kicin...@netronome.com> --- tools/bpf/bpftool/prog.c | 31 --- tools/include/

[PATCH net 09/10] bpf: revert report offload info to user space

2017-11-19 Thread Jakub Kicinski
This reverts commit bd601b6ada11 ("bpf: report offload info to user space"). The ifindex by itself is not sufficient, we should provide information on which network namespace this ifindex belongs to. After considering some options we concluded that it's best to just remove this A

Re: [PATCHv2 net] sctp: check stream reset info len before making reconf chunk

2017-11-15 Thread David Miller
From: Xin Long <lucien@gmail.com> Date: Wed, 15 Nov 2017 17:00:11 +0800 > Now when resetting stream, if both in and out flags are set, the info > len can reach: > sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + > sizeof(struct sctp_strreset_inreq) + SCT

Re: [PATCHv2 net] sctp: check stream reset info len before making reconf chunk

2017-11-15 Thread Neil Horman
On Wed, Nov 15, 2017 at 05:00:11PM +0800, Xin Long wrote: > Now when resetting stream, if both in and out flags are set, the info > len can reach: > sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + > sizeof(struct sctp_strreset_inreq) + SCTP_MAX_STREAM(65535) &g

[PATCHv2 net] sctp: check stream reset info len before making reconf chunk

2017-11-15 Thread Xin Long
Now when resetting stream, if both in and out flags are set, the info len can reach: sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + sizeof(struct sctp_strreset_inreq) + SCTP_MAX_STREAM(65535) even without duplicated stream no, this value is far greater than the chunk's max

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-14 Thread Marcelo Ricardo Leitner
rman <nhor...@tuxdriver.com> > >> wrote: > >> > On Mon, Nov 13, 2017 at 01:39:27PM +0800, Xin Long wrote: > >> >> Now when resetting stream, if both in and out flags are set, the info > >> >> len can reach: > >> >> sizeof(

Re: [PATCH net] geneve: show remote address and checksum info even after link down

2017-11-14 Thread Eric Garver
c > > > index ed51018..b010db7 100644 > > > --- a/drivers/net/geneve.c > > > +++ b/drivers/net/geneve.c > > > @@ -1511,32 +1511,18 @@ static int geneve_fill_info(struct sk_buff *skb, > > > const struct net_device *dev) > > > if (nla_put_u32(skb, I

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-14 Thread Xin Long
Xin Long wrote: >> >> Now when resetting stream, if both in and out flags are set, the info >> >> len can reach: >> >> sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + >> >> sizeof(struct sctp_strreset_inreq) + SCTP_MAX_STREAM(

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-14 Thread Neil Horman
On Mon, Nov 13, 2017 at 11:15:40PM +0800, Xin Long wrote: > On Mon, Nov 13, 2017 at 11:09 PM, Neil Horman <nhor...@tuxdriver.com> wrote: > > On Mon, Nov 13, 2017 at 01:39:27PM +0800, Xin Long wrote: > >> Now when resetting stream, if both in and out flags are set, the

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-14 Thread Xin Long
:39:27PM +0800, Xin Long wrote: >> >> Now when resetting stream, if both in and out flags are set, the info >> >> len can reach: >> >> sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + >> >> sizeof(struct sctp_strreset_inreq) + SCTP_MAX_ST

Re: [PATCH net] geneve: show remote address and checksum info even after link down

2017-11-13 Thread Hangbin Liu
> > @@ -1511,32 +1511,18 @@ static int geneve_fill_info(struct sk_buff *skb, > > const struct net_device *dev) > > if (nla_put_u32(skb, IFLA_GENEVE_ID, vni)) > > goto nla_put_failure; > > > > - if (rtnl_dereference(geneve->sock

Re: [PATCH net] geneve: show remote address and checksum info even after link down

2017-11-13 Thread Eric Garver
On Mon, Nov 13, 2017 at 05:03:26PM +0800, Hangbin Liu wrote: > geneve->sock4/6 were added with geneve_open and released with geneve_stop. > So when geneve link down, we will not able to show remote address and > checksum info after commit 11387fe4a98 ("geneve: fix fil

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-13 Thread Marcelo Ricardo Leitner
On Mon, Nov 13, 2017 at 11:15:40PM +0800, Xin Long wrote: > On Mon, Nov 13, 2017 at 11:09 PM, Neil Horman <nhor...@tuxdriver.com> wrote: > > On Mon, Nov 13, 2017 at 01:39:27PM +0800, Xin Long wrote: > >> Now when resetting stream, if both in and out flags are set, the

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-13 Thread Xin Long
On Mon, Nov 13, 2017 at 11:09 PM, Neil Horman <nhor...@tuxdriver.com> wrote: > On Mon, Nov 13, 2017 at 01:39:27PM +0800, Xin Long wrote: >> Now when resetting stream, if both in and out flags are set, the info >> len can reach: >> sizeof(struct sctp_strreset_outr

Re: [PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-13 Thread Neil Horman
On Mon, Nov 13, 2017 at 01:39:27PM +0800, Xin Long wrote: > Now when resetting stream, if both in and out flags are set, the info > len can reach: > sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + > sizeof(struct sctp_strreset_inreq) + SCTP_MAX_STREAM(65535) &g

[PATCH net] geneve: show remote address and checksum info even after link down

2017-11-13 Thread Hangbin Liu
geneve->sock4/6 were added with geneve_open and released with geneve_stop. So when geneve link down, we will not able to show remote address and checksum info after commit 11387fe4a98 ("geneve: fix fill_info when using collect_metadata"). Fix this by reset back to the previous behavi

[PATCH net] sctp: check stream reset info len before making reconf chunk

2017-11-12 Thread Xin Long
Now when resetting stream, if both in and out flags are set, the info len can reach: sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) + sizeof(struct sctp_strreset_inreq) + SCTP_MAX_STREAM(65535) even without duplicated stream no, this value is far greater than the chunk's max

Re: [PATCH net-next] cxgb4: collect vpd info directly from hardware

2017-11-11 Thread David Miller
From: Rahul Lakkireddy Date: Fri, 10 Nov 2017 13:03:37 +0530 > Collect vpd information directly from hardware instead of software > adapter context. Move EEPROM physical address to virtual address > translation logic to t4_hw.c and update relevant files. > > Fixes:

[PATCH net-next] cxgb4: collect vpd info directly from hardware

2017-11-09 Thread Rahul Lakkireddy
Collect vpd information directly from hardware instead of software adapter context. Move EEPROM physical address to virtual address translation logic to t4_hw.c and update relevant files. Fixes: 6f92a6544f1a ("cxgb4: collect hardware misc dumps") Signed-off-by: Rahul Lakkireddy

Re: [PATCH net-next v2 03/15] bpf: report offload info to user space

2017-11-04 Thread Jakub Kicinski
On Sat, 4 Nov 2017 18:45:31 +0900, Alexei Starovoitov wrote: > On Fri, Nov 03, 2017 at 01:56:18PM -0700, Jakub Kicinski wrote: > > Extend struct bpf_prog_info to contain information about program > > being bound to a device. Since the netdev may get destroyed while > > program still exists we

Re: [PATCH net-next v2 03/15] bpf: report offload info to user space

2017-11-04 Thread Alexei Starovoitov
On Fri, Nov 03, 2017 at 01:56:18PM -0700, Jakub Kicinski wrote: > Extend struct bpf_prog_info to contain information about program > being bound to a device. Since the netdev may get destroyed while > program still exists we need a flag to indicate the program is > loaded for a device, even if

Re: [PATCH net-next 09/12] tools: bpftool: turn err() and info() macros into functions

2017-11-03 Thread Quentin Monnet
2017-11-002 17:59 UTC-0700 ~ Joe Perches <j...@perches.com> > On Mon, 2017-10-23 at 09:24 -0700, Jakub Kicinski wrote: >> From: Quentin Monnet <quentin.mon...@netronome.com> >> >> Turn err() and info() macros into functions. >> >> In order to avoi

[PATCH net-next v2 03/15] bpf: report offload info to user space

2017-11-03 Thread Jakub Kicinski
Extend struct bpf_prog_info to contain information about program being bound to a device. Since the netdev may get destroyed while program still exists we need a flag to indicate the program is loaded for a device, even if the device is gone. Signed-off-by: Jakub Kicinski

[PATCH net-next v2 04/15] bpftool: print program device bound info

2017-11-03 Thread Jakub Kicinski
ftool/prog.c +++ b/tools/bpf/bpftool/prog.c @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -229,6 +230,21 @@ static void print_prog_json(struct bpf_prog_info *info, int fd) info->tag[0], info->tag[1], info->tag[2], info->tag

[PATCH net-next 03/15] bpf: report offload info to user space

2017-11-03 Thread Jakub Kicinski
Extend struct bpf_prog_info to contain information about program being bound to a device. Since the netdev may get destroyed while program still exists we need a flag to indicate the program is loaded for a device, even if the device is gone. Signed-off-by: Jakub Kicinski

[PATCH net-next 04/15] bpftool: print program device bound info

2017-11-03 Thread Jakub Kicinski
ftool/prog.c +++ b/tools/bpf/bpftool/prog.c @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -229,6 +230,21 @@ static void print_prog_json(struct bpf_prog_info *info, int fd) info->tag[0], info->tag[1], info->tag[2], info->tag

Re: [PATCH net-next 09/12] tools: bpftool: turn err() and info() macros into functions

2017-11-02 Thread Joe Perches
On Mon, 2017-10-23 at 09:24 -0700, Jakub Kicinski wrote: > From: Quentin Monnet <quentin.mon...@netronome.com> > > Turn err() and info() macros into functions. > > In order to avoid naming conflicts with variables in the code, rename > them as p_err() and p_info() respect

[RFC 03/12] bpf: report offload info to user space

2017-10-31 Thread Jakub Kicinski
Extend struct bpf_prog_info to contain information about program being bound to a device. Since the netdev may get destroyed while program still exists we need a flag to indicate the program is loaded for a device, even if the device is gone. Signed-off-by: Jakub Kicinski

[RFC 04/12] bpftool: print program device bound info

2017-10-31 Thread Jakub Kicinski
ftool/prog.c +++ b/tools/bpf/bpftool/prog.c @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -229,6 +230,21 @@ static void print_prog_json(struct bpf_prog_info *info, int fd) info->tag[0], info->tag[1], info->tag[2], info->tag

[PATCH iproute2 net-next v2 2/2] bridge: vlan: support for per vlan tunnel info

2017-10-27 Thread Roopa Prabhu
From: Roopa Prabhu <ro...@cumulusnetworks.com> This patch uses kernel bridge vlan attribute IFLA_BRIDGE_VLAN_TUNNEL_INFO to set/delete/show per vlan tunnel info. $bridge vlan add dev vxlan0 vid 2000 tunnel_info id 2000 $bridge vlan add dev vxlan0 vid 1000-1001 tunnel_info id 2000-2001 $

[PATCH iproute2 net-next 2/2] bridge: vlan: support for per vlan tunnel info

2017-10-26 Thread Roopa Prabhu
From: Roopa Prabhu <ro...@cumulusnetworks.com> This patch uses kernel bridge vlan attribute IFLA_BRIDGE_VLAN_TUNNEL_INFO to set/delete/show per vlan tunnel info. $bridge vlan add dev vxlan0 vid 2000 tunnel_info id 2000 $bridge vlan add dev vxlan0 vid 1000-1001 tunnel_info id 2000-2001 $

[PATCH net-next 4/8] cxgb4: collect TID info dump

2017-10-26 Thread Rahul Lakkireddy
Signed-off-by: Rahul Lakkireddy Signed-off-by: Ganesh Goudar --- drivers/net/ethernet/chelsio/cxgb4/cudbg_entity.h | 39 ++ drivers/net/ethernet/chelsio/cxgb4/cudbg_if.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c

Re: [PATCH V3 net-next] liquidio: pass date and time info to NIC firmware

2017-10-24 Thread David Miller
From: Felix Manlunas Date: Mon, 23 Oct 2017 20:33:25 -0700 > From: Veerasenareddy Burru > > Pass date and time information to NIC at the time of loading > firmware and periodically update the host time to NIC firmware. > This is to

[PATCH V3 net-next] liquidio: pass date and time info to NIC firmware

2017-10-23 Thread Felix Manlunas
en not accounting for it in subsequent date/time updates. For V3, all date/time updates are in Unix time. Octeon always uses UTC time. V1 -> V2: Follow reviewer's suggestion of periodically updating firmware with date and time info. drivers/net/ethernet/cavium/liqu

Re: [PATCH net-next 09/12] tools: bpftool: turn err() and info() macros into functions

2017-10-23 Thread Daniel Borkmann
On 10/23/2017 06:24 PM, Jakub Kicinski wrote: From: Quentin Monnet <quentin.mon...@netronome.com> Turn err() and info() macros into functions. In order to avoid naming conflicts with variables in the code, rename them as p_err() and p_info() respectively. The behavior of these fun

[PATCH net-next 09/12] tools: bpftool: turn err() and info() macros into functions

2017-10-23 Thread Jakub Kicinski
From: Quentin Monnet <quentin.mon...@netronome.com> Turn err() and info() macros into functions. In order to avoid naming conflicts with variables in the code, rename them as p_err() and p_info() respectively. The behavior of these functions is similar to the one of the macros for plain

Re: [PATCH net-next] spectrum: Convert fib event handlers to use container_of on info arg

2017-10-20 Thread David Miller
From: David Ahern Date: Wed, 18 Oct 2017 15:01:38 -0700 > Use container_of to convert the generic fib_notifier_info into > the event specific data structure. > > Signed-off-by: David Ahern > Reviewed-by: Ido Schimmel Applied.

Re: [PATCH net-next 3/8] tools: bpftool: use err() instead of info() if there are too many insns

2017-10-20 Thread Daniel Borkmann
On 10/20/2017 12:46 AM, Jakub Kicinski wrote: From: Quentin Monnet <quentin.mon...@netronome.com> Make error messages and return codes more consistent. Specifically, replace the use of info() macro with err() when too many eBPF instructions are received to be dumped, given that bpftool r

[PATCH net-next 3/8] tools: bpftool: use err() instead of info() if there are too many insns

2017-10-19 Thread Jakub Kicinski
From: Quentin Monnet <quentin.mon...@netronome.com> Make error messages and return codes more consistent. Specifically, replace the use of info() macro with err() when too many eBPF instructions are received to be dumped, given that bpftool returns with a non-null exit value in that case.

Re: [PATCH net-next] spectrum: Convert fib event handlers to use container_of on info arg

2017-10-19 Thread Jiri Pirko
Thu, Oct 19, 2017 at 12:01:38AM CEST, dsah...@gmail.com wrote: >Use container_of to convert the generic fib_notifier_info into >the event specific data structure. > >Signed-off-by: David Ahern >Reviewed-by: Ido Schimmel Acked-by: Jiri Pirko

[PATCH net-next] spectrum: Convert fib event handlers to use container_of on info arg

2017-10-18 Thread David Ahern
llanox/mlxsw/spectrum_router.c @@ -5209,25 +5209,35 @@ static void mlxsw_sp_router_fibmr_event_work(struct work_struct *work) static void mlxsw_sp_router_fib4_event(struct mlxsw_sp_fib_event_work *fib_work, struct fib_notifier_info *info) { +

Re: [PATCH V2 net-next] liquidio: pass date and time info to NIC firmware

2017-10-18 Thread Andrew Lunn
Hi Felix > +static void lio_sync_octeon_time(struct work_struct *work) > +{ > + struct cavium_wk *wk = (struct cavium_wk *)work; > + struct lio *lio = (struct lio *)wk->ctxptr; > + struct octeon_device *oct = lio->oct_dev; > + struct octeon_soft_command *sc; > + struct

[PATCH V2 net-next] liquidio: pass date and time info to NIC firmware

2017-10-18 Thread Felix Manlunas
lu...@cavium.com> --- Patch Change Log: V1 -> V2: Follow reviewer's suggestion of periodically updating firmware with date and time info. drivers/net/ethernet/cavium/liquidio/lio_main.c| 126 + .../net/ethernet/cavium/liquidio/liquidio_common.h | 8 ++

Re: [PATCH net-next 0/4] bpf: move context info out of the verifier

2017-10-18 Thread David Miller
roach to > move the info out of there. I want to be able to use different > set of verifier_ops for program analysis. To do that, I have > to first move the test_run callback to a separate structure. Then > verifier ops can be declared in the verifier directly and > different sets

Re: [PATCH net-next 0/4] bpf: move context info out of the verifier

2017-10-17 Thread Daniel Borkmann
On 10/17/2017 01:40 AM, Jakub Kicinski wrote: Hi! Daniel pointed out during the review of my previous patchset that the knowledge about context doesn't really belong directly in the verifier. This patch set takes a bit of a drastic approach to move the info out of there. I want to be able

[PATCH net-next 0/4] bpf: move context info out of the verifier

2017-10-16 Thread Jakub Kicinski
Hi! Daniel pointed out during the review of my previous patchset that the knowledge about context doesn't really belong directly in the verifier. This patch set takes a bit of a drastic approach to move the info out of there. I want to be able to use different set of verifier_ops for program

[PATCH net-next v2 4/7] net: qualcomm: rmnet: Remove duplicate setting of rmnet private info

2017-10-11 Thread Subash Abhinov Kasiviswanathan
The end point is set twice in the local_ep as well as the mux_id and the real_dev in the rmnet private structure. Remove the local_ep. While these elements are equivalent, rmnet_endpoint will be used only as part of the rmnet_port for muxed scenarios in VND mode. Signed-off-by: Subash Abhinov

[PATCH net-next 4/7] net: qualcomm: rmnet: Remove duplicate setting of rmnet private info

2017-10-10 Thread Subash Abhinov Kasiviswanathan
The end point is set twice in the local_ep as well as the mux_id and the real_dev in the rmnet private structure. Remove the local_ep. While these elements are equivalent, rmnet_endpoint will be used only as part of the rmnet_port for muxed scenarios in VND mode. Signed-off-by: Subash Abhinov

[PATCH net 4/7] net: qualcomm: rmnet: Remove duplicate setting of rmnet private info

2017-10-10 Thread Subash Abhinov Kasiviswanathan
The end point is set twice in the local_ep as well as the mux_id and the real_dev in the rmnet private structure. Remove the local_ep. While these elements are equivalent, rmnet_endpoint will be used only as part of the rmnet_port for muxed scenarios in VND mode. Fixes: ceed73a2cf4a ("drivers:

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-04 Thread Jiri Pirko
etronome.com> wrote: >> >>>> > On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote: >> >>>> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman >> >>>> >> <simon.hor...@netronome.com> wrote: >> >>>>

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-04 Thread Simon Horman
erbert wrote: > >>>> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman > >>>> >> <simon.hor...@netronome.com> wrote: > >>>> >> > Move dissection of tunnel info from the flower classifier to the > >>>&

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-04 Thread Jiri Pirko
rote: >>>> On Tue, Oct 3, 2017 at 2:40 AM, Simon Horman <simon.hor...@netronome.com> >>>> wrote: >>>> > On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote: >>>> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman >>>&

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-04 Thread Tom Herbert
.@netronome.com> >>> wrote: >>> > On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote: >>> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman >>> >> <simon.hor...@netronome.com> wrote: >>> >> > Move dissection o

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-04 Thread Jiri Pirko
:55PM -0700, Tom Herbert wrote: >> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.hor...@netronome.com> >> >> wrote: >> >> > Move dissection of tunnel info from the flower classifier to the flow >> >> > dissector where all other dissecti

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-04 Thread Simon Horman
<simon.hor...@netronome.com> > >> wrote: > >> > Move dissection of tunnel info from the flower classifier to the flow > >> > dissector where all other dissection occurs. This should not have any > >> > behavioural affect on other users of the flow diss

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-03 Thread Tom Herbert
On Tue, Oct 3, 2017 at 2:40 AM, Simon Horman <simon.hor...@netronome.com> wrote: > On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote: >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.hor...@netronome.com> >> wrote: >> > Move dissection of tu

Re: [PATCH net] net: rtnetlink: fix info leak in RTM_GETSTATS call

2017-10-03 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 3 Oct 2017 13:20:48 +0300 > When RTM_GETSTATS was added the fields of its header struct were not all > initialized when returning the result thus leaking 4 bytes of information > to user-space per rtnl_fill_statsinfo call, so

Re: [PATCH net] net: rtnetlink: fix info leak in RTM_GETSTATS call

2017-10-03 Thread Roopa Prabhu
On Tue, Oct 3, 2017 at 3:20 AM, Nikolay Aleksandrov wrote: > When RTM_GETSTATS was added the fields of its header struct were not all > initialized when returning the result thus leaking 4 bytes of information > to user-space per rtnl_fill_statsinfo call, so

[PATCH net] net: rtnetlink: fix info leak in RTM_GETSTATS call

2017-10-03 Thread Nikolay Aleksandrov
When RTM_GETSTATS was added the fields of its header struct were not all initialized when returning the result thus leaking 4 bytes of information to user-space per rtnl_fill_statsinfo call, so initialize them now. Thanks to Alexander Potapenko for the detailed report and bisection. Reported-by:

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-03 Thread Simon Horman
On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote: > On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.hor...@netronome.com> > wrote: > > Move dissection of tunnel info from the flower classifier to the flow > > dissector where all other dissection occurs.

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-02 Thread Tom Herbert
On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.hor...@netronome.com> wrote: > Move dissection of tunnel info from the flower classifier to the flow > dissector where all other dissection occurs. This should not have any > behavioural affect on other users of the flow dissec

Re: [oss-drivers] Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-02 Thread Simon Horman
On Mon, Oct 02, 2017 at 12:36:33PM -0700, Tom Herbert wrote: > On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.hor...@netronome.com> > wrote: > > Move dissection of tunnel info from the flower classifier to the flow > > dissector where all other dissection occurs.

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-02 Thread Tom Herbert
On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.hor...@netronome.com> wrote: > Move dissection of tunnel info from the flower classifier to the flow > dissector where all other dissection occurs. This should not have any > behavioural affect on other users of the flow dissec

Re: [PATCH net-next 0/2] flow_dissector: dissect tunnel info

2017-10-02 Thread David Miller
From: Simon Horman <simon.hor...@netronome.com> Date: Mon, 2 Oct 2017 10:41:14 +0200 > Move dissection of tunnel info from the flower classifier to the flow > dissector where all other dissection occurs. This should not have any > behavioural affect on other users of the flow dis

Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-02 Thread Jiri Pirko
Mon, Oct 02, 2017 at 10:41:16AM CEST, simon.hor...@netronome.com wrote: >Move dissection of tunnel info from the flower classifier to the flow >dissector where all other dissection occurs. This should not have any >behavioural affect on other users of the flow dissector. > >Signe

[PATCH net-next 2/2] flow_dissector: dissect tunnel info

2017-10-02 Thread Simon Horman
Move dissection of tunnel info from the flower classifier to the flow dissector where all other dissection occurs. This should not have any behavioural affect on other users of the flow dissector. Signed-off-by: Simon Horman <simon.hor...@netronome.com> Reviewed-by: Jakub Kicinski <ja

[PATCH net-next 0/2] flow_dissector: dissect tunnel info

2017-10-02 Thread Simon Horman
Move dissection of tunnel info from the flower classifier to the flow dissector where all other dissection occurs. This should not have any behavioural affect on other users of the flow dissector. Simon Horman (2): net/dst: Make skb parameter of skb{metadata_dst,tunnel_info}() const

Re: [PATCH net-next] liquidio: pass date and time info to NIC firmware

2017-09-25 Thread David Miller
From: Andrew Lunn Date: Sat, 23 Sep 2017 17:16:54 +0200 > On Fri, Sep 22, 2017 at 05:35:18PM -0700, Felix Manlunas wrote: >> From: Veerasenareddy Burru > > This is kind of interesting. So you do this once. It could be before > the RTC driver has

<    1   2   3   4   5   6   7   8   9   10   >