* [net-next 1/1] tipc: make link capability update thread safe
From: Jon Maloy @ 2018-07-18 17:50 UTC (permalink / raw)
To: davem, netdev
Cc: gordan.mihaljevic, tung.q.nguyen, hoang.h.le, jon.maloy,
canh.d.luu, ying.xue, tipc-discussion
The commit referred to below introduced an update of the link
capabilities field that is not safe. Given the recently added
feature to remove idle node and link items after 5 minutes, there
is a small risk that the update will happen at the very moment the
targeted link is being removed. To avoid this we have to perform
the update inside the node item's write lock protection.
Fixes: 9012de508956 ("tipc: add sequence number check for link STATE messages")
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/node.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 52fd80b..3819ab1 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -370,13 +370,17 @@ static struct tipc_node *tipc_node_create(struct net *net, u32 addr,
spin_lock_bh(&tn->node_list_lock);
n = tipc_node_find(net, addr);
if (n) {
+ if (n->capabilities == capabilities)
+ goto exit;
/* Same node may come back with new capabilities */
+ write_lock_bh(&n->lock);
n->capabilities = capabilities;
for (bearer_id = 0; bearer_id < MAX_BEARERS; bearer_id++) {
l = n->links[bearer_id].link;
if (l)
tipc_link_update_caps(l, capabilities);
}
+ write_unlock_bh(&n->lock);
goto exit;
}
n = kzalloc(sizeof(*n), GFP_ATOMIC);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] net/nfc: Avoid stalls when nfc_alloc_send_skb() returned NULL.
From: David Miller @ 2018-07-18 17:52 UTC (permalink / raw)
To: penguin-kernel; +Cc: sameo, linux-wireless, netdev, syzbot+d29d18215e477cfbfbdd
In-Reply-To: <1531907847-3500-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Wed, 18 Jul 2018 18:57:27 +0900
> syzbot is reporting stalls at nfc_llcp_send_ui_frame() [1]. This is
> because nfc_llcp_send_ui_frame() is retrying the loop without any delay
> when nonblocking nfc_alloc_send_skb() returned NULL.
>
> Since there is no need to use MSG_DONTWAIT if we retry until
> sock_alloc_send_pskb() succeeds, let's use blocking call.
> Also, in case an unexpected error occurred, let's break the loop
> if blocking nfc_alloc_send_skb() failed.
>
> [1] https://syzkaller.appspot.com/bug?id=4a131cc571c3733e0eff6bc673f4e36ae48f19c6
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Reported-by: syzbot <syzbot+d29d18215e477cfbfbdd@syzkaller.appspotmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: display number of rx and tx pages free
From: David Miller @ 2018-07-18 17:53 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1531915572-8850-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 18 Jul 2018 17:36:12 +0530
> display free rx and tx page count in the meminfo of
> an adapter.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH 3/3] net: macb: add support for padding and fcs computation
From: David Miller @ 2018-07-18 17:54 UTC (permalink / raw)
To: claudiu.beznea; +Cc: nicolas.ferre, netdev, jennifer.dahm, nathan.sullivan
In-Reply-To: <1531918689-22658-4-git-send-email-claudiu.beznea@microchip.com>
From: Claudiu Beznea <claudiu.beznea@microchip.com>
Date: Wed, 18 Jul 2018 15:58:09 +0300
>
> +static int macb_pad_and_fcs(struct sk_buff **skb, struct net_device *ndev)
> +{
> + struct sk_buff *nskb;
> + int padlen = ETH_ZLEN - (*skb)->len;
> + int headroom = skb_headroom(*skb);
> + int tailroom = skb_tailroom(*skb);
> + bool cloned = skb_cloned(*skb) || skb_header_cloned(*skb);
> + u32 fcs;
Please keep local variable ordered from longest to shortest line
(ie. reverse christmas tree format).
Thank you.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: show in bpftool map overview whether btf is available
From: Jakub Kicinski @ 2018-07-18 18:08 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: alexei.starovoitov, netdev
In-Reply-To: <20180718091942.2963-1-daniel@iogearbox.net>
On Wed, 18 Jul 2018 11:19:42 +0200, Daniel Borkmann wrote:
> For a quick overview in 'bpftool map' display 'btf' if it's
> available for the dump for a specific map:
>
> # bpftool map list
> 11: array flags 0x0 btf
> key 4B value 20B max_entries 40 memlock 4096B
>
> # bpftool --json --pretty map list
> [{
> "id": 11,
> "type": "array",
> "flags": 0,
> "btf_available": true,
> "bytes_key": 4,
> "bytes_value": 20,
> "max_entries": 40,
> "bytes_memlock": 4096
> }
> ]
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Hmm.. would it make sense to provide the actual BTF IDs instead of just
yes/no? At least in JSON?
^ permalink raw reply
* [PATCH net] bonding: set default miimon value for non-arp modes if not set
From: Jarod Wilson @ 2018-07-18 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: Jarod Wilson, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek,
Mahesh Bandewar, David S . Miller, netdev, stable
For some time now, if you load the bonding driver and configure bond
parameters via sysfs using minimal config options, such as specifying
nothing but the mode, relying on defaults for everything else, modes
that cannot use arp monitoring (802.3ad, balance-tlb, balance-alb) all
wind up with both arp_interval=0 (as it should be) and miimon=0, which
means the miimon monitor thread never actually runs. This is particularly
problematic for 802.3ad.
For example, from an LNST recipe I've set up:
$ modprobe bonding max_bonds=0"
$ echo "+t_bond0" > /sys/class/net/bonding_masters"
$ ip link set t_bond0 down"
$ echo "802.3ad" > /sys/class/net/t_bond0/bonding/mode"
$ ip link set ens1f1 down"
$ echo "+ens1f1" > /sys/class/net/t_bond0/bonding/slaves"
$ ip link set ens1f0 down"
$ echo "+ens1f0" > /sys/class/net/t_bond0/bonding/slaves"
$ ethtool -i t_bond0"
$ ip link set ens1f1 up"
$ ip link set ens1f0 up"
$ ip link set t_bond0 up"
$ ip addr add 192.168.9.1/24 dev t_bond0"
$ ip addr add 2002::1/64 dev t_bond0"
This bond comes up okay, but things look slightly suspect in
/proc/net/bonding/t_bond0 output:
$ grep -i mii /proc/net/bonding/t_bond0
MII Status: up
MII Polling Interval (ms): 0
MII Status: up
MII Status: up
Now, pull a cable on one of the ports in the bond, then reconnect it, and
you'll see:
Slave Interface: ens1f0
MII Status: down
Speed: 1000 Mbps
Duplex: full
I believe this became a major issue as of commit 4d2c0cda0744, which for
802.3ad bonds, sets slave->link = BOND_LINK_DOWN, with a comment about
relying on link monitoring via miimon to set it correctly, but since the
miimon work queue never runs, the link just stays marked down.
If we simply tweak bond_option_mode_set() slightly, we can check for the
non-arp modes having no miimon value set, and insert BOND_DEFAULT_MIIMON,
which gets things back in full working order. This problem exists as far
back as 4.14, and might be worth fixing in all stable trees since, though
the work-around is to simply specify an miimon value yourself.
Reported-by: Bob Ball <ball@umich.edu>
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Mahesh Bandewar <maheshb@google.com>
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: stable@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
---
drivers/net/bonding/bond_options.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
index 98663c50ded0..4d5d01cb8141 100644
--- a/drivers/net/bonding/bond_options.c
+++ b/drivers/net/bonding/bond_options.c
@@ -743,15 +743,20 @@ const struct bond_option *bond_opt_get(unsigned int option)
static int bond_option_mode_set(struct bonding *bond,
const struct bond_opt_value *newval)
{
- if (!bond_mode_uses_arp(newval->value) && bond->params.arp_interval) {
- netdev_dbg(bond->dev, "%s mode is incompatible with arp monitoring, start mii monitoring\n",
- newval->string);
- /* disable arp monitoring */
- bond->params.arp_interval = 0;
- /* set miimon to default value */
- bond->params.miimon = BOND_DEFAULT_MIIMON;
- netdev_dbg(bond->dev, "Setting MII monitoring interval to %d\n",
- bond->params.miimon);
+ if (!bond_mode_uses_arp(newval->value)) {
+ if (bond->params.arp_interval) {
+ netdev_dbg(bond->dev, "%s mode is incompatible with arp monitoring, start mii monitoring\n",
+ newval->string);
+ /* disable arp monitoring */
+ bond->params.arp_interval = 0;
+ }
+
+ if (!bond->params.miimon) {
+ /* set miimon to default value */
+ bond->params.miimon = BOND_DEFAULT_MIIMON;
+ netdev_dbg(bond->dev, "Setting MII monitoring interval to %d\n",
+ bond->params.miimon);
+ }
}
if (newval->value == BOND_MODE_ALB)
--
2.16.1
^ permalink raw reply related
* Re: [PATCH iproute2 5/5] bpf: implement btf handling and map annotation
From: Jakub Kicinski @ 2018-07-18 18:13 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: dsahern, alexei.starovoitov, netdev
In-Reply-To: <f0406f6a-ef26-5fe0-1fb4-1eda676743f5@iogearbox.net>
On Wed, 18 Jul 2018 11:33:22 +0200, Daniel Borkmann wrote:
> On 07/18/2018 10:42 AM, Daniel Borkmann wrote:
> > On 07/18/2018 02:27 AM, Jakub Kicinski wrote:
> >> On Wed, 18 Jul 2018 01:31:22 +0200, Daniel Borkmann wrote:
> >>> # bpftool map dump id 386
> >>> [{
> >>> "key": 0,
> >>> "value": {
> >>> "": {
> >>> "value": 0,
> >>> "ifindex": 0,
> >>> "mac": []
> >>> }
> >>> }
> >>> },{
> >>> "key": 1,
> >>> "value": {
> >>> "": {
> >>> "value": 0,
> >>> "ifindex": 0,
> >>> "mac": []
> >>> }
> >>> }
> >>> },{
> >>> [...]
> >>
> >> Ugh, the empty keys ("") look worrying, we should probably improve
> >> handling of anonymous structs in bpftool :S
> >
> > Yeah agree, I think it would be nice to see a more pahole style dump
> > where we have types and member names along with the value as otherwise
> > it might be a bit confusing.
>
> Another feature that would be super useful imho would be in the /single/
> map view e.g. 'bpftool map show id 123' to have a detailed BTF key+value
> type dump, so in addition to the basic map info we show pahole like info
> of the structs with length/offsets.
That sounds good! We could also consider adding a btf object and
commands to interrogate BTF types in the kernel in general.. Perhaps
then we could add something like bpftool btf describe map id 123.
Having the single map view show more information seems interesting, but
I wonder if it could be surprising. Is there precedent for such
behaviour?
^ permalink raw reply
* Re: [net-next, v6, 6/7] net-sysfs: Add interface for Rx queue(s) map per Tx queue
From: Andrei Vagin @ 2018-07-18 18:22 UTC (permalink / raw)
To: Nambiar, Amritha, Ingo Molnar, Peter Zijlstra
Cc: netdev, davem, alexander.h.duyck, willemdebruijn.kernel,
sridhar.samudrala, alexander.duyck, edumazet, hannes, tom, tom,
jasowang, gaowanlong
In-Reply-To: <4b7f5d42-1b81-f095-f313-f43e41cf8601@intel.com>
On Tue, Jul 10, 2018 at 07:28:49PM -0700, Nambiar, Amritha wrote:
> On 7/4/2018 12:20 AM, Andrei Vagin wrote:
> > Hello Amritha,
> >
> > I see a following warning on 4.18.0-rc3-next-20180703.
> > It looks like a problem is in this series.
> >
> > [ 1.084722] ============================================
> > [ 1.084797] WARNING: possible recursive locking detected
> > [ 1.084872] 4.18.0-rc3-next-20180703+ #1 Not tainted
> > [ 1.084949] --------------------------------------------
> > [ 1.085024] swapper/0/1 is trying to acquire lock:
> > [ 1.085100] 00000000cf973d46 (cpu_hotplug_lock.rw_sem){++++}, at: static_key_slow_inc+0xe/0x20
> > [ 1.085189]
> > [ 1.085189] but task is already holding lock:
> > [ 1.085271] 00000000cf973d46 (cpu_hotplug_lock.rw_sem){++++}, at: init_vqs+0x513/0x5a0
> > [ 1.085357]
> > [ 1.085357] other info that might help us debug this:
> > [ 1.085450] Possible unsafe locking scenario:
> > [ 1.085450]
> > [ 1.085531] CPU0
> > [ 1.085605] ----
> > [ 1.085679] lock(cpu_hotplug_lock.rw_sem);
> > [ 1.085753] lock(cpu_hotplug_lock.rw_sem);
> > [ 1.085828]
> > [ 1.085828] *** DEADLOCK ***
> > [ 1.085828]
> > [ 1.085916] May be due to missing lock nesting notation
> > [ 1.085916]
> > [ 1.085998] 3 locks held by swapper/0/1:
> > [ 1.086074] #0: 00000000244bc7da (&dev->mutex){....}, at: __driver_attach+0x5a/0x110
> > [ 1.086164] #1: 00000000cf973d46 (cpu_hotplug_lock.rw_sem){++++}, at: init_vqs+0x513/0x5a0
> > [ 1.086248] #2: 000000005cd8463f (xps_map_mutex){+.+.}, at: __netif_set_xps_queue+0x8d/0xc60
> > [ 1.086336]
> > [ 1.086336] stack backtrace:
> > [ 1.086419] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc3-next-20180703+ #1
> > [ 1.086504] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > [ 1.086587] Call Trace:
> > [ 1.086667] dump_stack+0x85/0xcb
> > [ 1.086744] __lock_acquire+0x68a/0x1330
> > [ 1.086821] ? lock_acquire+0x9f/0x200
> > [ 1.086900] ? find_held_lock+0x2d/0x90
> > [ 1.086976] ? lock_acquire+0x9f/0x200
> > [ 1.087051] lock_acquire+0x9f/0x200
> > [ 1.087126] ? static_key_slow_inc+0xe/0x20
> > [ 1.087205] cpus_read_lock+0x3e/0x80
> > [ 1.087280] ? static_key_slow_inc+0xe/0x20
> > [ 1.087355] static_key_slow_inc+0xe/0x20
> > [ 1.087435] __netif_set_xps_queue+0x216/0xc60
> > [ 1.087512] virtnet_set_affinity+0xf0/0x130
> > [ 1.087589] init_vqs+0x51b/0x5a0
> > [ 1.087665] virtnet_probe+0x39f/0x870
> > [ 1.087742] virtio_dev_probe+0x170/0x220
> > [ 1.087819] driver_probe_device+0x30b/0x480
> > [ 1.087897] ? set_debug_rodata+0x11/0x11
> > [ 1.087972] __driver_attach+0xe0/0x110
> > [ 1.088064] ? driver_probe_device+0x480/0x480
> > [ 1.088141] bus_for_each_dev+0x79/0xc0
> > [ 1.088221] bus_add_driver+0x164/0x260
> > [ 1.088302] ? veth_init+0x11/0x11
> > [ 1.088379] driver_register+0x5b/0xe0
> > [ 1.088402] ? veth_init+0x11/0x11
> > [ 1.088402] virtio_net_driver_init+0x6d/0x90
> > [ 1.088402] do_one_initcall+0x5d/0x34c
> > [ 1.088402] ? set_debug_rodata+0x11/0x11
> > [ 1.088402] ? rcu_read_lock_sched_held+0x6b/0x80
> > [ 1.088402] kernel_init_freeable+0x1ea/0x27b
> > [ 1.088402] ? rest_init+0xd0/0xd0
> > [ 1.088402] kernel_init+0xa/0x110
> > [ 1.088402] ret_from_fork+0x3a/0x50
> > [ 1.094190] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
> >
> >
> > https://travis-ci.org/avagin/linux/jobs/399867744
> >
>
> With this patch series, I introduced static_key for XPS maps
> (xps_needed), so static_key_slow_inc() is used to switch branches. The
> definition of static_key_slow_inc() has cpus_read_lock in place. In the
> virtio_net driver, XPS queues are initialized after setting the
> queue:cpu affinity in virtnet_set_affinity() which is already protected
> within cpus_read_lock. Hence, the warning here trying to acquire
> cpus_read_lock when it is already held.
>
> A quick fix for this would be to just extract netif_set_xps_queue() out
> of the lock by simply wrapping it with another put/get_online_cpus
> (unlock right before and hold lock right after). But this may not a
> clean solution. It'd help if I can get suggestions on what would be a
> clean option to fix this without extensively changing the code in
> virtio_net. Is it mandatory to protect the affinitization with
> read_lock? I don't see similar lock in other drivers while setting the
> affinity.
> I understand this warning should go away, but isn't it safe to
> have multiple readers.
Peter and Ingo, maybe you could explain why it isn't safe to take one
reader lock twice?
Thanks,
Andrei
>
> > On Fri, Jun 29, 2018 at 09:27:07PM -0700, Amritha Nambiar wrote:
> >> Extend transmit queue sysfs attribute to configure Rx queue(s) map
> >> per Tx queue. By default no receive queues are configured for the
> >> Tx queue.
> >>
> >> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
> >>
> >> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> >> ---
> >> net/core/net-sysfs.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 83 insertions(+)
> >>
> >> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> >> index b39987c..f25ac5f 100644
> >> --- a/net/core/net-sysfs.c
> >> +++ b/net/core/net-sysfs.c
> >> @@ -1283,6 +1283,88 @@ static ssize_t xps_cpus_store(struct netdev_queue *queue,
> >>
> >> static struct netdev_queue_attribute xps_cpus_attribute __ro_after_init
> >> = __ATTR_RW(xps_cpus);
> >> +
> >> +static ssize_t xps_rxqs_show(struct netdev_queue *queue, char *buf)
> >> +{
> >> + struct net_device *dev = queue->dev;
> >> + struct xps_dev_maps *dev_maps;
> >> + unsigned long *mask, index;
> >> + int j, len, num_tc = 1, tc = 0;
> >> +
> >> + index = get_netdev_queue_index(queue);
> >> +
> >> + if (dev->num_tc) {
> >> + num_tc = dev->num_tc;
> >> + tc = netdev_txq_to_tc(dev, index);
> >> + if (tc < 0)
> >> + return -EINVAL;
> >> + }
> >> + mask = kcalloc(BITS_TO_LONGS(dev->num_rx_queues), sizeof(long),
> >> + GFP_KERNEL);
> >> + if (!mask)
> >> + return -ENOMEM;
> >> +
> >> + rcu_read_lock();
> >> + dev_maps = rcu_dereference(dev->xps_rxqs_map);
> >> + if (!dev_maps)
> >> + goto out_no_maps;
> >> +
> >> + for (j = -1; j = netif_attrmask_next(j, NULL, dev->num_rx_queues),
> >> + j < dev->num_rx_queues;) {
> >> + int i, tci = j * num_tc + tc;
> >> + struct xps_map *map;
> >> +
> >> + map = rcu_dereference(dev_maps->attr_map[tci]);
> >> + if (!map)
> >> + continue;
> >> +
> >> + for (i = map->len; i--;) {
> >> + if (map->queues[i] == index) {
> >> + set_bit(j, mask);
> >> + break;
> >> + }
> >> + }
> >> + }
> >> +out_no_maps:
> >> + rcu_read_unlock();
> >> +
> >> + len = bitmap_print_to_pagebuf(false, buf, mask, dev->num_rx_queues);
> >> + kfree(mask);
> >> +
> >> + return len < PAGE_SIZE ? len : -EINVAL;
> >> +}
> >> +
> >> +static ssize_t xps_rxqs_store(struct netdev_queue *queue, const char *buf,
> >> + size_t len)
> >> +{
> >> + struct net_device *dev = queue->dev;
> >> + struct net *net = dev_net(dev);
> >> + unsigned long *mask, index;
> >> + int err;
> >> +
> >> + if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> >> + return -EPERM;
> >> +
> >> + mask = kcalloc(BITS_TO_LONGS(dev->num_rx_queues), sizeof(long),
> >> + GFP_KERNEL);
> >> + if (!mask)
> >> + return -ENOMEM;
> >> +
> >> + index = get_netdev_queue_index(queue);
> >> +
> >> + err = bitmap_parse(buf, len, mask, dev->num_rx_queues);
> >> + if (err) {
> >> + kfree(mask);
> >> + return err;
> >> + }
> >> +
> >> + err = __netif_set_xps_queue(dev, mask, index, true);
> >> + kfree(mask);
> >> + return err ? : len;
> >> +}
> >> +
> >> +static struct netdev_queue_attribute xps_rxqs_attribute __ro_after_init
> >> + = __ATTR_RW(xps_rxqs);
> >> #endif /* CONFIG_XPS */
> >>
> >> static struct attribute *netdev_queue_default_attrs[] __ro_after_init = {
> >> @@ -1290,6 +1372,7 @@ static struct attribute *netdev_queue_default_attrs[] __ro_after_init = {
> >> &queue_traffic_class.attr,
> >> #ifdef CONFIG_XPS
> >> &xps_cpus_attribute.attr,
> >> + &xps_rxqs_attribute.attr,
> >> &queue_tx_maxrate.attr,
> >> #endif
> >> NULL
^ permalink raw reply
* Re: [PATCH v2 net-next 01/14] net: Clear skb->tstamp only on the forwarding path
From: Jesus Sanchez-Palencia @ 2018-07-18 18:19 UTC (permalink / raw)
To: Eric Dumazet, netdev
Cc: tglx, jan.altenberg, vinicius.gomes, kurt.kanzenbach, henrik,
richardcochran, ilias.apalodimas, ivan.khoronzhuk, mlichvar,
willemb, jhs, xiyou.wangcong, jiri, jeffrey.t.kirsher
In-Reply-To: <463024c6-e085-ea88-688b-b42df679876a@gmail.com>
Hi Eric,
On 07/16/2018 04:15 PM, Eric Dumazet wrote:
>
>
> On 07/16/2018 02:52 PM, Jesus Sanchez-Palencia wrote:
>> Hi Eric,
>>
>>
>>
>> On 07/13/2018 10:35 AM, Eric Dumazet wrote:
>>>
>>>
>>> On 07/03/2018 03:42 PM, Jesus Sanchez-Palencia wrote:
>>>> This is done in preparation for the upcoming time based transmission
>>>> patchset. Now that skb->tstamp will be used to hold packet's txtime,
>>>> we must ensure that it is being cleared when traversing namespaces.
>>>> Also, doing that from skb_scrub_packet() before the early return would
>>>> break our feature when tunnels are used.
>>>>
>>>> Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
>>>> ---
>>>> net/core/skbuff.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>>>> index 1357f36c8a5e..c4e24ac27464 100644
>>>> --- a/net/core/skbuff.c
>>>> +++ b/net/core/skbuff.c
>>>> @@ -4898,7 +4898,6 @@ EXPORT_SYMBOL(skb_try_coalesce);
>>>> */
>>>> void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>>>> {
>>>> - skb->tstamp = 0;
>>>> skb->pkt_type = PACKET_HOST;
>>>> skb->skb_iif = 0;
>>>> skb->ignore_df = 0;
>>>> @@ -4912,6 +4911,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>>>>
>>>> ipvs_reset(skb);
>>>> skb->mark = 0;
>>>> + skb->tstamp = 0;
>>>> }
>>>> EXPORT_SYMBOL_GPL(skb_scrub_packet);
>>>>
>>>>
>>>
>>>
>>>
>>> I believe we had some misunderstanding here.
>>>
>>> What I meant by forwarding is the following case :
>>>
>>> - We receive a packet.
>>> - netstamp_wanted is >0 (because at least one packet capture is active)
>>> - __net_timestamp() is called and does :
>>> skb->tstamp = ktime_get_real();
>>>
>>> Then this skb is forwarded into an interface where EDT is taken into
>>> consideration by either a qdisc or a device.
>>>
>>> Since CLOCK_TAI is a different base than CLOCK_REALTIME, we might have a problem.
>>
>>
>> I'm not sure we have a problem here. For the Tx path I only see
>> net_timestamp_set() being called from dev_queue_xmit_nit(). And even there, it's
>> a clone of the skb that gets timestamped.
>>
>> I believe the original skb, which had the valid txtime copied into skb->tstamp,
>> is not modified anywhere along that path.
>>
>> What am I missing, please?
>>
>> Thanks,
>> Jesus
>>
>
>
> I am simply stating that a linux router, receiving packet on ethX and forwarding
> them on ethY, could have a problem if ethY has a qdisc looking at skb->tstamp
> assuming a timestamp in CLOCK_TAI base.
>
> In this case, skb->tstamp would have been set at ingress (not using CLOCK_TAI
> but CLOCK_REALTIME), and would be read at egress (assuming CLOCK_TAI)
>
> Normal IPV4 routing path would be in net/ipv4/ip_forward.c, no scrubbing ever happens,
> and no cloning either.
>
> Your patch (Clear skb->tstamp only on the forwarding path) is not handling the
> typical forward path, only the cases where 'scrubbing' is used.
Thanks for the clarification, I wasn't following you before.
I believe we're fine with what we have *today*, because the qdisc will drop skbs
that don't have a valid skb->sk, or if the SO_TXTIME flags is not set.
This is a problem, however, if another qdisc is developed tomorrow and uses the
same information but do not perform the same checks. Or, if the packet somehow
gets to the controller and the HW has the "launch time" feature enabled and the
driver uses the tstamp information the same way we do.
If we want to protect from that now, I think we should go with the most
immediate solution and clear skb->tstamp somewhere in ip_forward(), as you've
pointed before. It seems to me this wouldn't break any other feature that might
be re-using the tstamp information.
This is also a more correct fix for the problem you raised before:
>>> - We receive a packet.
>>> - netstamp_wanted is >0 (because at least one packet capture is active)
>>> - __net_timestamp() is called and does :
>>> skb->tstamp = ktime_get_real();
>>>
>>> Then this skb is forwarded into an interface where EDT is taken into
>>> consideration by either a qdisc or a device.
IMHO this Rx tstamp should never be forwarded to the Tx path as a valid txtime,
regardless if the time base used was UTC or TAI.
What do you think?
Jesus
>
>
>
>>
>>
>>>
>>>
>>> Solutions for this problem :
>>>
>>> 1) Convert all our skb->tstamp usages to CLOCK_TAI base.
>>>
>>> or
>>>
>>> 2) clear skb->tstamp in forwarding paths, including the ones not scrubbing the packet.
>>>
>>> My preference is 1), even if it is a bit more work.
>>>
^ permalink raw reply
* Re: [PATCH net-next] net: rename ndo_setup_tc to ndo_setup_offload
From: Jakub Kicinski @ 2018-07-18 18:31 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, thomas.lendacky, f.fainelli, ariel.elior, michael.chan,
santosh, madalin.bucur, yisen.zhuang, salil.mehta,
jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, ganeshgr,
linux-net-drivers, peppe.cavallaro, alexandre.torgue, joabreu,
grygorii.strashko, andrew, vivien.didelot
In-Reply-To: <20180718161404.24198-1-pablo@netfilter.org>
On Wed, 18 Jul 2018 18:14:04 +0200, Pablo Neira Ayuso wrote:
> One of the recurring complaints is that we do not have, as a driver
> writer, a central location from which we would be fed offloading rules
> into a NIC. This was brought up again during Netconf'18 in Boston.
>
> This patch just renames ndo_setup_tc to ndo_setup_offload as a very
> early initial work to prepare for follow up patches that discuss/propose
> unified flow representation for the existing offload programming APIs:
> ethtool_rxnfc, cls_flower, cls_u32 and (probably, not yet upstream)
> conntrack.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* [PATCH] e1000: ethtool: check on netif_running() before calling e1000_up()
From: Bo Chen @ 2018-07-18 19:18 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: davem, netdev, linux-kernel, phenix1108, Bo Chen
When the device is not up, the call to 'e1000_up()' from the error handling path
of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer
dereference. The null-pointer dereference is triggered in function
'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'.
This bug was reported by COD, a tool for testing kernel module binaries I am
building. This bug was also detected by KFI from Dr. Kai Cong.
This patch fixes the bug by checking on 'netif_running()' before calling
'e1000_up()' in 'e1000_set_ringparam()'.
Signed-off-by: Bo Chen <chenbo@pdx.edu>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index bdb3f8e65ed4..c1e4e94f100f 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -644,7 +644,8 @@ static int e1000_set_ringparam(struct net_device *netdev,
err_alloc_rx:
kfree(txdr);
err_alloc_tx:
- e1000_up(adapter);
+ if (netif_running(adapter->netdev))
+ e1000_up(adapter);
err_setup:
clear_bit(__E1000_RESETTING, &adapter->flags);
return err;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 01/14] net: Clear skb->tstamp only on the forwarding path
From: Dave Taht @ 2018-07-18 18:40 UTC (permalink / raw)
To: jesus.sanchez-palencia
Cc: Eric Dumazet, Linux Kernel Network Developers, tglx,
jan.altenberg, vinicius.gomes, kurt.kanzenbach, henrik,
richardcochran, ilias.apalodimas, ivan.khoronzhuk, mlichvar,
willemb, Jamal Hadi Salim, Cong Wang, Jiří Pírko,
Jeff Kirsher
In-Reply-To: <7d8db0f2-7a88-f42a-b3df-dcdd30155cbe@intel.com>
In my dreamworld, a packet with a timestamp achieved at rx time on
ethX, or via local traffic, would be consistent with the right clock
throughout the system and reliably still be there when it goes to
ethY.
This would save having to timestamp (again) inside the cb block in
fq_codel, cake, etc, and more importantly, measure total system delay
from entrance to egress, (e.g tc filters, firewall rules, routing
table lookups), not just queuing delay at the qdisc, thus detecting
when a system was overloaded and reducing queue size and throughput
appropriately as a result to cope.
^ permalink raw reply
* [PATCH] e1000: ethtool: ensure to free old tx/rx rings in set_ringparam()
From: Bo Chen @ 2018-07-18 19:24 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: davem, netdev, linux-kernel, Bo Chen
In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value
and the old tx/rx rings are freed only when the device is up. There are resource
leaks on old tx/rx rings when the device is not up. This bug is reported by COD,
a tool for testing kernel module binaries I am building.
This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in
'e1000_set_ringparam()'.
Signed-off-by: Bo Chen <chenbo@pdx.edu>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index bdb3f8e65ed4..27b006b60f8b 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -624,14 +624,14 @@ static int e1000_set_ringparam(struct net_device *netdev,
adapter->tx_ring = tx_old;
e1000_free_all_rx_resources(adapter);
e1000_free_all_tx_resources(adapter);
- kfree(tx_old);
- kfree(rx_old);
adapter->rx_ring = rxdr;
adapter->tx_ring = txdr;
err = e1000_up(adapter);
if (err)
goto err_setup;
}
+ kfree(tx_old);
+ kfree(rx_old);
clear_bit(__E1000_RESETTING, &adapter->flags);
return 0;
--
2.17.0
^ permalink raw reply related
* Re: [net-next, v6, 6/7] net-sysfs: Add interface for Rx queue(s) map per Tx queue
From: Stephen Hemminger @ 2018-07-18 19:24 UTC (permalink / raw)
To: Andrei Vagin
Cc: Nambiar, Amritha, Ingo Molnar, Peter Zijlstra, netdev, davem,
alexander.h.duyck, willemdebruijn.kernel, sridhar.samudrala,
alexander.duyck, edumazet, hannes, tom, tom, jasowang, gaowanlong
In-Reply-To: <20180718182235.GA28548@outlook.office365.com>
On Wed, 18 Jul 2018 11:22:36 -0700
Andrei Vagin <avagin@virtuozzo.com> wrote:
> On Tue, Jul 10, 2018 at 07:28:49PM -0700, Nambiar, Amritha wrote:
> > On 7/4/2018 12:20 AM, Andrei Vagin wrote:
> > > Hello Amritha,
> > >
> > > I see a following warning on 4.18.0-rc3-next-20180703.
> > > It looks like a problem is in this series.
> > >
> > > [ 1.084722] ============================================
> > > [ 1.084797] WARNING: possible recursive locking detected
> > > [ 1.084872] 4.18.0-rc3-next-20180703+ #1 Not tainted
> > > [ 1.084949] --------------------------------------------
> > > [ 1.085024] swapper/0/1 is trying to acquire lock:
> > > [ 1.085100] 00000000cf973d46 (cpu_hotplug_lock.rw_sem){++++}, at: static_key_slow_inc+0xe/0x20
> > > [ 1.085189]
> > > [ 1.085189] but task is already holding lock:
> > > [ 1.085271] 00000000cf973d46 (cpu_hotplug_lock.rw_sem){++++}, at: init_vqs+0x513/0x5a0
> > > [ 1.085357]
> > > [ 1.085357] other info that might help us debug this:
> > > [ 1.085450] Possible unsafe locking scenario:
> > > [ 1.085450]
> > > [ 1.085531] CPU0
> > > [ 1.085605] ----
> > > [ 1.085679] lock(cpu_hotplug_lock.rw_sem);
> > > [ 1.085753] lock(cpu_hotplug_lock.rw_sem);
> > > [ 1.085828]
> > > [ 1.085828] *** DEADLOCK ***
> > > [ 1.085828]
> > > [ 1.085916] May be due to missing lock nesting notation
> > > [ 1.085916]
> > > [ 1.085998] 3 locks held by swapper/0/1:
> > > [ 1.086074] #0: 00000000244bc7da (&dev->mutex){....}, at: __driver_attach+0x5a/0x110
> > > [ 1.086164] #1: 00000000cf973d46 (cpu_hotplug_lock.rw_sem){++++}, at: init_vqs+0x513/0x5a0
> > > [ 1.086248] #2: 000000005cd8463f (xps_map_mutex){+.+.}, at: __netif_set_xps_queue+0x8d/0xc60
> > > [ 1.086336]
> > > [ 1.086336] stack backtrace:
> > > [ 1.086419] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc3-next-20180703+ #1
> > > [ 1.086504] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > [ 1.086587] Call Trace:
> > > [ 1.086667] dump_stack+0x85/0xcb
> > > [ 1.086744] __lock_acquire+0x68a/0x1330
> > > [ 1.086821] ? lock_acquire+0x9f/0x200
> > > [ 1.086900] ? find_held_lock+0x2d/0x90
> > > [ 1.086976] ? lock_acquire+0x9f/0x200
> > > [ 1.087051] lock_acquire+0x9f/0x200
> > > [ 1.087126] ? static_key_slow_inc+0xe/0x20
> > > [ 1.087205] cpus_read_lock+0x3e/0x80
> > > [ 1.087280] ? static_key_slow_inc+0xe/0x20
> > > [ 1.087355] static_key_slow_inc+0xe/0x20
> > > [ 1.087435] __netif_set_xps_queue+0x216/0xc60
> > > [ 1.087512] virtnet_set_affinity+0xf0/0x130
> > > [ 1.087589] init_vqs+0x51b/0x5a0
> > > [ 1.087665] virtnet_probe+0x39f/0x870
> > > [ 1.087742] virtio_dev_probe+0x170/0x220
> > > [ 1.087819] driver_probe_device+0x30b/0x480
> > > [ 1.087897] ? set_debug_rodata+0x11/0x11
> > > [ 1.087972] __driver_attach+0xe0/0x110
> > > [ 1.088064] ? driver_probe_device+0x480/0x480
> > > [ 1.088141] bus_for_each_dev+0x79/0xc0
> > > [ 1.088221] bus_add_driver+0x164/0x260
> > > [ 1.088302] ? veth_init+0x11/0x11
> > > [ 1.088379] driver_register+0x5b/0xe0
> > > [ 1.088402] ? veth_init+0x11/0x11
> > > [ 1.088402] virtio_net_driver_init+0x6d/0x90
> > > [ 1.088402] do_one_initcall+0x5d/0x34c
> > > [ 1.088402] ? set_debug_rodata+0x11/0x11
> > > [ 1.088402] ? rcu_read_lock_sched_held+0x6b/0x80
> > > [ 1.088402] kernel_init_freeable+0x1ea/0x27b
> > > [ 1.088402] ? rest_init+0xd0/0xd0
> > > [ 1.088402] kernel_init+0xa/0x110
> > > [ 1.088402] ret_from_fork+0x3a/0x50
> > > [ 1.094190] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
> > >
> > >
> > > https://travis-ci.org/avagin/linux/jobs/399867744
> > >
> >
> > With this patch series, I introduced static_key for XPS maps
> > (xps_needed), so static_key_slow_inc() is used to switch branches. The
> > definition of static_key_slow_inc() has cpus_read_lock in place. In the
> > virtio_net driver, XPS queues are initialized after setting the
> > queue:cpu affinity in virtnet_set_affinity() which is already protected
> > within cpus_read_lock. Hence, the warning here trying to acquire
> > cpus_read_lock when it is already held.
> >
> > A quick fix for this would be to just extract netif_set_xps_queue() out
> > of the lock by simply wrapping it with another put/get_online_cpus
> > (unlock right before and hold lock right after). But this may not a
> > clean solution. It'd help if I can get suggestions on what would be a
> > clean option to fix this without extensively changing the code in
> > virtio_net. Is it mandatory to protect the affinitization with
> > read_lock? I don't see similar lock in other drivers while setting the
> > affinity.
>
> > I understand this warning should go away, but isn't it safe to
> > have multiple readers.
>
> Peter and Ingo, maybe you could explain why it isn't safe to take one
> reader lock twice?
>
> Thanks,
> Andrei
I think the issue was that some architectures, I think read lock is equivalent to a spin lock.
But maybe that is no longer true, or know one remembers.
^ permalink raw reply
* RE: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Steve Wise @ 2018-07-18 19:29 UTC (permalink / raw)
To: 'Max Gurtovoy', 'Sagi Grimberg',
'Leon Romanovsky'
Cc: 'Doug Ledford', 'Jason Gunthorpe',
'RDMA mailing list', 'Saeed Mahameed',
'linux-netdev'
In-Reply-To: <9a4d8d50-19b0-fcaa-d4a3-6cfa2318a973@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 6432 bytes --]
>
> On 7/18/2018 2:38 PM, Sagi Grimberg wrote:
> >
> >>> IMO we must fulfil the user wish to connect to N queues and not reduce
> >>> it because of affinity overlaps. So in order to push Leon's patch we
> >>> must also fix the blk_mq_rdma_map_queues to do a best effort
> mapping
> >>> according the affinity and map the rest in naive way (in that way we
> >>> will *always* map all the queues).
> >>
> >> That is what I would expect also. For example, in my node, where
> >> there are
> >> 16 cpus, and 2 numa nodes, I observe much better nvmf IOPS
> performance by
> >> setting up my 16 driver completion event queues such that each is
> >> bound to a
> >> node-local cpu. So I end up with each nodel-local cpu having 2 queues
> >> bound
> >> to it. W/O adding support in iw_cxgb4 for ib_get_vector_affinity(),
> >> this
> >> works fine. I assumed adding ib_get_vector_affinity() would allow
> >> this to
> >> all "just work" by default, but I'm running into this connection failure
> >> issue.
> >>
> >> I don't understand exactly what the blk_mq layer is trying to do, but I
> >> assume it has ingress event queues and processing that it trying to align
> >> with the drivers ingress cq event handling, so everybody stays on the
> >> same
> >> cpu (or at least node). But something else is going on. Is there
> >> documentation on how this works somewhere?
> >
> > Does this (untested) patch help?
>
> I'm not sure (I'll test it tomorrow) because the issue is the unmapped
> queues and not the cpus.
> for example, if the affinity of q=6 and q=12 returned the same cpumask
> than q=6 will not be mapped and will fail to connect.
>
Attached is a patch that applies cleanly for me. It has problems if vectors have affinity to more than 1 cpu:
[ 2031.988881] iw_cxgb4: comp_vector 0, irq 203 mask 0xff00
[ 2031.994706] iw_cxgb4: comp_vector 1, irq 204 mask 0xff00
[ 2032.000348] iw_cxgb4: comp_vector 2, irq 205 mask 0xff00
[ 2032.005992] iw_cxgb4: comp_vector 3, irq 206 mask 0xff00
[ 2032.011629] iw_cxgb4: comp_vector 4, irq 207 mask 0xff00
[ 2032.017271] iw_cxgb4: comp_vector 5, irq 208 mask 0xff00
[ 2032.022901] iw_cxgb4: comp_vector 6, irq 209 mask 0xff00
[ 2032.028514] iw_cxgb4: comp_vector 7, irq 210 mask 0xff00
[ 2032.034110] iw_cxgb4: comp_vector 8, irq 211 mask 0xff00
[ 2032.039677] iw_cxgb4: comp_vector 9, irq 212 mask 0xff00
[ 2032.045244] iw_cxgb4: comp_vector 10, irq 213 mask 0xff00
[ 2032.050889] iw_cxgb4: comp_vector 11, irq 214 mask 0xff00
[ 2032.056531] iw_cxgb4: comp_vector 12, irq 215 mask 0xff00
[ 2032.062174] iw_cxgb4: comp_vector 13, irq 216 mask 0xff00
[ 2032.067817] iw_cxgb4: comp_vector 14, irq 217 mask 0xff00
[ 2032.073457] iw_cxgb4: comp_vector 15, irq 218 mask 0xff00
[ 2032.079102] blk_mq_rdma_map_queues: set->mq_map[0] queue 0 vector 0
[ 2032.085621] blk_mq_rdma_map_queues: set->mq_map[1] queue 1 vector 1
[ 2032.092139] blk_mq_rdma_map_queues: set->mq_map[2] queue 2 vector 2
[ 2032.098658] blk_mq_rdma_map_queues: set->mq_map[3] queue 3 vector 3
[ 2032.105177] blk_mq_rdma_map_queues: set->mq_map[4] queue 4 vector 4
[ 2032.111689] blk_mq_rdma_map_queues: set->mq_map[5] queue 5 vector 5
[ 2032.118208] blk_mq_rdma_map_queues: set->mq_map[6] queue 6 vector 6
[ 2032.124728] blk_mq_rdma_map_queues: set->mq_map[7] queue 7 vector 7
[ 2032.131246] blk_mq_rdma_map_queues: set->mq_map[8] queue 15 vector 15
[ 2032.137938] blk_mq_rdma_map_queues: set->mq_map[9] queue 15 vector 15
[ 2032.144629] blk_mq_rdma_map_queues: set->mq_map[10] queue 15 vector 15
[ 2032.151401] blk_mq_rdma_map_queues: set->mq_map[11] queue 15 vector 15
[ 2032.158172] blk_mq_rdma_map_queues: set->mq_map[12] queue 15 vector 15
[ 2032.164940] blk_mq_rdma_map_queues: set->mq_map[13] queue 15 vector 15
[ 2032.171709] blk_mq_rdma_map_queues: set->mq_map[14] queue 15 vector 15
[ 2032.178477] blk_mq_rdma_map_queues: set->mq_map[15] queue 15 vector 15
[ 2032.187409] nvme nvme0: Connect command failed, error wo/DNR bit: -16402
[ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18
But if I set all my vector affinities single cpus but only those in the same numa node, it now works:
[ 2311.884397] iw_cxgb4: comp_vector 0, irq 203 mask 0x100
[ 2311.890103] iw_cxgb4: comp_vector 1, irq 204 mask 0x200
[ 2311.895659] iw_cxgb4: comp_vector 2, irq 205 mask 0x400
[ 2311.901211] iw_cxgb4: comp_vector 3, irq 206 mask 0x800
[ 2311.906758] iw_cxgb4: comp_vector 4, irq 207 mask 0x1000
[ 2311.912390] iw_cxgb4: comp_vector 5, irq 208 mask 0x2000
[ 2311.918014] iw_cxgb4: comp_vector 6, irq 209 mask 0x4000
[ 2311.923627] iw_cxgb4: comp_vector 7, irq 210 mask 0x8000
[ 2311.929213] iw_cxgb4: comp_vector 8, irq 211 mask 0x100
[ 2311.934694] iw_cxgb4: comp_vector 9, irq 212 mask 0x200
[ 2311.940163] iw_cxgb4: comp_vector 10, irq 213 mask 0x400
[ 2311.945716] iw_cxgb4: comp_vector 11, irq 214 mask 0x800
[ 2311.951272] iw_cxgb4: comp_vector 12, irq 215 mask 0x1000
[ 2311.956914] iw_cxgb4: comp_vector 13, irq 216 mask 0x2000
[ 2311.962558] iw_cxgb4: comp_vector 14, irq 217 mask 0x4000
[ 2311.968201] iw_cxgb4: comp_vector 15, irq 218 mask 0x8000
[ 2311.973845] blk_mq_rdma_map_queues: set->mq_map[0] queue 0 vector 0
[ 2311.980367] blk_mq_rdma_map_queues: set->mq_map[1] queue 1 vector 1
[ 2311.986885] blk_mq_rdma_map_queues: set->mq_map[2] queue 2 vector 2
[ 2311.993402] blk_mq_rdma_map_queues: set->mq_map[3] queue 3 vector 3
[ 2311.999919] blk_mq_rdma_map_queues: set->mq_map[4] queue 4 vector 4
[ 2312.006436] blk_mq_rdma_map_queues: set->mq_map[5] queue 5 vector 5
[ 2312.012956] blk_mq_rdma_map_queues: set->mq_map[6] queue 6 vector 6
[ 2312.019473] blk_mq_rdma_map_queues: set->mq_map[7] queue 7 vector 7
[ 2312.025991] blk_mq_rdma_map_queues: set->mq_map[8] queue 8 vector 8
[ 2312.032511] blk_mq_rdma_map_queues: set->mq_map[9] queue 9 vector 9
[ 2312.039030] blk_mq_rdma_map_queues: set->mq_map[10] queue 10 vector 10
[ 2312.045801] blk_mq_rdma_map_queues: set->mq_map[11] queue 11 vector 11
[ 2312.052572] blk_mq_rdma_map_queues: set->mq_map[12] queue 12 vector 12
[ 2312.059341] blk_mq_rdma_map_queues: set->mq_map[13] queue 13 vector 13
[ 2312.066111] blk_mq_rdma_map_queues: set->mq_map[14] queue 14 vector 14
[ 2312.072879] blk_mq_rdma_map_queues: set->mq_map[15] queue 15 vector 15
[ 2312.081926] nvme nvme0: new ctrl: NQN "nvme-nullb0", addr 172.16.2.1:4420
[-- Attachment #2: sagi2.patch --]
[-- Type: application/octet-stream, Size: 3258 bytes --]
commit 5128aa16a366c78aaa7a96f3e5760f993e9edb3e
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Jul 18 06:53:32 2018 -0700
sagi's patch2
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 3eb169f15842..02b888ff3c10 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -30,29 +30,36 @@ static int get_first_sibling(unsigned int cpu)
return cpu;
}
-int blk_mq_map_queues(struct blk_mq_tag_set *set)
+void blk_mq_map_queue_to_cpu(struct blk_mq_tag_set *set, unsigned int cpu)
{
unsigned int *map = set->mq_map;
unsigned int nr_queues = set->nr_hw_queues;
- unsigned int cpu, first_sibling;
+ unsigned int first_sibling;
- for_each_possible_cpu(cpu) {
- /*
- * First do sequential mapping between CPUs and queues.
- * In case we still have CPUs to map, and we have some number of
- * threads per cores then map sibling threads to the same queue for
- * performace optimizations.
- */
- if (cpu < nr_queues) {
+ /*
+ * First do sequential mapping between CPUs and queues.
+ * In case we still have CPUs to map, and we have some number of
+ * threads per cores then map sibling threads to the same queue for
+ * performace optimizations.
+ */
+ if (cpu < nr_queues) {
+ map[cpu] = cpu_to_queue_index(nr_queues, cpu);
+ } else {
+ first_sibling = get_first_sibling(cpu);
+ if (first_sibling == cpu)
map[cpu] = cpu_to_queue_index(nr_queues, cpu);
- } else {
- first_sibling = get_first_sibling(cpu);
- if (first_sibling == cpu)
- map[cpu] = cpu_to_queue_index(nr_queues, cpu);
- else
- map[cpu] = map[first_sibling];
- }
+ else
+ map[cpu] = map[first_sibling];
}
+}
+EXPORT_SYMBOL_GPL(blk_mq_map_queue_to_cpu);
+
+int blk_mq_map_queues(struct blk_mq_tag_set *set)
+{
+ unsigned int cpu;
+
+ for_each_possible_cpu(cpu)
+ blk_mq_map_queue_to_cpu(set, cpu);
return 0;
}
diff --git a/block/blk-mq-rdma.c b/block/blk-mq-rdma.c
index 996167f1de18..27210105a882 100644
--- a/block/blk-mq-rdma.c
+++ b/block/blk-mq-rdma.c
@@ -35,6 +35,10 @@ int blk_mq_rdma_map_queues(struct blk_mq_tag_set *set,
const struct cpumask *mask;
unsigned int queue, cpu;
+ /* reset all to */
+ for_each_possible_cpu(cpu)
+ set->mq_map[cpu] = UINT_MAX;
+
for (queue = 0; queue < set->nr_hw_queues; queue++) {
mask = ib_get_vector_affinity(dev, first_vec + queue);
if (!mask)
@@ -44,6 +48,11 @@ int blk_mq_rdma_map_queues(struct blk_mq_tag_set *set,
set->mq_map[cpu] = queue;
}
+ for_each_possible_cpu(cpu) {
+ if (set->mq_map[cpu] == UINT_MAX)
+ blk_mq_map_queue_to_cpu(set, cpu);
+ }
+
return 0;
fallback:
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index e3147eb74222..19e83d93a1d4 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -283,6 +283,7 @@ int blk_mq_freeze_queue_wait_timeout(struct request_queue *q,
unsigned long timeout);
int blk_mq_map_queues(struct blk_mq_tag_set *set);
+void blk_mq_map_queue_to_cpu(struct blk_mq_tag_set *set, unsigned int cpu);
void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues);
void blk_mq_quiesce_queue_nowait(struct request_queue *q);
^ permalink raw reply related
* Re: [PATCH resend -next] lib/rhashtable: consider param->min_size when setting initial table size
From: David Miller @ 2018-07-18 20:28 UTC (permalink / raw)
To: dave; +Cc: herbert, akpm, tgraf, linux-kernel, dbueso, netdev
In-Reply-To: <20180716202613.u6f3l3adrgjvs4wk@linux-r8p5>
From: Davidlohr Bueso <dave@stgolabs.net>
Date: Mon, 16 Jul 2018 13:26:13 -0700
> rhashtable_init() currently does not take into account the user-passed
> min_size parameter unless param->nelem_hint is set as well. As such,
> the default size (number of buckets) will always be HASH_DEFAULT_SIZE
> even if the smallest allowed size is larger than that. Remediate this
> by unconditionally calling into rounded_hashtable_size() and handling
> things accordingly.
>
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
> Resending per Herbert's request with Cc to netdev.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] bonding: set default miimon value for non-arp modes if not set
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-07-18 19:51 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek,
David S . Miller, linux-netdev, stable
In-Reply-To: <20180718184936.16037-1-jarod@redhat.com>
On Wed, Jul 18, 2018 at 11:49 AM, Jarod Wilson <jarod@redhat.com> wrote:
> For some time now, if you load the bonding driver and configure bond
> parameters via sysfs using minimal config options, such as specifying
> nothing but the mode, relying on defaults for everything else, modes
> that cannot use arp monitoring (802.3ad, balance-tlb, balance-alb) all
> wind up with both arp_interval=0 (as it should be) and miimon=0, which
> means the miimon monitor thread never actually runs. This is particularly
> problematic for 802.3ad.
>
> For example, from an LNST recipe I've set up:
>
> $ modprobe bonding max_bonds=0"
> $ echo "+t_bond0" > /sys/class/net/bonding_masters"
> $ ip link set t_bond0 down"
> $ echo "802.3ad" > /sys/class/net/t_bond0/bonding/mode"
> $ ip link set ens1f1 down"
> $ echo "+ens1f1" > /sys/class/net/t_bond0/bonding/slaves"
> $ ip link set ens1f0 down"
> $ echo "+ens1f0" > /sys/class/net/t_bond0/bonding/slaves"
> $ ethtool -i t_bond0"
> $ ip link set ens1f1 up"
> $ ip link set ens1f0 up"
> $ ip link set t_bond0 up"
> $ ip addr add 192.168.9.1/24 dev t_bond0"
> $ ip addr add 2002::1/64 dev t_bond0"
>
> This bond comes up okay, but things look slightly suspect in
> /proc/net/bonding/t_bond0 output:
>
> $ grep -i mii /proc/net/bonding/t_bond0
> MII Status: up
> MII Polling Interval (ms): 0
> MII Status: up
> MII Status: up
>
This doesn't seem correct since the MII interval set is 0. It should
set to 100 by default for this mode. This may be the side effect of
brining up the bond with default more (balance-rr) and then bringing
bond-down before configuring it. You can probably get away by just not
bringing down the bond (step 'set ip link bond0 down) in your recipe
above. But irrespective of that step, this mode needs miimon and
should have been set correctly.
> Now, pull a cable on one of the ports in the bond, then reconnect it, and
> you'll see:
>
> Slave Interface: ens1f0
> MII Status: down
> Speed: 1000 Mbps
> Duplex: full
>
> I believe this became a major issue as of commit 4d2c0cda0744, which for
> 802.3ad bonds, sets slave->link = BOND_LINK_DOWN, with a comment about
> relying on link monitoring via miimon to set it correctly, but since the
> miimon work queue never runs, the link just stays marked down.
>
> If we simply tweak bond_option_mode_set() slightly, we can check for the
> non-arp modes having no miimon value set, and insert BOND_DEFAULT_MIIMON,
> which gets things back in full working order. This problem exists as far
> back as 4.14, and might be worth fixing in all stable trees since, though
> the work-around is to simply specify an miimon value yourself.
>
> Reported-by: Bob Ball <ball@umich.edu>
> CC: Jay Vosburgh <j.vosburgh@gmail.com>
> CC: Veaceslav Falico <vfalico@gmail.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Mahesh Bandewar <maheshb@google.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: netdev@vger.kernel.org
> CC: stable@vger.kernel.org
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
> ---
> drivers/net/bonding/bond_options.c | 23 ++++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
> index 98663c50ded0..4d5d01cb8141 100644
> --- a/drivers/net/bonding/bond_options.c
> +++ b/drivers/net/bonding/bond_options.c
> @@ -743,15 +743,20 @@ const struct bond_option *bond_opt_get(unsigned int option)
> static int bond_option_mode_set(struct bonding *bond,
> const struct bond_opt_value *newval)
> {
> - if (!bond_mode_uses_arp(newval->value) && bond->params.arp_interval) {
> - netdev_dbg(bond->dev, "%s mode is incompatible with arp monitoring, start mii monitoring\n",
> - newval->string);
> - /* disable arp monitoring */
> - bond->params.arp_interval = 0;
> - /* set miimon to default value */
> - bond->params.miimon = BOND_DEFAULT_MIIMON;
> - netdev_dbg(bond->dev, "Setting MII monitoring interval to %d\n",
> - bond->params.miimon);
> + if (!bond_mode_uses_arp(newval->value)) {
> + if (bond->params.arp_interval) {
> + netdev_dbg(bond->dev, "%s mode is incompatible with arp monitoring, start mii monitoring\n",
> + newval->string);
> + /* disable arp monitoring */
> + bond->params.arp_interval = 0;
> + }
> +
> + if (!bond->params.miimon) {
> + /* set miimon to default value */
> + bond->params.miimon = BOND_DEFAULT_MIIMON;
> + netdev_dbg(bond->dev, "Setting MII monitoring interval to %d\n",
> + bond->params.miimon);
> + }
> }
>
> if (newval->value == BOND_MODE_ALB)
> --
> 2.16.1
>
^ permalink raw reply
* Re: [PATCH] net: cxgb3_main: fix potential Spectre v1
From: David Miller @ 2018-07-18 20:31 UTC (permalink / raw)
To: gustavo; +Cc: santosh, netdev, linux-kernel
In-Reply-To: <20180717015958.GA19236@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 16 Jul 2018 20:59:58 -0500
> t.qset_idx can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2286 cxgb_extension_ioctl()
> warn: potential spectre issue 'adapter->msix_info'
>
> Fix this by sanitizing t.qset_idx before using it to index
> adapter->msix_info
>
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Remove VLA usage
From: David Miller @ 2018-07-18 20:33 UTC (permalink / raw)
To: keescook
Cc: netdev, linux-kernel, s.mesoraca16, f.fainelli, andrew,
David.Laight
In-Reply-To: <20180717041034.GA37382@beast>
From: Kees Cook <keescook@chromium.org>
Date: Mon, 16 Jul 2018 21:10:34 -0700
> From: Salvatore Mesoraca <s.mesoraca16@gmail.com>
>
> We avoid 2 VLAs by using a pre-allocated field in dsa_switch. We also
> try to avoid dynamic allocation whenever possible (when using fewer than
> bits-per-long ports, which is the common case).
>
> Link: http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
> Link: http://lkml.kernel.org/r/20180505185145.GB32630@lunn.ch
> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
> [kees: tweak commit subject and message slightly]
> Signed-off-by: Kees Cook <keescook@chromium.org>
Florian and Andrew, please review.
^ permalink raw reply
* [PATCH next v2] bonding: pass link-local packets to bonding master also.
From: Mahesh Bandewar @ 2018-07-18 19:55 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, Veaceslav Falico, David Miller
Cc: Netdev, Michal Soltys, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Commit b89f04c61efe ("bonding: deliver link-local packets with
skb->dev set to link that packets arrived on") changed the behavior
of how link-local-multicast packets are processed. The change in
the behavior broke some legacy use cases where these packets are
expected to arrive on bonding master device also.
This patch passes the packet to the stack with the link it arrived
on as well as passes to the bonding-master device to preserve the
legacy use case.
Fixes: b89f04c61efe ("bonding: deliver link-local packets with skb->dev set to link that packets arrived on")
Reported-by: Michal Soltys <soltys@ziu.info>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
v2: Added Fixes tag.
v1: Initial patch.
drivers/net/bonding/bond_main.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 9a2ea3c1f949..1d3b7d8448f2 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1177,9 +1177,22 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
}
}
- /* don't change skb->dev for link-local packets */
- if (is_link_local_ether_addr(eth_hdr(skb)->h_dest))
+ /* Link-local multicast packets should be passed to the
+ * stack on the link they arrive as well as pass them to the
+ * bond-master device. These packets are mostly usable when
+ * stack receives it with the link on which they arrive
+ * (e.g. LLDP) but there may be some legacy behavior that
+ * expects these packets to appear on bonding master too.
+ */
+ if (is_link_local_ether_addr(eth_hdr(skb)->h_dest)) {
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+
+ if (nskb) {
+ nskb->dev = bond->dev;
+ netif_rx(nskb);
+ }
return RX_HANDLER_PASS;
+ }
if (bond_should_deliver_exact_match(skb, slave, bond))
return RX_HANDLER_EXACT;
--
2.18.0.203.gfac676dfb9-goog
^ permalink raw reply related
* Re: [PATCH v2] net: dsa: Remove VLA usage
From: Andrew Lunn @ 2018-07-18 20:37 UTC (permalink / raw)
To: David Miller
Cc: keescook, netdev, linux-kernel, s.mesoraca16, f.fainelli,
David.Laight
In-Reply-To: <20180719.053333.396851874410198344.davem@davemloft.net>
On Thu, Jul 19, 2018 at 05:33:33AM +0900, David Miller wrote:
> From: Kees Cook <keescook@chromium.org>
> Date: Mon, 16 Jul 2018 21:10:34 -0700
>
> > From: Salvatore Mesoraca <s.mesoraca16@gmail.com>
> >
> > We avoid 2 VLAs by using a pre-allocated field in dsa_switch. We also
> > try to avoid dynamic allocation whenever possible (when using fewer than
> > bits-per-long ports, which is the common case).
> >
> > Link: http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
> > Link: http://lkml.kernel.org/r/20180505185145.GB32630@lunn.ch
> > Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
> > [kees: tweak commit subject and message slightly]
> > Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Florian and Andrew, please review.
Last time there was some discussion of just always allocating it to
make the code simpler. But the extra complexity is O.K.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5: fix an unused-function warning
From: David Miller @ 2018-07-18 20:39 UTC (permalink / raw)
To: saeedm; +Cc: arnd, saeedm, leon, ilyal, borisp, netdev, linux-rdma,
linux-kernel
In-Reply-To: <CALzJLG_r5pkBWGvyE+e7PVtPOnLnXS8oee_ka+=UEAkbqDP-Kg@mail.gmail.com>
From: Saeed Mahameed <saeedm@dev.mellanox.co.il>
Date: Tue, 17 Jul 2018 17:42:25 -0700
> On Tue, Jul 17, 2018 at 6:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> These dummy helpers are all intended to be inline functions,
>> but one of them by accident came without the 'inline' keyword,
>> causing a harmless warning:
>>
>> In file included from drivers/net/ethernet/mellanox/mlx5/core/main.c:63:
>> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h:79:1: error: 'mlx5_accel_tls_add_flow' defined but not used [-Werror=unused-function]
>> mlx5_accel_tls_add_flow(struct mlx5_core_dev *mdev, void *flow,
>>
>> Fixes: ab412e1dd7db ("net/mlx5: Accel, add TLS rx offload routines")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Dave, you can take this one to net-next.
Sure, done.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: Using NULL instead of plain integer
From: David Miller @ 2018-07-18 20:41 UTC (permalink / raw)
To: yuehaibing
Cc: derek.chickles, satananda.burla, linux-kernel, netdev,
felix.manlunas, raghu.vatsavayi
In-Reply-To: <20180717092713.7752-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 17 Jul 2018 17:27:13 +0800
> Fixes the following sparse warnings:
>
> drivers/net/ethernet/cavium/liquidio/lio_main.c:3068:23: warning:
> Using plain integer as NULL pointer
> drivers/net/ethernet/cavium/liquidio/lio_main.c:2909:23: warning:
> Using plain integer as NULL pointer
> drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c:385:27: warning:
> Using plain integer as NULL pointer
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* RE: [PATCH v2 net-next 9/9] lan743x: Add PTP support
From: Bryan.Whitehead @ 2018-07-18 20:04 UTC (permalink / raw)
To: richardcochran; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <20180713033135.dfatbghlpeswm7g6@localhost>
Hi Richard,
Thank you for your detailed feedback. I'm working on it now, but I feel it will take a little extra time to complete. Therefor I'm planning to remove PTP support from this patch series, and resubmit it in a new patch later.
I also have a few questions below.
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Thursday, July 12, 2018 11:32 PM
> To: Bryan Whitehead - C21958 <Bryan.Whitehead@microchip.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; UNGLinuxDriver
> <UNGLinuxDriver@microchip.com>
> Subject: Re: [PATCH v2 net-next 9/9] lan743x: Add PTP support
>
...
> > + if (cleanup) {
> > + lan743x_ptp_unrequest_tx_timestamp(tx->adapter);
> > + dev_kfree_skb(buffer_info->skb);
> > + } else {
> > + lan743x_ptp_tx_timestamp_skb(tx->adapter,
> > + buffer_info->skb,
> > + (buffer_info->flags &
> > +
> TX_BUFFER_INFO_FLAG_IGNORE_SYNC)
> > + != 0);
>
> This is poor coding style. Please find a better way.
Can you clarify what is poor and what would be better?
For example, should I change "X != 0" to "X ? true : false".
> > +#ifdef CONFIG_PTP_1588_CLOCK
> > +static int lan743x_ptp_enable_pps(struct lan743x_adapter *adapter) {
> > + struct lan743x_ptp *ptp = &adapter->ptp;
> > + u32 current_seconds = 0;
> > + u32 target_seconds = 0;
> > + u32 general_config = 0;
> > + int result = -ENODEV;
> > + int pps_bit = 0;
>
> So this function is really *not* implementing the PTP_CLK_REQ_PPS feature
> but rather the PTP_CLK_REQ_PEROUT with a period of once per second.
>
> PTP_CLK_REQ_PPS means placing a PPS event into the kernel's "hardpps"
> subsystem by calling ptp_clock_event().
>
> I'm sorry this isn't really documented. I should fix that.
>
> If you HW can output arbitrary signals, then you should implement
> PTP_CLK_REQ_PEROUT. In any case, you shouldn't advertise the
> ptp_clock_info.pps capability.
So you mean PPS is not intended to generate a physical signal?
It is only intended to call ptp_clock_event?
I can configure the hardware to generate an interrupt each second and then call
ptp_clock_event. Would that satisfy the pps requirements?
Regarding PTP_CLK_REQ_PEROUT. Is that intended for physical signals?
Thanks,
Bryan
^ permalink raw reply
* Re: [PATCH net-next] net: sched: Using NULL instead of plain integer
From: David Miller @ 2018-07-18 20:44 UTC (permalink / raw)
To: yuehaibing; +Cc: jhs, xiyou.wangcong, jiri, linux-kernel, netdev
In-Reply-To: <20180717125814.13792-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 17 Jul 2018 20:58:14 +0800
> Fixes the following sparse warnings:
>
> net/sched/cls_api.c:1101:43: warning: Using plain integer as NULL pointer
> net/sched/cls_api.c:1492:75: warning: Using plain integer as NULL pointer
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ 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