* Re: [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
From: Jiri Kosina @ 2019-09-11 11:42 UTC (permalink / raw)
To: Johannes Berg
Cc: Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
David S. Miller, netdev, linux-kernel
In-Reply-To: <01d55c5cf513554d9cbdee0b14f9360a8df859c8.camel@sipsolutions.net>
On Mon, 15 Apr 2019, Johannes Berg wrote:
> > If there are other reasons why disable BH for the whole function (are
> > there?), then this bigger hammer works as well of course.
>
> I thought there are, but seeing the commit log here I'm not sure.
>
> In any case, even if not, the function itself is part of the TX fast
> path, but the caller from the workqueue is very uncommon (basically only
> happens for a handful of packets on each new RA/TID), so I'd say that'd
> be a good reason to use the slightly bigger hammer (it's not that much
> different really, if you look at how much code is covered by the lock)
> and avoid doing it all the time when we know it to be not needed.
So this now popped up on me with current Linus' tree from a different
codepath, see below. Therefore I'd like to propose bringing my previous
patch back to life.
Thanks.
From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
iwl_mvm_sta->lock can be taken from BH, and therefore BH must be disabled if
taking it from other contexts.
This fixes the lockdep warning below.
================================
WARNING: inconsistent lock state
5.3.0-rc8 #3 Tainted: G W
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/u8:2/28401 [HC0[0]:SC0[0]:HE1:SE1] takes:
000000009c020e13 (&(&mvm_sta->lock)->rlock){+.?.}, at: iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0xbd/0x1e0
_raw_spin_lock+0x35/0x50
iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
iwl_mvm_tx_skb+0x1f8/0x460 [iwlmvm]
iwl_mvm_mac_itxq_xmit+0xcc/0x200 [iwlmvm]
ieee80211_queue_skb+0x290/0x4c0 [mac80211]
ieee80211_xmit_fast+0x814/0xa70 [mac80211]
__ieee80211_subif_start_xmit+0x132/0x380 [mac80211]
ieee80211_subif_start_xmit+0x49/0x370 [mac80211]
dev_hard_start_xmit+0xaf/0x340
__dev_queue_xmit+0x98d/0xd20
ip6_finish_output2+0x323/0x960
ip6_output+0x19d/0x2d0
mld_sendpack+0x361/0x3a0
mld_ifc_timer_expire+0x19f/0x2e0
call_timer_fn+0x97/0x300
run_timer_softirq+0x233/0x590
__do_softirq+0x12c/0x448
irq_exit+0xa5/0xb0
smp_apic_timer_interrupt+0xac/0x2a0
apic_timer_interrupt+0xf/0x20
cpuidle_enter_state+0xbf/0x450
cpuidle_enter+0x29/0x40
do_idle+0x1cc/0x290
cpu_startup_entry+0x19/0x20
start_secondary+0x15f/0x1a0
secondary_startup_64+0xa4/0xb0
[ ... snip ... ]
stack backtrace:
CPU: 1 PID: 28401 Comm: kworker/u8:2 Tainted: G W 5.3.0-rc8 #3
Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017
Workqueue: phy0 ieee80211_beacon_connection_loss_work [mac80211]
Call Trace:
dump_stack+0x78/0xb3
mark_lock+0x28a/0x2a0
__lock_acquire+0x568/0x1020
? iwl_mvm_set_tx_cmd+0x1c5/0x400 [iwlmvm]
lock_acquire+0xbd/0x1e0
? iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
_raw_spin_lock+0x35/0x50
? iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
? ieee80211_tx_h_select_key+0xf1/0x4a0 [mac80211]
iwl_mvm_tx_skb+0x1f8/0x460 [iwlmvm]
iwl_mvm_mac_itxq_xmit+0xcc/0x200 [iwlmvm]
? iwl_mvm_mac_itxq_xmit+0x55/0x200 [iwlmvm]
_ieee80211_wake_txqs+0x2cf/0x660 [mac80211]
? _ieee80211_wake_txqs+0x5/0x660 [mac80211]
? __ieee80211_wake_queue+0x219/0x340 [mac80211]
ieee80211_wake_queues_by_reason+0x64/0xa0 [mac80211]
ieee80211_set_disassoc+0x3b1/0x520 [mac80211]
__ieee80211_disconnect+0x81/0x110 [mac80211]
process_one_work+0x1f0/0x5b0
? process_one_work+0x16a/0x5b0
worker_thread+0x4c/0x3f0
kthread+0x103/0x140
? process_one_work+0x5b0/0x5b0
? kthread_bind+0x10/0x10
ret_from_fork+0x3a/0x50
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 6ac114a393cc..bcfb290beaaf 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -1106,7 +1106,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
*/
info->flags &= ~IEEE80211_TX_STATUS_EOSP;
- spin_lock(&mvmsta->lock);
+ spin_lock_bh(&mvmsta->lock);
/* nullfunc frames should go to the MGMT queue regardless of QOS,
* the condition of !ieee80211_is_qos_nullfunc(fc) keeps the default
@@ -1145,7 +1145,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
if (WARN_ONCE(txq_id == IWL_MVM_INVALID_QUEUE, "Invalid TXQ id")) {
iwl_trans_free_tx_cmd(mvm->trans, dev_cmd);
- spin_unlock(&mvmsta->lock);
+ spin_unlock_bh(&mvmsta->lock);
return 0;
}
@@ -1181,7 +1181,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
if (tid < IWL_MAX_TID_COUNT && !ieee80211_has_morefrags(fc))
mvmsta->tid_data[tid].seq_number = seq_number + 0x10;
- spin_unlock(&mvmsta->lock);
+ spin_unlock_bh(&mvmsta->lock);
if (iwl_mvm_tx_pkt_queued(mvm, mvmsta,
tid == IWL_MAX_TID_COUNT ? 0 : tid))
@@ -1191,7 +1191,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
drop_unlock_sta:
iwl_trans_free_tx_cmd(mvm->trans, dev_cmd);
- spin_unlock(&mvmsta->lock);
+ spin_unlock_bh(&mvmsta->lock);
drop:
IWL_DEBUG_TX(mvm, "TX to [%d|%d] dropped\n", mvmsta->sta_id, tid);
return -1;
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH 1/7] net/dsa: configure autoneg for CPU port
From: kbuild test robot @ 2019-09-11 11:43 UTC (permalink / raw)
To: Robert Beckett
Cc: kbuild-all, netdev, Robert Beckett, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller
In-Reply-To: <20190910154238.9155-2-bob.beckett@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]
Hi Robert,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc8 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Robert-Beckett/net-dsa-mv88e6xxx-features-to-handle-network-storms/20190911-142233
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
net//dsa/port.c: In function 'dsa_port_setup_phy_of':
>> net//dsa/port.c:541:41: error: invalid operands to binary | (have 'long unsigned int *' and 'long unsigned int')
phydev->supported = PHY_GBIT_FEATURES | SUPPORTED_MII |
^
>> net//dsa/port.c:545:23: error: assignment to expression with array type
phydev->advertising = phydev->supported;
^
vim +541 net//dsa/port.c
525
526 static int dsa_port_setup_phy_of(struct dsa_port *dp, bool enable)
527 {
528 struct dsa_switch *ds = dp->ds;
529 struct phy_device *phydev;
530 int port = dp->index;
531 int err = 0;
532
533 phydev = dsa_port_get_phy_device(dp);
534 if (!phydev)
535 return 0;
536
537 if (IS_ERR(phydev))
538 return PTR_ERR(phydev);
539
540 if (enable) {
> 541 phydev->supported = PHY_GBIT_FEATURES | SUPPORTED_MII |
542 SUPPORTED_AUI | SUPPORTED_FIBRE |
543 SUPPORTED_BNC | SUPPORTED_Pause |
544 SUPPORTED_Asym_Pause;
> 545 phydev->advertising = phydev->supported;
546
547 err = genphy_config_init(phydev);
548 if (err < 0)
549 goto err_put_dev;
550
551 err = genphy_config_aneg(phydev);
552 if (err < 0)
553 goto err_put_dev;
554
555 err = genphy_resume(phydev);
556 if (err < 0)
557 goto err_put_dev;
558
559 err = genphy_read_status(phydev);
560 if (err < 0)
561 goto err_put_dev;
562 } else {
563 err = genphy_suspend(phydev);
564 if (err < 0)
565 goto err_put_dev;
566 }
567
568 if (ds->ops->adjust_link)
569 ds->ops->adjust_link(ds, port, phydev);
570
571 dev_dbg(ds->dev, "enabled port's phy: %s", phydev_name(phydev));
572
573 err_put_dev:
574 put_device(&phydev->mdio.dev);
575 return err;
576 }
577
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61484 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Don't use dst gateway directly in ip6_confirm_neigh()
From: Nicolas Dichtel @ 2019-09-11 11:47 UTC (permalink / raw)
To: Stefano Brivio, David Miller
Cc: Guillaume Nault, Julian Anastasov, David Ahern, netdev
In-Reply-To: <938b711c35ce3fa2b6f057cc23919e897a1e5c2b.1568061608.git.sbrivio@redhat.com>
Le 09/09/2019 à 22:44, Stefano Brivio a écrit :
> This is the equivalent of commit 2c6b55f45d53 ("ipv6: fix neighbour
> resolution with raw socket") for ip6_confirm_neigh(): we can send a
> packet with MSG_CONFIRM on a raw socket for a connected route, so the
> gateway would be :: here, and we should pick the next hop using
> rt6_nexthop() instead.
>
> This was found by code review and, to the best of my knowledge, doesn't
> actually fix a practical issue: the destination address from the packet
> is not considered while confirming a neighbour, as ip6_confirm_neigh()
> calls choose_neigh_daddr() without passing the packet, so there are no
> similar issues as the one fixed by said commit.
>
> A possible source of issues with the existing implementation might come
> from the fact that, if we have a cached dst, we won't consider it,
> while rt6_nexthop() takes care of that. I might just not be creative
> enough to find a practical problem here: the only way to affect this
> with cached routes is to have one coming from an ICMPv6 redirect, but
> if the next hop is a directly connected host, there should be no
> topology for which a redirect applies here, and tests with redirected
> routes show no differences for MSG_CONFIRM (and MSG_PROBE) packets on
> raw sockets destined to a directly connected host.
>
> However, directly using the dst gateway here is not consistent anymore
> with neighbour resolution, and, in general, as we want the next hop,
> using rt6_nexthop() looks like the only sane way to fetch it.
>
> Reported-by: Guillaume Nault <gnault@redhat.com>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH 0/7] net: dsa: mv88e6xxx: features to handle network storms
From: Robert Beckett @ 2019-09-11 11:49 UTC (permalink / raw)
To: Ido Schimmel, Florian Fainelli
Cc: netdev@vger.kernel.org, Andrew Lunn, Vivien Didelot,
David S. Miller, Jiri Pirko, bob.beckett
In-Reply-To: <20190911112134.GA20574@splinter>
On Wed, 2019-09-11 at 11:21 +0000, Ido Schimmel wrote:
> On Tue, Sep 10, 2019 at 09:49:46AM -0700, Florian Fainelli wrote:
> > +Ido, Jiri,
> >
> > On 9/10/19 8:41 AM, Robert Beckett wrote:
> > > This patch-set adds support for some features of the Marvell
> > > switch
> > > chips that can be used to handle packet storms.
> > >
> > > The rationale for this was a setup that requires the ability to
> > > receive
> > > traffic from one port, while a packet storm is occuring on
> > > another port
> > > (via an external switch with a deliberate loop). This is needed
> > > to
> > > ensure vital data delivery from a specific port, while mitigating
> > > any
> > > loops or DoS that a user may introduce on another port (can't
> > > guarantee
> > > sensible users).
> >
> > The use case is reasonable, but the implementation is not really.
> > You
> > are using Device Tree which is meant to describe hardware as a
> > policy
> > holder for setting up queue priorities and likewise for queue
> > scheduling.
> >
> > The tool that should be used for that purpose is tc and possibly an
> > appropriately offloaded queue scheduler in order to map the desired
> > scheduling class to what the hardware supports.
> >
> > Jiri, Ido, how do you guys support this with mlxsw?
>
> Hi Florian,
>
> Are you referring to policing traffic towards the CPU using a policer
> on
> the egress of the CPU port? At least that's what I understand from
> the
> description of patch 6 below.
>
> If so, mlxsw sets policers for different traffic types during its
> initialization sequence. These policers are not exposed to the user
> nor
> configurable. While the default settings are good for most users, we
> do
> want to allow users to change these and expose current settings.
>
> I agree that tc seems like the right choice, but the question is
> where
> are we going to install the filters?
>
Before I go too far down the rabbit hole of tc traffic shaping, maybe
it would be good to explain in more detail the problem I am trying to
solve.
We have a setup as follows:
Marvell 88E6240 switch chip, accepting traffic from 4 ports. Port 1
(P1) is critical priority, no dropped packets allowed, all others can
be best effort.
CPU port of swtich chip is connected via phy to phy of intel i210 (igb
driver).
i210 is connected via pcie switch to imx6.
When too many small packets attempt to be delivered to CPU port (e.g.
during broadcast flood) we saw dropped packets.
The packets were being received by i210 in to rx descriptor buffer
fine, but the CPU could not keep up with the load. We saw
rx_fifo_errors increasing rapidly and ksoftirqd at ~100% CPU.
With this in mind, I am wondering whether any amount of tc traffic
shaping would help? Would tc shaping require that the packet reception
manages to keep up before it can enact its policies? Does the
infrastructure have accelerator offload hooks to be able to apply it
via HW? I dont see how it would be able to inspect the packets to apply
filtering if they were dropped due to rx descriptor exhaustion. (please
bear with me with the basic questions, I am not familiar with this part
of the stack).
Assuming that tc is still the way to go, after a brief look in to the
man pages and the documentation at largc.org, it seems like it would
need to use the ingress qdisc, with some sort of system to segregate
and priortise based on ingress port. Is this possible?
> >
> > >
> > > [patch 1/7] configures auto negotiation for CPU ports connected
> > > with
> > > phys to enable pause frame propogation.
> > >
> > > [patch 2/7] allows setting of port's default output queue
> > > priority for
> > > any ingressing packets on that port.
> > >
> > > [patch 3/7] dt-bindings for patch 2.
> > >
> > > [patch 4/7] allows setting of a port's queue scheduling so that
> > > it can
> > > prioritise egress of traffic routed from high priority ports.
> > >
> > > [patch 5/7] dt-bindings for patch 4.
> > >
> > > [patch 6/7] allows ports to rate limit their egress. This can be
> > > used to
> > > stop the host CPU from becoming swamped by packet delivery and
> > > exhasting
> > > descriptors.
> > >
> > > [patch 7/7] dt-bindings for patch 6.
> > >
> > >
> > > Robert Beckett (7):
> > > net/dsa: configure autoneg for CPU port
> > > net: dsa: mv88e6xxx: add ability to set default queue
> > > priorities per
> > > port
> > > dt-bindings: mv88e6xxx: add ability to set default queue
> > > priorities
> > > per port
> > > net: dsa: mv88e6xxx: add ability to set queue scheduling
> > > dt-bindings: mv88e6xxx: add ability to set queue scheduling
> > > net: dsa: mv88e6xxx: add egress rate limiting
> > > dt-bindings: mv88e6xxx: add egress rate limiting
> > >
> > > .../devicetree/bindings/net/dsa/marvell.txt | 38 +++++
> > > drivers/net/dsa/mv88e6xxx/chip.c | 122
> > > ++++++++++++---
> > > drivers/net/dsa/mv88e6xxx/chip.h | 5 +-
> > > drivers/net/dsa/mv88e6xxx/port.c | 140
> > > +++++++++++++++++-
> > > drivers/net/dsa/mv88e6xxx/port.h | 24 ++-
> > > include/dt-bindings/net/dsa-mv88e6xxx.h | 22 +++
> > > net/dsa/port.c | 10 ++
> > > 7 files changed, 327 insertions(+), 34 deletions(-)
> > > create mode 100644 include/dt-bindings/net/dsa-mv88e6xxx.h
> > >
> >
> >
> > --
> > Florian
^ permalink raw reply
* Re: [PATCH v1 net-next 00/15] tc-taprio offload for SJA1105 DSA
From: Vladimir Oltean @ 2019-09-11 11:51 UTC (permalink / raw)
To: Gomes, Vinicius
Cc: David Miller, f.fainelli@gmail.com, vivien.didelot@gmail.com,
andrew@lunn.ch, Patel, Vedang, richardcochran@gmail.com,
Voon, Weifeng, jiri@mellanox.com, m-karicheri2@ti.com,
Jose.Abreu@synopsys.com, ilias.apalodimas@linaro.org,
jhs@mojatatu.com, xiyou.wangcong@gmail.com,
kurt.kanzenbach@linutronix.de, netdev@vger.kernel.org
In-Reply-To: <BN6PR11MB0050D9E694A143CBBAA24E2986B10@BN6PR11MB0050.namprd11.prod.outlook.com>
Hi Vinicius,
On 11/09/2019, Gomes, Vinicius <vinicius.gomes@intel.com> wrote:
> Hi Vladimir,
>
> [...]
>
>>
>> I'll make sure this subtlety is more clearly formulated in the next
>> version of the
>> patch.
>>
>
> Ack.
>
>> Actually let me ask you a few questions as well:
>>
>> - I'm trying to understand what is the correct use of the tc-mqprio
>> "queues"
>> argument. I've only tested it with "1@0 1@1 1@2 1@3 1@4 1@5
>> 1@6 1@7", which I believe is equivalent to not specifying it at all? I
>> believe it
>> should be interpreted as: "allocate this many netdev queues for each
>> traffic
>> class", where "traffic class" means a group of queues having the same
>> priority
>> (equal to the traffic class's number), but engaged in a strict priority
>> scheme with
>> other groups of queues (traffic classes). Right?
>
> Specifying the "queues" is mandatory, IIRC. Yeah, your reading of those
> arguments
> for you example matches mine.
>
> So you mean, that you only tested situations when only one queue is "open"
> at a time?
> I think this is another good thing to test.
>
No, I tested (using the "gatemask" shell function I wrote as a wrapper
for the SetGateStates command in tc-taprio) a schedule comprised of:
gatemask 7 # PTP
gatemask 5 # My scheduled traffic with clock_nanosleep()
gatemask "0 1 2 3 4 6" # Everything else
>>
>> - DSA can only formally support multi-queue, because its connection to the
>> Linux
>> host is through an Ethernet MAC (FIFO). Even if the DSA master netdevice
>> may
>> be multi-queue, allocating and separating those queues for each
>> front-panel
>> switch port is a task best left to the user/administrator. This means that
>> DSA
>> should reject all other "queues" mappings except the trivial one I pointed
>> to
>> above?
>>
>> - I'm looking at the "tc_mask_to_queue_mask" function that I'm carrying
>> along
>> from your initial offload RFC. Are you sure this is the right approach? I
>> don't feel
>> a need to translate from traffic class to netdev queues, considering that
>> in the
>> general case, a traffic class is a group of queues, and 802.1Qbv doesn't
>> really
>> specify that you can gate individual queues from a traffic class. In the
>> software
>> implementation you are only looking at netdev_get_prio_tc_map, which is
>> not
>> equivalent as far as my understanding goes, but saner.
>> Actually 802.1Q-2018 does not really clarify this either. It looks to me
>> like they
>> use the term "queue" and "traffic class" interchangeably.
>> See two examples below (emphasis mine):
>
> I spent quite a long time thinking about this, still not sure that I got it
> right. Let me begin
> with the objective for that "translation". Scheduled traffic only makes
> sense when
> the whole network shares the same schedule, so, I wanted a way so I minimize
> the
> amount of information of each schedule that's controller dependent, Linux
> already
> does most of it with the separation of traffic classes and queues (you are
> right that
> 802.1Q is confusing on this), the idea is that the only thing that needs to
> change from
> one node to another in the network is the "queues" parameter. Because each
> node might
> have different number of queues, or assign different priorities to different
> queues.
>
> So, that's the idea of doing that intermediate "transformation" step: taprio
> knows about
> traffic classes and HW queues, but the driver only knows about HW queues.
Not necessarily, I think.
The "other" TSN-capable SoC I know of - the NXP LS1028A, has a
standalone Ethernet controller (drivers/net/ethernet/freescale/enetc)
and an embedded L2 switch (not upstream yet). The ENETC has a
configurable number of TX rings per port. Each TX ring has an
"internal priority value" (IPV) and there is an IPV-to-TC mapping
register. The enetc driver keeps the rings with equal priorities under
normal circumstances (and affines 1 TX ring per core) - the idea being
to spread the load. In ndo_setup_tc for mqprio, they allocate num_tc
TX rings and they put them in strict priority mode by configuring the
IPV (internally mapped 1-to-1 to TC) as increasing values for each
ring.
Then the TSN egress scheduler is wired to look at the traffic class of
each frame, via the TX ring is was enqueued on, mapped to the IPV,
mapped to the TC.
The embedded switch in LS1028A is mostly the same if I just consider
the egress portion.
And the sja1105 doesn't really make a distinction between egress
priority queue and traffic class. They are hardcoded 1-to-1 in the
egress port.
> And unless I made
> a mistake, tc_mask_to_queue_mask() should be equivalent to:
>
> netdev_get_prio_tc_map() + scanning the gatemask for BIT(tc).
>
Yes, but my point is: do you know of any hardware implementation that
schedules traffic per-queue (in a situation where the queue-to-tc
mapping is not 1-to-1)? I know of 3 that don't. So if you translate
traffic class into netdev queue, then these drivers would just need to
translate it back into traffic class for programming the full offload.
The hardware doesn't know anything about the netdev queues.
Or are you saying that the driver doesn't need to care (or may not
care) about the traffic class and you're trying to make their life
easier? But my point is that with an mqprio-type offload, both the
driver and the stack already need to be fully aware of the traffic
class. See for example this snippet from skb_tx_hash, which is called
from netdev_pick_tx:
if (dev->num_tc) {
u8 tc = netdev_get_prio_tc_map(dev, skb->priority);
qoffset = sb_dev->tc_to_txq[tc].offset;
qcount = sb_dev->tc_to_txq[tc].count;
}
So the stack does tx hashing to pick a queue only from the queue pool
that the driver is supposed to assign a strict hardware priority. It
has this awareness because it's not supposed to hash between queues of
different priorities (which is akin to playing Russian roulette). And
of course the driver needs to ensure that each netdev queue is
correctly assigned to a traffic class (which may mean something to do,
or not).
My suggestion is: let's keep the SetGateStates semantics operate on
traffic classes for the full offload, just like for the software
implementation. If for whatever reason the driver needs to associate
the tc with a tx queue, let them do it privately and not imprint it
into the qdisc interface.
I think your mindset that the driver does not know about the traffic
class is because the taprio offload structure does not pass that info
to it, like mqprio does? But you kindly provide that info indirectly
to both the stack and the driver, through the netdev_set_tc_queue and
netdev_set_prio_tc_map calls, so the driver should have all the rope
it needs (maybe except num_tcs). In the future, maybe we can move
those calls them before taprio_enable_offload? Right now there would
be no justification to do so. And also perhaps maybe there should be a
call to netdev_reset_tc in case the qdisc is removed?
> (Thinking more about this, I am having a few ideas about ways to simplify
> software mode :-)
>
>>
>> Q.2 Using gate operations to create protected windows The enhancements
>> for
>> scheduled traffic described in 8.6.8.4 allow transmission to be switched
>> on and
>> off on a timed basis for each _traffic class_ that is implemented on a
>> port. This
>> switching is achieved by means of individual on/off transmission gates
>> associated with each _traffic class_ and a list of gate operations that
>> control the
>> gates; an individual SetGateStates operation has a time delay parameter
>> that
>> indicates the delay after the gate operation is executed until the next
>> operation
>> is to occur, and a GateState parameter that defines a vector of up to
>> eight state
>> values (open or
>> closed) that is to be applied to each gate when the operation is executed.
>> The
>> gate operations allow any combination of open/closed states to be defined,
>> and
>> the mechanism makes no assumptions about which _traffic classes_ are
>> being
>> “protected” and which are “unprotected”; any such assumptions are left to
>> the
>> designer of the sequence of gate operations.
>>
>> Table 8-7—Gate operations
>> The GateState parameter indicates a value, open or closed, for each of
>> the
>> Port’s _queues_.
>>
>> - What happens with the "clockid" argument now that hardware offload is
>> possible? Do we allow "/dev/ptp0" to be specified as input?
>> Actually this question is relevant to your txtime-assist mode as well:
>> doesn't it assume that there is an implicit phc2sys instance running to
>> keep the
>> system time in sync with the PHC?
>
> That's a very interesting question. I think, for now, allowing specifying
> /dev/ptp* clocks
> won't work "always": if the driver or something needs to add a timer to be
> able to run
> the schedule, it won't be able to use /dev/ptp* clocks (hrtimers and ptp
> clocks don’t mix).
> But for "full" offloads, it should work.
>
But since the full offload could only work with the interface's PHC as
clockid, that kind of makes specifying any clockid redundant, right? I
think the right behavior would be to ignore that parameter (allow the
user to not specify it)?
> So, you are right, taprio and txtime-assisted (and ETF) require the system
> clock and phc
> clock to be synchronized, via something like phc2sys.
>
> Hope I got all your questions.
>
> Cheers,
> --
> Vinicius
>
>
I only have a very superficial understanding of the qdisc and
discussing these aspects with you helps a lot. There are a lot of
subtleties I'm missing, so I'm looking forward to your response. One
thing I would like to avoid is introduce more complexity than is
needed to solve the task at hand - hopefully I'm not oversimplifying.
Thanks,
-Vladimir
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Linus Torvalds @ 2019-09-11 11:58 UTC (permalink / raw)
To: Johannes Berg
Cc: David S. Miller, Kalle Valo, linux-wireless, Netdev,
Linux List Kernel Mailing
In-Reply-To: <feecebfcceba521703f13c8ee7f5bb9016924cb6.camel@sipsolutions.net>
On Wed, Sep 11, 2019 at 11:26 AM Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> Hi,
>
> > So I'm at LCA
>
> When did LCA move to Portugal? ;-))
Heh. I may be jetlagged and not thinking straight. LCA/LPC ;)
> > Previous resume looks normal:
> > [snip]
> > wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
> > 54:ec:2f:05:70:2c
>
> Is that the message you meant?
>
> > I say _almost_, because I don't see the "No TX power limit" for the
> > country lookup (yes, Portugal) this time?
>
> because here you had it too, just a bit earlier. It usually comes when a
> beacon is received the first time, which depends on the AP timing.
Duh. I'm blind and didn't notice, because I was expecting it in the same order.
And I didn't think about it or double-check, because the errors that
then followed later _looked_ like that TX power failing that I thought
hadn't happened.
> I don't _think_ any of the above would be a reason to disconnect, but it
> clearly looks like the device got stuck at this point, since everything
> just fails afterwards.
Yeah, maybe the power stuff was just another effect of things getting
stuck, rather than the reason for it getting stuck.
So I probably mis-attributed the cause.
> > WARNING: CPU: 4 PID: 1246 at net/mac80211/sta_info.c:1057
> > __sta_info_destroy_part2+0x147/0x150 [mac80211]
>
> Not really a surprise. Perhaps we shouldn't even WARN_ON() this, if the
> driver is stuck completely and returning errors to everything that
> doesn't help so much.
>
> Then again, the stack trace was helpful this time:
>
> > ieee80211_set_disassoc+0xc2/0x590 [mac80211]
> > ieee80211_mgd_deauth.cold+0x4a/0x1b8 [mac80211]
> > cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211]
> > cfg80211_mlme_down+0x66/0x90 [cfg80211]
> > cfg80211_disconnect+0x129/0x1e0 [cfg80211]
> > cfg80211_leave+0x27/0x40 [cfg80211]
> > cfg80211_netdev_notifier_call+0x1a7/0x4e0 [cfg80211]
> > notifier_call_chain+0x4c/0x70
> > __dev_close_many+0x57/0x100
> > dev_close_many+0x8d/0x140
> > dev_close.part.0+0x44/0x70
> > cfg80211_shutdown_all_interfaces+0x71/0xd0 [cfg80211]
> > cfg80211_rfkill_set_block+0x22/0x30 [cfg80211]
> > rfkill_set_block+0x92/0x140 [rfkill]
> > rfkill_fop_write+0x11f/0x1c0 [rfkill]
> > vfs_write+0xb6/0x1a0
>
>
> Since we see that something actually did an rfkill operation. Did you
> push a button there?
No, I tried to turn off and turn on Wifi manually (no button, just the
settings panel).
I didn't notice the WARN_ON(), I just noticed that there was no
networking, and "turn it off and on again" is obviously the first
thing to try ;)
> You don't happen to have timing information on these logs, perhaps
> recorded in the logfile/journal?
Sure. I cleaned up the logs to not spam people with lots of illegible
data, but it's all in the journal log.
Rough timeline:
Sep 11 03:40:00 xps13 kernel: PM: suspend entry (s2idle)
Sep 11 03:40:00 xps13 kernel: Filesystems sync: 0.028 seconds
...
Sep 11 10:13:14 xps13 kernel: Restarting tasks ... done.
Sep 11 10:13:14 xps13 kernel: PM: suspend exit
Sep 11 10:13:14 xps13 kernel: ath10k_pci 0000:02:00.0: UART prints enabled
Sep 11 10:13:14 xps13 kernel: ath10k_pci 0000:02:00.0: unsupported HTC
service id: 1536
Sep 11 10:13:23 xps13 kernel: wlp2s0: authenticate with 54:ec:2f:05:70:2c
Sep 11 10:13:23 xps13 kernel: wlp2s0: send auth to 54:ec:2f:05:70:2c (try 1/3)
Sep 11 10:13:23 xps13 kernel: wlp2s0: authenticated
Sep 11 10:13:23 xps13 kernel: wlp2s0: Limiting TX power to 23 (23 - 0)
dBm as advertised by 54:ec:2f:05:70:2c
...
Sep 11 10:13:23 xps13 kernel: ath: regdomain 0x826c dynamically
updated by country element
Sep 11 10:13:24 xps13 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0:
link becomes ready
Sep 11 10:27:07 xps13 kernel: ath10k_pci 0000:02:00.0: wmi command
16387 timeout, restarting hardware
...
Sep 11 10:27:07 xps13 kernel: ath10k_pci 0000:02:00.0: failed to read
hi_board_data address: -16
Sep 11 10:27:10 xps13 kernel: ath10k_pci 0000:02:00.0: failed to
receive initialized event from target: 00000000
Sep 11 10:27:13 xps13 kernel: ath10k_pci 0000:02:00.0: failed to
receive initialized event from target: 00000000
...
Sep 11 10:27:13 xps13 kernel: WARNING: CPU: 4 PID: 1246 at
net/mac80211/sta_info.c:1057 __sta_info_destroy_part2+0x147/0x150
[mac80211]
but if you want full logs I can send them in private to you.
I do suspect it's atheros and suspend/resume or something. The
wireless clearly worked for a while after the resume, but then at some
point it stopped.
> It seems odd to me, since the RTNL is acquired by
> cfg80211_rfkill_set_block() and that doesn't even have an error path, it
> just does
> rtnl_lock();
> cfg80211_shutdown_all_interfaces(&rdev->wiphy);
> rtnl_unlock();
>
> The only explanation I therefore have is that something is just taking
> *forever* in that code path, hence my question about timing information
> on the logs.
Yeah, maybe it would time out everything eventually. But not for a
long time. It hadn't cleared up by
Sep 11 10:36:21 xps13 gnome-session-f[6837]: gnome-session-failed:
Fatal IO error 0 (Success) on X server :0.
which is when I shut down the machine (and had to then force a hard
power-off because the shutdown wanted things that needed the rtnl_lock
to go away)
Linus
^ permalink raw reply
* Re: [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
From: Jiri Kosina @ 2019-09-11 12:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
David S. Miller, netdev, linux-kernel
In-Reply-To: <nycvar.YFH.7.76.1909111238470.473@cbobk.fhfr.pm>
On Wed, 11 Sep 2019, Jiri Kosina wrote:
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: [PATCH] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
Hm, scratch that, that might actually spuriously enable BHs if called from
contexts that already did disabled BHs.
So what solution would you prefer here? Just stick another par of
bh_disable() / bh_enable() somewhere to the wake_txs() ->
iwl_mvm_mac_itxq_xmit() -> iwl_mvm_tx_skb() -> iwl_mvm_tx_mpdu() path?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Johannes Berg @ 2019-09-11 12:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: David S. Miller, Kalle Valo, linux-wireless, Netdev,
Linux List Kernel Mailing
In-Reply-To: <CAHk-=wj_jneK+UYzHhjwsH0XxP0knM+2o2OeFVEz-FjuQ77-ow@mail.gmail.com>
On Wed, 2019-09-11 at 12:58 +0100, Linus Torvalds wrote:
>
> And I didn't think about it or double-check, because the errors that
> then followed later _looked_ like that TX power failing that I thought
> hadn't happened.
Yeah, it could be something already got stuck there, hard to say.
> > Since we see that something actually did an rfkill operation. Did you
> > push a button there?
>
> No, I tried to turn off and turn on Wifi manually (no button, just the
> settings panel).
That does usually also cause rfkill, so that explains how we got down
this particular code path.
> I didn't notice the WARN_ON(), I just noticed that there was no
> networking, and "turn it off and on again" is obviously the first
> thing to try ;)
:-)
> Sep 11 10:27:13 xps13 kernel: WARNING: CPU: 4 PID: 1246 at
> net/mac80211/sta_info.c:1057 __sta_info_destroy_part2+0x147/0x150
> [mac80211]
>
> but if you want full logs I can send them in private to you.
No, it's fine, though maybe Kalle does - he was stepping out for a while
but said he'd look later.
This is the interesting time - 10:27:13 we get one of the first
failures. Really the first one was this:
> Sep 11 10:27:07 xps13 kernel: ath10k_pci 0000:02:00.0: wmi command 16387 timeout, restarting hardware
> I do suspect it's atheros and suspend/resume or something. The
> wireless clearly worked for a while after the resume, but then at some
> point it stopped.
I'm not really sure it's related to suspend/resume at all, the firmware
seems to just have gotten stuck, and the device and firmware most likely
got reset over the suspend/resume anyway.
> > The only explanation I therefore have is that something is just taking
> > *forever* in that code path, hence my question about timing information
> > on the logs.
>
> Yeah, maybe it would time out everything eventually. But not for a
> long time. It hadn't cleared up by
>
> Sep 11 10:36:21 xps13 gnome-session-f[6837]: gnome-session-failed:
> Fatal IO error 0 (Success) on X server :0.
Ok, that's way longer than I would have guessed even! That's over 9
minutes, that'd be close to 200 commands having to be issued and timing
out ...
I don't know. What I wrote before is basically all I can say, I think
the driver gets stuck somewhere waiting for the device "forever", and
the stack just doesn't get to release the lock, causing all the follow-
up problems.
johannes
^ permalink raw reply
* Re: VRF Issue Since kernel 5
From: Gowen @ 2019-09-11 11:49 UTC (permalink / raw)
To: David Ahern, Alexis Bauvin; +Cc: netdev@vger.kernel.org
In-Reply-To: <CWLP265MB15544E2F2303FA2D0F76B7F5FDB10@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
previously mentioned attchements
From: Gowen <gowen@potatocomputing.co.uk>
Sent: 11 September 2019 12:19
To: David Ahern <dsahern@gmail.com>; Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: Re: VRF Issue Since kernel 5
Hi there,
Your perf command:
isc-worker0000 20261 [000] 2215.013849: fib:fib_table_lookup: table 10 oif 0 iif 0 proto 0 0.0.0.0/0 -> 127.0.0.1/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
isc-worker0000 20261 [000] 2215.013915: fib:fib_table_lookup: table 10 oif 4 iif 1 proto 17 0.0.0.0/52138 -> 127.0.0.53/53 tos 0 scope 0 flags 4 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
isc-worker0000 20261 [000] 2220.014006: fib:fib_table_lookup: table 10 oif 4 iif 1 proto 17 0.0.0.0/52138 -> 127.0.0.53/53 tos 0 scope 0 flags 4 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
Also I set all iptables to policy ACCEPT and flushed the rules, enabled forwarding, checked the sysctl settings are all '1'. I've looked at tracing DNS through the iptables and I see that DNS uses a loopback interface as source and destination - this would
be odd on a Cisco box but having looked around this appears to be normal?
I also gathered an strace of updating the package cache as well as a perf of the same command - will send if interested (is more verbose and not sure if the spam filter will block it)
Gareth
From: Gowen
Sent: 11 September 2019 06:09
To: David Ahern <dsahern@gmail.com>; Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: RE: VRF Issue Since kernel 5
Thanks for the link - that's really useful. I did re-order ip rules Friday (I think) - no change
-----Original Message-----
From: David Ahern <dsahern@gmail.com>
Sent: 10 September 2019 17:36
To: Alexis Bauvin <abauvin@online.net>; Gowen <gowen@potatocomputing.co.uk>
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
On 9/9/19 1:01 PM, Alexis Bauvin wrote:
> Could you try swapping the local and l3mdev rules?
>
> `ip rule del pref 0; ip rule add from all lookup local pref 1001`
yes, the rules should be re-ordered so that local rule is after l3mdev rule (VRF is implemented as policy routing). In general, I would reverse the order of those commands to ensure no breakage.
Also, 5.0 I think it was (too many kernel versions) added a new l3mdev sysctl (raw_l3mdev_accept). Check all 3 of them and nmake sure they are set properly for your use case.
These slides do not cover 5.0 changes but are still the best collection of notes on VRF:
http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
[-- Attachment #2: perfAptUpdate.txt --]
[-- Type: text/plain, Size: 26235 bytes --]
sudo 25916 [000] 4124.775681: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/47817 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.775699: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/47817 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.776123: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/33336 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.776125: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/33336 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.776530: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
sudo 25916 [000] 4124.776532: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
sudo 25916 [000] 4124.776533: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.9/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
sudo 25916 [000] 4124.776533: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.9/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
sudo 25916 [000] 4124.776538: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/51581 -> 10.24.12.9/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
sudo 25916 [000] 4124.776539: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.9/51581 -> 10.24.12.9/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
http 25921 [001] 4124.841213: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/37649 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [001] 4124.841216: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/37649 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [001] 4124.841719: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/48658 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [001] 4124.841721: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/48658 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.841776: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/58750 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.841777: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/58750 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.842489: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/38137 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.842491: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/38137 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25922 [000] 4124.843247: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/45896 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25922 [000] 4124.843249: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/45896 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [000] 4124.869712: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869714: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869715: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869715: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869720: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869720: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869721: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869721: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869724: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869724: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869725: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869725: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869728: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869728: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869729: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869729: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869732: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869732: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869733: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869733: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869736: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869736: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869754: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869755: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869758: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869758: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869759: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869759: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869762: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869762: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869763: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869763: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869766: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869766: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869767: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869767: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869770: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869771: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869771: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869771: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869812: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869813: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869814: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869814: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869818: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/58264 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869819: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/58264 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4124.871436: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/35659 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25922 [000] 4124.871437: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/35659 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.872626: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25920 [000] 4124.872627: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25920 [000] 4124.872644: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25920 [000] 4124.872645: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25920 [000] 4124.872647: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/37810 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25920 [000] 4124.872648: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/37810 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4125.053166: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25922 [000] 4125.053169: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4125.053171: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25922 [000] 4125.053172: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4125.053175: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/46538 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25922 [000] 4125.053176: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/46538 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.120263: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.120265: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.120267: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.120268: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.120271: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/50938 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.120272: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/50938 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.370745: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.370749: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.370751: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.370752: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.370756: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/55830 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.370757: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/55830 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.621209: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.621212: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.621215: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.621216: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.621219: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/42472 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.621220: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/42472 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.871668: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.871671: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.871673: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.871674: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.871676: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/43154 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.871677: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/43154 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.122165: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.122167: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.122169: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.122169: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.122172: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/36070 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.122172: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/36070 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.372690: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.372696: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.372701: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.372703: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.372709: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/37798 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.372711: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/37798 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.623146: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.623167: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.623169: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.623170: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.623172: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/57332 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.623173: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/57332 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.873604: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.873608: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.873610: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.873610: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.873614: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/54374 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.873614: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/54374 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4127.124045: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4127.124050: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4127.124054: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4127.124056: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4127.124062: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/45496 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4127.124063: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/45496 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
[-- Attachment #3: straceAptUpdate.txt --]
[-- Type: text/plain, Size: 39294 bytes --]
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
strace: Process 36321 attached
[pid 36321] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36321, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
strace: Process 36322 attached
[pid 36322] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36322] +++ killed by SIGINT +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=36322, si_uid=0, si_status=SIGINT, si_utime=0, si_stime=0} ---
strace: Process 36323 attached
strace: Process 36324 attached
strace: Process 36325 attached
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36324] sendto(3, "PN\1\0\0\1\0\0\0\0\0\1\5_http\4_tcp\10security\6ubuntu\3com\0\0!\0\1\0\0)\2\0\0\0\0\0\0\0", 59, MSG_NOSIGNAL, NULL, 0) = 59
[pid 36324] recvfrom(3, "PN\201\203\0\1\0\0\0\0\0\1\5_http\4_tcp\10security\6ubuntu\3com\0\0!\0\1\0\0)\377\326\0\0\0\0\0\0", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 59
[pid 36324] socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
[pid 36324] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
[pid 36324] getsockname(3, {sa_family=AF_NETLINK, nl_pid=36324, nl_groups=00000000}, [12]) = 0
[pid 36324] sendto(3, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1568192209, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 36324] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 127.0.0.1}, {{nla_len=8, nla_type=IFA_LOCAL}, 127.0.0.1}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1494, tstamp=1494}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth1")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth1"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1200, tstamp=1200}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 252
[pid 36324] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, ::1}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:ccad}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1490, tstamp=1490}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth1")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:c96c}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1198, tstamp=1198}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 216
[pid 36324] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
[pid 36324] connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36323] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36323] sendto(3, "\247\n\1\0\0\1\0\0\0\0\0\1\5_http\4_tcp\3ppa\tlaunchpad\3net\0\0!\0\1\0\0)\2\0\0\0\0\0\0\0", 57, MSG_NOSIGNAL, NULL, 0) = 57
[pid 36323] recvfrom(3, "\247\n\201\203\0\1\0\0\0\0\0\1\5_http\4_tcp\3ppa\tlaunchpad\3net\0\0!\0\1\0\0)\377\326\0\0\0\0\0\0", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 57
[pid 36324] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36324] sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="2\331\1\0\0\1\0\0\0\0\0\1\10security\6ubuntu\3com\0\0\1\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=48}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=48}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\376\336\1\0\0\1\0\0\0\0\0\1\10security\6ubuntu\3com\0\0\34\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=48}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=48}], 2, MSG_NOSIGNAL) = 2
[pid 36324] recvfrom(3, <unfinished ...>
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0 <unfinished ...>
[pid 36324] <... recvfrom resumed> "\376\336\201\200\0\1\0\6\0\0\0\1\10security\6ubuntu\3com\0\0\34\0\1\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\23`\200\1\0\0\0\0\0\0\0!\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25`\200\1\0\0\0\0\0\0\0\21\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25b\0\0\0\0\0\0\0\0\0\26\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\23`\200\1\0\0\0\0\0\0\0\27\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25b\0\0\0\0\0\0\0\0\0\31\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25`\200\1\0\0\0\0\0\0\0\24\0\0)\377\326\0\0\0\0\0\0", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 216
[pid 36325] <... socket resumed> ) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0 <unfinished ...>
[pid 36323] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12 <unfinished ...>
[pid 36325] <... socket resumed> ) = 3
[pid 36323] <... bind resumed> ) = 0
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110 <unfinished ...>
[pid 36323] getsockname(3, <unfinished ...>
[pid 36325] <... connect resumed> ) = -1 ENOENT (No such file or directory)
[pid 36323] <... getsockname resumed> {sa_family=AF_NETLINK, nl_pid=36323, nl_groups=00000000}, [12]) = 0
[pid 36323] sendto(3, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1568192209, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 36323] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 127.0.0.1}, {{nla_len=8, nla_type=IFA_LOCAL}, 127.0.0.1}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1494, tstamp=1494}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth1")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth1"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1200, tstamp=1200}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 252
[pid 36323] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, ::1}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:ccad}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1490, tstamp=1490}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth1")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:c96c}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1198, tstamp=1198}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 216
[pid 36323] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
[pid 36323] connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36323] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36323] sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="DN\1\0\0\1\0\0\0\0\0\1\3ppa\tlaunchpad\3net\0\0\1\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=46}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=46}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\340S\1\0\0\1\0\0\0\0\0\1\3ppa\tlaunchpad\3net\0\0\34\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=46}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=46}], 2, MSG_NOSIGNAL) = 2
[pid 36323] recvfrom(3, "DN\201\200\0\1\0\1\0\0\0\1\3ppa\tlaunchpad\3net\0\0\1\0\1\300\f\0\1\0\1\0\0\0\n\0\4[\275_S\0\0)\377\326\0\0\0\0\0\0", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 62
[pid 36323] recvfrom(3, "\340S\201\200\0\1\0\0\0\0\0\1\3ppa\tlaunchpad\3net\0\0\34\0\1\0\0)\377\326\0\0\0\0\0\0", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 36323] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid 36323] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.95.83")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36325] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36325] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36325] sendto(3, "\24A\1\0\0\1\0\0\0\0\0\1\5_http\4_tcp\5azure\7archive\6ubuntu\3com\0\0!\0\1\0\0)\2\0\0\0\0\0\0\0", 64, MSG_NOSIGNAL, NULL, 0) = 64
[pid 36325] recvfrom(3, "\24A\201\203\0\1\0\0\0\0\0\1\5_http\4_tcp\5azure\7archive\6ubuntu\3com\0\0!\0\1\0\0)\377\326\0\0\0\0\0\0", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 64
[pid 36325] socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
[pid 36325] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
[pid 36325] getsockname(3, {sa_family=AF_NETLINK, nl_pid=36325, nl_groups=00000000}, [12]) = 0
[pid 36325] sendto(3, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1568192209, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 36325] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 127.0.0.1}, {{nla_len=8, nla_type=IFA_LOCAL}, 127.0.0.1}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1494, tstamp=1494}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth1")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth1"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1200, tstamp=1200}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 252
[pid 36325] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, ::1}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:ccad}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1490, tstamp=1490}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth1")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:c96c}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1198, tstamp=1198}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 216
[pid 36325] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
[pid 36325] connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] recvfrom(3, "2\331\201\200\0\1\0\n\0\0\0\1\10security\6ubuntu\3com\0\0\1\0\1\300\f\0\1\0\1\0\0\0\31\0\4[\275X\30\300\f\0\1\0\1\0\0\0\31\0\4[\275[\32\300\f\0\1\0\1\0\0\0\31\0\4[\275X\255\300\f\0\1\0\1\0\0\0\31\0\4[\275X\256\300\f\0\1\0\1\0\0\0\31\0\4[\275[\30\300\f\0\1\0\1\0\0\0\31\0\4[\275[\27\300\f\0\1\0\1\0\0\0\31\0\4[\275X\242\300\f\0\1\0\1\0\0\0\31\0\4[\275[\16\300\f\0\1\0\1\0\0\0\31\0\4[\275X\225\300\f\0\1\0\1\0\0\0\31\0\4[\275X\37\0\0)\377\326\0\0\0\0\0\0", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 208
[pid 36324] socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::21", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::11", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::16", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::17", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16 <unfinished ...>
[pid 36325] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP <unfinished ...>
[pid 36324] <... connect resumed> ) = 0
[pid 36325] <... socket resumed> ) = 3
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::19", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
[pid 36325] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16 <unfinished ...>
[pid 36324] <... connect resumed> ) = -1 ENETUNREACH (Network is unreachable)
[pid 36325] <... connect resumed> ) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::14", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
[pid 36325] sendmmsg(3, <unfinished ...>
[pid 36324] <... connect resumed> ) = -1 ENETUNREACH (Network is unreachable)
[pid 36325] <... sendmmsg resumed> [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\346o\1\0\0\1\0\0\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\1\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=53}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=53}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\310w\1\0\0\1\0\0\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\34\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=53}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=53}], 2, MSG_NOSIGNAL) = 2
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.24")}, 16 <unfinished ...>
[pid 36325] recvfrom(3, <unfinished ...>
[pid 36324] <... connect resumed> ) = 0
[pid 36325] <... recvfrom resumed> "\310w\201\200\0\1\0\2\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\34\0\1\300\f\0\5\0\1\0\0\0\32\0'\22ubuntu-archive-asm\16trafficmanager\3net\0\3006\0\5\0\1\0\0\0\243\0$\narchive-lb\7uksouth\10cloudapp\5azure\300!\0\0)\377\326\0\0\0\0\0\0", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 152
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(49655), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.26")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(49028), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.173")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(41881), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.174")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(38464), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.24")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(42203), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.23")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(36741), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.162")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(55074), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.14")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(38765), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.149")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(50952), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.31")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(49783), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.24")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36325] recvfrom(3, "\346o\201\200\0\1\0\3\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\1\0\1\300\f\0\5\0\1\0\0\0\32\0'\22ubuntu-archive-asm\16trafficmanager\3net\0\3006\0\5\0\1\0\0\0\243\0$\narchive-lb\7uksouth\10cloudapp\5azure\300!\300i\0\1\0\1\0\0\0\n\0\0043\214\0\323\0\0)\377\326\0\0\0\0\0\0", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 168
[pid 36325] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid 36325] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("51.140.0.211")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
[pid 36324] connect(4, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::21", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
[pid 36324] connect(4, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.26")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 5
[pid 36324] connect(5, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::11", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
[pid 36324] connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.173")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 6
[pid 36324] connect(6, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::16", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
[pid 36324] connect(6, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.174")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 7
[pid 36324] connect(7, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::17", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
[pid 36324] connect(7, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.24")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 8
[pid 36324] connect(8, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::19", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
[pid 36324] connect(8, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.23")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 9
[pid 36324] connect(9, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::14", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
[pid 36324] connect(9, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.162")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 10
[pid 36324] connect(10, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.14")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 11
[pid 36324] connect(11, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.149")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 12
[pid 36324] connect(12, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.31")}, 16) = -1 EINPROGRESS (Operation now in progress)
Err:1 http://ppa.launchpad.net/ansible/ansible/ubuntu bionic InRelease
Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out
Err:2 http://azure.archive.ubuntu.com/ubuntu bionic InRelease
Could not connect to azure.archive.ubuntu.com:80 (51.140.0.211), connection timed out
Err:3 http://azure.archive.ubuntu.com/ubuntu bionic-updates InRelease
Unable to connect to azure.archive.ubuntu.com:http:
Err:4 http://azure.archive.ubuntu.com/ubuntu bionic-backports InRelease
Unable to connect to azure.archive.ubuntu.com:http:
Err:5 http://security.ubuntu.com/ubuntu bionic-security InRelease
Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::11). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::16). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::17). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::19). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::14). - connect (101: Network is unreachable) Could not connect to security.ubuntu.com:80 (91.189.88.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.26), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.173), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.174), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.23), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.162), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.14), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.149), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.31), connection timed out
[pid 36323] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36323] +++ exited with 100 +++
[pid 36320] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36323, si_uid=104, si_status=100, si_utime=0, si_stime=1} ---
[pid 36324] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36324] +++ exited with 100 +++
[pid 36320] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36324, si_uid=104, si_status=100, si_utime=0, si_stime=1} ---
[pid 36325] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36325] +++ exited with 100 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36325, si_uid=104, si_status=100, si_utime=1, si_stime=1} ---
Reading package lists...strace: Process 36394 attached
[pid 36394] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36394, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
strace: Process 36396 attached
[pid 36396] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36396, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
Building dependency tree...
Reading state information...
All packages are up to date.
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/bionic/InRelease Could not connect to azure.archive.ubuntu.com:80 (51.140.0.211), connection timed out
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease Unable to connect to azure.archive.ubuntu.com:http:
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease Unable to connect to azure.archive.ubuntu.com:http:
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::11). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::16). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::17). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::19). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::14). - connect (101: Network is unreachable) Could not connect to security.ubuntu.com:80 (91.189.88.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.26), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.173), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.174), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.23), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.162), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.14), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.149), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.31), connection timed out
W: Failed to fetch http://ppa.launchpad.net/ansible/ansible/ubuntu/dists/bionic/InRelease Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.
+++ exited with 0 +++
^ permalink raw reply
* Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled
From: Toke Høiland-Jørgensen @ 2019-09-11 12:09 UTC (permalink / raw)
To: Björn Töpel, Yonghong Song, Sami Tolvanen
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, Martin Lau,
Song Liu, netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, Jesper Dangaard Brouer
In-Reply-To: <fd8b6f04-3902-12e9-eab1-fa85b7e44dd5@intel.com>
Björn Töpel <bjorn.topel@intel.com> writes:
> On 2019-09-11 09:42, Yonghong Song wrote:
>> I am not an expert in XDP testing. Toke, Björn, could you give some
>> suggestions what to test for XDP performance here?
>
> I ran the "xdp_rxq_info" sample with and without Sami's patch:
Thanks for doing this!
> $ sudo ./xdp_rxq_info --dev enp134s0f0 --action XDP_DROP
>
> Before:
>
> Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch
> XDP stats CPU pps issue-pps
> XDP-RX CPU 20 23923874 0
> XDP-RX CPU total 23923874
>
> RXQ stats RXQ:CPU pps issue-pps
> rx_queue_index 20:20 23923878 0
> rx_queue_index 20:sum 23923878
>
> After Sami's patch:
>
> Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch
> XDP stats CPU pps issue-pps
> XDP-RX CPU 20 22998700 0
> XDP-RX CPU total 22998700
>
> RXQ stats RXQ:CPU pps issue-pps
> rx_queue_index 20:20 22998705 0
> rx_queue_index 20:sum 22998705
>
>
> So, roughly ~4% for this somewhat naive scenario.
Or (1/22998700 - 1/23923874) * 10**9 == 1.7 nanoseconds of overhead.
I guess that is not *too* bad; but it's still chipping away at
performance; anything we could do to lower the overhead?
-Toke
^ permalink raw reply
* [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 12:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason Wang, kvm, virtualization, netdev
iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.
Userspace address are later validated with array_index_nospec so we can
be sure kernel info does not leak through these addresses, but vhost
must also not leak userspace info outside the allowed memory table to
guests.
Following the defence in depth principle, make sure
the address is not validated out of node range.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Tested-by: Jason Wang <jasowang@redhat.com>
---
changes from v1: fix build on 32 bit
drivers/vhost/vhost.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 5dc174ac8cac..34ea219936e3 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
_iov = iov + ret;
size = node->size - addr + node->start;
_iov->iov_len = min((u64)len - s, size);
- _iov->iov_base = (void __user *)(unsigned long)
- (node->userspace_addr + addr - node->start);
+ _iov->iov_base = (void __user *)
+ ((unsigned long)node->userspace_addr +
+ array_index_nospec((unsigned long)(addr - node->start),
+ node->size));
s += size;
addr += size;
++ret;
--
MST
^ permalink raw reply related
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michal Hocko @ 2019-09-11 12:16 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911120908.28410-1-mst@redhat.com>
On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> iovec addresses coming from vhost are assumed to be
> pre-validated, but in fact can be speculated to a value
> out of range.
>
> Userspace address are later validated with array_index_nospec so we can
> be sure kernel info does not leak through these addresses, but vhost
> must also not leak userspace info outside the allowed memory table to
> guests.
>
> Following the defence in depth principle, make sure
> the address is not validated out of node range.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Acked-by: Jason Wang <jasowang@redhat.com>
> Tested-by: Jason Wang <jasowang@redhat.com>
no need to mark fo stable? Other spectre fixes tend to be backported
even when the security implications are not really clear. The risk
should be low and better to be covered in case.
> ---
>
> changes from v1: fix build on 32 bit
>
> drivers/vhost/vhost.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5dc174ac8cac..34ea219936e3 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
> _iov = iov + ret;
> size = node->size - addr + node->start;
> _iov->iov_len = min((u64)len - s, size);
> - _iov->iov_base = (void __user *)(unsigned long)
> - (node->userspace_addr + addr - node->start);
> + _iov->iov_base = (void __user *)
> + ((unsigned long)node->userspace_addr +
> + array_index_nospec((unsigned long)(addr - node->start),
> + node->size));
> s += size;
> addr += size;
> ++ret;
> --
> MST
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 12:25 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911121628.GT4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > iovec addresses coming from vhost are assumed to be
> > pre-validated, but in fact can be speculated to a value
> > out of range.
> >
> > Userspace address are later validated with array_index_nospec so we can
> > be sure kernel info does not leak through these addresses, but vhost
> > must also not leak userspace info outside the allowed memory table to
> > guests.
> >
> > Following the defence in depth principle, make sure
> > the address is not validated out of node range.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Acked-by: Jason Wang <jasowang@redhat.com>
> > Tested-by: Jason Wang <jasowang@redhat.com>
>
> no need to mark fo stable? Other spectre fixes tend to be backported
> even when the security implications are not really clear. The risk
> should be low and better to be covered in case.
This is not really a fix - more a defence in depth thing,
quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
in scope.
That one doesn't seem to be tagged for stable. Was it queued
there in practice?
> > ---
> >
> > changes from v1: fix build on 32 bit
> >
> > drivers/vhost/vhost.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 5dc174ac8cac..34ea219936e3 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
> > _iov = iov + ret;
> > size = node->size - addr + node->start;
> > _iov->iov_len = min((u64)len - s, size);
> > - _iov->iov_base = (void __user *)(unsigned long)
> > - (node->userspace_addr + addr - node->start);
> > + _iov->iov_base = (void __user *)
> > + ((unsigned long)node->userspace_addr +
> > + array_index_nospec((unsigned long)(addr - node->start),
> > + node->size));
> > s += size;
> > addr += size;
> > ++ret;
> > --
> > MST
>
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* Re: [PATCH 6/7] net: dsa: mv88e6xxx: add egress rate limiting
From: kbuild test robot @ 2019-09-11 12:26 UTC (permalink / raw)
To: Robert Beckett
Cc: kbuild-all, netdev, Robert Beckett, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller
In-Reply-To: <20190910154238.9155-7-bob.beckett@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]
Hi Robert,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc8 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Robert-Beckett/net-dsa-mv88e6xxx-features-to-handle-network-storms/20190911-142233
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/net//dsa/mv88e6xxx/chip.c:3529:31: error: 'mv88e6097_port_egress_rate_limiting' undeclared here (not in a function); did you mean 'mv88e6xxx_port_egress_rate_limiting'?
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mv88e6xxx_port_egress_rate_limiting
vim +3529 drivers/net//dsa/mv88e6xxx/chip.c
b3469dd8adade1 Vivien Didelot 2016-09-29 3510
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3511 static const struct mv88e6xxx_ops mv88e6250_ops = {
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3512 /* MV88E6XXX_FAMILY_6250 */
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3513 .ieee_pri_map = mv88e6250_g1_ieee_pri_map,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3514 .ip_pri_map = mv88e6085_g1_ip_pri_map,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3515 .irl_init_all = mv88e6352_g2_irl_init_all,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3516 .get_eeprom = mv88e6xxx_g2_get_eeprom16,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3517 .set_eeprom = mv88e6xxx_g2_set_eeprom16,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3518 .set_switch_mac = mv88e6xxx_g2_set_switch_mac,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3519 .phy_read = mv88e6xxx_g2_smi_phy_read,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3520 .phy_write = mv88e6xxx_g2_smi_phy_write,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3521 .port_set_link = mv88e6xxx_port_set_link,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3522 .port_set_duplex = mv88e6xxx_port_set_duplex,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3523 .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3524 .port_set_speed = mv88e6250_port_set_speed,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3525 .port_tag_remap = mv88e6095_port_tag_remap,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3526 .port_set_frame_mode = mv88e6351_port_set_frame_mode,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3527 .port_set_egress_floods = mv88e6352_port_set_egress_floods,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3528 .port_set_ether_type = mv88e6351_port_set_ether_type,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 @3529 .port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3530 .port_pause_limit = mv88e6097_port_pause_limit,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3531 .port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3532 .port_link_state = mv88e6250_port_link_state,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3533 .stats_snapshot = mv88e6320_g1_stats_snapshot,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3534 .stats_set_histogram = mv88e6095_g1_stats_set_histogram,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3535 .stats_get_sset_count = mv88e6250_stats_get_sset_count,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3536 .stats_get_strings = mv88e6250_stats_get_strings,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3537 .stats_get_stats = mv88e6250_stats_get_stats,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3538 .set_cpu_port = mv88e6095_g1_set_cpu_port,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3539 .set_egress_port = mv88e6095_g1_set_egress_port,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3540 .watchdog_ops = &mv88e6250_watchdog_ops,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3541 .mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3542 .pot_clear = mv88e6xxx_g2_pot_clear,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3543 .reset = mv88e6250_g1_reset,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3544 .vtu_getnext = mv88e6250_g1_vtu_getnext,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3545 .vtu_loadpurge = mv88e6250_g1_vtu_loadpurge,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3546 .phylink_validate = mv88e6065_phylink_validate,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3547 };
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3548
:::::: The code at line 3529 was first introduced by commit
:::::: 1f71836f5d96e4c87fad16db86d324bee47e1d30 net: dsa: mv88e6xxx: add support for mv88e6250
:::::: TO: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50818 bytes --]
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michal Hocko @ 2019-09-11 12:33 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911082236-mutt-send-email-mst@kernel.org>
On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > iovec addresses coming from vhost are assumed to be
> > > pre-validated, but in fact can be speculated to a value
> > > out of range.
> > >
> > > Userspace address are later validated with array_index_nospec so we can
> > > be sure kernel info does not leak through these addresses, but vhost
> > > must also not leak userspace info outside the allowed memory table to
> > > guests.
> > >
> > > Following the defence in depth principle, make sure
> > > the address is not validated out of node range.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > Tested-by: Jason Wang <jasowang@redhat.com>
> >
> > no need to mark fo stable? Other spectre fixes tend to be backported
> > even when the security implications are not really clear. The risk
> > should be low and better to be covered in case.
>
> This is not really a fix - more a defence in depth thing,
> quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> in scope.
>
> That one doesn't seem to be tagged for stable. Was it queued
> there in practice?
not marked for stable but it went in. At least to 4.4.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: Marcelo Ricardo Leitner @ 2019-09-11 12:56 UTC (permalink / raw)
To: Xin Long
Cc: David Laight, network dev, linux-sctp@vger.kernel.org,
Neil Horman, davem@davemloft.net
In-Reply-To: <CADvbK_dqNas+vwP2t3LqWyabNnzRDO=PZPe4p+zE-vQJTnfKpA@mail.gmail.com>
On Wed, Sep 11, 2019 at 05:38:33PM +0800, Xin Long wrote:
> On Wed, Sep 11, 2019 at 5:21 PM Xin Long <lucien.xin@gmail.com> wrote:
> >
> > On Wed, Sep 11, 2019 at 5:03 PM David Laight <David.Laight@aculab.com> wrote:
> > >
> > > From: Xin Long [mailto:lucien.xin@gmail.com]
> > > > Sent: 11 September 2019 09:52
> > > > On Tue, Sep 10, 2019 at 9:19 PM David Laight <David.Laight@aculab.com> wrote:
> > > > >
> > > > > From: Xin Long
> > > > > > Sent: 09 September 2019 08:57
> > > > > > Section 7.2 of rfc7829: "Peer Address Thresholds (SCTP_PEER_ADDR_THLDS)
> > > > > > Socket Option" extends 'struct sctp_paddrthlds' with 'spt_pathcpthld'
> > > > > > added to allow a user to change ps_retrans per sock/asoc/transport, as
> > > > > > other 2 paddrthlds: pf_retrans, pathmaxrxt.
> > > > > >
> > > > > > Note that ps_retrans is not allowed to be greater than pf_retrans.
> > > > > >
> > > > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > > > ---
> > > > > > include/uapi/linux/sctp.h | 1 +
> > > > > > net/sctp/socket.c | 10 ++++++++++
> > > > > > 2 files changed, 11 insertions(+)
> > > > > >
> > > > > > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > > > > > index a15cc28..dfd81e1 100644
> > > > > > --- a/include/uapi/linux/sctp.h
> > > > > > +++ b/include/uapi/linux/sctp.h
> > > > > > @@ -1069,6 +1069,7 @@ struct sctp_paddrthlds {
> > > > > > struct sockaddr_storage spt_address;
> > > > > > __u16 spt_pathmaxrxt;
> > > > > > __u16 spt_pathpfthld;
> > > > > > + __u16 spt_pathcpthld;
> > > > > > };
> > > > > >
> > > > > > /*
> > > > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > > > > index 5e2098b..5b9774d 100644
> > > > > > --- a/net/sctp/socket.c
> > > > > > +++ b/net/sctp/socket.c
> > > > > > @@ -3954,6 +3954,9 @@ static int sctp_setsockopt_paddr_thresholds(struct sock *sk,
> > > > >
> > > > > This code does:
> > > > > if (optlen < sizeof(struct sctp_paddrthlds))
> > > > > return -EINVAL;
> > > > here will become:
> > > >
> > > > if (optlen >= sizeof(struct sctp_paddrthlds)) {
> > > > optlen = sizeof(struct sctp_paddrthlds);
> > > > } else if (optlen >= ALIGN(offsetof(struct sctp_paddrthlds,
> > > > spt_pathcpthld), 4))
> > > > optlen = ALIGN(offsetof(struct sctp_paddrthlds,
> > > > spt_pathcpthld), 4);
> > > > val.spt_pathcpthld = 0xffff;
> > > > else {
> > > > return -EINVAL;
> > > > }
> > >
> > > Hmmm...
> > > If the kernel has to default 'val.spt_pathcpthld = 0xffff'
> > > then recompiling an existing application with the new uapi
> > > header is going to lead to very unexpected behaviour.
> > >
> > > The best you can hope for is that the application memset the
> > > structure to zero.
> > > But more likely it is 'random' on-stack data.
> > 0xffff is a value to disable the feature 'Primary Path Switchover'.
> > you're right that user might set it to zero unexpectly with their
> > old application rebuilt.
> >
> > A safer way is to introduce "sysctl net.sctp.ps_retrans", it won't
> > matter if users set spt_pathcpthld properly when they're not aware
> > of this feature, like "sysctl net.sctp.pF_retrans". Looks better?
> Sorry for confusing, "sysctl net.sctp.ps_retrans" is already there
> (its value is 0xffff by default),
> we just need to do this in sctp_setsockopt_paddr_thresholds():
>
> if (copy_from_user(&val, (struct sctp_paddrthlds __user *)optval,
> optlen))
> return -EFAULT;
>
> if (sock_net(sk)->sctp.ps_retrans == 0xffff)
> val.spt_pathcpthld = 0xffff;
I'm confused with the snippets, but if I got them right, this is after
dealing with proper len and could leave val.spt_pathcpthld
uninitialized if the application used the old format and sysctl is !=
0xffff.
>
> if (val.spt_pathpfthld > val.spt_pathcpthld)
> return -EINVAL;
>
> >
> > >
> > > David
> > >
> > > -
> > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > Registration No: 1397386 (Wales)
>
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 13:03 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911123316.GX4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > iovec addresses coming from vhost are assumed to be
> > > > pre-validated, but in fact can be speculated to a value
> > > > out of range.
> > > >
> > > > Userspace address are later validated with array_index_nospec so we can
> > > > be sure kernel info does not leak through these addresses, but vhost
> > > > must also not leak userspace info outside the allowed memory table to
> > > > guests.
> > > >
> > > > Following the defence in depth principle, make sure
> > > > the address is not validated out of node range.
> > > >
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > Tested-by: Jason Wang <jasowang@redhat.com>
> > >
> > > no need to mark fo stable? Other spectre fixes tend to be backported
> > > even when the security implications are not really clear. The risk
> > > should be low and better to be covered in case.
> >
> > This is not really a fix - more a defence in depth thing,
> > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > in scope.
> >
> > That one doesn't seem to be tagged for stable. Was it queued
> > there in practice?
>
> not marked for stable but it went in. At least to 4.4.
So I guess the answer is I don't know. If you feel it's
justified, then sure, feel free to forward.
--
MST
^ permalink raw reply
* [PATCH] mac80211: Do not send Layer 2 Update frame before authorization
From: Jouni Malinen @ 2019-09-11 13:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David Miller, netdev, Jouni Malinen
The Layer 2 Update frame is used to update bridges when a station roams
to another AP even if that STA does not transmit any frames after the
reassociation. This behavior was described in IEEE Std 802.11F-2003 as
something that would happen based on MLME-ASSOCIATE.indication, i.e.,
before completing 4-way handshake. However, this IEEE trial-use
recommended practice document was published before RSN (IEEE Std
802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
maintained amd should not be used anymore.
Sending out the Layer 2 Update frame immediately after association is
fine for open networks (and also when using SAE, FT protocol, or FILS
authentication when the station is actually authenticated by the time
association completes). However, it is not appropriate for cases where
RSN is used with PSK or EAP authentication since the station is actually
fully authenticated only once the 4-way handshake completes after
authentication and attackers might be able to use the unauthenticated
triggering of Layer 2 Update frame transmission to disrupt bridge
behavior.
Fix this by postponing transmission of the Layer 2 Update frame from
station entry addition to the point when the station entry is marked
authorized. Similarly, send out the VLAN binding update only if the STA
entry has already been authorized.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
---
net/mac80211/cfg.c | 14 ++++----------
net/mac80211/sta_info.c | 4 ++++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index ed56b0c6fe19..817f37b64eb5 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1532,7 +1532,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
struct sta_info *sta;
struct ieee80211_sub_if_data *sdata;
int err;
- int layer2_update;
if (params->vlan) {
sdata = IEEE80211_DEV_TO_SUB_IF(params->vlan);
@@ -1575,18 +1574,12 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
test_sta_flag(sta, WLAN_STA_ASSOC))
rate_control_rate_init(sta);
- layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
- sdata->vif.type == NL80211_IFTYPE_AP;
-
err = sta_info_insert_rcu(sta);
if (err) {
rcu_read_unlock();
return err;
}
- if (layer2_update)
- cfg80211_send_layer2_update(sta->sdata->dev, sta->sta.addr);
-
rcu_read_unlock();
return 0;
@@ -1684,10 +1677,11 @@ static int ieee80211_change_station(struct wiphy *wiphy,
sta->sdata = vlansdata;
ieee80211_check_fast_xmit(sta);
- if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ if (test_sta_flag(sta, WLAN_STA_AUTHORIZED)) {
ieee80211_vif_inc_num_mcast(sta->sdata);
-
- cfg80211_send_layer2_update(sta->sdata->dev, sta->sta.addr);
+ cfg80211_send_layer2_update(sta->sdata->dev,
+ sta->sta.addr);
+ }
}
err = sta_apply_parameters(local, sta, params);
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index df553070206c..bd11fef2139f 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1979,6 +1979,10 @@ int sta_info_move_state(struct sta_info *sta,
ieee80211_check_fast_xmit(sta);
ieee80211_check_fast_rx(sta);
}
+ if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sta->sdata->vif.type == NL80211_IFTYPE_AP)
+ cfg80211_send_layer2_update(sta->sdata->dev,
+ sta->sta.addr);
break;
default:
break;
--
2.20.1
^ permalink raw reply related
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Ben Greear @ 2019-09-11 13:03 UTC (permalink / raw)
To: Johannes Berg, Linus Torvalds
Cc: David S. Miller, Kalle Valo, linux-wireless, Netdev,
Linux List Kernel Mailing
In-Reply-To: <30679d3f86731475943856196478677e70a349a9.camel@sipsolutions.net>
On 09/11/2019 05:04 AM, Johannes Berg wrote:
> On Wed, 2019-09-11 at 12:58 +0100, Linus Torvalds wrote:
>>
>> And I didn't think about it or double-check, because the errors that
>> then followed later _looked_ like that TX power failing that I thought
>> hadn't happened.
>
> Yeah, it could be something already got stuck there, hard to say.
>
>>> Since we see that something actually did an rfkill operation. Did you
>>> push a button there?
>>
>> No, I tried to turn off and turn on Wifi manually (no button, just the
>> settings panel).
>
> That does usually also cause rfkill, so that explains how we got down
> this particular code path.
>
>> I didn't notice the WARN_ON(), I just noticed that there was no
>> networking, and "turn it off and on again" is obviously the first
>> thing to try ;)
>
> :-)
>
>> Sep 11 10:27:13 xps13 kernel: WARNING: CPU: 4 PID: 1246 at
>> net/mac80211/sta_info.c:1057 __sta_info_destroy_part2+0x147/0x150
>> [mac80211]
>>
>> but if you want full logs I can send them in private to you.
>
> No, it's fine, though maybe Kalle does - he was stepping out for a while
> but said he'd look later.
>
> This is the interesting time - 10:27:13 we get one of the first
> failures. Really the first one was this:
>
>> Sep 11 10:27:07 xps13 kernel: ath10k_pci 0000:02:00.0: wmi command 16387 timeout, restarting hardware
>
>
>> I do suspect it's atheros and suspend/resume or something. The
>> wireless clearly worked for a while after the resume, but then at some
>> point it stopped.
>
> I'm not really sure it's related to suspend/resume at all, the firmware
> seems to just have gotten stuck, and the device and firmware most likely
> got reset over the suspend/resume anyway.
>
>>> The only explanation I therefore have is that something is just taking
>>> *forever* in that code path, hence my question about timing information
>>> on the logs.
>>
>> Yeah, maybe it would time out everything eventually. But not for a
>> long time. It hadn't cleared up by
>>
>> Sep 11 10:36:21 xps13 gnome-session-f[6837]: gnome-session-failed:
>> Fatal IO error 0 (Success) on X server :0.
>
> Ok, that's way longer than I would have guessed even! That's over 9
> minutes, that'd be close to 200 commands having to be issued and timing
> out ...
>
> I don't know. What I wrote before is basically all I can say, I think
> the driver gets stuck somewhere waiting for the device "forever", and
> the stack just doesn't get to release the lock, causing all the follow-
> up problems.
It looks to me like the ath10k firmware is not responding to commands and/or
is out of its WMI tx credits. The code often takes a lock and then blocks for up to 3
or so seconds waiting for a response from the firmware, and the mac80211 calling
code is often already holding rtnl. Pretty much every mac80211 call will cause a
WMI message and thus potentially hit this timeout.
This can easily cause rtnl to be held for 3 seconds, but after that, I believe
upstream ath10k will now time out and kill the firmware and restart. (I run
a significantly modified ath10k driver, and that is how mine works, at least.)
In this case, it looks like restarting the firmware/NIC failed, and I guess
that must get it in a state where it is still blocking and trying to talk
to the firmware? Or maybe deadlock down inside ath10k driver.
For what it's worth, we see that WARN_ON often when ath10k firmware crashes, but it
seems to not be a big deal and the system normally recovers fine.
Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH iproute2-next] devlink: add 'reset_dev_on_drv_probe' devlink param
From: Simon Horman @ 2019-09-11 13:05 UTC (permalink / raw)
To: David Ahern
Cc: Jiri Pirko, netdev, oss-drivers, Jakub Kicinski,
Dirk van der Merwe, Simon Horman
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add support for the new devlink parameter along with string to uint
conversion.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Depends on devlink.h changes present in net-next commit
5bbd21df5a07 ("devlink: add 'reset_dev_on_drv_probe' param")
---
devlink/devlink.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 2f084c020765..15877a04f5d6 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -2253,6 +2253,26 @@ static const struct param_val_conv param_val_conv[] = {
.vstr = "flash",
.vuint = DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH,
},
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "unknown",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_UNKNOWN,
+ },
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "always",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_ALWAYS,
+ },
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "never",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_NEVER,
+ },
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "disk",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_DISK,
+ },
};
#define PARAM_VAL_CONV_LEN ARRAY_SIZE(param_val_conv)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] mac80211: Do not send Layer 2 Update frame before authorization
From: Johannes Berg @ 2019-09-11 13:06 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, David Miller, netdev
In-Reply-To: <20190911130305.23704-1-jouni@codeaurora.org>
On Wed, 2019-09-11 at 16:03 +0300, Jouni Malinen wrote:
> The Layer 2 Update frame is used to update bridges when a station roams
> to another AP even if that STA does not transmit any frames after the
> reassociation. This behavior was described in IEEE Std 802.11F-2003 as
> something that would happen based on MLME-ASSOCIATE.indication, i.e.,
> before completing 4-way handshake. However, this IEEE trial-use
> recommended practice document was published before RSN (IEEE Std
> 802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
> IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
> maintained amd should not be used anymore.
>
> Sending out the Layer 2 Update frame immediately after association is
> fine for open networks (and also when using SAE, FT protocol, or FILS
> authentication when the station is actually authenticated by the time
> association completes). However, it is not appropriate for cases where
> RSN is used with PSK or EAP authentication since the station is actually
> fully authenticated only once the 4-way handshake completes after
> authentication and attackers might be able to use the unauthenticated
> triggering of Layer 2 Update frame transmission to disrupt bridge
> behavior.
>
> Fix this by postponing transmission of the Layer 2 Update frame from
> station entry addition to the point when the station entry is marked
> authorized. Similarly, send out the VLAN binding update only if the STA
> entry has already been authorized.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Dave, if you were still planning to send a pull request to Linus before
he closes the tree on Sunday this would be good to include (and we
should also backport it to stable later).
If not, I can pick it up afterwards, let me know.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michal Hocko @ 2019-09-11 13:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911085807-mutt-send-email-mst@kernel.org>
On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > > iovec addresses coming from vhost are assumed to be
> > > > > pre-validated, but in fact can be speculated to a value
> > > > > out of range.
> > > > >
> > > > > Userspace address are later validated with array_index_nospec so we can
> > > > > be sure kernel info does not leak through these addresses, but vhost
> > > > > must also not leak userspace info outside the allowed memory table to
> > > > > guests.
> > > > >
> > > > > Following the defence in depth principle, make sure
> > > > > the address is not validated out of node range.
> > > > >
> > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > > Tested-by: Jason Wang <jasowang@redhat.com>
> > > >
> > > > no need to mark fo stable? Other spectre fixes tend to be backported
> > > > even when the security implications are not really clear. The risk
> > > > should be low and better to be covered in case.
> > >
> > > This is not really a fix - more a defence in depth thing,
> > > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > > in scope.
> > >
> > > That one doesn't seem to be tagged for stable. Was it queued
> > > there in practice?
> >
> > not marked for stable but it went in. At least to 4.4.
>
> So I guess the answer is I don't know. If you feel it's
> justified, then sure, feel free to forward.
Well, that obviously depends on you as a maintainer but the point is
that spectre gatgets are quite hard to find. There is a smack check
AFAIK but that generates quite some false possitives and it is PITA to
crawl through those. If you want an interesting (I am not saying
vulnerable on purpose) gatget then it would be great to mark it for
stable so all stable consumers (disclaimer: I am not one of those) and
add that really great feeling of safety ;)
So take this as my 2c
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* pull-request: mac80211-next 2019-09-11
From: Johannes Berg @ 2019-09-11 13:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
As detailed below, here are some more changes for -next, almost
certainly the final round since the merge window is around the
corner now.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit c76c992525245ec1c7b6738bf887c42099abab02:
nexthops: remove redundant assignment to variable err (2019-08-22 12:14:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2019-09-11
for you to fetch changes up to c1d3ad84eae35414b6b334790048406bd6301b12:
cfg80211: Purge frame registrations on iftype change (2019-09-11 10:45:10 +0200)
----------------------------------------------------------------
We have a number of changes, but things are settling down:
* a fix in the new 6 GHz channel support
* a fix for recent minstrel (rate control) updates
for an infinite loop
* handle interface type changes better wrt. management frame
registrations (for management frames sent to userspace)
* add in-BSS RX time to survey information
* handle HW rfkill properly if !CONFIG_RFKILL
* send deauth on IBSS station expiry, to avoid state mismatches
* handle deferred crypto tailroom updates in mac80211 better
when device restart happens
* fix a spectre-v1 - really a continuation of a previous patch
* advertise NL80211_CMD_UPDATE_FT_IES as supported if so
* add some missing parsing in VHT extended NSS support
* support HE in mac80211_hwsim
* let mac80211 drivers determine the max MTU themselves
along with the usual cleanups etc.
----------------------------------------------------------------
Arend van Spriel (1):
cfg80211: fix boundary value in ieee80211_frequency_to_channel()
Colin Ian King (1):
mac80211: minstrel_ht: fix infinite loop because supported is not being shifted
Denis Kenzior (1):
cfg80211: Purge frame registrations on iftype change
Felix Fietkau (1):
cfg80211: add local BSS receive time to survey information
Johannes Berg (4):
cfg80211: always shut down on HW rfkill
mac80211: list features in WEP/TKIP disable in better order
mac80211: remove unnecessary key condition
mac80211: IBSS: send deauth when expiring inactive STAs
Lior Cohen (1):
mac80211: clear crypto tx tailroom counter upon keys enable
Luca Coelho (1):
mac80211: don't check if key is NULL in ieee80211_key_link()
Masashi Honma (1):
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
Matthew Wang (1):
nl80211: add NL80211_CMD_UPDATE_FT_IES to supported commands
Mordechay Goodstein (1):
mac80211: vht: add support VHT EXT NSS BW in parsing VHT
Sven Eckelmann (1):
mac80211_hwsim: Register support for HE meshpoint
Wen Gong (1):
mac80211: allow drivers to set max MTU
zhong jiang (1):
cfg80211: Do not compare with boolean in nl80211_common_reg_change_event
drivers/net/wireless/mac80211_hwsim.c | 283 +++++++++++++++++++++++-----------
include/net/cfg80211.h | 4 +
include/net/mac80211.h | 3 +
include/uapi/linux/nl80211.h | 3 +
net/mac80211/ibss.c | 8 +
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/iface.c | 2 +-
net/mac80211/key.c | 48 ++----
net/mac80211/key.h | 4 +-
net/mac80211/main.c | 1 +
net/mac80211/mlme.c | 13 +-
net/mac80211/rc80211_minstrel_ht.c | 2 +-
net/mac80211/util.c | 11 +-
net/mac80211/vht.c | 10 +-
net/wireless/core.c | 13 +-
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 17 +-
net/wireless/util.c | 3 +-
net/wireless/wext-compat.c | 5 +-
19 files changed, 274 insertions(+), 161 deletions(-)
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Linus Torvalds @ 2019-09-11 13:21 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, David S. Miller, Kalle Valo, linux-wireless,
Netdev, Linux List Kernel Mailing
In-Reply-To: <2d673d55-eb27-8573-b8ae-a493335723cf@candelatech.com>
On Wed, Sep 11, 2019 at 2:03 PM Ben Greear <greearb@candelatech.com> wrote:
>
> Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
It's a Dell XPS 13 9380, with
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac
Wireless Network Adapter (rev 32)
Subsystem: Bigfoot Networks, Inc. Killer 1435 Wireless-AC
(numeric PCI ID 168c:003e, subsystem 1a56:143a).
The ath10k driver says
qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:143a
firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1 api 6 features
wowlan,ignore-otp,mfp crc32 29eb8ca1
board_file api 2 bmi_id N/A crc32 4ed3569e
if that tells you anything more.
Linus
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Ben Greear @ 2019-09-11 13:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, David S. Miller, Kalle Valo, linux-wireless,
Netdev, Linux List Kernel Mailing
In-Reply-To: <CAHk-=wgAXAw=U_kthB9mG+MBocpawxCzo=6WDrbGgOUr+ac3CA@mail.gmail.com>
On 09/11/2019 06:21 AM, Linus Torvalds wrote:
> On Wed, Sep 11, 2019 at 2:03 PM Ben Greear <greearb@candelatech.com> wrote:
>>
>> Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
>
> It's a Dell XPS 13 9380, with
>
> 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac
> Wireless Network Adapter (rev 32)
> Subsystem: Bigfoot Networks, Inc. Killer 1435 Wireless-AC
>
> (numeric PCI ID 168c:003e, subsystem 1a56:143a).
>
> The ath10k driver says
>
> qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:143a
> firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1 api 6 features
> wowlan,ignore-otp,mfp crc32 29eb8ca1
> board_file api 2 bmi_id N/A crc32 4ed3569e
>
> if that tells you anything more.
That means it is something I have never used nor have firmware for, but
the WMI logic should be similar to what I described and have experienced
with other chips.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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