* SMSC95XX updates for packet alignment and turbo mode (V2)
From: Ben Dooks @ 2018-10-12 8:33 UTC (permalink / raw)
To: netdev; +Cc: oneukum, davem, linux-usb, linux-kernel, linux-kernel
This is the new seris of SMSC95XX patches to deal with the issues we
found when working on this driver for a client. The new series has been
tested on an Raspberry Pi3 B.
Changes since v1:
- Change memcpy to use {get,put}_unaligned_le32() calls
- Merge tx fixups
- Added rx_turbo attribute
^ permalink raw reply
* Re: [GIT] Networking
From: Greg KH @ 2018-10-12 8:23 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20181011.190615.78309421924776793.davem@davemloft.net>
On Thu, Oct 11, 2018 at 07:06:15PM -0700, David Miller wrote:
>
> 1) RXRPC receive path fixes from David Howells.
>
> 2) Re-export __skb_recv_udp(), from Jiri Kosina.
>
> 3) Fix refcounting in u32 classificer, from Al Viro.
>
> 4) Userspace netlink ABI fixes from Eugene Syromiatnikov.
>
> 5) Don't double iounmap on rmmod in ena driver, from Arthur
> Kiyanovski.
>
> 6) Fix devlink string attribute handling, we must pull a copy
> into a kernel buffer if the lifetime extends past the netlink
> request. From Moshe Shemesh.
>
> 7) Fix hangs in RDS, from Ka-Cheong Poon.
>
> 8) Fix recursive locking lockdep warnings in tipc, from Ying Xue.
>
> 9) Clear RX irq correctly in socionext, from Ilias Apalodimas.
>
> 10) bcm_sf2 fixes from Florian Fainelli.
>
> Please pull, thanks a lot!
>
> The following changes since commit c1d84a1b42ef70d8ae601df9cadedc7ed4f1beb1:
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-10-06 02:11:30 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>
Now merged, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH] virtio_net: enable tx after resuming from suspend
From: Jason Wang @ 2018-10-12 8:23 UTC (permalink / raw)
To: ake
Cc: Michael S. Tsirkin, David S. Miller, virtualization, netdev,
linux-kernel
In-Reply-To: <b294cbba-24a0-939d-98e8-d1483e3688a1@igel.co.jp>
On 2018年10月12日 12:30, ake wrote:
>
> On 2018年10月11日 22:06, Jason Wang wrote:
>>
>> On 2018年10月11日 18:22, ake wrote:
>>> On 2018年10月11日 18:44, Jason Wang wrote:
>>>> On 2018年10月11日 15:51, Ake Koomsin wrote:
>>>>> commit 713a98d90c5e ("virtio-net: serialize tx routine during reset")
>>>>> disabled the virtio tx before going to suspend to avoid a use after
>>>>> free.
>>>>> However, after resuming, it causes the virtio_net device to lose its
>>>>> network connectivity.
>>>>>
>>>>> To solve the issue, we need to enable tx after resuming.
>>>>>
>>>>> Fixes commit 713a98d90c5e ("virtio-net: serialize tx routine during
>>>>> reset")
>>>>> Signed-off-by: Ake Koomsin <ake@igel.co.jp>
>>>>> ---
>>>>> drivers/net/virtio_net.c | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>>> index dab504ec5e50..3453d80f5f81 100644
>>>>> --- a/drivers/net/virtio_net.c
>>>>> +++ b/drivers/net/virtio_net.c
>>>>> @@ -2256,6 +2256,7 @@ static int virtnet_restore_up(struct
>>>>> virtio_device *vdev)
>>>>> }
>>>>> netif_device_attach(vi->dev);
>>>>> + netif_start_queue(vi->dev);
>>>> I believe this is duplicated with netif_tx_wake_all_queues() in
>>>> netif_device_attach() above?
>>> Thank you for your review.
>>>
>>> If both netif_tx_wake_all_queues() and netif_start_queue() result in
>>> clearing __QUEUE_STATE_DRV_XOFF, then is it possible that some
>>> conditions in netif_device_attach() is not satisfied?
>> Yes, maybe. One case I can see now is when the device is down, in this
>> case netif_device_attach() won't try to wakeup the queue.
>>
>>> Without
>>> netif_start_queue(), the virtio_net device does not resume properly
>>> after waking up.
>> How do you trigger the issue? Just do suspend/resume?
> Yes, simply suspend and resume.
>
> Here is how I trigger the issue:
>
> 1) Start the Virtual Machine Manager GUI program.
> 2) Create a guest Linux OS. Make sure that the guest OS kernel is
> >= 4.12. Make sure that it uses virtio_net as its network device.
> In addition, make sure that the video adapter is VGA. Otherwise,
> waking up with the virtual power button does not work.
> 3) After installing the guest OS, log in, and test the network
> connectivity by ping the host machine.
> 4) Suspend. After this, the screen is blank.
> 5) Resume by hitting the virtual power button. The login screen
> appears again.
> 6) Log in again. The guest loses its network connection.
>
> In my test:
> Guest: Ubuntu 16.04/18.04 with kernel 4.15.0-36-generic
> Host: Ubuntu 16.04 with kernel 4.15.0-36-generic/4.4.0-137-generic
I can not reproduce this issue if virtio-net interface is up in guest
before the suspend. I'm using net-next.git and qemu master. But I do
reproduce when virtio-net interface is down in guest before suspend,
after resume, even if I make it up, the network is still lost.
I think the interface is up in your case, but please confirm this.
>
>>> Is it better to report this as a bug first?
>> Nope, you're very welcome to post patch directly.
>>
>>> If I am to do more
>>> investigation, what areas should I look into?
>> As you've figured out, you can start with why netif_tx_wake_all_queues()
>> were not executed?
>>
>> (Btw, does the issue disappear if you move netif_tx_disable() under the
>> check of netif_running() in virtnet_freeze_down()?)
> The issue disappears if I move netif_tx_disable() under the check of
> netif_running() in virtnet_freeze_down(). Moving netif_tx_disable()
> is probably better as its logic is consistent with
> netif_device_attach() implementation. If you are OK with this idea,
> I will submit another patch.
I think the it helps for the case when interface is down before suspend.
But it's still unclear why it help even if the interface is up
(netif_running() is true).
Please submit a patch but we should figure out why it help for a up
interface as well.
Thanks
>
>> Thanks
>>
>>> Best Regards
>>> Ake Koomsin
>>>
> Best Regards
^ permalink raw reply
* BUG: please report to dccp@vger.kernel.org => prev = 5, last = 5 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: syzbot @ 2018-10-12 7:58 UTC (permalink / raw)
To: davem, dccp, garsilva, gerrit, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 771b65e89c8a Add linux-next specific files for 20181011
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=167d2376400000
kernel config: https://syzkaller.appspot.com/x/.config?x=45f1c06c4da0a925
dashboard link: https://syzkaller.appspot.com/bug?extid=e326127852f785c44347
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e326127852f785c44347@syzkaller.appspotmail.com
BUG: please report to dccp@vger.kernel.org => prev = 5, last = 5 at
net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 4.19.0-rc7-next-20181011+ #92
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x3ab lib/dump_stack.c:113
tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
net/dccp/ccids/lib/packet_history.c:422
ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
sk_backlog_rcv include/net/sock.h:932 [inline]
__sk_receive_skb+0x3e0/0xeb0 net/core/sock.c:473
binder: send failed reply for transaction 41 to 27388:27389
dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
NF_HOOK include/linux/netfilter.h:289 [inline]
ip_local_deliver+0x1e4/0x740 net/ipv4/ip_input.c:256
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
NF_HOOK include/linux/netfilter.h:289 [inline]
ip_rcv+0xe8/0x600 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4908
__netif_receive_skb+0x27/0x1e0 net/core/dev.c:5018
process_backlog+0x24e/0x7a0 net/core/dev.c:5822
napi_poll net/core/dev.c:6242 [inline]
net_rx_action+0x7fa/0x19b0 net/core/dev.c:6308
__do_softirq+0x30d/0xb26 kernel/softirq.c:292
run_ksoftirqd+0x5e/0x100 kernel/softirq.c:654
smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
dccp_close: ABORT with 52224 bytes unread
binder: send failed reply for transaction 43 to 27399:27404
dccp_close: ABORT with 3584 bytes unread
binder: send failed reply for transaction 45 to 27417:27418
binder: send failed reply for transaction 47 to 27424:27425
dccp_close: ABORT with 105984 bytes unread
dccp_close: ABORT with 105984 bytes unread
dccp_close: ABORT with 105984 bytes unread
nf_conntrack: default automatic helper assignment has been turned off for
security reasons and CT-based firewall rule not found. Use the iptables CT
target to attach helpers instead.
Dead loop on virtual device ip6_vti0, fix it urgently!
Dead loop on virtual device ip6_vti0, fix it urgently!
Dead loop on virtual device ip6_vti0, fix it urgently!
Dead loop on virtual device ip6_vti0, fix it urgently!
Dead loop on virtual device ip6_vti0, fix it urgently!
Dead loop on virtual device ip6_vti0, fix it urgently!
IPVS: sync thread started: state = BACKUP, mcast_ifn = team_slave_0, syncid
= 0, id = 0
Dead loop on virtual device ip6_vti0, fix it urgently!
IPVS: sync thread started: state = BACKUP, mcast_ifn = team_slave_0, syncid
= 0, id = 0
IPVS: ftp: loaded support on port[0] = 21
\x01: renamed from bpq0
IPVS: ftp: loaded support on port[0] = 21
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH bpf-next v2 3/7] bpf: add MAP_LOOKUP_AND_DELETE_ELEM syscall
From: Alexei Starovoitov @ 2018-10-11 23:51 UTC (permalink / raw)
To: Mauricio Vasquez
Cc: Song Liu, Alexei Starovoitov, Daniel Borkmann, Networking
In-Reply-To: <44cde629-becb-09ee-1689-c82d87474367@polito.it>
On Wed, Oct 10, 2018 at 05:50:01PM -0500, Mauricio Vasquez wrote:
> > > Does it make sense to you?
> > I reread the other patch, and found it does NOT use the following logic for
> > queue and stack:
> >
> > rcu_read_lock();
> > ptr = map->ops->map_lookup_and_delete_elem(map, key);
> > if (ptr)
> > memcpy(value, ptr, value_size);
> >
> > I guess this part is not used at all? Can we just remove it?
> >
> > Thanks,
> > Song
>
> This is the base code for map_lookup_and_delete support, it is not used in
> queue/stack maps.
>
> I think we can leave it there, so when somebody implements lookup_and_delete
> for other maps doesn't have to care about implementing also this.
The code looks useful to me, but I also agree with Song. And in the kernel
we don't typically add 'almost dead code'.
May be provide an implementation of the lookup_and_delete for hash map
so it's actually used ?
imo it would be a useful feature to have for hash map and will clarify
the intent of it for all other maps and for stack/queue in particular.
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info
From: Greg KH @ 2018-10-12 6:36 UTC (permalink / raw)
To: haiyangz; +Cc: davem, netdev, olaf, sthemmin, linux-kernel, devel, vkuznets
In-Reply-To: <20181011201434.30737-1-haiyangz@linuxonhyperv.com>
On Thu, Oct 11, 2018 at 08:14:34PM +0000, Haiyang Zhang wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The VF device's serial number is saved as a string in PCI slot's
> kobj name, not the slot->number. This patch corrects the netvsc
> driver, so the VF device can be successfully paired with synthetic
> NIC.
>
> Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/net/hyperv/netvsc_drv.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 9bcaf204a7d4..8121ce34a39f 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -2030,14 +2030,15 @@ static void netvsc_vf_setup(struct work_struct *w)
> rtnl_unlock();
> }
>
> -/* Find netvsc by VMBus serial number.
> - * The PCI hyperv controller records the serial number as the slot.
> +/* Find netvsc by VF serial number.
> + * The PCI hyperv controller records the serial number as the slot kobj name.
> */
> static struct net_device *get_netvsc_byslot(const struct net_device *vf_netdev)
> {
> struct device *parent = vf_netdev->dev.parent;
> struct net_device_context *ndev_ctx;
> struct pci_dev *pdev;
> + u32 serial;
>
> if (!parent || !dev_is_pci(parent))
> return NULL; /* not a PCI device */
> @@ -2048,16 +2049,22 @@ static struct net_device *get_netvsc_byslot(const struct net_device *vf_netdev)
> return NULL;
> }
>
> + if (kstrtou32(pdev->slot->kobj.name, 10, &serial)) {
kobject_name()?
And that feels _very_ fragile to me. This is now an api that you are
guaranteeing will never change?
Good luck with that!
greg k-h
^ permalink raw reply
* [PATCH net-next v3 1/2] net/ncsi: Add NCSI Broadcom OEM command
From: Vijay Khemka @ 2018-10-11 23:05 UTC (permalink / raw)
To: Samuel Mendoza-Jonas, David S. Miller, netdev, linux-kernel
Cc: vijaykhemka, openbmc @ lists . ozlabs . org, Justin.Lee1, joel,
linux-aspeed
This patch adds OEM Broadcom commands and response handling. It also
defines OEM Get MAC Address handler to get and configure the device.
ncsi_oem_gma_handler_bcm: This handler send NCSI broadcom command for
getting mac address.
ncsi_rsp_handler_oem_bcm: This handles response received for all
broadcom OEM commands.
ncsi_rsp_handler_oem_bcm_gma: This handles get mac address response and
set it to device.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
net/ncsi/Kconfig | 6 ++++
net/ncsi/internal.h | 8 +++++
net/ncsi/ncsi-manage.c | 70 ++++++++++++++++++++++++++++++++++++++++++
net/ncsi/ncsi-pkt.h | 8 +++++
net/ncsi/ncsi-rsp.c | 40 +++++++++++++++++++++++-
5 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/net/ncsi/Kconfig b/net/ncsi/Kconfig
index 08a8a6031fd7..7f2b46108a24 100644
--- a/net/ncsi/Kconfig
+++ b/net/ncsi/Kconfig
@@ -10,3 +10,9 @@ config NET_NCSI
support. Enable this only if your system connects to a network
device via NCSI and the ethernet driver you're using supports
the protocol explicitly.
+config NCSI_OEM_CMD_GET_MAC
+ bool "Get NCSI OEM MAC Address"
+ depends on NET_NCSI
+ ---help---
+ This allows to get MAC address from NCSI firmware and set them back to
+ controller.
diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
index 3d0a33b874f5..45883b32790e 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -71,6 +71,13 @@ enum {
/* OEM Vendor Manufacture ID */
#define NCSI_OEM_MFR_MLX_ID 0x8119
#define NCSI_OEM_MFR_BCM_ID 0x113d
+/* Broadcom specific OEM Command */
+#define NCSI_OEM_BCM_CMD_GMA 0x01 /* CMD ID for Get MAC */
+/* OEM Command payload lengths*/
+#define NCSI_OEM_BCM_CMD_GMA_LEN 12
+/* Mac address offset in OEM response */
+#define BCM_MAC_ADDR_OFFSET 28
+
struct ncsi_channel_version {
u32 version; /* Supported BCD encoded NCSI version */
@@ -240,6 +247,7 @@ enum {
ncsi_dev_state_probe_dp,
ncsi_dev_state_config_sp = 0x0301,
ncsi_dev_state_config_cis,
+ ncsi_dev_state_config_oem_gma,
ncsi_dev_state_config_clear_vids,
ncsi_dev_state_config_svf,
ncsi_dev_state_config_ev,
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index 091284760d21..75504ccd1b95 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -635,6 +635,39 @@ static int set_one_vid(struct ncsi_dev_priv *ndp, struct ncsi_channel *nc,
return 0;
}
+#if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC)
+
+/* NCSI OEM Command APIs */
+static void ncsi_oem_gma_handler_bcm(struct ncsi_cmd_arg *nca)
+{
+ int ret = 0;
+ unsigned char data[NCSI_OEM_BCM_CMD_GMA_LEN];
+
+ nca->payload = NCSI_OEM_BCM_CMD_GMA_LEN;
+
+ memset(data, 0, NCSI_OEM_BCM_CMD_GMA_LEN);
+ *(unsigned int *)data = ntohl(NCSI_OEM_MFR_BCM_ID);
+ data[5] = NCSI_OEM_BCM_CMD_GMA;
+
+ nca->data = data;
+
+ ret = ncsi_xmit_cmd(nca);
+ if (ret)
+ netdev_err(nca->ndp->ndev.dev,
+ "NCSI: Failed to transmit cmd 0x%x during configure\n",
+ nca->type);
+}
+
+/* OEM Command handlers initialization */
+static struct ncsi_oem_gma_handler {
+ unsigned int mfr_id;
+ void (*handler)(struct ncsi_cmd_arg *nca);
+} ncsi_oem_gma_handlers[] = {
+ { NCSI_OEM_MFR_BCM_ID, ncsi_oem_gma_handler_bcm }
+};
+
+#endif /* CONFIG_NCSI_OEM_CMD_GET_MAC */
+
static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
{
struct ncsi_dev *nd = &ndp->ndev;
@@ -685,6 +718,43 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
goto error;
}
+#if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC)
+ nd->state = ncsi_dev_state_config_oem_gma;
+ break;
+ case ncsi_dev_state_config_oem_gma:
+ nca.type = NCSI_PKT_CMD_OEM;
+ nca.package = np->id;
+ nca.channel = nc->id;
+ ndp->pending_req_num = 1;
+
+ /* Check for manufacturer id and Find the handler */
+ struct ncsi_oem_gma_handler *nch = NULL;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ncsi_oem_gma_handlers); i++) {
+ if (ncsi_oem_gma_handlers[i].mfr_id ==
+ nc->version.mf_id) {
+ if (ncsi_oem_gma_handlers[i].handler)
+ nch = &ncsi_oem_gma_handlers[i];
+ else
+ nch = NULL;
+
+ break;
+ }
+ }
+
+ if (!nch) {
+ netdev_err(ndp->ndev.dev, "No handler available for GMA with MFR-ID (0x%x)\n",
+ nc->version.mf_id);
+ nd->state = ncsi_dev_state_config_clear_vids;
+ schedule_work(&ndp->work);
+ break;
+ }
+
+ /* Get Mac address from NCSI device */
+ nch->handler(&nca);
+#endif /* CONFIG_NCSI_OEM_CMD_GET_MAC */
+
nd->state = ncsi_dev_state_config_clear_vids;
break;
case ncsi_dev_state_config_clear_vids:
diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h
index 0f2087c8d42a..4d3f06be38bd 100644
--- a/net/ncsi/ncsi-pkt.h
+++ b/net/ncsi/ncsi-pkt.h
@@ -165,6 +165,14 @@ struct ncsi_rsp_oem_pkt {
unsigned char data[]; /* Payload data */
};
+/* Broadcom Response Data */
+struct ncsi_rsp_oem_bcm_pkt {
+ unsigned char ver; /* Payload Version */
+ unsigned char type; /* OEM Command type */
+ __be16 len; /* Payload Length */
+ unsigned char data[]; /* Cmd specific Data */
+};
+
/* Get Link Status */
struct ncsi_rsp_gls_pkt {
struct ncsi_rsp_pkt_hdr rsp; /* Response header */
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index d66b34749027..31672e967db2 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -596,12 +596,50 @@ static int ncsi_rsp_handler_snfc(struct ncsi_request *nr)
return 0;
}
+/* Response handler for Broadcom command Get Mac Address */
+static int ncsi_rsp_handler_oem_bcm_gma(struct ncsi_request *nr)
+{
+ struct ncsi_rsp_oem_pkt *rsp;
+ struct ncsi_dev_priv *ndp = nr->ndp;
+ struct net_device *ndev = ndp->ndev.dev;
+ int ret = 0;
+ const struct net_device_ops *ops = ndev->netdev_ops;
+ struct sockaddr saddr;
+
+ /* Get the response header */
+ rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
+
+ saddr.sa_family = ndev->type;
+ ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+ memcpy(saddr.sa_data, &rsp->data[BCM_MAC_ADDR_OFFSET], ETH_ALEN);
+ ret = ops->ndo_set_mac_address(ndev, &saddr);
+ if (ret < 0)
+ netdev_warn(ndev, "NCSI: Writing mac address to device failed\n");
+
+ return ret;
+}
+
+/* Response handler for Broadcom card */
+static int ncsi_rsp_handler_oem_bcm(struct ncsi_request *nr)
+{
+ struct ncsi_rsp_oem_pkt *rsp;
+ struct ncsi_rsp_oem_bcm_pkt *bcm;
+
+ /* Get the response header */
+ rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
+ bcm = (struct ncsi_rsp_oem_bcm_pkt *)(rsp->data);
+
+ if (bcm->type == NCSI_OEM_BCM_CMD_GMA)
+ return ncsi_rsp_handler_oem_bcm_gma(nr);
+ return 0;
+}
+
static struct ncsi_rsp_oem_handler {
unsigned int mfr_id;
int (*handler)(struct ncsi_request *nr);
} ncsi_rsp_oem_handlers[] = {
{ NCSI_OEM_MFR_MLX_ID, NULL },
- { NCSI_OEM_MFR_BCM_ID, NULL }
+ { NCSI_OEM_MFR_BCM_ID, ncsi_rsp_handler_oem_bcm }
};
/* Response handler for OEM command */
--
2.17.1
^ permalink raw reply related
* RE: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info
From: Vitaly Kuznetsov @ 2018-10-12 6:27 UTC (permalink / raw)
To: Haiyang Zhang
Cc: davem@davemloft.net, netdev@vger.kernel.org, KY Srinivasan,
Stephen Hemminger, olaf@aepfle.de, devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org
In-Reply-To: <MWHPR21MB0176EB148DC772F9DC5845D2CAE10@MWHPR21MB0176.namprd21.prod.outlook.com>
Haiyang Zhang <haiyangz@microsoft.com> writes:
>> -----Original Message-----
>> From: Haiyang Zhang <haiyangz@linuxonhyperv.com>
>> Sent: Thursday, October 11, 2018 4:15 PM
>> To: davem@davemloft.net; netdev@vger.kernel.org
>> Cc: Haiyang Zhang <haiyangz@microsoft.com>; KY Srinivasan
>> <kys@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>;
>> olaf@aepfle.de; vkuznets <vkuznets@redhat.com>;
>> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org
>> Subject: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info
>>
>> From: Haiyang Zhang <haiyangz@microsoft.com>
>>
>> The VF device's serial number is saved as a string in PCI slot's kobj name, not
>> the slot->number. This patch corrects the netvsc driver, so the VF device can be
>> successfully paired with synthetic NIC.
>>
>> Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
>> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
>
> Thanks Stephen for the reminder -- I added the "reported-by" here:
>
> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Thanks)
The difference in the hack I sent to Stephen was that instead of using
kstrtou32() and checking the return value I opted for snprintf() and
doing strncmp().
--
Vitaly
^ permalink raw reply
* Re: [PATCH bpf-next 3/8] bpf, sockmap: convert to generic sk_msg interface
From: Alexei Starovoitov @ 2018-10-11 22:57 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: john.fastabend, davejwatson, netdev
In-Reply-To: <20181011004547.16662-4-daniel@iogearbox.net>
On Thu, Oct 11, 2018 at 02:45:42AM +0200, Daniel Borkmann wrote:
> Add a generic sk_msg layer, and convert current sockmap and later
> kTLS over to make use of it. While sk_buff handles network packet
> representation from netdevice up to socket, sk_msg handles data
> representation from application to socket layer.
>
> This means that sk_msg framework spans across ULP users in the
> kernel, and enables features such as introspection or filtering
> of data with the help of BPF programs that operate on this data
> structure.
>
> Latter becomes in particular useful for kTLS where data encryption
> is deferred into the kernel, and as such enabling the kernel to
> perform L7 introspection and policy based on BPF for TLS connections
> where the record is being encrypted after BPF has run and came to
> a verdict. In order to get there, first step is to transform open
> coding of scatter-gather list handling into a common core framework
> that subsystems use.
>
> Joint work with John.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> include/linux/bpf.h | 33 +-
> include/linux/bpf_types.h | 2 +-
> include/linux/filter.h | 21 -
> include/linux/skmsg.h | 371 +++++++
> include/net/tcp.h | 27 +
> kernel/bpf/Makefile | 5 -
> kernel/bpf/core.c | 2 -
> kernel/bpf/sockmap.c | 2610 ---------------------------------------------
> kernel/bpf/syscall.c | 6 +-
> net/Kconfig | 11 +
> net/core/Makefile | 2 +
> net/core/filter.c | 270 ++---
> net/core/skmsg.c | 763 +++++++++++++
> net/core/sock_map.c | 1002 +++++++++++++++++
> net/ipv4/Makefile | 1 +
> net/ipv4/tcp_bpf.c | 655 ++++++++++++
> net/strparser/Kconfig | 4 +-
> 17 files changed, 2925 insertions(+), 2860 deletions(-)
> +void sk_msg_trim(struct sock *sk, struct sk_msg *msg, int len)
> +{
> + int trim = msg->sg.size - len;
> + u32 i = msg->sg.end;
> +
> + if (trim <= 0) {
> + WARN_ON(trim < 0);
> + return;
> + }
> +
> + sk_msg_iter_var_prev(i);
> + msg->sg.size = len;
> + while (msg->sg.data[i].length &&
> + trim >= msg->sg.data[i].length) {
> + trim -= msg->sg.data[i].length;
> + sk_msg_free_elem(sk, msg, i, true);
> + sk_msg_iter_var_prev(i);
> + if (!trim)
> + goto out;
> + }
> +
> + msg->sg.data[i].length -= trim;
> + sk_mem_uncharge(sk, trim);
> +out:
> + /* If we trim data before curr pointer update copybreak and current
> + * so that any future copy operations start at new copy location.
> + * However trimed data that has not yet been used in a copy op
> + * does not require an update.
> + */
> + if (msg->sg.curr >= i) {
> + msg->sg.curr = i;//msg->sg.end;
is this a leftover of some debugging ?
I think such giant patchset is impossible to review in reasonable
amount of time. I guess you've considered splitting it, but
couldn't find a way to do so ?
May be expand the commit log a bit more to explain not only _why_
(which is typical requiremnt), but _how_ the patchset is doing it?
Overall sk_msg generalization looks great to me. Especially
considering how it's used in the next patches,
but details are scary. sockmap was plagued with bugs that
syzbot found. Are we changing it a lot again or it's mainly
copy-paste/split into different files plus rename?
I'm willing to take a leap of faith and merge it, but would
love if commit log could make it easier to see what is going on.
^ permalink raw reply
* Re: [PATCH net 0/2] net: dsa: bcm_sf2: Couple of fixes
From: David Miller @ 2018-10-11 22:20 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot
In-Reply-To: <05eb558e-b20c-fab0-e111-f73948069e5a@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 11 Oct 2018 15:02:54 -0700
> On 10/10/2018 10:53 PM, David Miller wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue, 9 Oct 2018 16:48:56 -0700
>>
>>> Here are two fixes for the bcm_sf2 driver that were found during
>>> testing unbind and analysing another issue during system
>>> suspend/resume.
>>
>> Series applied and queued up for -stable, thanks.
>
> Did you push that series yet?
>
> git pull
> remote: Counting objects: 171, done.
> remote: Compressing objects: 100% (71/71), done.
> remote: Total 171 (delta 144), reused 118 (delta 100)
> Receiving objects: 100% (171/171), 32.80 KiB | 16.40 MiB/s, done.
> Resolving deltas: 100% (144/144), completed with 61 local objects.
> From https://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> 52b5d6f5dcf0..052858663db3 master -> davem-net/master
>
> git rebase net/master sf2-fixes
> First, rewinding head to replay your work on top of it...
> Applying: net: dsa: bcm_sf2: Fix unbind ordering
> Applying: net: dsa: bcm_sf2: Call setup during switch resume
I applied them to net-next, sorry about that.
I'll add them to 'net' too.
Done.
^ permalink raw reply
* Re: [PATCH net 0/2] net: dsa: bcm_sf2: Couple of fixes
From: Florian Fainelli @ 2018-10-11 22:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andrew, vivien.didelot
In-Reply-To: <20181010.225335.776879235761704804.davem@davemloft.net>
On 10/10/2018 10:53 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 9 Oct 2018 16:48:56 -0700
>
>> Here are two fixes for the bcm_sf2 driver that were found during
>> testing unbind and analysing another issue during system
>> suspend/resume.
>
> Series applied and queued up for -stable, thanks.
Did you push that series yet?
git pull
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 171 (delta 144), reused 118 (delta 100)
Receiving objects: 100% (171/171), 32.80 KiB | 16.40 MiB/s, done.
Resolving deltas: 100% (144/144), completed with 61 local objects.
>From https://git.kernel.org/pub/scm/linux/kernel/git/davem/net
52b5d6f5dcf0..052858663db3 master -> davem-net/master
git rebase net/master sf2-fixes
First, rewinding head to replay your work on top of it...
Applying: net: dsa: bcm_sf2: Fix unbind ordering
Applying: net: dsa: bcm_sf2: Call setup during switch resume
--
Florian
^ permalink raw reply
* Some suggestions for tc-tests
From: Cong Wang @ 2018-10-11 21:53 UTC (permalink / raw)
To: Roman Mashak; +Cc: Jamal Hadi Salim, Linux Kernel Network Developers
Hi,
I tried to run tc-tests with some old iproute2 package, it is painful.
I'd suggest the following improvements:
1. Create veth pair devices by its own. The most important thing for
tc-tests is to automate everything, it is not friendly for users to
create their own veth pair named v0p0 to just run the tests. tc-tests
should be able to create a veth pair with random names and clean up
them once it is finished.
2. Test iproute2 version or capability. Apparently my iproute2 doesn't
support tc filter chain yet, this makes many tests failed. Ideally,
each test should be able to check if the iproute2 supports the thing
it wants to test, if not just skip it, at least by default.
3. Is there anything in the tests that can be done only with Python3?
If we could lower the requirement to Python2, then it would be easier
to setup and run these tests.
Thanks!
^ permalink raw reply
* Re: [PATCH] virtio_net: enable tx after resuming from suspend
From: ake @ 2018-10-12 4:30 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, David S. Miller, virtualization, netdev,
linux-kernel
In-Reply-To: <a156fd7e-e36e-e4e9-c240-3117ecc5b1b4@redhat.com>
On 2018年10月11日 22:06, Jason Wang wrote:
>
>
> On 2018年10月11日 18:22, ake wrote:
>>
>> On 2018年10月11日 18:44, Jason Wang wrote:
>>>
>>> On 2018年10月11日 15:51, Ake Koomsin wrote:
>>>> commit 713a98d90c5e ("virtio-net: serialize tx routine during reset")
>>>> disabled the virtio tx before going to suspend to avoid a use after
>>>> free.
>>>> However, after resuming, it causes the virtio_net device to lose its
>>>> network connectivity.
>>>>
>>>> To solve the issue, we need to enable tx after resuming.
>>>>
>>>> Fixes commit 713a98d90c5e ("virtio-net: serialize tx routine during
>>>> reset")
>>>> Signed-off-by: Ake Koomsin <ake@igel.co.jp>
>>>> ---
>>>> drivers/net/virtio_net.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>> index dab504ec5e50..3453d80f5f81 100644
>>>> --- a/drivers/net/virtio_net.c
>>>> +++ b/drivers/net/virtio_net.c
>>>> @@ -2256,6 +2256,7 @@ static int virtnet_restore_up(struct
>>>> virtio_device *vdev)
>>>> }
>>>> netif_device_attach(vi->dev);
>>>> + netif_start_queue(vi->dev);
>>> I believe this is duplicated with netif_tx_wake_all_queues() in
>>> netif_device_attach() above?
>> Thank you for your review.
>>
>> If both netif_tx_wake_all_queues() and netif_start_queue() result in
>> clearing __QUEUE_STATE_DRV_XOFF, then is it possible that some
>> conditions in netif_device_attach() is not satisfied?
>
> Yes, maybe. One case I can see now is when the device is down, in this
> case netif_device_attach() won't try to wakeup the queue.
>
>> Without
>> netif_start_queue(), the virtio_net device does not resume properly
>> after waking up.
>
> How do you trigger the issue? Just do suspend/resume?
Yes, simply suspend and resume.
Here is how I trigger the issue:
1) Start the Virtual Machine Manager GUI program.
2) Create a guest Linux OS. Make sure that the guest OS kernel is
>= 4.12. Make sure that it uses virtio_net as its network device.
In addition, make sure that the video adapter is VGA. Otherwise,
waking up with the virtual power button does not work.
3) After installing the guest OS, log in, and test the network
connectivity by ping the host machine.
4) Suspend. After this, the screen is blank.
5) Resume by hitting the virtual power button. The login screen
appears again.
6) Log in again. The guest loses its network connection.
In my test:
Guest: Ubuntu 16.04/18.04 with kernel 4.15.0-36-generic
Host: Ubuntu 16.04 with kernel 4.15.0-36-generic/4.4.0-137-generic
>>
>> Is it better to report this as a bug first?
>
> Nope, you're very welcome to post patch directly.
>
>> If I am to do more
>> investigation, what areas should I look into?
>
> As you've figured out, you can start with why netif_tx_wake_all_queues()
> were not executed?
>
> (Btw, does the issue disappear if you move netif_tx_disable() under the
> check of netif_running() in virtnet_freeze_down()?)
The issue disappears if I move netif_tx_disable() under the check of
netif_running() in virtnet_freeze_down(). Moving netif_tx_disable()
is probably better as its logic is consistent with
netif_device_attach() implementation. If you are OK with this idea,
I will submit another patch.
> Thanks
>
>>
>> Best Regards
>> Ake Koomsin
>>
>
Best Regards
^ permalink raw reply
* [PATCH iproute2 net-next] ipneigh: support for NTF_EXT_LEARNED flag on neigh entries
From: Roopa Prabhu @ 2018-10-11 20:45 UTC (permalink / raw)
To: dsahern; +Cc: netdev
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Adds new option extern_learn to set NTF_EXT_LEARNED flag
on neigh entries.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
ip/ipneigh.c | 7 ++++++-
man/man8/ip-neighbour.8 | 9 ++++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/ip/ipneigh.c b/ip/ipneigh.c
index 165546e..042d01f 100644
--- a/ip/ipneigh.c
+++ b/ip/ipneigh.c
@@ -48,7 +48,7 @@ static void usage(void)
{
fprintf(stderr, "Usage: ip neigh { add | del | change | replace }\n"
" { ADDR [ lladdr LLADDR ] [ nud STATE ] | proxy ADDR } [ dev DEV ]\n");
- fprintf(stderr, " [ router ]\n\n");
+ fprintf(stderr, " [ router ] [ extern_learn ]\n\n");
fprintf(stderr, " ip neigh { show | flush } [ proxy ] [ to PREFIX ] [ dev DEV ] [ nud STATE ]\n");
fprintf(stderr, " [ vrf NAME ]\n\n");
fprintf(stderr, "STATE := { permanent | noarp | stale | reachable | none |\n"
@@ -142,6 +142,8 @@ static int ipneigh_modify(int cmd, int flags, int argc, char **argv)
req.ndm.ndm_flags |= NTF_PROXY;
} else if (strcmp(*argv, "router") == 0) {
req.ndm.ndm_flags |= NTF_ROUTER;
+ } else if (matches(*argv, "extern_learn") == 0) {
+ req.ndm.ndm_flags |= NTF_EXT_LEARNED;
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
dev = *argv;
@@ -354,6 +356,9 @@ int print_neigh(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
if (r->ndm_flags & NTF_PROXY)
print_null(PRINT_ANY, "proxy", " %s", "proxy");
+ if (r->ndm_flags & NTF_EXT_LEARNED)
+ print_null(PRINT_ANY, "extern_learn", " %s ", "extern_learn");
+
if (show_stats) {
if (tb[NDA_CACHEINFO])
print_cacheinfo(RTA_DATA(tb[NDA_CACHEINFO]));
diff --git a/man/man8/ip-neighbour.8 b/man/man8/ip-neighbour.8
index db286d1..4a672bb 100644
--- a/man/man8/ip-neighbour.8
+++ b/man/man8/ip-neighbour.8
@@ -24,7 +24,8 @@ ip-neighbour \- neighbour/arp tables management.
.IR ADDR " } [ "
.B dev
.IR DEV " ] [ "
-.BR router " ] "
+.BR router " ] [ "
+.BR extern_learn " ]"
.ti -8
.BR "ip neigh" " { " show " | " flush " } [ " proxy " ] [ " to
@@ -85,6 +86,12 @@ indicates whether we are proxying for this neigbour entry
indicates whether neigbour is a router
.TP
+.BI extern_learn
+this neigh entry was learned externally. This option can be used to
+indicate to the kernel that this is a controller learnt dynamic entry.
+Kernel will not gc such an entry.
+
+.TP
.BI lladdr " LLADDRESS"
the link layer address of the neighbour.
.I LLADDRESS
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next] rxrpc: Remove set but not used variable 'ioc'
From: David Howells @ 2018-10-11 20:38 UTC (permalink / raw)
To: Dan Carpenter
Cc: dhowells, YueHaibing, davem, linux-afs, netdev, kernel-janitors
In-Reply-To: <20181011083807.tvhfguimyw7glrtp@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> I told him to do that because it wasn't a bugfix... Probably just Fixes
> is the right thing to use though.
But the correct fix *is* a bug fix.
David
^ permalink raw reply
* [PATCH net-next 2/2] net: phy: simplify handling of PHY_RESUMING in state machine
From: Heiner Kallweit @ 2018-10-11 20:37 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a3f84d67-c7f1-82d5-1956-bd348ab2b5c0@gmail.com>
Simplify code for handling state PHY_RESUMING, no functional change
intended.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy.c | 43 ++++++++++++++-----------------------------
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 696955d38..d03bdbbd1 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1059,41 +1059,26 @@ void phy_state_machine(struct work_struct *work)
case PHY_RESUMING:
if (AUTONEG_ENABLE == phydev->autoneg) {
err = phy_aneg_done(phydev);
- if (err < 0)
+ if (err < 0) {
break;
-
- /* err > 0 if AN is done.
- * Otherwise, it's 0, and we're still waiting for AN
- */
- if (err > 0) {
- err = phy_read_status(phydev);
- if (err)
- break;
-
- if (phydev->link) {
- phydev->state = PHY_RUNNING;
- phy_link_up(phydev);
- } else {
- phydev->state = PHY_NOLINK;
- phy_link_down(phydev, false);
- }
- } else {
+ } else if (!err) {
phydev->state = PHY_AN;
phydev->link_timeout = PHY_AN_TIMEOUT;
- }
- } else {
- err = phy_read_status(phydev);
- if (err)
break;
-
- if (phydev->link) {
- phydev->state = PHY_RUNNING;
- phy_link_up(phydev);
- } else {
- phydev->state = PHY_NOLINK;
- phy_link_down(phydev, false);
}
}
+
+ err = phy_read_status(phydev);
+ if (err)
+ break;
+
+ if (phydev->link) {
+ phydev->state = PHY_RUNNING;
+ phy_link_up(phydev);
+ } else {
+ phydev->state = PHY_NOLINK;
+ phy_link_down(phydev, false);
+ }
break;
}
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 1/2] net: phy: improve handling of PHY_RUNNING in state machine
From: Heiner Kallweit @ 2018-10-11 20:36 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a3f84d67-c7f1-82d5-1956-bd348ab2b5c0@gmail.com>
Handling of state PHY_RUNNING seems to be more complex than it needs
to be. If not polling, then we don't have to do anything, we'll
receive an interrupt and go to state PHY_CHANGELINK once the link
goes down. If polling and link is down, we don't have to go the
extra mile over PHY_CHANGELINK and call phy_read_status() again
but can set status PHY_NOLINK directly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 704428211..696955d38 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -941,7 +941,6 @@ void phy_state_machine(struct work_struct *work)
bool needs_aneg = false, do_suspend = false;
enum phy_state old_state;
int err = 0;
- int old_link;
mutex_lock(&phydev->lock);
@@ -1025,26 +1024,16 @@ void phy_state_machine(struct work_struct *work)
}
break;
case PHY_RUNNING:
- /* Only register a CHANGE if we are polling and link changed
- * since latest checking.
- */
- if (phy_polling_mode(phydev)) {
- old_link = phydev->link;
- err = phy_read_status(phydev);
- if (err)
- break;
+ if (!phy_polling_mode(phydev))
+ break;
- if (old_link != phydev->link)
- phydev->state = PHY_CHANGELINK;
- }
- /*
- * Failsafe: check that nobody set phydev->link=0 between two
- * poll cycles, otherwise we won't leave RUNNING state as long
- * as link remains down.
- */
- if (!phydev->link && phydev->state == PHY_RUNNING) {
- phydev->state = PHY_CHANGELINK;
- phydev_err(phydev, "no link in PHY_RUNNING\n");
+ err = phy_read_status(phydev);
+ if (err)
+ break;
+
+ if (!phydev->link) {
+ phydev->state = PHY_NOLINK;
+ phy_link_down(phydev, true);
}
break;
case PHY_CHANGELINK:
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 0/2] net: phy: improve and simplify state machine
From: Heiner Kallweit @ 2018-10-11 20:35 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Improve / simplify handling of states PHY_RUNNING and PHY_RESUMING in
phylib state machine.
Heiner Kallweit (2):
net: phy: improve handling of PHY_RUNNING in state machine
net: phy: simplify handling of PHY_RESUMING in state machine
drivers/net/phy/phy.c | 72 ++++++++++++++-----------------------------
1 file changed, 23 insertions(+), 49 deletions(-)
--
2.19.1
^ permalink raw reply
* Fwd: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)
From: salil GK @ 2018-10-12 3:53 UTC (permalink / raw)
To: maowenan, netdev, dwmw2, eric.dumazet, davem, stable,
linux-kernel, gregkh
In-Reply-To: <CAPACB-yF16qtiYn9e41_iFNRUzHB349NEiAGubUvW-kiUwpRMQ@mail.gmail.com>
I was looking for fix for CVE-2018-5390 and CVE-2018-5390) in 4.18.x.
Will these fix be available in 4.18 train ?
PS: Sorry for sending again - I got a rejection message as my previous
message contains html tags !
Thanks
~S
On Oct 11, 2018 7:38 PM, "Greg KH" <gregkh@linux-foundation.org> wrote:
On Wed, Sep 26, 2018 at 10:21:21PM +0200, Greg KH wrote:
> On Tue, Sep 25, 2018 at 10:10:15PM +0800, maowenan wrote:
> > Hi Greg:
> >
> > can you review this patch set?
>
> It is still in the queue, don't worry. It will take some more time to
> properly review and test it.
>
> Ideally you could get someone else to test this and provide a
> "tested-by:" tag for it?
All now queued up, let's see what breaks :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)
From: maowenan @ 2018-10-12 3:39 UTC (permalink / raw)
To: salil GK, gregkh
Cc: netdev, dwmw2, eric.dumazet, davem, stable, linux-kernel,
maowenan
In-Reply-To: <CAPACB-yF16qtiYn9e41_iFNRUzHB349NEiAGubUvW-kiUwpRMQ@mail.gmail.com>
On 2018/10/12 10:28, salil GK wrote:
> I was looking for fix for CVE-2018-5390 and CVE-2018-5390) in 4.18.x. Will these fix be available in 4.18 train ?
The fixes of CVE-2018-5390 have already existed in stable 4.18. These fixes only available with < 4.9 that don't using RB tree.
58152ec tcp: add tcp_ooo_try_coalesce() helper
8541b21 tcp: call tcp_drop() from tcp_data_queue_ofo()
3d4bf93 tcp: detect malicious patterns in tcp_collapse_ofo_queue()
f4a3313 tcp: avoid collapses in tcp_prune_queue() if possible
72cd43b tcp: free batches of packets in tcp_prune_ofo_queue()
>
> Thanks
> ~S
>
> On Oct 11, 2018 7:38 PM, "Greg KH" <gregkh@linux-foundation.org <mailto:gregkh@linux-foundation.org>> wrote:
>
> On Wed, Sep 26, 2018 at 10:21:21PM +0200, Greg KH wrote:
> > On Tue, Sep 25, 2018 at 10:10:15PM +0800, maowenan wrote:
> > > Hi Greg:
> > >
> > > can you review this patch set?
> >
> > It is still in the queue, don't worry. It will take some more time to
> > properly review and test it.
> >
> > Ideally you could get someone else to test this and provide a
> > "tested-by:" tag for it?
>
> All now queued up, let's see what breaks :)
>
> thanks,
>
> greg k-h
>
>
^ permalink raw reply
* [net 1/1] tipc: initialize broadcast link stale counter correctly
From: Jon Maloy @ 2018-10-11 20:02 UTC (permalink / raw)
To: davem, netdev
Cc: gordan.mihaljevic, tung.q.nguyen, hoang.h.le, jon.maloy,
canh.d.luu, ying.xue, tipc-discussion
In the commit referred to below we added link tolerance as an additional
criteria for declaring broadcast transmission "stale" and resetting the
unicast links to the affected node.
Unfortunately, this 'improvement' introduced two bugs, which each and
one alone cause only limited problems, but combined lead to seemingly
stochastic unicast link resets, depending on the amount of broadcast
traffic transmitted.
The first issue, a missing initialization of the 'tolerance' field of
the receiver broadcast link, was recently fixed by commit 047491ea334a
("tipc: set link tolerance correctly in broadcast link").
Ths second issue, where we omit to reset the 'stale_cnt' field of
the same link after a 'stale' period is over, leads to this counter
accumulating over time, and in the absence of the 'tolerance' criteria
leads to the above described symptoms. This commit adds the missing
initialization.
Fixes: a4dc70d46cf1 ("tipc: extend link reset criteria for stale packet
retransmission")
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/link.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index f6552e4..201c3b5 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1041,6 +1041,7 @@ static int tipc_link_retrans(struct tipc_link *l, struct tipc_link *r,
if (r->last_retransm != buf_seqno(skb)) {
r->last_retransm = buf_seqno(skb);
r->stale_limit = jiffies + msecs_to_jiffies(r->tolerance);
+ r->stale_cnt = 0;
} else if (++r->stale_cnt > 99 && time_after(jiffies, r->stale_limit)) {
link_retransmit_failure(l, skb);
if (link_is_bc_sndlink(l))
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next 0/9] net: Kernel side filtering for route dumps
From: Jamal Hadi Salim @ 2018-10-11 19:54 UTC (permalink / raw)
To: David Ahern, Sowmini Varadhan, Stephen Hemminger
Cc: David Ahern, netdev, davem
In-Reply-To: <199349c3-fd14-1401-86d1-814776372917@gmail.com>
On 2018-10-11 2:44 p.m., David Ahern wrote:
> On 10/11/18 12:05 PM, Jamal Hadi Salim wrote:
>> On 2018-10-11 1:04 p.m., David Ahern wrote:
>
> I meant the general API of users passing filter arguments as attributes
> to the dump (or values in the header) -- KIND, MASTER, device index,
> etc. This is an existing API and existing capability.
>
which i referred to as use-case driven. It is not unreasonable
to optimize for the most common - but every time somebody
comes up with something new you need to patch the kernel.
> I disagree with your overall premise of bpf the end-all hammer. It is a
> tool but not the only tool. For starters, you are proposing building the
> message, run the filter on it, and potentially back the message up to
> drop the recently added piece because the filter does not want it
> included. That is still wasting a lot of cpu cycles to build and drop. I
> am thinking about scale to 1 million routes -- I do not need the dump
> loop building a message for 1 million entries only to drop 99% of them.
> That is crazy.
>
My earlier suggestion was for somewhere before the skb is formed.
In the vicinity of xxx_fill_info()
The "create skb and drop" kind works already today with some
acrobatics needed for some cases with cbpf.
Is it unfeasible to add an ebpf hook at that point and ask a user
supplied code "is this ok to send?" - this is no different
than doing a "get by key" operation where key/filter is any arbitrary
construction of fields rtm understands (including the ones you
provided like table index) that are passed in the user program.
Classical "select" mechanism in database tables
> The way the kernel manages route tables says I should pass in the table
> id as it is a major differentiator on what is returned. From there
> lookup the specific table (I need to fix this part per my response to
> Andrew), and then only walk it. The existing semantics, capabilities
> that exist for other dump commands is the most efficient for some of
> these high level, big hammer filters.
>
Sure.
> What you want gets into the tiniest of details and yes the imagination
> can go wild with combinations of filter options. So maybe this scanning
> of post-built messages is reasonable *after* the high level sorting is done.
>
That doesnt require any change.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: Kernel side filtering for route dumps
From: David Miller @ 2018-10-11 19:43 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: dsahern, jhs, stephen, dsahern, netdev
In-Reply-To: <20181011193248.GD17841@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Thu, 11 Oct 2018 15:32:48 -0400
> Without getting into Ahern's patchset, which he obviously feels
> quite passionately about..
>
> On (10/11/18 12:28), David Miller wrote:
>>
>> Once you've composed the message, the whole point of filtering is lost.
>
> it would be nice to apply the filter *before* constructing the skb,
> but afaict most things in BPF today only operate on sk_buffs. How should
> we use *BPF on something other than an sk_buff?
Personally I'm not going to spend cycles on that.
What's important to me in the short term is that David's patch set is
an appropriate way to add filtering, using existing facilities and
mechanisms that already exist for that purpose.
If people want to explore a possible eBPF mechanism for the future,
with an emphasis on "future", feel free to explore to your heart's
content.
But that doesn't exist in any form whatsoever, so that's not what we
should be talking about here.
^ permalink raw reply
* [PATCH net-next v2] vxlan: support NTF_USE refresh of fdb entries
From: Roopa Prabhu @ 2018-10-11 19:35 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This makes use of NTF_USE in vxlan driver consistent
with bridge driver.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
v2: fix patch prefix
drivers/net/vxlan.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index fb0cdbb..018406c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -697,6 +697,7 @@ static int vxlan_fdb_update(struct vxlan_dev *vxlan,
__be16 port, __be32 src_vni, __be32 vni,
__u32 ifindex, __u8 ndm_flags)
{
+ __u8 fdb_flags = (ndm_flags & ~NTF_USE);
struct vxlan_rdst *rd = NULL;
struct vxlan_fdb *f;
int notify = 0;
@@ -714,8 +715,8 @@ static int vxlan_fdb_update(struct vxlan_dev *vxlan,
f->updated = jiffies;
notify = 1;
}
- if (f->flags != ndm_flags) {
- f->flags = ndm_flags;
+ if (f->flags != fdb_flags) {
+ f->flags = fdb_flags;
f->updated = jiffies;
notify = 1;
}
@@ -737,6 +738,9 @@ static int vxlan_fdb_update(struct vxlan_dev *vxlan,
return rc;
notify |= rc;
}
+
+ if (ndm_flags & NTF_USE)
+ f->used = jiffies;
} else {
if (!(flags & NLM_F_CREATE))
return -ENOENT;
@@ -748,7 +752,7 @@ static int vxlan_fdb_update(struct vxlan_dev *vxlan,
netdev_dbg(vxlan->dev, "add %pM -> %pIS\n", mac, ip);
rc = vxlan_fdb_create(vxlan, mac, ip, state, port, src_vni,
- vni, ifindex, ndm_flags, &f);
+ vni, ifindex, fdb_flags, &f);
if (rc < 0)
return rc;
notify = 1;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH cumulus-4.18.y] vxlan: support NTF_USE refresh of fdb entries
From: Roopa Prabhu @ 2018-10-11 19:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1539286408-25597-1-git-send-email-roopa@cumulusnetworks.com>
On Thu, Oct 11, 2018 at 12:33 PM Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This makes use of NTF_USE in vxlan driver consistent
> with bridge driver.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
pls ignore. wrong patch prefix :)
^ 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