- 04 Jul, 2022 1 commit
-
-
Thomas Zimmermann authored
Always run fbdev removal first to remove simpledrm via sysfb_disable(). This clears the internal state. The later call to drm_aperture_detach_drivers() then does nothing. Otherwise, with drm_aperture_detach_drivers() running first, the call to sysfb_disable() uses inconsistent state. Example backtrace show below: [ 11.663422] ================================================================== [ 11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0 [ 11.663435] Read of size 8 at addr ffff888108185050 by task systemd-udevd/311 [ 11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: G E 5 .19.0-rc2-1-default+ #1689 [ 11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011 [ 11.663447] Call Trace: [ 11.663449] <TASK> [ 11.663451] ? device_del+0x79/0x5f0 [ 11.663456] dump_stack_lvl+0x5b/0x73 [ 11.663462] print_address_description.constprop.0+0x1f/0x1b0 [ 11.663468] ? device_del+0x79/0x5f0 [ 11.663471] ? device_del+0x79/0x5f0 [ 11.663475] print_report.cold+0x3c/0x21c [ 11.663481] ? lock_acquired+0x87/0x1e0 [ 11.663484] ? lock_acquired+0x87/0x1e0 [ 11.663489] ? device_del+0x79/0x5f0 [ 11.663492] kasan_report+0xbf/0xf0 [ 11.663498] ? device_del+0x79/0x5f0 [ 11.663503] device_del+0x79/0x5f0 [ 11.663509] ? device_remove_attrs+0x170/0x170 [ 11.663514] ? lock_is_held_type+0xe8/0x140 [ 11.663523] platform_device_del.part.0+0x19/0xe0 [ 11.663530] platform_device_unregister+0x1c/0x30 [ 11.663535] sysfb_disable+0x2d/0x70 [ 11.663540] remove_conflicting_framebuffers+0x1c/0xf0 [ 11.663546] remove_conflicting_pci_framebuffers+0x130/0x1a0 [ 11.663554] drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0 [ 11.663561] ? mgag200_pci_remove+0x30/0x30 [mgag200] [ 11.663578] mgag200_pci_probe+0x2d/0x140 [mgag200] Reported-by:
Zack Rusin <zackr@vmware.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
- 01 Jul, 2022 1 commit
-
-
Hans de Goede authored
The Lenovo Yoga Tablet 2 830F / 830L use a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
- 29 Jun, 2022 3 commits
-
-
Javier Martinez Canillas authored
The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Javier Martinez Canillas authored
This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by:
-
Javier Martinez Canillas authored
This function just returned 0 on success or an errno code on error, but it could be useful for sysfb_init() callers to have a pointer to the device. Signed-off-by:
-
- 27 Jun, 2022 1 commit
-
-
Maxime Ripard authored
Commit 30f8c74c ("drm/vc4: Warn if some v3d code is run on BCM2711") introduced a check in vc4_perfmon_get() that dereferences a pointer before we checked whether that pointer is valid or not. Let's rework that function a bit to do things in the proper order. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 30f8c74c ("drm/vc4: Warn if some v3d code is run on BCM2711") Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
José Expósito <jose.exposito89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220622080243.22119-1-maxime@cerno.tech
-
- 22 Jun, 2022 4 commits
-
-
Saud Farooqui authored
Added return statement in sun4i_layer_format_mod_supported() in case frontend is not present. Signed-off-by:
Saud Farooqui <farooqui_saud@hotmail.com> Signed-off-by:
-
Dan Carpenter authored
The vc4_check_tex_size() function is supposed to return false on error but this error path accidentally returns -ENODEV (which means true). Fixes: 30f8c74c ("drm/vc4: Warn if some v3d code is run on BCM2711") Signed-off-by:
-
Jernej Skrabec authored
Kernel occasionally complains that there is mismatch in segment size when trying to render HW decoded videos and rendering them directly with sun4i DRM driver. Following message can be observed on H6 SoC: [ 184.298308] ------------[ cut here ]------------ [ 184.298326] DMA-API: sun4i-drm display-engine: mapping sg segment longer than device claims to support [len=6144000] [max=65536] [ 184.298364] WARNING: CPU: 1 PID: 382 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2b0/0x350 [ 184.322997] CPU: 1 PID: 382 Comm: ffmpeg Not tainted 5.19.0-rc1+ #1331 [ 184.329533] Hardware name: Tanix TX6 (DT) [ 184.333544] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 184.340512] pc : debug_dma_map_sg+0x2b0/0x350 [ 184.344882] lr : debug_dma_map_sg+0x2b0/0x350 [ 184.349250] sp : ffff800009f33a50 [ 184.352567] x29: ffff800009f33a50 x28: 0000000000010000 x27: ffff000001b86c00 [ 184.359725] x26: ffffffffffffffff x25: ffff000005d8cc80 x24: 0000000000000000 [ 184.366879] x23: ffff80000939ab18 x22: 0000000000000001 x21: 0000000000000001 [ 184.374031] x20: 0000000000000000 x19: ffff0000018a7410 x18: ffffffffffffffff [ 184.381186] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff [ 184.388338] x14: 0000000000000001 x13: ffff800009534e86 x12: 6f70707573206f74 [ 184.395493] x11: 20736d69616c6320 x10: 000000000000000a x9 : 0000000000010000 [ 184.402647] x8 : ffff8000093b6d40 x7 : ffff800009f33850 x6 : 000000000000000c [ 184.409800] x5 : ffff0000bf997940 x4 : 0000000000000000 x3 : 0000000000000027 [ 184.416953] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003960e80 [ 184.424106] Call trace: [ 184.426556] debug_dma_map_sg+0x2b0/0x350 [ 184.430580] __dma_map_sg_attrs+0xa0/0x110 [ 184.434687] dma_map_sgtable+0x28/0x4c [ 184.438447] vb2_dc_dmabuf_ops_map+0x60/0xcc [ 184.442729] __map_dma_buf+0x2c/0xd4 [ 184.446321] dma_buf_map_attachment+0xa0/0x130 [ 184.450777] drm_gem_prime_import_dev+0x7c/0x18c [ 184.455410] drm_gem_prime_fd_to_handle+0x1b8/0x214 [ 184.460300] drm_prime_fd_to_handle_ioctl+0x2c/0x40 [ 184.465190] drm_ioctl_kernel+0xc4/0x174 [ 184.469123] drm_ioctl+0x204/0x420 [ 184.472534] __arm64_sys_ioctl+0xac/0xf0 [ 184.476474] invoke_syscall+0x48/0x114 [ 184.480240] el0_svc_common.constprop.0+0x44/0xec [ 184.484956] do_el0_svc+0x2c/0xc0 [ 184.488283] el0_svc+0x2c/0x84 [ 184.491354] el0t_64_sync_handler+0x11c/0x150 [ 184.495723] el0t_64_sync+0x18c/0x190 [ 184.499397] ---[ end trace 0000000000000000 ]--- Fix that by setting DMA mask and segment size. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Saud Farooqui authored
Multiplying ints and saving it in unsigned long long could lead to integer overflow before being type casted to unsigned long long. Addresses-Coverity: 1505113: Unintentional integer overflow. Signed-off-by:
-
- 19 Jun, 2022 1 commit
-
-
Maya Matuszczyk authored
The device is identified by "NEXT" in board name, however there are different versions of it, "Next Advance" and "Next Pro", that have different DMI board names. Due to a production error a batch or two have their board names prefixed by "AYANEO", this makes it 6 different DMI board names. To save some space in final kernel image DMI_MATCH is used instead of DMI_EXACT_MATCH. Signed-off-by:
Maya Matuszczyk <maccraft123mc@gmail.com> Reviewed-by:
-
- 16 Jun, 2022 16 commits
-
-
Maxime Ripard authored
The BCM2711 has a separate driver for the v3d, and thus we can't call into any of the driver entrypoints that rely on the v3d being there. Let's add a bunch of checks and complain loudly if that ever happen. Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Maxime Ripard authored
When doing an asynchronous page flip (PAGE_FLIP ioctl with the DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the possible GPU buffer being rendered through a call to vc4_queue_seqno_cb(). On the BCM2835-37, the GPU driver is part of the vc4 driver and that function is defined in vc4_gem.c to wait for the buffer to be rendered, and once it's done, call a callback. However, on the BCM2711 used on the RaspberryPi4, the GPU driver is separate (v3d) and that function won't do anything. This was working because we were going into a path, due to uninitialized variables, that was always scheduling the callback. However, we were never actually waiting for the buffer to be rendered which was resulting in frames being displayed out of order. The generic API to signal those kind of completion in the kernel are the DMA fences, and fortunately the v3d drivers supports them and signal when its job is done. That API also provides an equivalent function that allows to have a callback being executed when the fence is signalled as done. Let's change our driver a bit to rely on the previous function for the older SoCs, and on DMA fences for the BCM2711. Signed-off-by:
-
Maxime Ripard authored
The BCM2711 doesn't have a v3d GPU so we don't want to call into its BO management code. Let's create an asynchronous page-flip handler for the BCM2711 that just calls into the common code. Reviewed-by:
-
Maxime Ripard authored
The function vc4_async_page_flip() handles asynchronous page-flips in the vc4 driver. However, it mixes some generic code with code that should only be run on older generations that have the GPU handled by the vc4 driver. Let's split the generic part out of vc4_async_page_flip() and into a common function that we be reusable by an handler made for the BCM2711. Reviewed-by:
-
Maxime Ripard authored
We'll soon introduce another completion callback source that won't need to use the BO reference counting, so let's move it around to create a function we will be able to share between both callbacks. Reviewed-by:
-
Maxime Ripard authored
We'll need to extend the vc4_async_flip_state structure to rely on another callback implementation, so let's move the current one into a union. Reviewed-by:
-
Maxime Ripard authored
On the BCM2711, we currently call the vc4_bo_cache_init() and vc4_gem_init() functions. These functions initialize the BO and GEM backends. However, this code was initially created to accomodate the requirements of the GPU on the older SoCs, while the BCM2711 has a separate driver for it. So let's just skip these calls when we're on a newer hardware. Reviewed-by:
-
Maxime Ripard authored
On the BCM2711, our current definition of drm_plane_helper_funcs uses the custom vc4_prepare_fb() and vc4_cleanup_fb(). Those functions rely on the buffer allocation path that was relying on the GPU, and is no longer relevant. Let's create another drm_plane_helper_funcs structure that we will register on the BCM2711. Reviewed-by:
-
Maxime Ripard authored
On the BCM2711, our current definition of drm_mode_config_funcs uses the custom vc4_fb_create(). However, that function relies on the buffer allocation path that was relying on the GPU, and is no longer relevant. Let's create another drm_mode_config_funcs structure that we will register on the BCM2711. Reviewed-by:
-
Maxime Ripard authored
Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display components of the SoC. It was thus a part of the vc4 driver. However, with the BCM2711, it got split out and thus the v3d driver was created. The vc4 driver now only handles the display part. We didn't properly split out the code when doing the BCM2711 support though, and most of the code around buffer allocations is still involved, even though it doesn't have the backing hardware anymore. Let's start the split out by creating a new drm_driver that only reports and uses what we support on the BCM2711. The ioctl were properly filtered already, but we were still exposing a .gem_create_object hook, as well as having an .open and .postclose hooks which are only relevant on older generations. Reviewed-by:
-
Maxime Ripard authored
The vc4_bo_dumb_create() both fixes up the allocation arguments to match the hardware constraints and actually performs the allocation. Since we're going to introduce a new function that uses a different allocator, let's split the arguments fixup to a separate function we will be able to reuse. Reviewed-by:
-
Maxime Ripard authored
We're going to add a new variant of the dumb BO allocation function, so let's rename vc4_dumb_create() to something a bit more specific. Reviewed-by:
-
Maxime Ripard authored
A new generation of controller has been introduced with the BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over time we've piled on a number of checks in most parts of the drivers. All these checks are performed several times, and are not always consistent. Let's create a single, global, variable to hold it and use it everywhere. Reviewed-by:
-
Maxime Ripard authored
The vc4 planes are setup in hardware by creating a hardware descriptor in a dedicated RAM. As part of the process to setup a plane in KMS, we thus need to allocate some part of that dedicated RAM to store our descriptor there. The async update path will just reuse the descriptor already allocated for that plane and will modify it directly in RAM to match whatever has been asked for. In order to do that, it will compare the descriptor for the old plane state and the new plane state, will make sure they fit in the same size, and check that only the position or buffer address have changed. Reviewed-by:
-
Samuel Holland authored
If the component driver fails to bind, or is unbound, the driver data for the top-level platform device points to a freed drm_device. If the system is then suspended, the driver passes this dangling pointer to drm_mode_config_helper_suspend(), which crashes. Fix this by only setting the driver data while the platform driver holds a reference to the drm_device. Fixes: 624b4b48 ("drm: sun4i: Add support for suspending the display driver") Signed-off-by:
-
Samuel Holland authored
commit 6de79dd3 ("drm/bridge: display-connector: add ddc-en gpio support") added a consumer for this GPIO in the HDMI connector device. This new consumer conflicts with the pre-existing GPIO consumer in the sun8i HDMI controller driver, which prevents the driver from probing: [ 4.983358] display-connector connector: GPIO lookup for consumer ddc-en [ 4.983364] display-connector connector: using device tree for GPIO lookup [ 4.983392] gpio-226 (ddc-en): gpiod_request: status -16 [ 4.983399] sun8i-dw-hdmi 6000000.hdmi: Couldn't get ddc-en gpio [ 4.983618] sun4i-drm display-engine: failed to bind 6000000.hdmi (ops sun8i_dw_hdmi_ops [sun8i_drm_hdmi]): -16 [ 4.984082] sun4i-drm display-engine: Couldn't bind all pipelines components [ 4.984171] sun4i-drm display-engine: adev bind failed: -16 [ 4.984179] sun8i-dw-hdmi: probe of 6000000.hdmi failed with error -16 Both drivers have the same behavior: they leave the GPIO active for the life of the device. Let's take advantage of the new implementation, and drop the now-obsolete code from the HDMI controller driver. Fixes: 6de79dd3 ("drm/bridge: display-connector: add ddc-en gpio support") Signed-off-by:
-
- 14 Jun, 2022 1 commit
-
-
Christian König authored
The resource must be on the LRU before ttm_lru_bulk_move_add() is called and we need to check if the BO is pinned or not before adding it. Additional to that we missed taking the LRU spinlock in ttm_bo_unpin(). Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Acked-by:
Luben Tuikov <luben.tuikov@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613080816.4965-1-christian.koenig@amd.com Fixes: fee2ede1 ("drm/ttm: rework bulk move handling v5")
-
- 10 Jun, 2022 1 commit
-
-
Christian König authored
Resources about to be destructed are not tied to BOs any more. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Fixes: 6a9b0289 ("drm/ttm: move the LRU into resource handling v4") Link: https://patchwork.freedesktop.org/patch/msgid/20220603104604.456991-1-christian.koenig@amd.com
-
- 09 Jun, 2022 2 commits
-
-
GONG, Ruiqi authored
Fix the `unused-but-set-variable` warning as how other iteration wrappers do. Link: https://lore.kernel.org/all/202206071049.pofHsRih-lkp@intel.com/Reported-by:
GONG, Ruiqi <gongruiqi1@huawei.com> Signed-off-by:
-
Thomas Zimmermann authored
Systems with AST graphics can have multiple output; typically VGA plus some other port. Record detected output chips in a bitmask and initialize each output on its own. Assume a VGA output by default and use SIL164 and DP501 if available. For ASTDP assume that it can run in parallel with VGA. Tested on AST2100. v3: * define a macro for each BIT(ast_tx_chip) (Patrik) v2: * make VGA/SIL164/DP501 mutually exclusive Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Fixes: a59b0264 ("drm/ast: Initialize encoder and connector for VGA in helper function") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220607092008.22123-2-tzimmermann@suse.de (cherry picked from commit 7f35680a) Signed-off-by:
-
- 08 Jun, 2022 1 commit
-
-
Maxime Ripard authored
Let's kick-off the start of the 5.19 fix cycle Signed-off-by:
-
- 06 Jun, 2022 5 commits
-
-
Brian Norris authored
It's possible to change which CRTC is in use for a given connector/encoder/bridge while we're in self-refresh without fully disabling the connector/encoder/bridge along the way. This can confuse the bridge encoder/bridge, because (a) it needs to track the SR state (trying to perform "active" operations while the panel is still in SR can be Bad(TM)); and (b) it tracks the SR state via the CRTC state (and after the switch, the previous SR state is lost). Thus, we need to either somehow carry the self-refresh state over to the new CRTC, or else force an encoder/bridge self-refresh transition during such a switch. I choose the latter, so we disable the encoder (and exit PSR) before attaching it to the new CRTC (where we can continue to assume a clean (non-self-refresh) state). This fixes PSR issues seen on Rockchip RK3399 systems with drivers/gpu/drm/bridge/analogix/analogix_dp_core.c. Change in v2: - Drop "->enable" condition; this could possibly be "->active" to reflect the intended hardware state, but it also is a little over-specific. We want to make a transition through "disabled" any time we're exiting PSR at the same time as a CRTC switch. (Thanks Liu Ying) Cc: Liu Ying <victor.liu@oss.nxp.com> Cc: <stable@vger.kernel.org> Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers") Signed-off-by:Brian Norris <briannorris@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.2.Ic15a2ef69c540aee8732703103e2cff51fb9c399@changeid
-
Brian Norris authored
Most eDP panel functions only work correctly when the panel is not in self-refresh. In particular, analogix_dp_bridge_disable() tends to hit AUX channel errors if the panel is in self-refresh. Given the above, it appears that so far, this driver assumes that we are never in self-refresh when it comes time to fully disable the bridge. Prior to commit 846c7dfc ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2."), this tended to be true, because we would automatically disable the pipe when framebuffers were removed, and so we'd typically disable the bridge shortly after the last display activity. However, that is not guaranteed: an idle (self-refresh) display pipe may be disabled, e.g., when switching CRTCs. We need to exit PSR first. Stable notes: this is definitely a bugfix, and the bug has likely existed in some form for quite a while. It may predate the "PSR helpers" refactor, but the code looked very different before that, and it's probably not worth rewriting the fix. Cc: <stable@vger.kernel.org> Fixes: 6c836d96 ("drm/rockchip: Use the helpers for PSR") Signed-off-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull file descriptor fix from Al Viro: "Fix for breakage in #work.fd this window" * tag 'pull-work.fd-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix the breakage in close_fd_get_file() calling conventions change
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull mm hotfixes from Andrew Morton: "Fixups for various recently-added and longer-term issues and a few minor tweaks: - fixes for material merged during this merge window - cc:stable fixes for more longstanding issues - minor mailmap and MAINTAINERS updates" * tag 'mm-hotfixes-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/oom_kill.c: fix vm_oom_kill_table[] ifdeffery x86/kexec: fix memory leak of elf header buffer mm/memremap: fix missing call to untrack_pfn() in pagemap_range() mm: page_isolation: use compound_nr() correctly in isolate_single_pageblock() mm: hugetlb_vmemmap: fix CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON MAINTAINERS: add maintainer information for z3fold mailmap: update Josh Poimboeuf's email
-
- 05 Jun, 2022 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull delay-accounting update from Andrew Morton: "A single featurette for delay accounting. Delayed a bit because, unusually, it had dependencies on both the mm-stable and mm-nonmm-stable queues" * tag 'mm-nonmm-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: delayacct: track delays from write-protect copy
-
Linus Torvalds authored
The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953f ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee64 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by:
Yury Norov <yury.norov@gmail.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Al Viro authored
It used to grab an extra reference to struct file rather than just transferring to caller the one it had removed from descriptor table. New variant doesn't, and callers need to be adjusted. Reported-and-tested-by: syzbot+47dd250f527cb7bebf24@syzkaller.appspotmail.com Fixes: 6319194e ("Unify the primitives for file descriptor closing") Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
