* [PATCH] net: lmc: fix spelling mistake "runnin" -> "running"
From: Colin King @ 2019-09-11 11:37 UTC (permalink / raw)
To: David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in the lmc_trace message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/lmc/lmc_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index d74349628db2..0e6a51525d91 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1115,7 +1115,7 @@ static void lmc_running_reset (struct net_device *dev) /*fold00*/
sc->lmc_cmdmode |= (TULIP_CMD_TXRUN | TULIP_CMD_RXRUN);
LMC_CSR_WRITE (sc, csr_command, sc->lmc_cmdmode);
- lmc_trace(dev, "lmc_runnin_reset_out");
+ lmc_trace(dev, "lmc_running_reset_out");
}
--
2.20.1
^ permalink raw reply related
* [vhost:linux-next 8/9] drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
From: kbuild test robot @ 2019-09-11 11:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kbuild-all, kvm, virtualization, netdev
[-- Attachment #1: Type: text/plain, Size: 8189 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next
head: f2c4b499aecc0c5a1ec67f3a2a7310cb7168a8ab
commit: 4c145987a955269da79312a79ec26638712644bb [8/9] vhost: block speculation of translated descriptors
config: mips-malta_kvm_defconfig (attached as .config)
compiler: mipsel-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
git checkout 4c145987a955269da79312a79ec26638712644bb
# 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 error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/eventfd.h:13,
from drivers/vhost/vhost.c:13:
drivers/vhost/vhost.c: In function 'translate_desc':
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
>> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
^~~~~~~~~~~~
>> drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \
^~~~~~~~~~~~
>> drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
--
In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/eventfd.h:13,
from drivers//vhost/vhost.c:13:
drivers//vhost/vhost.c: In function 'translate_desc':
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
>> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
^~~~~~~~~~~~
drivers//vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \
^~~~~~~~~~~~
drivers//vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
vim +/array_index_nospec +2076 drivers/vhost/vhost.c
2039
2040 static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
2041 struct iovec iov[], int iov_size, int access)
2042 {
2043 const struct vhost_umem_node *node;
2044 struct vhost_dev *dev = vq->dev;
2045 struct vhost_umem *umem = dev->iotlb ? dev->iotlb : dev->umem;
2046 struct iovec *_iov;
2047 u64 s = 0;
2048 int ret = 0;
2049
2050 while ((u64)len > s) {
2051 u64 size;
2052 if (unlikely(ret >= iov_size)) {
2053 ret = -ENOBUFS;
2054 break;
2055 }
2056
2057 node = vhost_umem_interval_tree_iter_first(&umem->umem_tree,
2058 addr, addr + len - 1);
2059 if (node == NULL || node->start > addr) {
2060 if (umem != dev->iotlb) {
2061 ret = -EFAULT;
2062 break;
2063 }
2064 ret = -EAGAIN;
2065 break;
2066 } else if (!(node->perm & access)) {
2067 ret = -EPERM;
2068 break;
2069 }
2070
2071 _iov = iov + ret;
2072 size = node->size - addr + node->start;
2073 _iov->iov_len = min((u64)len - s, size);
2074 _iov->iov_base = (void __user *)(unsigned long)
2075 (node->userspace_addr +
> 2076 array_index_nospec(addr - node->start,
2077 node->size));
2078 s += size;
2079 addr += size;
2080 ++ret;
2081 }
2082
2083 if (ret == -EAGAIN)
2084 vhost_iotlb_miss(vq, addr, access);
2085 return ret;
2086 }
2087
---
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: 20549 bytes --]
^ permalink raw reply
* [vhost:linux-next 16/17] include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
From: kbuild test robot @ 2019-09-11 11:38 UTC (permalink / raw)
To: Alexander Duyck
Cc: kbuild-all, kvm, virtualization, netdev, Michael S. Tsirkin
[-- Attachment #1: Type: text/plain, Size: 23931 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next
head: 39c226b6b576b23d6d558331e6895f02b0892555
commit: 990055c63121520ad29deca72b1167b392563ddd [16/17] virtio-balloon: Add support for providing unused page reports to host
config: riscv-allmodconfig (attached as .config)
compiler: riscv64-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
git checkout 990055c63121520ad29deca72b1167b392563ddd
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/radix-tree.h:14,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from drivers/scsi/snic/snic_attrs.c:19:
include/linux/page_reporting.h: In function '__del_page_from_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/page.h:24:22: note: each undeclared identifier is reported only once for each function it appears in
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'get_unreported_tail':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:77:15: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order >= PAGE_REPORTING_MIN_ORDER &&
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'add_page_to_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:99:31: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'page_reporting_notify_free':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:159:14: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order < PAGE_REPORTING_MIN_ORDER)
^~~~~~~~~~~~~~~~~~~~~~~~
--
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h: In function 'add_to_free_list_tail':
include/linux/mmzone.h:791:27: error: implicit declaration of function 'get_unreported_tail' [-Werror=implicit-function-declaration]
struct list_head *tail = get_unreported_tail(zone, order, migratetype);
^~~~~~~~~~~~~~~~~~~
include/linux/mmzone.h:791:27: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
include/linux/mmzone.h: In function 'move_to_free_list':
include/linux/mmzone.h:807:27: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
struct list_head *tail = get_unreported_tail(zone, order, migratetype);
^~~~~~~~~~~~~~~~~~~
include/linux/mmzone.h:815:3: error: implicit declaration of function 'move_page_to_reported_list'; did you mean 'move_to_free_list'? [-Werror=implicit-function-declaration]
move_page_to_reported_list(page, zone, migratetype);
^~~~~~~~~~~~~~~~~~~~~~~~~~
move_to_free_list
include/linux/mmzone.h: In function 'del_page_from_free_list':
include/linux/mmzone.h:831:3: error: implicit declaration of function 'del_page_from_reported_list'; did you mean 'del_page_from_free_list'? [-Werror=implicit-function-declaration]
del_page_from_reported_list(page, zone);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
del_page_from_free_list
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/page_reporting.h:5,
from <command-line>:0:
include/linux/page_reporting.h: In function '__del_page_from_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/page.h:24:22: note: each undeclared identifier is reported only once for each function it appears in
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
include/linux/page_reporting.h: At top level:
include/linux/page_reporting.h:74:1: error: conflicting types for 'get_unreported_tail'
get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
^~~~~~~~~~~~~~~~~~~
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h:791:27: note: previous implicit declaration of 'get_unreported_tail' was here
struct list_head *tail = get_unreported_tail(zone, order, migratetype);
^~~~~~~~~~~~~~~~~~~
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/page_reporting.h:5,
from <command-line>:0:
include/linux/page_reporting.h: In function 'get_unreported_tail':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:77:15: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order >= PAGE_REPORTING_MIN_ORDER &&
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'add_page_to_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:99:31: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
include/linux/page_reporting.h: At top level:
include/linux/page_reporting.h:106:20: warning: conflicting types for 'del_page_from_reported_list'
static inline void del_page_from_reported_list(struct page *page,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h:106:20: error: static declaration of 'del_page_from_reported_list' follows non-static declaration
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h:831:3: note: previous implicit declaration of 'del_page_from_reported_list' was here
del_page_from_reported_list(page, zone);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
include/linux/page_reporting.h:118:20: warning: conflicting types for 'move_page_to_reported_list'
static inline void move_page_to_reported_list(struct page *page,
^~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h:118:20: error: static declaration of 'move_page_to_reported_list' follows non-static declaration
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h:815:3: note: previous implicit declaration of 'move_page_to_reported_list' was here
move_page_to_reported_list(page, zone, migratetype);
^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/page_reporting.h:5,
from <command-line>:0:
include/linux/page_reporting.h: In function 'page_reporting_notify_free':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:159:14: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order < PAGE_REPORTING_MIN_ORDER)
^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/radix-tree.h:14,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from drivers/soundwire/slave.c:4:
include/linux/page_reporting.h: In function '__del_page_from_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/page.h:24:22: note: each undeclared identifier is reported only once for each function it appears in
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'get_unreported_tail':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:77:15: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order >= PAGE_REPORTING_MIN_ORDER &&
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'add_page_to_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:99:31: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'page_reporting_notify_free':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:159:14: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order < PAGE_REPORTING_MIN_ORDER)
^~~~~~~~~~~~~~~~~~~~~~~~
At top level:
drivers/soundwire/slave.c:16:12: warning: 'sdw_slave_add' defined but not used [-Wunused-function]
static int sdw_slave_add(struct sdw_bus *bus,
^~~~~~~~~~~~~
vim +/pageblock_order +9 include/linux/page_reporting.h
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 8
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 @9 #define PAGE_REPORTING_MIN_ORDER pageblock_order
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 10 #define PAGE_REPORTING_HWM 32
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 11
:::::: The code at line 9 was first introduced by commit
:::::: 50ed0c2ecb2e254a50e4ad775840f29d42cf6c00 mm: Introduce Reported pages
:::::: TO: Alexander Duyck <alexander.h.duyck@linux.intel.com>
:::::: CC: Michael S. Tsirkin <mst@redhat.com>
---
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: 59248 bytes --]
^ permalink raw reply
* Re: [PATCH] net/mlx5: Declare 'rt' as corresponding enum type
From: Austin Kim @ 2019-09-11 11:39 UTC (permalink / raw)
To: Saeed Mahameed
Cc: leon@kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Bloch, davem@davemloft.net,
netdev@vger.kernel.org, Alex Vesker, Erez Shitrit
In-Reply-To: <61418cb7514460e24bfcd431eee9c540e795fcbc.camel@mellanox.com>
It is good to hear that similar patch was submitted.
Thanks for notification.
Thanks,
Austin Kim
2019년 9월 11일 (수) 오전 2:59, Saeed Mahameed <saeedm@mellanox.com>님이 작성:
>
> On Tue, 2019-09-10 at 18:27 +0900, Austin Kim wrote:
> > When building kernel with clang, we can observe below warning
> > message:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1080:9:
> > warning: implicit conversion from enumeration type 'enum
> > mlx5_reformat_ctx_type'
> > to different enumeration type 'enum mlx5dr_action_type' [- Wenum-
> > conversion]
> > rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL;
> > ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1082:9:
> > warning: implicit conversion from enumeration type 'enum
> > mlx5_reformat_ctx_type'
> > to different enumeration type 'enum mlx5dr_action_type' [- Wenum-
> > conversion]
> > rt = MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL;
> > ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1084:51:
> > warning: implicit conversion from enumeration type 'enum
> > mlx5dr_action_type'
> > to different enumeration type 'enum mlx5_reformat_ctx_type'
> > [- Wenum-conversion]
> > ret = mlx5dr_cmd_create_reformat_ctx(dmn->mdev, rt, data_sz,
> > data,
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
> >
> > Declare 'rt' as corresponding enum mlx5_reformat_ctx_type type.
> >
> > Signed-off-by: Austin Kim <austindh.kim@gmail.com>
> Hi Austin, Thanks for the patch:
>
> We already have a similar patch queued for submission.
> https://patchwork.ozlabs.org/patch/1158175/
>
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > index a02f87f..7d81a77 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > @@ -1074,7 +1074,7 @@ dr_action_create_reformat_action(struct
> > mlx5dr_domain *dmn,
> > case DR_ACTION_TYP_L2_TO_TNL_L2:
> > case DR_ACTION_TYP_L2_TO_TNL_L3:
> > {
> > - enum mlx5dr_action_type rt;
> > + enum mlx5_reformat_ctx_type rt;
> >
> > if (action->action_type == DR_ACTION_TYP_L2_TO_TNL_L2)
> > rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL;
^ permalink raw reply
* Re: [PATCH net-next 01/11] net: aquantia: PTP skeleton declarations and callbacks
From: Igor Russkikh @ 2019-09-11 11:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, richardcochran@gmail.com,
davem@davemloft.net, Egor Pomozov, Sergey Samoilenko,
Dmitry Bezrukov
In-Reply-To: <20190910191029.GE9761@lunn.ch>
Hi Andrew,
>> + struct ptp_clock *clock;
>> + struct aq_ptp_s *self;
>
> I find the use of self in this code quite confusing. It does not
> appear to have a clear meaning. It can be a aq_ring_s, aq_nic_c,
> aq_hw_s, aq_vec_s.
>
> Looking at this code i always have to figure out what self is. Could
> you not just use struct aq_ptp_s aq_ptp consistently in the code?
Agreed,
>> +
>> + self = kzalloc(sizeof(*self), GFP_KERNEL);
>
> Using devm_kzalloc() will make your clean up easier.
>> +
>> + kfree(self);
>
> kfree() is happy to take a NULL pointer. But this could all go away
> with devm_kzalloc().
You are probably right, that'll be easier,
>> +static int hw_atl_b0_adj_sys_clock(struct aq_hw_s *self, s64 delta)
>> +{
>> + ptp_clk_offset += delta;
>> +
>> + return 0;
>> +}
>
> Does this work when i have a box with 42 NICs in it? Does not each NIC
> need its own clock offset? Just seeing code like this causes alarm
> bells. So if it is correct, i would expect some sort of comment to
> prevent those alarm bells.
No comment is needed, that is obviously a per-device variable,
Thanks for catching this!
Will fix that, as well as kbuild robot discovered issues.
Regards,
Igor
^ permalink raw reply
* [PATCH net-next 0/2] qed* Fix series.
From: Sudarsana Reddy Kalluru @ 2019-09-11 11:42 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
The patch series addresses couple of issues in the recent commits.
Patch (1) populates the actual dump-size of config attribute instead of
providing a fixed size value.
Patch(2) updates frame format of flash config buffer as required by
management FW (MFW).
Please consider applying it to net-next.
Sudarsana Reddy Kalluru (2):
qed*: Fix size of config attribute dump.
qed: Fix Config attribute frame format.
drivers/net/ethernet/qlogic/qed/qed_main.c | 47 +++++++++++++++++++------
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 14 ++++----
include/linux/qed/qed_if.h | 8 +++++
3 files changed, 53 insertions(+), 16 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 1/2] qed*: Fix size of config attribute dump.
From: Sudarsana Reddy Kalluru @ 2019-09-11 11:42 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190911114251.7013-1-skalluru@marvell.com>
Driver currently returns max-buf-size as size of the config attribute.
This patch incorporates changes to read this value from MFW (if available)
and provide it to the user. Also did a trivial clean up in this path.
Fixes: d44a3ced7023 ("qede: Add support for reading the config id attributes.")
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 26 +++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 14 +++++++------
include/linux/qed/qed_if.h | 8 ++++++++
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index ac1511a8..38c0ec3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -2300,6 +2300,31 @@ static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
return rc;
}
+#define QED_MAX_NVM_BUF_LEN 32
+static int qed_nvm_flash_cfg_len(struct qed_dev *cdev, u32 cmd)
+{
+ struct qed_hwfn *hwfn = QED_LEADING_HWFN(cdev);
+ u8 buf[QED_MAX_NVM_BUF_LEN];
+ struct qed_ptt *ptt;
+ u32 len;
+ int rc;
+
+ ptt = qed_ptt_acquire(hwfn);
+ if (!ptt)
+ return QED_MAX_NVM_BUF_LEN;
+
+ rc = qed_mcp_nvm_get_cfg(hwfn, ptt, cmd, 0, QED_NVM_CFG_GET_FLAGS, buf,
+ &len);
+ if (rc || !len) {
+ DP_ERR(cdev, "Error %d reading %d\n", rc, cmd);
+ len = QED_MAX_NVM_BUF_LEN;
+ }
+
+ qed_ptt_release(hwfn, ptt);
+
+ return len;
+}
+
static int qed_nvm_flash_cfg_read(struct qed_dev *cdev, u8 **data,
u32 cmd, u32 entity_id)
{
@@ -2657,6 +2682,7 @@ static u8 qed_get_affin_hwfn_idx(struct qed_dev *cdev)
.read_module_eeprom = &qed_read_module_eeprom,
.get_affin_hwfn_idx = &qed_get_affin_hwfn_idx,
.read_nvm_cfg = &qed_nvm_flash_cfg_read,
+ .read_nvm_cfg_len = &qed_nvm_flash_cfg_len,
.set_grc_config = &qed_set_grc_config,
};
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index ec27a43..8a426af 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -49,7 +49,6 @@
#define QEDE_SELFTEST_POLL_COUNT 100
#define QEDE_DUMP_VERSION 0x1
-#define QEDE_DUMP_NVM_BUF_LEN 32
#define QEDE_DUMP_NVM_ARG_COUNT 2
static const struct {
@@ -2026,7 +2025,8 @@ static int qede_get_dump_flag(struct net_device *dev,
switch (edev->dump_info.cmd) {
case QEDE_DUMP_CMD_NVM_CFG:
dump->flag = QEDE_DUMP_CMD_NVM_CFG;
- dump->len = QEDE_DUMP_NVM_BUF_LEN;
+ dump->len = edev->ops->common->read_nvm_cfg_len(edev->cdev,
+ edev->dump_info.args[0]);
break;
case QEDE_DUMP_CMD_GRCDUMP:
dump->flag = QEDE_DUMP_CMD_GRCDUMP;
@@ -2051,9 +2051,8 @@ static int qede_get_dump_data(struct net_device *dev,
if (!edev->ops || !edev->ops->common) {
DP_ERR(edev, "Edev ops not populated\n");
- edev->dump_info.cmd = QEDE_DUMP_CMD_NONE;
- edev->dump_info.num_args = 0;
- return -EINVAL;
+ rc = -EINVAL;
+ goto err;
}
switch (edev->dump_info.cmd) {
@@ -2062,7 +2061,8 @@ static int qede_get_dump_data(struct net_device *dev,
DP_ERR(edev, "Arg count = %d required = %d\n",
edev->dump_info.num_args,
QEDE_DUMP_NVM_ARG_COUNT);
- return -EINVAL;
+ rc = -EINVAL;
+ goto err;
}
rc = edev->ops->common->read_nvm_cfg(edev->cdev, (u8 **)&buf,
edev->dump_info.args[0],
@@ -2078,8 +2078,10 @@ static int qede_get_dump_data(struct net_device *dev,
break;
}
+err:
edev->dump_info.cmd = QEDE_DUMP_CMD_NONE;
edev->dump_info.num_args = 0;
+ memset(edev->dump_info.args, 0, sizeof(edev->dump_info.args));
return rc;
}
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index e354638..b5db1ee 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -1143,6 +1143,14 @@ struct qed_common_ops {
*/
int (*read_nvm_cfg)(struct qed_dev *cdev, u8 **buf, u32 cmd,
u32 entity_id);
+/**
+ * @brief read_nvm_cfg - Read NVM config attribute value.
+ * @param cdev
+ * @param cmd - NVM CFG command id
+ *
+ * @return config id length, 0 on error.
+ */
+ int (*read_nvm_cfg_len)(struct qed_dev *cdev, u32 cmd);
/**
* @brief set_grc_config - Configure value for grc config id.
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/2] qed: Fix Config attribute frame format.
From: Sudarsana Reddy Kalluru @ 2019-09-11 11:42 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190911114251.7013-1-skalluru@marvell.com>
MFW associates the entity id to a config attribute instead of assigning
one entity id for all the config attributes.
This patch incorporates driver changes to link entity id to a config id
attribute.
Fixes: 0dabbe1bb3a4 ("qed: Add driver API for flashing the config attributes.")
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 38c0ec3..2ce7009 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -2240,12 +2240,13 @@ static int qed_nvm_flash_image_validate(struct qed_dev *cdev,
/* Binary file format -
* /----------------------------------------------------------------------\
* 0B | 0x5 [command index] |
- * 4B | Entity ID | Reserved | Number of config attributes |
- * 8B | Config ID | Length | Value |
+ * 4B | Number of config attributes | Reserved |
+ * 4B | Config ID | Entity ID | Length |
+ * 4B | Value |
* | |
* \----------------------------------------------------------------------/
- * There can be several cfg_id-Length-Value sets as specified by 'Number of...'.
- * Entity ID - A non zero entity value for which the config need to be updated.
+ * There can be several cfg_id-entity_id-Length-Value sets as specified by
+ * 'Number of config attributes'.
*
* The API parses config attributes from the user provided buffer and flashes
* them to the respective NVM path using Management FW inerface.
@@ -2265,18 +2266,17 @@ static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
/* NVM CFG ID attribute header */
*data += 4;
- entity_id = **data;
- *data += 2;
count = *((u16 *)*data);
- *data += 2;
+ *data += 4;
DP_VERBOSE(cdev, NETIF_MSG_DRV,
- "Read config ids: entity id %02x num _attrs = %0d\n",
- entity_id, count);
+ "Read config ids: num_attrs = %0d\n", count);
/* NVM CFG ID attributes */
for (i = 0; i < count; i++) {
cfg_id = *((u16 *)*data);
*data += 2;
+ entity_id = **data;
+ (*data)++;
len = **data;
(*data)++;
memcpy(buf, *data, len);
@@ -2286,7 +2286,8 @@ static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
QED_NVM_CFG_SET_FLAGS;
DP_VERBOSE(cdev, NETIF_MSG_DRV,
- "cfg_id = %d len = %d\n", cfg_id, len);
+ "cfg_id = %d entity = %d len = %d\n", cfg_id,
+ entity_id, len);
rc = qed_mcp_nvm_set_cfg(hwfn, ptt, cfg_id, entity_id, flags,
buf, len);
if (rc) {
--
1.8.3.1
^ permalink raw reply related
* 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
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