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

Hi Florian, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-dsa-Receive-path-simplifications/20170408-074503 config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget

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

Hi Florian, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-dsa-Receive-path-simplifications/20170408-074503 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 6.2.0 reproduce: wget

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

>> - trace_seq_printf(s, "#%-5u inner/outer(us): %4llu/%-5llu ts:%ld.%09ld", >> + trace_seq_printf(s, "#%-5u inner/outer(us): %4llu/%-5llu >> ts:%lld.%09ld", >>field->seqnum, >>field->duration, >>

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

On Fri, 7 Apr 2017 17:57:00 -0700 Deepa Dinamani wrote: > struct timespec is not y2038 safe on 32 bit machines > and needs to be replaced by struct timespec64 > in order to represent times beyond year 2038 on such > machines. > > Fix all the timestamp representation in

[PATCH 05/12] fs: ufs: Use ktime_get_real_ts64() for birthtime

CURRENT_TIME is not y2038 safe. Replace it with ktime_get_real_ts64(). Inode time formats are already 64 bit long and accommodates time64_t. Signed-off-by: Deepa Dinamani --- fs/ufs/ialloc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

struct timespec is not y2038 safe on 32 bit machines and needs to be replaced by struct timespec64 in order to represent times beyond year 2038 on such machines. Fix all the timestamp representation in struct trace_hwlat and all the corresponding implementations. Signed-off-by: Deepa Dinamani

[PATCH 10/12] apparmorfs: Replace CURRENT_TIME with current_time()

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time(). This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. current_time() is also planned to be

[PATCH 11/12] time: Delete CURRENT_TIME_SEC and CURRENT_TIME

All uses of CURRENT_TIME_SEC and CURRENT_TIME macros have been replaced by other time functions. These macros are also not y2038 safe. And, all their use cases can be fulfilled by y2038 safe ktime_get_* variants. Signed-off-by: Deepa Dinamani Acked-by: John Stultz

[PATCH 09/12] lustre: Replace CURRENT_TIME macro

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time() for filesystem times, and ktime_get_* functions for others. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as lustre uses it

[PATCH 07/12] fs: btrfs: Use ktime_get_real_ts for root ctime

btrfs_root_item maintains the ctime for root updates. This is not part of vfs_inode. Since current_time() uses struct inode* as an argument as Linus suggested, this cannot be used to update root times unless, we modify the signature to use inode. Since btrfs uses nanosecond time granularity, it

[PATCH 08/12] fs: ubifs: Replace CURRENT_TIME_SEC with current_time

CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transition CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() returns timestamps according to the granularities set in the inode's

[PATCH 12/12] time: Delete current_fs_time() function

All uses of the current_fs_time() function have been replaced by other time interfaces. And, its use cases can be fulfilled by current_time() or ktime_get_* variants. Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann --- include/linux/fs.h | 1 -

[PATCH 03/12] fs: cifs: Replace CURRENT_TIME by other appropriate apis

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time() for filesystem times, and ktime_get_* functions for authentication timestamps and timezone calculations. This is also in preparation for the patch that transitions vfs

[PATCH 06/12] audit: Use timespec64 to represent audit timestamps

struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto

[PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

CURRENT_TIME is not y2038 safe. The macro will be deleted and all the references to it will be replaced by ktime_get_* apis. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as ceph uses it internally everywhere. These references will be changed to use

[PATCH 01/12] fs: f2fs: Use ktime_get_real_seconds for sit_info times

CURRENT_TIME_SEC is not y2038 safe. Replace use of CURRENT_TIME_SEC with ktime_get_real_seconds in segment timestamps used by GC algorithm including the segment mtime timestamps. Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann ---

[PATCH 00/12] Delete CURRENT_TIME, CURRENT_TIME_SEC and current_fs_time

The series contains the last unmerged uses of CURRENT_TIME, CURRENT_TIME_SEC, and current_fs_time(). The series also deletes these apis. All the patches except [PATCH 9/12] and [PATCH 10/12] are resend patches. These patches fix new instances of CURRENT_TIME. cifs and ceph patches have been

Re: [4.4-RT PATCH RFC/RFT] drivers: net: cpsw: mark rx/tx irq as IRQF_NO_THREAD

Hi Sebastian, On 09/09/2016 07:46 AM, Grygorii Strashko wrote: > On 09/08/2016 07:00 PM, Sebastian Andrzej Siewior wrote: >> On 2016-08-19 17:29:16 [+0300], Grygorii Strashko wrote: >>> I've collected trace before first occurrence of "NOHZ: >>> local_softirq_pending 80" >>> > >> >>>

Re: [PATCH 02/12] ftgmac100: Move ftgmac100_hard_start_xmit() around

On Fri, 2017-04-07 at 05:49 -0700, David Miller wrote: > >    /* Tx ring */ > > + struct sk_buff *tx_skbs[TX_QUEUE_ENTRIES]; > >    unsigned int tx_clean_pointer; > >    unsigned int tx_pointer; > >    unsigned int tx_pending; > > Add this only in patch #6 or wherever it is

Re: [PATCH 11/12] ftgmac100: Add support for fragmented tx

On Fri, 2017-04-07 at 06:26 -0700, Florian Fainelli wrote: > > On 04/06/2017 08:31 PM, Benjamin Herrenschmidt wrote: > > Add NETIF_F_SG and create multiple TX ring entries for skb fragments. > > > > On reclaim, the skb is only freed on the segment marked as "last". > > > > > > Signed-off-by:

Re: [PATCH 05/12] ftgmac100: Pad small frames properly

On Fri, 2017-04-07 at 06:05 -0700, Florian Fainelli wrote: > You may want to use skb_put_padto() which also takes care of bumping > skb->len accordingly, in case that makes a difference for the > ftgmac100 hardware. Subsequent patch adds fragments, so it needs to bump headlen. I'll have a look

Re: [PATCH 02/12] ftgmac100: Move ftgmac100_hard_start_xmit() around

On Fri, 2017-04-07 at 13:09 +0300, Sergei Shtylyov wrote: > Hello! > > On 4/7/2017 6:30 AM, Benjamin Herrenschmidt wrote: > > > Move it below ftgmac100_xmit() and the rest of the tx path > > > > No code change. > > > > Signed-off-by: Benjamin Herrenschmidt > > --- >

[PATCH net-next] gso: Support frag_list splitting with head_frag

From: Ilan Tayari A driver may use build_skb() for received packets. These SKBs then have a head_frag. Since commit d7e8883cfcf4 ("net: make GRO aware of skb->head_frag"), GRO may build frag_list SKBs out of head_frag received SKBs. In such a case, the chained SKBs end up

[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

[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 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 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 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):

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

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: [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: thunderx: Enable TSO and checksum offloads for ipv6

From: dev.srinivas...@gmail.com Date: Thu, 6 Apr 2017 16:12:26 +0530 > From: Thanneeru Srinivasulu > > Adding support for TSO and checksum hardware offloads for ipv6. > > Signed-off-by: Thanneeru Srinivasulu > Signed-off-by: Sunil Goutham

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

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 wrote: >> > On Sun, Apr 02, 2017 at 04:10:12PM -0400, Willem de Bruijn wrote: >>

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

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 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 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 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 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 RFC v2 0/2] phylib non-autoneg speed setting

On 04/06/2017 03:00 AM, Russell King - ARM Linux wrote: > This set of two patches fixes and cleans up the phylib code associated > with selecting the fixed mode. > > phylib currently assumes that all PHYs will support the 10baseT/Half mode > of operation irrespective of the supported bitmask,

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

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 skb. Signed-off-by: Florian Fainelli

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

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 --- net/dsa/tag_brcm.c| 3 --- net/dsa/tag_dsa.c | 3 --- net/dsa/tag_edsa.c| 3 ---

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

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 counters - call netif_receive_skb() Factor all of that into

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

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 point. Florian Fainelli (3): net: dsa: Do not check for NULL dst in tag

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

On Fri, 2017-04-07 at 12:55 -0700, David Miller wrote: > > One idea.  We use the macro thing to generate a "netlink.pot" file > and then some userland tree can contain the latest netlink.pot and > the translations. Right. For the record - since we just talked about it - I was thinking of putting

[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 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 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: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:45 +0200, Pablo Neira Ayuso wrote: > > We only need to store the pointer to the attribute in the error > container structure. We can calculate the offset from nl_err() by > pasing the skbuff as parameter there, right? Ah, that's a good point, we could store the nlattr

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

On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote: > > I have no strong opinions about string length. > > In my opinion, I would like to believe that if someone tried to get a > networking patch applied that emitted a rediculously long string then > we would give them feedback about how that

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

On Fri, Apr 07, 2017 at 09:29:17PM +0200, Johannes Berg wrote: > On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote: > > I think the most flexible way is to pass the container error > > structure to nla_parse() so it sets this for you. This would also > > save tons of "malformed attribute"

Re: [PATCH net-next v4 1/5] dt-bindings: net: dsa: add Mediatek MT7530 binding

On 04/07/2017 01:45 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add device-tree binding for Mediatek MT7530 switch. > > Cc: devicet...@vger.kernel.org > Signed-off-by: Sean Wang > Acked-by: Rob Herring

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

On 04/07/2017 01:45 AM, 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 and 5-port Gigabit

[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

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 >>

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: [PATCH net-next v4 1/5] dt-bindings: net: dsa: add Mediatek MT7530 binding

On Fri, Apr 07, 2017 at 04:45:05PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add device-tree binding for Mediatek MT7530 switch. > > Cc: devicet...@vger.kernel.org > Signed-off-by: Sean Wang > Acked-by: Rob Herring

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: [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: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: [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

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: [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: [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, 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 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

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: >> [...] >> > Heh. I think I really want to solve - at least partially - >> >

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 2/3] genetlink: pass extended error report down

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 the err_str logic free it when done? We

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

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 that it can be done this way. It'd be nice to even transform > > all > >

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

On Fri, 2017-04-07 at 21:02 +0200, Pablo Neira Ayuso wrote: > > > I'm tempted to apply this as-is just to show that person that > > things do in fact happen eventually :-) > > We can just send follow up patches to refine, I think it's a good > start, Johannes? I guess we can. Like I just

Re: [Intel-wired-lan] [PATCH v2] igb: Allow to remove administratively set MAC on VFs

On Wed, 2017-04-05 at 15:46 +0200, Corinna Vinschen wrote: >   Before libvirt modifies the MAC address and vlan tag for an SRIOV > VF >   for use by a virtual machine (either using vfio device assignment > or >   macvtap passthru mode), it saves the current MAC address and vlan > tag >   so that

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

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 that it can be done this way. It'd be nice to even transform all > the callers (I generated half of these patches with spatch anyway) to > have at

Re: [PATCH v2 1/2] bpf: remove struct bpf_prog_type_list

So two things about this, and they apply to the other patch as well: > +extern const struct bpf_verifier_ops sk_filter_prog_ops; > +extern const struct bpf_verifier_ops tc_cls_act_prog_ops; > +extern const struct bpf_verifier_ops xdp_prog_ops; > +extern const struct bpf_verifier_ops

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

On Fri, Apr 07, 2017 at 11:53:15AM -0700, David Miller wrote: > From: Johannes Berg > Date: Fri, 7 Apr 2017 20:26:17 +0200 > > > So this is my first draft of what we'd talked about at netconf. > > I'm not super happy with the way we have to pass the extended > > error

[PATCH v2 2/2] bpf: remove struct bpf_map_type_list

From: Johannes Berg There's no need to have struct bpf_map_type_list since it just contains a list_head, the type, and the ops pointer. Since the types are densely packed and not actually dynamically registered, it's much easier and smaller to have an array of type->ops

[PATCH v2 1/2] bpf: remove struct bpf_prog_type_list

From: Johannes Berg There's no need to have struct bpf_prog_type_list since it just contains a list_head, the type, and the ops pointer. Since the types are densely packed and not actually dynamically registered, it's much easier and smaller to have an array of type->ops

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

On Fri, 2017-04-07 at 11:53 -0700, David Miller wrote: > > Alexander Shishkin had a nice way of reporting static extended > > error data, but that isn't really suitable for reporting the > > offset or even reporting the broken attribute from nla_parse(). > >  > > Speaking of nla_parse(), that'll

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

From: Johannes Berg Date: Fri, 7 Apr 2017 20:26:17 +0200 > So this is my first draft of what we'd talked about at netconf. > I'm not super happy with the way we have to pass the extended > error struct, but I don't see a way to implement reporting any > dynamic

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

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 firmware loading, GPIO control, and shared access for >> NFC, FM radio,

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

On Fri, 7 Apr 2017 21:16:49 +0300 Ido Schimmel wrote: > On Fri, Apr 07, 2017 at 01:37:53PM -0400, Stephen Hemminger wrote: > > Fix it right now. The patch you propose is too half baked. > > Given this patch needs to be back ported to three different stable > kernels I tried

Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

From: Yuchung Cheng Date: Fri, 7 Apr 2017 11:42:05 -0700 > The recent extension of F-RTO 89fe18e44 ("tcp: extend F-RTO > to catch more spurious timeouts") interacts badly with certain > broken middle-boxes. These broken boxes modify and falsely raise > the receive window on

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

On Fri, 7 Apr 2017 21:16:49 +0300 Ido Schimmel wrote: > On Fri, Apr 07, 2017 at 01:37:53PM -0400, Stephen Hemminger wrote: > > Fix it right now. The patch you propose is too half baked. > > Given this patch needs to be back ported to three different stable > kernels I tried

[PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

The recent extension of F-RTO 89fe18e44 ("tcp: extend F-RTO to catch more spurious timeouts") interacts badly with certain broken middle-boxes. These broken boxes modify and falsely raise the receive window on the ACKs. During a timeout induced recovery, F-RTO would send new data packets to probe

Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")

From: Eric Dumazet Date: Fri, 07 Apr 2017 11:38:49 -0700 > I do not really see what could be wrong, the code should run just fine > on UP. One theory is that the interrupt masking isn't working properly and interrupts are still arriving and hitting the NAPI state even

[PATCH net-next] netvsc: use napi_consume_skb

This allows using deferred skb freeing and with NAPI. And get buffer recycling. Signed-off-by: Stephen Hemminger --- drivers/net/hyperv/netvsc.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/hyperv/netvsc.c

Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")

On Fri, 2017-04-07 at 21:17 +0300, Ville Syrjälä wrote: > Hi, > > My old P3 laptop started to die on me in the middle of larger compile > jobs (using distcc) after v4.11-rc. I bisected the problem > to 617f01211baf ("8139too: use napi_complete_done()"). > > Unfortunately I wasn't able to capture

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

On 04/07/2017 11:26 AM, Johannes Berg wrote: From: Johannes Berg Signed-off-by: Johannes Berg --- include/net/genetlink.h | 27 +++ net/netlink/genetlink.c | 6 -- 2 files changed, 31 insertions(+), 2 deletions(-)

[net-next 7/7] net/mlx5e: Set default RX moderation parameters on driver load

RX moderation default parameters shouldn't be set in mlx5e_build_rx_cq_param since it would reset the values every time on netdev open/close. Instead, it should be set in mlx5e_set_rx_cq_mode_params which is called on driver load only. Fixes: 6a9764efb255 ("net/mlx5e: Isolate open_channels from

[net-next 4/7] net/mlx5e: Change FW sub_minor display to 4 zeros padding

From: Eran Ben Elisha FW version should be reported as X.Y., add leading zeroes to sub minor in order to fix it. Signed-off-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed ---

[net-next 3/7] net/mlx5e: Make mlx5e_modify_rqs_vsd a static function

From: Guy Ergas Make mlx5e_modify_rqs_vsd a static function and remove from en.h in order to reduce redundant exposure of functions. Signed-off-by: Guy Ergas Signed-off-by: Saeed Mahameed ---

  1   2   3   >