[PATCH 1/9] drm/nouveau/kms: Handle -EINPROGRESS in nouveau_connector_hotplug()
Looks like that we forgot to handle -EINPROGRESS being returned by
pm_runtime_get(), which can happen if multiple callers try to
asynchronously resume the GPU before it wakes up. This is perfectly
normal and OK, so fix this by treating -EINPROGRESS as success.
Signed-off-by: Lyude Paul
Fixes: 3e1a12754d4d ("drm/nouveau: Fix deadlocks in nouveau_connector_detect()")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7674025a4bfe8..38e226b8cfd05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1173,7 +1173,7 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
}
ret = pm_runtime_get(drm->dev->dev);
- if (ret == 0) {
+ if (ret == 0 || ret == -EINPROGRESS) {
/* We can't block here if there's a pending PM request
* running, as we'll deadlock nouveau_display_fini() when it
* calls nvif_put() on our nvif_notify struct. So, simply
--
2.26.2
[PATCH 5/9] drm/nouveau/kms/fbcon: Use pm_runtime_put_autosuspend() in suspend work
While I don't know of any problems this has caused, it's definitely not
a great idea for us to potentially block in
nouveau_fbcon_set_suspend_work(). We don't really need to anyway, and
want to simply trigger the autosuspend timer instead.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index b936bf1c14dec..2234f012ca0c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -468,7 +468,7 @@ nouveau_fbcon_set_suspend_work(struct work_struct *work)
if (state == FBINFO_STATE_RUNNING) {
nouveau_fbcon_hotplug_resume(drm->fbcon);
pm_runtime_mark_last_busy(drm->dev->dev);
- pm_runtime_put_sync(drm->dev->dev);
+ pm_runtime_put_autosuspend(drm->dev->dev);
}
}
--
2.26.2
[PATCH 2/9] drm/nouveau/kms: Fix rpm leak in nouveau_connector_hotplug()
Found another one, we forget to drop the runtime PM reference we grab
here in the event of a failure. So, do that.
Signed-off-by: Lyude Paul
Fixes: 3e1a12754d4d ("drm/nouveau: Fix deadlocks in nouveau_connector_detect()")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 38e226b8cfd05..ab35153e31b72 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1188,6 +1188,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
} else if (ret != 1 && ret != -EACCES) {
NV_WARN(drm, "HPD on %s dropped due to RPM failure: %d\n",
name, ret);
+
+ pm_runtime_mark_last_busy(drm->dev->dev);
+ pm_runtime_put_autosuspend(drm->dev->dev);
return NVIF_NOTIFY_DROP;
}
--
2.26.2
[PATCH V5 3/3] platform/x86: Intel PMT Telemetry capability driver
PMT Telemetry is a capability of the Intel Platform Monitoring Technology. The Telemetry capability provides access to device telemetry metrics that provide hardware performance data to users from continuous, memory mapped, read-only register spaces. Register mappings are not provided by the driver. Instead, a GUID is read from a header for each endpoint. The GUID identifies the device and is to be used with an XML, provided by the vendor, to discover the available set of metrics and their register mapping. This allows firmware updates to modify the register space without needing to update the driver every time with new mappings. Firmware writes a new GUID in this case to specify the new mapping. Software tools with access to the associated XML file can then interpret the changes. The module manages access to all PMT Telemetry endpoints on a system, independent of the device exporting them. It creates a pmt_telemetry class to manage the devices. For each telemetry endpoint, sysfs files provide GUID and size information as well as a pointer to the parent device the telemetry came from. Software may discover the association between endpoints and devices by iterating through the list in sysfs, or by looking for the existence of the class folder under the device of interest. A device node of the same name allows software to then map the telemetry space for direct access. Also create a PCI device id list for early telemetry hardware that require workarounds for known issues. Co-developed-by: Alexander Duyck Signed-off-by: Alexander Duyck Signed-off-by: David E. Box Reviewed-by: Andy Shevchenko --- .../ABI/testing/sysfs-class-pmt_telemetry | 46 ++ MAINTAINERS | 1 + drivers/platform/x86/Kconfig | 10 + drivers/platform/x86/Makefile | 1 + drivers/platform/x86/intel_pmt_telemetry.c| 448 ++ 5 files changed, 506 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-pmt_telemetry create mode 100644 drivers/platform/x86/intel_pmt_telemetry.c diff --git a/Documentation/ABI/testing/sysfs-class-pmt_telemetry b/Documentation/ABI/testing/sysfs-class-pmt_telemetry new file mode 100644 index ..b0b096db9cae --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-pmt_telemetry @@ -0,0 +1,46 @@ +What: /sys/class/pmt_telemetry/ +Date: July 2020 +KernelVersion: 5.9 +Contact: David Box +Description: + The pmt_telemetry/ class directory contains information for + devices that expose hardware telemetry using Intel Platform + Monitoring Technology (PMT) + +What: /sys/class/pmt_telemetry/telem +Date: July 2020 +KernelVersion: 5.9 +Contact: David Box +Description: + The telem directory contains files describing an instance of + a PMT telemetry device that exposes hardware telemetry. Each + telem directory has an associated /dev/telem node. This + node may be opened and mapped to access the telemetry space of + the device. The register layout of the telemetry space is + determined from an XML file that matches the PCI device id and + GUID for the device. + +What: /sys/class/pmt_telemetry/telem/guid +Date: July 2020 +KernelVersion: 5.9 +Contact: David Box +Description: + (RO) The GUID for this telemetry device. The GUID identifies + the version of the XML file for the parent device that is to + be used to get the register layout. + +What: /sys/class/pmt_telemetry/telem/size +Date: July 2020 +KernelVersion: 5.9 +Contact: David Box +Description: + (RO) The size of telemetry region in bytes that corresponds to + the mapping size for the /dev/telem device node. + +What: /sys/class/pmt_telemetry/telem/offset +Date: July 2020 +KernelVersion: 5.9 +Contact: David Box +Description: + (RO) The offset of telemetry region in bytes that corresponds to + the mapping for the /dev/telem device node. diff --git a/MAINTAINERS b/MAINTAINERS index b69429c70330..40794cc721af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8849,6 +8849,7 @@ INTEL PMT DRIVER M: "David E. Box" S: Maintained F: drivers/mfd/intel_pmt.c +F: drivers/platform/x86/intel_pmt_* INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT M: Stanislav Yakovlev diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 0581a54cf562..8552b094d005 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -1339,6 +1339,16 @@ config INTEL_PMC_CORE - LTR Ignore - MPHY/PLL gating status (Sunrisepoint PCH only) +config INTEL_PMT_TELEMETRY + tristate "Intel Platform Monitoring
[PATCH V5 2/3] mfd: Intel Platform Monitoring Technology support
Intel Platform Monitoring Technology (PMT) is an architecture for
enumerating and accessing hardware monitoring facilities. PMT supports
multiple types of monitoring capabilities. This driver creates platform
devices for each type so that they may be managed by capability specific
drivers (to be introduced). Capabilities are discovered using PCIe DVSEC
ids. Support is included for the 3 current capability types, Telemetry,
Watcher, and Crashlog. The features are available on new Intel platforms
starting from Tiger Lake for which support is added.
Also add a quirk mechanism for several early hardware differences and bugs.
For Tiger Lake, do not support Watcher and Crashlog capabilities since they
will not be compatible with future product. Also, fix use a quirk to fix
the discovery table offset.
Co-developed-by: Alexander Duyck
Signed-off-by: Alexander Duyck
Signed-off-by: David E. Box
Reviewed-by: Andy Shevchenko
---
MAINTAINERS | 5 +
drivers/mfd/Kconfig | 10 ++
drivers/mfd/Makefile| 1 +
drivers/mfd/intel_pmt.c | 220
4 files changed, 236 insertions(+)
create mode 100644 drivers/mfd/intel_pmt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f0569cf304ca..b69429c70330 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8845,6 +8845,11 @@ F: drivers/mfd/intel_soc_pmic*
F: include/linux/mfd/intel_msic.h
F: include/linux/mfd/intel_soc_pmic*
+INTEL PMT DRIVER
+M: "David E. Box"
+S: Maintained
+F: drivers/mfd/intel_pmt.c
+
INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
M: Stanislav Yakovlev
L: linux-wirel...@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index a37d7d171382..5dd05f1b8ce5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -670,6 +670,16 @@ config MFD_INTEL_PMC_BXT
Register and P-unit access. In addition this creates devices
for iTCO watchdog and telemetry that are part of the PMC.
+config MFD_INTEL_PMT
+ tristate "Intel Platform Monitoring Technology (PMT) support"
+ depends on PCI
+ select MFD_CORE
+ help
+ The Intel Platform Monitoring Technology (PMT) is an interface that
+ provides access to hardware monitor registers. This driver supports
+ Telemetry, Watcher, and Crashlog PMT capabilities/devices for
+ platforms starting from Tiger Lake.
+
config MFD_IPAQ_MICRO
bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
depends on SA1100_H3100 || SA1100_H3600
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9367a92f795a..1961b4737985 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -216,6 +216,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS_PCI)+= intel-lpss-pci.o
obj-$(CONFIG_MFD_INTEL_LPSS_ACPI) += intel-lpss-acpi.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
obj-$(CONFIG_MFD_INTEL_PMC_BXT)+= intel_pmc_bxt.o
+obj-$(CONFIG_MFD_INTEL_PMT)+= intel_pmt.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
new file mode 100644
index ..0e572b105101
--- /dev/null
+++ b/drivers/mfd/intel_pmt.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Platform Monitoring Technology PMT driver
+ *
+ * Copyright (c) 2020, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Author: David E. Box
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Intel DVSEC capability vendor space offsets */
+#define INTEL_DVSEC_ENTRIES0xA
+#define INTEL_DVSEC_SIZE 0xB
+#define INTEL_DVSEC_TABLE 0xC
+#define INTEL_DVSEC_TABLE_BAR(x) ((x) & GENMASK(2, 0))
+#define INTEL_DVSEC_TABLE_OFFSET(x)((x) & GENMASK(31, 3))
+#define INTEL_DVSEC_ENTRY_SIZE 4
+
+/* PMT capabilities */
+#define DVSEC_INTEL_ID_TELEMETRY 2
+#define DVSEC_INTEL_ID_WATCHER 3
+#define DVSEC_INTEL_ID_CRASHLOG4
+
+struct intel_dvsec_header {
+ u16 length;
+ u16 id;
+ u8 num_entries;
+ u8 entry_size;
+ u8 tbir;
+ u32 offset;
+};
+
+enum pmt_quirks {
+ /* Watcher capability not supported */
+ PMT_QUIRK_NO_WATCHER= BIT(0),
+
+ /* Crashlog capability not supported */
+ PMT_QUIRK_NO_CRASHLOG = BIT(1),
+
+ /* Use shift instead of mask to read discovery table offset */
+ PMT_QUIRK_TABLE_SHIFT = BIT(2),
+};
+
+struct pmt_platform_info {
+ unsigned long quirks;
+};
+
+static const struct pmt_platform_info tgl_info = {
+ .quirks = PMT_QUIRK_NO_WATCHER | PMT_QUIRK_NO_CRASHLOG |
+ PMT_QUIRK_TABLE_SHIFT,
+};
+
+static int pmt_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
+
[PATCH V5 1/3] PCI: Add defines for Designated Vendor-Specific Extended Capability
Add PCIe Designated Vendor-Specific Extended Capability (DVSEC) and defines for the header offsets. Defined in PCIe r5.0, sec 7.9.6. Signed-off-by: David E. Box Acked-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko --- include/uapi/linux/pci_regs.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index f9701410d3b5..beafeee39e44 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -720,6 +720,7 @@ #define PCI_EXT_CAP_ID_DPC 0x1D/* Downstream Port Containment */ #define PCI_EXT_CAP_ID_L1SS0x1E/* L1 PM Substates */ #define PCI_EXT_CAP_ID_PTM 0x1F/* Precision Time Measurement */ +#define PCI_EXT_CAP_ID_DVSEC 0x23/* Designated Vendor-Specific */ #define PCI_EXT_CAP_ID_DLF 0x25/* Data Link Feature */ #define PCI_EXT_CAP_ID_PL_16GT 0x26/* Physical Layer 16.0 GT/s */ #define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL_16GT @@ -1062,6 +1063,10 @@ #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE0xe000 /* LTR_L1.2_THRESHOLD_Scale */ #define PCI_L1SS_CTL2 0x0c/* Control 2 Register */ +/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */ +#define PCI_DVSEC_HEADER1 0x4 /* Designated Vendor-Specific Header1 */ +#define PCI_DVSEC_HEADER2 0x8 /* Designated Vendor-Specific Header2 */ + /* Data Link Feature */ #define PCI_DLF_CAP0x04/* Capabilities Register */ #define PCI_DLF_EXCHANGE_ENABLE 0x8000 /* Data Link Feature Exchange Enable */ -- 2.20.1
[PATCH V5 0/3] Intel Platform Monitoring Technology
Intel Platform Monitoring Technology (PMT) is an architecture for enumerating and accessing hardware monitoring capabilities on a device. With customers increasingly asking for hardware telemetry, engineers not only have to figure out how to measure and collect data, but also how to deliver it and make it discoverable. The latter may be through some device specific method requiring device specific tools to collect the data. This in turn requires customers to manage a suite of different tools in order to collect the differing assortment of monitoring data on their systems. Even when such information can be provided in kernel drivers, they may require constant maintenance to update register mappings as they change with firmware updates and new versions of hardware. PMT provides a solution for discovering and reading telemetry from a device through a hardware agnostic framework that allows for updates to systems without requiring patches to the kernel or software tools. PMT defines several capabilities to support collecting monitoring data from hardware. All are discoverable as separate instances of the PCIE Designated Vendor extended capability (DVSEC) with the Intel vendor code. The DVSEC ID field uniquely identifies the capability. Each DVSEC also provides a BAR offset to a header that defines capability-specific attributes, including GUID, feature type, offset and length, as well as configuration settings where applicable. The GUID uniquely identifies the register space of any monitor data exposed by the capability. The GUID is associated with an XML file from the vendor that describes the mapping of the register space along with properties of the monitor data. This allows vendors to perform firmware updates that can change the mapping (e.g. add new metrics) without requiring any changes to drivers or software tools. The new mapping is confirmed by an updated GUID, read from the hardware, which software uses with a new XML. The current capabilities defined by PMT are Telemetry, Watcher, and Crashlog. The Telemetry capability provides access to a continuous block of read only data. The Watcher capability provides access to hardware sampling and tracing features. Crashlog provides access to device crash dumps. While there is some relationship between capabilities (Watcher can be configured to sample from the Telemetry data set) each exists as stand alone features with no dependency on any other. The design therefore splits them into individual, capability specific drivers. MFD is used to create platform devices for each capability so that they may be managed by their own driver. The PMT architecture is (for the most part) agnostic to the type of device it can collect from. Devices nodes are consequently generic in naming, e.g. /dev/telem and /dev/smplr. Each capability driver creates a class to manage the list of devices supporting it. Software can determine which devices support a PMT feature by searching through each device node entry in the sysfs class folder. It can additionally determine if a particular device supports a PMT feature by checking for a PMT class folder in the device folder. This patch set provides support for the PMT framework, along with support for Telemetry on Tiger Lake. Changes from V4: - Replace MFD with PMT in driver title - Fix commit tags in chronological order - Fix includes in alphabetical order - Use 'raw' string instead of defines for device names - Add an error message when returning an error code for unrecognized capability id - Use dev_err instead of dev_warn for messages when returning an error - Change while loop to call pci_find_next_ext_capability once - Add missing continue in while loop - Keep PCI platform defines using PCI_DEVICE_DATA magic tied to the pci_device_id table - Comment and kernel message cleanup Changes from V3: - Write out full acronym for DVSEC in PCI patch commit message and add 'Designated' to comments - remove unused variable caught by kernel test robot - Add required Co-developed-by signoffs, noted by Andy - Allow access using new CAP_PERFMON capability as suggested by Alexey Bundankov - Fix spacing in Kconfig, noted by Randy - Other style changes and fixups suggested by Andy Changes from V2: - In order to handle certain HW bugs from the telemetry capability driver, create a single platform device per capability instead of a device per entry. Add the entry data as device resources and let the capability driver manage them as a set allowing for cleaner HW bug resolution. - Handle discovery table offset bug in intel_pmt.c - Handle overlapping regions in intel_pmt_telemetry.c - Add description of sysfs class to testing ABI. - Don't check size and count until confirming support for the
kernel BUG at arch/x86/mm/physaddr.c:LINE! (6)
Hello, syzbot found the following issue on: HEAD commit:23ee3e4e Merge tag 'pci-v5.8-fixes-2' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c45f7890 kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 dashboard link: https://syzkaller.appspot.com/bug?extid=dfb45ba0aafa4329fd19 compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+dfb45ba0aafa4329f...@syzkaller.appspotmail.com [ cut here ] kernel BUG at arch/x86/mm/physaddr.c:28! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 15249 Comm: syz-executor.4 Not tainted 5.8.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__phys_addr+0xa7/0x110 arch/x86/mm/physaddr.c:28 Code: 61 7a 09 4c 89 e3 31 ff 48 d3 eb 48 89 de e8 90 60 3f 00 48 85 db 75 0d e8 e6 63 3f 00 4c 89 e0 5b 5d 41 5c c3 e8 d9 63 3f 00 <0f> 0b e8 d2 63 3f 00 48 c7 c0 10 10 a8 89 48 ba 00 00 00 00 00 fc RSP: 0018:c90015be7c18 EFLAGS: 00010216 RAX: 3629 RBX: 00077000 RCX: c900116ea000 RDX: 0004 RSI: 813458b7 RDI: 0006 RBP: 80077000 R08: R09: R10: 80077000 R11: R12: 77877000 R13: c90015be7c70 R14: R15: 0286 FS: () GS:8880ae70(0063) knlGS:f5db6b40 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 55bcdd3fe588 CR3: 70105000 CR4: 001426e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: virt_to_head_page include/linux/mm.h:841 [inline] qlink_to_cache mm/kasan/quarantine.c:128 [inline] qlist_free_all+0xbb/0x140 mm/kasan/quarantine.c:164 quarantine_reduce+0x17e/0x200 mm/kasan/quarantine.c:260 __kasan_kmalloc.constprop.0+0x9e/0xd0 mm/kasan/common.c:475 slab_post_alloc_hook mm/slab.h:586 [inline] slab_alloc mm/slab.c:3320 [inline] kmem_cache_alloc+0x12c/0x3b0 mm/slab.c:3484 __d_alloc+0x2a/0x920 fs/dcache.c:1709 d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838 alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226 sock_alloc_file+0x4f/0x190 net/socket.c:411 sock_map_fd net/socket.c:435 [inline] __sys_socket+0x13d/0x200 net/socket.c:1525 __do_sys_socket net/socket.c:1530 [inline] __se_sys_socket net/socket.c:1528 [inline] __ia32_sys_socket+0x6f/0xb0 net/socket.c:1528 do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428 __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline] do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7fbb569 Code: Bad RIP value. RSP: 002b:f5db60cc EFLAGS: 0296 ORIG_RAX: 0167 RAX: ffda RBX: 000a RCX: 0001 RDX: RSI: RDI: RBP: R08: R09: R10: R11: R12: R13: R14: R15: Modules linked in: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
RE: [PATCH v3 05/11] KVM: SVM: Modify 64 bit intercept field to two 32 bit vectors
> -Original Message-
> From: Jim Mattson
> Sent: Wednesday, July 29, 2020 4:06 PM
> To: Moger, Babu
> Cc: Paolo Bonzini ; Vitaly Kuznetsov
> ; Wanpeng Li ; Sean
> Christopherson ; kvm list
> ; Joerg Roedel ; the arch/x86
> maintainers ; LKML ; Ingo
> Molnar ; Borislav Petkov ; H . Peter Anvin
> ; Thomas Gleixner
> Subject: Re: [PATCH v3 05/11] KVM: SVM: Modify 64 bit intercept field to two
> 32
> bit vectors
>
> On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote:
> >
> > Convert all the intercepts to one array of 32 bit vectors in
> > vmcb_control_area. This makes it easy for future intercept vector
> > additions. Also update trace functions.
> >
> > Signed-off-by: Babu Moger
> > ---
>
> > @@ -128,8 +129,7 @@ enum {
> >
> > struct __attribute__ ((__packed__)) vmcb_control_area {
> > u32 intercepts[MAX_VECTORS];
> > - u64 intercept;
> > - u8 reserved_1[40];
> > + u8 reserved_1[60 - (MAX_VECTORS * 4)];
>
> Perhaps this could be simplified to 'u32 reserved_1[15 - MAX_VECTORS];'
Ok. Will change it. thanks
>
> > u16 pause_filter_thresh;
> > u16 pause_filter_count;
> > u64 iopm_base_pa;
>
> Reviewed-by: Jim Mattson
RE: [PATCH v3 04/11] KVM: SVM: Modify intercept_exceptions to generic intercepts
> -Original Message-
> From: Jim Mattson
> Sent: Wednesday, July 29, 2020 3:48 PM
> To: Moger, Babu
> Cc: Paolo Bonzini ; Vitaly Kuznetsov
> ; Wanpeng Li ; Sean
> Christopherson ; kvm list
> ; Joerg Roedel ; the arch/x86
> maintainers ; LKML ; Ingo
> Molnar ; Borislav Petkov ; H . Peter Anvin
> ; Thomas Gleixner
> Subject: Re: [PATCH v3 04/11] KVM: SVM: Modify intercept_exceptions to
> generic intercepts
>
> On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote:
> >
> > Modify intercept_exceptions to generic intercepts in vmcb_control_area.
> > Use the generic __set_intercept, __clr_intercept and __is_intercept to
> > set the intercept_exceptions bits.
> >
> > Signed-off-by: Babu Moger
> > ---
>
> > @@ -52,6 +54,25 @@ enum {
> > INTERCEPT_DR5_WRITE,
> > INTERCEPT_DR6_WRITE,
> > INTERCEPT_DR7_WRITE,
> > + /* Byte offset 008h (Vector 2) */
> > + INTERCEPT_DE_VECTOR = 64 + DE_VECTOR,
> > + INTERCEPT_DB_VECTOR,
> > + INTERCEPT_BP_VECTOR = 64 + BP_VECTOR,
> > + INTERCEPT_OF_VECTOR,
> > + INTERCEPT_BR_VECTOR,
> > + INTERCEPT_UD_VECTOR,
> > + INTERCEPT_NM_VECTOR,
> > + INTERCEPT_DF_VECTOR,
> > + INTERCEPT_TS_VECTOR = 64 + TS_VECTOR,
> > + INTERCEPT_NP_VECTOR,
> > + INTERCEPT_SS_VECTOR,
> > + INTERCEPT_GP_VECTOR,
> > + INTERCEPT_PF_VECTOR,
> > + INTERCEPT_MF_VECTOR = 64 + MF_VECTOR,
> > + INTERCEPT_AC_VECTOR,
> > + INTERCEPT_MC_VECTOR,
> > + INTERCEPT_XM_VECTOR,
> > + INTERCEPT_VE_VECTOR,
> > };
>
> I think it's demanding a lot of the reader to know where there are and are not
> gaps in the allocated hardware exception vectors. Perhaps all of the above
> enumeration definitions could have initializers? Either way...
Sure. Will add all the initializers here. Thanks
>
> Reviewed-by: Jim Mattson
Re: [PATCH net] ptp: ptp_clockmatrix: update to support 4.8.7 firmware
On Tue, Jul 28, 2020 at 04:00:30PM -0400, min.li...@renesas.com wrote: > From: Min Li > > With 4.8.7 firmware, adjtime can change delta instead of absolute time, > which greately increases snap accuracy. PPS alignment doesn't have to > be set for every single TOD change. Other minor changes includes: > adding more debug logs, increasing snap accuracy for pre 4.8.7 firmware > and supporting new tcs2bin format. > > Signed-off-by: Min Li Acked-by: Richard Cochran
drivers/staging/media/atomisp/pci/hmm/hmm.c:269:6: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'size_t' {aka 'unsigned int'}
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: 03884c93560c48c2739caa9b104b0cb4d3ea8c91 media: atomisp: add debug for
hmm alloc
date: 7 weeks ago
config: i386-randconfig-r016-20200729 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
git checkout 03884c93560c48c2739caa9b104b0cb4d3ea8c91
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
cc1: warning:
drivers/staging/media/atomisp//pci/hive_isp_css_include/memory_access/: No such
file or directory [-Wmissing-include-dirs]
In file included from include/linux/device.h:15,
from include/linux/acpi.h:15,
from include/linux/i2c.h:13,
from
drivers/staging/media/atomisp//include/hmm/../../include/linux/atomisp_platform.h:20,
from
drivers/staging/media/atomisp//pci/atomisp_internal.h:22,
from drivers/staging/media/atomisp/pci/hmm/hmm.c:33:
drivers/staging/media/atomisp/pci/hmm/hmm.c: In function 'hmm_alloc':
>> drivers/staging/media/atomisp/pci/hmm/hmm.c:269:6: warning: format '%ld'
>> expects argument of type 'long int', but argument 6 has type 'size_t' {aka
>> 'unsigned int'} [-Wformat=]
269 | "%s: pages: 0x%08x (%ld bytes), type: %d from highmem %d, user
ptr %p, cached %d\n",
|
^~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
19 | #define dev_fmt(fmt) fmt
| ^~~
drivers/staging/media/atomisp/pci/hmm/hmm.c:268:6: note: in expansion of
macro 'dev_dbg'
268 | dev_dbg(atomisp_dev,
| ^~~
drivers/staging/media/atomisp/pci/hmm/hmm.c:269:28: note: format string is
defined here
269 | "%s: pages: 0x%08x (%ld bytes), type: %d from highmem %d, user
ptr %p, cached %d\n",
| ~~^
||
|long int
| %d
vim +269 drivers/staging/media/atomisp/pci/hmm/hmm.c
220
221 ia_css_ptr hmm_alloc(size_t bytes, enum hmm_bo_type type,
222 int from_highmem, const void __user *userptr,
223 const uint16_t attrs)
224 {
225 unsigned int pgnr;
226 struct hmm_buffer_object *bo;
227 bool cached = attrs & ATOMISP_MAP_FLAG_CACHED;
228 int ret;
229
230 WARN_ON(attrs & ATOMISP_MAP_FLAG_CONTIGUOUS);
231
232 /*
233 * Check if we are initialized. In the ideal world we wouldn't
need
234 * this but we can tackle it once the driver is a lot cleaner
235 */
236
237 if (!hmm_initialized)
238 hmm_init();
239 /* Get page number from size */
240 pgnr = size_to_pgnr_ceil(bytes);
241
242 /* Buffer object structure init */
243 bo = hmm_bo_alloc(_device, pgnr);
244 if (!bo) {
245 dev_err(atomisp_dev, "hmm_bo_create failed.\n");
246 goto create_bo_err;
247 }
248
249 /* Allocate pages for memory */
250 ret = hmm_bo_alloc_pages(bo, type, from_highmem, userptr,
cached);
251 if (ret) {
252 dev_err(atomisp_dev, "hmm_bo_alloc_pages failed.\n");
253 goto alloc_page_err;
254 }
255
256 /* Combine the virtual address and pages together */
257 ret = hmm_bo_bind(bo);
258 if (ret) {
259 dev_err(atomisp_dev, "hmm_bo_bind failed.\n");
260 goto bind_err;
261 }
262
263 hmm_mem_stat.tol_cnt += pgnr;
264
265 if (attrs & ATOMISP_MAP_FLAG_CLEARED)
266 hmm_set(bo->start, 0, bytes);
267
268 dev_dbg(atomisp_dev,
> 269 "%s: pages: 0x%08x (%ld bytes), type: %d from highmem %d,
> user ptr %p, cached %d\n",
270 __func__, bo->start, bytes, type, from_highmem, userptr,
cached);
271
272 return bo->start;
273
274 bind_err:
275 hmm_bo_free_pages(bo);
276 alloc_page_err:
277 hmm_bo_unref(bo);
278 create_bo_err:
279 return 0;
280 }
281
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v3 06/11] KVM: SVM: Add new intercept vector in vmcb_control_area
On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote:
>
> The new intercept bits have been added in vmcb control area to support
> few more interceptions. Here are the some of them.
> - INTERCEPT_INVLPGB,
> - INTERCEPT_INVLPGB_ILLEGAL,
> - INTERCEPT_INVPCID,
> - INTERCEPT_MCOMMIT,
> - INTERCEPT_TLBSYNC,
>
> Add new intercept vector in vmcb_control_area to support these instructions.
> Also update kvm_nested_vmrun trace function to support the new addition.
>
> AMD documentation for these instructions is available at "AMD64
> Architecture Programmer’s Manual Volume 2: System Programming, Pub. 24593
> Rev. 3.34(or later)"
>
> The documentation can be obtained at the links below:
> Link: https://www.amd.com/system/files/TechDocs/24593.pdf
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
>
> Signed-off-by: Babu Moger
> ---
> @@ -16,6 +16,7 @@ enum vector_offset {
> EXCEPTION_VECTOR,
> INTERCEPT_VECTOR_3,
> INTERCEPT_VECTOR_4,
> + INTERCEPT_VECTOR_5,
> MAX_VECTORS,
> };
Is this enumeration actually adding any value?
vmcb->control.intercepts[INTERCEPT_VECTOR_5] doesn't seem in any way
"better" than just vmcb->control.intercepts[5].
Reviewed-by: Jim Mattson
Re: [PATCH] include: Replace HTTP links with HTTPS ones
On Sun, Jul 26, 2020 at 01:01:17PM +0200, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Signed-off-by: Alexander A. Klimov Reviewed-by: Kees Cook Jon, do you want to take this? -- Kees Cook
Re: [PATCH 1/2] kbuild: move shared library build rules to scripts/gcc-plugins/Makefile
On Wed, Jul 29, 2020 at 12:15:36PM +0900, Masahiro Yamada wrote: > The shared library build rules are currently implemented in > scripts/Makefile.host, but actually GCC-plugin is the only user of > them. Hence, they do not need to be treewide available. Are none of the VDSOs intending to use these rules? > Move all the relevant build rules to scripts/gcc-plugins/Makefile. > > I also optimized the build steps so *.so is directly built from .c > because every upstream plugin is compiled from a single source file. > > I am still keeping the infrastructure to build a plugin from multiple > files because Kees suggested to do so in my previous attempt. > (https://lkml.org/lkml/2019/1/11/1107) > > If the plugin, foo.so, is compiled from two files foo.c and foo2.c, > then you can do like follows: > > foo-objs := foo.o foo2.o > > Single-file plugins do not need the *-objs notation. > > Signed-off-by: Masahiro Yamada But, yeah, sure! Acked-by: Kees Cook Unrelated, but I do note that objtool maybe has the wrong indentation, path name reporting, and tool names (HOSTLD vs CC)? ... HOSTCC scripts/asn1_compiler HOSTCC scripts/extract-cert HOSTCC scripts/genksyms/genksyms.o YACCscripts/genksyms/parse.tab.[ch] LEX scripts/genksyms/lex.lex.c DESCEND objtool HOSTCXX scripts/gcc-plugins/cyc_complexity_plugin.so HOSTCXX scripts/gcc-plugins/latent_entropy_plugin.so HOSTCXX scripts/gcc-plugins/structleak_plugin.so GENSEED scripts/gcc-plugins/randomize_layout_seed.h HOSTCXX scripts/gcc-plugins/stackleak_plugin.so HOSTCC scripts/genksyms/parse.tab.o HOSTCC scripts/genksyms/lex.lex.o HOSTCC /home/kees/src/linux-build/plugins/tools/objtool/fixdep.o HOSTLD arch/x86/tools/relocs HOSTLD /home/kees/src/linux-build/plugins/tools/objtool/fixdep-in.o LINK /home/kees/src/linux-build/plugins/tools/objtool/fixdep CC /home/kees/src/linux-build/plugins/tools/objtool/exec-cmd.o CC /home/kees/src/linux-build/plugins/tools/objtool/help.o CC /home/kees/src/linux-build/plugins/tools/objtool/weak.o ... -- Kees Cook
[RFC PATCH 2/3] ipv4/icmp: l3mdev: Perform icmp error route lookup on source device routing table
As per RFC792, ICMP errors should be sent to the source host.
However, in configurations with Virtual Routing and Forwarding tables,
looking up which routing table to use is currently done by using the
destination net_device.
commit 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to
determine L3 domain") changes the interface passed to
l3mdev_master_ifindex() and inet_addr_type_dev_table() from skb_in->dev
to skb_dst(skb_in)->dev. This effectively uses the destination device
rather than the source device for choosing which routing table should be
used to lookup where to send the ICMP error.
Therefore, if the source and destination interfaces are within separate
VRFs, or one in the global routing table and the other in a VRF, looking
up the source host in the destination interface's routing table will
fail if the destination interface's routing table contains no route to
the source host.
One observable effect of this issue is that traceroute does not work in
the following cases:
- Route leaking between global routing table and VRF
- Route leaking between VRFs
Preferably use the source device routing table when sending ICMPv6 error
messages. If no source device is set, fall-back on the destination
device routing table.
Fixes: 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3
domain")
Link: https://tools.ietf.org/html/rfc792
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
net/ipv4/icmp.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index e30515f89802..029e12d35b19 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -465,6 +465,7 @@ static struct rtable *icmp_route_lookup(struct net *net,
int type, int code,
struct icmp_bxm *param)
{
+ struct net_device *route_lookup_dev = NULL;
struct rtable *rt, *rt2;
struct flowi4 fl4_dec;
int err;
@@ -479,7 +480,17 @@ static struct rtable *icmp_route_lookup(struct net *net,
fl4->flowi4_proto = IPPROTO_ICMP;
fl4->fl4_icmp_type = type;
fl4->fl4_icmp_code = code;
- fl4->flowi4_oif = l3mdev_master_ifindex(skb_dst(skb_in)->dev);
+ /*
+* The device used for looking up which routing table to use is
+* preferably the source whenever it is set, which should ensure
+* the icmp error can be sent to the source host, else fallback
+* on the destination device.
+*/
+ if (skb_in->dev)
+ route_lookup_dev = skb_in->dev;
+ else if (skb_dst(skb_in))
+ route_lookup_dev = skb_dst(skb_in)->dev;
+ fl4->flowi4_oif = l3mdev_master_ifindex(route_lookup_dev);
security_skb_classify_flow(skb_in, flowi4_to_flowi(fl4));
rt = ip_route_output_key_hash(net, fl4, skb_in);
@@ -503,7 +514,7 @@ static struct rtable *icmp_route_lookup(struct net *net,
if (err)
goto relookup_failed;
- if (inet_addr_type_dev_table(net, skb_dst(skb_in)->dev,
+ if (inet_addr_type_dev_table(net, route_lookup_dev,
fl4_dec.saddr) == RTN_LOCAL) {
rt2 = __ip_route_output_key(net, _dec);
if (IS_ERR(rt2))
--
2.17.1
[RFC PATCH 1/3] selftests: Add VRF icmp error route lookup test
From: Michael Jeanson
The objective is to check that the incoming vrf routing table is selected
to send an ICMP error back to the source when the ttl of a packet reaches 1
while it is forwarded between different vrfs.
The first test sends a ping with a ttl of 1 from h1 to h2 and parses the
output of the command to check that a ttl expired error is received.
[This may be flaky, I'm open to suggestions of a more robust approch.]
The second test runs traceroute from h1 to h2 and parses the output to check
for a hop on r1.
Signed-off-by: Michael Jeanson
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
tools/testing/selftests/net/Makefile | 1 +
.../selftests/net/vrf_icmp_error_route.sh | 461 ++
2 files changed, 462 insertions(+)
create mode 100755 tools/testing/selftests/net/vrf_icmp_error_route.sh
diff --git a/tools/testing/selftests/net/Makefile
b/tools/testing/selftests/net/Makefile
index 895ec992b2f1..2fc72bc2908c 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -17,6 +17,7 @@ TEST_PROGS += route_localnet.sh
TEST_PROGS += reuseaddr_ports_exhausted.sh
TEST_PROGS += txtimestamp.sh
TEST_PROGS += vrf-xfrm-tests.sh
+TEST_PROGS += vrf_icmp_error_route.sh
TEST_PROGS_EXTENDED := in_netns.sh
TEST_GEN_FILES = socket nettest
TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
diff --git a/tools/testing/selftests/net/vrf_icmp_error_route.sh
b/tools/testing/selftests/net/vrf_icmp_error_route.sh
new file mode 100755
index ..faeedf9f9e1c
--- /dev/null
+++ b/tools/testing/selftests/net/vrf_icmp_error_route.sh
@@ -0,0 +1,461 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2019 David Ahern . All rights reserved.
+# Copyright (c) 2020 Michael Jeanson . All rights
reserved.
+#
+# redirect test
+#
+# blue red
+# .253 ++ .253
+# +| r1 |+
+# |++|
+# ++ | | ++
+# | h1 |--+ +--| h2 |
+# ++ .1 | | .2 ++
+# 172.16.1/24 |++| 172.16.2/24
+#2001:db8:16:1/64 +| r2 |+ 2001:db8:16:2/64
+# .254 ++ .254
+#
+#
+# Route from h1 to h2 goes through r1, incoming vrf blue has a route to the
+# outgoing vrf red for the n2 network but red doesn't have a route back to n1.
+# Route from h2 to h1 goes through r2.
+#
+# The objective is to check that the incoming vrf routing table is selected
+# to send an ICMP error back to the source when the ttl of a packet reaches 1
+# while it is forwarded between different vrfs.
+#
+# The first test sends a ping with a ttl of 1 from h1 to h2 and parses the
+# output of the command to check that a ttl expired error is received.
+#
+# The second test runs traceroute from h1 to h2 and parses the output to check
+# for a hop on r1.
+#
+# Requires CONFIG_NET_VRF, CONFIG_VETH, CONFIG_BRIDGE and CONFIG_NET_NS.
+
+VERBOSE=0
+PAUSE_ON_FAIL=no
+
+H1_N1_IP=172.16.1.1
+R1_N1_IP=172.16.1.253
+R2_N1_IP=172.16.1.254
+
+H1_N1_IP6=2001:db8:16:1::1
+R1_N1_IP6=2001:db8:16:1::253
+R2_N1_IP6=2001:db8:16:1::254
+
+H2_N2=172.16.2.0/24
+H2_N2_6=2001:db8:16:2::/64
+
+H2_N2_IP=172.16.2.2
+R1_N2_IP=172.16.2.253
+R2_N2_IP=172.16.2.254
+
+H2_N2_IP6=2001:db8:16:2::2
+R1_N2_IP6=2001:db8:16:2::253
+R2_N2_IP6=2001:db8:16:2::254
+
+
+# helpers
+
+log_section()
+{
+ echo
+ echo
"###"
+ echo "$*"
+ echo
"###"
+ echo
+}
+
+log_test()
+{
+ local rc=$1
+ local expected=$2
+ local msg="$3"
+
+ if [ "${rc}" -eq "${expected}" ]; then
+ printf "TEST: %-60s [ OK ]\n" "${msg}"
+ nsuccess=$((nsuccess+1))
+ else
+ ret=1
+ nfail=$((nfail+1))
+ printf "TEST: %-60s [FAIL]\n" "${msg}"
+ if [ "${PAUSE_ON_FAIL}" = "yes" ]; then
+ echo
+ echo "hit enter to continue, 'q' to quit"
+ read -r a
+ [ "$a" = "q" ] && exit 1
+ fi
+ fi
+}
+
+log_debug()
+{
+ if [ "$VERBOSE" = "1" ]; then
+ echo "$*"
+ fi
+}
+
+run_cmd()
+{
+ local cmd="$*"
+ local out
+ local rc
+
+ if [ "$VERBOSE" = "1" ]; then
+ echo "COMMAND: $cmd"
+ fi
+
+ out=$(eval $cmd 2>&1)
+ rc=$?
+ if [ "$VERBOSE" = "1" ] && [ -n "$out" ]; then
+ echo "$out"
+ fi
+
+ [ "$VERBOSE" = "1" ] && echo
+
+ return $rc
+}
+
+get_linklocal()
+{
+ local ns=$1
+
[RFC PATCH 3/3] ipv6/icmp: l3mdev: Perform icmp error route lookup on source device routing table
As per RFC4443, the destination address field for ICMPv6 error messages
is copied from the source address field of the invoking packet.
In configurations with Virtual Routing and Forwarding tables, looking up
which routing table to use for sending ICMPv6 error messages is
currently done by using the destination net_device.
If the source and destination interfaces are within separate VRFs, or
one in the global routing table and the other in a VRF, looking up the
source address of the invoking packet in the destination interface's
routing table will fail if the destination interface's routing table
contains no route to the invoking packet's source address.
One observable effect of this issue is that traceroute6 does not work in
the following cases:
- Route leaking between global routing table and VRF
- Route leaking between VRFs
Preferably use the source device routing table when sending ICMPv6 error
messages. If no source device is set, fall-back on the destination
device routing table.
Link: https://tools.ietf.org/html/rfc4443
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
net/ipv6/icmp.c | 15 +--
net/ipv6/ip6_output.c | 2 --
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 9df8737ae0d3..beee93065688 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -501,8 +501,19 @@ static void icmp6_send(struct sk_buff *skb, u8 type, u8
code, __u32 info,
if (__ipv6_addr_needs_scope_id(addr_type)) {
iif = icmp6_iif(skb);
} else {
- dst = skb_dst(skb);
- iif = l3mdev_master_ifindex(dst ? dst->dev : skb->dev);
+ struct net_device *route_lookup_dev = NULL;
+
+ /*
+* The device used for looking up which routing table to use is
+* preferably the source whenever it is set, which should
+* ensure the icmp error can be sent to the source host, else
+* fallback on the destination device.
+*/
+ if (skb->dev)
+ route_lookup_dev = skb->dev;
+ else if (skb_dst(skb))
+ route_lookup_dev = skb_dst(skb)->dev;
+ iif = l3mdev_master_ifindex(route_lookup_dev);
}
/*
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 8a8c2d0cfcc8..00243d7d276c 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -468,8 +468,6 @@ int ip6_forward(struct sk_buff *skb)
* check and decrement ttl
*/
if (hdr->hop_limit <= 1) {
- /* Force OUTPUT device used as source address */
- skb->dev = dst->dev;
icmpv6_send(skb, ICMPV6_TIME_EXCEED, ICMPV6_EXC_HOPLIMIT, 0);
__IP6_INC_STATS(net, idev, IPSTATS_MIB_INHDRERRORS);
--
2.17.1
Re: [PATCH net-next RFC 02/13] devlink: Add reload levels data to dev get
On Wed, 29 Jul 2020 17:37:41 +0300 Moshe Shemesh wrote: > > The fact that the driver supports fw_live_patch, does not necessarily > > mean that the currently running FW can be live upgraded to the > > currently flashed one, right? > > That's correct, though the feature is supported, the firmware gap may > not be suitable for live_patch. > > The user will be noted accordingly by extack message. That's kinda late, because use may have paid the cost of migrating the workload or otherwise taking precautions - and if live reset fails all this work is wasted. While the device most likely knows upfront whether it can be live reset or not, otherwise I don't see how it could reject the reset reliably. > > This interface does not appear to be optimal for the purpose. > > > > Again, documentation of what can be lost (in terms of configuration and > > features) upon upgrade is missing. > > I will clarify in documentation. On live_patch nothing should be lost or > re-initialized, that's the "live" thing. Okay, so FW upgrade cannot be allowed when it'd mean the device gets de-featured? Also no link loss, correct? What's the expected length of traffic interruption (order of magnitude)?
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
On Wed, Jul 29, 2020 at 08:40:57PM +, Fenghua Yu wrote:
> On Wed, Jul 29, 2020 at 10:49:47AM +0200, pet...@infradead.org wrote:
> > On Fri, Jul 17, 2020 at 02:35:00PM -0700, Fenghua Yu wrote:
> >
> > > #DB for bus lock detect fixes all issues in #AC for split lock detect:
> > > 1) It's architectural ... just need to look at one CPUID bit to know it
> > >exists
> > > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread.
> > >So each process or guest can have different behavior.
> >
> > And it generates a whole new problem due to #DB being an IST, and
> > we very much rely on #DB never recursing, which we carefully crafted by
> > disallowing hardare breakpoints on noinstr code and clearing DR7 early.
> >
> > But now it can... please keep the pieces.
>
> Can we disable Bus Lock Detection before handle it and re-enable it
> after handle it? Will that resolve the recursion issue?
Because WRMSR is cheap, right?
You have to unconditionally {dis,en}able it on #DB entry/exit. Not only
when it's a DR_BUS_LOCK, _always_. Then maybe. I'm too tired to think
through the IST mess.
IST's suck, they're horrible crap.
Suppose we get a #DB, then we get an NMI right before it does WRMSR, so
BUS_LOCK is still on, then the NMI does a dodgy LOCK op, we die.
So that means, you get to disable it on every NMI-like exception too,
but we happen to care about performance for those, you loose.
Also, what happens if you have a hardware watchpoint on the instruction
that causes DR_BUS_LOCK? Does that work as expected?
Re: [PATCH net-next RFC 01/13] devlink: Add reload level option to devlink reload command
On Wed, 29 Jul 2020 17:54:08 +0300 Moshe Shemesh wrote: > On 7/28/2020 11:06 PM, Jakub Kicinski wrote: > > On Tue, 28 Jul 2020 12:18:30 -0700 Jacob Keller wrote: > >> On 7/28/2020 11:44 AM, Jakub Kicinski wrote: > >>> From user perspective what's important is what the reset achieves (and > >>> perhaps how destructive it is). We can define the reset levels as: > >>> > >>> $ devlink dev reload pci/:82:00.0 net-ns-respawn > >>> $ devlink dev reload pci/:82:00.0 driver-param-init > >>> $ devlink dev reload pci/:82:00.0 fw-activate > >>> > >>> combining should be possible when user wants multiple things to happen: > >>> > >>> $ devlink dev reload pci/:82:00.0 fw-activate driver-param-init > >> Where today "driver-param-init" is the default behavior. But didn't we > >> just say that mlxsw also does the equivalent of fw-activate? > > Actually the default should probably be the combination of > > driver-param-init and net-ns-respawn. > > What about the support of these combinations, one device needs to reset > fw to apply the param init, while another device can apply param-init > without fw reset, but has to reload the driver for fw-reset. > > So the support per driver will be a matrix of combinations ? Note that there is no driver reload in my examples, driver reload is likely not user's goal. Whatever the driver needs to reset to satisfy the goal is fair game IMO. It's already the case that some drivers reset FW for param init and some don't and nobody is complaining. We should treat constraints separate (in this set we have the live activation which is a constraint on the reload operation). > > My expectations would be that the driver must perform the lowest > > reset level possible that satisfies the requested functional change. > > IOW driver may do more, in fact it should be acceptable for the > > driver to always for a full HW reset (unless --live or other > > constraint is specified). > > OK, but some combinations may still not be valid for specific driver > even if it tries lowest level possible. Can you give an example?
Re: [PATCH bpf-next v2] Documentation/bpf: Use valid and new links in index.rst
On Wed, Jul 29, 2020 at 6:17 AM Tiezhu Yang wrote:
>
> There exists an error "404 Not Found" when I click the html link of
> "Documentation/networking/filter.rst" in the BPF documentation [1],
> fix it.
>
> Additionally, use the new links about "BPF and XDP Reference Guide"
> and "bpf(2)" to avoid redirects.
>
> [1] https://www.kernel.org/doc/html/latest/bpf/
>
> Fixes: d9b9170a2653 ("docs: bpf: Rename README.rst to index.rst")
> Fixes: cb3f0d56e153 ("docs: networking: convert filter.txt to ReST")
> Signed-off-by: Tiezhu Yang
> ---
>
> v2:
> - Fix a typo "clik" to "click" in the commit message, sorry for that
>
> Documentation/bpf/index.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
> index 26f4bb3..1b901b4 100644
> --- a/Documentation/bpf/index.rst
> +++ b/Documentation/bpf/index.rst
> @@ -68,7 +68,7 @@ Testing and debugging BPF
>
>
> .. Links:
> -.. _Documentation/networking/filter.rst: ../networking/filter.txt
> +.. _Documentation/networking/filter.rst: ../networking/filter.html
This should be filter.rst, no?
> .. _man-pages: https://www.kernel.org/doc/man-pages/
> -.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
> -.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
> +.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
> +.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/
> --
> 2.1.0
>
Re: [PATCH v3 05/11] KVM: SVM: Modify 64 bit intercept field to two 32 bit vectors
On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote:
>
> Convert all the intercepts to one array of 32 bit vectors in
> vmcb_control_area. This makes it easy for future intercept vector
> additions. Also update trace functions.
>
> Signed-off-by: Babu Moger
> ---
> @@ -128,8 +129,7 @@ enum {
>
> struct __attribute__ ((__packed__)) vmcb_control_area {
> u32 intercepts[MAX_VECTORS];
> - u64 intercept;
> - u8 reserved_1[40];
> + u8 reserved_1[60 - (MAX_VECTORS * 4)];
Perhaps this could be simplified to 'u32 reserved_1[15 - MAX_VECTORS];'
> u16 pause_filter_thresh;
> u16 pause_filter_count;
> u64 iopm_base_pa;
Reviewed-by: Jim Mattson
Re: [RFC PATCH 03/14] coresight: tpiu: Use coresight device access abstraction
On Wed, Jul 22, 2020 at 06:20:29PM +0100, Suzuki K Poulose wrote:
> TPIU driver access the device before the coresight device
> is registered. In other words, before the drvdata->csdev
> is valid. Thus, we need to make sure that the csdev_access
> is valid for both the invocations. Switch to using the
> csdev_access directly instead of relying on availability
> of drvdata->csdev.
I'm not sure all of the above is needed and based on the wording I could easily
see this patch being selected for stable backport, which would be a mistak.
The gist of this patch is that we are moving to the access abstraction and the
changelog should reflect that.
>
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-tpiu.c | 30 +---
> 1 file changed, 13 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c
> b/drivers/hwtracing/coresight/coresight-tpiu.c
> index 7ef7649f48ad..84ff4bf5d3b8 100644
> --- a/drivers/hwtracing/coresight/coresight-tpiu.c
> +++ b/drivers/hwtracing/coresight/coresight-tpiu.c
> @@ -60,49 +60,45 @@ struct tpiu_drvdata {
> struct coresight_device *csdev;
> };
>
> -static void tpiu_enable_hw(struct tpiu_drvdata *drvdata)
> +static void tpiu_enable_hw(struct csdev_access *csa)
> {
> - CS_UNLOCK(drvdata->base);
> + CS_UNLOCK(csa->base);
>
> /* TODO: fill this up */
>
> - CS_LOCK(drvdata->base);
> + CS_LOCK(csa->base);
> }
>
> static int tpiu_enable(struct coresight_device *csdev, u32 mode, void
> *__unused)
> {
> - struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> -
> - tpiu_enable_hw(drvdata);
> + tpiu_enable_hw(>access);
> atomic_inc(csdev->refcnt);
> dev_dbg(>dev, "TPIU enabled\n");
> return 0;
> }
>
> -static void tpiu_disable_hw(struct tpiu_drvdata *drvdata)
> +static void tpiu_disable_hw(struct csdev_access *csa)
> {
> - CS_UNLOCK(drvdata->base);
> + CS_UNLOCK(csa->base);
>
> /* Clear formatter and stop on flush */
> - writel_relaxed(FFCR_STOP_FI, drvdata->base + TPIU_FFCR);
> + csdev_access_relaxed_write32(csa, FFCR_STOP_FI, TPIU_FFCR);
> /* Generate manual flush */
> - writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
> + csdev_access_relaxed_write32(csa, FFCR_STOP_FI | FFCR_FON_MAN,
> TPIU_FFCR);
> /* Wait for flush to complete */
> - coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN_BIT, 0);
> + coresight_timeout(csa->base, TPIU_FFCR, FFCR_FON_MAN_BIT, 0);
> /* Wait for formatter to stop */
> - coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED_BIT, 1);
> + coresight_timeout(csa->base, TPIU_FFSR, FFSR_FT_STOPPED_BIT, 1);
>
> - CS_LOCK(drvdata->base);
> + CS_LOCK(csa->base);
> }
>
> static int tpiu_disable(struct coresight_device *csdev)
> {
> - struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> -
> if (atomic_dec_return(csdev->refcnt))
> return -EBUSY;
>
> - tpiu_disable_hw(drvdata);
> + tpiu_disable_hw(>access);
>
> dev_dbg(>dev, "TPIU disabled\n");
> return 0;
> @@ -152,7 +148,7 @@ static int tpiu_probe(struct amba_device *adev, const
> struct amba_id *id)
> desc.access.base = base;
Any reason for introducing the above in patch 02? I would have done that as
part of this patch... Also part of this patch I would remove drvdata::base
since it is no longer needed.
I'm out of time for today - I will continue tomorrow.
Regards,
Mathieu
>
> /* Disable tpiu to support older devices */
> - tpiu_disable_hw(drvdata);
> + tpiu_disable_hw();
>
> pdata = coresight_get_platform_data(dev);
> if (IS_ERR(pdata))
> --
> 2.24.1
>
Re: [PATCH 15/23] seq_file: switch over direct seq_read method calls to seq_read_iter
On Fri, Jul 17, 2020 at 11:09:13PM +0200, Thomas Gleixner wrote:
>
> Needs some thought and maybe some cocci help from Julia, but that's way
> better than this brute force sed thing which results in malformed crap
> like this:
>
> static const struct file_operations debug_stats_fops = {
> .open = debug_stats_open,
> .read_iter = seq_read_iter,
> .llseek = seq_lseek,
> .release= single_release,
> };
>
> and proliferates the copy and paste voodoo programming.
Better copy and paste than templates, IMO; at least the former is
greppable; fucking DEFINE_..._ATRIBUTE is *NOT*, especially due
to the use of ##.
Re: Inverted mount options completely broken (iversion,relatime)
David Howells wrote:
> > So my question is, what do we do here?
>
> Hmmm... As the code stands, MS_RDONLY, MS_SYNCHRONOUS, MS_MANDLOCK,
> MS_I_VERSION and MS_LAZYTIME should all be masked off before the new flags are
> set if called from mount(2) rather than fsconfig(2).
>
> do_remount() gives MS_RMT_MASK to fs_context_for_reconfigure() to load into
> fc->sb_flags_mask, which should achieve the desired effect in
> reconfigure_super() on this line:
>
> WRITE_ONCE(sb->s_flags, ((sb->s_flags & ~fc->sb_flags_mask) |
>(fc->sb_flags & fc->sb_flags_mask)));
So applying the attached patch and then doing:
mount -t tmpfs none /mnt
mount -o remount,iversion /mnt
mount -o remount,noiversion /mnt
mount -o remount,norelatime /mnt
mount -o remount,relatime /mnt
prints:
sb=7001 set=80 mask=2800051
sb=7081 set=0 mask=2800051
sb=7001 set=0 mask=2800051
sb=7001 set=0 mask=2800051
MS_RELATIME isn't included in MS_RMT_MASK, so remount shouldn't be able to
change it.
David
---
diff --git a/fs/super.c b/fs/super.c
index 904459b35119..540cb37c11e7 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -964,6 +964,7 @@ int reconfigure_super(struct fs_context *fc)
}
}
+ printk("sb=%lx set=%x mask=%x\n", sb->s_flags, fc->sb_flags,
fc->sb_flags_mask);
WRITE_ONCE(sb->s_flags, ((sb->s_flags & ~fc->sb_flags_mask) |
(fc->sb_flags & fc->sb_flags_mask)));
/* Needs to be ordered wrt mnt_is_readonly() */
Re: [PATCH v2] interconnect: Add bulk API helpers
On Wed 29 Jul 05:34 PDT 2020, Georgi Djakov wrote:
> There are drivers which just need to get multiple interconnect paths,
> request some predefined amounts of bandwidth and then just toggle the
> paths between enabled/disabled state.
>
> The aim of this patch is simplify the above and to allow drivers to put
> all the path names and bandwidth data into a single static icc_bulk_data
> table and call the icc_bulk_* functions on that table in order to scale
> all the interconnect paths in parallel.
>
> Suggested-by: Evan Green
> Suggested-by: Bjorn Andersson
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Georgi Djakov
> ---
>
> v2:
> * Fix kernel-doc. (Bjorn)
> * Do not print EPROBE_DEFER errors. (Bjorn)
>
> v1: https://lore.kernel.org/r/20200528162542.30158-1-georgi.dja...@linaro.org/
>
> drivers/interconnect/Makefile | 2 +-
> drivers/interconnect/bulk.c | 117 ++
> include/linux/interconnect.h | 22 +++
> 3 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 drivers/interconnect/bulk.c
>
> diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
> index 4825c287ca13..d203520b0a56 100644
> --- a/drivers/interconnect/Makefile
> +++ b/drivers/interconnect/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> CFLAGS_core.o:= -I$(src)
> -icc-core-objs:= core.o
> +icc-core-objs:= core.o bulk.o
>
> obj-$(CONFIG_INTERCONNECT) += icc-core.o
> obj-$(CONFIG_INTERCONNECT_IMX) += imx/
> diff --git a/drivers/interconnect/bulk.c b/drivers/interconnect/bulk.c
> new file mode 100644
> index ..73e2c8d0a412
> --- /dev/null
> +++ b/drivers/interconnect/bulk.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +
> +/**
> + * of_icc_bulk_get() - get interconnect paths
> + * @dev: the device requesting the path
> + * @num_paths: the number of icc_bulk_data
> + * @paths: the table with the paths we want to get
> + *
> + * Returns 0 on success or negative errno otherwise.
> + */
> +int __must_check of_icc_bulk_get(struct device *dev, int num_paths,
> + struct icc_bulk_data *paths)
> +{
> + int ret, i;
> +
> + for (i = 0; i < num_paths; i++) {
> + paths[i].path = of_icc_get(dev, paths[i].name);
> + if (IS_ERR(paths[i].path)) {
> + ret = PTR_ERR(paths[i].path);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "of_icc_get() failed on path %s
> (%d)\n",
> + paths[i].name, ret);
> + paths[i].path = NULL;
> + goto err;
> + }
> + }
> +
> + return 0;
> +
> +err:
> + icc_bulk_put(i, paths);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_icc_bulk_get);
> +
> +/**
> + * icc_bulk_put() - put a list of interconnect paths
> + * @num_paths: the number of icc_bulk_data
> + * @paths: the icc_bulk_data table with the paths being put
> + */
> +void icc_bulk_put(int num_paths, struct icc_bulk_data *paths)
> +{
> + while (--num_paths >= 0) {
> + icc_put(paths[num_paths].path);
> + paths[num_paths].path = NULL;
> + }
> +}
> +EXPORT_SYMBOL_GPL(icc_bulk_put);
> +
> +/**
> + * icc_bulk_set() - set bandwidth to a set of paths
> + * @num_paths: the number of icc_bulk_data
> + * @paths: the icc_bulk_data table containing the paths and bandwidth
> + *
> + * Returns 0 on success or negative errno otherwise.
> + */
> +int icc_bulk_set_bw(int num_paths, const struct icc_bulk_data *paths)
> +{
> + int ret = 0;
> + int i;
> +
> + for (i = 0; i < num_paths; i++) {
> + ret = icc_set_bw(paths[i].path, paths[i].avg_bw,
> paths[i].peak_bw);
> + if (ret) {
> + pr_err("icc_set_bw() failed on path %s (%d)\n",
> paths[i].name, ret);
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(icc_bulk_set_bw);
> +
> +/**
> + * icc_bulk_enable() - enable a previously disabled set of paths
> + * @num_paths: the number of icc_bulk_data
> + * @paths: the icc_bulk_data table containing the paths and bandwidth
> + *
> + * Returns 0 on success or negative errno otherwise.
> + */
> +int icc_bulk_enable(int num_paths, const struct icc_bulk_data *paths)
> +{
> + int ret, i;
> +
> + for (i = 0; i < num_paths; i++) {
> + ret = icc_enable(paths[i].path);
> + if (ret) {
> + pr_err("icc_enable() failed on path %s (%d)\n",
> paths[i].name, ret);
> + goto err;
> + }
> + }
> +
> + return 0;
> +
> +err:
> + icc_bulk_disable(i, paths);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(icc_bulk_enable);
> +
> +/**
> +
Re: [PATCH net-next RFC 09/13] devlink: Add enable_remote_dev_reset generic parameter
On Wed, 29 Jul 2020 17:42:12 +0300 Moshe Shemesh wrote: > On 7/28/2020 3:59 AM, Jakub Kicinski wrote: > > On Mon, 27 Jul 2020 14:02:29 +0300 Moshe Shemesh wrote: > >> The enable_remote_dev_reset devlink param flags that the host admin > >> allows device resets that can be initiated by other hosts. This > >> parameter is useful for setups where a device is shared by different > >> hosts, such as multi-host setup. Once the user set this parameter to > >> false, the driver should NACK any attempt to reset the device while the > >> driver is loaded. > >> > >> Signed-off-by: Moshe Shemesh > > There needs to be a devlink event generated when reset is triggered > > (remotely or not). > > > > You're also missing failure reasons. Users need to know if the reset > > request was clearly nacked by some host, not supported, etc. vs > > unexpected failure. > > I will fix and send extack message to the user accordingly. I'd suggest the reason codes to be somewhat standard. The groups I can think of: - timeout - device did not respond to the reset request - device reject - FW or else has nacked the activation req - host incapable - one of the participating hosts (in MH) is not capable of handling live activation - host denied - one of the participating hosts has NACKed - host timeout - one of the p. hosts did not ack or done the procedure in time (e.g. has not toggled the link) - failed reset - the activation itself had failed - failed reinit - one of p. hosts was not able to cleanly come back up
Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable
On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson wrote: > > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann wrote: > > > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson wrote: > > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman > > > wrote: > > >> > > >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote: > > >> > El sáb., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman < > > >> > gre...@linuxfoundation.org> escribió: > > >> > > > >> > > > >> > 1) I just did the same that intel-spi.c does. > > >> > > >> No need to copy bad examples :) > > > > > > > > > Didn't know it was a bad example. What's is the current modern mechanism > > > that replaces initialization-time configuration? > > > > I'd say you'd generally want this to be a per-instance setting, which > > could be a sysfs attribute of the physical device, or an ioctl for an > > existing user space abstraction. > > But still, they are not equivalent. The initial configuration remains > constant for the rest of the life of the driver, whereas the > sysfs attribute is set after the initialization and can be re-set over > time. I'm not asking module parameters "to come back" if > they are now considered obsolete, I'm just trying to understand. > > > > > In the changelog, you should also explain what this is used for. Do > > you actually want to write to a device that is marked read-only, or > > are you just trying to make the interface more consistent between the > > two drivers? > > The device can either be locked or unlocked. If it is unlocked, it can > be set writable depending on the module > argument in intel-spi, or straight writable in intel-spi-pci. Which is > dangerous. > I wanted to make, as you say, the interface consistent. > Exposing an interface to the user (via a sysfs attribute) to try to > make the driver writable is definitively a bad idea. > I'd rather do nothing (no module arg) rather than open that > here-be-dragons door. ping. This is a real existing problem that I'm trying to address. There's currently no way to prevent the kernel to try to turn the SPI flash chip writable for the device IDs handled by intel-spi-pci. And allowing userspace to switch it between writable/non-writable is not an option. What other mechanism can I use other than the module parameter, so - not accessible through user space - ideally set once, ideally at initialization time Thanks, Daniel. > > > > > Arnd > > > > -- > Daniel Gutson > Argentina Site Director > Enginieering Director > Eclypsium > > Below The Surface: Get the latest threat research and insights on > firmware and supply chain threats from the research team at Eclypsium. > https://eclypsium.com/research/#threatreport -- Daniel Gutson Argentina Site Director Enginieering Director Eclypsium Below The Surface: Get the latest threat research and insights on firmware and supply chain threats from the research team at Eclypsium. https://eclypsium.com/research/#threatreport
Re: [PATCH v6 1/6] docs: IOMMU user API
On Wed, 29 Jul 2020 01:18:04 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Wednesday, July 29, 2020 3:20 AM > > > [...] > > > + > > > +For example, IOTLB invalidations should always succeed. There is > > > no +architectural way to report back to the vIOMMU if the UAPI > > > data is +incompatible. If that happens, in order to guarantee > > > IOMMU iosolation, > > > > isolation > > > > > +we have to resort to not giving completion status in vIOMMU. > > > This may +result in VM hang. > > > + > > > +For this reason the following IOMMU UAPIs cannot fail without > > > +catastrophic effect: > > > + > > > +1. Free PASID > > > +2. Unbind guest PASID > > > +3. Unbind guest PASID table (SMMU) > > > +4. Cache invalidate > > > > I'm not entirely sure what we're trying to assert here. Clearly > > cache invalidation can fail and patch 5/6 goes on to add over a > > dozen checks of the user provided data that return an -errno. Any > > user ioctl can fail if the user botches the parameters. So are we > > just trying to explain the feature checking that should allow the > > user to know supported combinations and if they adhere to them, > > these should not fail? It's not quite worded to that effect. > > Thanks, > > I guess the above wording is messed by what a UAPI should > behave and whether the vIOMMU reports associated errors. > UAPI can always fail, as you pointed out. vIOMMU may not > have a matching error code though, e.g. on Intel VT-d there is no > error reporting mechanism for cache invalidation. However, > it is not wise to assert UAPI behavior according to vIOMMU > definition. An error is an error. vIOMMU should just react to > UAPI errors according to its architecture definition (e.g. ignore, > forward to guest, hang, etc.). From this matter I feel above > section could better be removed. > Yes, I agreed, the scope is not drawn clearly. This section is kind of the relic of a previous version where responsibility of feature checking lies with IOMMU UAPI instead of VFIO. How about just briefly mention that upfront feature checking is encouraged to avoid complex and catastrophic error at runtime? I will remove the rest. > Thanks > Kevin [Jacob Pan]
Re: [RFC][PATCH] locking/refcount: Provide __refcount API to obtain the old value
On Wed, Jul 29, 2020 at 09:41:37PM +0100, David Howells wrote: > pet...@infradead.org wrote: > > > I'm not entirely sure what you mean with interpret, provided you don't > > trigger a refcount fail, the number will be just what you expect and > > would get from refcount_read(). If you do trigger a fail, you'll get a > > negative value. > > That's fine. I seem to remember talk about the possibility that the number > wouldn't necessarily bottom out at zero - for instance if it was arranged such > that the overflow flag was set on an overflow or underflow so that it could be > trapped on (using INTO or TRAPV, for example). The trap is an internal detail. The saturation value will be negative, though. -- Kees Cook
Re: [PATCH] net/mlx5e: fix bpf_prog refcnt leaks in mlx5e_alloc_rq
On Wed, 2020-07-29 at 13:28 -0700, David Miller wrote:
> From: Saeed Mahameed
> Date: Wed, 29 Jul 2020 19:02:15 +
>
> >> Fix this issue by jumping to the error handling path
> >> err_rq_wq_destroy
> >> when either function fails.
> >>
> >
> > Fixes: 422d4c401edd ("net/mlx5e: RX, Split WQ objects for different
> RQ
> > types")
>
> Saeed, are you going to take this into your tree or would you like me
> to
> apply it directly?
>
> Thanks.
I will take this to my tree once Xin adds the missing Fixes tag.
Thanks.
Re: [PATCH 08/23] fs: don't change the address limit for ->write_iter in __kernel_write
On Tue, Jul 07, 2020 at 07:47:46PM +0200, Christoph Hellwig wrote: > If we write to a file that implements ->write_iter there is no need > to change the address limit if we send a kvec down. Implement that > case, and prefer it over using plain ->write with a changed address > limit if available. You are flipping the priorities of ->write and ->write_iter for kernel_write(). Now, there are 4 instances of file_operations where we have both. null_fops and zero_fops are fine either way - ->write() and ->write_iter() do the same thing there (and arguably removing ->write might be the right thing; the only reason I hesistate is that writing to /dev/null *is* critical for many things, including the proper mail delivery ;-) However, the other two (infinibarf and pcm) are different; there we really have different semantics. I don't believe anything writes into either under KERNEL_DS, but having kernel_write() and vfs_write() with subtly different semantics is asking for trouble down the road. How about we remove ->write in null_fops/zero_fops and fail loudly if *both* ->write() and ->write_iter() are present (in kernel_write(), that is)? There's a similar situation on the read side - there we have /dev/null with both ->read() and ->read_iter() (and there "remove ->read" is obviously the right thing to do) *and* we have pcm crap, with different semantics for ->read() and ->read_iter().
Re: [PATCH] KVM: x86: Deflect unknown MSR accesses to user space
On Wed, Jul 29, 2020 at 1:46 PM Alexander Graf wrote: > Do you have a rough ETA for Aaron's patch set yet? :) Rough ETA: Friday (31 July 2020).
Re: [PATCH 2/2] soc: qcom: smd-rpm: Fix kerneldoc
On Wed 29 Jul 00:44 PDT 2020, Krzysztof Kozlowski wrote:
> Fix W=1 compile warnings (invalid kerneldoc):
>
> drivers/soc/qcom/smd-rpm.c:35: warning: Function parameter or member
> 'dev' not described in 'qcom_smd_rpm'
> drivers/soc/qcom/smd-rpm.c:99: warning: Function parameter or member
> 'state' not described in 'qcom_rpm_smd_write'
>
> Signed-off-by: Krzysztof Kozlowski
Thanks for spotting these, applied.
PS. This doesn't have any relationship with the Mediatek patch, the two
goes through different maintainer trees and my manual mailbox filter
almost discarded the series. So please send patches like this
individually in the future.
Thanks,
Bjorn
> ---
> drivers/soc/qcom/smd-rpm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> index 877b13850730..1d4eb46b417a 100644
> --- a/drivers/soc/qcom/smd-rpm.c
> +++ b/drivers/soc/qcom/smd-rpm.c
> @@ -20,6 +20,7 @@
> * struct qcom_smd_rpm - state of the rpm device driver
> * @rpm_channel: reference to the smd channel
> * @icc: interconnect proxy device
> + * @dev: rpm device
> * @ack: completion for acks
> * @lock:mutual exclusion around the send/complete pair
> * @ack_status: result of the rpm request
> @@ -86,6 +87,7 @@ struct qcom_rpm_message {
> /**
> * qcom_rpm_smd_write - write @buf to @type:@id
> * @rpm: rpm handle
> + * @state: active/sleep state flags
> * @type:resource type
> * @id: resource identifier
> * @buf: the data to be written
> --
> 2.17.1
>
Re: [PATCH v3 04/11] KVM: SVM: Modify intercept_exceptions to generic intercepts
On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote:
>
> Modify intercept_exceptions to generic intercepts in vmcb_control_area.
> Use the generic __set_intercept, __clr_intercept and __is_intercept to
> set the intercept_exceptions bits.
>
> Signed-off-by: Babu Moger
> ---
> @@ -52,6 +54,25 @@ enum {
> INTERCEPT_DR5_WRITE,
> INTERCEPT_DR6_WRITE,
> INTERCEPT_DR7_WRITE,
> + /* Byte offset 008h (Vector 2) */
> + INTERCEPT_DE_VECTOR = 64 + DE_VECTOR,
> + INTERCEPT_DB_VECTOR,
> + INTERCEPT_BP_VECTOR = 64 + BP_VECTOR,
> + INTERCEPT_OF_VECTOR,
> + INTERCEPT_BR_VECTOR,
> + INTERCEPT_UD_VECTOR,
> + INTERCEPT_NM_VECTOR,
> + INTERCEPT_DF_VECTOR,
> + INTERCEPT_TS_VECTOR = 64 + TS_VECTOR,
> + INTERCEPT_NP_VECTOR,
> + INTERCEPT_SS_VECTOR,
> + INTERCEPT_GP_VECTOR,
> + INTERCEPT_PF_VECTOR,
> + INTERCEPT_MF_VECTOR = 64 + MF_VECTOR,
> + INTERCEPT_AC_VECTOR,
> + INTERCEPT_MC_VECTOR,
> + INTERCEPT_XM_VECTOR,
> + INTERCEPT_VE_VECTOR,
> };
I think it's demanding a lot of the reader to know where there are and
are not gaps in the allocated hardware exception vectors. Perhaps all
of the above enumeration definitions could have initializers? Either
way...
Reviewed-by: Jim Mattson
Re: [PATCH] KVM: x86: Deflect unknown MSR accesses to user space
On 29.07.20 22:37, Jim Mattson wrote: On Wed, Jul 29, 2020 at 1:29 PM Alexander Graf wrote: Meanwhile, I have cleaned up Karim's old patch to add allow listing to KVM and would post it if Aaron doesn't beat me to it :). Ideally, this becomes a collaboration rather than a race to the finish. I'd like to see both proposals, so that we can take the best parts of each! Oh, definitely! I'm not really married to Karim's patch here, it was just simply there and is dead simple. Do you have a rough ETA for Aaron's patch set yet? :) Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
arch/x86/mm/numa.c:925:5: warning: no previous prototype for 'memory_add_physaddr_to_nid'
Hi Dan, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 6ba1b005ffc388c2aeaddae20da29e4810dea298 commit: 7b27a8622f802761d5c6abd6c37b22312a35343c libnvdimm/e820: Retrieve and populate correct 'target_node' info date: 5 months ago config: i386-randconfig-r016-20200729 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce (this is a W=1 build): git checkout 7b27a8622f802761d5c6abd6c37b22312a35343c # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arch/x86/mm/numa.c:925:5: warning: no previous prototype for >> 'memory_add_physaddr_to_nid' [-Wmissing-prototypes] 925 | int memory_add_physaddr_to_nid(u64 start) | ^~ vim +/memory_add_physaddr_to_nid +925 arch/x86/mm/numa.c 5d30f92e7631286 Dan Williams 2020-02-16 924 5d30f92e7631286 Dan Williams 2020-02-16 @925 int memory_add_physaddr_to_nid(u64 start) :: The code at line 925 was first introduced by commit :: 5d30f92e7631286b861c5400c8eadcae50a1 x86/NUMA: Provide a range-to-target_node lookup facility :: TO: Dan Williams :: CC: Dan Williams --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] netfilter: ip6tables: Remove redundant null checks
Applied, thanks.
Re: [PATCH v2] netfilter: Replace HTTP links with HTTPS ones
On Sat, Jul 25, 2020 at 07:02:25PM +0200, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. Applied.
Re: [PATCH] perf bench: Add benchmark of find_next_bit
Em Wed, Jul 29, 2020 at 04:59:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jul 28, 2020 at 08:51:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jul 24, 2020 at 12:19:59AM -0700, Ian Rogers escreveu:
> > > for_each_set_bit, or similar functions like for_each_cpu, may be hot
> > > within the kernel. If many bits were set then one could imagine on
> > > Intel a "bt" instruction with every bit may be faster than the function
> > > call and word length find_next_bit logic. Add a benchmark to measure
> > > this.
> >
> > Thanks, applied.
> > > This benchmark on AMD rome and Intel skylakex shows "bt" is not a good
> > > option except for very small bitmaps.
>
> > > +++ b/tools/perf/bench/find-bit-bench.c
>
> > > +#if defined(__i386__) || defined(__x86_64__)
> > > +static bool asm_test_bit(long nr, const unsigned long *addr)
> > > +{
> > > + bool oldbit;
> > > +
> > > + asm volatile("bt %2,%1"
> > > + : "=@ccc" (oldbit)
> > > + : "m" (*(unsigned long *)addr), "Ir" (nr) : "memory");
> > > +
> > > + return oldbit;
>
> Some old clang versions are not liking this:
Failed with:
clang version 3.8.0 (tags/RELEASE_380/final)
clang version 3.8.1 (tags/RELEASE_381/final)
clang version 4.0.0 (tags/RELEASE_400/final)
Alpine clang version 8.0.0 (tags/RELEASE_800/final) (based on LLVM 8.0.0)
Alpine clang version 5.0.0 (tags/RELEASE_500/final) (based on LLVM 5.0.0)
Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
Alpine clang version 5.0.1 (tags/RELEASE_502/final) (based on LLVM 5.0.1)
Worked with:
Alpine clang version 9.0.0 (https://git.alpinelinux.org/aports
f7f0d2c2b8bcd6a5843401a9a702029556492689) (based on LLVM 9.0.0)
Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git
7445adce501f8473efdb93b17b5eaf2f1445ed4c)
Alpine clang version 10.0.0 (git://git.alpinelinux.org/aports
7445adce501f8473efdb93b17b5eaf2f1445ed4c)
Also failed for;
# grep FAIL dm.log/summary | grep -v alpine
alt:p8: FAIL
clang version 3.8.0 (tags/RELEASE_380/final)
alt:p9: FAIL
clang version 7.0.1
amazonlinux:1: FAIL
clang version 3.6.2 (tags/RELEASE_362/final)
amazonlinux:2: FAIL
clang version 7.0.1 (Amazon Linux 2 7.0.1-1.amzn2.0.2)
#
Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus
On Tue 28 Jul 13:11 PDT 2020, Lina Iyer wrote: > On Tue, Jul 28 2020 at 13:51 -0600, Stephen Boyd wrote: > > Quoting Lina Iyer (2020-07-28 09:52:12) > > > On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote: > > > >Quoting Lina Iyer (2020-07-24 09:28:25) > > > >> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote: > > > >> >Hi Maulik/Lina, > > > >> > > > > >> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote: > > > >> >>Hi Rajendra, > > > >> >> > > > >> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I > > > >> >>see > > > >> >>below messages on db845: > > > >> >> > > > >> >>qcom-venus aa0.video-codec: dev_pm_opp_set_rate: failed to find > > > >> >>current OPP for freq 53397 (-34) > > > >> >> > > > >> >>^^^ This one is new. > > > >> >> > > > >> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x3 > > > >> >> > > > >> >>^^^ and this message is annoying, can we make it pr_debug in rpmh? > > > >> > > > > >> How annoyingly often do you see this message? > > > >> Usually, this is an indication of bad system state either on remote > > > >> processors in the SoC or in Linux itself. On a smooth sailing build you > > > >> should not see this 'warning'. > > > >> > > > >> >Would you be fine with moving this message to a pr_debug? Its > > > >> >currently > > > >> >a pr_info_ratelimited() > > > >> I would rather not, moving this out of sight will mask a lot serious > > > >> issues that otherwise bring attention to the developers. > > > >> > > > > > > > >I removed this warning message in my patch posted to the list[1]. If > > > >it's a serious problem then I suppose a timeout is more appropriate, on > > > >the order of several seconds or so and then a pr_warn() and bail out of > > > >the async call with an error. > > > > > > > The warning used to capture issues that happen within a second and it > > > helps capture system related issues. Timing out after many seconds > > > overlooks the system issues that generally tend to resolve itself, but > > > nevertheless need to be investigated. > > > > > > > Is it correct to read "system related issues" as performance problems > > where the thread is spinning forever trying to send a message and it > > can't? So the problem is mostly that it's an unbounded amount of time > > before the message is sent to rpmh and this printk helps identify those > > situations where that is happening? > > > Yes, but mostly a short period of time like when other processors are in > the middle of a restart or resource states changes have taken unusual > amounts of time. The system will generally recover from this without > crashing in this case. User action is investigation of the situation > leading to these messages. > Given that these messages shows up from time and seemingly is harmless, users such as myself implements the action of ignoring these printouts. In the cases I do see these messages it seems, as you say, to be related to something happening in the firmware. So it's not something that a user typically could investigate/debug anyways. As such I do second Doug's request of not printing what looks like error messages unless there is a persistent problem - but provide some means for the few who would find them useful.. Regards, Bjorn > > Otherwise as you say above it's a bad system state where the rpmh > > processor has gotten into a bad state like a crash? Can we recover from > > that? Or is the only recovery a reboot of the system? Does the rpmh > > processor reboot the system if it crashes? > We cannot recover from such a state. The remote processor will reboot if > it detects a failure at it's end. If the system entered a bad state, it > is possible that RPMH requests start timing out in Linux and remote > processor may not detect it. Hence, the timeout in rpmh_write() API. The > advised course of action is a restart as there is no way to recover from > this state. > > --Lina > >
Re: [RFC][PATCH] locking/refcount: Provide __refcount API to obtain the old value
pet...@infradead.org wrote: > I'm not entirely sure what you mean with interpret, provided you don't > trigger a refcount fail, the number will be just what you expect and > would get from refcount_read(). If you do trigger a fail, you'll get a > negative value. That's fine. I seem to remember talk about the possibility that the number wouldn't necessarily bottom out at zero - for instance if it was arranged such that the overflow flag was set on an overflow or underflow so that it could be trapped on (using INTO or TRAPV, for example). David
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
Hi, Peter,
On Wed, Jul 29, 2020 at 10:49:47AM +0200, pet...@infradead.org wrote:
> On Fri, Jul 17, 2020 at 02:35:00PM -0700, Fenghua Yu wrote:
>
> > #DB for bus lock detect fixes all issues in #AC for split lock detect:
> > 1) It's architectural ... just need to look at one CPUID bit to know it
> >exists
> > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread.
> >So each process or guest can have different behavior.
>
> And it generates a whole new problem due to #DB being an IST, and
>
> > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > index b038695f36c5..58725567da39 100644
> > --- a/arch/x86/kernel/traps.c
> > +++ b/arch/x86/kernel/traps.c
> > @@ -812,6 +812,16 @@ static void handle_debug(struct pt_regs *regs,
> > unsigned long dr6, bool user)
> > if (!user && !dr6)
> > return;
> >
> > + /* Handle bus lock. */
> > + if (!(dr6 & DR_BUS_LOCK)) {
> > + cond_local_irq_enable(regs);
> > + if (user)
> > + handle_user_bus_lock(regs);
> > + else
> > + handle_kernel_bus_lock(regs);
> > + goto out;
> > + }
> > +
> > /*
> > * If dr6 has no reason to give us about the origin of this trap,
> > * then it's very likely the result of an icebp/int01 trap.
>
> we very much rely on #DB never recursing, which we carefully crafted by
> disallowing hardare breakpoints on noinstr code and clearing DR7 early.
>
> But now it can... please keep the pieces.
Can we disable Bus Lock Detection before handle it and re-enable it
after handle it? Will that resolve the recursion issue?
Thanks.
-Fenghua
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
On Wed, Jul 29, 2020 at 08:35:57PM +, Fenghua Yu wrote: > Hi, Sean, > > On Wed, Jul 29, 2020 at 01:00:33PM -0700, Sean Christopherson wrote: > > On Wed, Jul 29, 2020 at 07:42:59PM +, Fenghua Yu wrote: > > > > Smushing the two into a single option is confusing, e.g. from the table > > > > below it's not at all clear what will happen if sld=fatal, both features > > > > are supported, and the kernel generates a split lock. > > > > > > > > Given that both SLD (per-core, not architectural) and BLD (#DB > > > > recursion and > > > > inverted DR6 flag) have warts, it would be very nice to enable/disable > > > > them > > > > independently. The lock to non-WB behavior for BLD may also be > > > > problematic, > > > > e.g. maybe it turns out that fixing drivers to avoid locks to non-WB > > > > isn't > > > > as straightforward as avoiding split locks. > > > > > > But the two features are related if both of them are enabled in hardware: > > > If a split lock happens, SLD will generate #AC before instruction > > > execution > > > and BLD will generate #DB after instruction execution. > > > > > > The software needs to make them exclusive. The same kernel option reflects > > > the relationship and make them exclusive, e.g. "fatal" enables SLD and > > > disables BLD, "warn" does the other way. > > > > Why do they need to be exclusive? We've already established that BLD > > catches > > things that SLD does not. What's wrong with running sld=fatal and > > bld=ratelimit > > so that split locks never happen and kill applications, and non-WB locks are > > are ratelimited? > > Sorry if I didn't explain bus lock and split lock detections clearly before. > > There are two causes of bus locks: > 1. a locked access across cache line boundary: this is split lock. > 2. a locked access to non-WB memory. > > BLD detects both causes and SLD only detects the first one, i.e. BLD can > detect > both split lock AND lock to non-WB memory. > > If sld=fatal and bld=ratelimit (both sld and bld are enabled in hw), > a split lock always generates #AC and kills the app and bld will never have > a chance to trigger #DB for split lock. So effectively the combination makes > the kernel to take two different actions after detecting a bus lock: if the > bus lock comes from a split lock, fatal (sld); if the bus lock comes from > lock to non-WB memory, ratelimit (bld). Seems this is not a useful combination > and is not what the user really wants to do because the user wants ratelimit > for BLD, right? I understood all off that. And as I user I want to run sld=fatal and bld=ratelimit to provide maximum protection, i.e. disallow split locks at all times, and ratelimit the crud SLD #AC can't catch.
Re: [PATCH] lib: kunit: add test_min_heap test conversion to KUnit
On Wed, Jul 29, 2020 at 05:11:46PM -0300, Vitor Massaru Iha wrote:
> This adds the conversion of the runtime tests of test_min_heap,
> from `lib/test_min_heap.c` to KUnit tests.
>
> Please apply this commit first (linux-kselftest/kunit-fixes):
> 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of
> CONFIG options with space
>
> Signed-off-by: Vitor Massaru Iha
> ---
> lib/Kconfig.debug | 29 --
> lib/Makefile | 2 +-
> lib/{test_min_heap.c => min_heap_kunit.c} | 117 --
> 3 files changed, 83 insertions(+), 65 deletions(-)
> rename lib/{test_min_heap.c => min_heap_kunit.c} (60%)
So where's the win? What's KUnit, why should I care and more lines.
Re: [PATCH] test_power: Fix battery_current initial value
Hi, On Wed, Jul 29, 2020 at 08:14:00PM +0800, lh lin wrote: > From: LH Lin > > Since default battery_status is POWER_SUPPLY_STATUS_DISCHARGING, > we should change default battery_current to a negative value. > > Signed-off-by: LH Lin > --- Thanks, queued. -- Sebastian > drivers/power/supply/test_power.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/power/supply/test_power.c > b/drivers/power/supply/test_power.c > index 65c23ef6408d..4f29f0f096f5 100644 > --- a/drivers/power/supply/test_power.c > +++ b/drivers/power/supply/test_power.c > @@ -34,7 +34,7 @@ static int battery_technology = > POWER_SUPPLY_TECHNOLOGY_LION; > static int battery_capacity = 50; > static int battery_voltage = 3300; > static int battery_charge_counter= -1000; > -static int battery_current = 1600; > +static int battery_current = -1600; > > static bool module_initialized; > > -- > 2.18.0 signature.asc Description: PGP signature
Re: [PATCH v6 4/4] power: supply: bq27xxx_battery: Add the BQ28z610 Battery monitor
Hi,
On Wed, Jul 29, 2020 at 01:31:45PM -0500, Dan Murphy wrote:
> Add the Texas Instruments BQ28z610 battery monitor.
> The register address map is laid out the same as compared to other
> devices within the file.
>
> The battery status register bits are similar to the bq27z561 but they
> are different compared to other fuel gauge devices within this file.
>
> Signed-off-by: Dan Murphy
> ---
Thanks, queued.
-- Sebastian
> drivers/power/supply/bq27xxx_battery.c | 42 ++
> drivers/power/supply/bq27xxx_battery_i2c.c | 2 ++
> include/linux/power/bq27xxx_battery.h | 1 +
> 3 files changed, 45 insertions(+)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c
> b/drivers/power/supply/bq27xxx_battery.c
> index a05b9a2d112d..a123f6e21f08 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -44,6 +44,7 @@
> * https://www.ti.com/product/bq27441-g1
> * https://www.ti.com/product/bq27621-g1
> * https://www.ti.com/product/bq27z561
> + * https://www.ti.com/product/bq28z610
> */
>
> #include
> @@ -462,6 +463,26 @@ static u8
> [BQ27XXX_REG_DCAP] = 0x3c,
> [BQ27XXX_REG_AP] = 0x22,
> BQ27XXX_DM_REG_ROWS,
> + },
> + bq28z610_regs[BQ27XXX_REG_MAX] = {
> + [BQ27XXX_REG_CTRL] = 0x00,
> + [BQ27XXX_REG_TEMP] = 0x06,
> + [BQ27XXX_REG_INT_TEMP] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_VOLT] = 0x08,
> + [BQ27XXX_REG_AI] = 0x14,
> + [BQ27XXX_REG_FLAGS] = 0x0a,
> + [BQ27XXX_REG_TTE] = 0x16,
> + [BQ27XXX_REG_TTF] = 0x18,
> + [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_FCC] = 0x12,
> + [BQ27XXX_REG_CYCT] = 0x2a,
> + [BQ27XXX_REG_AE] = 0x22,
> + [BQ27XXX_REG_SOC] = 0x2c,
> + [BQ27XXX_REG_DCAP] = 0x3c,
> + [BQ27XXX_REG_AP] = 0x22,
> + BQ27XXX_DM_REG_ROWS,
> };
>
> static enum power_supply_property bq27000_props[] = {
> @@ -717,6 +738,25 @@ static enum power_supply_property bq27z561_props[] = {
> POWER_SUPPLY_PROP_MANUFACTURER,
> };
>
> +static enum power_supply_property bq28z610_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_CAPACITY,
> + POWER_SUPPLY_PROP_CAPACITY_LEVEL,
> + POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
> + POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_CHARGE_FULL,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CYCLE_COUNT,
> + POWER_SUPPLY_PROP_POWER_AVG,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_MANUFACTURER,
> +};
> +
> struct bq27xxx_dm_reg {
> u8 subclass_id;
> u8 offset;
> @@ -813,6 +853,7 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
> #endif
>
> #define bq27z561_dm_regs 0
> +#define bq28z610_dm_regs 0
>
> #define BQ27XXX_O_ZERO 0x0001
> #define BQ27XXX_O_OTDC 0x0002 /* has OTC/OTD overtemperature flags
> */
> @@ -865,6 +906,7 @@ static struct {
> [BQ27441] = BQ27XXX_DATA(bq27441, 0x80008000, BQ27XXX_O_UTOT |
> BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
> [BQ27621] = BQ27XXX_DATA(bq27621, 0x80008000, BQ27XXX_O_UTOT |
> BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
> [BQ27Z561] = BQ27XXX_DATA(bq27z561, 0 , BQ27Z561_O_BITS),
> + [BQ28Z610] = BQ27XXX_DATA(bq28z610, 0 , BQ27Z561_O_BITS),
> };
>
> static DEFINE_MUTEX(bq27xxx_list_lock);
> diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c
> b/drivers/power/supply/bq27xxx_battery_i2c.c
> index 15f4e75786ab..ab02456d69e5 100644
> --- a/drivers/power/supply/bq27xxx_battery_i2c.c
> +++ b/drivers/power/supply/bq27xxx_battery_i2c.c
> @@ -254,6 +254,7 @@ static const struct i2c_device_id bq27xxx_i2c_id_table[]
> = {
> { "bq27441", BQ27441 },
> { "bq27621", BQ27621 },
> { "bq27z561", BQ27Z561 },
> + { "bq28z610", BQ28Z610 },
> {},
> };
> MODULE_DEVICE_TABLE(i2c, bq27xxx_i2c_id_table);
> @@ -288,6 +289,7 @@ static const struct of_device_id
> bq27xxx_battery_i2c_of_match_table[] = {
> { .compatible = "ti,bq27441" },
> { .compatible = "ti,bq27621" },
> { .compatible = "ti,bq27z561" },
> + { .compatible = "ti,bq28z610" },
> {},
> };
> MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);
> diff --git a/include/linux/power/bq27xxx_battery.h
> b/include/linux/power/bq27xxx_battery.h
> index 1f6ea5d5063d..987d9652aa4e 100644
> --- a/include/linux/power/bq27xxx_battery.h
> +++ b/include/linux/power/bq27xxx_battery.h
> @@ -31,6 +31,7 @@ enum bq27xxx_chip {
> BQ27441,
>
Re: [PATCH v6 3/4] dt-bindings: power: Add BQ28z610 compatible
Hi, On Wed, Jul 29, 2020 at 01:31:44PM -0500, Dan Murphy wrote: > Add the Texas Instruments bq28z610 battery monitor to the bq27xxx > binding. > > Acked-by: Rob Herring > Signed-off-by: Dan Murphy > --- Thanks, queued. -- Sebastian > Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > index 0aa33590ac24..82f682705f44 100644 > --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > @@ -50,6 +50,7 @@ properties: >- ti,bq27441 >- ti,bq27621 >- ti,bq27z561 > + - ti,bq28z610 > >reg: > maxItems: 1 > -- > 2.28.0 > signature.asc Description: PGP signature
Re: [PATCH v6 2/4] power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor
Hi,
On Wed, Jul 29, 2020 at 01:31:43PM -0500, Dan Murphy wrote:
> Add the Texas Instruments BQ27Z561 battery monitor. The register address
> map is laid out the same as compared to other devices within the file.
> The battery status register has differing bits to determine if the
> battery is full, discharging or dead.
>
> Signed-off-by: Dan Murphy
> ---
Thanks, queued.
-- Sebastian
> drivers/power/supply/bq27xxx_battery.c | 68 +-
> drivers/power/supply/bq27xxx_battery_i2c.c | 2 +
> include/linux/power/bq27xxx_battery.h | 1 +
> 3 files changed, 70 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c
> b/drivers/power/supply/bq27xxx_battery.c
> index acaafed037be..a05b9a2d112d 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -43,6 +43,7 @@
> * https://www.ti.com/product/bq27411-g1
> * https://www.ti.com/product/bq27441-g1
> * https://www.ti.com/product/bq27621-g1
> + * https://www.ti.com/product/bq27z561
> */
>
> #include
> @@ -79,6 +80,11 @@
> #define BQ27000_FLAG_FC BIT(5)
> #define BQ27000_FLAG_CHGSBIT(7) /* Charge state flag */
>
> +/* BQ27Z561 has different layout for Flags register */
> +#define BQ27Z561_FLAG_FDCBIT(4) /* Battery fully discharged */
> +#define BQ27Z561_FLAG_FC BIT(5) /* Battery fully charged */
> +#define BQ27Z561_FLAG_DIS_CH BIT(6) /* Battery is discharging */
> +
> /* control register params */
> #define BQ27XXX_SEALED 0x20
> #define BQ27XXX_SET_CFGUPDATE0x13
> @@ -431,12 +437,32 @@ static u8
> [BQ27XXX_REG_DCAP] = 0x3c,
> [BQ27XXX_REG_AP] = 0x18,
> BQ27XXX_DM_REG_ROWS,
> - };
> + },
> #define bq27411_regs bq27421_regs
> #define bq27425_regs bq27421_regs
> #define bq27426_regs bq27421_regs
> #define bq27441_regs bq27421_regs
> #define bq27621_regs bq27421_regs
> + bq27z561_regs[BQ27XXX_REG_MAX] = {
> + [BQ27XXX_REG_CTRL] = 0x00,
> + [BQ27XXX_REG_TEMP] = 0x06,
> + [BQ27XXX_REG_INT_TEMP] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_VOLT] = 0x08,
> + [BQ27XXX_REG_AI] = 0x14,
> + [BQ27XXX_REG_FLAGS] = 0x0a,
> + [BQ27XXX_REG_TTE] = 0x16,
> + [BQ27XXX_REG_TTF] = 0x18,
> + [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_FCC] = 0x12,
> + [BQ27XXX_REG_CYCT] = 0x2a,
> + [BQ27XXX_REG_AE] = 0x22,
> + [BQ27XXX_REG_SOC] = 0x2c,
> + [BQ27XXX_REG_DCAP] = 0x3c,
> + [BQ27XXX_REG_AP] = 0x22,
> + BQ27XXX_DM_REG_ROWS,
> + };
>
> static enum power_supply_property bq27000_props[] = {
> POWER_SUPPLY_PROP_STATUS,
> @@ -672,6 +698,25 @@ static enum power_supply_property bq27421_props[] = {
> #define bq27441_props bq27421_props
> #define bq27621_props bq27421_props
>
> +static enum power_supply_property bq27z561_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_CAPACITY,
> + POWER_SUPPLY_PROP_CAPACITY_LEVEL,
> + POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
> + POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_CHARGE_FULL,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CYCLE_COUNT,
> + POWER_SUPPLY_PROP_POWER_AVG,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_MANUFACTURER,
> +};
> +
> struct bq27xxx_dm_reg {
> u8 subclass_id;
> u8 offset;
> @@ -767,11 +812,14 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
> #define bq27621_dm_regs 0
> #endif
>
> +#define bq27z561_dm_regs 0
> +
> #define BQ27XXX_O_ZERO 0x0001
> #define BQ27XXX_O_OTDC 0x0002 /* has OTC/OTD overtemperature flags
> */
> #define BQ27XXX_O_UTOT 0x0004 /* has OT overtemperature flag */
> #define BQ27XXX_O_CFGUP 0x0008
> #define BQ27XXX_O_RAM0x0010
> +#define BQ27Z561_O_BITS 0x0020
>
> #define BQ27XXX_DATA(ref, key, opt) {\
> .opts = (opt), \
> @@ -816,6 +864,7 @@ static struct {
> [BQ27426] = BQ27XXX_DATA(bq27426, 0x80008000, BQ27XXX_O_UTOT |
> BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
> [BQ27441] = BQ27XXX_DATA(bq27441, 0x80008000, BQ27XXX_O_UTOT |
> BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
> [BQ27621] = BQ27XXX_DATA(bq27621, 0x80008000, BQ27XXX_O_UTOT |
> BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
> + [BQ27Z561] = BQ27XXX_DATA(bq27z561, 0 , BQ27Z561_O_BITS),
> };
>
> static DEFINE_MUTEX(bq27xxx_list_lock);
> @@ -1551,6 +1600,8 @@ static
Re: [PATCH v6 1/4] dt-bindings: power: Add BQ27Z561 compatible
Hi, On Wed, Jul 29, 2020 at 01:31:42PM -0500, Dan Murphy wrote: > Add the Texas Instruments bq27z561 battery monitor to the bq27xxx > binding. > > Acked-by: Rob Herring > Signed-off-by: Dan Murphy > --- Thanks, queued. -- Sebastian > Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > index 03d1020a2e47..0aa33590ac24 100644 > --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml > @@ -49,6 +49,7 @@ properties: >- ti,bq27426 >- ti,bq27441 >- ti,bq27621 > + - ti,bq27z561 > >reg: > maxItems: 1 > -- > 2.28.0 > signature.asc Description: PGP signature
Re: [PATCH 2/2] ASoC: Intel: Add period size constraint on strago board
On 7/29/20 6:03 AM, Brent Lu wrote: From: Yu-Hsuan Hsu The CRAS server does not set the period size in hw_param so ALSA will calculate a value for period size which is based on the buffer size and other parameters. The value may not always be aligned with Atom's dsp design so a constraint is added to make sure the board always has a good value. Cyan uses chtmax98090 and others(banon, celes, edgar, kefka...) use rt5650. Is this patch required if you've already constrained the period sizes for the platform driver in patch1?
Re: [PATCH] KVM: x86: Deflect unknown MSR accesses to user space
On Wed, Jul 29, 2020 at 1:29 PM Alexander Graf wrote: > Meanwhile, I have cleaned up Karim's old patch to add allow listing to > KVM and would post it if Aaron doesn't beat me to it :). Ideally, this becomes a collaboration rather than a race to the finish. I'd like to see both proposals, so that we can take the best parts of each!
Re: Inverted mount options completely broken (iversion,relatime)
Josef Bacik wrote: > So my question is, what do we do here? Hmmm... As the code stands, MS_RDONLY, MS_SYNCHRONOUS, MS_MANDLOCK, MS_I_VERSION and MS_LAZYTIME should all be masked off before the new flags are set if called from mount(2) rather than fsconfig(2). do_remount() gives MS_RMT_MASK to fs_context_for_reconfigure() to load into fc->sb_flags_mask, which should achieve the desired effect in reconfigure_super() on this line: WRITE_ONCE(sb->s_flags, ((sb->s_flags & ~fc->sb_flags_mask) | (fc->sb_flags & fc->sb_flags_mask))); David
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
Hi, Sean, On Wed, Jul 29, 2020 at 01:00:33PM -0700, Sean Christopherson wrote: > On Wed, Jul 29, 2020 at 07:42:59PM +, Fenghua Yu wrote: > > > Smushing the two into a single option is confusing, e.g. from the table > > > below it's not at all clear what will happen if sld=fatal, both features > > > are supported, and the kernel generates a split lock. > > > > > > Given that both SLD (per-core, not architectural) and BLD (#DB recursion > > > and > > > inverted DR6 flag) have warts, it would be very nice to enable/disable > > > them > > > independently. The lock to non-WB behavior for BLD may also be > > > problematic, > > > e.g. maybe it turns out that fixing drivers to avoid locks to non-WB isn't > > > as straightforward as avoiding split locks. > > > > But the two features are related if both of them are enabled in hardware: > > If a split lock happens, SLD will generate #AC before instruction execution > > and BLD will generate #DB after instruction execution. > > > > The software needs to make them exclusive. The same kernel option reflects > > the relationship and make them exclusive, e.g. "fatal" enables SLD and > > disables BLD, "warn" does the other way. > > Why do they need to be exclusive? We've already established that BLD catches > things that SLD does not. What's wrong with running sld=fatal and > bld=ratelimit > so that split locks never happen and kill applications, and non-WB locks are > are ratelimited? Sorry if I didn't explain bus lock and split lock detections clearly before. There are two causes of bus locks: 1. a locked access across cache line boundary: this is split lock. 2. a locked access to non-WB memory. BLD detects both causes and SLD only detects the first one, i.e. BLD can detect both split lock AND lock to non-WB memory. If sld=fatal and bld=ratelimit (both sld and bld are enabled in hw), a split lock always generates #AC and kills the app and bld will never have a chance to trigger #DB for split lock. So effectively the combination makes the kernel to take two different actions after detecting a bus lock: if the bus lock comes from a split lock, fatal (sld); if the bus lock comes from lock to non-WB memory, ratelimit (bld). Seems this is not a useful combination and is not what the user really wants to do because the user wants ratelimit for BLD, right? > > If using two different kernel options, the user needs to give right options > > to make both work, e.g. can the user give this combination > > "split_lock_detect=fatal bus_lock_detect=warn"? What does the combination > > mean? > > Split locks are fatal, non-WB locks are logged but not fatal. Similar here: bus lock from a split lock is fatal (sld triggers #AC) and bus lock from lock to non-WB mem is warn (bld triggers #DB). Seems not what the user really wants, right? Thanks. -Fenghua
Re: [PATCH v3 4/4] vfio/type1: Use iommu_aux_at(de)tach_group() APIs
On Tue, 14 Jul 2020 13:57:03 +0800
Lu Baolu wrote:
> Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
> It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
> vfio_group data structure so that it could be reused in other places.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/vfio/vfio_iommu_type1.c | 44 ++---
> 1 file changed, 7 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5e556ac9102a..f8812e68de77 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -100,6 +100,7 @@ struct vfio_dma {
> struct vfio_group {
> struct iommu_group *iommu_group;
> struct list_headnext;
> + struct device *iommu_device;
> boolmdev_group; /* An mdev group */
> boolpinned_page_dirty_scope;
> };
> @@ -1627,45 +1628,13 @@ static struct device
> *vfio_mdev_get_iommu_device(struct device *dev)
> return NULL;
> }
>
> -static int vfio_mdev_attach_domain(struct device *dev, void *data)
> -{
> - struct iommu_domain *domain = data;
> - struct device *iommu_device;
> -
> - iommu_device = vfio_mdev_get_iommu_device(dev);
> - if (iommu_device) {
> - if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
> - return iommu_aux_attach_device(domain, iommu_device);
> - else
> - return iommu_attach_device(domain, iommu_device);
> - }
> -
> - return -EINVAL;
> -}
> -
> -static int vfio_mdev_detach_domain(struct device *dev, void *data)
> -{
> - struct iommu_domain *domain = data;
> - struct device *iommu_device;
> -
> - iommu_device = vfio_mdev_get_iommu_device(dev);
> - if (iommu_device) {
> - if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
> - iommu_aux_detach_device(domain, iommu_device);
> - else
> - iommu_detach_device(domain, iommu_device);
> - }
> -
> - return 0;
> -}
> -
> static int vfio_iommu_attach_group(struct vfio_domain *domain,
> struct vfio_group *group)
> {
> if (group->mdev_group)
> - return iommu_group_for_each_dev(group->iommu_group,
> - domain->domain,
> - vfio_mdev_attach_domain);
> + return iommu_aux_attach_group(domain->domain,
> + group->iommu_group,
> + group->iommu_device);
No, we previously iterated all devices in the group and used the aux
interface only when we have an iommu_device supporting aux. If we
simply assume an mdev group only uses an aux domain we break existing
users, ex. SR-IOV VF backed mdevs. Thanks,
Alex
> else
> return iommu_attach_group(domain->domain, group->iommu_group);
> }
> @@ -1674,8 +1643,8 @@ static void vfio_iommu_detach_group(struct vfio_domain
> *domain,
> struct vfio_group *group)
> {
> if (group->mdev_group)
> - iommu_group_for_each_dev(group->iommu_group, domain->domain,
> - vfio_mdev_detach_domain);
> + iommu_aux_detach_group(domain->domain, group->iommu_group,
> +group->iommu_device);
> else
> iommu_detach_group(domain->domain, group->iommu_group);
> }
> @@ -2007,6 +1976,7 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> return 0;
> }
>
> + group->iommu_device = iommu_device;
> bus = iommu_device->bus;
> }
>
Re: [PATCH] net/mlx5e: fix bpf_prog refcnt leaks in mlx5e_alloc_rq
From: Saeed Mahameed
Date: Wed, 29 Jul 2020 19:02:15 +
> On Wed, 2020-07-29 at 20:33 +0800, Xin Xiong wrote:
>> The function invokes bpf_prog_inc(), which increases the refcount of
>> a
>> bpf_prog object "rq->xdp_prog" if the object isn't NULL.
>>
>> The refcount leak issues take place in two error handling paths. When
>> mlx5_wq_ll_create() or mlx5_wq_cyc_create() fails, the function
>> simply
>> returns the error code and forgets to drop the refcount increased
>> earlier, causing a refcount leak of "rq->xdp_prog".
>>
>> Fix this issue by jumping to the error handling path
>> err_rq_wq_destroy
>> when either function fails.
>>
>
> Fixes: 422d4c401edd ("net/mlx5e: RX, Split WQ objects for different RQ
> types")
Saeed, are you going to take this into your tree or would you like me to
apply it directly?
Thanks.
Re: [PATCH] KVM: x86: Deflect unknown MSR accesses to user space
On 29.07.20 20:27, Jim Mattson wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On Wed, Jul 29, 2020 at 2:06 AM Alexander Graf wrote:
On 28.07.20 19:13, Jim Mattson wrote:
This sounds similar to Peter Hornyack's RFC from 5 years ago:
https://www.mail-archive.com/kvm@vger.kernel.org/msg124448.html.
Yeah, looks very similar. Do you know the history why it never got
merged? I couldn't spot a non-RFC version of this on the ML.
I believe Peter got frustrated with all of the pushback he was
getting, and he moved on to other things. While Google still uses that
code, Aaron's new approach should give us equivalent functionality
without having to comment out the MSRs that kvm previously didn't know
about, and which we still want redirected to userspace.
It seems unlikely that userspace is going to know what to do with a
large number of MSRs. I suspect that a small enumerated list will
suffice. In fact, +Aaron Lewis is working on upstreaming a local
Google patch set that does just that.
I tend to disagree on that sentiment. One of the motivations behind this
patch is to populate invalid MSR accesses into user space, to move logic
like "ignore_msrs"[1] into user space. This is not very useful for the
cloud use case, but it does come in handy when you want to have VMs that
can handle unimplemented MSRs in parallel to ones that do not.
So whatever we implement, I would ideally want a mechanism at the end of
the day that allows me to "trap the rest" into user space.
I do think "the rest" should be explicitly specified, so that
userspace doesn't get surprises when kvm evolves. Maybe this can be
done using the allow-list you refer to later, along with a specified
action for disallowed MSRs: (1) raise #GP, (2) ignore, or (3) exit to
userspace. This actually seems orthogonal to what Aaron is working on,
which is to request that specific MSR accesses exit to userspace. But,
at least the plumbing for {RD,WR}MSR completion when coming back from
userspace can be leveraged by both.
Thinking about this for a while, I am quite confident that we don't need
to complexify this all that much. The #GP path is never performance
critical and thus can easily be handled in user space. There are a few
niche cases where exiting to user space is "too complicated" (think nVMX
MSR restore path). But they are niche and just bailing out for the user
space exit path on them is fine.
So I think a patch that allows us to allow list MSRs that should be
handled in KVM and another patch that allows us to deflect any MSR
inflicted #GPs into user space is all it takes to make this a flexible
and stable ABI.
The great thing is that by untangling the two bits, we can also support
the "user space wants to leave it all to KVM, but be able to implement
ignore_msrs itself" use case easily. User space would just not set an
allow list.
Meanwhile, I have cleaned up Karim's old patch to add allow listing to
KVM and would post it if Aaron doesn't beat me to it :).
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Re: [PATCH net-next] fib: fix fib_rules_ops indirect calls wrappers
From: Brian Vazquez
Date: Wed, 29 Jul 2020 11:10:18 -0700
> This patch fixes:
> commit b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
> fib_rules_ops") which didn't consider the case when
> CONFIG_IPV6_MULTIPLE_TABLES is not set.
>
> Reported-by: Stephen Rothwell
> Fixes: b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
> fib_rules_ops")
> Signed-off-by: Brian Vazquez
Applied, thanks Brian.
Re: [PATCH v3 3/4] iommu: Add iommu_aux_get_domain_for_dev()
On Tue, 14 Jul 2020 13:57:02 +0800
Lu Baolu wrote:
> The device driver needs an API to get its aux-domain. A typical usage
> scenario is:
>
> unsigned long pasid;
> struct iommu_domain *domain;
> struct device *dev = mdev_dev(mdev);
> struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
>
> domain = iommu_aux_get_domain_for_dev(dev);
> if (!domain)
> return -ENODEV;
>
> pasid = iommu_aux_get_pasid(domain, iommu_device);
> if (pasid <= 0)
> return -EINVAL;
>
> /* Program the device context */
>
>
> This adds an API for such use case.
>
> Suggested-by: Alex Williamson
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommu.c | 18 ++
> include/linux/iommu.h | 7 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index cad5a19ebf22..434bf42b6b9b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2817,6 +2817,24 @@ void iommu_aux_detach_group(struct iommu_domain
> *domain,
> }
> EXPORT_SYMBOL_GPL(iommu_aux_detach_group);
>
> +struct iommu_domain *iommu_aux_get_domain_for_dev(struct device *dev)
> +{
> + struct iommu_domain *domain = NULL;
> + struct iommu_group *group;
> +
> + group = iommu_group_get(dev);
> + if (!group)
> + return NULL;
> +
> + if (group->aux_domain_attached)
> + domain = group->domain;
Why wouldn't the aux domain flag be on the domain itself rather than
the group? Then if we wanted sanity checking in patch 1/ we'd only
need to test the flag on the object we're provided.
If we had such a flag, we could create an iommu_domain_is_aux()
function and then simply use iommu_get_domain_for_dev() and test that
it's an aux domain in the example use case. It seems like that would
resolve the jump from a domain to an aux-domain just as well as adding
this separate iommu_aux_get_domain_for_dev() interface. The is_aux
test might also be useful in other cases too. Thanks,
Alex
> +
> + iommu_group_put(group);
> +
> + return domain;
> +}
> +EXPORT_SYMBOL_GPL(iommu_aux_get_domain_for_dev);
> +
> /**
> * iommu_sva_bind_device() - Bind a process address space to a device
> * @dev: the device
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 9506551139ab..cda6cef7579e 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -639,6 +639,7 @@ int iommu_aux_attach_group(struct iommu_domain *domain,
> struct iommu_group *group, struct device *dev);
> void iommu_aux_detach_group(struct iommu_domain *domain,
> struct iommu_group *group, struct device *dev);
> +struct iommu_domain *iommu_aux_get_domain_for_dev(struct device *dev);
>
> struct iommu_sva *iommu_sva_bind_device(struct device *dev,
> struct mm_struct *mm,
> @@ -1040,6 +1041,12 @@ iommu_aux_detach_group(struct iommu_domain *domain,
> {
> }
>
> +static inline struct iommu_domain *
> +iommu_aux_get_domain_for_dev(struct device *dev)
> +{
> + return NULL;
> +}
> +
> static inline struct iommu_sva *
> iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void
> *drvdata)
> {
general protection fault in security_inode_getattr
Hello, syzbot found the following issue on: HEAD commit:92ed3019 Linux 5.8-rc7 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=140003ac90 kernel config: https://syzkaller.appspot.com/x/.config?x=84f076779e989e69 dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f07cc9be8d1d22694...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc0c: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0060-0x0067] CPU: 0 PID: 9214 Comm: syz-executor.3 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline] RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b RSP: 0018:c9000d41f638 EFLAGS: 00010206 RAX: dc00 RBX: RCX: c9000f539000 RDX: 000c RSI: 8354f8ee RDI: 0060 RBP: c9000d41f810 R08: 0001 R09: 88804edc2dc8 R10: R11: 000ebc58 R12: 888089f10170 R13: c9000d41f810 R14: 07ff R15: FS: 7f3599717700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2c12c000 CR3: 99919000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: vfs_getattr+0x22/0x60 fs/stat.c:121 ovl_copy_up_one+0x13b/0x1870 fs/overlayfs/copy_up.c:850 ovl_copy_up_flags+0x14b/0x1d0 fs/overlayfs/copy_up.c:931 ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:963 ovl_open+0xba/0x270 fs/overlayfs/file.c:147 do_dentry_open+0x501/0x1290 fs/open.c:828 do_open fs/namei.c:3243 [inline] path_openat+0x1bb9/0x2750 fs/namei.c:3360 do_filp_open+0x17e/0x3c0 fs/namei.c:3387 file_open_name+0x290/0x400 fs/open.c:1124 acct_on+0x78/0x770 kernel/acct.c:207 __do_sys_acct kernel/acct.c:286 [inline] __se_sys_acct kernel/acct.c:273 [inline] __x64_sys_acct+0xab/0x1f0 kernel/acct.c:273 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45c369 Code: 8d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f3599716c78 EFLAGS: 0246 ORIG_RAX: 00a3 RAX: ffda RBX: 0700 RCX: 0045c369 RDX: RSI: RDI: 2440 RBP: 0078bf30 R08: R09: R10: R11: 0246 R12: 0078bf0c R13: 7ffda41ffbef R14: 7f35997179c0 R15: 0078bf0c Modules linked in: ---[ end trace d1398a63985d3915 ]--- RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline] RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b RSP: 0018:c9000d41f638 EFLAGS: 00010206 RAX: dc00 RBX: RCX: c9000f539000 RDX: 000c RSI: 8354f8ee RDI: 0060 RBP: c9000d41f810 R08: 0001 R09: 88804edc2dc8 R10: R11: 000ebc58 R12: 888089f10170 R13: c9000d41f810 R14: 07ff R15: FS: 7f3599717700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2440 CR3: 99919000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH] perf/x86/svm: Convert 'perf kvm stat report' output lowercase to uppercase
On Tue, Jul 28, 2020 at 11:24 PM Haiwei Li wrote: > > From: Haiwei Li > > The reason output of 'perf kvm stat report --event=vmexit' is uppercase > on VMX and lowercase on SVM. > > To be consistent with VMX, convert lowercase to uppercase. > > Signed-off-by: Haiwei Li Please don't do this. It breaks an existing ABI.
Re: [PATCH 1/7] clk: samsung: s3c64xx: Declare s3c64xx_clk_init() in shared header
On Wed, Jul 29, 2020 at 12:42:43PM -0700, Stephen Boyd wrote:
> Quoting Krzysztof Kozlowski (2020-07-29 09:09:36)
> > diff --git a/include/linux/clk/samsung.h b/include/linux/clk/samsung.h
> > new file mode 100644
> > index ..b6b253c46c22
> > --- /dev/null
> > +++ b/include/linux/clk/samsung.h
> > @@ -0,0 +1,21 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (c) 2020 Krzysztof Kozlowski
> > + */
> > +
> > +#ifndef __LINUX_CLK_SAMSUNG_H_
> > +#define __LINUX_CLK_SAMSUNG_H_
> > +
> > +#ifdef CONFIG_ARCH_S3C64XX
> > +void __init s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
>
> Don't use __init in header files. It doesn't do anything.
>
> > +unsigned long xusbxti_f, bool s3c6400,
> > +void __iomem *base);
> > +#else
> > +static inline void __init s3c64xx_clk_init(struct device_node *np,
>
> Forward declare struct device_node;
>
> > + unsigned long xtal_f,
> > + unsigned long xusbxti_f,
> > + bool s3c6400,
> > + void __iomem *base) { }
>
> Include (or compiler_types.h) for __iomem define
> please.
Thanks for the feedback. I'll send v2.
Best regards,
Krzysztof
Re: [PATCH v2] lib: kunit: Convert test_sort to KUnit test
On Wed, Jul 29, 2020 at 4:19 PM Andy Shevchenko
wrote:
>
> On Wed, Jul 29, 2020 at 04:11:51PM -0300, Vitor Massaru Iha wrote:
> > This adds the conversion of the test_sort.c to KUnit test.
> >
> > Please apply this commit first (linux-kselftest/kunit-fixes):
> > 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing
> > of CONFIG options with space
>
> Looks like you mixed up commit message and changelog / comments.
>
> > Code Style Documentation: [0]
> >
> > Fix these warnings Reported-by l...@intel.com
> >
> > WARNING: modpost: vmlinux.o(.data+0x4fc70): Section mismatch in reference
> > from the variable sort_test_cases to the variable .init.text:sort_test
> >The variable sort_test_cases references
> >the variable __init sort_test
> >If the reference is valid then annotate the
> >variable with or __refdata (see linux/init.h) or name the variable
> >
> > WARNING: modpost: lib/sort_kunit.o(.data+0x11c): Section mismatch in
> > reference from the variable sort_test_cases to the function
> > .init.text:sort_test()
> >The variable sort_test_cases references
> >the function __init sort_test()
>
> > Signed-off-by: Vitor Massaru Iha
> > Reported-by: kernel test robot
> > Link: [0]
> > https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u
>
> This should be in different order: Link, Reported-by, SoB.
> Also [0] is unnecessary
Sure, thanks!
>
> > lib/{test_sort.c => sort_kunit.c} | 31 +++
>
> Still opened question why kunit is a suffix? Can't we leave same name? Can't
> we
> do it rather prefix?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Re: [PATCH 0/7] ARM: samsung: Cleanup of various S3C bits
On Wed, Jul 29, 2020 at 10:01:26PM +0200, Arnd Bergmann wrote: > On Wed, Jul 29, 2020 at 6:11 PM Krzysztof Kozlowski wrote: > > > > Hi, > > > > I tried to cleanup few warnings in S3C machine code which lead to > > finding some bigger issues. > > > > Patches touch mostly the ARM Samsung machine code except patch #1 (clk) > > and #5 (watchdog). They are independent from each other, except > > some conflicting lines. > > > > The last three patches would welcome some testing... as I did not > > perform such (lack of S3C hardware). > > I have an older series that I mean to repost. Please have a look at > the s3c-multiplatform branch of > git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git > > The patches in there need to be rebased on a newer kernel, which > should be easy, but they will conflict with your work. If there is > anything in there you can easily pick up into your series, please > do so. Indeed now I remember you were doing it some time ago but a follow up never happened. I can take a look and either cherry pick or even take over the series. Best regards, Krzysztof
[CFP LPC 2020] Scheduler Microconference
Hi all, We are pleased to announce the Scheduler Microconference has been accepted at LPC this year. Please submit your proposals on the LPC website at: https://www.linuxplumbersconf.org/event/7/abstracts/#submit-abstract And be sure to select "Scheduler MC" in the Track pulldown menu. Topics we are interested in, but certainly not limited to, this year are, - Load Balancer Rework - Idle Balance optimizations - Flattening the group scheduling hierarchy - Core scheduling - Proxy Execution for CFS - What was formerly known as latency nice Please get your submissions in by Aug 7th! Thanks! The organizers of the Scheduler Microconference
[PATCH v3 3/6] PCI: hotplug: Fix kerneldoc
Fix W=1 compile warnings (invalid kerneldoc): drivers/pci/hotplug/acpi_pcihp.c:69: warning: Function parameter or member 'pdev' not described in 'acpi_get_hp_hw_control_from_firmware' drivers/pci/hotplug/acpi_pcihp.c:69: warning: Excess function parameter 'dev' description in 'acpi_get_hp_hw_control_from_firmware' drivers/pci/hotplug/acpi_pcihp.c:199: warning: Function parameter or member 'handle' not described in 'acpi_pci_detect_ejectable' drivers/pci/hotplug/pciehp_core.c:165: warning: Function parameter or member 'ctrl' not described in 'pciehp_check_presence' Signed-off-by: Krzysztof Kozlowski --- drivers/pci/hotplug/acpi_pcihp.c | 4 ++-- drivers/pci/hotplug/pciehp_core.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/acpi_pcihp.c b/drivers/pci/hotplug/acpi_pcihp.c index 6b7c1ed58e7e..2750a64cecd3 100644 --- a/drivers/pci/hotplug/acpi_pcihp.c +++ b/drivers/pci/hotplug/acpi_pcihp.c @@ -61,7 +61,7 @@ static acpi_status acpi_run_oshp(acpi_handle handle) /** * acpi_get_hp_hw_control_from_firmware - * @dev: the pci_dev of the bridge that has a hotplug controller + * @pdev: the pci_dev of the bridge that has a hotplug controller * * Attempt to take hotplug control from firmware. */ @@ -191,7 +191,7 @@ check_hotplug(acpi_handle handle, u32 lvl, void *context, void **rv) /** * acpi_pci_detect_ejectable - check if the PCI bus has ejectable slots - * @handle - handle of the PCI bus to scan + * @handle: handle of the PCI bus to scan * * Returns 1 if the PCI bus has ACPI based ejectable slots, 0 otherwise. */ diff --git a/drivers/pci/hotplug/pciehp_core.c b/drivers/pci/hotplug/pciehp_core.c index bf779f291f15..ad3393930ecb 100644 --- a/drivers/pci/hotplug/pciehp_core.c +++ b/drivers/pci/hotplug/pciehp_core.c @@ -153,6 +153,7 @@ static int get_adapter_status(struct hotplug_slot *hotplug_slot, u8 *value) /** * pciehp_check_presence() - synthesize event if presence has changed + * @ctrl: controller to check * * On probe and resume, an explicit presence check is necessary to bring up an * occupied slot or bring down an unoccupied slot. This can't be triggered by -- 2.17.1
Re: [PATCH] ext4: fix spelling mistakes in extents.c
On Wed, Jun 10, 2020 at 11:19:46PM -0400, Keyur Patel wrote: > Fix spelling issues over the comments in the code. > > requsted ==> requested > deterimined ==> determined > insde ==> inside > neet ==> need > somthing ==> something > > Signed-off-by: Keyur Patel Applied, thanks. - Ted
[PATCH v3 4/6] PCI: dwc: Fix kerneldoc
Fix W=1 compile warnings (invalid kerneldoc): drivers/pci/controller/dwc/pcie-designware-ep.c:16: warning: Function parameter or member 'ep' not described in 'dw_pcie_ep_linkup' Signed-off-by: Krzysztof Kozlowski --- drivers/pci/controller/dwc/pcie-designware-ep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index 5e5b8821bed8..305bfec2424d 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 -/** +/* * Synopsys DesignWare PCIe Endpoint controller driver * * Copyright (C) 2017 Texas Instruments -- 2.17.1
[PATCH v3 6/6] PCI: xilinx: Fix kerneldoc
Fix W=1 compile warnings (invalid kerneldoc): drivers/pci/controller/pcie-xilinx-cpm.c:122: warning: Function parameter or member 'cpm_domain' not described in 'xilinx_cpm_pcie_port' Signed-off-by: Krzysztof Kozlowski --- drivers/pci/controller/pcie-xilinx-cpm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/controller/pcie-xilinx-cpm.c b/drivers/pci/controller/pcie-xilinx-cpm.c index 66f554694e03..cd8c77457b5f 100644 --- a/drivers/pci/controller/pcie-xilinx-cpm.c +++ b/drivers/pci/controller/pcie-xilinx-cpm.c @@ -104,6 +104,7 @@ * @cpm_base: CPM System Level Control and Status Register(SLCR) Base * @dev: Device pointer * @intx_domain: Legacy IRQ domain pointer + * @cpm_domain: CPM IRQ domain pointer * @cfg: Holds mappings of config space window * @intx_irq: legacy interrupt number * @irq: Error interrupt number -- 2.17.1
[PATCH v3 1/6] PCI: Fix kerneldoc
Fix W=1 compile warnings (invalid kerneldoc): drivers/pci/ats.c:196: warning: Function parameter or member 'pdev' not described in 'pci_enable_pri' drivers/pci/ats.c:196: warning: Function parameter or member 'reqs' not described in 'pci_enable_pri' drivers/pci/of.c:262: warning: Function parameter or member 'ib_resources' not described in 'devm_of_pci_get_host_bridge_resources' drivers/pci/pci-pf-stub.c:20: warning: cannot understand function prototype: 'const struct pci_device_id pci_pf_stub_whitelist[] = ' drivers/pci/setup-bus.c:62: warning: Function parameter or member 'min_align' not described in 'add_to_list' drivers/pci/vc.c:188: warning: Excess function parameter 'name' description in 'pci_vc_do_save_buffer' Signed-off-by: Krzysztof Kozlowski --- drivers/pci/ats.c | 3 ++- drivers/pci/of.c | 2 ++ drivers/pci/pci-pf-stub.c | 2 +- drivers/pci/setup-bus.c | 1 + drivers/pci/vc.c | 1 - 5 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index b761c1f72f67..2e1073052509 100644 --- a/drivers/pci/ats.c +++ b/drivers/pci/ats.c @@ -188,7 +188,8 @@ void pci_pri_init(struct pci_dev *pdev) /** * pci_enable_pri - Enable PRI capability - * @ pdev: PCI device structure + * @pdev: PCI device structure + * @reqs: outstanding requests * * Returns 0 on success, negative value on error */ diff --git a/drivers/pci/of.c b/drivers/pci/of.c index 22727fc9558d..d9621a603702 100644 --- a/drivers/pci/of.c +++ b/drivers/pci/of.c @@ -243,6 +243,8 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only); * @busno: bus number associated with the bridge root bus * @bus_max: maximum number of buses for this bridge * @resources: list where the range of resources will be added after DT parsing + * @ib_resources: list where the range of inbound resources (with addresses + *from 'dma-ranges' will be added after DT parsing * @io_base: pointer to a variable that will contain on return the physical * address for the start of the I/O range. Can be NULL if the caller doesn't * expect I/O ranges to be present in the device tree. diff --git a/drivers/pci/pci-pf-stub.c b/drivers/pci/pci-pf-stub.c index ef293e735c55..a0b2bd6c918a 100644 --- a/drivers/pci/pci-pf-stub.c +++ b/drivers/pci/pci-pf-stub.c @@ -9,7 +9,7 @@ #include #include -/** +/* * pci_pf_stub_whitelist - White list of devices to bind pci-pf-stub onto * * This table provides the list of IDs this driver is supposed to bind diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 4d870ed89385..3951e02b7ded 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -55,6 +55,7 @@ static void free_list(struct list_head *head) * @dev: Device to which the resource belongs * @res: Resource to be tracked * @add_size: Additional size to be optionally added to the resource + * @min_align: Minimum memory window alignment */ static int add_to_list(struct list_head *head, struct pci_dev *dev, struct resource *res, resource_size_t add_size, diff --git a/drivers/pci/vc.c b/drivers/pci/vc.c index 5486f8768c86..5fc59ac31145 100644 --- a/drivers/pci/vc.c +++ b/drivers/pci/vc.c @@ -172,7 +172,6 @@ static void pci_vc_enable(struct pci_dev *dev, int pos, int res) * @dev: device * @pos: starting position of VC capability (VC/VC9/MFVC) * @save_state: buffer for save/restore - * @name: for error message * @save: if provided a buffer, this indicates what to do with it * * Walking Virtual Channel config space to size, save, or restore it -- 2.17.1
[PATCH v3 5/6] PCI: rockchip: Fix kerneldoc
Fix W=1 compile warnings (invalid kerneldoc): drivers/pci/controller/pcie-rockchip-ep.c:50: warning: Function parameter or member 'epc' not described in 'rockchip_pcie_ep' Signed-off-by: Krzysztof Kozlowski --- drivers/pci/controller/pcie-rockchip-ep.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c index 5eaf36629a75..7631dc3961c1 100644 --- a/drivers/pci/controller/pcie-rockchip-ep.c +++ b/drivers/pci/controller/pcie-rockchip-ep.c @@ -22,6 +22,7 @@ /** * struct rockchip_pcie_ep - private data for PCIe endpoint controller driver * @rockchip: Rockchip PCIe controller + * @epc: PCI EPC device * @max_regions: maximum number of regions supported by hardware * @ob_region_map: bitmask of mapped outbound regions * @ob_addr: base addresses in the AXI bus where the outbound regions start -- 2.17.1
[PATCH v3 0/6] PCI: Minor kerneldoc warning fixes
Hi, Changes since v2: 1. Fix almost all warnings, except: drivers/pci/controller/pci-hyperv.c:2534: warning: Function parameter or member 'version' not described in 'hv_pci_protocol_negotiation' drivers/pci/controller/pci-hyperv.c:2534: warning: Function parameter or member 'num_version' not described in 'hv_pci_protocol_negotiation' Not sure what are these. 2. New patches, split per driver or subdirectory Best regards, Krzysztof Krzysztof Kozlowski (6): PCI: Fix kerneldoc PCI: endpoint: Fix kerneldoc PCI: hotplug: Fix kerneldoc PCI: dwc: Fix kerneldoc PCI: rockchip: Fix kerneldoc PCI: xilinx: Fix kerneldoc drivers/pci/ats.c | 3 ++- drivers/pci/controller/dwc/pcie-designware-ep.c | 2 +- drivers/pci/controller/pcie-rockchip-ep.c | 1 + drivers/pci/controller/pcie-xilinx-cpm.c| 1 + drivers/pci/endpoint/functions/pci-epf-test.c | 2 +- drivers/pci/endpoint/pci-ep-cfs.c | 2 +- drivers/pci/endpoint/pci-epc-core.c | 2 +- drivers/pci/endpoint/pci-epc-mem.c | 2 +- drivers/pci/endpoint/pci-epf-core.c | 4 +++- drivers/pci/hotplug/acpi_pcihp.c| 4 ++-- drivers/pci/hotplug/pciehp_core.c | 1 + drivers/pci/of.c| 2 ++ drivers/pci/pci-pf-stub.c | 2 +- drivers/pci/setup-bus.c | 1 + drivers/pci/vc.c| 1 - 15 files changed, 19 insertions(+), 11 deletions(-) -- 2.17.1
[PATCH v3 2/6] PCI: endpoint: Fix kerneldoc
Fix W=1 compile warnings (invalid kerneldoc): drivers/pci/endpoint/pci-epc-core.c:18: warning: cannot understand function prototype: 'struct class *pci_epc_class; ' drivers/pci/endpoint/pci-ep-cfs.c:17: warning: Function parameter or member 'functions_idr' not described in 'DEFINE_IDR' drivers/pci/endpoint/pci-epf-core.c:18: warning: Function parameter or member 'pci_epf_mutex' not described in 'DEFINE_MUTEX' drivers/pci/endpoint/pci-epf-core.c:80: warning: Function parameter or member 'epf' not described in 'pci_epf_free_space' drivers/pci/endpoint/pci-epf-core.c:107: warning: Function parameter or member 'epf' not described in 'pci_epf_alloc_space' drivers/pci/endpoint/pci-epc-mem.c:16: warning: Incorrect use of kernel-doc format: * pci_epc_mem_get_order() - determine the allocation order of a memory size drivers/pci/endpoint/pci-epc-mem.c:24: warning: Function parameter or member 'mem' not described in 'pci_epc_mem_get_order' drivers/pci/endpoint/pci-epc-mem.c:24: warning: Function parameter or member 'size' not described in 'pci_epc_mem_get_order' drivers/pci/endpoint/functions/pci-epf-test.c:189: warning: Function parameter or member 'epf_test' not described in 'pci_epf_test_clean_dma_chan' drivers/pci/endpoint/functions/pci-epf-test.c:189: warning: Excess function parameter 'epf' description in 'pci_epf_test_clean_dma_chan' Signed-off-by: Krzysztof Kozlowski --- drivers/pci/endpoint/functions/pci-epf-test.c | 2 +- drivers/pci/endpoint/pci-ep-cfs.c | 2 +- drivers/pci/endpoint/pci-epc-core.c | 2 +- drivers/pci/endpoint/pci-epc-mem.c| 2 +- drivers/pci/endpoint/pci-epf-core.c | 4 +++- 5 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c index c89a9561439f..e4e51d884553 100644 --- a/drivers/pci/endpoint/functions/pci-epf-test.c +++ b/drivers/pci/endpoint/functions/pci-epf-test.c @@ -181,7 +181,7 @@ static int pci_epf_test_init_dma_chan(struct pci_epf_test *epf_test) /** * pci_epf_test_clean_dma_chan() - Function to cleanup EPF test DMA channel - * @epf: the EPF test device that performs data transfer operation + * @epf_test: the EPF test device that performs data transfer operation * * Helper to cleanup EPF test DMA channel. */ diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-ep-cfs.c index 55edce50be96..3710adf51912 100644 --- a/drivers/pci/endpoint/pci-ep-cfs.c +++ b/drivers/pci/endpoint/pci-ep-cfs.c @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 -/** +/* * configfs to configure the PCI endpoint * * Copyright (C) 2017 Texas Instruments diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c index 82ba0dc7f2f5..cadd3db0cbb0 100644 --- a/drivers/pci/endpoint/pci-epc-core.c +++ b/drivers/pci/endpoint/pci-epc-core.c @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 -/** +/* * PCI Endpoint *Controller* (EPC) library * * Copyright (C) 2017 Texas Instruments diff --git a/drivers/pci/endpoint/pci-epc-mem.c b/drivers/pci/endpoint/pci-epc-mem.c index 80c46f3a4590..a97b56a6d2db 100644 --- a/drivers/pci/endpoint/pci-epc-mem.c +++ b/drivers/pci/endpoint/pci-epc-mem.c @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 -/** +/* * PCI Endpoint *Controller* Address Space Management * * Copyright (C) 2017 Texas Instruments diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c index 244e00f48c5c..c977cf9dce56 100644 --- a/drivers/pci/endpoint/pci-epf-core.c +++ b/drivers/pci/endpoint/pci-epf-core.c @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 -/** +/* * PCI Endpoint *Function* (EPF) library * * Copyright (C) 2017 Texas Instruments @@ -71,6 +71,7 @@ EXPORT_SYMBOL_GPL(pci_epf_bind); /** * pci_epf_free_space() - free the allocated PCI EPF register space + * @epf: the EPF device from whom to free the memory * @addr: the virtual address of the PCI EPF register space * @bar: the BAR number corresponding to the register space * @@ -96,6 +97,7 @@ EXPORT_SYMBOL_GPL(pci_epf_free_space); /** * pci_epf_alloc_space() - allocate memory for the PCI EPF register space + * @epf: the EPF device to whom allocate the memory * @size: the size of the memory that has to be allocated * @bar: the BAR number corresponding to the allocated register space * @align: alignment size for the allocation region -- 2.17.1
[PATCH] lib: kunit: add test_min_heap test conversion to KUnit
This adds the conversion of the runtime tests of test_min_heap,
from `lib/test_min_heap.c` to KUnit tests.
Please apply this commit first (linux-kselftest/kunit-fixes):
3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of
CONFIG options with space
Signed-off-by: Vitor Massaru Iha
---
lib/Kconfig.debug | 29 --
lib/Makefile | 2 +-
lib/{test_min_heap.c => min_heap_kunit.c} | 117 --
3 files changed, 83 insertions(+), 65 deletions(-)
rename lib/{test_min_heap.c => min_heap_kunit.c} (60%)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210d70a1..46674fc4972c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1864,16 +1864,6 @@ config TEST_LIST_SORT
If unsure, say N.
-config TEST_MIN_HEAP
- tristate "Min heap test"
- depends on DEBUG_KERNEL || m
- help
- Enable this to turn on min heap function tests. This test is
- executed only once during system boot (so affects only boot time),
- or at module load time.
-
- If unsure, say N.
-
config TEST_SORT
tristate "Array-based sort test"
depends on DEBUG_KERNEL || m
@@ -2185,6 +2175,25 @@ config LINEAR_RANGES_TEST
If unsure, say N.
+config MIN_HEAP_KUNIT
+tristate "KUnit test for Min heap"
+depends on KUNIT
+depends on DEBUG_KERNEL || m
+help
+ Enable this to turn on min heap function tests. This test is
+ executed only once during system boot (so affects only boot time),
+ or at module load time.
+
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
config TEST_UDELAY
tristate "udelay test driver"
help
diff --git a/lib/Makefile b/lib/Makefile
index b1c42c10073b..748f57063160 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -72,7 +72,6 @@ CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
UBSAN_SANITIZE_test_ubsan.o := y
obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
obj-$(CONFIG_TEST_LIST_SORT) += test_list_sort.o
-obj-$(CONFIG_TEST_MIN_HEAP) += test_min_heap.o
obj-$(CONFIG_TEST_LKM) += test_module.o
obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o
@@ -318,3 +317,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o
# KUnit tests
obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
+obj-$(CONFIG_MIN_HEAP_KUNIT) += min_heap_kunit.o
diff --git a/lib/test_min_heap.c b/lib/min_heap_kunit.c
similarity index 60%
rename from lib/test_min_heap.c
rename to lib/min_heap_kunit.c
index d19c8080fd4d..398db1c63146 100644
--- a/lib/test_min_heap.c
+++ b/lib/min_heap_kunit.c
@@ -7,9 +7,8 @@
#include
#include
-#include
-#include
#include
+#include
static __init bool less_than(const void *lhs, const void *rhs)
{
@@ -29,37 +28,34 @@ static __init void swap_ints(void *lhs, void *rhs)
*(int *)rhs = temp;
}
-static __init int pop_verify_heap(bool min_heap,
+static __init void pop_verify_heap(struct kunit *context,
+ bool min_heap,
struct min_heap *heap,
const struct min_heap_callbacks *funcs)
{
int *values = heap->data;
- int err = 0;
int last;
last = values[0];
min_heap_pop(heap, funcs);
while (heap->nr > 0) {
if (min_heap) {
- if (last > values[0]) {
- pr_err("error: expected %d <= %d\n", last,
- values[0]);
- err++;
- }
+ KUNIT_EXPECT_FALSE_MSG(context,
+ last > values[0],
+ "expected %d <= %d\n",
+ last, values[0]);
} else {
- if (last < values[0]) {
- pr_err("error: expected %d >= %d\n", last,
- values[0]);
- err++;
- }
+ KUNIT_EXPECT_FALSE_MSG(context,
+ last < values[0],
+ "expected %d >= %d\n",
+ last, values[0]);
}
last = values[0];
min_heap_pop(heap, funcs);
}
-
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
On Wed, Jul 29, 2020 at 01:00:33PM -0700, Sean Christopherson wrote: > Why do they need to be exclusive? We've already established that BLD catches > things that SLD does not. What's wrong with running sld=fatal and > bld=ratelimit > so that split locks never happen and kill applications, and non-WB locks are > are ratelimited? It's all moot until there's a sane proposal for #DB that isn't utterly wrecked.
Re: [PATCH v5 3/5] media: venus: core: Add support for opp tables/perf voting
On Wed 29 Jul 00:16 PDT 2020, Rajendra Nayak wrote:
> Add support to add OPP tables and perf voting on the OPP powerdomain.
> This is needed so venus votes on the corresponding performance state
> for the OPP powerdomain along with setting the core clock rate.
>
> Signed-off-by: Rajendra Nayak
> Reviewed-by: Matthias Kaehlcke
> Acked-by: Stanimir Varbanov
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/media/platform/qcom/venus/core.c | 2 +
> drivers/media/platform/qcom/venus/core.h | 5 ++
> drivers/media/platform/qcom/venus/pm_helpers.c | 92
> --
> 3 files changed, 92 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index bfcaba3..a3e98a5 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -525,6 +525,7 @@ static const struct venus_resources sdm845_res_v2 = {
> .vcodec_clks_num = 2,
> .vcodec_pmdomains = { "venus", "vcodec0", "vcodec1" },
> .vcodec_pmdomains_num = 3,
> + .opp_pmdomain = (const char *[]) { "cx", NULL },
> .vcodec_num = 2,
> .max_load = 3110400,/* 4096x2160@90 */
> .hfi_version = HFI_VERSION_4XX,
> @@ -570,6 +571,7 @@ static const struct venus_resources sc7180_res = {
> .vcodec_clks_num = 2,
> .vcodec_pmdomains = { "venus", "vcodec0" },
> .vcodec_pmdomains_num = 2,
> + .opp_pmdomain = (const char *[]) { "cx", NULL },
> .vcodec_num = 1,
> .hfi_version = HFI_VERSION_4XX,
> .vmem_id = VIDC_RESOURCE_NONE,
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index 7118612..b0cc544 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -62,6 +62,7 @@ struct venus_resources {
> unsigned int vcodec_clks_num;
> const char * const vcodec_pmdomains[VIDC_PMDOMAINS_NUM_MAX];
> unsigned int vcodec_pmdomains_num;
> + const char **opp_pmdomain;
> unsigned int vcodec_num;
> enum hfi_version hfi_version;
> u32 max_load;
> @@ -145,8 +146,12 @@ struct venus_core {
> struct clk *vcodec1_clks[VIDC_VCODEC_CLKS_NUM_MAX];
> struct icc_path *video_path;
> struct icc_path *cpucfg_path;
> + struct opp_table *opp_table;
> + bool has_opp_table;
> struct device_link *pd_dl_venus;
> struct device *pmdomains[VIDC_PMDOMAINS_NUM_MAX];
> + struct device_link *opp_dl_venus;
> + struct device *opp_pmdomain;
> struct video_device *vdev_dec;
> struct video_device *vdev_enc;
> struct v4l2_device v4l2_dev;
> diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c
> b/drivers/media/platform/qcom/venus/pm_helpers.c
> index abf9315..0308d20 100644
> --- a/drivers/media/platform/qcom/venus/pm_helpers.c
> +++ b/drivers/media/platform/qcom/venus/pm_helpers.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -66,10 +67,9 @@ static void core_clks_disable(struct venus_core *core)
>
> static int core_clks_set_rate(struct venus_core *core, unsigned long freq)
> {
> - struct clk *clk = core->clks[0];
> int ret;
>
> - ret = clk_set_rate(clk, freq);
> + ret = dev_pm_opp_set_rate(core->dev, freq);
> if (ret)
> return ret;
>
> @@ -740,13 +740,16 @@ static int venc_power_v4(struct device *dev, int on)
>
> static int vcodec_domains_get(struct device *dev)
> {
> + int ret;
> + struct opp_table *opp_table;
> + struct device **opp_virt_dev;
> struct venus_core *core = dev_get_drvdata(dev);
> const struct venus_resources *res = core->res;
> struct device *pd;
> unsigned int i;
>
> if (!res->vcodec_pmdomains_num)
> - return -ENODEV;
> + goto skip_pmdomains;
>
> for (i = 0; i < res->vcodec_pmdomains_num; i++) {
> pd = dev_pm_domain_attach_by_name(dev,
> @@ -763,7 +766,41 @@ static int vcodec_domains_get(struct device *dev)
> if (!core->pd_dl_venus)
> return -ENODEV;
>
> +skip_pmdomains:
> + if (!core->has_opp_table)
> + return 0;
> +
> + /* Attach the power domain for setting performance state */
> + opp_table = dev_pm_opp_attach_genpd(dev, res->opp_pmdomain,
> _virt_dev);
> + if (IS_ERR(opp_table)) {
> + ret = PTR_ERR(opp_table);
> + goto opp_attach_err;
> + }
> +
> + core->opp_pmdomain = *opp_virt_dev;
> + core->opp_dl_venus = device_link_add(dev, core->opp_pmdomain,
> + DL_FLAG_RPM_ACTIVE |
> + DL_FLAG_PM_RUNTIME |
> + DL_FLAG_STATELESS);
> + if (!core->opp_dl_venus) {
> + ret = -ENODEV;
> + goto opp_dl_add_err;
> +
Re: [PATCH ghak90 V9 02/13] audit: add container id
On 2020-07-05 11:09, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs wrote:
> >
> > Implement the proc fs write to set the audit container identifier of a
> > process, emitting an AUDIT_CONTAINER_OP record to document the event.
> >
> > This is a write from the container orchestrator task to a proc entry of
> > the form /proc/PID/audit_containerid where PID is the process ID of the
> > newly created task that is to become the first task in a container, or
> > an additional task added to a container.
> >
> > The write expects up to a u64 value (unset: 18446744073709551615).
> >
> > The writer must have capability CAP_AUDIT_CONTROL.
> >
> > This will produce a record such as this:
> > type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set
> > opid=2209 contid=123456 old-contid=18446744073709551615
> >
> > The "op" field indicates an initial set. The "opid" field is the
> > object's PID, the process being "contained". New and old audit
> > container identifier values are given in the "contid" fields.
> >
> > It is not permitted to unset the audit container identifier.
> > A child inherits its parent's audit container identifier.
> >
> > Store the audit container identifier in a refcounted kernel object that
> > is added to the master list of audit container identifiers. This will
> > allow multiple container orchestrators/engines to work on the same
> > machine without danger of inadvertantly re-using an existing identifier.
> > It will also allow an orchestrator to inject a process into an existing
> > container by checking if the original container owner is the one
> > injecting the task. A hash table list is used to optimize searches.
> >
> > Please see the github audit kernel issue for the main feature:
> > https://github.com/linux-audit/audit-kernel/issues/90
> > Please see the github audit userspace issue for supporting additions:
> > https://github.com/linux-audit/audit-userspace/issues/51
> > Please see the github audit testsuiite issue for the test case:
> > https://github.com/linux-audit/audit-testsuite/issues/64
> > Please see the github audit wiki for the feature overview:
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> >
> > Signed-off-by: Richard Guy Briggs
> > Acked-by: Serge Hallyn
> > Acked-by: Steve Grubb
> > Acked-by: Neil Horman
> > Reviewed-by: Ondrej Mosnacek
> > ---
> > fs/proc/base.c | 36 +++
> > include/linux/audit.h | 33 ++
> > include/uapi/linux/audit.h | 2 +
> > kernel/audit.c | 148
> > +
> > kernel/audit.h | 8 +++
> > 5 files changed, 227 insertions(+)
>
> ...
>
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index c2150415f9df..2800d4f1a2a8 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -692,6 +715,16 @@ static inline bool audit_loginuid_set(struct
> > task_struct *tsk)
> > return uid_valid(audit_get_loginuid(tsk));
> > }
> >
> > +static inline bool audit_contid_valid(u64 contid)
> > +{
> > + return contid != AUDIT_CID_UNSET;
> > +}
> > +
> > +static inline bool audit_contid_set(struct task_struct *tsk)
> > +{
> > + return audit_contid_valid(audit_get_contid(tsk));
> > +}
>
> This is quasi-nitpicky, but it seems like audit_contid_valid() and
> audit_contid_set() should be moved to kernel/audit.h if possible
> (possibly even kernel/audit.c). Maybe I'll see something later in the
> patchset, but right now I'm struggling to think of why anyone outside
> of audit would need to call these functions.
This was historical made moot by the conversion to contobj. I moved
them to kernel/audit.c and then just went with an open coded test once
and even just looking at the existance of a contobj.
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 5d8147a29291..6d387793f702 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -138,6 +138,13 @@ struct auditd_connection {
> >
> > /* Hash for inode-based rules */
> > struct list_head audit_inode_hash[AUDIT_INODE_BUCKETS];
> > +/* Hash for contid object lists */
> > +struct list_head audit_contid_hash[AUDIT_CONTID_BUCKETS];
> > +/* Lock all additions and deletions to the contid hash lists, assignment
> > + * of container objects to tasks. There should be no need for
> > + * interaction with tasklist_lock
> > + */
> > +static DEFINE_SPINLOCK(audit_contobj_list_lock);
> >
> > static struct kmem_cache *audit_buffer_cache;
> >
> > @@ -212,6 +219,33 @@ void __init audit_task_init(void)
> > 0, SLAB_PANIC, NULL);
> > }
> >
> > +/* rcu_read_lock must be held by caller unless new */
> > +static struct audit_contobj *_audit_contobj_hold(struct audit_contobj
> > *cont)
> > +{
> > + if (cont)
> > + refcount_inc(>refcount);
> > + return cont;
> > +}
> > +
> > +static struct audit_contobj
Re: [PATCH v3 2/4] iommu: Add iommu_aux_at(de)tach_group()
On Thu, 16 Jul 2020 09:07:46 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 7/16/20 12:01 AM, Jacob Pan wrote:
> > On Wed, 15 Jul 2020 08:47:36 +0800
> > Lu Baolu wrote:
> >
> >> Hi Jacob,
> >>
> >> On 7/15/20 12:39 AM, Jacob Pan wrote:
> >>> On Tue, 14 Jul 2020 13:57:01 +0800
> >>> Lu Baolu wrote:
> >>>
> This adds two new aux-domain APIs for a use case like vfio/mdev
> where sub-devices derived from an aux-domain capable device are
> created and put in an iommu_group.
>
> /**
> * iommu_aux_attach_group - attach an aux-domain to an iommu_group
> which
> * contains sub-devices (for example
> mdevs) derived
> * from @dev.
> * @domain: an aux-domain;
> * @group: an iommu_group which contains sub-devices derived from
> @dev;
> * @dev:the physical device which supports IOMMU_DEV_FEAT_AUX.
> *
> * Returns 0 on success, or an error value.
> */
> int iommu_aux_attach_group(struct iommu_domain *domain,
> struct iommu_group *group,
> struct device *dev)
>
> /**
> * iommu_aux_detach_group - detach an aux-domain from an
> iommu_group *
> * @domain: an aux-domain;
> * @group: an iommu_group which contains sub-devices derived from
> @dev;
> * @dev:the physical device which supports IOMMU_DEV_FEAT_AUX.
> *
> * @domain must have been attached to @group via
> iommu_aux_attach_group(). */
> void iommu_aux_detach_group(struct iommu_domain *domain,
> struct iommu_group *group,
> struct device *dev)
>
> It also adds a flag in the iommu_group data structure to identify
> an iommu_group with aux-domain attached from those normal ones.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommu.c | 58
> +++ include/linux/iommu.h |
> 17 + 2 files changed, 75 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index e1fdd3531d65..cad5a19ebf22 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -45,6 +45,7 @@ struct iommu_group {
> struct iommu_domain *default_domain;
> struct iommu_domain *domain;
> struct list_head entry;
> +unsigned int aux_domain_attached:1;
> };
>
> struct group_device {
> @@ -2759,6 +2760,63 @@ int iommu_aux_get_pasid(struct iommu_domain
> *domain, struct device *dev) }
> EXPORT_SYMBOL_GPL(iommu_aux_get_pasid);
>
> +/**
> + * iommu_aux_attach_group - attach an aux-domain to an iommu_group
> which
> + * contains sub-devices (for example
> mdevs) derived
> + * from @dev.
> + * @domain: an aux-domain;
> + * @group: an iommu_group which contains sub-devices derived from
> @dev;
> + * @dev:the physical device which supports IOMMU_DEV_FEAT_AUX.
> + *
> + * Returns 0 on success, or an error value.
> + */
> +int iommu_aux_attach_group(struct iommu_domain *domain,
> + struct iommu_group *group, struct
> device *dev) +{
> +int ret = -EBUSY;
> +
> +mutex_lock(>mutex);
> +if (group->domain)
> +goto out_unlock;
> +
> >>> Perhaps I missed something but are we assuming only one mdev per
> >>> mdev group? That seems to change the logic where vfio does:
> >>> iommu_group_for_each_dev()
> >>> iommu_aux_attach_device()
> >>>
> >>
> >> It has been changed in PATCH 4/4:
> >>
> >> static int vfio_iommu_attach_group(struct vfio_domain *domain,
> >> struct vfio_group *group)
> >> {
> >> if (group->mdev_group)
> >> return iommu_aux_attach_group(domain->domain,
> >> group->iommu_group,
> >> group->iommu_device);
> >> else
> >> return iommu_attach_group(domain->domain,
> >> group->iommu_group);
> >> }
> >>
> >> So, for both normal domain and aux-domain, we use the same concept:
> >> attach a domain to a group.
> >>
> > I get that, but don't you have to attach all the devices within the
>
> This iommu_group includes only mediated devices derived from an
> IOMMU_DEV_FEAT_AUX-capable device. Different from iommu_attach_group(),
> iommu_aux_attach_group() doesn't need to attach the domain to each
> device in group, instead it only needs to attach the domain to the
> physical device where the mdev's were created from.
>
> > group? Here you
kernel BUG at mm/internal.h:LINE! (2)
Hello, syzbot found the following issue on: HEAD commit:68845a55 Merge branch 'akpm' into master (patches from And.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17c86c5490 kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 dashboard link: https://syzkaller.appspot.com/bug?extid=f62749569eab36774dc5 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f62749569eab36774...@syzkaller.appspotmail.com vma 888000153210 start 000770077000 end 00077000 next 00077000 prev 07070707 mm 00077000 prot 7770077000 anon_vma vm_ops 885cecc0 pgoff 0 file 88809e09a7c0 private_data flags: 0x0() [ cut here ] kernel BUG at mm/internal.h:401! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 0 PID: 1676 Comm: kswapd0 Not tainted 5.8.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vma_address mm/internal.h:401 [inline] RIP: 0010:vma_address mm/internal.h:393 [inline] RIP: 0010:rmap_walk_file+0x6a4/0xbf0 mm/rmap.c:1921 Code: e8 91 20 cc ff 48 83 eb 01 48 89 e8 48 29 d8 48 c1 f8 06 48 01 44 24 18 e9 1a fb ff ff e8 74 20 cc ff 4c 89 e7 e8 95 e3 f9 ff <0f> 0b e8 65 20 cc ff 48 8b 44 24 10 4c 8d 68 78 4c 89 ef e8 b4 8a RSP: 0018:c90006987598 EFLAGS: 00010287 RAX: 010f RBX: 00077019e000 RCX: RDX: 8880a425e540 RSI: 815d4eb7 RDI: f52000d30e8e RBP: ea00021eac40 R08: 010f R09: 8880ae6318e7 R10: R11: R12: 888000153210 R13: dc00 R14: 000770077000 R15: 00077000 FS: () GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00788070 CR3: 00020b00c000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: rmap_walk+0x105/0x190 mm/rmap.c:1946 page_referenced+0x417/0x4b0 mm/rmap.c:888 shrink_active_list+0x3a6/0x1350 mm/vmscan.c:2061 shrink_list mm/vmscan.c:2167 [inline] shrink_lruvec+0x842/0x10f0 mm/vmscan.c:2467 shrink_node_memcgs mm/vmscan.c:2656 [inline] shrink_node+0x4b0/0x1b60 mm/vmscan.c:2770 kswapd_shrink_node mm/vmscan.c:3517 [inline] balance_pgdat+0x72f/0x10d0 mm/vmscan.c:3675 kswapd+0x5a5/0xe70 mm/vmscan.c:3932 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Modules linked in: ---[ end trace aecaf7276f5d1d16 ]--- RIP: 0010:vma_address mm/internal.h:401 [inline] RIP: 0010:vma_address mm/internal.h:393 [inline] RIP: 0010:rmap_walk_file+0x6a4/0xbf0 mm/rmap.c:1921 Code: e8 91 20 cc ff 48 83 eb 01 48 89 e8 48 29 d8 48 c1 f8 06 48 01 44 24 18 e9 1a fb ff ff e8 74 20 cc ff 4c 89 e7 e8 95 e3 f9 ff <0f> 0b e8 65 20 cc ff 48 8b 44 24 10 4c 8d 68 78 4c 89 ef e8 b4 8a RSP: 0018:c90006987598 EFLAGS: 00010287 RAX: 010f RBX: 00077019e000 RCX: RDX: 8880a425e540 RSI: 815d4eb7 RDI: f52000d30e8e RBP: ea00021eac40 R08: 010f R09: 8880ae6318e7 R10: R11: R12: 888000153210 R13: dc00 R14: 000770077000 R15: 00077000 FS: () GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00788070 CR3: 00020b00c000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v3 1/4] iommu: Check IOMMU_DEV_FEAT_AUX feature in aux api's
On Tue, 14 Jul 2020 13:57:00 +0800
Lu Baolu wrote:
> The iommu aux-domain api's work only when IOMMU_DEV_FEAT_AUX is enabled
> for the device. Add this check to avoid misuse.
Shouldn't this really be the IOMMU driver's responsibility to test? If
nothing else, iommu_dev_feature_enabled() needs to get the iommu_ops
from dev->bus->iommu_ops, which is presumably the same iommu_ops we're
then calling from domain->ops to attach/detach the device, so it'd be
more efficient for the IOMMU driver to error on devices that don't
support aux. Thanks,
Alex
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommu.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 1ed1e14a1f0c..e1fdd3531d65 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2725,11 +2725,13 @@ EXPORT_SYMBOL_GPL(iommu_dev_feature_enabled);
> */
> int iommu_aux_attach_device(struct iommu_domain *domain, struct device *dev)
> {
> - int ret = -ENODEV;
> + int ret;
>
> - if (domain->ops->aux_attach_dev)
> - ret = domain->ops->aux_attach_dev(domain, dev);
> + if (!iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX) ||
> + !domain->ops->aux_attach_dev)
> + return -ENODEV;
>
> + ret = domain->ops->aux_attach_dev(domain, dev);
> if (!ret)
> trace_attach_device_to_domain(dev);
>
> @@ -2748,12 +2750,12 @@ EXPORT_SYMBOL_GPL(iommu_aux_detach_device);
>
> int iommu_aux_get_pasid(struct iommu_domain *domain, struct device *dev)
> {
> - int ret = -ENODEV;
> + if (!iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX) ||
> + !domain->ops->aux_get_pasid)
> + return -ENODEV;
>
> - if (domain->ops->aux_get_pasid)
> - ret = domain->ops->aux_get_pasid(domain, dev);
> + return domain->ops->aux_get_pasid(domain, dev);
>
> - return ret;
> }
> EXPORT_SYMBOL_GPL(iommu_aux_get_pasid);
>
Re: [PATCH 0/7] ARM: samsung: Cleanup of various S3C bits
On Wed, Jul 29, 2020 at 6:11 PM Krzysztof Kozlowski wrote: > > Hi, > > I tried to cleanup few warnings in S3C machine code which lead to > finding some bigger issues. > > Patches touch mostly the ARM Samsung machine code except patch #1 (clk) > and #5 (watchdog). They are independent from each other, except > some conflicting lines. > > The last three patches would welcome some testing... as I did not > perform such (lack of S3C hardware). I have an older series that I mean to repost. Please have a look at the s3c-multiplatform branch of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git The patches in there need to be rebased on a newer kernel, which should be easy, but they will conflict with your work. If there is anything in there you can easily pick up into your series, please do so. Arnd
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
On Wed, Jul 29, 2020 at 07:42:59PM +, Fenghua Yu wrote:
> > Smushing the two into a single option is confusing, e.g. from the table
> > below it's not at all clear what will happen if sld=fatal, both features
> > are supported, and the kernel generates a split lock.
> >
> > Given that both SLD (per-core, not architectural) and BLD (#DB recursion and
> > inverted DR6 flag) have warts, it would be very nice to enable/disable them
> > independently. The lock to non-WB behavior for BLD may also be problematic,
> > e.g. maybe it turns out that fixing drivers to avoid locks to non-WB isn't
> > as straightforward as avoiding split locks.
>
> But the two features are related if both of them are enabled in hardware:
> If a split lock happens, SLD will generate #AC before instruction execution
> and BLD will generate #DB after instruction execution.
>
> The software needs to make them exclusive. The same kernel option reflects
> the relationship and make them exclusive, e.g. "fatal" enables SLD and
> disables BLD, "warn" does the other way.
Why do they need to be exclusive? We've already established that BLD catches
things that SLD does not. What's wrong with running sld=fatal and bld=ratelimit
so that split locks never happen and kill applications, and non-WB locks are
are ratelimited?
Sure, sld==warn with bld!=off is a bit silly, but the kernel can easily handle
that particular case.
> If using two different kernel options, the user needs to give right options
> to make both work, e.g. can the user give this combination
> "split_lock_detect=fatal bus_lock_detect=warn"? What does the combination
> mean?
Split locks are fatal, non-WB locks are logged but not fatal.
> There could be many combinations of the two options, some of them
> are meaningful and some of them aren't. Maintaining the combinations is
> unnecessary complex, right?
Honestly, it seems less complex than deciphering the resulting behavior from
that table.
sld=off|warn|fatal
bld=off|warn|ratelimit
As above, sld then could become
if (sld == warn && bld != off) {
pr_warn("disabling SLD in favor of BLD\n");
sld = off;
}
Everything else should simply work. The necessary refactoring for SLD should
be minimial as well.
Re: [PATCH v2] lib: kunit: Convert test_sort to KUnit test
On Wed, Jul 29, 2020 at 12:19 PM Andy Shevchenko
wrote:
>
> On Wed, Jul 29, 2020 at 04:11:51PM -0300, Vitor Massaru Iha wrote:
> > This adds the conversion of the test_sort.c to KUnit test.
> >
> > Please apply this commit first (linux-kselftest/kunit-fixes):
> > 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing
> > of CONFIG options with space
>
> Looks like you mixed up commit message and changelog / comments.
>
> > Code Style Documentation: [0]
> >
> > Fix these warnings Reported-by l...@intel.com
> >
> > WARNING: modpost: vmlinux.o(.data+0x4fc70): Section mismatch in reference
> > from the variable sort_test_cases to the variable .init.text:sort_test
> >The variable sort_test_cases references
> >the variable __init sort_test
> >If the reference is valid then annotate the
> >variable with or __refdata (see linux/init.h) or name the variable
> >
> > WARNING: modpost: lib/sort_kunit.o(.data+0x11c): Section mismatch in
> > reference from the variable sort_test_cases to the function
> > .init.text:sort_test()
> >The variable sort_test_cases references
> >the function __init sort_test()
>
> > Signed-off-by: Vitor Massaru Iha
> > Reported-by: kernel test robot
> > Link: [0]
> > https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u
>
> This should be in different order: Link, Reported-by, SoB.
> Also [0] is unnecessary
>
> > lib/{test_sort.c => sort_kunit.c} | 31 +++
>
> Still opened question why kunit is a suffix? Can't we leave same name? Can't
> we
> do it rather prefix?
Sorry to jump in now; I thought Vitor's reply with a link to the new
proposed documentation[1] addressed this. The naming convention issue
came up about a month ago[2]. The people in the discussion (including
myself) came to an agreement on _kunit.c. That being said, the
documentation hasn't been accepted yet, so if you really feel strongly
about it, now is the time to change it.
All that being said, I would rather not discuss that issue here for
the benefit of the participants in the preceding discussions.
I posted lore links for the relevant threads, which should be easy
enough to In-Reply-To your way into. Nevertheless, if it makes it
easier, let me know and I can CC you into the discussions.
[1]
https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u
[2] https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u
Cheers
Re: [PATCH] perf bench: Add benchmark of find_next_bit
Em Tue, Jul 28, 2020 at 08:51:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jul 24, 2020 at 12:19:59AM -0700, Ian Rogers escreveu:
> > for_each_set_bit, or similar functions like for_each_cpu, may be hot
> > within the kernel. If many bits were set then one could imagine on
> > Intel a "bt" instruction with every bit may be faster than the function
> > call and word length find_next_bit logic. Add a benchmark to measure
> > this.
>
> Thanks, applied.
>
> - Arnaldo
>
> > This benchmark on AMD rome and Intel skylakex shows "bt" is not a good
> > option except for very small bitmaps.
> > +++ b/tools/perf/bench/find-bit-bench.c
> > +#if defined(__i386__) || defined(__x86_64__)
> > +static bool asm_test_bit(long nr, const unsigned long *addr)
> > +{
> > + bool oldbit;
> > +
> > + asm volatile("bt %2,%1"
> > +: "=@ccc" (oldbit)
> > +: "m" (*(unsigned long *)addr), "Ir" (nr) : "memory");
> > +
> > + return oldbit;
Some old clang versions are not liking this:
clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= -C /git/linux/tools/perf
O=/tmp/build/perf CC=clang
CC /tmp/build/perf/trace/beauty/pkey_alloc.o
CC /tmp/build/perf/tests/openat-syscall-tp-fields.o
bench/find-bit-bench.c:46:10: error: invalid output constraint '=@ccc' in asm
: "=@ccc" (oldbit)
^
1 error generated.
mv: can't rename '/tmp/build/perf/bench/.find-bit-bench.o.tmp': No such file or
directory
/git/linux/tools/build/Makefile.build:96: recipe for target
'/tmp/build/perf/bench/find-bit-bench.o' failed
make[4]: *** [/tmp/build/perf/bench/find-bit-bench.o] Error 1
/git/linux/tools/build/Makefile.build:139: recipe for target 'bench' failed
make[3]: *** [bench] Error 2
make[3]: *** Waiting for unfinished jobs
MKDIR/tmp/build/perf/arch/x86/tests/
Also:
clang version 3.8.1 (tags/RELEASE_381/final)
clang version 4.0.0 (tags/RELEASE_400/final)
- Arnaldo
Re: [PATCH] PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken
On Tue, Jul 28, 2020 at 06:45:53PM +0800, Kai-Heng Feng wrote:
> We are seeing AMD Radeon Pro W5700 doesn't work when IOMMU is enabled:
> [3.375841] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT
> device=63:00.0 address=0x42b5b01a0]
> [3.375845] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT
> device=63:00.0 address=0x42b5b01c0]
>
> The error also makes graphics driver fail to probe the device.
>
> It appears to be the same issue as commit 5e89cd303e3a ("PCI: Mark AMD
> Navi14 GPU rev 0xc5 ATS as broken") addresses, and indeed the same ATS
> quirk can workaround the issue.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208725
> Cc: Alex Deucher
> Signed-off-by: Kai-Heng Feng
Applied with Alex's ack to pci/virtualization for v5.9, thanks!
I also added a stable tag since we did that for 5e89cd303e3a. Let me
know if you *don't* want that.
> ---
> drivers/pci/quirks.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 812bfc32ecb8..052efeb9f053 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5192,7 +5192,8 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS,
> 0x0422, quirk_no_ext_tags);
> */
> static void quirk_amd_harvest_no_ats(struct pci_dev *pdev)
> {
> - if (pdev->device == 0x7340 && pdev->revision != 0xc5)
> + if ((pdev->device == 0x7312 && pdev->revision != 0x00) ||
> + (pdev->device == 0x7340 && pdev->revision != 0xc5))
> return;
>
> pci_info(pdev, "disabling ATS\n");
> @@ -5203,6 +5204,8 @@ static void quirk_amd_harvest_no_ats(struct pci_dev
> *pdev)
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_amd_harvest_no_ats);
> /* AMD Iceland dGPU */
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900, quirk_amd_harvest_no_ats);
> +/* AMD Navi10 dGPU */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7312, quirk_amd_harvest_no_ats);
> /* AMD Navi14 dGPU */
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7340, quirk_amd_harvest_no_ats);
> #endif /* CONFIG_PCI_ATS */
> --
> 2.17.1
>
Re: [RFC PATCH 02/14] coresight: Introduce device access abstraction
On Wed, Jul 22, 2020 at 06:20:28PM +0100, Suzuki K Poulose wrote: > We are about to introduce support for sysreg access to ETMv4.4+ > component. Since there are generic routines that access the > registers (e.g, CS_LOCK/UNLOCK , claim/disclaim operations, timeout) > and in order to preserve the logic of these operations at a single place > we introduce an abstraction layer for the accesses to a given device. > This will also be helpful in consolidating the sysfs.attribute helpers, > that we define per driver. Please drop the last sentence, it doesn't add to the current patch. > > Cc: Mathieu Poirier > Cc: Mike Leach > Signed-off-by: Suzuki K Poulose > --- > drivers/hwtracing/coresight/coresight-catu.c | 1 + > drivers/hwtracing/coresight/coresight-cti.c | 1 + > drivers/hwtracing/coresight/coresight-etb10.c | 1 + > drivers/hwtracing/coresight/coresight-etm3x.c | 1 + > drivers/hwtracing/coresight/coresight-etm4x.c | 1 + > .../hwtracing/coresight/coresight-funnel.c| 1 + > .../coresight/coresight-replicator.c | 1 + > drivers/hwtracing/coresight/coresight-stm.c | 1 + > drivers/hwtracing/coresight/coresight-tmc.c | 1 + > drivers/hwtracing/coresight/coresight-tpiu.c | 1 + > drivers/hwtracing/coresight/coresight.c | 49 ++ > include/linux/coresight.h | 156 ++ > 12 files changed, 215 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-catu.c > b/drivers/hwtracing/coresight/coresight-catu.c > index 1801804a7762..6299ff7b8a14 100644 > --- a/drivers/hwtracing/coresight/coresight-catu.c > +++ b/drivers/hwtracing/coresight/coresight-catu.c > @@ -551,6 +551,7 @@ static int catu_probe(struct amba_device *adev, const > struct amba_id *id) > dev->platform_data = pdata; > > drvdata->base = base; > + catu_desc.access.base = base; > catu_desc.pdata = pdata; > catu_desc.dev = dev; > catu_desc.groups = catu_groups; > diff --git a/drivers/hwtracing/coresight/coresight-cti.c > b/drivers/hwtracing/coresight/coresight-cti.c > index 3ccc703dc940..c810ea3ba155 100644 > --- a/drivers/hwtracing/coresight/coresight-cti.c > +++ b/drivers/hwtracing/coresight/coresight-cti.c > @@ -865,6 +865,7 @@ static int cti_probe(struct amba_device *adev, const > struct amba_id *id) > return PTR_ERR(base); > > drvdata->base = base; > + cti_desc.access.base = base; > > dev_set_drvdata(dev, drvdata); > > diff --git a/drivers/hwtracing/coresight/coresight-etb10.c > b/drivers/hwtracing/coresight/coresight-etb10.c > index 03e3f2590191..0f2735e15119 100644 > --- a/drivers/hwtracing/coresight/coresight-etb10.c > +++ b/drivers/hwtracing/coresight/coresight-etb10.c > @@ -755,6 +755,7 @@ static int etb_probe(struct amba_device *adev, const > struct amba_id *id) > return PTR_ERR(base); > > drvdata->base = base; > + desc.access.base = base; > > spin_lock_init(>spinlock); > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c > b/drivers/hwtracing/coresight/coresight-etm3x.c > index bf22dcfd3327..7ddcb7fcb2d6 100644 > --- a/drivers/hwtracing/coresight/coresight-etm3x.c > +++ b/drivers/hwtracing/coresight/coresight-etm3x.c > @@ -805,6 +805,7 @@ static int etm_probe(struct amba_device *adev, const > struct amba_id *id) > return PTR_ERR(base); > > drvdata->base = base; > + desc.access.base = base; > > spin_lock_init(>spinlock); > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c > b/drivers/hwtracing/coresight/coresight-etm4x.c > index cb83fb77ded6..7bb74c659c4f 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c > @@ -1501,6 +1501,7 @@ static int etm4_probe(struct amba_device *adev, const > struct amba_id *id) > return PTR_ERR(base); > > drvdata->base = base; > + desc.access.base = base; > > spin_lock_init(>spinlock); > > diff --git a/drivers/hwtracing/coresight/coresight-funnel.c > b/drivers/hwtracing/coresight/coresight-funnel.c > index 900690a9f7f0..67fc3e3b77d8 100644 > --- a/drivers/hwtracing/coresight/coresight-funnel.c > +++ b/drivers/hwtracing/coresight/coresight-funnel.c > @@ -242,6 +242,7 @@ static int funnel_probe(struct device *dev, struct > resource *res) > } > drvdata->base = base; > desc.groups = coresight_funnel_groups; > + desc.access.base = base; > } > > dev_set_drvdata(dev, drvdata); > diff --git a/drivers/hwtracing/coresight/coresight-replicator.c > b/drivers/hwtracing/coresight/coresight-replicator.c > index 78acf29c49ca..65704ada20a5 100644 > --- a/drivers/hwtracing/coresight/coresight-replicator.c > +++ b/drivers/hwtracing/coresight/coresight-replicator.c > @@ -254,6 +254,7 @@ static int replicator_probe(struct device *dev, struct > resource *res) > } >
Re: kernel BUG at include/linux/swapops.h:LINE!
On Wed, Jul 29, 2020 at 10:21:51PM +0300, Kirill A. Shutemov wrote:
> On Mon, Jul 27, 2020 at 01:03:10PM +0100, Matthew Wilcox wrote:
> > > It would be interesting to know if the migration entires ever got removed
> > > for pfn. I mean if remove_migration_pte() got called for it.
> > >
> > > It can be rmap issue too. Maybe it misses PMD on remove_migration_ptes()
> > > or something.
> >
> > It's not mapped with a PMD. I tweaked my debugging slightly:
> >
> > static inline swp_entry_t make_migration_entry(struct page *page, int
> > write)
> > {
> > - BUG_ON(!PageLocked(compound_head(page)));
> > + VM_BUG_ON_PAGE(!PageLocked(page), page);
> >
> > +if (PageHead(page)) dump_page(page, "make entry");
> > +if (PageTail(page)) printk("pfn %lx order %d\n", page_to_pfn(page),
> > thp_order(thp_head(page)));
> >
> > 1523 page:06f62206 refcount:490 mapcount:1 mapping:
> > index:0x562b12a00 pfn:0x1dc00
> > 1523 head:06f62206 order:9 compound_mapcount:0 compound_pincount:0
> > 1523 anon flags:
> > 0x4009003d(locked|uptodate|dirty|lru|active|head|swapbacked)
> > 1523 raw: 4009003d ecfd41301308 ecfd41b08008
> > 9e9971c00059
> > 1523 raw: 000562b12a00 01ea
> >
> > 1523 page dumped because: make entry
> > 1523 pfn 1dc01 order 9
> > 1523 pfn 1dc02 order 9
> > 1523 pfn 1dc03 order 9
> > ...
> >
> > Notice that it's an anonymous page, so it's not related to my work.
>
> I don't have much hope, but could you try if the patch below would blow
> up?
Running it now. Results probably in twenty minutes.
> Could you share the setup you use to trigger the issue? I want try it
> myself.
Head commit d8b18bdf9870b131802d641f5e7f32ddc53dcce3 which you can find
in http://git.infradead.org/users/willy/pagecache.git
I'm using Kent Overstreet's ktest as the base:
https://github.com/koverstreet/ktest
from the root of the kernel tree, I type:
$ ../ktest/build-test-kernel run ../ktest/tests/xfs.ktest
xfs.ktest is not in Kent's repo:
#!/bin/bash
require-kernel-config XFS_FS
require-kernel-config XFS_QUOTA XFS_POSIX_ACL XFS_RT XFS_ONLINE_SCRUB
require-kernel-config XFS_ONLINE_REPAIR XFS_DEBUG XFS_ASSERT_FATAL
require-kernel-config QUOTA
require-lib xfstests.sh
run_tests()
{
run_xfstests xfs "$@"
}
I think that's all you'll need to get going.
Re: [PATCH] clk: mmp: avoid missing prototype warning
Quoting Arnd Bergmann (2020-07-29 04:34:39) > The kernel test robot points out two harmless warnings in the > mmp clk drivers: > > drivers/clk/mmp/clk-pxa168.c:68:13: warning: no previous prototype for > 'pxa168_clk_init' [-Wmissing-prototypes] > drivers/clk/mmp/clk-pxa910.c:66:13: warning: no previous prototype for > 'pxa910_clk_init' [-Wmissing-prototypes] > > Fix these by including corresponding header file. > > Reported-by: kernel test robot > Signed-off-by: Arnd Bergmann > --- Applied to clk-next
Re: add file system helpers that take kernel pointers for the init code v4
On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote: > Hi Al and Linus, > > currently a lot of the file system calls in the early in code (and the > devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot. > This is one of the few last remaining places we need to deal with to kill > off set_fs entirely, so this series adds new helpers that take kernel > pointers. These helpers are in init/ and marked __init and thus will > be discarded after bootup. A few also need to be duplicated in devtmpfs, > though unfortunately. > > The series sits on top of my previous > > "decruft the early init / initrd / initramfs code v2" Could you fold the fixes in the parent branch to avoid the bisect hazards? As it is, you have e.g. "initd: pass a non-f_pos offset to kernel_read/kernel_write" that ought to go into "initrd: switch initrd loading to struct file based APIs"...
Re: [PATCH 10/17] Documentation: bindings: clk: Add bindings for i.MX BLK_CTRL
Quoting Abel Vesa (2020-07-29 05:07:56)
> diff --git a/Documentation/devicetree/bindings/clock/fsl,imx-blk-ctrl.yaml
> b/Documentation/devicetree/bindings/clock/fsl,imx-blk-ctrl.yaml
> new file mode 100644
> index ..036d3d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/fsl,imx-blk-ctrl.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/fsl,imx-blk-ctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
[...]
> +
> +examples:
> + - |
> +audio-blk-ctrl: blk-ctrl@30e2 {
clock-controller@30e2 {
> + compatible = "fsl,imx8mp-blk-ctrl", "syscon";
> + reg = <0x30e2 0x1>;
> + power-domains = <_pd>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> +};
Re: [PATCH] uapi, seg6_iptunnel: Add missing include in seg6_iptunnel.h
From: Ioana-Ruxandra Stancioi Date: Wed, 29 Jul 2020 10:49:03 + > From: Ioana-Ruxandra Stăncioi > > Include in uapi/linux/seg6_iptunnel.h to fix the > following linux/seg6_iptunnel.h compilation error: > >invalid application of 'sizeof' to incomplete type 'struct ipv6hdr' >head = sizeof(struct ipv6hdr); > ^~ > > This is to allow including this header in places where > has not been included but __KERNEL__ is defined. In the kernel the easy > workaround is including , but the header may also be used > by code analysis tools. > > Signed-off-by: Ioana-Ruxandra Stăncioi This doesn't belong in a UAPI header (it's __KERNEL__ protected after all), and it's only called in one place in the kernel, namely net/ipv6/net/ipv6/seg6_iptunnel.c) Just move the helper to that foo.c file, and drop the inline keyword. Thank you.
Re: Regression in nvme driver
On Wed, Jul 29, 2020 at 07:29:08PM +, Lach wrote: > Hello > > I caught a regression in the nvme driver, which shows itself on some > controllers (In my case, at 126h:2263) Fix is staged for the next 5.8 pull; https://git.kernel.dk/cgit/linux-block/commit/?h=block-5.8=5bedd3afee8eb01ccd256f0cd2cc0fa6f841417a
[PATCH 1/1] scsi: virtio-scsi: handle correctly case when all LUNs were unplugged
Commit 5ff843721467 ("scsi: virtio_scsi: unplug LUNs when events missed"),
almost fixed the case of mass unpluging of LUNs, but it missed a
corner case in which all the LUNs are unplugged at the same time.
In this case INQUIRY ends with DID_BAD_TARGET.
Detect this and unplug the LUN.
Signed-off-by: Maxim Levitsky
---
drivers/scsi/virtio_scsi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 0e0910c5b9424..c7f0c22b6f11d 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -351,6 +351,16 @@ static void virtscsi_rescan_hotunplug(struct virtio_scsi
*vscsi)
/* PQ indicates the LUN is not attached */
scsi_remove_device(sdev);
}
+
+ else if (host_byte(result) == DID_BAD_TARGET) {
+ /*
+* if all LUNs of a virtio-scsi device are unplugged,
+* it will respond with BAD TARGET on any INQUIRY
+* command.
+* Remove the device in this case as well
+*/
+ scsi_remove_device(sdev);
+ }
}
kfree(inq_result);
--
2.26.2
[PATCH 0/1] virtio-scsi: fix missing unplug events when all LUNs are unplugged at the same time
virtio-scsi currently has limit of 8 outstanding notifications so when more that
8 LUNs are unplugged, some are missed.
Commit 5ff843721467 ("scsi: virtio_scsi: unplug LUNs when events missed")
Fixed this by checking the 'event overflow' bit and manually scanned the bus
to see which LUNs are still there.
However there is a corner case when all LUNs are unplugged.
In this case (which is not fully scsi confirmant IMHO), all scsi
commands to such device respond with INVALID TARGET.
This patch proposes to detect this and remove the LUN in this case
as well.
Maxim Levitsky (1):
scsi: virtio-scsi: handle correctly case when all LUNs were unplugged
drivers/scsi/virtio_scsi.c | 10 ++
1 file changed, 10 insertions(+)
--
2.26.2
Re: [PATCH 01/17] dt-bindings: clocks: imx8mp: Rename audiomix ids clocks to audio_blk_ctrl
Quoting Abel Vesa (2020-07-29 05:07:47) > In the reference manual the actual name is Audio BLK_CTRL. > Lets make it more obvious here by renaming from audiomix to audio_blk_ctrl. And this is safe because there aren't any users of the defines?
Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
Hello,
- Original Message -
> From: "Segher Boessenkool"
> To: "Vladis Dronov"
> Cc: linuxppc-...@lists.ozlabs.org, "Aneesh Kumar K . V"
> , linux-kernel@vger.kernel.org,
> "Paul Mackerras"
> Sent: Wednesday, July 29, 2020 4:49:49 PM
> Subject: Re: [PATCH] powerpc: fix function annotations to avoid section
> mismatch warnings with gcc-10
>
> On Wed, Jul 29, 2020 at 03:37:41PM +0200, Vladis Dronov wrote:
> > Certain warnings are emitted for powerpc code when building with a gcc-10
> > toolset:
> >
> > WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
> > reference from the function remove_pmd_table() to the function
> > .meminit.text:split_kernel_mapping()
> > The function remove_pmd_table() references
> > the function __meminit split_kernel_mapping().
> > This is often because remove_pmd_table lacks a __meminit
> > annotation or the annotation of split_kernel_mapping is wrong.
> >
> > Add the appropriate __init and __meminit annotations to make modpost not
> > complain. In all the cases there are just a single callsite from another
> > __init or __meminit function:
> >
> > __meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
> > __init prom_init() -> setup_secure_guest()
> > __init xive_spapr_init() -> xive_spapr_disabled()
>
> So what changed? These functions were inlined with older compilers, but
> not anymore?
Yes, exactly. Gcc-10 does not inline them anymore. If this is because of my
build system, this can happen to others also.
The same thing was fixed by Linus in e99332e7b4cd ("gcc-10: mark more functions
__init to avoid section mismatch warnings").
>
> Segher
Best regards,
Vladis Dronov | Red Hat, Inc. | The Core Kernel | Senior Software Engineer
Re: [PATCH 1/7] clk: samsung: s3c64xx: Declare s3c64xx_clk_init() in shared header
Quoting Krzysztof Kozlowski (2020-07-29 09:09:36)
> diff --git a/include/linux/clk/samsung.h b/include/linux/clk/samsung.h
> new file mode 100644
> index ..b6b253c46c22
> --- /dev/null
> +++ b/include/linux/clk/samsung.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2020 Krzysztof Kozlowski
> + */
> +
> +#ifndef __LINUX_CLK_SAMSUNG_H_
> +#define __LINUX_CLK_SAMSUNG_H_
> +
> +#ifdef CONFIG_ARCH_S3C64XX
> +void __init s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
Don't use __init in header files. It doesn't do anything.
> +unsigned long xusbxti_f, bool s3c6400,
> +void __iomem *base);
> +#else
> +static inline void __init s3c64xx_clk_init(struct device_node *np,
Forward declare struct device_node;
> + unsigned long xtal_f,
> + unsigned long xusbxti_f,
> + bool s3c6400,
> + void __iomem *base) { }
Include (or compiler_types.h) for __iomem define
please.
> +#endif /* CONFIG_ARCH_S3C64XX */
> +
> +#endif /* __LINUX_CLK_SAMSUNG_H_ */
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
Hi, Sean, On Wed, Jul 29, 2020 at 11:46:14AM -0700, Sean Christopherson wrote: > On Wed, Jul 29, 2020 at 11:09:16AM -0700, Yu, Fenghua wrote: > > > > Some CPUs have ability to notify the kernel by an #DB trap after the > > > > instruction acquires a bus lock and is executed. This allows the > > > > kernel to enforce user application throttling or mitigations and also > > > > provides a better environment to debug kernel split lock issues since > > > > the kernel can continue instead of crashing. > > > > > > > > #DB for bus lock detect fixes all issues in #AC for split lock detect: > > > > > > Fixes "all" issues... and creates some new ones, e.g. there are use cases > > > where preventing the split lock from happening in the first place is > > > strongly > > > desired. It's why that train wreck exists. > > > > Bus Lock Detection doesn't replace Split Lock Detection. If both features > > are enabled, default behavior is warning from bus lock, fatal behavior is > > still from split lock. See the behavior table as follows. > > > > > > > > > 1) It's architectural ... just need to look at one CPUID bit to know it > > > >exists > > > > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread. > > > >So each process or guest can have different behavior. > > > > 3) It has support for VMM/guests (new VMEXIT codes, etc). > > > > > > > > Use the existing kernel command line option "split_lock_detect=" to > > > > handle #DB for bus lock: > > > > > > Are SLD and BLD mutually exclusive? Can we even guarantee that given the > > > track record of SLD? If not, we'll likely want to allow the user to > > > choose > > > between SDL and BLD via split_lock_detect. > > > > The two hardware features can be enabled on the same platform. > > But they are mutually exclusive in the kernel because #AC from SLD happens > > before the instruction is executed and #DB happens after the instruction is > > executed. > > > > Right now, if both of them are enabled, "warn" behavior goes to > > bus lock and "fatal" behavior goes to split lock. > > > > Do you want the user to override the behaviors by something like this? > > > > split_lock_detect=warn[,sld]: if given "sld" while both features are > > enabled, > > warn behavior is from split lock instead of bus lock detection. > > > > split_lock_detect=fatal[,bld]: if given "bld" while both features are > > enabled, > > fatal behavior is from bus lock detection. > > IMO these should be completely independent features (that happen to share > some code). > > BLD in fatal mode doesn't make any sense because it can't be fatal without > a completely different implementation, e.g. the bus lock has already > happened and the application can eat the SIGBUS. The current SLD code > works because the split lock is prevented entirely, i.e. eating SIGBUS > doesn't allow the application to make forward progress. If "fatal" is meaningless for BLD, we can remove it for BLD. If we need it in the future, we can add it later. The "ratelimit:N" maybe more useful for BLD: it mitigates DOS from bus locks. > > Smushing the two into a single option is confusing, e.g. from the table > below it's not at all clear what will happen if sld=fatal, both features > are supported, and the kernel generates a split lock. > > Given that both SLD (per-core, not architectural) and BLD (#DB recursion and > inverted DR6 flag) have warts, it would be very nice to enable/disable them > independently. The lock to non-WB behavior for BLD may also be problematic, > e.g. maybe it turns out that fixing drivers to avoid locks to non-WB isn't > as straightforward as avoiding split locks. But the two features are related if both of them are enabled in hardware: If a split lock happens, SLD will generate #AC before instruction execution and BLD will generate #DB after instruction execution. The software needs to make them exclusive. The same kernel option reflects the relationship and make them exclusive, e.g. "fatal" enables SLD and disables BLD, "warn" does the other way. If using two different kernel options, the user needs to give right options to make both work, e.g. can the user give this combination "split_lock_detect=fatal bus_lock_detect=warn"? What does the combination mean? There could be many combinations of the two options, some of them are meaningful and some of them aren't. Maintaining the combinations is unnecessary complex, right? Thanks. -Fenghua
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On 2020-07-05 11:10, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs wrote:
> >
> > Create a new audit record AUDIT_CONTAINER_ID to document the audit
> > container identifier of a process if it is present.
> >
> > Called from audit_log_exit(), syscalls are covered.
> >
> > Include target_cid references from ptrace and signal.
> >
> > A sample raw event:
> > type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> > success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> > ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key="tmpcontainerid"
> > type=CWD msg=audit(1519924845.499:257): cwd="/root"
> > type=PATH msg=audit(1519924845.499:257): item=0 name="/tmp/" inode=13863
> > dev=00:27 mode=041777 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tmp_t:s0 nametype= PARENT cap_fp=0 cap_fi=0 cap_fe=0
> > cap_fver=0
> > type=PATH msg=audit(1519924845.499:257): item=1 name="/tmp/tmpcontainerid"
> > inode=17729 dev=00:27 mode=0100644 ouid=0 ogid=0 rdev=00:00
> > obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=0 cap_fi=0
> > cap_fe=0 cap_fver=0
> > type=PROCTITLE msg=audit(1519924845.499:257):
> > proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> > type=CONTAINER_ID msg=audit(1519924845.499:257): contid=123458
> >
> > Please see the github audit kernel issue for the main feature:
> > https://github.com/linux-audit/audit-kernel/issues/90
> > Please see the github audit userspace issue for supporting additions:
> > https://github.com/linux-audit/audit-userspace/issues/51
> > Please see the github audit testsuiite issue for the test case:
> > https://github.com/linux-audit/audit-testsuite/issues/64
> > Please see the github audit wiki for the feature overview:
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> > Signed-off-by: Richard Guy Briggs
> > Acked-by: Serge Hallyn
> > Acked-by: Steve Grubb
> > Acked-by: Neil Horman
> > Reviewed-by: Ondrej Mosnacek
> > ---
> > include/linux/audit.h | 7 +++
> > include/uapi/linux/audit.h | 1 +
> > kernel/audit.c | 25 +++--
> > kernel/audit.h | 4
> > kernel/auditsc.c | 45
> > +++--
> > 5 files changed, 74 insertions(+), 8 deletions(-)
>
> ...
>
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 9e0b38ce1ead..a09f8f661234 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -2211,6 +2211,27 @@ void audit_log_session_info(struct audit_buffer *ab)
> > audit_log_format(ab, "auid=%u ses=%u", auid, sessionid);
> > }
> >
> > +/*
> > + * audit_log_container_id - report container info
> > + * @context: task or local context for record
> > + * @cont: container object to report
> > + */
> > +void audit_log_container_id(struct audit_context *context,
> > + struct audit_contobj *cont)
> > +{
> > + struct audit_buffer *ab;
> > +
> > + if (!cont)
> > + return;
> > + /* Generate AUDIT_CONTAINER_ID record with container ID */
> > + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER_ID);
> > + if (!ab)
> > + return;
> > + audit_log_format(ab, "contid=%llu", contid);
>
> Did this patch compile? Where is "contid" coming from? I'm guessing
> you mean to get it from "cont", but that isn't what appears to be
> happening; likely a casualty of the object vs token discussion we had
> during the last review cycle.
Yes, it was supposed to be cont->id.
> I'm assuming this code gets modified later in this patchset and you
> only compiled tested the patchset as a whole. Please make sure the
> patchset compiles at each patch along the way to applying them all;
> this helps ensure that git bisect remains useful and it fits better
> with the general idea that individual patches must have merit on their
> own.
Yes, agreed.
> ... and yes, I do check for this when merging patchsets, it isn't just
> a visual inspection, I compile test each patch.
>
> If nothing else, at least this answers the question of if it is worth
> respinning or not (this alone requires a respin).
>
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index f03d3eb0752c..9e79645e5c0e 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1458,6 +1466,7 @@ static void audit_log_exit(void)
> > struct audit_buffer *ab;
> > struct audit_aux_data *aux;
> > struct audit_names *n;
> > + struct audit_contobj *cont;
> >
> > context->personality = current->personality;
> >
> > @@ -1541,7 +1550,7 @@ static void audit_log_exit(void)
> > for (aux = context->aux_pids; aux; aux = aux->next) {
> > struct
