* [PATCH 1/2] net: qrtr: Broadcast messages only from control port
From: Arun Kumar Neelakantam @ 2018-07-04 14:19 UTC (permalink / raw)
To: davem, bjorn.andersson
Cc: netdev, linux-kernel, linux-arm-msm, Arun Kumar Neelakantam,
Florian Westphal, Nicolas Dechesne, Denys Vlasenko
In-Reply-To: <1530713973-26696-1-git-send-email-aneela@codeaurora.org>
The broadcast node id should only be sent with the control port id.
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
---
net/qrtr/qrtr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 2aa07b5..7ffc9a3 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -764,6 +764,10 @@ static int qrtr_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
node = NULL;
if (addr->sq_node == QRTR_NODE_BCAST) {
enqueue_fn = qrtr_bcast_enqueue;
+ if (addr->sq_port != QRTR_PORT_CTRL) {
+ release_sock(sk);
+ return -ENOTCONN;
+ }
} else if (addr->sq_node == ipc->us.sq_node) {
enqueue_fn = qrtr_local_enqueue;
} else {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 2/2] net: qrtr: Reset the node and port ID of broadcast messages
From: Arun Kumar Neelakantam @ 2018-07-04 14:19 UTC (permalink / raw)
To: davem, bjorn.andersson
Cc: netdev, linux-kernel, linux-arm-msm, Arun Kumar Neelakantam,
Florian Westphal, Hannes Frederic Sowa, Denys Vlasenko,
Nicolas Dechesne
In-Reply-To: <1530713973-26696-1-git-send-email-aneela@codeaurora.org>
All the control messages broadcast to remote routers are using
QRTR_NODE_BCAST instead of using local router NODE ID which cause
the packets to be dropped on remote router due to invalid NODE ID.
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
---
net/qrtr/qrtr.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 7ffc9a3..86e1e37 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -191,8 +191,13 @@ static int qrtr_node_enqueue(struct qrtr_node *node, struct sk_buff *skb,
hdr->type = cpu_to_le32(type);
hdr->src_node_id = cpu_to_le32(from->sq_node);
hdr->src_port_id = cpu_to_le32(from->sq_port);
- hdr->dst_node_id = cpu_to_le32(to->sq_node);
- hdr->dst_port_id = cpu_to_le32(to->sq_port);
+ if (to->sq_port == QRTR_PORT_CTRL) {
+ hdr->dst_node_id = cpu_to_le32(node->nid);
+ hdr->dst_port_id = cpu_to_le32(QRTR_NODE_BCAST);
+ } else {
+ hdr->dst_node_id = cpu_to_le32(to->sq_node);
+ hdr->dst_port_id = cpu_to_le32(to->sq_port);
+ }
hdr->size = cpu_to_le32(len);
hdr->confirm_rx = 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
From: Matteo Croce @ 2018-07-04 14:23 UTC (permalink / raw)
To: netdev, dev, Pravin B Shelar; +Cc: Stefano Brivio, Jiri Benc, Aaron Conole
From: Stefano Brivio <sbrivio@redhat.com>
Open vSwitch sends to userspace all received packets that have
no associated flow (thus doing an "upcall"). Then the userspace
program creates a new flow and determines the actions to apply
based on its configuration.
When a single port generates a high rate of upcalls, it can
prevent other ports from dispatching their own upcalls. vswitchd
overcomes this problem by creating many netlink sockets for each
port, but it quickly exceeds any reasonable maximum number of
open files when dealing with huge amounts of ports.
This patch queues all the upcalls into a list, ordering them in
a per-port round-robin fashion, and schedules a deferred work to
queue them to userspace.
The algorithm to queue upcalls in a round-robin fashion,
provided by Stefano, is based on these two rules:
- upcalls for a given port must be inserted after all the other
occurrences of upcalls for the same port already in the queue,
in order to avoid out-of-order upcalls for a given port
- insertion happens once the highest upcall count for any given
port (excluding the one currently at hand) is greater than the
count for the port we're queuing to -- if this condition is
never true, upcall is queued at the tail. This results in a
per-port round-robin order.
In order to implement a fair round-robin behaviour, a variable
queueing delay is introduced. This will be zero if the upcalls
rate is below a given threshold, and grows linearly with the
queue utilisation (i.e. upcalls rate) otherwise.
This ensures fairness among ports under load and with few
netlink sockets.
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Co-authored-by: Stefano Brivio <sbrivio@redhat.com>
---
net/openvswitch/datapath.c | 143 ++++++++++++++++++++++++++++++++++---
net/openvswitch/datapath.h | 27 ++++++-
2 files changed, 161 insertions(+), 9 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 0f5ce77460d4..2cfd504562d8 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -59,6 +59,10 @@
#include "vport-internal_dev.h"
#include "vport-netdev.h"
+#define UPCALL_QUEUE_TIMEOUT msecs_to_jiffies(10)
+#define UPCALL_QUEUE_MAX_DELAY msecs_to_jiffies(10)
+#define UPCALL_QUEUE_MAX_LEN 200
+
unsigned int ovs_net_id __read_mostly;
static struct genl_family dp_packet_genl_family;
@@ -225,6 +229,116 @@ void ovs_dp_detach_port(struct vport *p)
ovs_vport_del(p);
}
+static void ovs_dp_upcall_dequeue(struct work_struct *work)
+{
+ struct datapath *dp = container_of(work, struct datapath,
+ upcalls.work.work);
+ struct dp_upcall_info *u, *n;
+
+ spin_lock_bh(&dp->upcalls.lock);
+ list_for_each_entry_safe(u, n, &dp->upcalls.list, list) {
+ if (unlikely(ovs_dp_upcall(dp, u->skb, &u->key, u, 0)))
+ kfree_skb(u->skb);
+ else
+ consume_skb(u->skb);
+ kfree(u);
+ }
+ dp->upcalls.len = 0;
+ INIT_LIST_HEAD(&dp->upcalls.list);
+ spin_unlock_bh(&dp->upcalls.lock);
+}
+
+/* Calculate the delay of the deferred work which sends the upcalls. If it ran
+ * more than UPCALL_QUEUE_TIMEOUT ago, schedule the work immediately. Otherwise
+ * return a time between 0 and UPCALL_QUEUE_MAX_DELAY, depending linearly on the
+ * queue utilisation.
+ */
+static unsigned long ovs_dp_upcall_delay(int queue_len, unsigned long last_run)
+{
+ if (jiffies - last_run >= UPCALL_QUEUE_TIMEOUT)
+ return 0;
+
+ return UPCALL_QUEUE_MAX_DELAY -
+ UPCALL_QUEUE_MAX_DELAY * queue_len / UPCALL_QUEUE_MAX_LEN;
+}
+
+static int ovs_dp_upcall_queue_roundrobin(struct datapath *dp,
+ struct dp_upcall_info *upcall)
+{
+ struct list_head *head = &dp->upcalls.list;
+ struct dp_upcall_info *here = NULL, *pos;
+ bool find_next = true;
+ unsigned long delay;
+ int err = 0;
+ u8 count;
+
+ spin_lock_bh(&dp->upcalls.lock);
+ if (dp->upcalls.len > UPCALL_QUEUE_MAX_LEN) {
+ err = -ENOSPC;
+ goto out;
+ }
+
+ /* Insert upcalls in the list in a per-port round-robin fashion, look
+ * for insertion point:
+ * - to avoid out-of-order per-port upcalls, we can insert only after
+ * the last occurrence of upcalls for the same port
+ * - insert upcall only after we reach a count of occurrences for a
+ * given port greater than the one we're inserting this upcall for
+ */
+ list_for_each_entry(pos, head, list) {
+ /* Count per-port upcalls. */
+ if (dp->upcalls.count[pos->port_no] == U8_MAX - 1) {
+ err = -ENOSPC;
+ goto out_clear;
+ }
+ dp->upcalls.count[pos->port_no]++;
+
+ if (pos->port_no == upcall->port_no) {
+ /* Another upcall for the same port: move insertion
+ * point here, keep looking for insertion condition to
+ * be still met further on.
+ */
+ find_next = true;
+ here = pos;
+ continue;
+ }
+
+ count = dp->upcalls.count[upcall->port_no];
+ if (find_next && dp->upcalls.count[pos->port_no] >= count) {
+ /* Insertion condition met: no need to look further,
+ * unless another upcall for the same port occurs later.
+ */
+ find_next = false;
+ here = pos;
+ }
+ }
+
+ if (here)
+ list_add(&upcall->list, &here->list);
+ else
+ list_add_tail(&upcall->list, head);
+
+ dp->upcalls.len++;
+
+out_clear:
+ /* Clear the per-port counters we used, so that we don't need to zero
+ * out the counters array on every insertion.
+ */
+ list_for_each_entry_reverse(pos, head, list)
+ dp->upcalls.count[pos->port_no] = 0;
+
+out:
+ spin_unlock_bh(&dp->upcalls.lock);
+
+ if (!err) {
+ delay = ovs_dp_upcall_delay(dp->upcalls.len,
+ dp->upcalls.last_run);
+ mod_delayed_work(system_wq, &dp->upcalls.work, delay);
+ }
+
+ return err;
+}
+
/* Must be called with rcu_read_lock. */
void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)
{
@@ -241,18 +355,25 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)
/* Look up flow. */
flow = ovs_flow_tbl_lookup_stats(&dp->table, key, &n_mask_hit);
if (unlikely(!flow)) {
- struct dp_upcall_info upcall;
+ struct dp_upcall_info *upcall;
int error;
- memset(&upcall, 0, sizeof(upcall));
- upcall.cmd = OVS_PACKET_CMD_MISS;
- upcall.portid = ovs_vport_find_upcall_portid(p, skb);
- upcall.mru = OVS_CB(skb)->mru;
- error = ovs_dp_upcall(dp, skb, key, &upcall, 0);
+ upcall = kzalloc(sizeof(*upcall), GFP_ATOMIC);
+ if (!upcall) {
+ kfree_skb(skb);
+ stats_counter = &stats->n_missed;
+ goto out;
+ }
+
+ upcall->cmd = OVS_PACKET_CMD_MISS;
+ upcall->portid = ovs_vport_find_upcall_portid(p, skb);
+ upcall->port_no = p->port_no;
+ upcall->mru = OVS_CB(skb)->mru;
+ upcall->skb = skb;
+ upcall->key = *key;
+ error = ovs_dp_upcall_queue_roundrobin(dp, upcall);
if (unlikely(error))
kfree_skb(skb);
- else
- consume_skb(skb);
stats_counter = &stats->n_missed;
goto out;
}
@@ -1589,6 +1710,10 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
for (i = 0; i < DP_VPORT_HASH_BUCKETS; i++)
INIT_HLIST_HEAD(&dp->ports[i]);
+ INIT_LIST_HEAD(&dp->upcalls.list);
+ spin_lock_init(&dp->upcalls.lock);
+ INIT_DELAYED_WORK(&dp->upcalls.work, ovs_dp_upcall_dequeue);
+
err = ovs_meters_init(dp);
if (err)
goto err_destroy_ports_array;
@@ -1658,6 +1783,8 @@ static void __dp_destroy(struct datapath *dp)
{
int i;
+ cancel_delayed_work_sync(&dp->upcalls.work);
+
for (i = 0; i < DP_VPORT_HASH_BUCKETS; i++) {
struct vport *vport;
struct hlist_node *n;
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index c9eb267c6f7e..f8b8bb679929 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -24,6 +24,7 @@
#include <linux/mutex.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
+#include <linux/workqueue.h>
#include <linux/u64_stats_sync.h>
#include <net/ip_tunnels.h>
@@ -70,6 +71,12 @@ struct dp_stats_percpu {
* @net: Reference to net namespace.
* @max_headroom: the maximum headroom of all vports in this datapath; it will
* be used by all the internal vports in this dp.
+ * @upcalls.work: sends queued upcalls to userspace.
+ * @upcalls.list: list of queued upcalls.
+ * @upcalls.len: elements in upcall_list.
+ * @upcalls.lock: lock for the upcall list.
+ * @upcalls.count: array used to sort the upcalls delivered to userspace.
+ * @upcalls.last_run: timestamp of last work run.
*
* Context: See the comment on locking at the top of datapath.c for additional
* locking information.
@@ -96,6 +103,16 @@ struct datapath {
/* Switch meters. */
struct hlist_head *meters;
+
+ /* Upcalls queue handling. */
+ struct {
+ struct delayed_work work;
+ struct list_head list;
+ int len;
+ spinlock_t lock; /* Protects len and upcall list. */
+ u8 count[DP_MAX_PORTS];
+ unsigned long last_run;
+ } upcalls;
};
/**
@@ -116,7 +133,7 @@ struct ovs_skb_cb {
#define OVS_CB(skb) ((struct ovs_skb_cb *)(skb)->cb)
/**
- * struct dp_upcall - metadata to include with a packet to send to userspace
+ * struct dp_upcall_info - Upcall for userspace, including metadata to send
* @cmd: One of %OVS_PACKET_CMD_*.
* @userdata: If nonnull, its variable-length value is passed to userspace as
* %OVS_PACKET_ATTR_USERDATA.
@@ -125,6 +142,10 @@ struct ovs_skb_cb {
* counter.
* @egress_tun_info: If nonnull, becomes %OVS_PACKET_ATTR_EGRESS_TUN_KEY.
* @mru: If not zero, Maximum received IP fragment size.
+ * @list: list within vport for upcall queue handling.
+ * @skb: the socket buffer that generated the upcall.
+ * @key: flow key.
+ * @port_no: port number within the datapath.
*/
struct dp_upcall_info {
struct ip_tunnel_info *egress_tun_info;
@@ -134,6 +155,10 @@ struct dp_upcall_info {
u32 portid;
u8 cmd;
u16 mru;
+ struct list_head list;
+ struct sk_buff *skb;
+ struct sw_flow_key key;
+ u16 port_no;
};
/**
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net: dsa: bcm_sf2: remove redundant variable off
From: Andrew Lunn @ 2018-07-04 14:25 UTC (permalink / raw)
To: Colin King
Cc: Vivien Didelot, Florian Fainelli, David S . Miller, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20180704065436.13719-1-colin.king@canonical.com>
Hi Florian
I this a bug? It seems to be a result of moving to
b53_disable_port() in f86ad77faf.
Before you would handle the CPU port differently than a normal
port. After this change, there is no difference?
Andrew
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Mark Brown @ 2018-07-04 14:32 UTC (permalink / raw)
To: Ben Whitten
Cc: Steve deRosier, Matthias Brugger, Jiri Pirko, Hasnain Virk,
netdev@vger.kernel.org, Marcel Holtmann, Dollar Chen,
linux-kernel@vger.kernel.org, David S . Miller, Janus Piwek,
linux-spi@vger.kernel.org, LoRa_Community_Support@semtech.com,
Jian-Hong Pan, Ken Yu, Michael Röder, Andreas Färber,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BY1PR02MB1114BC0F12654B1E7C614108E7410@BY1PR02MB1114.namprd02.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 819 bytes --]
On Wed, Jul 04, 2018 at 01:41:42PM +0000, Ben Whitten wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> In my SX1257 driver currently the regmap is backed via SPI with
> devm_regmap_init_spi, please correct me if I am wrong but if I
> understand correctly this could be split out to regmap backed by SPI
> in the case of a direct host connection, and a regmap backed by the
> SX1301's regmapped strobing register interface, regmap_bus?
Yes.
> Is there a precedent to this I can examine?
There's lots of devices that provide both SPI and I2C, you'd just be
using a regmap_bus instead of the I2C one. I can't recall an example of
the specific combination you're looking for though.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 3/4] Add .ndo_set_rx_mode to cdc_ncm_netdev_ops
From: Miguel Rodríguez Pérez @ 2018-07-04 14:32 UTC (permalink / raw)
To: oliver, linux-usb, netdev, gregkh; +Cc: Miguel Rodríguez Pérez
In-Reply-To: <20180701090553.7776-4-miguel@det.uvigo.gal>
The cdc_ncm driver overrides the net_device_ops structure used by usbnet
to be able to hook into .ndo_change_mtu. However, the structure was
missing the .ndo_set_rx_mode field, preventing the driver from
hooking into usbnet's set_rx_mode. This patch adds the missing callback to
usbnet_set_rx_mode in net_device_ops.
Signed-off-by: Miguel Rodríguez Pérez <miguel@det.uvigo.gal>
---
drivers/net/usb/cdc_ncm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 9e1b74590682..342bf9bb91b5 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -755,6 +755,7 @@ static const struct net_device_ops cdc_ncm_netdev_ops = {
.ndo_stop = usbnet_stop,
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
+ .ndo_set_rx_mode = usbnet_set_rx_mode,
.ndo_get_stats64 = usbnet_get_stats64,
.ndo_change_mtu = cdc_ncm_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
--
2.17.1
^ permalink raw reply related
* [PATCH] qmi_wwan: add support for Quectel EG91
From: Matevz Vucnik @ 2018-07-04 14:40 UTC (permalink / raw)
To: bjorn; +Cc: davem, netdev, linux-usb, linux-kernel, Matevz Vucnik
This adds the USB id of LTE modem Quectel EG91. It requires the
same quirk as other Quectel modems to make it work.
Signed-off-by: Matevz Vucnik <vucnikm@gmail.com>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8fac8e1..829c05b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1255,6 +1255,7 @@ static const struct usb_device_id products[] = {
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
{QMI_FIXED_INTF(0x2c7c, 0x0296, 4)}, /* Quectel BG96 */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0306, 4)}, /* Quectel EP06 Mini PCIe */
+ {QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 3/4] Add .ndo_set_rx_mode to cdc_ncm_netdev_ops
From: Miguel Rodríguez Pérez @ 2018-07-04 14:41 UTC (permalink / raw)
To: oliver, linux-usb, netdev, gregkh
In-Reply-To: <20180704143217.6363-1-miguel@det.uvigo.gal>
This is another alternative, but it would require exporting
usbnet_set_rx_mode. The main drawback of this approach is that it would
need to make use that net_device_ops copy in cdc_ncm remains updated,
should usbnet.c version change.
On the other hand, the structure can be kept const.
Which alternative do you think is best?
On 04/07/18 16:32, Miguel Rodríguez Pérez wrote:
> The cdc_ncm driver overrides the net_device_ops structure used by usbnet
> to be able to hook into .ndo_change_mtu. However, the structure was
> missing the .ndo_set_rx_mode field, preventing the driver from
> hooking into usbnet's set_rx_mode. This patch adds the missing callback to
> usbnet_set_rx_mode in net_device_ops.
>
> Signed-off-by: Miguel Rodríguez Pérez <miguel@det.uvigo.gal>
> ---
> drivers/net/usb/cdc_ncm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 9e1b74590682..342bf9bb91b5 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -755,6 +755,7 @@ static const struct net_device_ops cdc_ncm_netdev_ops = {
> .ndo_stop = usbnet_stop,
> .ndo_start_xmit = usbnet_start_xmit,
> .ndo_tx_timeout = usbnet_tx_timeout,
> + .ndo_set_rx_mode = usbnet_set_rx_mode,
> .ndo_get_stats64 = usbnet_get_stats64,
> .ndo_change_mtu = cdc_ncm_change_mtu,
> .ndo_set_mac_address = eth_mac_addr,
>
--
Miguel Rodríguez Pérez
Laboratorio de Redes
EE Telecomunicación – Universidade de Vigo
^ permalink raw reply
* Re: [PATCH net-next 08/10] r8169: remove rtl8169_set_speed_xmii
From: Andrew Lunn @ 2018-07-04 14:46 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David Miller, Florian Fainelli, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <30dcf9f0-b5a0-1690-6964-a0afff6c3fec@gmail.com>
On Mon, Jul 02, 2018 at 11:54:54PM +0200, Heiner Kallweit wrote:
> On 02.07.2018 23:21, Andrew Lunn wrote:
> >> - auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
> >
> > This bit you probably want to keep. The PHY never says it support
> > Pause. The MAC needs to enable pause if the MAC supports pause.
> >
> Actually I assumed that phylib would do this for me. But:
> In phy_probe() first phydev->supported is copied to
> phydev->advertising, and only after this both pause flags are added
> to phydev->supported. Therefore I think they are not advertised.
> Is this intentional? It sounds a little weird to me to add the
> pause flags to the supported features per default, but not
> advertise them.
phylib has no idea if the MAC supports Pause. So it should not enable
it by default. The MAC needs to enable it. And a lot of MAC drivers
get this wrong...
> Except e.g. we call by chance phy_set_max_speed(), which copies
> phydev->supported to phydev->advertising after having adjusted
> the supported speeds.
As you correctly pointed out, phy_set_max_speed() is masking out too
much.
> If this is not a bug, then where would be the right place to add
> the pause flags to phydev->advertising?
Before you call phy_start().
Andrew
^ permalink raw reply
* netdev 0x12 conference update
From: Jamal Hadi Salim @ 2018-07-04 14:53 UTC (permalink / raw)
To: netdev, linux-wireless, netfilter-devel
Folks,
This is a small update to the community on the Netdev 0x12 conference
(July 11-13, 2018 in Montreal, Canada, https://www.netdevconf.org/0x12).
We still have a week to go - so not too late to register.
This email provides a good summary:
https://lists.netdevconf.org/pipermail/people/2018-June/000067.html
For regular updates, please subscribe to people@lists.netdevconf.org
(more info at: https://lists.netdevconf.org/cgi-bin/mailman/listinfo/people)
If twitter is your thing then follow us: @netdev01
and use hashtag #netdevconf
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] qmi_wwan: add support for Quectel EG91
From: Bjørn Mork @ 2018-07-04 14:55 UTC (permalink / raw)
To: Matevz Vucnik; +Cc: davem, netdev, linux-usb, linux-kernel
In-Reply-To: <1530715205-13676-1-git-send-email-vucnikm@gmail.com>
On July 4, 2018 4:40:05 PM GMT+02:00, Matevz Vucnik <vucnikm@gmail.com> wrote:
>This adds the USB id of LTE modem Quectel EG91. It requires the
>same quirk as other Quectel modems to make it work.
>
>Signed-off-by: Matevz Vucnik <vucnikm@gmail.com>
>---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>index 8fac8e1..829c05b 100644
>--- a/drivers/net/usb/qmi_wwan.c
>+++ b/drivers/net/usb/qmi_wwan.c
>@@ -1255,6 +1255,7 @@ static const struct usb_device_id products[] = {
> {QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
> {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)}, /* Quectel BG96 */
> {QMI_QUIRK_SET_DTR(0x2c7c, 0x0306, 4)}, /* Quectel EP06 Mini PCIe */
>+ {QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */
>
> /* 4. Gobi 1000 devices */
> {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
I know it's not perfect before, but can we try to keep new entries in numerical order?
Thanks
Bjørn
^ permalink raw reply
* RE: [net-next,v2] tcp: Improve setsockopt() TCP_USER_TIMEOUT accuracy
From: David Laight @ 2018-07-04 14:57 UTC (permalink / raw)
To: 'Neal Cardwell', Jonathan Maxwell
Cc: David Miller, Eric Dumazet, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Netdev, LKML, jmaxwell@redhat.com
In-Reply-To: <CADVnQykfvmWyOJxT7_nHPOvfNEwi7+Hz2qJPooPpNLmdMWChYw@mail.gmail.com>
From: Neal Cardwell
> Sent: 04 July 2018 15:14
>
> On Tue, Jul 3, 2018 at 8:06 PM Jon Maxwell <jmaxwell37@gmail.com> wrote:
> >
> > Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
> > ---
> > net/ipv4/tcp_timer.c | 48 +++++++++++++++++++++++++++++++++++++++---------
> > 1 file changed, 39 insertions(+), 9 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> > index 3b3611729928..d129e670d02a 100644
> > --- a/net/ipv4/tcp_timer.c
> > +++ b/net/ipv4/tcp_timer.c
...
> > +static __u32 tcp_clamp_rto_to_user_timeout(struct sock *sk)
> > +{
> > + struct inet_connection_sock *icsk = inet_csk(sk);
> > + __u32 rto = icsk->icsk_rto;
Why cache rto past all the function calls until it is needed?
> > + __u32 elapsed, user_timeout;
> > + unsigned int start_ts;
>
> I'd suggest u32 here for start_ts (per the rationale above).
>
> > +
> > + start_ts = tcp_retransmit_stamp(sk);
> > + if (!icsk->icsk_user_timeout || !start_ts)
> > + return rto;
> > + elapsed = tcp_time_stamp(tcp_sk(sk)) - start_ts;
> > + user_timeout = jiffies_to_msecs(icsk->icsk_user_timeout);
> > + if (elapsed >= user_timeout)
> > + rto = 1; /* user timeout has passed; fire ASAP */
> > + else
> > + rto = min(rto, (__u32)msecs_to_jiffies(user_timeout - elapsed));
>
> My sense is that min_t would be preferred here, e.g:
>
> rto = min_t(__u32, rto, msecs_to_jiffies(user_timeout - elapsed));
Think I'd just write the conditional...
> > + return rto;
> > +}
Looks to me like it doesn't correctly allow for the conversions
between millisecond and jiffies either.
I suspect the msecs_to_jiffies() call can return zero (unless it rounds up).
Coding with a signed 'time until user timeout' might make it simpler.
David
^ permalink raw reply
* general protection fault in smap_list_hash_remove
From: syzbot @ 2018-07-04 15:09 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 2bdea157b999 Merge branch 'sctp-fully-support-for-dscp-and..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=102e5b48400000
kernel config: https://syzkaller.appspot.com/x/.config?x=f62553dc846b0692
dashboard link: https://syzkaller.appspot.com/bug?extid=b912ba691bb508925d72
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=168d1662400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1556a594400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b912ba691bb508925d72@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4454 Comm: syz-executor594 Not tainted 4.18.0-rc3+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:do_raw_spin_lock+0x27/0x200 kernel/locking/spinlock_debug.c:111
Code: 00 00 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 56 41 55 41 54
53 48 89 fb 48 83 c7 04 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 7b
RSP: 0018:ffff8801ad3e77c8 EFLAGS: 00010292
RAX: dffffc0000000000 RBX: 0000000000000230 RCX: 0000000000000000
RDX: 0000000000000046 RSI: 0000000000000000 RDI: 0000000000000234
RBP: ffff8801ad3e77f0 R08: 0000000000000001 R09: 0000000000000000
R10: ffffed00359b8286 R11: ffff8801acdc1433 R12: dffffc0000000000
R13: ffff8801d8b35540 R14: ffff8801c65bb118 R15: ffff8801c65bb100
FS: 00007f51a93fb700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc4338af60 CR3: 00000001ad3f7000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
smap_list_hash_remove+0xa3/0x470 kernel/bpf/sockmap.c:1683
sock_hash_ctx_update_elem.isra.27+0x1140/0x1690 kernel/bpf/sockmap.c:2384
sock_hash_update_elem+0x157/0x2f0 kernel/bpf/sockmap.c:2418
map_update_elem+0x5c4/0xc90 kernel/bpf/syscall.c:765
__do_sys_bpf kernel/bpf/syscall.c:2296 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2267 [inline]
__x64_sys_bpf+0x32d/0x510 kernel/bpf/syscall.c:2267
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445d19
Code: e8 2c b7 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f51a93face8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 0000000000445d19
RDX: 0000000000000020 RSI: 0000000020000180 RDI: 0000000000000002
RBP: 00000000006dac38 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd36a1e17f R14: 00007f51a93fb9c0 R15: 0000000000000005
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 996d9c1f5fab271a ]---
RIP: 0010:do_raw_spin_lock+0x27/0x200 kernel/locking/spinlock_debug.c:111
Code: 00 00 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 56 41 55 41 54
53 48 89 fb 48 83 c7 04 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 7b
RSP: 0018:ffff8801ad3e77c8 EFLAGS: 00010292
RAX: dffffc0000000000 RBX: 0000000000000230 RCX: 0000000000000000
RDX: 0000000000000046 RSI: 0000000000000000 RDI: 0000000000000234
RBP: ffff8801ad3e77f0 R08: 0000000000000001 R09: 0000000000000000
R10: ffffed00359b8286 R11: ffff8801acdc1433 R12: dffffc0000000000
R13: ffff8801d8b35540 R14: ffff8801c65bb118 R15: ffff8801c65bb100
FS: 00007f51a93fb700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc4338af60 CR3: 00000001ad3f7000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: wlcore: Fix memory leak in wlcore_cmd_wait_for_event_or_timeout
From: Kalle Valo @ 2018-07-04 15:14 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Tony Lindgren, David S. Miller, linux-wireless, netdev,
linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20180628130809.GA8147@embeddedor.com>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> In case memory resources for *events_vector* were allocated, release
> them before return.
>
> Addresses-Coverity-ID: 1470194 ("Resource leak")
> Fixes: 4ec7cece87b3 ("wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Acked-by: Tony Lindgren <tony@atomide.com>
Patch applied to wireless-drivers-next.git, thanks.
04614fe46f31 wlcore: Fix memory leak in wlcore_cmd_wait_for_event_or_timeout
--
https://patchwork.kernel.org/patch/10493849/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] atmel: using strlcpy() to avoid possible buffer overflows
From: Kalle Valo @ 2018-07-04 15:15 UTC (permalink / raw)
To: YueHaibing
Cc: simon, linux-kernel, netdev, linux-wireless, davem,
andy.shevchenko, YueHaibing
In-Reply-To: <20180630063341.9900-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> 'firmware' is a module param which may been longer than firmware_id,
> so using strlcpy() to guard against overflows. Also priv is allocated
> with zeroed memory,no need to set firmware_id[0] to '\0'.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
f9cbaeb52930 atmel: using strlcpy() to avoid possible buffer overflows
--
https://patchwork.kernel.org/patch/10498009/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* WARNING: locking bug in register_lock_class
From: syzbot @ 2018-07-04 15:48 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 1904148a361a Merge tag 'powerpc-4.18-3' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13ea3924400000
kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370
dashboard link: https://syzkaller.appspot.com/bug?extid=892f961d5cef6601aaf7
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10b0a434400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1360b160400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+892f961d5cef6601aaf7@syzkaller.appspotmail.com
WARNING: CPU: 0 PID: 25919 at kernel/locking/lockdep.c:704
arch_local_save_flags arch/x86/include/asm/paravirt.h:778 [inline]
WARNING: CPU: 0 PID: 25919 at kernel/locking/lockdep.c:704
look_up_lock_class kernel/locking/lockdep.c:695 [inline]
WARNING: CPU: 0 PID: 25919 at kernel/locking/lockdep.c:704
register_lock_class+0xce6/0x2650 kernel/locking/lockdep.c:754
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 25919 Comm: syz-executor677 Not tainted 4.18.0-rc2+ #123
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+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:arch_local_save_flags arch/x86/include/asm/paravirt.h:778 [inline]
RIP: 0010:look_up_lock_class kernel/locking/lockdep.c:695 [inline]
RIP: 0010:register_lock_class+0xce6/0x2650 kernel/locking/lockdep.c:754
Code: f9 ff ff 4c 89 ff 44 89 85 68 fc ff ff 89 8d 70 fc ff ff e8 cc 99 5b
00 44 8b 85 68 fc ff ff 8b 8d 70 fc ff ff e9 6f f9 ff ff <0f> 0b e9 c8 f6
ff ff 48 8d 50 01 48 89 15 28 22 22 09 48 8d 14 80
RSP: 0018:ffff8801b0b7ee08 EFLAGS: 00010083
RAX: 0000000000000004 RBX: ffffffff8a5c01b0 RCX: 0000000000000000
RDX: ffffffff887db060 RSI: ffffffff886d1ee0 RDI: 1ffffffff154956c
RBP: ffff8801b0b7f210 R08: 0000000000000000 R09: dffffc0000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 1ffff1003616fdd1
R13: 0000000000000003 R14: 0000000000000000 R15: ffff8801b81f7920
__lock_acquire+0x1bd/0x5020 kernel/locking/lockdep.c:3323
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
lock_sock_nested+0x46/0x120 net/core/sock.c:2834
lock_sock include/net/sock.h:1474 [inline]
do_ipv6_setsockopt.isra.9+0x5ba/0x4680 net/ipv6/ipv6_sockglue.c:167
ipv6_setsockopt+0xbd/0x170 net/ipv6/ipv6_sockglue.c:922
udpv6_setsockopt+0x62/0xa0 net/ipv6/udp.c:1472
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3040
__sys_setsockopt+0x1c5/0x3b0 net/socket.c:1911
__do_sys_setsockopt net/socket.c:1922 [inline]
__se_sys_setsockopt net/socket.c:1919 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1919
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447c59
Code: e8 bc bd 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb 06 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4e66aa9db8 EFLAGS: 00000297 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006e39fc RCX: 0000000000447c59
RDX: 0000000000000037 RSI: 0000000000000029 RDI: 0000000000000006
RBP: 00000000006e39f8 R08: 0000000000000010 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000297 R12: 0000000000000000
R13: 00007ffcd170ce8f R14: 00007f4e66aaa9c0 R15: 0000000000000008
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
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.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] qmi_wwan: add support for Quectel EG91
From: Bjørn Mork @ 2018-07-04 15:56 UTC (permalink / raw)
To: Matevž Vučnik; +Cc: davem, netdev, linux-usb, linux-kernel
In-Reply-To: <CAJRueBROA936kdgmH3kwp0X4CD=Y+KJ7_iqzuZ8dJqidBRzYiA@mail.gmail.com>
Matevž Vučnik <vucnikm@gmail.com> writes:
> Sorry, I missed this one. It's a good idea to keep numerical order. Is it ok
> to fix it and send a new patch?
Yes, sure. Just label it as v2 or similar to make it clear that it's a
new version of the same patch.
Bjørn
^ permalink raw reply
* Re: [PATCH v4 net-next 7/9] net: ipv4: listified version of ip_rcv
From: Edward Cree @ 2018-07-04 16:01 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <68230d9e-e93c-ef91-4b54-e7aebedf1f84@solarflare.com>
On 02/07/18 16:14, Edward Cree wrote:
> +/* Receive a list of IP packets */
> +void ip_list_rcv(struct list_head *head, struct packet_type *pt,
> + struct net_device *orig_dev)
> +{
> + struct net_device *curr_dev = NULL;
> + struct net *curr_net = NULL;
> + struct sk_buff *skb, *next;
> + struct list_head sublist;
> +
> + list_for_each_entry_safe(skb, next, head, list) {
> + struct net_device *dev = skb->dev;
> + struct net *net = dev_net(dev);
> +
> + skb = ip_rcv_core(skb, net);
> + if (skb == NULL)
> + continue;
I've spotted a bug here, in that if ip_rcv_core() eats the skb (e.g. by
freeing it) it won't list_del() it, so when we process the sublist we'll
end up trying to process this skb anyway.
Thus, places where an skb could get freed (possibly remotely, as in nf
hooks that can steal packets) need to use the dequeue/enqueue model
rather than the list_cut_before() approach.
Followup patches soon.
-Ed
^ permalink raw reply
* [PATCH v2] qmi_wwan: add support for Quectel EG91
From: Matevz Vucnik @ 2018-07-04 16:12 UTC (permalink / raw)
To: bjorn; +Cc: davem, netdev, linux-usb, linux-kernel, Matevz Vucnik
This adds the USB id of LTE modem Quectel EG91. It requires the
same quirk as other Quectel modems to make it work.
Signed-off-by: Matevz Vucnik <vucnikm@gmail.com>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8fac8e1..3850280 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1253,6 +1253,7 @@ static const struct usb_device_id products[] = {
{QMI_QUIRK_SET_DTR(0x1e0e, 0x9001, 5)}, /* SIMCom 7100E, 7230E, 7600E ++ */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0 Mini PCIe */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
+ {QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */
{QMI_FIXED_INTF(0x2c7c, 0x0296, 4)}, /* Quectel BG96 */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0306, 4)}, /* Quectel EP06 Mini PCIe */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] qmi_wwan: add support for Quectel EG91
From: Bjørn Mork @ 2018-07-04 16:27 UTC (permalink / raw)
To: Matevz Vucnik; +Cc: davem, netdev, linux-usb, linux-kernel
In-Reply-To: <1530720768-18349-1-git-send-email-vucnikm@gmail.com>
On July 4, 2018 6:12:48 PM GMT+02:00, Matevz Vucnik <vucnikm@gmail.com> wrote:
>This adds the USB id of LTE modem Quectel EG91. It requires the
>same quirk as other Quectel modems to make it work.
>
>Signed-off-by: Matevz Vucnik <vucnikm@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/3] bpf: btf: add btf print functionality
From: Okash Khawaja @ 2018-07-04 16:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180703152331.151d1c4b@cakuba.netronome.com>
hi,
On Tue, Jul 03, 2018 at 03:23:31PM -0700, Jakub Kicinski wrote:
> On Tue, 3 Jul 2018 22:46:00 +0100, Okash Khawaja wrote:
> > On Mon, Jul 02, 2018 at 10:06:59PM -0700, Jakub Kicinski wrote:
> > > On Mon, 2 Jul 2018 11:39:15 -0700, Okash Khawaja wrote:
> > > > +#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
> > > > +#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
> > >
> > > Perhaps it's just me but BIT_OFFSET or BIT_COUNT as a name of this macro
> > > would make it more obvious to parse in the code below.
> > I don't mind either. However these macro names are also used inside
> > kernel for same purpose. For sake of consistency, I'd recommend we keep
> > them :)
>
> Ugh, okay :)
>
> > > > + } print_num;
> > > > +
> > > > + total_bits_offset = bit_offset + BTF_INT_OFFSET(int_type);
> > > > + data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
> > > > + bit_offset = BITS_PER_BYTE_MASKED(total_bits_offset);
> > > > + bits_to_copy = bits + bit_offset;
> > > > + bytes_to_copy = BITS_ROUNDUP_BYTES(bits_to_copy);
> > > > +
> > > > + print_num.u64_num = 0;
> > > > + memcpy(&print_num.u64_num, data, bytes_to_copy);
> > >
> > > This scheme is unlikely to work on big endian machines...
> > Can you give an example how?
>
> On BE:
>
> Input: [0x01, 0x82]
> Bit length: 15
> Bytes to copy: 2
> bit_offset: 0
> upper_bits: 7
>
> print_num.u64_num = 0;
> # [0, 0, 0, 0, 0, 0, 0, 0]
>
> memcpy(&print_num.u64_num, data, bytes_to_copy);
> # [0x01, 0x82, 0, 0, 0, 0, 0, 0]
>
> mask = (1 << upper_bits) - 1;
> # mask = 0x7f
>
> print_num.u8_nums[bytes_to_copy - 1] &= mask;
> # [0x01, 0x02, 0, 0, 0, 0, 0, 0]
>
> printf("0x%llx", print_num.u64_num);
> # 0x0102000000000000 AKA 72620543991349248
> # expected:
> # 0x0102 AKA 258
>
> Am I missing something?
yes you're right, good catch! i'll fix this. thanks vrey much :)
>
> > > > + upper_bits = BITS_PER_BYTE_MASKED(bits_to_copy);
> > > > + if (upper_bits) {
> > > > + uint8_t mask = (1 << upper_bits) - 1;
> > > > +
> > > > + print_num.u8_nums[bytes_to_copy - 1] &= mask;
> > > > + }
> > > > +
> > > > + print_num.u64_num >>= bit_offset;
> > > > +
> > > > + if (is_plain_text)
> > > > + jsonw_printf(jw, "0x%llx", print_num.u64_num);
> > > > + else
> > > > + jsonw_printf(jw, "%llu", print_num.u64_num);
> > > > +}
> > > > +
> > > > +static int btf_dumper_int(const struct btf_type *t, uint8_t bit_offset,
> > > > + const void *data, json_writer_t *jw,
> > > > + bool is_plain_text)
> > > > +{
> > > > + uint32_t *int_type = (uint32_t *)(t + 1);
> > > > + uint32_t bits = BTF_INT_BITS(*int_type);
> > > > + int ret = 0;
> > > > +
> > > > + /* if this is bit field */
> > > > + if (bit_offset || BTF_INT_OFFSET(*int_type) ||
> > > > + BITS_PER_BYTE_MASKED(bits)) {
> > > > + btf_dumper_int_bits(*int_type, bit_offset, data, jw,
> > > > + is_plain_text);
> > > > + return ret;
> > > > + }
> > > > +
> > > > + switch (BTF_INT_ENCODING(*int_type)) {
> > > > + case 0:
> > > > + if (BTF_INT_BITS(*int_type) == 64)
> > > > + jsonw_printf(jw, "%lu", *((uint64_t *)data));
> > > > + else if (BTF_INT_BITS(*int_type) == 32)
> > > > + jsonw_printf(jw, "%u", *((uint32_t *)data));
> > > > + else if (BTF_INT_BITS(*int_type) == 16)
> > > > + jsonw_printf(jw, "%hu", *((uint16_t *)data));
> > > > + else if (BTF_INT_BITS(*int_type) == 8)
> > > > + jsonw_printf(jw, "%hhu", *((uint8_t *)data));
> > > > + else
> > > > + btf_dumper_int_bits(*int_type, bit_offset, data, jw,
> > > > + is_plain_text);
> > > > + break;
> > > > + case BTF_INT_SIGNED:
> > > > + if (BTF_INT_BITS(*int_type) == 64)
> > > > + jsonw_printf(jw, "%ld", *((int64_t *)data));
> > > > + else if (BTF_INT_BITS(*int_type) == 32)
> > > > + jsonw_printf(jw, "%d", *((int32_t *)data));
> > > > + else if (BTF_INT_BITS(*int_type) == 16)
> > >
> > > Please drop the double space. Both for 16 where it makes no sense and
> > > for 8 where it's marginally useful but not really.
> > >
> > > > + jsonw_printf(jw, "%hd", *((int16_t *)data));
> > > > + else if (BTF_INT_BITS(*int_type) == 8)
> > > > + jsonw_printf(jw, "%hhd", *((int8_t *)data));
> > > > + else
> > > > + btf_dumper_int_bits(*int_type, bit_offset, data, jw,
> > > > + is_plain_text);
> > > > + break;
> > > > + case BTF_INT_CHAR:
> > > > + if (*((char *)data) == '\0')
> > > > + jsonw_null(jw);
> > >
> > > Mm.. I don't think 0 char is equivalent to null.
> > Yes, thanks. Will fix.
> >
> > >
> > > > + else if (isprint(*((char *)data)))
> > > > + jsonw_printf(jw, "\"%c\"", *((char *)data));
> > >
> > > This looks very suspicious. So if I see a "6" for a char field it's
> > > either a 6 ('\u0006') or a 54 ('6')...
> > It will always be 54. May be I missed your point. Could you explain why
> > it would be other than 54?
>
> Ah, I think I missed that %c is in quotes...
>
> > > > + else
> > > > + if (is_plain_text)
> > > > + jsonw_printf(jw, "%hhx", *((char *)data));
>
> This seems to be missing a "0x" prefix?
yes it does. will add 0x.
>
> > > > + else
> > > > + jsonw_printf(jw, "%hhd", *((char *)data));
> > >
> > > ... I think you need to always print a string, and express it as
> > > \u00%02hhx for non-printable.
> > Okay that makes sense
>
> Yeah, IDK, char can be used as a byte as well as a string. In eBPF
> it may actually be more likely to just be used as a raw byte buffer...
> Either way I think it may be nice to keep it consistent, at least for
> the JSON output could we do either always ints or always characters?
yes, makes sense. i'll keep them always characters.
^ permalink raw reply
* Re: KASAN: stack-out-of-bounds Read in timerqueue_add
From: Dmitry Vyukov @ 2018-07-04 16:34 UTC (permalink / raw)
To: syzbot
Cc: LKML, syzkaller-bugs, Thomas Gleixner, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <000000000000b2989805702eedd3@google.com>
On Wed, Jul 4, 2018 at 6:29 PM, syzbot
<syzbot+b680e42077a0d7c9a0c4@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: fc36def997cf mm: teach dump_page() to correctly output poi..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=167e3b92400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f62553dc846b0692
> dashboard link: https://syzkaller.appspot.com/bug?extid=b680e42077a0d7c9a0c4
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1030a858400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1167aaa4400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b680e42077a0d7c9a0c4@syzkaller.appspotmail.com
+bpf maintainers since the repro seems to deal to bpf maps
We've got a splash of crashes today, all seem to suggest some kind of
stack corruption/overflow, see the last 6 bugs here:
https://syzkaller.appspot.com/
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> IPVS: ftp: loaded support on port[0] = 21
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in timerqueue_add+0x249/0x2b0
> lib/timerqueue.c:52
> Read of size 8 at addr ffff8801af537cf8 by task syz-executor591/7178
>
> CPU: 0 PID: 7178 Comm: syz-executor591 Not tainted 4.18.0-rc3+ #130
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> timerqueue_add+0x249/0x2b0 lib/timerqueue.c:52
> enqueue_hrtimer+0x18e/0x540 kernel/time/hrtimer.c:960
> __run_hrtimer kernel/time/hrtimer.c:1413 [inline]
> __hrtimer_run_queues+0xc07/0x10c0 kernel/time/hrtimer.c:1460
> hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> smp_apic_timer_interrupt+0x165/0x730 arch/x86/kernel/apic/apic.c:1050
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
> </IRQ>
>
> The buggy address belongs to the page:
> page:ffffea0006bd4dc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 0000000000000000 ffffffff06bd0101 0000000000000000
> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801af537b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801af537c00: 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2
>>
>> ffff8801af537c80: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2
>
> ^
> ffff8801af537d00: f8 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 00 00 00 00
> ffff8801af537d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> 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.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000b2989805702eedd3%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: KASAN: stack-out-of-bounds Read in timerqueue_add
From: Alexei Starovoitov @ 2018-07-04 16:59 UTC (permalink / raw)
To: Dmitry Vyukov, John Fastabend
Cc: syzbot, LKML, syzkaller-bugs, Thomas Gleixner, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <CACT4Y+b0fysS3D4QCcfw5X-rFt3c1a7XAHntN4Q7p9tdHNCuow@mail.gmail.com>
On Wed, Jul 4, 2018 at 9:34 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Wed, Jul 4, 2018 at 6:29 PM, syzbot
> <syzbot+b680e42077a0d7c9a0c4@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: fc36def997cf mm: teach dump_page() to correctly output poi..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=167e3b92400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=f62553dc846b0692
>> dashboard link: https://syzkaller.appspot.com/bug?extid=b680e42077a0d7c9a0c4
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1030a858400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1167aaa4400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+b680e42077a0d7c9a0c4@syzkaller.appspotmail.com
>
> +bpf maintainers since the repro seems to deal to bpf maps
>
> We've got a splash of crashes today, all seem to suggest some kind of
> stack corruption/overflow, see the last 6 bugs here:
> https://syzkaller.appspot.com/
John, this is sockhash map related. Please take a look asap.
^ permalink raw reply
* [PATCH] net/mlx5: Use 2-factor allocator calls
From: Kees Cook @ 2018-07-04 17:28 UTC (permalink / raw)
To: David S. Miller
Cc: Saeed Mahameed, Tariq Toukan, Leon Romanovsky, Vadim Pasternak,
netdev, linux-kernel
This restores the use of 2-factor allocation helpers that were already
fixed treewide. Please do not use open-coded multiplication; prefer,
instead, using 2-factor allocation helpers.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index bbd2fd0b2e06..c7791d036e9f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -349,7 +349,8 @@ static int mlx5e_rq_alloc_mpwqe_info(struct mlx5e_rq *rq,
{
int wq_sz = mlx5_wq_ll_get_size(&rq->mpwqe.wq);
- rq->mpwqe.info = kvzalloc_node(wq_sz * sizeof(*rq->mpwqe.info),
+ rq->mpwqe.info = kvzalloc_node(array_size(wq_sz,
+ sizeof(*rq->mpwqe.info)),
GFP_KERNEL, cpu_to_node(c->cpu));
if (!rq->mpwqe.info)
return -ENOMEM;
@@ -969,7 +970,7 @@ static int mlx5e_alloc_xdpsq_db(struct mlx5e_xdpsq *sq, int numa)
{
int wq_sz = mlx5_wq_cyc_get_size(&sq->wq);
- sq->db.di = kvzalloc_node(sizeof(*sq->db.di) * wq_sz,
+ sq->db.di = kvzalloc_node(array_size(wq_sz, sizeof(*sq->db.di)),
GFP_KERNEL, numa);
if (!sq->db.di) {
mlx5e_free_xdpsq_db(sq);
@@ -1028,7 +1029,8 @@ static int mlx5e_alloc_icosq_db(struct mlx5e_icosq *sq, int numa)
{
u8 wq_sz = mlx5_wq_cyc_get_size(&sq->wq);
- sq->db.ico_wqe = kvzalloc_node(sizeof(*sq->db.ico_wqe) * wq_sz,
+ sq->db.ico_wqe = kvzalloc_node(array_size(wq_sz,
+ sizeof(*sq->db.ico_wqe)),
GFP_KERNEL, numa);
if (!sq->db.ico_wqe)
return -ENOMEM;
@@ -1083,9 +1085,11 @@ static int mlx5e_alloc_txqsq_db(struct mlx5e_txqsq *sq, int numa)
int wq_sz = mlx5_wq_cyc_get_size(&sq->wq);
int df_sz = wq_sz * MLX5_SEND_WQEBB_NUM_DS;
- sq->db.dma_fifo = kvzalloc_node(df_sz * sizeof(*sq->db.dma_fifo),
+ sq->db.dma_fifo = kvzalloc_node(array_size(df_sz,
+ sizeof(*sq->db.dma_fifo)),
GFP_KERNEL, numa);
- sq->db.wqe_info = kvzalloc_node(wq_sz * sizeof(*sq->db.wqe_info),
+ sq->db.wqe_info = kvzalloc_node(array_size(wq_sz,
+ sizeof(*sq->db.wqe_info)),
GFP_KERNEL, numa);
if (!sq->db.dma_fifo || !sq->db.wqe_info) {
mlx5e_free_txqsq_db(sq);
--
2.17.1
--
Kees Cook
Pixel Security
^ permalink raw reply related
* Re: [PATCH rdma-next 0/3] Dump and fill MKEY
From: Jason Gunthorpe @ 2018-07-04 17:47 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi,
Yishai Hadas, Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180619054724.32677-1-leon@kernel.org>
On Tue, Jun 19, 2018 at 08:47:21AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> MLX5 IB HCA offers the memory key, dump_fill_mkey to increase
> performance, when used in a send or receive operations.
>
> It is used to force local HCA operations to skip the PCI bus access,
> while keeping track of the processed length in the ibv_sge handling.
>
> In this three patch series, we expose various bits in our HW
> spec file (mlx5_ifc.h), move unneeded for mlx5_core FW command and
> export such memory key to user space thought our mlx5-abi header file.
>
> Thanks
This looks fine, can you send a pull request off the mlx5 branch
please?
Thanks,
Jason
^ 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