* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Init lspcon after HPD in intel_dp_detect()
From: Patchwork @ 2020-02-14 21:24 UTC (permalink / raw)
To: Kai-Heng Feng; +Cc: intel-gfx
In-Reply-To: <20200214175646.25532-1-kai.heng.feng@canonical.com>
== Series Details ==
Series: drm/i915: Init lspcon after HPD in intel_dp_detect()
URL : https://patchwork.freedesktop.org/series/73480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16576
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/index.html
Known issues
------------
Here are the changes found in Patchwork_16576 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][1] ([i915#694]) -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [TIMEOUT][3] ([fdo#112271] / [i915#1084]) -> [PASS][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_exec_parallel@fds.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-byt-n2820/igt@gem_exec_parallel@fds.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][5] ([i915#424]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 41)
------------------------------
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing (10): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 fi-skl-lmem fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7942 -> Patchwork_16576
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16576: b2ae75309a73a42403618e73da934af0caf97eec @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b2ae75309a73 drm/i915: Init lspcon after HPD in intel_dp_detect()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Feature Suggestion: Allow to enforce "rename" in git while committing
From: Bruno Macabeus @ 2020-02-14 21:23 UTC (permalink / raw)
To: git
Hello for all,
initially I posted a question on Stack Overflow asking if is possible
to do something using Git, but seems that there is no away to do that,
and I think that it could be useful in order to improve the
organisation on logs.
My user case is:
- I'm doing a refactor on a project, migrating from JS to TS
- So I need to rename a file from index.js to index.ts (for example)
- Since the TS build steps are different, I also need to change its contents
- Sometimes I need to do so much changes that git thinks that I
removed index.js and created index.ts, but it's wrong, losing its
tracking on logs!
I should not create one commit just renaming the file and on another
commit updating its content, because the project won't build on the
first commit (since the build steps is different on a .ts file). And I
don't want to create a commit that the project can't be built on.
So I think that would be useful explicitly say to git "Hey, you should
forgot the minimum similarity threshold on this file and on this
commit. I renamed this file from index.js to index.ts. You should bind
they".
Is it make sense?
Thank you!
^ permalink raw reply
* Re: [PATCH v3 00/12] Enable per-file/directory DAX operations V3
From: Jeff Moyer @ 2020-02-14 21:23 UTC (permalink / raw)
To: Ira Weiny
Cc: Dan Williams, Darrick J. Wong, Linux Kernel Mailing List,
Alexander Viro, Dave Chinner, Christoph Hellwig,
Theodore Y. Ts'o, Jan Kara, linux-ext4, linux-xfs,
linux-fsdevel
In-Reply-To: <20200214200607.GA18593@iweiny-DESK2.sc.intel.com>
Ira Weiny <ira.weiny@intel.com> writes:
> [disclaimer: the following assumes the underlying 'device' (superblock)
> supports DAX]
>
> ... which results in S_DAX == false when the file is opened without the mount
> option. The key would be that all directories/files created under a root with
> XFS_DIFLAG2_DAX == true would inherit their flag and be XFS_DIFLAG2_DAX == true
> all the way down the tree. Any file not wanting DAX would need to set
> XFS_DIFLAG2_DAX == false. And setting false could be used on a directory to
> allow a user or group to not use dax on files in that sub-tree.
>
> Then without '-o dax' (XFS_MOUNT_DAX == false) all files when opened set S_DAX
> equal to XFS_DIFLAG2_DAX value. (Directories, as of V4, never get S_DAX set.)
>
> If '-o dax' (XFS_MOUNT_DAX == true) then S_DAX is set on all files.
One more clarifying question. Let's say I set XFS_DIFLAG2_DAX on an
inode. I then open the file, and perform mmap/load/store/etc. I close
the file, and I unset XFS_DIFLAG2_DAX. Will the next open treat the
file as S_DAX or not? My guess is the inode won't be evicted, and so
S_DAX will remain set.
The reason I ask is I've had requests from application developers to do
just this. They want to be able to switch back and forth between dax
modes.
Thanks,
Jeff
> [1] I'm beginning to think that if I type dax one more time I'm going to go
> crazy... :-P
dax dax dax!
^ permalink raw reply
* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] i915/gem_ctx_engines: Exercise 0 engines[]
From: Antonio Argenziano @ 2020-02-14 21:22 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
On 14/02/20 11:40, Chris Wilson wrote:
> Setup a context with no engines, and make sure we reject all execution
> attempts.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
> ---
> tests/i915/gem_ctx_engines.c | 45 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
> index cb82f08ef..063140e0f 100644
> --- a/tests/i915/gem_ctx_engines.c
> +++ b/tests/i915/gem_ctx_engines.c
> @@ -242,6 +242,48 @@ static void idempotent(int i915)
> gem_context_destroy(i915, p.ctx_id);
> }
>
> +static uint32_t batch_create(int i915)
> +{
> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> + uint32_t handle = gem_create(i915, 4096);
> +
> + gem_write(i915, handle, 0, &bbe, sizeof(bbe));
> + return handle;
> +}
> +
> +static void none(int i915)
> +{
> + struct i915_context_param_engines engines = {};
> + struct drm_i915_gem_context_param p = {
> + .ctx_id = gem_context_create(i915),
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + .value = to_user_pointer(&engines),
> + .size = sizeof(engines),
> + };
> +
> + gem_context_set_param(i915, &p);
> +
> + {
> + struct drm_i915_gem_exec_object2 obj = {
> + .handle = batch_create(i915),
> + };
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = to_user_pointer(&obj),
> + .buffer_count = 1,
> + .rsvd1 = p.ctx_id,
> + };
> +
> + for (execbuf.flags = 0;
> + execbuf.flags <= I915_EXEC_RING_MASK;
> + execbuf.flags++)
> + igt_assert_eq(__gem_execbuf(i915, &execbuf), -EINVAL);
> +
> + gem_close(i915, obj.handle);
> + }
> +
> + gem_context_destroy(i915, p.ctx_id);
> +}
> +
> static void execute_one(int i915)
> {
> I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
> @@ -527,6 +569,9 @@ igt_main
> igt_subtest("idempotent")
> idempotent(i915);
>
> + igt_subtest("none")
> + none(i915);
> +
> igt_subtest("execute-one")
> execute_one(i915);
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t 1/4] i915/gem_ctx_engines: Exercise 0 engines[]
From: Antonio Argenziano @ 2020-02-14 21:22 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
On 14/02/20 11:40, Chris Wilson wrote:
> Setup a context with no engines, and make sure we reject all execution
> attempts.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
> ---
> tests/i915/gem_ctx_engines.c | 45 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
> index cb82f08ef..063140e0f 100644
> --- a/tests/i915/gem_ctx_engines.c
> +++ b/tests/i915/gem_ctx_engines.c
> @@ -242,6 +242,48 @@ static void idempotent(int i915)
> gem_context_destroy(i915, p.ctx_id);
> }
>
> +static uint32_t batch_create(int i915)
> +{
> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> + uint32_t handle = gem_create(i915, 4096);
> +
> + gem_write(i915, handle, 0, &bbe, sizeof(bbe));
> + return handle;
> +}
> +
> +static void none(int i915)
> +{
> + struct i915_context_param_engines engines = {};
> + struct drm_i915_gem_context_param p = {
> + .ctx_id = gem_context_create(i915),
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + .value = to_user_pointer(&engines),
> + .size = sizeof(engines),
> + };
> +
> + gem_context_set_param(i915, &p);
> +
> + {
> + struct drm_i915_gem_exec_object2 obj = {
> + .handle = batch_create(i915),
> + };
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = to_user_pointer(&obj),
> + .buffer_count = 1,
> + .rsvd1 = p.ctx_id,
> + };
> +
> + for (execbuf.flags = 0;
> + execbuf.flags <= I915_EXEC_RING_MASK;
> + execbuf.flags++)
> + igt_assert_eq(__gem_execbuf(i915, &execbuf), -EINVAL);
> +
> + gem_close(i915, obj.handle);
> + }
> +
> + gem_context_destroy(i915, p.ctx_id);
> +}
> +
> static void execute_one(int i915)
> {
> I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
> @@ -527,6 +569,9 @@ igt_main
> igt_subtest("idempotent")
> idempotent(i915);
>
> + igt_subtest("none")
> + none(i915);
> +
> igt_subtest("execute-one")
> execute_one(i915);
>
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
From: Parav Pandit @ 2020-02-14 21:22 UTC (permalink / raw)
To: Jeff Kirsher, davem@davemloft.net, gregkh@linuxfoundation.org
Cc: Dave Ertman, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
nhorman@redhat.com, sassmann@redhat.com, jgg@ziepe.ca,
galpress@amazon.com, selvin.xavier@broadcom.com,
sriharsha.basavapatna@broadcom.com, benve@cisco.com,
bharat@chelsio.com, xavier.huwei@huawei.com, Yishai Hadas,
Leon Romanovsky, mkalderon@marvell.com, aditr@vmware.com,
Kiran Patil, Andrew Bowers
In-Reply-To: <20200212191424.1715577-2-jeffrey.t.kirsher@intel.com>
On 2/12/2020 1:14 PM, Jeff Kirsher wrote:
> From: Dave Ertman <david.m.ertman@intel.com>
>
> This is the initial implementation of the Virtual Bus,
> virtbus_device and virtbus_driver. The virtual bus is
> a software based bus intended to support registering
> virtbus_devices and virtbus_drivers and provide matching
> between them and probing of the registered drivers.
>
> The bus will support probe/remove shutdown and
> suspend/resume callbacks.
>
> Kconfig and Makefile alterations are included
>
> Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> Signed-off-by: Kiran Patil <kiran.patil@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> Documentation/driver-api/virtual_bus.rst | 59 +++++
> drivers/bus/Kconfig | 11 +
> drivers/bus/Makefile | 1 +
> drivers/bus/virtual_bus.c | 267 +++++++++++++++++++++++
> include/linux/mod_devicetable.h | 8 +
> include/linux/virtual_bus.h | 57 +++++
> scripts/mod/devicetable-offsets.c | 3 +
> scripts/mod/file2alias.c | 8 +
> 8 files changed, 414 insertions(+)
> create mode 100644 Documentation/driver-api/virtual_bus.rst
> create mode 100644 drivers/bus/virtual_bus.c
> create mode 100644 include/linux/virtual_bus.h
>
> diff --git a/Documentation/driver-api/virtual_bus.rst b/Documentation/driver-api/virtual_bus.rst
> new file mode 100644
> index 000000000000..5f35c19171d7
> --- /dev/null
> +++ b/Documentation/driver-api/virtual_bus.rst
> @@ -0,0 +1,59 @@
> +===============================
> +Virtual Bus Devices and Drivers
> +===============================
> +
> +See <linux/virtual_bus.h> for the models for virtbus_device and virtbus_driver.
> +This bus is meant to be a lightweight software based bus to attach generic
> +devices and drivers to so that a chunk of data can be passed between them.
> +
> +One use case example is an rdma driver needing to connect with several
> +different types of PCI LAN devices to be able to request resources from
> +them (queue sets). Each LAN driver that supports rdma will register a
> +virtbus_device on the virtual bus for each physical function. The rdma
> +driver will register as a virtbus_driver on the virtual bus to be
> +matched up with multiple virtbus_devices and receive a pointer to a
> +struct containing the callbacks that the PCI LAN drivers support for
> +registering with them.
> +
> +Sections in this document:
> + Virtbus devices
> + Virtbus drivers
> + Device Enumeration
> + Device naming and driver binding
> + Virtual Bus API entry points
> +
> +Virtbus devices
> +~~~~~~~~~~~~~~~
> +Virtbus_devices support the minimal device functionality. Devices will
> +accept a name, and then, when added to the virtual bus, an automatically
> +generated index is concatenated onto it for the virtbus_device->name.
> +
> +Virtbus drivers
> +~~~~~~~~~~~~~~~
> +Virtbus drivers register with the virtual bus to be matched with virtbus
> +devices. They expect to be registered with a probe and remove callback,
> +and also support shutdown, suspend, and resume callbacks. They otherwise
> +follow the standard driver behavior of having discovery and enumeration
> +handled in the bus infrastructure.
> +
> +Virtbus drivers register themselves with the API entry point virtbus_drv_reg
> +and unregister with virtbus_drv_unreg.
> +
If you are mentioning API names, please keep the API documentation match
with API name in header file.
> +Device Enumeration
> +~~~~~~~~~~~~~~~~~~
> +Enumeration is handled automatically by the bus infrastructure via the
> +ida_simple methods.
> +
> +Device naming and driver binding
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +The virtbus_device.dev.name is the canonical name for the device. It is
> +built from two other parts:
> +
> + - virtbus_device.name (also used for matching).
> + - virtbus_device.id (generated automatically from ida_simple calls)
> +
> +Virtbus device IDs are always in "<name>.<instance>" format. Instances are
> +automatically selected through an ida_simple_get so are positive integers.
> +Names are taken from the device name field.
Name is taken from the device name field.
Driver IDs are simple <name>.
> +Need to extract the name from the Virtual Device compare to name of the
> +driver.
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 6095b6df8a81..2e8b89c1761a 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -202,4 +202,15 @@ config DA8XX_MSTPRI
>
> source "drivers/bus/fsl-mc/Kconfig"
>
> +config VIRTUAL_BUS
> + tristate "Software based Virtual Bus"
> + help
> + Provides a software bus for virtbus_devices to be added to it
> + and virtbus_drivers to be registered on it. Will create a match> + between the driver and device, then call the driver's probe with
> + the virtbus_device's struct.
below text reads better for "Will create a match.."
It matches driver and device based on id and calls driver's probe routine.
> + One example is the irdma driver needing to connect with various
> + PCI LAN drivers to request resources (queues) to be able to perform
> + its function.
> +
> endmenu
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 1320bcf9fa9d..6721c77dc71b 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -34,3 +34,4 @@ obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
> obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
>
> obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
> +obj-$(CONFIG_VIRTUAL_BUS) += virtual_bus.o
> diff --git a/drivers/bus/virtual_bus.c b/drivers/bus/virtual_bus.c
> new file mode 100644
> index 000000000000..85d2dbfa3376
> --- /dev/null
> +++ b/drivers/bus/virtual_bus.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * virtual_bus.c - lightweight software based bus for virtual devices
> + *
> + * Copyright (c) 2019-20 Intel Corporation
> + *
> + * Please see Documentation/driver-api/virtual_bus.rst for
> + * more information
> + */
> +
> +#include <linux/string.h>
> +#include <linux/virtual_bus.h>
> +#include <linux/of_irq.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/pm_domain.h>
> +#include <linux/acpi.h>
> +#include <linux/device.h>
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Lightweight Virtual Bus");
Last time Greg had comment about "Lightweight".
In the bus/Kconfig, it is named as "software based virtual bus".
Just say "Virtual bus".
> +MODULE_AUTHOR("David Ertman <david.m.ertman@intel.com>");
> +MODULE_AUTHOR("Kiran Patil <kiran.patil@intel.com>");
> +
> +static DEFINE_IDA(virtbus_dev_ida);
> +
> +static const
> +struct virtbus_dev_id *virtbus_match_id(const struct virtbus_dev_id *id,
> + struct virtbus_device *vdev)
> +{
> + while (id->name[0]) {
> + if (!strcmp(vdev->name, id->name)) {
> + vdev->matched_element = id;
I am yet to review the actual usage of matched_element field in
subsequent patches, but assigning this inside the match routine doesn't
look correct.
> + return id;
> + }
> + id++;
> + }
> + return NULL;
> +}
> +
> +static int virtbus_match(struct device *dev, struct device_driver *drv)
> +{
> + struct virtbus_driver *vdrv = to_virtbus_drv(drv);
> + struct virtbus_device *vdev = to_virtbus_dev(dev);
> +
> + return virtbus_match_id(vdrv->id_table, vdev) != NULL;
> +}
> +
> +static int virtbus_probe(struct device *dev)
> +{
> + return dev->driver->probe(dev);
> +}
> +
> +static int virtbus_remove(struct device *dev)
> +{
> + return dev->driver->remove(dev);
> +}
> +
> +static void virtbus_shutdown(struct device *dev)
> +{
> + dev->driver->shutdown(dev);
> +}
> +
> +static int virtbus_suspend(struct device *dev, pm_message_t state)
> +{
> + if (dev->driver->suspend)
> + return dev->driver->suspend(dev, state);
> +
> + return 0;
> +}
> +
> +static int virtbus_resume(struct device *dev)
> +{
> + if (dev->driver->resume)
> + return dev->driver->resume(dev);
> +
> + return 0;
> +}
> +
> +struct bus_type virtual_bus_type = {
static struct bus_type.
> + .name = "virtbus",
> + .match = virtbus_match,
> + .probe = virtbus_probe,
> + .remove = virtbus_remove,
> + .shutdown = virtbus_shutdown,
> + .suspend = virtbus_suspend,
> + .resume = virtbus_resume,
> +};
> +
> +/**
> + * virtbus_dev_release - Destroy a virtbus device
> + * @vdev: virtual device to release
> + */
> +static void virtbus_dev_release(struct device *_dev)
> +{
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> +
> + ida_simple_remove(&virtbus_dev_ida, vdev->id);
Device is not yet released. It is getting released below. Please move
ida_simple_remove() after completing the release call. Save vdev->id first.
This makes mirror sequence of dev_register() once you move ida_get
before device_initialize() as Greg suggested.
> + vdev->release(vdev);
> +}
> +
> +/**
> + * virtbus_dev_register - add a virtual bus device
> + * @vdev: virtual bus device to add
> + */
> +int virtbus_dev_register(struct virtbus_device *vdev)
> +{
> + int ret;
> +
> + if (!vdev->release) {
> + dev_err(&vdev->dev, "virtbus_device .release callback NULL\n");
> + return -EINVAL;
> + }
> +
> + device_initialize(&vdev->dev);
> +
> + vdev->dev.bus = &virtual_bus_type;
> + vdev->dev.release = virtbus_dev_release;
> + /* All device IDs are automatically allocated */
> + ret = ida_simple_get(&virtbus_dev_ida, 0, 0, GFP_KERNEL);
> + if (ret < 0) {
> + dev_err(&vdev->dev, "get IDA idx for virtbus device failed!\n");
> + put_device(&vdev->dev);
> + return ret;
> + }
> +
> + vdev->id = ret;
> + dev_set_name(&vdev->dev, "%s.%d", vdev->name, vdev->id);
> +
> + dev_dbg(&vdev->dev, "Registering virtbus device '%s'\n",
> + dev_name(&vdev->dev));
> +
> + ret = device_add(&vdev->dev);
> + if (ret)
> + goto device_add_err;
> +
> + return 0;
> +
> +device_add_err:
> + dev_err(&vdev->dev, "Add device to virtbus failed!\n");
Print error code along with the error line is more useful.
> + put_device(&vdev->dev);
> + ida_simple_remove(&virtbus_dev_ida, vdev->id);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(virtbus_dev_register);
> +
> +/**
> + * virtbus_dev_unregister - remove a virtual bus device
> + * vdev: virtual bus device we are removing
> + */
> +void virtbus_dev_unregister(struct virtbus_device *vdev)
> +{
> + device_del(&vdev->dev);
> + put_device(&vdev->dev);
> +}
> +EXPORT_SYMBOL_GPL(virtbus_dev_unregister);
> +
> +static int virtbus_drv_probe(struct device *_dev)
> +{
> + struct virtbus_driver *vdrv = to_virtbus_drv(_dev->driver);
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> + int ret;
> +
> + ret = dev_pm_domain_attach(_dev, true);
> + if (ret) {
> + dev_warn(_dev, "Failed to attatch to PM Domain : %d\n", ret);
> + return ret;
> + }
> +
> + ret = vdrv->probe(vdev);
> + if (ret) {
> + dev_err(&vdev->dev, "Probe returned error\n");
> + dev_pm_domain_detach(_dev, true);
> + }
> +
> + return ret;
> +}
> +
> +static int virtbus_drv_remove(struct device *_dev)
> +{
> + struct virtbus_driver *vdrv = to_virtbus_drv(_dev->driver);
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> + int ret = 0;
> +
> + ret = vdrv->remove(vdev);
> + dev_pm_domain_detach(_dev, true);
> +
> + return ret;
> +}
> +
> +static void virtbus_drv_shutdown(struct device *_dev)
> +{
> + struct virtbus_driver *vdrv = to_virtbus_drv(_dev->driver);
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> +
> + vdrv->shutdown(vdev);
> +}
> +
> +static int virtbus_drv_suspend(struct device *_dev, pm_message_t state)
> +{
> + struct virtbus_driver *vdrv = to_virtbus_drv(_dev->driver);
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> +
> + if (vdrv->suspend)
> + return vdrv->suspend(vdev, state);
> +
> + return 0;
> +}
> +
> +static int virtbus_drv_resume(struct device *_dev)
> +{
> + struct virtbus_driver *vdrv = to_virtbus_drv(_dev->driver);
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> +
> + if (vdrv->resume)
> + return vdrv->resume(vdev);
> +
> + return 0;
> +}
> +
> +/**
> + * __virtbus_drv_register - register a driver for virtual bus devices
> + * @vdrv: virtbus_driver structure
> + * @owner: owning module/driver
> + */
> +int __virtbus_drv_register(struct virtbus_driver *vdrv, struct module *owner)
> +{
Lets keep name consistent with other subsystems such as,
pci_register_driver(), spi_register_driver() etc as
virtbus_register_driver() and unregister().
> + if (!vdrv->probe || !vdrv->remove || !vdrv->shutdown || !vdrv->id_table)
> + return -EINVAL;
> +
> + vdrv->driver.owner = owner;
> + vdrv->driver.bus = &virtual_bus_type;
> + vdrv->driver.probe = virtbus_drv_probe;
> + vdrv->driver.remove = virtbus_drv_remove;
> + vdrv->driver.shutdown = virtbus_drv_shutdown;
> + vdrv->driver.suspend = virtbus_drv_suspend;
> + vdrv->driver.resume = virtbus_drv_resume;
> +
> + return driver_register(&vdrv->driver);
> +}
> +EXPORT_SYMBOL_GPL(__virtbus_drv_register);
> +
> +/**
> + * virtbus_drv_unregister - unregister a driver for virtual bus devices
> + * @drv: virtbus_driver structure
> + */
> +void virtbus_drv_unregister(struct virtbus_driver *vdrv)
> +{
> + driver_unregister(&vdrv->driver);
> +}
> +EXPORT_SYMBOL_GPL(virtbus_drv_unregister);
^ permalink raw reply
* Re: [PATCH 08/35] KVM: s390: protvirt: Add initial lifecycle handling
From: Christian Borntraeger @ 2020-02-14 21:22 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
Andrea Arcangeli, linux-s390, Michael Mueller, Vasily Gorbik,
Janosch Frank
In-Reply-To: <e627e0a6-b27a-7e3a-05cd-056eb49ed16e@redhat.com>
On 14.02.20 19:39, David Hildenbrand wrote:
> On 07.02.20 12:39, Christian Borntraeger wrote:
>> From: Janosch Frank <frankja@linux.ibm.com>
>>
>> This contains 3 main changes:
>> 1. changes in SIE control block handling for secure guests
>> 2. helper functions for create/destroy/unpack secure guests
>> 3. KVM_S390_PV_COMMAND ioctl to allow userspace dealing with secure
>> machines
[...]
>
> I feel like my review comments for this patch were lost, so not
> repeating them
Basically you only asked if we could combine vm/vcpu_create/destroy into
enable/disable. Janosch came up with some cases regarding error handling
where the enable/disable would be hard to do right and exposing the single
interfaces provide some advantages.
If you still want to go down that path, please look at the next round of
kernel/qemu patches and then lets discuss.
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12.
From: Patchwork @ 2020-02-14 21:20 UTC (permalink / raw)
To: Caz Yokoyama; +Cc: intel-gfx
In-Reply-To: <3e1780946bd06f42b9d9e2a2fd1169923dd52e9f.1581444370.git.caz.yokoyama@intel.com>
== Series Details ==
Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12.
URL : https://patchwork.freedesktop.org/series/73332/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7924_full -> Patchwork_16531_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_16531_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16531_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16531_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_async@concurrent-writes-render:
- shard-tglb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@gem_exec_async@concurrent-writes-render.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-tglb1/igt@gem_exec_async@concurrent-writes-render.html
Known issues
------------
Here are the changes found in Patchwork_16531_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +9 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb4/igt@gem_exec_parallel@vcs1-fds.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb8/igt@gem_exec_parallel@vcs1-fds.html
* igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb3/igt@gem_exec_schedule@pi-common-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb1/igt@gem_exec_schedule@pi-common-bsd.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb6/igt@gem_exec_schedule@preempt-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb2/igt@gem_exec_schedule@preempt-bsd.html
* igt@gem_partial_pwrite_pread@writes-after-reads:
- shard-hsw: [PASS][9] -> [FAIL][10] ([i915#694]) +1 similar issue
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw7/igt@gem_partial_pwrite_pread@writes-after-reads.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-hsw1/igt@gem_partial_pwrite_pread@writes-after-reads.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-kbl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#79])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl6/igt@kms_flip@flip-vs-expired-vblank.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl7/igt@kms_flip@flip-vs-expired-vblank.html
* igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb6/igt@kms_psr@psr2_cursor_plane_onoff.html
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103665])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl1/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-kbl4/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl2/igt@kms_vblank@pipe-c-ts-continuation-suspend.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-apl8/igt@kms_vblank@pipe-c-ts-continuation-suspend.html
* igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +15 similar issues
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@prime_vgem@fence-wait-bsd2.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb5/igt@prime_vgem@fence-wait-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@blt}:
- shard-apl: [FAIL][23] ([i915#679]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl4/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-apl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-apl: [INCOMPLETE][25] ([fdo#103927]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl4/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-apl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [DMESG-WARN][27] ([i915#180]) -> [PASS][28] +2 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl4/igt@gem_eio@in-flight-suspend.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-kbl3/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [SKIP][29] ([fdo#109276]) -> [PASS][30] +23 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb8/igt@gem_exec_schedule@independent-bsd2.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [SKIP][31] ([i915#677]) -> [PASS][32] +1 similar issue
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb1/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb6/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@pi-shared-iova-blt:
- shard-kbl: [INCOMPLETE][33] ([fdo#103665]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl3/igt@gem_exec_schedule@pi-shared-iova-blt.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-kbl3/igt@gem_exec_schedule@pi-shared-iova-blt.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [SKIP][35] ([fdo#112146]) -> [PASS][36] +2 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb6/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-skl: [FAIL][37] ([i915#644]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl9/igt@gem_ppgtt@flink-and-close-vma-leak.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl8/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_tiled_partial_pwrite_pread@writes-after-reads:
- shard-hsw: [FAIL][39] -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw5/igt@gem_tiled_partial_pwrite_pread@writes-after-reads.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-hsw7/igt@gem_tiled_partial_pwrite_pread@writes-after-reads.html
* igt@gen7_exec_parse@basic-allocation:
- shard-hsw: [FAIL][41] ([i915#694]) -> [PASS][42] +2 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw1/igt@gen7_exec_parse@basic-allocation.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-hsw5/igt@gen7_exec_parse@basic-allocation.html
* igt@i915_suspend@forcewake:
- shard-skl: [INCOMPLETE][43] ([i915#69]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl10/igt@i915_suspend@forcewake.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl4/igt@i915_suspend@forcewake.html
* igt@kms_flip@flip-vs-suspend:
- shard-skl: [INCOMPLETE][45] ([i915#221]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl5/igt@kms_flip@flip-vs-suspend.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl5/igt@kms_flip@flip-vs-suspend.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-apl: [DMESG-WARN][47] ([i915#180]) -> [PASS][48] +3 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-apl3/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
- shard-glk: [FAIL][49] ([i915#49]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-glk6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-glk3/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [FAIL][51] ([fdo#108145]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [SKIP][53] ([fdo#109441]) -> [PASS][54] +1 similar issue
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb6/igt@kms_psr@psr2_cursor_render.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
* igt@kms_setmode@basic:
- shard-skl: [FAIL][55] ([i915#31]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl7/igt@kms_setmode@basic.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl1/igt@kms_setmode@basic.html
* igt@perf_pmu@init-busy-vcs1:
- shard-iclb: [SKIP][57] ([fdo#112080]) -> [PASS][58] +10 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb3/igt@perf_pmu@init-busy-vcs1.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb1/igt@perf_pmu@init-busy-vcs1.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][59] ([i915#831]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw5/igt@prime_mmap_coherency@ioctl-errors.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-hsw6/igt@prime_mmap_coherency@ioctl-errors.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv-switch:
- shard-iclb: [FAIL][61] ([IGT#28]) -> [SKIP][62] ([fdo#112080])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb7/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html
* igt@gem_tiled_blits@normal:
- shard-hsw: [FAIL][63] ([i915#694]) -> [FAIL][64] ([i915#818])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw7/igt@gem_tiled_blits@normal.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-hsw1/igt@gem_tiled_blits@normal.html
* igt@i915_pm_dc@dc6-psr:
- shard-tglb: [SKIP][65] ([i915#468]) -> [FAIL][66] ([i915#454])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@i915_pm_dc@dc6-psr.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-tglb8/igt@i915_pm_dc@dc6-psr.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1197]: https://gitlab.freedesktop.org/drm/intel/issues/1197
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#221]: https://gitlab.freedesktop.org/drm/intel/issues/221
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7924 -> Patchwork_16531
CI-20190529: 20190529
CI_DRM_7924: d4ea682de87f4e4378f34f0a196e8fa8983bd306 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16531: cbf3d2d61711eb72a4bbb3180d707e637e3971ea @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 5.5 000/120] 5.5.4-stable review
From: Greg Kroah-Hartman @ 2020-02-14 21:17 UTC (permalink / raw)
To: Jeffrin Jose
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
In-Reply-To: <20200214155834.GA6389@debian>
On Fri, Feb 14, 2020 at 09:28:34PM +0530, Jeffrin Jose wrote:
> On Thu, Feb 13, 2020 at 07:19:56AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.5.4 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 15 Feb 2020 15:16:41 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.4-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> >
>
> hello,
>
> compiled and booted 5.5.4-rc1+ . No new errors according to "dmesg -l err"
Wonderful, thanks for testing and letting me know.
greg k-h
^ permalink raw reply
* Re: [PATCH 5.5 000/120] 5.5.4-stable review
From: Greg Kroah-Hartman @ 2020-02-14 21:18 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20200214162829.GD18488@roeck-us.net>
On Fri, Feb 14, 2020 at 08:28:29AM -0800, Guenter Roeck wrote:
> On Thu, Feb 13, 2020 at 07:19:56AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.5.4 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 15 Feb 2020 15:16:41 +0000.
> > Anything received after that time might be too late.
> >
>
> For v5.5.3-121-ged6d023a1817:
>
> Build results:
> total: 157 pass: 157 fail: 0
> Qemu test results:
> total: 400 pass: 400 fail: 0
Great, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply
* Re: [PATCH for 4.19-stable] padata: fix null pointer deref of pd->pinst
From: Greg Kroah-Hartman @ 2020-02-14 21:17 UTC (permalink / raw)
To: Daniel Jordan
Cc: Sasha Levin, Yang Yingliang, Herbert Xu, Steffen Klassert,
linux-kernel, stable
In-Reply-To: <20200214182821.337706-1-daniel.m.jordan@oracle.com>
On Fri, Feb 14, 2020 at 01:28:21PM -0500, Daniel Jordan wrote:
> The 4.19 backport dc34710a7aba ("padata: Remove broken queue flushing")
> removed padata_alloc_pd()'s assignment to pd->pinst, resulting in:
>
> Unable to handle kernel NULL pointer dereference ...
> ...
> pc : padata_reorder+0x144/0x2e0
> ...
> Call trace:
> padata_reorder+0x144/0x2e0
> padata_do_serial+0xc8/0x128
> pcrypt_aead_enc+0x60/0x70 [pcrypt]
> padata_parallel_worker+0xd8/0x138
> process_one_work+0x1bc/0x4b8
> worker_thread+0x164/0x580
> kthread+0x134/0x138
> ret_from_fork+0x10/0x18
>
> This happened because the backport was based on an enhancement that
> moved this assignment but isn't in 4.19:
>
> bfde23ce200e ("padata: unbind parallel jobs from specific CPUs")
>
> Simply restore the assignment to fix the crash.
>
> Fixes: dc34710a7aba ("padata: Remove broken queue flushing")
> Reported-by: Yang Yingliang <yangyingliang@huawei.com>
> Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
> ---
> kernel/padata.c | 1 +
> 1 file changed, 1 insertion(+)
Thanks for this, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH v1 3/3] virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM
From: David Hildenbrand @ 2020-02-14 21:17 UTC (permalink / raw)
To: Tyler Sanderson
Cc: David Hildenbrand, Michal Hocko, linux-kernel, linux-mm,
virtualization, Michael S . Tsirkin, Wei Wang, Alexander Duyck,
David Rientjes, Nadav Amit
In-Reply-To: <CAJuQAmpGKcyWo8Ojnia_pXZAaOt98u0c_Sk-8ieCO218hutW1g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
> Am 14.02.2020 um 21:49 schrieb Tyler Sanderson <tysand@google.com>:
>
>
> Regarding Wei's patch that modifies the shrinker implementation, versus this patch which reverts to OOM notifier:
> I am in favor of both patches. But I do want to make sure a fix gets back ported to 4.19 where the performance regression was first introduced.
> My concern with reverting to the OOM notifier is, as mst@ put it (in the other thread):
> "when linux hits OOM all kind of error paths are being hit, latent bugs start triggering, latency goes up drastically."
Yeah, and that was the default behavior for years, so it‘s not big news :)
> The guest could be in a lot of pain before the OOM notifier is invoked, and it seems like the shrinker API might allow more fine grained control of when we deflate.
>
> On the other hand, I'm not totally convinced that Wei's patch is an expected use of the shrinker/page-cache APIs, and maybe it is fragile. Needs more testing and scrutiny.
>
> It seems to me like the shrinker API is the right API in the long run, perhaps with some fixes and modifications. But maybe reverting to OOM notifier is the best patch to back
I think that‘s a good idea. Revert to the old state we had for years and then implement a proper, fully tested solution (e.g., shrinkers with priorities).
Cheers!
[-- Attachment #2: Type: text/html, Size: 1967 bytes --]
^ permalink raw reply
* Re: [PATCH] btrfs: add a find_contiguous_extent_bit helper and use it for safe isize
From: David Sterba @ 2020-02-14 21:17 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs, kernel-team
In-Reply-To: <20200212183831.78293-1-josef@toxicpanda.com>
On Wed, Feb 12, 2020 at 01:38:31PM -0500, Josef Bacik wrote:
> Filipe noticed a race where we would sometimes get the wrong answer for
> the i_disk_size for !NO_HOLES with my patch. That is because I expected
> that find_first_extent_bit() would find the contiguous range, since I'm
> only ever setting EXTENT_DIRTY. However the way set_extent_bit() works
> is it'll temporarily split the range, loop around and set our bits, and
> then merge the state. When it loops it drops the tree->lock, so there
> is a window where we can have two adjacent states instead of one large
> state. Fix this by walking forward until we find a non-contiguous
> state, and set our end_ret to the end of our logically contiguous area.
> This fixes the problem without relying on specific behavior from
> set_extent_bit().
>
> Fixes: 79ceff7f6e5d ("btrfs: introduce per-inode file extent tree")
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> Dave, I assume you'll want to fold this in to the referenced patch, if not let
> me know and I'll rework the series to include this as a different patch.
Folding looks like a good option, the patch adds other helper for
btrfs_inode_clear_file_extent_range so this patch fits in nicely.
> +/**
> + * find_contiguous_extent_bit: find a contiguous area of bits
> + * @tree - io tree to check
> + * @start - offset to start the search from
> + * @start_ret - the first offset we found with the bits set
> + * @end_ret - the final contiguous range of the bits that were set
> + *
> + * set_extent_bit anc clear_extent_bit can temporarily split contiguous ranges
> + * to set bits appropriately, and then merge them again. During this time it
> + * will drop the tree->lock, so use this helper if you want to find the actual
> + * contiguous area for given bits. We will search to the first bit we find, and
> + * then walk down the tree until we find a non-contiguous area. The area
> + * returned will be the full contiguous area with the bits set.
> + */
This summarizes why it's needed so the changelog does not need to be
updated AFAICS. Patch updated and misc-next pushed. Thanks.
^ permalink raw reply
* Re: [PATCH v1 3/3] virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM
From: David Hildenbrand @ 2020-02-14 21:17 UTC (permalink / raw)
To: Tyler Sanderson
Cc: Michael S . Tsirkin, linux-kernel, Michal Hocko, linux-mm,
Nadav Amit, David Rientjes, Alexander Duyck, virtualization
In-Reply-To: <CAJuQAmpGKcyWo8Ojnia_pXZAaOt98u0c_Sk-8ieCO218hutW1g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1345 bytes --]
> Am 14.02.2020 um 21:49 schrieb Tyler Sanderson <tysand@google.com>:
>
>
> Regarding Wei's patch that modifies the shrinker implementation, versus this patch which reverts to OOM notifier:
> I am in favor of both patches. But I do want to make sure a fix gets back ported to 4.19 where the performance regression was first introduced.
> My concern with reverting to the OOM notifier is, as mst@ put it (in the other thread):
> "when linux hits OOM all kind of error paths are being hit, latent bugs start triggering, latency goes up drastically."
Yeah, and that was the default behavior for years, so it‘s not big news :)
> The guest could be in a lot of pain before the OOM notifier is invoked, and it seems like the shrinker API might allow more fine grained control of when we deflate.
>
> On the other hand, I'm not totally convinced that Wei's patch is an expected use of the shrinker/page-cache APIs, and maybe it is fragile. Needs more testing and scrutiny.
>
> It seems to me like the shrinker API is the right API in the long run, perhaps with some fixes and modifications. But maybe reverting to OOM notifier is the best patch to back
I think that‘s a good idea. Revert to the old state we had for years and then implement a proper, fully tested solution (e.g., shrinkers with priorities).
Cheers!
[-- Attachment #1.2: Type: text/html, Size: 1967 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 05/35] s390/mm: provide memory management functions for protected KVM guests
From: Christian Borntraeger @ 2020-02-14 21:17 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
Andrea Arcangeli, linux-s390, Michael Mueller, Vasily Gorbik,
linux-mm, Andrew Morton
In-Reply-To: <1fb4da22-bab4-abe3-847b-5a7d79d84774@redhat.com>
In general this patch has changed a lot, but several comments still apply
On 14.02.20 18:59, David Hildenbrand wrote:
>>
>> /*
>> @@ -1086,12 +1106,16 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
>> unsigned long addr,
>> pte_t *ptep, int full)
>> {
>> + pte_t res;
>
> Empty line missing.
ack
>
>> if (full) {
>> - pte_t pte = *ptep;
>> + res = *ptep;
>> *ptep = __pte(_PAGE_INVALID);
>> - return pte;
>> + } else {
>> + res = ptep_xchg_lazy(mm, addr, ptep, __pte(_PAGE_INVALID));
>> }
>> - return ptep_xchg_lazy(mm, addr, ptep, __pte(_PAGE_INVALID));
>> + if (mm_is_protected(mm) && pte_present(res))
>> + uv_convert_from_secure(pte_val(res) & PAGE_MASK);
>> + return res;
>> }
>
> [...]
>
>> +int uv_make_secure(struct gmap *gmap, unsigned long gaddr, void *uvcb);
>> +int uv_convert_from_secure(unsigned long paddr);
>> +
>> +static inline int uv_convert_to_secure(struct gmap *gmap, unsigned long gaddr)
>> +{
>> + struct uv_cb_cts uvcb = {
>> + .header.cmd = UVC_CMD_CONV_TO_SEC_STOR,
>> + .header.len = sizeof(uvcb),
>> + .guest_handle = gmap->guest_handle,
>> + .gaddr = gaddr,
>> + };
>> +
>> + return uv_make_secure(gmap, gaddr, &uvcb);
>> +}
>
> I'd actually suggest to name everything that eats a gmap "gmap_",
>
> e.g., "gmap_make_secure()"
>
> [...]
ack.
>
>>
>> #if defined(CONFIG_PROTECTED_VIRTUALIZATION_GUEST) || \
>> diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
>> index a06a628a88da..15ac598a3d8d 100644
>> --- a/arch/s390/kernel/uv.c
>> +++ b/arch/s390/kernel/uv.c
>> @@ -9,6 +9,8 @@
>> #include <linux/sizes.h>
>> #include <linux/bitmap.h>
>> #include <linux/memblock.h>
>> +#include <linux/pagemap.h>
>> +#include <linux/swap.h>
>> #include <asm/facility.h>
>> #include <asm/sections.h>
>> #include <asm/uv.h>
>> @@ -99,4 +101,174 @@ void adjust_to_uv_max(unsigned long *vmax)
>> if (prot_virt_host && *vmax > uv_info.max_sec_stor_addr)
>> *vmax = uv_info.max_sec_stor_addr;
>> }
>> +
>> +static int __uv_pin_shared(unsigned long paddr)
>> +{
>> + struct uv_cb_cfs uvcb = {
>> + .header.cmd = UVC_CMD_PIN_PAGE_SHARED,
>> + .header.len = sizeof(uvcb),
>> + .paddr = paddr,
>
> please drop all the superfluous spaces (just as in the other uv calls).
ack
>
>> + };
>> +
>> + if (uv_call(0, (u64)&uvcb))
>> + return -EINVAL;
>> + return 0;
>> +}
>
> [...]
>
>> +static int make_secure_pte(pte_t *ptep, unsigned long addr, void *data)
>> +{
>> + struct conv_params *params = data;
>> + pte_t entry = READ_ONCE(*ptep);
>> + struct page *page;
>> + int expected, rc = 0;
>> +
>> + if (!pte_present(entry))
>> + return -ENXIO;
>> + if (pte_val(entry) & (_PAGE_INVALID | _PAGE_PROTECT))
>> + return -ENXIO;
>> +
>> + page = pte_page(entry);
>> + if (page != params->page)
>> + return -ENXIO;
>> +
>> + if (PageWriteback(page))
>> + return -EAGAIN;
>> + expected = expected_page_refs(page);
>
> I do wonder if we could factor out expected_page_refs() and reuse from
> other sources ...
>
> I do wonder about huge page backing of guests, and especially
> hpage_nr_pages(page) used in mm/migrate.c:expected_page_refs(). But I
> can spot some hugepage exclusion below ... This needs comments.
Yes, we looked into several places and ALL places do their own math with their
own side conditions. There is no single function that accounts all possible
conditions and I am not going to start that now given the review bandwidth of
the mm tree.
I will add:
/*
* Calculate the expected ref_count for a page that would otherwise have no
* further pins. This was cribbed from similar functions in other places in
* the kernel, but with some slight modifications. We know that a secure
* page can not be a huge page for example.
*/
to expected page count
and something to the hugetlb check.
>
>> + if (!page_ref_freeze(page, expected))
>> + return -EBUSY;
>> + set_bit(PG_arch_1, &page->flags);
>
> Can we please document somewhere how PG_arch_1 is used on s390x? (page)
>
> "The generic code guarantees that this bit is cleared for a page when it
> first is entered into the page cache" - should not be an issue, right?
Right
>
>> + rc = uv_call(0, (u64)params->uvcb);
>> + page_ref_unfreeze(page, expected);
>> + if (rc)
>> + rc = (params->uvcb->rc == 0x10a) ? -ENXIO : -EINVAL;
>> + return rc;
>> +}
>> +
>> +/*
>> + * Requests the Ultravisor to make a page accessible to a guest.
>> + * If it's brought in the first time, it will be cleared. If
>> + * it has been exported before, it will be decrypted and integrity
>> + * checked.
>> + *
>> + * @gmap: Guest mapping
>> + * @gaddr: Guest 2 absolute address to be imported
>
> I'd just drop the the (incomplete) parameter documentation, everybody
> reaching this point should now what a gmap and what a gaddr is ...
ack.
>
>> + */
>> +int uv_make_secure(struct gmap *gmap, unsigned long gaddr, void *uvcb)
>> +{
>> + struct conv_params params = { .uvcb = uvcb };
>> + struct vm_area_struct *vma;
>> + unsigned long uaddr;
>> + int rc, local_drain = 0;
>> +
>> +again:
>> + rc = -EFAULT;
>> + down_read(&gmap->mm->mmap_sem);
>> +
>> + uaddr = __gmap_translate(gmap, gaddr);
>> + if (IS_ERR_VALUE(uaddr))
>> + goto out;
>> + vma = find_vma(gmap->mm, uaddr);
>> + if (!vma)
>> + goto out;
>> + if (is_vm_hugetlb_page(vma))
>> + goto out;
>
> Hah there it is! How is it enforced on upper layers/excluded? Will
> hpage=true fail with prot virt? What if a guest is not a protected guest
> but wants to sue huge pages? This needs comments/patch description.
will add
/*
* Secure pages cannot be huge and userspace should not combine both.
* In case userspace does it anyway this will result in an -EFAULT for
* the unpack. The guest is thus never reaching secure mode. If
* userspace is playing dirty tricky with mapping huge pages later
* on this will result in a segmenation fault.
*/
>
>> +
>> + rc = -ENXIO;
>> + params.page = follow_page(vma, uaddr, FOLL_WRITE | FOLL_NOWAIT);
>> + if (IS_ERR_OR_NULL(params.page))
>> + goto out;
>> +
>> + lock_page(params.page);
>> + rc = apply_to_page_range(gmap->mm, uaddr, PAGE_SIZE, make_secure_pte, ¶ms);
>
> Ehm, isn't it just always a single page?
Yes, already fixed.
>
>> + unlock_page(params.page);
>> +out:
>> + up_read(&gmap->mm->mmap_sem);
>> +
>> + if (rc == -EBUSY) {
>> + if (local_drain) {
>> + lru_add_drain_all();
>> + return -EAGAIN;
>> + }
>> + lru_add_drain();
>
> comments please why that is performed.
done
>
>> + local_drain = 1;
[..]
>> +
>> + if (PageHuge(page))
>> + return 0;
>
> Ah, another instance. Comment please why
>
>> +
>> + if (!test_bit(PG_arch_1, &page->flags))
>> + return 0;
>
> "Can you describe the meaning of this bit with three words"? Or a couple
> more? :D
>
> "once upon a time, the page was secure and still might be" ?
> "the page is secure and therefore inaccessible" ?
/*
* PG_arch_1 is used in 3 places:
* 1. for kernel page tables during early boot
* 2. for storage keys of huge pages and KVM
* 3. As an indication that this page might be secure. This can
* overindicate, e.g. we set the bit before calling
* convert_to_secure.
* As secure pages are never huge, all 3 variants can co-exists.
*/
>
>> +
>> + rc = __uv_pin_shared(page_to_phys(page));
>> + if (!rc) {
>> + clear_bit(PG_arch_1, &page->flags);
>> + return 0;
>> + }
>> +
>> + rc = uv_convert_from_secure(page_to_phys(page));
>> + if (!rc) {
>> + clear_bit(PG_arch_1, &page->flags);
>> + return 0;
>> + }
>> +
>> + return rc;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_make_page_accessible);
>> +
>> #endif
>>
>
> More code comments would be highly appreciated!
>
done
^ permalink raw reply
* Re: [PATCH 4.9 087/116] drm/dp_mst: Remove VCPI while disabling topology mgr
From: Greg Kroah-Hartman @ 2020-02-14 21:11 UTC (permalink / raw)
To: Lyude Paul; +Cc: linux-kernel, stable, Wayne Lin, Sasha Levin
In-Reply-To: <6fa270d0d395d87c41b7d0a9ec87eadea5398eb6.camel@redhat.com>
On Fri, Feb 14, 2020 at 12:38:44PM -0500, Lyude Paul wrote:
> We should drop this and the versions for all of the other kernel versions.
> This patch later got reverted in a86675968e2300fb567994459da3dbc4cd1b322a in
> drm-misc/drm-misc-next, and then replaced with a proper fix in
> 8732fe46b20c951493bfc4dba0ad08efdf41de81
That commit is not in Linus's tree so I can't do much with it yet :)
And the revert isn't there either, ugh, and that commit ended up in the
last round of 5.5.y and 5.4.y and 4.19.y releases.
I'll drop this one for now though, thanks for letting me know.
greg k-h
^ permalink raw reply
* Re: [PATCH 4.19 091/195] padata: Remove broken queue flushing
From: Greg Kroah-Hartman @ 2020-02-14 20:49 UTC (permalink / raw)
To: Daniel Jordan
Cc: Yang Yingliang, linux-kernel, stable, Herbert Xu, Sasha Levin
In-Reply-To: <20200214201006.6qlfqillveotr47n@ca-dmjordan1.us.oracle.com>
On Fri, Feb 14, 2020 at 03:10:06PM -0500, Daniel Jordan wrote:
> On Fri, Feb 14, 2020 at 07:21:28AM -0800, Greg Kroah-Hartman wrote:
> > So this causes a problem in the 4.19-rc tree but not in Linus's tree?
> > Or am I confused? Should it be dropped from stable or is there some
> > other fix-of-a-fix that I need to apply here?
>
> This causes a problem in 4.19.103 and 4.19-rc but not Linus's tree.
>
> The fix-of-a-fix is posted recently here:
>
> https://lore.kernel.org/lkml/20200214182821.337706-1-daniel.m.jordan@oracle.com/
>
> For 4.14, 4.9, and 4.4, I'm posting a revised version of "Remove broken queue
> flushing" in each review thread. 4.14 is already up. Is this what I should be
> doing?
That is exactly correct, thanks for doing this, I'll drop what is
currently in these trees and then queue your new fix up for the next
round of releases, thanks!
greg k-h
^ permalink raw reply
* Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
From: Greg KH @ 2020-02-14 20:43 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jeff Kirsher, davem, Dave Ertman, netdev, linux-rdma, nhorman,
sassmann, parav, galpress, selvin.xavier, sriharsha.basavapatna,
benve, bharat, xavier.huwei, yishaih, leonro, mkalderon, aditr,
Kiran Patil, Andrew Bowers
In-Reply-To: <20200214203455.GX31668@ziepe.ca>
On Fri, Feb 14, 2020 at 04:34:55PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 14, 2020 at 09:02:40AM -0800, Greg KH wrote:
> > > +/**
> > > + * virtbus_dev_register - add a virtual bus device
> > > + * @vdev: virtual bus device to add
> > > + */
> > > +int virtbus_dev_register(struct virtbus_device *vdev)
> > > +{
> > > + int ret;
> > > +
> > > + if (!vdev->release) {
> > > + dev_err(&vdev->dev, "virtbus_device .release callback NULL\n");
> >
> > "virtbus_device MUST have a .release callback that does something!\n"
> >
> > > + return -EINVAL;
> > > + }
> > > +
> > > + device_initialize(&vdev->dev);
> > > +
> > > + vdev->dev.bus = &virtual_bus_type;
> > > + vdev->dev.release = virtbus_dev_release;
> > > + /* All device IDs are automatically allocated */
> > > + ret = ida_simple_get(&virtbus_dev_ida, 0, 0, GFP_KERNEL);
> > > + if (ret < 0) {
> > > + dev_err(&vdev->dev, "get IDA idx for virtbus device failed!\n");
> > > + put_device(&vdev->dev);
> >
> > If you allocate the number before device_initialize(), no need to call
> > put_device(). Just a minor thing, no big deal.
>
> If *_regster does put_device on error then it must always do
> put_device on any error, for instance the above return -EINVAL with
> no put_device leaks memory.
That's why I said to move the ida_simple_get() call to before
device_initialize() is called. Once device_initialize() is called, you
HAVE to call put_device().
Just trying to make code smaller :)
greg k-h
^ permalink raw reply
* Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
From: Greg KH @ 2020-02-14 20:45 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jeff Kirsher, davem, Dave Ertman, netdev, linux-rdma, nhorman,
sassmann, parav, galpress, selvin.xavier, sriharsha.basavapatna,
benve, bharat, xavier.huwei, yishaih, leonro, mkalderon, aditr,
Kiran Patil, Andrew Bowers
In-Reply-To: <20200214203455.GX31668@ziepe.ca>
On Fri, Feb 14, 2020 at 04:34:55PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 14, 2020 at 09:02:40AM -0800, Greg KH wrote:
> > > + put_device(&vdev->dev);
> > > + ida_simple_remove(&virtbus_dev_ida, vdev->id);
> >
> > You need to do this before put_device().
>
> Shouldn't it be in the release function? The ida index should not be
> re-used until the kref goes to zero..
Doesn't really matter, once you have unregistered it, you can reuse it.
But yes, putting it in release() is the safest thing to do.
> > > +struct virtbus_device {
> > > + struct device dev;
> > > + const char *name;
> > > + void (*release)(struct virtbus_device *);
> > > + int id;
> > > + const struct virtbus_dev_id *matched_element;
> > > +};
> >
> > Any reason you need to make "struct virtbus_device" a public structure
> > at all?
>
> The general point of this scheme is to do this in a public header:
>
> +struct iidc_virtbus_object {
> + struct virtbus_device vdev;
> + struct iidc_peer_dev *peer_dev;
> +};
>
> And then this when the driver binds:
Ah, yes, nevermind, I missed that.
greg k-h
^ permalink raw reply
* Re: [PATCH] x86/mce/amd: Fix kobject lifetime
From: Greg KH @ 2020-02-14 20:41 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Borislav Petkov, stable, X86 ML, Yazen Ghannam, LKML
In-Reply-To: <87a75kud8o.fsf@nanos.tec.linutronix.de>
On Fri, Feb 14, 2020 at 09:26:31PM +0100, Thomas Gleixner wrote:
> Borislav Petkov <bp@alien8.de> writes:
>
> > On Fri, Feb 14, 2020 at 07:17:27AM -0800, Greg KH wrote:
> >> Does not bother me at all, it's fine to see stuff come by that will end
> >> up in future trees, it's not noise at all. So no need to suppress
> >> stable@vger if you don't want to.
> >
> > Ok, but what about your formletter which you send to people explaining
> > this is not how you should send a patch to stable?
> >
> > Like this, for example:
> >
> > https://lkml.kernel.org/r/20200116100925.GA157179@kroah.com
>
> This once Cc'ed stable but lacked a Cc: stable tag in the changelog.
Exactly :)
^ permalink raw reply
* Re: [PATCH RFT] regulator: mp5416: Fix output discharge enable bit for LDOs
From: saravanan sekar @ 2020-02-14 21:16 UTC (permalink / raw)
To: Axel Lin, Mark Brown; +Cc: Liam Girdwood, linux-kernel
In-Reply-To: <20200212150223.20042-1-axel.lin@ingics.com>
On 12/02/20 4:02 pm, Axel Lin wrote:
> The .active_discharge_on/.active_discharge_mask settings does not match
> the datasheet, fix it.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> ---
> Hi Saravanan,
> I don't have the h/w to test, please help review and test this patch.
Thanks for pointing out, I have tested this patch and works as expected.
>
> Thanks,
> Axel
>
> drivers/regulator/mp5416.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/regulator/mp5416.c b/drivers/regulator/mp5416.c
> index 7954ad17249b..67ce1b52a1a1 100644
> --- a/drivers/regulator/mp5416.c
> +++ b/drivers/regulator/mp5416.c
> @@ -73,7 +73,7 @@
> .owner = THIS_MODULE, \
> }
>
> -#define MP5416LDO(_name, _id) \
> +#define MP5416LDO(_name, _id, _dval) \
> [MP5416_LDO ## _id] = { \
> .id = MP5416_LDO ## _id, \
> .name = _name, \
> @@ -87,9 +87,9 @@
> .vsel_mask = MP5416_MASK_VSET, \
> .enable_reg = MP5416_REG_LDO ##_id, \
> .enable_mask = MP5416_REGULATOR_EN, \
> - .active_discharge_on = BIT(_id), \
> + .active_discharge_on = _dval, \
> .active_discharge_reg = MP5416_REG_CTL2, \
> - .active_discharge_mask = BIT(_id), \
> + .active_discharge_mask = _dval, \
> .owner = THIS_MODULE, \
> }
>
> @@ -155,10 +155,10 @@ static struct regulator_desc mp5416_regulators_desc[MP5416_MAX_REGULATORS] = {
> MP5416BUCK("buck2", 2, mp5416_I_limits2, MP5416_REG_CTL1, BIT(1), 2),
> MP5416BUCK("buck3", 3, mp5416_I_limits1, MP5416_REG_CTL1, BIT(2), 1),
> MP5416BUCK("buck4", 4, mp5416_I_limits2, MP5416_REG_CTL2, BIT(5), 2),
> - MP5416LDO("ldo1", 1),
> - MP5416LDO("ldo2", 2),
> - MP5416LDO("ldo3", 3),
> - MP5416LDO("ldo4", 4),
> + MP5416LDO("ldo1", 1, BIT(4)),
> + MP5416LDO("ldo2", 2, BIT(3)),
> + MP5416LDO("ldo3", 3, BIT(2)),
> + MP5416LDO("ldo4", 4, BIT(1)),
> };
>
> /*
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Chia-I Wu @ 2020-02-14 21:15 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, vkuznets, wanpengli, jmattson, joro, Gurchetan Singh,
Gerd Hoffmann, ML dri-devel, Sean Christopherson
In-Reply-To: <b82cd76c-0690-c13b-cf2c-75d7911c5c61@redhat.com>
On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 13/02/20 23:18, Chia-I Wu wrote:
> >
> > The bug you mentioned was probably this one
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=104091
>
> Yes, indeed.
>
> > From what I can tell, the commit allowed the guests to create cached
> > mappings to MMIO regions and caused MCEs. That is different than what
> > I need, which is to allow guests to create uncached mappings to system
> > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > mappings. But it is true that this still allows the userspace & guest
> > kernel to create conflicting memory types.
>
> Right, the question is whether the MCEs were tied to MMIO regions
> specifically and if so why.
>
> An interesting remark is in the footnote of table 11-7 in the SDM.
> There, for the MTRR (EPT for us) memory type UC you can read:
>
> The UC attribute comes from the MTRRs and the processors are not
> required to snoop their caches since the data could never have
> been cached. This attribute is preferred for performance reasons.
>
> There are two possibilities:
>
> 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> That would make your change safe.
>
> 2) the footnote also applies when the UC attribute comes from the EPT
> page tables rather than the MTRRs. In that case, the host should use
> UC as the EPT page attribute if and only if it's consistent with the host
> MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> In that case, something like the patch below would be needed.
>
> It is not clear from the manual why the footnote would not apply to WC; that
> is, the manual doesn't say explicitly that the processor does not do snooping
> for accesses to WC memory. But I guess that must be the case, which is why I
> used MTRR_TYPE_WRCOMB in the patch below.
>
> Either way, we would have an explanation of why creating cached mapping to
> MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> (the guest would have set WB for that memory in its MTRRs, not UC).
>
> One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> regions would it be set?
It will be set for shmems that are mapped WC.
GPU/DRM drivers allocate shmems as DMA-able gpu buffers and allow the
userspace to map them cached or WC (I915_MMAP_WC or
AMDGPU_GEM_CREATE_CPU_GTT_USWC for example). When a shmem is mapped
WC and is made available to the guest, we would like the ability to
map the region WC in the guest.
> Thanks,
>
> Paolo
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc331fb06495..2be6f7effa1d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> }
>
> cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> -
> exit:
> + if (cache == MTRR_TYPE_UNCACHABLE && !is_mmio) {
> + /*
> + * We cannot set UC in the EPT page tables as it can cause
> + * machine check exceptions (??). Hopefully the guest is
> + * using PAT.
> + */
> + cache = MTRR_TYPE_WRCOMB;
> + }
> +
> return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
> }
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Chia-I Wu @ 2020-02-14 21:15 UTC (permalink / raw)
To: Paolo Bonzini
Cc: wanpengli, kvm, joro, ML dri-devel, Gurchetan Singh,
Sean Christopherson, Gerd Hoffmann, vkuznets, jmattson
In-Reply-To: <b82cd76c-0690-c13b-cf2c-75d7911c5c61@redhat.com>
On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 13/02/20 23:18, Chia-I Wu wrote:
> >
> > The bug you mentioned was probably this one
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=104091
>
> Yes, indeed.
>
> > From what I can tell, the commit allowed the guests to create cached
> > mappings to MMIO regions and caused MCEs. That is different than what
> > I need, which is to allow guests to create uncached mappings to system
> > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > mappings. But it is true that this still allows the userspace & guest
> > kernel to create conflicting memory types.
>
> Right, the question is whether the MCEs were tied to MMIO regions
> specifically and if so why.
>
> An interesting remark is in the footnote of table 11-7 in the SDM.
> There, for the MTRR (EPT for us) memory type UC you can read:
>
> The UC attribute comes from the MTRRs and the processors are not
> required to snoop their caches since the data could never have
> been cached. This attribute is preferred for performance reasons.
>
> There are two possibilities:
>
> 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> That would make your change safe.
>
> 2) the footnote also applies when the UC attribute comes from the EPT
> page tables rather than the MTRRs. In that case, the host should use
> UC as the EPT page attribute if and only if it's consistent with the host
> MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> In that case, something like the patch below would be needed.
>
> It is not clear from the manual why the footnote would not apply to WC; that
> is, the manual doesn't say explicitly that the processor does not do snooping
> for accesses to WC memory. But I guess that must be the case, which is why I
> used MTRR_TYPE_WRCOMB in the patch below.
>
> Either way, we would have an explanation of why creating cached mapping to
> MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> (the guest would have set WB for that memory in its MTRRs, not UC).
>
> One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> regions would it be set?
It will be set for shmems that are mapped WC.
GPU/DRM drivers allocate shmems as DMA-able gpu buffers and allow the
userspace to map them cached or WC (I915_MMAP_WC or
AMDGPU_GEM_CREATE_CPU_GTT_USWC for example). When a shmem is mapped
WC and is made available to the guest, we would like the ability to
map the region WC in the guest.
> Thanks,
>
> Paolo
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc331fb06495..2be6f7effa1d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> }
>
> cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> -
> exit:
> + if (cache == MTRR_TYPE_UNCACHABLE && !is_mmio) {
> + /*
> + * We cannot set UC in the EPT page tables as it can cause
> + * machine check exceptions (??). Hopefully the guest is
> + * using PAT.
> + */
> + cache = MTRR_TYPE_WRCOMB;
> + }
> +
> return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
> }
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Tejun Heo @ 2020-02-14 21:15 UTC (permalink / raw)
To: Kenny Ho
Cc: juan.zuniga-anaya, Kenny Ho, Kuehling, Felix, jsparks, nirmoy.das,
Maling list - DRI developers, lkaplan, Greathouse, Joseph,
amd-gfx mailing list, Jason Ekstrand, Johannes Weiner,
Alex Deucher, cgroups, Christian König, damon.mcdougall
In-Reply-To: <CAOWid-dA2Ad-FTZDDLOs4pperYbsru9cknSuXo_2ajpPbQH0Xg@mail.gmail.com>
On Fri, Feb 14, 2020 at 03:28:40PM -0500, Kenny Ho wrote:
> Can you elaborate, per your understanding, how the lgpu weight
> attribute differ from the io.weight you suggested? Is it merely a
Oh, it's the non-weight part which is problematic.
> formatting/naming issue or is it the implementation details that you
> find troubling? From my perspective, the weight attribute implements
> as you suggested back in RFCv4 (proportional control on top of a unit
> - either physical or time unit.)
>
> Perhaps more explicit questions would help me understand what you
> mean. If I remove the 'list' and 'count' attributes leaving just
> weight, is that satisfactory? Are you saying the idea of affinity or
At least from interface pov, yes, although I think it should be clear
what the weight controls.
> named-resource is banned from cgroup entirely (even though it exists
> in the form of cpuset already and users are interested in having such
> options [i.e. userspace OpenCL] when needed?)
>
> To be clear, I am not saying no proportional control. I am saying
> give the user the options, which is what has been implemented.
We can get there if we *really* have to but not from the get-go but
I'd rather avoid affinities if at all possible.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Tejun Heo @ 2020-02-14 21:15 UTC (permalink / raw)
To: Kenny Ho
Cc: juan.zuniga-anaya, Daniel Vetter, Kenny Ho, Kuehling, Felix,
jsparks, nirmoy.das, Maling list - DRI developers, lkaplan,
Greathouse, Joseph, amd-gfx mailing list, Jason Ekstrand,
Johannes Weiner, Alex Deucher, cgroups, Christian König,
damon.mcdougall
In-Reply-To: <CAOWid-dA2Ad-FTZDDLOs4pperYbsru9cknSuXo_2ajpPbQH0Xg@mail.gmail.com>
On Fri, Feb 14, 2020 at 03:28:40PM -0500, Kenny Ho wrote:
> Can you elaborate, per your understanding, how the lgpu weight
> attribute differ from the io.weight you suggested? Is it merely a
Oh, it's the non-weight part which is problematic.
> formatting/naming issue or is it the implementation details that you
> find troubling? From my perspective, the weight attribute implements
> as you suggested back in RFCv4 (proportional control on top of a unit
> - either physical or time unit.)
>
> Perhaps more explicit questions would help me understand what you
> mean. If I remove the 'list' and 'count' attributes leaving just
> weight, is that satisfactory? Are you saying the idea of affinity or
At least from interface pov, yes, although I think it should be clear
what the weight controls.
> named-resource is banned from cgroup entirely (even though it exists
> in the form of cpuset already and users are interested in having such
> options [i.e. userspace OpenCL] when needed?)
>
> To be clear, I am not saying no proportional control. I am saying
> give the user the options, which is what has been implemented.
We can get there if we *really* have to but not from the get-go but
I'd rather avoid affinities if at all possible.
Thanks.
--
tejun
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.