dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[RFC] CRIU support for ROCm
by Felix Kuehling 21 Jun '21

21 Jun '21

We have been working on a prototype supporting CRIU (Checkpoint/Restore In Userspace) for accelerated compute applications running on AMD GPUs using ROCm (Radeon Open Compute Platform). We're happy to finally share this work publicly to solicit feedback and advice. The end-goal is to get this work included upstream in Linux and CRIU. A short whitepaper describing our design and intention can be found on Github: https://github.com/RadeonOpenCompute/criu/tree/criu-dev/test/others/ext-kfd…. We have RFC patch series for the kernel (based on Alex Deucher's amd-staging-drm-next branch) and for CRIU including a new plugin and a few core CRIU changes. I will send those to the respective mailing lists separately in a minute. They can also be found on Github. CRIU+plugin: https://github.com/RadeonOpenCompute/criu/commits/criu-dev Kernel (KFD): https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/commits/fxkamd/criu… At this point this is very much a work in progress and not ready for upstream inclusion. There are still several missing features, known issues, and open questions that we would like to start addressing with your feedback. What's working and tested at this point: * Checkpoint and restore accelerated machine learning apps: PyTorch running Bert on systems with 1 or 2 GPUs (MI50 or MI100), 100% unmodified user mode stack * Checkpoint on one system, restore on a different system * Checkpoint on one GPU, restore on a different GPU Major Known issues: * The KFD ioctl API is not final: Needs a complete redesign to allow future extension without breaking the ABI * Very slow: Need to implement DMA to dump VRAM contents Missing or incomplete features: * Support for the new KFD SVM API * Check device topology during restore * Checkpoint and restore multiple processes * Support for applications using Mesa for video decode/encode * Testing with more different GPUs and workloads Big Open questions: * What's the preferred way to publish our CRIU plugin? In-tree or out-of-tree? * What's the preferred way to distribute our CRIU plugin? Source? Binary .so? Whole CRIU? Just in-box support? * If our plugin can be upstreamed in the CRIU tree, what would be the right directory? Best regards, Felix

3 8

[PATCH 0/4] delete useless function return values & remove meaningless if(r) check code
by Bernard Zhao 21 Jun '21

21 Jun '21

Function radeon_fence_driver_init always returns success, the function type maybe coule be changed to void. This patch series will first delete the check of the return value of the function call radeon_fence_driver_init, then, optimise the function declaration and function to void type. Signed-off-by: Bernard Zhao <bernard(a)vivo.com> Bernard Zhao (4): drm/radeon: remove meaningless if(r) check code drm/radeon: remove meaningless if(r) check code drm/radeon: remove meaningless if(r) check code drm/radeon: delete useless return values drivers/gpu/drm/radeon/cik.c | 4 +--- drivers/gpu/drm/radeon/evergreen.c | 4 +--- drivers/gpu/drm/radeon/ni.c | 4 +--- drivers/gpu/drm/radeon/r100.c | 4 +--- drivers/gpu/drm/radeon/r300.c | 4 +--- drivers/gpu/drm/radeon/r420.c | 5 +---- drivers/gpu/drm/radeon/r520.c | 4 +--- drivers/gpu/drm/radeon/r600.c | 4 +--- drivers/gpu/drm/radeon/radeon.h | 2 +- drivers/gpu/drm/radeon/radeon_fence.c | 5 +---- drivers/gpu/drm/radeon/rs400.c | 4 +--- drivers/gpu/drm/radeon/rs600.c | 4 +--- drivers/gpu/drm/radeon/rs690.c | 4 +--- drivers/gpu/drm/radeon/rv515.c | 4 +--- drivers/gpu/drm/radeon/rv770.c | 4 +--- drivers/gpu/drm/radeon/si.c | 4 +--- 16 files changed, 16 insertions(+), 48 deletions(-) -- 2.31.0

3 6

[PATCH AUTOSEL 5.4 07/15] drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device
by Sasha Levin 20 Jun '21

20 Jun '21

From: Saravana Kannan <saravanak(a)google.com> [ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ] On sunxi boards that use HDMI output, HDMI device probe keeps being avoided indefinitely with these repeated messages in dmesg: platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready There's a fwnode_link being created with fw_devlink=on between hdmi and hdmi-phy nodes, because both nodes have 'compatible' property set. Fw_devlink code assumes that nodes that have compatible property set will also have a device associated with them by some driver eventually. This is not the case with the current sun8i-hdmi driver. This commit makes sun8i-hdmi-phy into a proper platform device and fixes the display pipeline probe on sunxi boards that use HDMI. More context: https://lkml.org/lkml/2021/5/16/203 Signed-off-by: Saravana Kannan <saravanak(a)google.com> Signed-off-by: Ondrej Jirman <megous(a)megous.com> Tested-by: Andre Przywara <andre.przywara(a)arm.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210607085836.2827429-1-mego… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 31 ++++++++++++++++--- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 5 ++-- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 41 ++++++++++++++++++++++---- 3 files changed, 66 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index 8f721be26477..cfb63cae4b12 100644 --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c @@ -211,7 +211,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master, goto err_disable_clk_tmds; } - ret = sun8i_hdmi_phy_probe(hdmi, phy_node); + ret = sun8i_hdmi_phy_get(hdmi, phy_node); of_node_put(phy_node); if (ret) { dev_err(dev, "Couldn't get the HDMI PHY\n"); @@ -244,7 +244,6 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master, cleanup_encoder: drm_encoder_cleanup(encoder); - sun8i_hdmi_phy_remove(hdmi); err_disable_clk_tmds: clk_disable_unprepare(hdmi->clk_tmds); err_assert_ctrl_reset: @@ -265,7 +264,6 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, struct device *master, struct sun8i_dw_hdmi *hdmi = dev_get_drvdata(dev); dw_hdmi_unbind(hdmi->hdmi); - sun8i_hdmi_phy_remove(hdmi); clk_disable_unprepare(hdmi->clk_tmds); reset_control_assert(hdmi->rst_ctrl); gpiod_set_value(hdmi->ddc_en, 0); @@ -322,7 +320,32 @@ static struct platform_driver sun8i_dw_hdmi_pltfm_driver = { .of_match_table = sun8i_dw_hdmi_dt_ids, }, }; -module_platform_driver(sun8i_dw_hdmi_pltfm_driver); + +static int __init sun8i_dw_hdmi_init(void) +{ + int ret; + + ret = platform_driver_register(&sun8i_dw_hdmi_pltfm_driver); + if (ret) + return ret; + + ret = platform_driver_register(&sun8i_hdmi_phy_driver); + if (ret) { + platform_driver_unregister(&sun8i_dw_hdmi_pltfm_driver); + return ret; + } + + return ret; +} + +static void __exit sun8i_dw_hdmi_exit(void) +{ + platform_driver_unregister(&sun8i_dw_hdmi_pltfm_driver); + platform_driver_unregister(&sun8i_hdmi_phy_driver); +} + +module_init(sun8i_dw_hdmi_init); +module_exit(sun8i_dw_hdmi_exit); MODULE_AUTHOR("Jernej Skrabec <jernej.skrabec(a)siol.net>"); MODULE_DESCRIPTION("Allwinner DW HDMI bridge"); diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index d707c9171824..5a299a6f5aa5 100644 --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h @@ -194,14 +194,15 @@ struct sun8i_dw_hdmi { struct gpio_desc *ddc_en; }; +extern struct platform_driver sun8i_hdmi_phy_driver; + static inline struct sun8i_dw_hdmi * encoder_to_sun8i_dw_hdmi(struct drm_encoder *encoder) { return container_of(encoder, struct sun8i_dw_hdmi, encoder); } -int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node); -void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi); +int sun8i_hdmi_phy_get(struct sun8i_dw_hdmi *hdmi, struct device_node *node); void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy); void sun8i_hdmi_phy_set_ops(struct sun8i_hdmi_phy *phy, diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index a4012ec13d4b..c6289328c874 100644 --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c @@ -5,6 +5,7 @@ #include <linux/delay.h> #include <linux/of_address.h> +#include <linux/of_platform.h> #include "sun8i_dw_hdmi.h" @@ -596,10 +597,30 @@ static const struct of_device_id sun8i_hdmi_phy_of_table[] = { { /* sentinel */ } }; -int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node) +int sun8i_hdmi_phy_get(struct sun8i_dw_hdmi *hdmi, struct device_node *node) +{ + struct platform_device *pdev = of_find_device_by_node(node); + struct sun8i_hdmi_phy *phy; + + if (!pdev) + return -EPROBE_DEFER; + + phy = platform_get_drvdata(pdev); + if (!phy) + return -EPROBE_DEFER; + + hdmi->phy = phy; + + put_device(&pdev->dev); + + return 0; +} + +static int sun8i_hdmi_phy_probe(struct platform_device *pdev) { const struct of_device_id *match; - struct device *dev = hdmi->dev; + struct device *dev = &pdev->dev; + struct device_node *node = dev->of_node; struct sun8i_hdmi_phy *phy; struct resource res; void __iomem *regs; @@ -703,7 +724,7 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node) clk_prepare_enable(phy->clk_phy); } - hdmi->phy = phy; + platform_set_drvdata(pdev, phy); return 0; @@ -727,9 +748,9 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node) return ret; } -void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi) +static int sun8i_hdmi_phy_remove(struct platform_device *pdev) { - struct sun8i_hdmi_phy *phy = hdmi->phy; + struct sun8i_hdmi_phy *phy = platform_get_drvdata(pdev); clk_disable_unprepare(phy->clk_mod); clk_disable_unprepare(phy->clk_bus); @@ -743,4 +764,14 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi) clk_put(phy->clk_pll1); clk_put(phy->clk_mod); clk_put(phy->clk_bus); + return 0; } + +struct platform_driver sun8i_hdmi_phy_driver = { + .probe = sun8i_hdmi_phy_probe, + .remove = sun8i_hdmi_phy_remove, + .driver = { + .name = "sun8i-hdmi-phy", + .of_match_table = sun8i_hdmi_phy_of_table, + }, +}; -- 2.30.2

2 2

[drm-intel:drm-intel-gt-next 2/8] drivers/gpu/drm/i915/selftests/i915_buddy.c:777:5: error: no previous prototype for 'i915_buddy_mock_selftests'
by kernel test robot 19 Jun '21

19 Jun '21

tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next head: 13c2ceb6addb6b14468e09b75832c98909eed8e7 commit: 88be9a0a06b73ecd85a688a7c174c941e9692e92 [2/8] drm/i915/ttm: add ttm_buddy_man config: x86_64-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): git remote add drm-intel git://anongit.freedesktop.org/drm-intel git fetch --no-tags drm-intel drm-intel-gt-next git checkout 88be9a0a06b73ecd85a688a7c174c941e9692e92 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> Note: the drm-intel/drm-intel-gt-next HEAD bfde26df7af4e8ea894008dfda1d7d54a834dcd4 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/i915_buddy.c:411: >> drivers/gpu/drm/i915/selftests/i915_buddy.c:777:5: error: no previous prototype for 'i915_buddy_mock_selftests' [-Werror=missing-prototypes] 777 | int i915_buddy_mock_selftests(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors vim +/i915_buddy_mock_selftests +777 drivers/gpu/drm/i915/selftests/i915_buddy.c 776 > 777 int i915_buddy_mock_selftests(void) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

[PATCH] drm/atmel-hlcdc: Allow async page flips
by Dan Sneddon 19 Jun '21

19 Jun '21

The driver is capable of doing async page flips so we need to tell the core to allow them. Signed-off-by: Dan Sneddon <dan.sneddon(a)microchip.com> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index 871293d1aeeb..f6c3d8809fd8 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c @@ -686,6 +686,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev) dev->mode_config.max_width = dc->desc->max_width; dev->mode_config.max_height = dc->desc->max_height; dev->mode_config.funcs = &mode_config_funcs; + dev->mode_config.async_page_flip = true; return 0; } -- 2.17.1

4 3

[PATCH] drm/gma500/oaktrail_lvds: replace continue with break
by Colin King 19 Jun '21

19 Jun '21

From: Colin Ian King <colin.king(a)canonical.com> Currently a loop scans through the connector list checking for connectors that do not match a specific criteria. The use of the continue statement is a little unintuitive and can confuse static analysis checking. Invert the criteria matching logic and use a break to terminate the loop once the first suitable connector has been found. Thanks to Patrik Jakobsson for explaining the original intent of the code and suggesting this change. Addresses-Coverity: ("Continue has no effect") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/gma500/oaktrail_lvds.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c b/drivers/gpu/drm/gma500/oaktrail_lvds.c index 432bdcc57ac9..8541dcf237eb 100644 --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c @@ -113,8 +113,8 @@ static void oaktrail_lvds_mode_set(struct drm_encoder *encoder, /* Find the connector we're trying to set up */ list_for_each_entry(connector, &mode_config->connector_list, head) { - if (!connector->encoder || connector->encoder->crtc != crtc) - continue; + if (connector->encoder && connector->encoder->crtc == crtc) + break; } if (!connector) { -- 2.31.1

3 3

[RESEND PATCH] drm/panel: ld9040: reference spi_device_id table
by Krzysztof Kozlowski 19 Jun '21

19 Jun '21

Reference the spi_device_id table to silence W=1 warning: drivers/gpu/drm/panel/panel-samsung-ld9040.c:377:35: warning: ‘ld9040_ids’ defined but not used [-Wunused-const-variable=] This also would be needed for matching the driver if booted without CONFIG_OF (although it's not necessarily real case). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> --- drivers/gpu/drm/panel/panel-samsung-ld9040.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-samsung-ld9040.c b/drivers/gpu/drm/panel/panel-samsung-ld9040.c index f484147fc3a6..c4b388850a13 100644 --- a/drivers/gpu/drm/panel/panel-samsung-ld9040.c +++ b/drivers/gpu/drm/panel/panel-samsung-ld9040.c @@ -383,6 +383,7 @@ MODULE_DEVICE_TABLE(spi, ld9040_ids); static struct spi_driver ld9040_driver = { .probe = ld9040_probe, .remove = ld9040_remove, + .id_table = ld9040_ids, .driver = { .name = "panel-samsung-ld9040", .of_match_table = ld9040_of_match, -- 2.27.0

2 1

[PATCH] drm:atmel: Enable the crtc vblank prior to crtc usage.
by Dan Sneddon 19 Jun '21

19 Jun '21

'commit eec44d44a3d2 ("drm/atmel: Use drm_atomic_helper_commit")' removed the home-grown handling of atomic commits and exposed an issue in the crtc atomic commit handling where vblank is expected to be enabled but hasn't yet, causing kernel warnings during boot. This patch cleans up the crtc vblank handling thus removing the warning on boot. Fixes: eec44d44a3d2 ("drm/atmel: Use drm_atomic_helper_commit") Signed-off-by: Dan Sneddon <dan.sneddon(a)microchip.com> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c index 05ad75d155e8..cfe4fc69277e 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c @@ -232,7 +232,6 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc *c, pm_runtime_put_sync(dev->dev); - drm_crtc_vblank_on(c); } #define ATMEL_HLCDC_RGB444_OUTPUT BIT(0) @@ -343,8 +342,17 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc *c, static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c, struct drm_atomic_state *state) +{ + drm_crtc_vblank_on(c); +} + +static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc *c, + struct drm_atomic_state *state) { struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c); + unsigned long flags; + + spin_lock_irqsave(&c->dev->event_lock, flags); if (c->state->event) { c->state->event->pipe = drm_crtc_index(c); @@ -354,12 +362,7 @@ static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c, crtc->event = c->state->event; c->state->event = NULL; } -} - -static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc *crtc, - struct drm_atomic_state *state) -{ - /* TODO: write common plane control register if available */ + spin_unlock_irqrestore(&c->dev->event_lock, flags); } static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = { -- 2.17.1

3 2

[PATCH v13 00/12] Restricted DMA
by Claire Chang 19 Jun '21

19 Jun '21

This series implements mitigations for lack of DMA access control on systems without an IOMMU, which could result in the DMA accessing the system memory at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is not behind an IOMMU. As PCI-e, by design, gives the device full access to system memory, a vulnerability in the Wi-Fi firmware could easily escalate to a full system exploit (remote wifi exploits: [1a], [1b] that shows a full chain of exploits; [2], [3]). To mitigate the security concerns, we introduce restricted DMA. Restricted DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a specially allocated region and does memory allocation from the same region. The feature on its own provides a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to restrict the DMA to a predefined memory region (this is usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcom… [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcom… [2] https://blade.tencent.com/en/advisories/qualpwn/ [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-hig… [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/media… v13: - Fix xen-swiotlb issues - memset in patch 01/12 - is_swiotlb_force_bounce in patch 06/12 - Fix the dts example typo in reserved-memory.txt - Add Stefano and Will's Tested-by tag from v12 v12: Split is_dev_swiotlb_force into is_swiotlb_force_bounce (patch 06/12) and is_swiotlb_for_alloc (patch 09/12) https://lore.kernel.org/patchwork/cover/1447254/ v11: - Rebase against swiotlb devel/for-linus-5.14 - s/mempry/memory/g - exchange the order of patch 09/12 and 10/12 https://lore.kernel.org/patchwork/cover/1447216/ v10: Address the comments in v9 to - fix the dev->dma_io_tlb_mem assignment - propagate swiotlb_force setting into io_tlb_default_mem->force - move set_memory_decrypted out of swiotlb_init_io_tlb_mem - move debugfs_dir declaration into the main CONFIG_DEBUG_FS block - add swiotlb_ prefix to find_slots and release_slots - merge the 3 alloc/free related patches - move the CONFIG_DMA_RESTRICTED_POOL later https://lore.kernel.org/patchwork/cover/1446882/ v9: Address the comments in v7 to - set swiotlb active pool to dev->dma_io_tlb_mem - get rid of get_io_tlb_mem - dig out the device struct for is_swiotlb_active - move debugfs_create_dir out of swiotlb_create_debugfs - do set_memory_decrypted conditionally in swiotlb_init_io_tlb_mem - use IS_ENABLED in kernel/dma/direct.c - fix redefinition of 'of_dma_set_restricted_buffer' https://lore.kernel.org/patchwork/cover/1445081/ v8: - Fix reserved-memory.txt and add the reg property in example. - Fix sizeof for of_property_count_elems_of_size in drivers/of/address.c#of_dma_set_restricted_buffer. - Apply Will's suggestion to try the OF node having DMA configuration in drivers/of/address.c#of_dma_set_restricted_buffer. - Fix typo in the comment of drivers/of/address.c#of_dma_set_restricted_buffer. - Add error message for PageHighMem in kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to rmem_swiotlb_setup. - Fix the message string in rmem_swiotlb_setup. https://lore.kernel.org/patchwork/cover/1437112/ v7: Fix debugfs, PageHighMem and comment style in rmem_swiotlb_device_init https://lore.kernel.org/patchwork/cover/1431031/ v6: Address the comments in v5 https://lore.kernel.org/patchwork/cover/1423201/ v5: Rebase on latest linux-next https://lore.kernel.org/patchwork/cover/1416899/ v4: - Fix spinlock bad magic - Use rmem->name for debugfs entry - Address the comments in v3 https://lore.kernel.org/patchwork/cover/1378113/ v3: Using only one reserved memory region for both streaming DMA and memory allocation. https://lore.kernel.org/patchwork/cover/1360992/ v2: Building on top of swiotlb. https://lore.kernel.org/patchwork/cover/1280705/ v1: Using dma_map_ops. https://lore.kernel.org/patchwork/cover/1271660/ Claire Chang (12): swiotlb: Refactor swiotlb init functions swiotlb: Refactor swiotlb_create_debugfs swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used swiotlb: Update is_swiotlb_buffer to add a struct device argument swiotlb: Update is_swiotlb_active to add a struct device argument swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing swiotlb: Move alloc_size to swiotlb_find_slots swiotlb: Refactor swiotlb_tbl_unmap_single swiotlb: Add restricted DMA alloc/free support swiotlb: Add restricted DMA pool initialization dt-bindings: of: Add restricted DMA pool of: Add plumbing for restricted DMA pool .../reserved-memory/reserved-memory.txt | 36 ++- drivers/base/core.c | 4 + drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/iommu/dma-iommu.c | 12 +- drivers/of/address.c | 33 +++ drivers/of/device.c | 3 + drivers/of/of_private.h | 6 + drivers/pci/xen-pcifront.c | 2 +- drivers/xen/swiotlb-xen.c | 4 +- include/linux/device.h | 4 + include/linux/swiotlb.h | 51 +++- kernel/dma/Kconfig | 14 + kernel/dma/direct.c | 59 +++-- kernel/dma/direct.h | 8 +- kernel/dma/swiotlb.c | 250 +++++++++++++----- 16 files changed, 387 insertions(+), 103 deletions(-) -- 2.32.0.288.g62a8d224e6-goog

3 22

[PATCH v2 0/2] drm: Address potential UAF bugs with drm_master ptrs
by Desmond Cheong Zhi Xi 18 Jun '21

18 Jun '21

This patch series addresses potential use-after-free errors when dereferencing pointers to struct drm_master. These were identified after one such bug was caught by Syzbot in drm_getunique(): https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f8… The series is broken up into two patches: 1. Implement a locked version of drm_is_current_master() function that's used within drm_auth.c 2. Identify areas in drm_lease.c where pointers to struct drm_master are dereferenced, and ensure that the master pointers are protected by a mutex Change in v2: - Patch 2: Move the lock and assignment before the DRM_DEBUG_LEASE in drm_mode_get_lease_ioctl, as suggested by Emil Velikov Desmond Cheong Zhi Xi (2): drm: Add a locked version of drm_is_current_master drm: Protect drm_master pointers in drm_lease.c drivers/gpu/drm/drm_auth.c | 23 ++++++++++++--- drivers/gpu/drm/drm_lease.c | 58 +++++++++++++++++++++++++++---------- 2 files changed, 62 insertions(+), 19 deletions(-) -- 2.25.1

2 9

← Newer
1
...
36
37
38
39
40
41
42
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021