Re: [PATCH v2] net: Remove unnecessary cast on void pointer

On Wed, Mar 29, 2017 at 12:35:16AM +0530, simran singhal wrote: > The following Coccinelle script was used to detect this: > @r@ > expression x; > void* e; > type T; > identifier f; > @@ > ( > *((T *)e) > | > ((T *)x)[...] > | > ((T*)x)->f > | > > - (T*) > e > ) > > Unnecessary

Re: [PATCH] RDS: IB: ensure an initialized ret is printed in pr_warn message

Setting it to zero doesn't seem like the right thing, it should be an error code. Oh, heh... Smatch parses this one correctly. "ret" is always initialized but the code is probably buggy in a different way: net/rds/ib_rdma.c 539 void *rds_ib_get_mr(struct scatterlist *sg, unsigned long

Re: [PATCH v2 4/4] net: dsa: LAN9303: add MDIO managed mode support

On Fri, Apr 07, 2017 at 10:15:02AM +0200, Juergen Borleis wrote: > When the LAN9303 device is in MDIO manged mode, all register accesses must > be done via MDIO. > > Please note: this code is *untested* yet due to the absence of such > configured hardware. It is based on a patch of Stefan Roese

Re: [PATCH net] bridge: netlink: register netdevice before executing changelink

On Fri, 7 Apr 2017 18:27:37 +0300 Nikolay Aleksandrov wrote: > On 07/04/17 18:22, Stephen Hemminger wrote: > > On Fri, 7 Apr 2017 17:19:48 +0300 > > Nikolay Aleksandrov wrote: > > > >> On 07/04/17 17:10, Stephen Hemminger wrote: >

Re: [PATCH RFC net-next v3 4/7] net: use skb->csum_algo to identify packets needing crc32c

On Fri, Apr 7, 2017 at 7:16 AM, Davide Caratti wrote: > skb->csum_algo carries the indication on which algorithm is needed to > compute checksum on skb in the transmit path, when skb->ip_summed is > equal to CHECKSUM_PARTIAL. If skb carries a SCTP packet and crc32c > hasn't

Re: [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 18:36, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 18:27:37 +0300 > Nikolay Aleksandrov wrote: > >> On 07/04/17 18:22, Stephen Hemminger wrote: >>> On Fri, 7 Apr 2017 17:19:48 +0300 >>> Nikolay Aleksandrov wrote: >>>

Re: [PATCH v2 4/4] net: dsa: LAN9303: add MDIO managed mode support

> +static const struct of_device_id lan9303_mdio_of_match[] = { > + { .compatible = "smsc,lan9303" }, > + { /* sentinel */ }, > +}; We still have the open question of is it a problem to have two different drivers using the same compatible string. Changing these strings is hard, once they

Re: [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 17:10, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 15:49:15 +0300 > wrote: > >> From: Ido Schimmel >> >> Peter reported a kernel oops when executing the following command: >> >> $ ip link add name test type bridge vlan_default_pvid 1 >> >>

Re: [PATCH net-next 1/1] skbuff: Extend gso_type to unsigned int.

On Mon, Apr 3, 2017 at 1:15 AM, Steffen Klassert wrote: > All available gso_type flags are currently in use, so > extend gso_type from 'unsigned short' to 'unsigned int' > to be able to add further flags. > > We also reorder the struct skb_shared_info to use > two

Re: [PATCH v2 4/4] net: dsa: LAN9303: add MDIO managed mode support

> +static const struct of_device_id lan9303_mdio_of_match[] = { > + { .compatible = "smsc,lan9303" }, > + { /* sentinel */ }, > +}; I just chatted with Dave about this. Please include mdio and i2c in the compatible string, so they are different. That will avoid any possible problems.

Re: [PATCH] net: netfilter: Use seq_puts()/seq_putc() where possible

On Wed, Mar 29, 2017 at 03:25:17AM +0530, simran singhal wrote: > For string without format specifiers, use seq_puts(). For > seq_printf("\n"), use seq_putc('\n'). Applied, thanks.

Re: linux-next: manual merge of the net-next tree with the net tree

On Thu, Apr 6, 2017 at 5:12 PM, Stephen Rothwell wrote: > diff --cc net/sched/sch_generic.c > index 1a2f9e964330,3e64d23e098c.. > --- a/net/sched/sch_generic.c > +++ b/net/sched/sch_generic.c > @@@ -794,8 -794,8 +794,8 @@@ static void attach_default_qdiscs(struc

Re: [RFC 2/3] genetlink: pass extended error report down

On 04/07/2017 12:12 PM, Johannes Berg wrote: On Fri, 2017-04-07 at 11:37 -0700, Ben Greear wrote: I guess the error string must be constant and always available in memory in this implementation? Yes. I think it would be nice to dynamically create strings (malloc, snprintf, etc) and have

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:20 -0700, David Miller wrote: > But what it lacks fundamentally is context.  Therefore it can't be > used to provide the offset or the bad attribute number.  So it can't > meet our requirements. Yes, it doesn't address the requirements here, and in a sense I suspect this

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 12:22:23PM -0700, David Miller wrote: > From: Johannes Berg > Date: Fri, 07 Apr 2017 21:09:45 +0200 > > > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: > >> On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: > >> [...]

Re: [RFC 1/3] netlink: extended error reporting

On Fri, 2017-04-07 at 20:26 +0200, Johannes Berg wrote: > > + if (nlk->flags & NETLINK_F_EXT_ACK) { > + if (exterr && exterr->msg) > + WARN_ON(nla_put_string(skb, > NLMSGERR_ATTR_MSG, > +    exterr->msg)); > +

Re: [RFC 0/3] netlink: extended error reporting

From: Johannes Berg Date: Fri, 07 Apr 2017 21:46:46 +0200 > On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote: >> I suspect that someone will eventually give us a hard time about the >> strings wrt. internationalization. :-) It's solvable at least >> partially in

Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support

On Fri, 2017-04-07 at 13:48 -0500, Rob Herring wrote: > On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams > wrote: > > On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote: > > > Turns out that the LL protocol and the TI-ST are the same thing > > > AFAICT. > > > The TI-ST adds

Re: [RFC 0/3] netlink: extended error reporting

From: Johannes Berg Date: Fri, 07 Apr 2017 20:59:12 +0200 > Alexander Shishkin's patch > https://patchwork.kernel.org/patch/7162421/ > > was nice in a way because you could get away without passing the error > structure down all the time, but like I said it doesn't

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 09:09:45PM +0200, Johannes Berg wrote: > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: > > On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: > > [...] > > > Heh. I think I really want to solve - at least partially - > > > nla_parse() > > > to see

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote: [...] > Let's just discuss the UAPI, since people complain we don't talk > about that enough :-) For those playing at home it is three new > attributes returned in a netlink ACK when the application asks > for the extended response: >

Re: [RFC 0/3] netlink: extended error reporting

From: Pablo Neira Ayuso Date: Fri, 7 Apr 2017 21:35:50 +0200 > On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote: > [...] >> Let's just discuss the UAPI, since people complain we don't talk >> about that enough :-) For those playing at home it is three new >>

[RFC] netlink: send exterr cookie on success

From: Johannes Berg This is for Jamal, it allows the subsystem to return an arbitrary cookie to identify a new object/operation, perhaps to delete or cancel it later. This is actually something we use a lot in wifi too, though I'm not sure how we could do the backport

[vhost:linux-next 13/26] drivers//virtio/virtio_pci_common.c:186:7: error: too few arguments to function 'vp_dev->setup_vq'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 4293ed1476ec42e45e54f812341058d812d820a5 commit: d5edad95c2f89cced19a23713f752442b620f0e1 [13/26] virtio: add context flag to find vqs config: x86_64-randconfig-x012-201714 (attached as .config) compiler:

Re: [PATCH net-next 1/3] net: dsa: Do not check for NULL dst in tag parsers

On Fri, Apr 07, 2017 at 01:41:52PM -0700, Florian Fainelli wrote: > dsa_switch_rcv() already tests for dst == NULL, so there is no need to > duplicate > the same check within the tag receive functions. > > Signed-off-by: Florian Fainelli Reviewed-by: Andrew Lunn

Re: [PATCH net-next 1/3] net: dsa: Do not check for NULL dst in tag parsers

Florian Fainelli writes: > dsa_switch_rcv() already tests for dst == NULL, so there is no need to > duplicate > the same check within the tag receive functions. > > Signed-off-by: Florian Fainelli Reviewed-by: Vivien Didelot

Re: [PATCH net-next 0/3] net: dsa: Receive path simplifications

On 04/07/2017 01:53 PM, Andrew Lunn wrote: > On Fri, Apr 07, 2017 at 01:41:51PM -0700, Florian Fainelli wrote: >> Hi all, >> >> This patch series does factor the common code found in all tag >> implementations >> into dsa_switch_rcv(). The original motivation was to add GRO support, but >>

Re: [PATCH net-next 0/3] net: dsa: Receive path simplifications

From: Florian Fainelli Date: Fri, 7 Apr 2017 13:41:51 -0700 > This patch series does factor the common code found in all tag implementations > into dsa_switch_rcv(). The original motivation was to add GRO support, but > this > may be a lot of work with unclear benefits at

[PATCH net-next 4/8] rtnetlink: Do not generate notifications for POST_TYPE_CHANGE event

Changing the master device for a link generates many messages; the one generated for POST_TYPE_CHANGE is redundant: [LINK]11: dummy1: mtu 1500 qdisc noqueue master br1 state UNKNOWN group default event POST_TYPE_CHANGE link/ether 02:02:02:02:02:03 brd

[PATCH net-next 8/8] rtnetlink: Do not generate notifications for CHANGELOWERSTATE event

CHANGELOWERSTATE is an internal event; do not generate userspace notifications. Signed-off-by: David Ahern --- include/uapi/linux/if_link.h | 1 - net/core/rtnetlink.c | 4 2 files changed, 5 deletions(-) diff --git a/include/uapi/linux/if_link.h

[PATCH net-next 7/8] rtnetlink: Do not generate notifications for NOTIFY_PEERS event

NOTIFY_PEERS is an internal event; do not generate userspace notifications. Signed-off-by: David Ahern --- include/uapi/linux/if_link.h | 1 - net/core/rtnetlink.c | 4 2 files changed, 5 deletions(-) diff --git a/include/uapi/linux/if_link.h

Re: [PATCH net-next v4 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On Fri, Apr 07, 2017 at 04:45:09PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on > Mediatek router platforms such as MT7623A or MT7623N platform which > includes 7-port Gigabit Ethernet MAC

Re: [PATCH net-next 0/3] net: dsa: Receive path simplifications

On Fri, Apr 07, 2017 at 01:41:51PM -0700, Florian Fainelli wrote: > Hi all, > > This patch series does factor the common code found in all tag implementations > into dsa_switch_rcv(). The original motivation was to add GRO support, but > this > may be a lot of work with unclear benefits at this

Re: [PATCH net-next v4 0/5] net-next: dsa: add Mediatek MT7530 support

From: Date: Fri, 7 Apr 2017 16:45:04 +0800 > MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on > Mediatek router platforms such as MT7623A or MT7623N which includes 7-port > Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY. Among these ports, > The

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Mon, Apr 03, 2017 at 01:02:13AM -0400, Willem de Bruijn wrote: > On Sun, Apr 2, 2017 at 10:47 PM, Michael S. Tsirkin wrote: > > On Sun, Apr 02, 2017 at 04:10:12PM -0400, Willem de Bruijn wrote: > >> From: Willem de Bruijn > >> > >> Amortize the cost of

Re: [PATCH net-next 2/3] net: dsa: Move skb_unshare() to dsa_switch_rcv()

Florian Fainelli writes: > All DSA tag receive functions need to unshare the skb before mangling it, move > this to the generic dsa_switch_rcv() function which will allow us to make the > tag receive function return their mangled skb without caring about freeing a > NULL

Re: [PATCH net-next 3/3] net: dsa: Factor bottom tag receive functions

Florian Fainelli writes: > All DSA tag receive functions do strictly the same thing after they have > located > the originating source port from their tag specific protocol: > > - push ETH_HLEN bytes > - set pkt_type to PACKET_HOST > - call eth_type_trans() > - bump up

Re: [PATCH net-next 2/3] net: dsa: Move skb_unshare() to dsa_switch_rcv()

On Fri, Apr 07, 2017 at 01:41:53PM -0700, Florian Fainelli wrote: > All DSA tag receive functions need to unshare the skb before mangling it, move > this to the generic dsa_switch_rcv() function which will allow us to make the > tag receive function return their mangled skb without caring about

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Fri, Apr 07, 2017 at 04:59:58PM -0400, Willem de Bruijn wrote: > On Fri, Apr 7, 2017 at 3:28 PM, Michael S. Tsirkin wrote: > > On Mon, Apr 03, 2017 at 01:02:13AM -0400, Willem de Bruijn wrote: > >> On Sun, Apr 2, 2017 at 10:47 PM, Michael S. Tsirkin > >>

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Fri, Apr 7, 2017 at 5:10 PM, Michael S. Tsirkin wrote: > On Fri, Apr 07, 2017 at 04:59:58PM -0400, Willem de Bruijn wrote: >> On Fri, Apr 7, 2017 at 3:28 PM, Michael S. Tsirkin wrote: >> > On Mon, Apr 03, 2017 at 01:02:13AM -0400, Willem de Bruijn wrote: >>

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote: > > For my usecases in netfilter, the attributes and an specific error > code should be enough to figure out what is wrong. Will not need > strings. Fair enough. > BTW, we may not have an offset, eg. EINVAL because of missing >

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:27 +0200, Pablo Neira Ayuso wrote: > > > Also another way to look at this is that we're providing a lot of > > new power and expressability.  So even if only one aspect of the > > new error reporting is used it's a positive step forward. True. > > So allow offset "0"

Re: [RFC 0/3] netlink: extended error reporting

From: Pablo Neira Ayuso Date: Fri, 7 Apr 2017 21:27:14 +0200 > On Fri, Apr 07, 2017 at 12:22:23PM -0700, David Miller wrote: >> From: Johannes Berg >> Date: Fri, 07 Apr 2017 21:09:45 +0200 >> >> > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira

Re: [RFC 0/3] netlink: extended error reporting

From: Pablo Neira Ayuso Date: Fri, 7 Apr 2017 21:21:34 +0200 > For my usecases in netfilter, the attributes and an specific error > code should be enough to figure out what is wrong. Will not need > strings. > > BTW, we may not have an offset, eg. EINVAL because of missing

Re: [PATCH net-next 0/3] net: dsa: Receive path simplifications

> Yes, that's a good point, this just became slightly obsolete since the > mediatek tag code got included. Yes, rebase, add the received tags, and Dave can merge it before the next talk ends :-) Andrew

[PATCH net-next 1/8] rtnetlink: Do not generate notifications for MTU events

Changing MTU on a link currently causes 3 messages to be sent to userspace: [LINK]11: dummy1: mtu 1490 qdisc noqueue state UNKNOWN group default event PRE_CHANGE_MTU link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff [LINK]11: dummy1:

[PATCH net-next 6/8] rtnetlink: Do not generate notifications for PRECHANGEUPPER event

PRECHANGEUPPER is an internal event; do not generate userspace notifications. Signed-off-by: David Ahern --- include/uapi/linux/if_link.h | 1 - net/core/rtnetlink.c | 4 2 files changed, 5 deletions(-) diff --git a/include/uapi/linux/if_link.h

[PATCH net-next 2/8] rtnetlink: Do not generate notification for UDP_TUNNEL_PUSH_INFO

NETDEV_UDP_TUNNEL_PUSH_INFO is an internal notifier; nothing userspace can do so don't generate a netlink notification. Signed-off-by: David Ahern --- include/uapi/linux/if_link.h | 1 - net/core/rtnetlink.c | 4 2 files changed, 5 deletions(-) diff --git

[PATCH net-next 5/8] rtnetlink: Remove NETDEV_CHANGEINFODATA netdev event

Nobody cares about the event, so don't send it. Signed-off-by: David Ahern --- drivers/net/bonding/bond_options.c | 2 -- include/linux/netdevice.h | 1 - include/uapi/linux/if_link.h | 1 - net/core/rtnetlink.c | 4 4 files changed, 8

[PATCH net-next 3/8] rtnetlink: Do not generate notifications for CHANGEADDR event

Changing hardware address generates redundant messages: [LINK]11: dummy1: mtu 1500 qdisc noqueue state UNKNOWN group default event CHANGE_ADDR link/ether 02:02:02:02:02:02 brd ff:ff:ff:ff:ff:ff [LINK]11: dummy1: mtu 1500 qdisc

[PATCH net-next 0/8] rtnetlink: Cleanup user notifications for netdev events

Vlad's recent patch to add the event type to rtnetlink notifications points out a number of redundant or unnecessary notifications sent to userspace for events that are essentially internal to the kernel. Trim the list before the new IFLA attributes become part of the UAPI. David Ahern (8):

<    1   2   3