Tree/Branch: v4.15.4
Git describe: v4.15.4
Commit: bb61956d9d Linux 4.15.4
Build Time: 112 min 28 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
1 ../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: v4.14.20
Git describe: v4.14.20
Commit: 7e83b2ff48 Linux 4.14.20
Build Time: 109 min 30 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
1 ../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Hi Ingo,
Here is a small pile of cleanups and fixes for nospec.h after inspection
from Linus, Rasmus, and Christian. Full changelogs below:
These have received a build success notification from 0day across 126
configs.
---
Dan Williams (2):
nospec: Kill array_index_nospec_mask_check()
nospec: Include asm/barrier.h dependency
Rasmus Villemoes (1):
nospec: Allow index argument to have const-qualified type
include/linux/nospec.h | 26 +++-----------------------
1 file changed, 3 insertions(+), 23 deletions(-)
--
nospec: Kill array_index_nospec_mask_check()
There are multiple problems with the dynamic sanity checking in
array_index_nospec_mask_check():
* It causes unnecessary overhead in the 32-bit case since integer sized
@index values will no longer cause the check to be compiled away like
in the 64-bit case.
* In the 32-bit case it may trigger with user controllable input when
the expectation is that should only trigger during development of new
kernel enabling.
* The macro reuses the input parameter in multiple locations which is
broken if someone passes an expression like 'index++' to
array_index_nospec().
nospec: Allow index argument to have const-qualified type
The last expression in a statement expression need not be a bare
variable, quoting gcc docs
The last thing in the compound statement should be an expression
followed by a semicolon; the value of this subexpression serves as the
value of the entire construct.
and we already use that in e.g. the min/max macros which end with a
ternary expression.
This way, we can allow index to have const-qualified type, which will in
some cases avoid the need for introducing a local copy of index of
non-const qualified type. That, in turn, can prevent readers not
familiar with the internals of array_index_nospec from wondering about
the seemingly redundant extra variable, and I think that's worthwhile
considering how confusing the whole _nospec business is.
The expression _i&_mask has type unsigned long (since that is the type
of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to
that), so in order not to change the type of the whole expression, add
a cast back to typeof(_i).
nospec: Include asm/barrier.h dependency
The nospec.h header expects the per-architecture header file
asm/barrier.h to optionally define array_index_mask_nospec(). Include
that dependency to prevent inadvertent fallback to the default
array_index_mask_nospec() implementation. The default implementation may
not provide a full mitigation on architectures that perform data value
speculation.
The patch titled
Subject: mm: don't defer struct page initialization for Xen pv guests
has been added to the -mm tree. Its filename is
mm-dont-defer-struct-page-initialization-for-xen-pv-guests.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-dont-defer-struct-page-initiali…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-dont-defer-struct-page-initiali…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Juergen Gross <jgross(a)suse.com>
Subject: mm: don't defer struct page initialization for Xen pv guests
f7f99100d8d95d ("mm: stop zeroing memory during allocation in vmemmap")
broke Xen pv domains in some configurations, as the "Pinned" information
in struct page of early page tables could get lost. This will lead to the
kernel trying to write directly into the page tables instead of asking the
hypervisor to do so. The result is a crash like the following:
[ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008
[ 0.004000] IP: xen_set_pud+0x4e/0xd0
[ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065
[ 0.004000] Oops: 0003 [#1] PREEMPT SMP
[ 0.004000] Modules linked in:
[ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ #271
[ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014
[ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000
[ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0
[ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246
[ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000
[ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008
[ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80
[ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067
[ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000
[ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000
[ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660
[ 0.004000] Call Trace:
[ 0.004000] __pmd_alloc+0x128/0x140
[ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0
[ 0.004000] ioremap_page_range+0x3f4/0x410
[ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0
[ 0.004000] __ioremap_caller+0x1c3/0x2e0
[ 0.004000] acpi_os_map_iomem+0x175/0x1b0
[ 0.004000] acpi_tb_acquire_table+0x39/0x66
[ 0.004000] acpi_tb_validate_table+0x44/0x7c
[ 0.004000] acpi_tb_verify_temp_table+0x45/0x304
[ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2
[ 0.004000] acpi_reallocate_root_table+0x12d/0x141
[ 0.004000] acpi_early_init+0x4d/0x10a
[ 0.004000] start_kernel+0x3eb/0x4a1
[ 0.004000] ? set_init_arg+0x55/0x55
[ 0.004000] xen_start_kernel+0x528/0x532
[ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3
[ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8
[ 0.004000] CR2: ffff8801ead19008
[ 0.004000] ---[ end trace 38eca2e56f1b642e ]---
Avoid this problem by not deferring struct page initialization when
running as Xen pv guest.
Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com
Fixes: f7f99100d8d95d ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Steven Sistare <steven.sistare(a)oracle.com>
Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com>
Cc: Bob Picco <bob.picco(a)oracle.com>
Cc: <stable(a)vger.kernel.org> [4.15.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests mm/page_alloc.c
--- a/mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests
+++ a/mm/page_alloc.c
@@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_
/* Always populate low zones for address-constrained allocations */
if (zone_end < pgdat_end_pfn(pgdat))
return true;
+ /* Xen PV domains need page structures early */
+ if (xen_pv_domain())
+ return true;
(*nr_initialised)++;
if ((*nr_initialised > pgdat->static_init_pgcnt) &&
(pfn & (PAGES_PER_SECTION - 1)) == 0) {
_
Patches currently in -mm which might be from jgross(a)suse.com are
mm-dont-defer-struct-page-initialization-for-xen-pv-guests.patch
From: Casey Leedom <leedom(a)chelsio.com>
We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help. The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.
The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.
The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor. Thus PF4 can
be exported to a Virtual Machine and everything should work.
Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc: <stable(a)vger.kernel.org> # v4.9+
Signed-off-by: Casey Leedom <leedom(a)chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 --------
drivers/pci/quirks.c | 39 ++++++++++++++++++------------
2 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 047609e..920bccd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2637,7 +2637,6 @@ void t4_get_regs(struct adapter *adap, void *buf, size_t buf_size)
}
#define EEPROM_STAT_ADDR 0x7bfc
-#define VPD_SIZE 0x800
#define VPD_BASE 0x400
#define VPD_BASE_OLD 0
#define VPD_LEN 1024
@@ -2704,15 +2703,6 @@ int t4_get_raw_vpd_params(struct adapter *adapter, struct vpd_params *p)
if (!vpd)
return -ENOMEM;
- /* We have two VPD data structures stored in the adapter VPD area.
- * By default, Linux calculates the size of the VPD area by traversing
- * the first VPD area at offset 0x0, so we need to tell the OS what
- * our real VPD size is.
- */
- ret = pci_set_vpd_size(adapter->pdev, VPD_SIZE);
- if (ret < 0)
- goto out;
-
/* Card information normally starts at VPD_BASE but early cards had
* it at 0.
*/
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index fc73401..8b14bd3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3419,22 +3419,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
{
- pci_set_vpd_size(dev, 8192);
-}
-
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+ int chip = (dev->device & 0xf000) >> 12;
+ int func = (dev->device & 0x0f00) >> 8;
+ int prod = (dev->device & 0x00ff) >> 0;
+
+ /*
+ * If this is a T3-based adapter, there's a 1KB VPD area at offset
+ * 0xc00 which contains the preferred VPD values. If this is a T4 or
+ * later based adapter, the special VPD is at offset 0x400 for the
+ * Physical Functions (the SR-IOV Virtual Functions have no VPD
+ * Capabilities). The PCI VPD Access core routines will normally
+ * compute the size of the VPD by parsing the VPD Data Structure at
+ * offset 0x000. This will result in silent failures when attempting
+ * to accesses these other VPD areas which are beyond those computed
+ * limits.
+ */
+ if (chip == 0x0 && prod >= 0x20)
+ pci_set_vpd_size(dev, 8192);
+ else if (chip >= 0x4 && func < 0x8)
+ pci_set_vpd_size(dev, 2048);
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+ quirk_chelsio_extend_vpd);
#ifdef CONFIG_ACPI
/*
--
2.1.0