* [PATCH net] netxen: fix netxen_nic_poll() logic
From: Eric Dumazet @ 2015-01-22 15:56 UTC (permalink / raw)
To: Mike Galbraith, David Miller; +Cc: netdev, Manish Chopra
In-Reply-To: <1421915821.5286.71.camel@marge.simpson.net>
From: Eric Dumazet <edumazet@google.com>
NAPI poll logic now enforces that a poller returns exactly the budget
when it wants to be called again.
If a driver limits TX completion, it has to return budget as well when
the limit is hit, not the number of received packets.
Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: d75b1ade567f ("net: less interrupt masking in NAPI")
Cc: Manish Chopra <manish.chopra@qlogic.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index 613037584d08..c531c8ae1be4 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -2388,7 +2388,10 @@ static int netxen_nic_poll(struct napi_struct *napi, int budget)
work_done = netxen_process_rcv_ring(sds_ring, budget);
- if ((work_done < budget) && tx_complete) {
+ if (!tx_complete)
+ work_done = budget;
+
+ if (work_done < budget) {
napi_complete(&sds_ring->napi);
if (test_bit(__NX_DEV_UP, &adapter->state))
netxen_nic_enable_int(sds_ring);
^ permalink raw reply related
* ITECIR 8710 not recognized by any kernel
From: J.Pujó @ 2015-01-22 16:00 UTC (permalink / raw)
To: netdev
Hello,
My laptop comes with a ITECIR 8710 infrared receiver, but is not
recognized by any kernel. I tried newer and older versions but nothing
changed.
It's an integrated infrared receiver, which is working like a charm on
Windows partition, so the device is working (obviously, not in Linux).
I tried to search on the net, but I couldn't see anything useful to
make it work with Linux. I guess the drivers never were developed. Is
that possible?
Moreover, there is no /dev/lircX nor /sys/class/rc on my system. So
it's not recognized at all.
Here you have journalctl, dmesg, lsusb, lspci and lircd log.
journalctl: https://dl.dropboxusercontent.com/u/2135959/journalctl.txt
dmesg: https://dl.dropboxusercontent.com/u/2135959/dmesg.txt
lsusb: https://dl.dropboxusercontent.com/u/2135959/lsusb.txt
lspci: https://dl.dropboxusercontent.com/u/2135959/lspci.txt
lircd: https://dl.dropboxusercontent.com/u/2135959/lircd
Let me know if you need more info or details and if it's possible to
make it work with Linux.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] nfc: NXP PN544 ACPI support
From: Daniel Baluta @ 2015-01-22 16:07 UTC (permalink / raw)
To: Robert Dolca
Cc: linux-nfc, Linux Kernel Mailing List,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
David S. Miller, Johannes Berg, Clement Perrochaud
In-Reply-To: <1420804937-10787-2-git-send-email-robert.dolca@intel.com>
On Fri, Jan 9, 2015 at 2:02 PM, Robert Dolca <robert.dolca@intel.com> wrote:
> Device id: NXP5440
> Pin mapping:
> - 0 IRQ pin
> - 1 enable pin
> - 2 firmware pin
>
> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
> ---
> drivers/nfc/Kconfig | 1 +
> drivers/nfc/pn544/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++--
> net/nfc/core.c | 1 +
> 3 files changed, 114 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
> index 7929fac..a25e712 100644
> --- a/drivers/nfc/Kconfig
> +++ b/drivers/nfc/Kconfig
> @@ -68,6 +68,7 @@ config NFC_PORT100
>
> If unsure, say N.
>
> +source "drivers/nfc/pn547/Kconfig"
I think this line shouldn't be here :).
> source "drivers/nfc/pn544/Kconfig"
> source "drivers/nfc/microread/Kconfig"
> source "drivers/nfc/nfcmrvl/Kconfig"
> diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
> index 5f4b9c1..58b9029 100644
> --- a/drivers/nfc/pn544/i2c.c
> +++ b/drivers/nfc/pn544/i2c.c
> @@ -24,6 +24,7 @@
> #include <linux/gpio.h>
> #include <linux/of_gpio.h>
> #include <linux/of_irq.h>
> +#include <linux/acpi.h>
> #include <linux/miscdevice.h>
> #include <linux/interrupt.h>
> #include <linux/delay.h>
> @@ -41,6 +42,11 @@
> #define PN544_I2C_FRAME_HEADROOM 1
> #define PN544_I2C_FRAME_TAILROOM 2
>
> +/* GPIO names */
> +#define PN544_GPIO_NAME_IRQ "pn544_irq"
> +#define PN544_GPIO_NAME_FW "pn544_fw"
> +#define PN544_GPIO_NAME_EN "pn544_en"
> +
> /* framing in HCI mode */
> #define PN544_HCI_I2C_LLC_LEN 1
> #define PN544_HCI_I2C_LLC_CRC 2
> @@ -58,6 +64,13 @@ static struct i2c_device_id pn544_hci_i2c_id_table[] = {
>
> MODULE_DEVICE_TABLE(i2c, pn544_hci_i2c_id_table);
>
> +static const struct acpi_device_id pn544_hci_i2c_acpi_match[] = {
> + {"NXP5440", 0},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(acpi, pn544_hci_i2c_acpi_match);
> +
> #define PN544_HCI_I2C_DRIVER_NAME "pn544_hci_i2c"
>
> /*
> @@ -859,6 +872,90 @@ exit_state_wait_secure_write_answer:
> }
> }
>
> +static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
> +{
> + struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
> + const struct acpi_device_id *id;
> + struct gpio_desc *gpiod_en, *gpiod_irq, *gpiod_fw;
> + struct device *dev;
> + int ret;
> +
> + if (!client)
> + return -EINVAL;
> +
> + dev = &client->dev;
> +
> + /* Match the struct device against a given list of ACPI IDs */
> + id = acpi_match_device(dev->driver->acpi_match_table, dev);
> +
> + if (!id)
> + return -ENODEV;
> +
> + /* Get EN GPIO from ACPI */
> + gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
> + if (IS_ERR(gpiod_en)) {
> + nfc_err(dev,
> + "Unable to get EN GPIO\n");
> + return -ENODEV;
> + }
> +
> + phy->gpio_en = desc_to_gpio(gpiod_en);
> +
> + /* Configuration EN GPIO */
> + ret = gpiod_direction_output(gpiod_en, 0);
> + if (ret) {
> + nfc_err(dev, "Fail EN pin direction\n");
> + return ret;
> + }
> +
> + /* Get FW GPIO from ACPI */
> + gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
> + if (IS_ERR(gpiod_fw)) {
> + nfc_err(dev,
> + "Unable to get FW GPIO\n");
> + return -ENODEV;
> + }
> +
> + phy->gpio_fw = desc_to_gpio(gpiod_fw);
> +
> + /* Configuration FW GPIO */
> + ret = gpiod_direction_output(gpiod_fw, 0);
> + if (ret) {
> + nfc_err(dev, "Fail FW pin direction\n");
> + return ret;
> + }
> +
> + /* Get IRQ GPIO */
> + gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
> + if (IS_ERR(gpiod_irq)) {
> + nfc_err(dev,
> + "Unable to get IRQ GPIO\n");
> + return -ENODEV;
> + }
> +
> + phy->gpio_irq = desc_to_gpio(gpiod_irq);
> +
> + /* Configure IRQ GPIO */
> + ret = gpiod_direction_input(gpiod_irq);
> + if (ret) {
> + nfc_err(dev, "Fail IRQ pin direction\n");
> + return ret;
> + }
> +
> + /* Map the pin to an IRQ */
> + ret = gpiod_to_irq(gpiod_irq);
> + if (ret < 0) {
> + nfc_err(dev, "Fail pin IRQ mapping\n");
> + return ret;
> + }
> +
> + nfc_info(dev, "GPIO resource, no:%d irq:%d\n",
> + desc_to_gpio(gpiod_irq), ret);
> + client->irq = ret;
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_OF
>
> static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
> @@ -884,7 +981,7 @@ static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
> phy->gpio_en = ret;
>
> /* Configuration of EN GPIO */
> - ret = gpio_request(phy->gpio_en, "pn544_en");
> + ret = gpio_request(phy->gpio_en, PN544_GPIO_NAME_EN);
> if (ret) {
> nfc_err(&client->dev, "Fail EN pin\n");
> goto err_dt;
> @@ -906,7 +1003,7 @@ static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
> phy->gpio_fw = ret;
>
> /* Configuration of FW GPIO */
> - ret = gpio_request(phy->gpio_fw, "pn544_fw");
> + ret = gpio_request(phy->gpio_fw, PN544_GPIO_NAME_FW);
> if (ret) {
> nfc_err(&client->dev, "Fail FW pin\n");
> goto err_gpio_en;
> @@ -1001,6 +1098,14 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
> phy->gpio_en = pdata->get_gpio(NFC_GPIO_ENABLE);
> phy->gpio_fw = pdata->get_gpio(NFC_GPIO_FW_RESET);
> phy->gpio_irq = pdata->get_gpio(NFC_GPIO_IRQ);
> + /* Using ACPI */
> + } else if (ACPI_HANDLE(&client->dev)) {
> + r = pn544_hci_i2c_acpi_request_resources(client);
> + if (r) {
> + nfc_err(&client->dev,
> + "Cannot get ACPI data\n");
> + return r;
> + }
> } else {
> nfc_err(&client->dev, "No platform data\n");
> return -EINVAL;
> @@ -1020,9 +1125,12 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
> PN544_I2C_FRAME_HEADROOM, PN544_I2C_FRAME_TAILROOM,
> PN544_HCI_I2C_LLC_MAX_PAYLOAD,
> pn544_hci_i2c_fw_download, &phy->hdev);
> - if (r < 0)
> + if (r < 0) {
> + nfc_err(&client->dev, "HCI Probing error\n");
> goto err_hci;
> + }
>
> + nfc_info(&client->dev, "NFC I2C driver loaded\n");
> return 0;
>
> err_hci:
> @@ -1080,6 +1188,7 @@ static struct i2c_driver pn544_hci_i2c_driver = {
> .name = PN544_HCI_I2C_DRIVER_NAME,
> .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(of_pn544_i2c_match),
> + .acpi_match_table = ACPI_PTR(pn544_hci_i2c_acpi_match),
> },
> .probe = pn544_hci_i2c_probe,
> .id_table = pn544_hci_i2c_id_table,
> diff --git a/net/nfc/core.c b/net/nfc/core.c
> index 819b877..a53c2cc 100644
> --- a/net/nfc/core.c
> +++ b/net/nfc/core.c
> @@ -32,6 +32,7 @@
>
> #include "nfc.h"
>
> +#define DEBUG
> #define VERSION "0.1"
>
> #define NFC_CHECK_PRES_FREQ_MS 2000
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next 2/2] flow_dissector: add tipc support
From: erik.hugne @ 2015-01-22 16:10 UTC (permalink / raw)
To: richard.alpe, netdev, jon.maloy, ying.xue; +Cc: tipc-discussion
In-Reply-To: <1421943032-29924-1-git-send-email-erik.hugne@ericsson.com>
From: Erik Hugne <erik.hugne@ericsson.com>
The flows are hashed on the sending node address, which allows us
to spread out the TIPC link processing to RPS enabled cores. There
is no point to include the destination address in the hash as that
will always be the same for all inbound links. We have experimented
with a 3-tuple hash over [srcnode, sport, dport], but this showed to
give slightly lower performance because of increased lock contention
when the same link was handled by multiple cores.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/core/flow_dissector.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 4508493..beb83d1 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -178,6 +178,20 @@ ipv6:
return false;
}
}
+ case htons(ETH_P_TIPC): {
+ struct {
+ __be32 pre[3];
+ __be32 srcnode;
+ } *hdr, _hdr;
+ hdr = __skb_header_pointer(skb, nhoff, sizeof(_hdr), data, hlen, &_hdr);
+ if (!hdr)
+ return false;
+ flow->src = hdr->srcnode;
+ flow->dst = 0;
+ flow->n_proto = proto;
+ flow->thoff = (u16)nhoff;
+ return true;
+ }
case htons(ETH_P_FCOE):
flow->thoff = (u16)(nhoff + FCOE_HEADER_LEN);
/* fall through */
--
2.1.3
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
^ permalink raw reply related
* [PATCH net-next 1/2] tipc: fix excessive network event logging
From: erik.hugne @ 2015-01-22 16:10 UTC (permalink / raw)
To: richard.alpe, netdev, jon.maloy, ying.xue; +Cc: tipc-discussion, Erik Hugne
From: Erik Hugne <erik.hugne@ericsson.com>
If a large number of namespaces is spawned on a node and TIPC is
enabled in each of these, the excessive printk tracing of network
events will cause the system to grind down to a near halt.
The traces are still of debug value, so instead of removing them
completely we fix it by changing the link state and node availability
logging debug traces.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/link.c | 20 ++++++++++----------
net/tipc/node.c | 22 +++++++++++-----------
2 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 193bc15..2846ad80 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -538,8 +538,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
link_set_timer(l_ptr, cont_intv / 4);
break;
case RESET_MSG:
- pr_info("%s<%s>, requested by peer\n", link_rst_msg,
- l_ptr->name);
+ pr_debug("%s<%s>, requested by peer\n",
+ link_rst_msg, l_ptr->name);
tipc_link_reset(l_ptr);
l_ptr->state = RESET_RESET;
l_ptr->fsm_msg_cnt = 0;
@@ -549,7 +549,7 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
link_set_timer(l_ptr, cont_intv);
break;
default:
- pr_err("%s%u in WW state\n", link_unk_evt, event);
+ pr_debug("%s%u in WW state\n", link_unk_evt, event);
}
break;
case WORKING_UNKNOWN:
@@ -561,8 +561,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
link_set_timer(l_ptr, cont_intv);
break;
case RESET_MSG:
- pr_info("%s<%s>, requested by peer while probing\n",
- link_rst_msg, l_ptr->name);
+ pr_debug("%s<%s>, requested by peer while probing\n",
+ link_rst_msg, l_ptr->name);
tipc_link_reset(l_ptr);
l_ptr->state = RESET_RESET;
l_ptr->fsm_msg_cnt = 0;
@@ -588,8 +588,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
l_ptr->fsm_msg_cnt++;
link_set_timer(l_ptr, cont_intv / 4);
} else { /* Link has failed */
- pr_warn("%s<%s>, peer not responding\n",
- link_rst_msg, l_ptr->name);
+ pr_debug("%s<%s>, peer not responding\n",
+ link_rst_msg, l_ptr->name);
tipc_link_reset(l_ptr);
l_ptr->state = RESET_UNKNOWN;
l_ptr->fsm_msg_cnt = 0;
@@ -1568,9 +1568,9 @@ static void tipc_link_proto_rcv(struct net *net, struct tipc_link *l_ptr,
if (msg_linkprio(msg) &&
(msg_linkprio(msg) != l_ptr->priority)) {
- pr_warn("%s<%s>, priority change %u->%u\n",
- link_rst_msg, l_ptr->name, l_ptr->priority,
- msg_linkprio(msg));
+ pr_debug("%s<%s>, priority change %u->%u\n",
+ link_rst_msg, l_ptr->name,
+ l_ptr->priority, msg_linkprio(msg));
l_ptr->priority = msg_linkprio(msg);
tipc_link_reset(l_ptr); /* Enforce change to take effect */
break;
diff --git a/net/tipc/node.c b/net/tipc/node.c
index b1eb092..ee5d33c 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -230,8 +230,8 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
n_ptr->action_flags |= TIPC_NOTIFY_LINK_UP;
n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
- pr_info("Established link <%s> on network plane %c\n",
- l_ptr->name, l_ptr->net_plane);
+ pr_debug("Established link <%s> on network plane %c\n",
+ l_ptr->name, l_ptr->net_plane);
if (!active[0]) {
active[0] = active[1] = l_ptr;
@@ -239,7 +239,7 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
goto exit;
}
if (l_ptr->priority < active[0]->priority) {
- pr_info("New link <%s> becomes standby\n", l_ptr->name);
+ pr_debug("New link <%s> becomes standby\n", l_ptr->name);
goto exit;
}
tipc_link_dup_queue_xmit(active[0], l_ptr);
@@ -247,9 +247,9 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
active[0] = l_ptr;
goto exit;
}
- pr_info("Old link <%s> becomes standby\n", active[0]->name);
+ pr_debug("Old link <%s> becomes standby\n", active[0]->name);
if (active[1] != active[0])
- pr_info("Old link <%s> becomes standby\n", active[1]->name);
+ pr_debug("Old link <%s> becomes standby\n", active[1]->name);
active[0] = active[1] = l_ptr;
exit:
/* Leave room for changeover header when returning 'mtu' to users: */
@@ -297,12 +297,12 @@ void tipc_node_link_down(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
if (!tipc_link_is_active(l_ptr)) {
- pr_info("Lost standby link <%s> on network plane %c\n",
- l_ptr->name, l_ptr->net_plane);
+ pr_debug("Lost standby link <%s> on network plane %c\n",
+ l_ptr->name, l_ptr->net_plane);
return;
}
- pr_info("Lost link <%s> on network plane %c\n",
- l_ptr->name, l_ptr->net_plane);
+ pr_debug("Lost link <%s> on network plane %c\n",
+ l_ptr->name, l_ptr->net_plane);
active = &n_ptr->active_links[0];
if (active[0] == l_ptr)
@@ -380,8 +380,8 @@ static void node_lost_contact(struct tipc_node *n_ptr)
char addr_string[16];
u32 i;
- pr_info("Lost contact with %s\n",
- tipc_addr_string_fill(addr_string, n_ptr->addr));
+ pr_debug("Lost contact with %s\n",
+ tipc_addr_string_fill(addr_string, n_ptr->addr));
/* Flush broadcast link info associated with lost node */
if (n_ptr->bclink.recv_permitted) {
--
2.1.3
^ permalink raw reply related
* Re: [patch net-next RFC] tc: introduce OpenFlow classifier
From: Jiri Pirko @ 2015-01-22 16:16 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, davem
In-Reply-To: <54C11C4A.1070206@mojatatu.com>
Thu, Jan 22, 2015 at 04:50:34PM CET, jhs@mojatatu.com wrote:
>On 01/22/15 08:37, Jiri Pirko wrote:
>>This patch introduces OpenFlow-based filter. So far, the very essential
>>packet fields are supported (according to OpenFlow v1.4 spec).
>>
>>Known issues: skb_flow_dissect hashes out ipv6 addresses. That needs
>>to be changed to store them somewhere so they can be used later on.
>>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>---
>> include/uapi/linux/pkt_cls.h | 33 +++
>> net/sched/Kconfig | 11 +
>> net/sched/Makefile | 1 +
>> net/sched/cls_openflow.c | 514 +++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 559 insertions(+)
>> create mode 100644 net/sched/cls_openflow.c
>>
>>diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>>index 25731df..d4cef16 100644
>>--- a/include/uapi/linux/pkt_cls.h
>>+++ b/include/uapi/linux/pkt_cls.h
>>@@ -402,6 +402,39 @@ enum {
>>
>> #define TCA_BPF_MAX (__TCA_BPF_MAX - 1)
>>
>>+/* OpenFlow classifier */
>>+
>>+enum {
>>+ TCA_OF_UNSPEC,
>>+ TCA_OF_CLASSID,
>>+ TCA_OF_POLICE,
>>+ TCA_OF_INDEV,
>
>I think POLICE is an old way of doing policing and INDEV if i am not
>mistaken is only legit for u32 classifier.
>So i am not sure you want to keep them.
I use INDEV for matching skb input device. I can move this to
TCA_OF_KEY_INDEV but since I spotted TCA_*_INDEV, I made this to be the
same.
The POLICE, I just copied from the other cls's
>
>Other than that looks good - will be interested to see how perfomance looks
>on this with the list walking ;->
I plan to do some optimizations as follow-ups. (hash list for example)
>
>cheers,
>jamal
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-22 16:24 UTC (permalink / raw)
To: Vincent JARDIN
Cc: Jesse Gross, Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <54C03A57.4080002@6wind.com>
On Wed, Jan 21, 2015 at 3:46 PM, Vincent JARDIN
<vincent.jardin@6wind.com> wrote:
> Jesse, Tom,
>
> On 21/01/2015 23:14, Jesse Gross wrote:
>>>
>>> I'm not going to try to draw conclusions from data which is obviously
>>> >biased and incomplete. If you want to move forward on this, then just
>>> >provide network interface for STT so we can independently run our own
>>> >comparisons against other encapsulations like we've been doing all
>>> >along.
>>
>> You have the source code, so you are totally free to run whatever
>> tests you like to draw your own conclusions. Personally, I find a more
>> than doubling of performance in the environments that I have seen
>> compelling. Your mileage may vary.
>
>
> +1 for STT in the kernel:
> - whatever the performances, it is needed because it happened to be used.
Vincent, it's not that simple. This is not just another case of an
encapsulation protocol that we can easily ignore and filter because it
hides behind a UDP port or even a new protocol number. This is adding
a new definition to *the* most critical protocol on the planet. I
don't see how this anyone can claim this doesn't violate a whole bunch
of long standing RFCs and break a whole bunch of baked in assumptions
we make about TCP (IP protocol number 6).
For example, TCP MUST have congestion avoidance as per RFC2581:
"The slow start and congestion avoidance algorithms MUST be used by a
TCP sender to control the amount of outstanding data being injected
into the network."
But from STT draft:
"STT segments are transmitted as IP datagrams using the TCP protocol
number (6)."-- that makes this a TCP sender.
"STT does not provide any sort of congestion control."-- that puts STT
in clear violation of RFC2581.
Congestion avoidance for TCP is not just a nice to have, it's not
optional, it's not just best effort like UDP is. There is no provision
for reusing the TCP protocol number and claiming to be exempt from
standards compliance because it's now a different protocol. We build
whole data centers around these principles, and in fact the very
operation of the Internet depends on them. For instance, if we allow
this into the kernel and this becomes available on billions of
devices, what assurances do we have that people won't start abusing
this because they find congestion avoidance annoying and this a
convenient way to bypass it?
STT is undoubtedly a creative and unique solution I'll give you that,
but the potential repercussions of allowing this to be widely deployed
are profound. IMO this needs to be fully explored before it can ever
be allowed in the kernel. If there has already been discussion on this
please forward a pointer (I didn't find anything in the IETF mailing
list archives other than the draft posting announcements), but at the
minimum these patches warrant a lot of scrutiny.
Thanks,
Tom
> If the patch can be optimized, someone will do and provide the related
> patches. The patch from Pravin is ok but...
>
> - ...I agree with Tom, a netdevice is a must have to ack't this patch.
> Such feature should not be added into openvswitch without its counter-part
> netdevice.
>
> thank you,
> Vincent
^ permalink raw reply
* Re: [PATCH net 4/4] sh_eth: Fix serialisation of interrupt disable with interrupt & NAPI handlers
From: Sergei Shtylyov @ 2015-01-22 16:35 UTC (permalink / raw)
To: Ben Hutchings
Cc: David S.Miller, netdev, linux-kernel, Nobuhiro Iwamatsu,
Mitsuhiro Kimura, Hisashi Nakamura, Yoshihiro Kaneko
In-Reply-To: <1421939177.1222.298.camel@xylophone.i.decadent.org.uk>
Hello.
On 01/22/2015 06:06 PM, Ben Hutchings wrote:
>>> In order to stop the RX path accessing the RX ring while it's being
>>> stopped or resized, we clear the interrupt mask (EESIPR) and then call
>>> free_irq() or synchronise_irq(). This is insufficient because the
>>> interrupt handler or NAPI poller may set EESIPR again after we clear
>>> it.
>> Hm, how come the interrupt handler gets called when we have disabled all
>> interrupts?
> It may be running on another processor and racing with the function that
> clears EESIPR.
Ah, I didn't think about SMP... but then we need more spinlock protection
instead, no?
>> Is it unmaskable EESR.ECI interrupt? BTW, I'm not seeing where the
>> interrupt handler enables interrupts again; only NAPI poller does that AFAIK.
> Normally it only clears EESR_RX_CHECK, but as it cannot atomically clear
> a single bit of EESIPR this can result in setting other bits.
This is again only possible on SMP kernel, right?
[...]
> Ben.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net 1/2] net: cls_bpf: fix size mismatch on filter preparation
From: Alexei Starovoitov @ 2015-01-22 16:39 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Jiří Pírko,
netdev@vger.kernel.org
On Thu, Jan 22, 2015 at 1:41 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> In cls_bpf_modify_existing(), we read out the number of filter blocks,
> do some sanity checks, allocate a block on that size, and copy over the
> BPF instruction blob from user space, then pass everything through the
> classic BPF checker prior to installation of the classifier.
>
> We should reject mismatches here, there are 2 scenarios: the number of
> filter blocks could be smaller than the provided instruction blob, so
> we do a partial copy of the BPF program, and thus the instructions will
> either be rejected from the verifier or a valid BPF program will be run;
> in the other case, we'll end up copying more than we're supposed to,
> and most likely the trailing garbage will be rejected by the verifier
> as well (i.e. we need to fit instruction pattern, ret {A,K} needs to be
> last instruction, load/stores must be correct, etc); in case not, we
> would leak memory when dumping back instruction patterns. The code should
> have only used nla_len() as Dave noted to avoid this from the beginning.
> Anyway, lets fix it by rejecting such load attempts.
>
> Fixes: 7d1d65cb84e1 ("net: sched: cls_bpf: add BPF-based classifier")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: act_bpf: fix size mismatch on filter preparation
From: Alexei Starovoitov @ 2015-01-22 16:44 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Jiří Pírko,
netdev@vger.kernel.org
In-Reply-To: <1421920699-26556-3-git-send-email-dborkman@redhat.com>
On Thu, Jan 22, 2015 at 1:58 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> Similarly as in cls_bpf, also this code needs to reject mismatches.
>
> Reference: http://article.gmane.org/gmane.linux.network/347406
> Fixes: d23b8ad8ab23 ("tc: add BPF based action")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Pablo Neira Ayuso @ 2015-01-22 16:49 UTC (permalink / raw)
To: Thomas Graf
Cc: Jamal Hadi Salim, John Fastabend, simon.horman, sfeldma, netdev,
davem, gerlitz.or, andy, ast, Jiri Pirko
In-Reply-To: <20150122153727.GC25797@casper.infradead.org>
On Thu, Jan 22, 2015 at 03:37:27PM +0000, Thomas Graf wrote:
> On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
> > On 01/22/15 10:13, Thomas Graf wrote:
> >
> > >I don't follow this. John's proposal allows to decide on a case by
> > >case basis what we want to export. Just like with ethtool or
> > >RTNETLINK. There is no direct access to hardware. A user can only
> > >configure what is being exposed by the kernel.
> > >
> >
> > So if i am a vendor with my own driver, I can expose whatever i want.
>
> No. We will reject any driver change attempting to do so on this
> list.
I think those vendors do not want to push those driver changes
mainstream. They will likely use these new ndo's to fully expose their
vendor-specific capabilities distributed in proprietary blobs.
I remember to have seen one ugly patch for netfilter that added
several hook functions (not netfilter hooks) at different positions of
the NAT code, the goal was to offload NAT through hardware. I was told
the code that was using those ad-hoc hooks was distributed in a binary
blob.
> This is the whole point of this: Coming up with a model that allows
> to describe capabilities and offer flow programming capabilities
> in a Vendor neutral way. A "push_vlan" or "pop_vlan" action will work
> with any driver that supports it.
Right, we need an abstraction for actions too, and the infrastructure
should not provide any means to circunvent and expose vendor specific
details.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-22 16:58 UTC (permalink / raw)
To: Thomas Graf
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman, sfeldma,
netdev, davem, gerlitz.or, andy, ast, Jiri Pirko
In-Reply-To: <20150122151316.GB25797@casper.infradead.org>
On 01/22/2015 07:13 AM, Thomas Graf wrote:
> On 01/22/15 at 10:00am, Jamal Hadi Salim wrote:
>> On 01/22/15 09:00, Pablo Neira Ayuso wrote:
>>
>>>
I'll try to unify the threads here
>>> +/* rocker specific action definitions */
>>> +struct net_flow_action_arg rocker_set_group_id_args[] = {
>>> + {
>>> + .name = "group_id",
>>> + .type = NFL_ACTION_ARG_TYPE_U32,
>>> + .value_u32 = 0,
>>> + },
>>>
In response to Pablo's observation,
Correct this is fully exposed to user space, but it is also self
contained inside the API meaning I can learn when to use it and what it
does by looking at the other operations tables the table graph and
supported headers. The assumption I am making that is not in the API
explicitly yet. Is that actions named "set_field_name" perform the
set operation on that field. We can and plan to extend the API to make
this assumption explicit in the API.
In this case I can "learn" that I can match on group_id in some tables
and then use the above action to set the group_id in others.
>>> that is retrieved via ndo_flow_get_actions and fully exposed to
>>> userspace.
>>>
>>
>> My main concern is along similar lines (I did express it earlier and
>> I think Jiri chimed in as well).
>> The API exposes direct access to hardware. I am sure this was a result
>> of trying to replace the ethtool interface (which was primitive).
>> By providing vendors direct access to the hardware - they do not need
>> to use any traditional Linux tooling/APIs.
>
> I don't follow this. John's proposal allows to decide on a case by
> case basis what we want to export. Just like with ethtool or
> RTNETLINK. There is no direct access to hardware. A user can only
> configure what is being exposed by the kernel.
>
> Pablo raises an interesting point though. How do we handle unique
> features like Rocker groups.
>
> Maybe Jiri and Scott can chime in and describe if we can map this to
> something more generic and avoid exporting anything Rocker specific.
>
Even though its a detail of the rocker world its easy enough for a
program on top of the API to learn how it works.
So in the rocker switch case if I want to rewrite an eth_dst adress I
have a couple choices. I can set the group_id in one of the tables
that support setting the group_id and then do the rewrite in one of the
tables that supports matching on group_id and setting the eth_dst mac.
The "choice" I make is a policy IMO and I don't want to hard code logic
in the kernel that picks tables and decides things like what should I
do if table x is full but table y could also be used should I overflow
into table y? Or is table y reserved for some other network function?
etc.
There are some actions and metadata though that _need_ to be
standardized. These are the metadata that is used outside the API. For
example ingress_port is metadata that is set outside the tables.
Similarly set_egress_port and set_egress_queue provide the forwarding
and queueing fields. No matter how hard you look at the model from the
API you can not learn how these are used.
> What would a rocker group map to in the tc world?
In the 'tc' world I would guess the easiest thing to do is simply bind
a 'tc' qdisc to the ACL table. It seems a good first approximation of
how to make this work. But the rocker world doesn't yet have any QOS so
it makes it difficult to "offload" anything but the fifo qdiscs.
>
>> I see this as a gaping hole
>> for vendor SDKs with their own definitions of their own hardware that
>> doesnt work with anyone else. i.e it seems to standardize proprietary
>> interfaces. Maybe thats what Pablo is alluding to.
>
> I will be the first to root for rejection if such patches appear.
>
Is it problematic if users define some unique header here and then
provide actions to set/pop/push/get operations on it?
For me this seems perfectly reasonable. We can pull it out of hardware
or a database in libvirt perhaps then feed it back into Linux nft,
ebpf, tc u32_filter, to create a unified view. I think ebpf, nft, and
u32 have been all about supporting vendor specific protocols?
I must be missing the point about proprietary interfaces. The FLOW API
would be the interface and if we create interesting tools/systems around
it and integration with other Linux sub-systems by choosing to use a
proprietary SDK you lose the goodness.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-22 17:10 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Thomas Graf, Jamal Hadi Salim, simon.horman, sfeldma, netdev,
davem, gerlitz.or, andy, ast, Jiri Pirko
In-Reply-To: <20150122164951.GA3417@salvia>
On 01/22/2015 08:49 AM, Pablo Neira Ayuso wrote:
> On Thu, Jan 22, 2015 at 03:37:27PM +0000, Thomas Graf wrote:
>> On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
>>> On 01/22/15 10:13, Thomas Graf wrote:
>>>
>>>> I don't follow this. John's proposal allows to decide on a case by
>>>> case basis what we want to export. Just like with ethtool or
>>>> RTNETLINK. There is no direct access to hardware. A user can only
>>>> configure what is being exposed by the kernel.
>>>>
>>>
>>> So if i am a vendor with my own driver, I can expose whatever i want.
>>
>> No. We will reject any driver change attempting to do so on this
>> list.
>
> I think those vendors do not want to push those driver changes
> mainstream. They will likely use these new ndo's to fully expose their
> vendor-specific capabilities distributed in proprietary blobs.
>
> I remember to have seen one ugly patch for netfilter that added
> several hook functions (not netfilter hooks) at different positions of
> the NAT code, the goal was to offload NAT through hardware. I was told
> the code that was using those ad-hoc hooks was distributed in a binary
> blob.
>
>> This is the whole point of this: Coming up with a model that allows
>> to describe capabilities and offer flow programming capabilities
>> in a Vendor neutral way. A "push_vlan" or "pop_vlan" action will work
>> with any driver that supports it.
>
> Right, we need an abstraction for actions too, and the infrastructure
> should not provide any means to circunvent and expose vendor specific
> details.
>
I'm not sure what a vendor specific detail is in the API now?
The API provides a mechanism to define the headers you support in a
vendor neutral way. Perhaps vendor X may be the only hardware to
support the packet type but the packets are not really vendor specific
if we have the packet layout we can generate code to create the packets
if we care to in software and find it useful.
Maybe the issue is the actions look like UIDs without any specification
as to what they do? The concern being as a vendor I could create an
action and call it my_vendor_specific_action and if I never tell anyone
how to use it then we are stuck.
I can add a set of specifier attributes to the get_action call that
describes actions using basic primitives to resolve this specific issue.
Actions should either 'set' fields, 'get' fields, 'dec' fields, 'inc'
fields, etc. Then you specify an action by providing the list of
operations it performs. So set_group_id is simply
'set_field uid=group_id_metadata'
More complicated actions exist like route() and such which will be a
list of operations that may set multiple fields in a single atomic step.
The table API also seems vendor neutral to me. I'm not sure what
specific details would be vendor specific here either.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next 1/2] tipc: fix excessive network event logging
From: Joe Perches @ 2015-01-22 17:24 UTC (permalink / raw)
To: erik.hugne; +Cc: richard.alpe, netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <1421943032-29924-1-git-send-email-erik.hugne@ericsson.com>
On Thu, 2015-01-22 at 17:10 +0100, erik.hugne@ericsson.com wrote:
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> If a large number of namespaces is spawned on a node and TIPC is
> enabled in each of these, the excessive printk tracing of network
> events will cause the system to grind down to a near halt.
> The traces are still of debug value, so instead of removing them
> completely we fix it by changing the link state and node availability
> logging debug traces.
Maybe some of these should be net_<level>_ratelimited(fmt, ...)
> diff --git a/net/tipc/link.c b/net/tipc/link.c
[]
> @@ -588,8 +588,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
> l_ptr->fsm_msg_cnt++;
> link_set_timer(l_ptr, cont_intv / 4);
> } else { /* Link has failed */
> - pr_warn("%s<%s>, peer not responding\n",
> - link_rst_msg, l_ptr->name);
Like this one.
> + pr_debug("%s<%s>, peer not responding\n",
> + link_rst_msg, l_ptr->name);
> tipc_link_reset(l_ptr);
> l_ptr->state = RESET_UNKNOWN;
> l_ptr->fsm_msg_cnt = 0;
> @@ -380,8 +380,8 @@ static void node_lost_contact(struct tipc_node *n_ptr)
> char addr_string[16];
> u32 i;
>
> - pr_info("Lost contact with %s\n",
> - tipc_addr_string_fill(addr_string, n_ptr->addr));
> + pr_debug("Lost contact with %s\n",
> + tipc_addr_string_fill(addr_string, n_ptr->addr));
>
> /* Flush broadcast link info associated with lost node */
> if (n_ptr->bclink.recv_permitted) {
And maybe this one too.
^ permalink raw reply
* [PATCH net] net: sctp: fix slab corruption from use after free on INIT collisions
From: Daniel Borkmann @ 2015-01-22 17:26 UTC (permalink / raw)
To: davem; +Cc: vyasevich, netdev, linux-sctp
When hitting an INIT collision case during the 4WHS with AUTH enabled, as
already described in detail in commit 1be9a950c646 ("net: sctp: inherit
auth_capable on INIT collisions"), it can happen that we occasionally
still remotely trigger the following panic on server side which seems to
have been uncovered after the fix from commit 1be9a950c646 ...
[ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff
[ 533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230
[ 533.940559] PGD 5030f2067 PUD 0
[ 533.957104] Oops: 0000 [#1] SMP
[ 533.974283] Modules linked in: sctp mlx4_en [...]
[ 534.939704] Call Trace:
[ 534.951833] [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0
[ 534.984213] [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0
[ 535.015025] [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170
[ 535.045661] [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0
[ 535.074593] [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50
[ 535.105239] [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp]
[ 535.138606] [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0
[ 535.166848] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
... or depending on the the application, for example this one:
[ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff
[ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0
[ 1370.054568] PGD 633c94067 PUD 0
[ 1370.070446] Oops: 0000 [#1] SMP
[ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
[ 1370.963431] Call Trace:
[ 1370.974632] [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960
[ 1371.000863] [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960
[ 1371.027154] [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170
[ 1371.054679] [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130
[ 1371.080183] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
With slab debugging enabled, we can see that the poison has been overwritten:
[ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten
[ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b
[ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494
[ 669.826424] __slab_alloc+0x4bf/0x566
[ 669.826433] __kmalloc+0x280/0x310
[ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp]
[ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
[ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
[ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...]
[ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
[ 669.826635] __slab_free+0x39/0x2a8
[ 669.826643] kfree+0x1d6/0x230
[ 669.826650] kzfree+0x31/0x40
[ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp]
[ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp]
[ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp]
Since this only triggers in some collision-cases with AUTH, the problem at
heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
when having refcnt 1, once directly in sctp_assoc_update() and yet again
from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
the already kzfree'd memory, which is also consistent with the observation
of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
at a later point in time when poison is checked on new allocation).
Reference counting of auth keys revisited:
Shared keys for AUTH chunks are being stored in endpoints and associations
in endpoint_shared_keys list. On endpoint creation, a null key is being
added; on association creation, all endpoint shared keys are being cached
and thus cloned over to the association. struct sctp_shared_key only holds
a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
keeps track of users internally through refcounting. Naturally, on assoc
or enpoint destruction, sctp_shared_key are being destroyed directly and
the reference on sctp_auth_bytes dropped.
User space can add keys to either list via setsockopt(2) through struct
sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
with refcount 1 and in case of replacement drops the reference on the old
sctp_auth_bytes. A key can be set active from user space through setsockopt()
on the id via sctp_auth_set_active_key(), which iterates through either
endpoint_shared_keys and in case of an assoc, invokes (one of various places)
sctp_auth_asoc_init_active_key().
sctp_auth_asoc_init_active_key() computes the actual secret from local's
and peer's random, hmac and shared key parameters and returns a new key
directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
the reference if there was a previous one. The secret, which where we
eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
intitial refcount of 1, which also stays unchanged eventually in
sctp_assoc_update(). This key is later being used for crypto layer to
set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().
To close the loop: asoc->asoc_shared_key is freshly allocated secret
material and independant of the sctp_shared_key management keeping track
of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
("net: sctp: fix memory leak in auth key management") is independant of
this bug here since it concerns a different layer (though same structures
being used eventually). asoc->asoc_shared_key is reference dropped correctly
on assoc destruction in sctp_association_free() and when active keys are
being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
to remove that sctp_auth_key_put() from there which fixes these panics.
Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/sctp/associola.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index f791edd..26d06db 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1182,7 +1182,6 @@ void sctp_assoc_update(struct sctp_association *asoc,
asoc->peer.peer_hmacs = new->peer.peer_hmacs;
new->peer.peer_hmacs = NULL;
- sctp_auth_key_put(asoc->asoc_shared_key);
sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC);
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] bpf: Call rcu_read_unlock() before copy_to_user()
From: Alexei Starovoitov @ 2015-01-22 17:27 UTC (permalink / raw)
To: Michael Holzheu
Cc: Alexei Starovoitov, Martin Schwidefsky,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
On Thu, Jan 22, 2015 at 7:57 AM, Michael Holzheu
<holzheu@linux.vnet.ibm.com> wrote:
> We must not hold locks when calling copy_to_user():
>
> BUG: sleeping function called from invalid context at mm/memory.c:3732
> in_atomic(): 0, irqs_disabled(): 0, pid: 671, name: test_maps
> 1 lock held by test_maps/671:
> #0: (rcu_read_lock){......}, at: [<0000000000264190>] map_lookup_elem+0xe8/0x260
> Preemption disabled at:[<00000000001be3b6>] vprintk_default+0x56/0x68
>
> CPU: 0 PID: 671 Comm: test_maps Not tainted 3.19.0-rc5-00117-g5eb11d6-dirty #424
> 000000001e447bb0 000000001e447c40 0000000000000002 0000000000000000
> 000000001e447ce0 000000001e447c58 000000001e447c58 0000000000115c8a
> 0000000000000000 0000000000c08246 0000000000c27e8a 000000000000000b
> 000000001e447ca0 000000001e447c40 0000000000000000 0000000000000000
> 0000000000000000 0000000000115c8a 000000001e447c40 000000001e447ca0
> Call Trace:
> ([<0000000000115b7e>] show_trace+0x12e/0x150)
> [<0000000000115c40>] show_stack+0xa0/0x100
> [<00000000009b163c>] dump_stack+0x74/0xc8
> [<000000000017424a>] ___might_sleep+0x23a/0x248
> [<00000000002b58e8>] might_fault+0x70/0xe8
> [<0000000000264230>] map_lookup_elem+0x188/0x260
> [<0000000000264716>] SyS_bpf+0x20e/0x840
> [<00000000009bbe3a>] system_call+0xd6/0x24c
> [<000003fffd15f566>] 0x3fffd15f566
> 1 lock held by test_maps/671:
> #0: (rcu_read_lock){......}, at: [<0000000000264190>] map_lookup_elem+0xe8/0x260
>
> So call rcu_read_unlock() before copy_to_user(). We can
> release the lock earlier because it is not needed for copy_to_user().
we cannot move the rcu unlock this way, since it protects the value.
So we need to copy the value while still under rcu.
I'm puzzled how I missed this warning.
I guess you have CONFIG_PREEMPT_RCU=y ?
and if (in_atomic()) return; as part of might_fault() hid it.
^ permalink raw reply
* Re: [PATCH net-next 2/2] flow_dissector: add tipc support
From: Eric Dumazet @ 2015-01-22 17:29 UTC (permalink / raw)
To: erik.hugne; +Cc: richard.alpe, netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <1421943032-29924-2-git-send-email-erik.hugne@ericsson.com>
On Thu, 2015-01-22 at 17:10 +0100, erik.hugne@ericsson.com wrote:
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> The flows are hashed on the sending node address, which allows us
> to spread out the TIPC link processing to RPS enabled cores. There
> is no point to include the destination address in the hash as that
> will always be the same for all inbound links. We have experimented
> with a 3-tuple hash over [srcnode, sport, dport], but this showed to
> give slightly lower performance because of increased lock contention
> when the same link was handled by multiple cores.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
> ---
> net/core/flow_dissector.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 4508493..beb83d1 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -178,6 +178,20 @@ ipv6:
> return false;
> }
> }
> + case htons(ETH_P_TIPC): {
> + struct {
> + __be32 pre[3];
> + __be32 srcnode;
> + } *hdr, _hdr;
Is this header defined somewhere in an include file ?
This looks a bit ugly to locally define the format...
^ permalink raw reply
* Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
From: Alexei Starovoitov @ 2015-01-22 17:32 UTC (permalink / raw)
To: Michael Holzheu
Cc: Alexei Starovoitov, Martin Schwidefsky,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu
<holzheu@linux.vnet.ibm.com> wrote:
> Looks like the "test_maps" test case expects to get the keys in
> the wrong order when iterating over the elements:
>
> test_maps: samples/bpf/test_maps.c:79: test_hashmap_sanity: Assertion
> `bpf_get_next_key(map_fd, &key, &next_key) == 0 && next_key == 2' failed.
> Aborted
>
> Fix this and test for the correct order.
that will break this test on x86...
we need to understand first why the order of two elements
came out different on s390...
Could it be that jhash() produced different hash for the same
values on x86 vs s390 ?
The better fix for the test is probably not to assume AB or BA
order, but accept both.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-22 17:44 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Jamal Hadi Salim, John Fastabend, simon.horman, sfeldma, netdev,
davem, gerlitz.or, andy, ast, Jiri Pirko
In-Reply-To: <20150122164951.GA3417@salvia>
On 01/22/15 at 05:49pm, Pablo Neira Ayuso wrote:
> On Thu, Jan 22, 2015 at 03:37:27PM +0000, Thomas Graf wrote:
> > On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
> > > On 01/22/15 10:13, Thomas Graf wrote:
> > >
> > > >I don't follow this. John's proposal allows to decide on a case by
> > > >case basis what we want to export. Just like with ethtool or
> > > >RTNETLINK. There is no direct access to hardware. A user can only
> > > >configure what is being exposed by the kernel.
> > > >
> > >
> > > So if i am a vendor with my own driver, I can expose whatever i want.
> >
> > No. We will reject any driver change attempting to do so on this
> > list.
>
> I think those vendors do not want to push those driver changes
> mainstream. They will likely use these new ndo's to fully expose their
> vendor-specific capabilities distributed in proprietary blobs.
You can achieve the exact same thing with an out of tree tc action,
classifier or even a new link type. Nothing prevents an out of tree
driver to register a new rtnetlink link type and do vendor specific
crap.
Out of tree code can abuse any kernel API in any way it wants. Not
sure how much we can do about that.
That said, as we know, vendor specific SDKs for most of the chips in
question here already exist. I'm not sure why a vendor would want to
use this infrastructure (which is subject to constant internal API
changes) to implement vendor specific APIs if that vendor already has
an indepdendent out of tree SDK.
^ permalink raw reply
* [PATCH] net: macb: allow deffered probe of the driver
From: Nicolae Rosia @ 2015-01-22 17:31 UTC (permalink / raw)
To: netdev@vger.kernel.org, nicolas.ferre@atmel.com
The driver is trying to acquire clocks which maybe
are not available yet. Allow the driver to request
deffered probe by providing a probe function and
registering it with module_platform_driver. [1]
This patch is based on 3.19-rc5.
[1] https://lkml.org/lkml/2013/9/23/118
Signed-off-by: Nicolae Rosia <nicolae.rosia@certsign.ro>
---
drivers/net/ethernet/cadence/macb.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 3767271..4dfcd66 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2148,7 +2148,7 @@ static void macb_probe_queues(void __iomem *mem,
(*num_queues)++;
}
-static int __init macb_probe(struct platform_device *pdev)
+static int macb_probe(struct platform_device *pdev)
{
struct macb_platform_data *pdata;
struct resource *regs;
@@ -2386,7 +2386,7 @@ err_out:
return err;
}
-static int __exit macb_remove(struct platform_device *pdev)
+static int macb_remove(struct platform_device *pdev)
{
struct net_device *dev;
struct macb *bp;
@@ -2449,7 +2449,8 @@ static int macb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(macb_pm_ops, macb_suspend, macb_resume);
static struct platform_driver macb_driver = {
- .remove = __exit_p(macb_remove),
+ .probe = macb_probe,
+ .remove = macb_remove,
.driver = {
.name = "macb",
.of_match_table = of_match_ptr(macb_dt_ids),
@@ -2457,7 +2458,7 @@ static struct platform_driver macb_driver = {
},
};
-module_platform_driver_probe(macb_driver, macb_probe);
+module_platform_driver(macb_driver);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Vincent JARDIN @ 2015-01-22 17:51 UTC (permalink / raw)
To: Tom Herbert; +Cc: Jesse Gross, Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9pnkJBVftqFTK6fcd-toAxsJrvB=drTxWQs_=5s9C0+A@mail.gmail.com>
On 22/01/2015 17:24, Tom Herbert wrote:
> STT is undoubtedly a creative and unique solution I'll give you that,
> but the potential repercussions of allowing this to be widely deployed
> are profound. IMO this needs to be fully explored before it can ever
> be allowed in the kernel. If there has already been discussion on this
> please forward a pointer (I didn't find anything in the IETF mailing
> list archives other than the draft posting announcements), but at the
> minimum these patches warrant a lot of scrutiny.
I share this concern of biased use of TCP, all the critics will be
valid. But anyone can hack TCP (so peer to peer software does or CDN
software does). So, I prefer the let the freedom to the sysadmin to
enable/disable it for their networks. Not having this feature into the
kernel prevent sysadmin from doing it. To be safe, it can be an
experimental feature of the Linux kernel.
Same: LRO/GRO is is bad features: it breaks many times networking (most
IP forwarders must disable it), but it helps for servers. Same for STT
in fact, it has its narrow set of use-cases which are valid.
Best regards,
Vincent
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix slab corruption from use after free on INIT collisions
From: Vlad Yasevich @ 2015-01-22 17:52 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: netdev, linux-sctp
In-Reply-To: <1421947614-31407-1-git-send-email-dborkman@redhat.com>
On 01/22/2015 12:26 PM, Daniel Borkmann wrote:
> When hitting an INIT collision case during the 4WHS with AUTH enabled, as
> already described in detail in commit 1be9a950c646 ("net: sctp: inherit
> auth_capable on INIT collisions"), it can happen that we occasionally
> still remotely trigger the following panic on server side which seems to
> have been uncovered after the fix from commit 1be9a950c646 ...
>
> [ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff
> [ 533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230
> [ 533.940559] PGD 5030f2067 PUD 0
> [ 533.957104] Oops: 0000 [#1] SMP
> [ 533.974283] Modules linked in: sctp mlx4_en [...]
> [ 534.939704] Call Trace:
> [ 534.951833] [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0
> [ 534.984213] [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0
> [ 535.015025] [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170
> [ 535.045661] [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0
> [ 535.074593] [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50
> [ 535.105239] [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp]
> [ 535.138606] [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0
> [ 535.166848] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
>
> ... or depending on the the application, for example this one:
>
> [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff
> [ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0
> [ 1370.054568] PGD 633c94067 PUD 0
> [ 1370.070446] Oops: 0000 [#1] SMP
> [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
> [ 1370.963431] Call Trace:
> [ 1370.974632] [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960
> [ 1371.000863] [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960
> [ 1371.027154] [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170
> [ 1371.054679] [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130
> [ 1371.080183] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
>
> With slab debugging enabled, we can see that the poison has been overwritten:
>
> [ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten
> [ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b
> [ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494
> [ 669.826424] __slab_alloc+0x4bf/0x566
> [ 669.826433] __kmalloc+0x280/0x310
> [ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp]
> [ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
> [ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
> [ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...]
> [ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
> [ 669.826635] __slab_free+0x39/0x2a8
> [ 669.826643] kfree+0x1d6/0x230
> [ 669.826650] kzfree+0x31/0x40
> [ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp]
> [ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp]
> [ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp]
>
> Since this only triggers in some collision-cases with AUTH, the problem at
> heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
> when having refcnt 1, once directly in sctp_assoc_update() and yet again
> from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
> the already kzfree'd memory, which is also consistent with the observation
> of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
> at a later point in time when poison is checked on new allocation).
>
> Reference counting of auth keys revisited:
>
> Shared keys for AUTH chunks are being stored in endpoints and associations
> in endpoint_shared_keys list. On endpoint creation, a null key is being
> added; on association creation, all endpoint shared keys are being cached
> and thus cloned over to the association. struct sctp_shared_key only holds
> a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
> keeps track of users internally through refcounting. Naturally, on assoc
> or enpoint destruction, sctp_shared_key are being destroyed directly and
> the reference on sctp_auth_bytes dropped.
>
> User space can add keys to either list via setsockopt(2) through struct
> sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
> adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
> with refcount 1 and in case of replacement drops the reference on the old
> sctp_auth_bytes. A key can be set active from user space through setsockopt()
> on the id via sctp_auth_set_active_key(), which iterates through either
> endpoint_shared_keys and in case of an assoc, invokes (one of various places)
> sctp_auth_asoc_init_active_key().
>
> sctp_auth_asoc_init_active_key() computes the actual secret from local's
> and peer's random, hmac and shared key parameters and returns a new key
> directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
> the reference if there was a previous one. The secret, which where we
> eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
> intitial refcount of 1, which also stays unchanged eventually in
> sctp_assoc_update(). This key is later being used for crypto layer to
> set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().
>
> To close the loop: asoc->asoc_shared_key is freshly allocated secret
> material and independant of the sctp_shared_key management keeping track
> of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
> ("net: sctp: fix memory leak in auth key management") is independant of
> this bug here since it concerns a different layer (though same structures
> being used eventually). asoc->asoc_shared_key is reference dropped correctly
> on assoc destruction in sctp_association_free() and when active keys are
> being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
> of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
> to remove that sctp_auth_key_put() from there which fixes these panics.
>
> Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/associola.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index f791edd..26d06db 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1182,7 +1182,6 @@ void sctp_assoc_update(struct sctp_association *asoc,
> asoc->peer.peer_hmacs = new->peer.peer_hmacs;
> new->peer.peer_hmacs = NULL;
>
> - sctp_auth_key_put(asoc->asoc_shared_key);
> sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC);
> }
>
>
^ permalink raw reply
* Re: [PATCH] bpf: Call rcu_read_unlock() before copy_to_user()
From: Michael Holzheu @ 2015-01-22 17:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Martin Schwidefsky,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <CAADnVQLnrAgk3vTppugqCtSsHL4XiZeQJrQi3cqhgLCCq1v8Pg@mail.gmail.com>
On Thu, 22 Jan 2015 09:27:21 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Thu, Jan 22, 2015 at 7:57 AM, Michael Holzheu
> <holzheu@linux.vnet.ibm.com> wrote:
> > We must not hold locks when calling copy_to_user():
> >
> > BUG: sleeping function called from invalid context at mm/memory.c:3732
> > in_atomic(): 0, irqs_disabled(): 0, pid: 671, name: test_maps
> > 1 lock held by test_maps/671:
> > #0: (rcu_read_lock){......}, at: [<0000000000264190>] map_lookup_elem+0xe8/0x260
> > Preemption disabled at:[<00000000001be3b6>] vprintk_default+0x56/0x68
> >
> > CPU: 0 PID: 671 Comm: test_maps Not tainted 3.19.0-rc5-00117-g5eb11d6-dirty #424
> > 000000001e447bb0 000000001e447c40 0000000000000002 0000000000000000
> > 000000001e447ce0 000000001e447c58 000000001e447c58 0000000000115c8a
> > 0000000000000000 0000000000c08246 0000000000c27e8a 000000000000000b
> > 000000001e447ca0 000000001e447c40 0000000000000000 0000000000000000
> > 0000000000000000 0000000000115c8a 000000001e447c40 000000001e447ca0
> > Call Trace:
> > ([<0000000000115b7e>] show_trace+0x12e/0x150)
> > [<0000000000115c40>] show_stack+0xa0/0x100
> > [<00000000009b163c>] dump_stack+0x74/0xc8
> > [<000000000017424a>] ___might_sleep+0x23a/0x248
> > [<00000000002b58e8>] might_fault+0x70/0xe8
> > [<0000000000264230>] map_lookup_elem+0x188/0x260
> > [<0000000000264716>] SyS_bpf+0x20e/0x840
> > [<00000000009bbe3a>] system_call+0xd6/0x24c
> > [<000003fffd15f566>] 0x3fffd15f566
> > 1 lock held by test_maps/671:
> > #0: (rcu_read_lock){......}, at: [<0000000000264190>] map_lookup_elem+0xe8/0x260
> >
> > So call rcu_read_unlock() before copy_to_user(). We can
> > release the lock earlier because it is not needed for copy_to_user().
>
> we cannot move the rcu unlock this way, since it protects the value.
> So we need to copy the value while still under rcu.
Ok, right. I assume you will provide the correct fix.
> I'm puzzled how I missed this warning.
> I guess you have CONFIG_PREEMPT_RCU=y ?
Yes.
Regards,
Michael
^ permalink raw reply
* [PATCH] net: phy: fix phy device autoneg wrong value
From: Nicolae Rosia @ 2015-01-22 17:56 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
f.fainelli@gmail.com
In phy_device_create, autoneg is set to AUTONEG_ENABLE.
When using the generic phy driver (phy_device.c),
genphy_config_init reads BMSR and finds out if autonegotiation
is possible and sets the phy device features accordingly.
phy_sanitize_settings is supposed to set the right value of
autoneg, but it is never called if autonegotiation is enabled,
which is always the case.
Signed-off-by: Nicolae Rosia <nicolae.rosia@certsign.ro>
---
drivers/net/phy/phy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 767cd11..9c35136 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -249,9 +249,6 @@ static void phy_sanitize_settings(struct phy_device
*phydev)
unsigned int idx;
/* Sanitize settings based on PHY capabilities */
- if ((features & SUPPORTED_Autoneg) == 0)
- phydev->autoneg = AUTONEG_DISABLE;
-
idx = phy_find_valid(phy_find_setting(phydev->speed, phydev->duplex),
features);
@@ -436,6 +433,9 @@ int phy_start_aneg(struct phy_device *phydev)
mutex_lock(&phydev->lock);
+ if ((phydev->supported & SUPPORTED_Autoneg) == 0)
+ phydev->autoneg = AUTONEG_DISABLE;
+
if (AUTONEG_DISABLE == phydev->autoneg)
phy_sanitize_settings(phydev);
--
2.1.0
^ permalink raw reply related
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-22 17:58 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150122154840.GC1863@nanopsycho.orion>
On 01/22/15 at 04:48pm, Jiri Pirko wrote:
> Thu, Jan 22, 2015 at 04:37:27PM CET, tgraf@suug.ch wrote:
> >On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
> >> On 01/22/15 10:13, Thomas Graf wrote:
> >>
> >> >I don't follow this. John's proposal allows to decide on a case by
> >> >case basis what we want to export. Just like with ethtool or
> >> >RTNETLINK. There is no direct access to hardware. A user can only
> >> >configure what is being exposed by the kernel.
> >> >
> >>
> >> So if i am a vendor with my own driver, I can expose whatever i want.
> >
> >No. We will reject any driver change attempting to do so on this
> >list.
>
> That is not 100%, on contrary. If the infrastructure would be made to
> explicitly disallow that kind of behaviour, it would be much safer.
I'm very much in favour of that. Ideas?
^ 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