- 06 Oct, 2021 15 commits
-
-
Yang Yingliang authored
When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 6e9fc177 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-2-yangyingliang@huawei.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Yang Yingliang authored
When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 12885ecb ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-1-yangyingliang@huawei.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Jeremy Cline authored
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm_bo_init() invokes the provided destructor which should de-initialize and free the memory. Thus, when nouveau_bo_init() returns an error the gem object has already been released and the memory freed by nouveau_bo_del_ttm(). Fixes: 019cbd4a ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201203000220.18238-1-jcline@redhat.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Randy Dunlap authored
Remove documentation associated with the removal of the DRM IRQ legacy midlayer. Eliminates these documentation warnings: ../drivers/gpu/drm/drm_irq.c:1: warning: 'irq helpers' not found ../drivers/gpu/drm/drm_irq.c:1: warning: no structured comments found Fixes: c1736b90 ("drm: IRQ midlayer is now legacy") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: dri-devel@lists.freedesktop.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211005025312.20913-1-rdunlap@infradead.orgSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Mark Brown authored
The gbefb driver not only registers a driver but also the device for that driver. This is all well and good when run on the IP32 machines that are supported by the driver but since the driver supports building with COMPILE_TEST we might also be building on other platforms which do not have this hardware and will crash instantiating the driver. Add an IS_ENABLED() check so we compile out the device registration if we don't have the Kconfig option for the machine enabled. Fixes: 552ccf6b ("video: fbdev: gbefb: add COMPILE_TEST support") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210921212102.30803-1-broonie@kernel.orgSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Arnd Bergmann authored
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This can however result in a build failure when cfb_fillrect() etc are then also in loadable modules: x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x1f8): undefined reference to `cfb_fillrect' x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x200): undefined reference to `cfb_copyarea' x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x208): undefined reference to `cfb_imageblit' To work around this, change FB_SIMPLE to be a 'tristate' symbol, which still allows both to be =m together, but not one of them to be =y if the other one is =m. If a distro kernel picks this configuration, it can be determined by local policy which of the two modules gets loaded. The 'of_chosen' export is needed as this is the first loadable module referencing it. Alternatively, the Kconfig dependency could be changed to 'depends on DRM_SIMPLEDRM=n', which would forbid the configuration with both drivers. Fixes: 11e8f5fd ("drm: Add simpledrm driver") Acked-by: Rob Herring <robh@kernel.org> # for drivers/of/ Link: https://lore.kernel.org/all/20210721151839.2484245-1-arnd@kernel.org/Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> # fbdev support Cc: Maxime Ripard <maxime@cerno.tech> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Borislav Petkov <bp@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Peter Collingbourne <pcc@google.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: <stable@vger.kernel.org> # v5.14+ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210928145243.1098064-1-arnd@kernel.orgSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Christophe Branchereau authored
The previous parameters caused an unbalanced yellow tint. Fixes: 7467389b ("drm/panel: Add ABT Y030XX067A 3.0" 320x480 panel") Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> [Paul: Add Fixes: tag, and fix case and punctuation in commit message] Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210914092716.2370039-1-cbranchereau@gmail.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Krzysztof Kozlowski authored
Correct indentation warning: ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but found 8 (indentation) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210819101020.26368-1-krzysztof.kozlowski@canonical.com (cherry picked from commit 333ba0d9) Link: https://lore.kernel.org/dri-devel/CAL_JsqKcTfgnXNYzGDSFhKS2udhw2Dvk04ODwTxUdDRQjKdT0Q@mail.gmail.com/Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ben Skeggs authored
Turns out caller isn't zero-initialised after-all. Fixes: 49b2dfc0 ("drm/nouveau/ga102-: support ttm buffer moves via copy engine") Reported-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921090735.247236-1-skeggsb@gmail.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Chris Morgan authored
After commit 928f9e26 ("clk: fractional-divider: Hide clk_fractional_divider_ops from wide audience") was merged it appears that the DSI panel on my Odroid Go Advance stopped working. Upon closer examination of the problem, it looks like it was the fixup in the rockchip_drm_vop.c file was causing the issue. The changes made to the clk driver appear to change some assumptions made in the fixup. After debugging the working 5.14 kernel and the no-longer working 5.15 kernel, it looks like this was broken all along but still worked, whereas after the fractional clock change it stopped working despite the issue (it went from sort-of broken to very broken). In the 5.14 kernel the dclk_vopb_frac was being requested to be set to 17000999 on my board. The clock driver was taking the value of the parent clock and attempting to divide the requested value from it (17000000/17000999 = 0), then subtracting 1 from it (making it -1), and running it through fls_long to get 64. It would then subtract the value of fd->mwidth from it to get 48, and then bit shift 17000999 to the left by 48, coming up with a very large number of 7649082492112076800. This resulted in a numerator of 65535 and a denominator of 1 from the clk driver. The driver seemingly would try again and get a correct 1:1 value later, and then move on. Output from my 5.14 kernel (with some printfs for good measure): [ 2.830066] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops) [ 2.839431] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 2.855980] Clock is dclk_vopb_frac [ 2.856004] Scale 64, Rate 7649082492112076800, Oldrate 17000999, Parent Rate 17000000, Best Numerator 65535, Best Denominator 1, fd->mwidth 16 [ 2.903529] Clock is dclk_vopb_frac [ 2.903556] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16 [ 2.903579] Clock is dclk_vopb_frac [ 2.903583] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16 Contrast this with 5.15 after the clk change where the rate of 17000999 was getting passed and resulted in numerators/denomiators of 17001/ 17000. Output from my 5.15 kernel (with some printfs added for good measure): [ 2.817571] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops) [ 2.826975] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 2.843430] Rate 17000999, Parent Rate 17000000, Best Numerator 17018, Best Denominator 17017 [ 2.891073] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 [ 2.891269] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 [ 2.891281] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 I have tested the change extensively on my Odroid Go Advance (Rockchip RK3326) and it appears to work well. However, this change will affect all Rockchip SoCs that use this driver so I believe further testing is warranted. Please note that without this change I can confirm at least all PX30s with DSI panels will stop working with the 5.15 kernel. Upon advice from Doug Anderson <dianders@chromium.org> it was decided that we would first check if the clock rate can be set exactly as requested, and only if it could not would we then add 999 to it and attempt the process again. This way we can preserve the behavior for clocks that still need it while resolving the specific issue for the PX30 and DSI panels (since it is using a fractional clock). Changes since v2: - Moved fixes to correct location. Changes since v1: - Made the addition of 999 conditional based on whether the clock subsystem can set the actual clock rate as requested. - Updated the notes in the fixup routine to reflect this new behavior. - Added reference to original commit, as this has technically been broken since then however only now is it an issue due to the clock changes. Fixes: 4e7cf74f ("clk: fractional-divider: Export approximation algorithm to the CCF users") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210916202907.18394-1-macroalpha82@gmail.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ben Skeggs authored
We don't currently have any kind of real acceleration on Ampere GPUs, but the TTM memcpy() fallback paths aren't really designed to handle copies between different devices, such as on Optimus systems, and result in a kernel OOPS. A few options were investigated to try and fix this, but didn't work out, and likely would have resulted in a very unpleasant experience for users anyway. This commit adds just enough support for setting up a single channel connected to a copy engine, which the kernel can use to accelerate the buffer copies between devices. Userspace has no access to this incomplete channel support, but it's suitable for TTM's needs. A more complete implementation of host(fifo) for Ampere GPUs is in the works, but the required changes are far too invasive that they would be unsuitable to backport to fix this issue on current kernels. v2: fix GPFIFO length in RAMFC (reported by Karol) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Tested-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916220406.666454-1-skeggsb@gmail.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ben Skeggs authored
Prevent NVD core channel error code 67 occuring and hanging display, managed to reproduce on GA102 while testing suspend/resume scenarios. Required extension of earlier commit to fix interactions with EFI. Fixes: e78b1b54 ("drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210906005628.11499-2-skeggsb@gmail.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Jernej Skrabec authored
Recent rework, which made HDMI PHY driver a platform device, inadvertely reversed clock setup order. HW is very touchy about it. Proper way is to handle controllers resets and clocks first and HDMI PHYs second. Currently, without this fix, first mode set completely fails (nothing on HDMI monitor) on H3 era PHYs. On H6, it still somehow work. Move HDMI PHY reset & clocks handling to sun8i_hdmi_phy_init() which will assure that code is executed after controllers reset & clocks are handled. Additionally, add sun8i_hdmi_phy_deinit() which will deinit them at controllers driver unload. Tested on A64, H3, H6 and R40. Fixes: 9bf37977 ("drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210915175836.3158839-1-jernej.skrabec@gmail.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Maxime Ripard authored
Commitc7d30623 ("drm/vc4: hdmi: Remove unused struct") removed the references to the vc4_hdmi_audio_widgets and vc4_hdmi_audio_routes structures, but not the structures themselves resulting in two warnings. Remove it. Fixes: c7d30623 ("drm/vc4: hdmi: Remove unused struct") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819140753.930751-1-maxime@cerno.techSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Edmund Dea authored
Enable one additional plane that is alpha blended on top of the primary plane. This also fixes the below warnings when building with -Warray-bounds: drivers/gpu/drm/kmb/kmb_plane.c:135:20: warning: array subscript 3 is above array bounds of 'struct layer_status[1]' [-Warray-bounds] drivers/gpu/drm/kmb/kmb_plane.c:132:20: warning: array subscript 2 is above array bounds of 'struct layer_status[1]' [-Warray-bounds] drivers/gpu/drm/kmb/kmb_plane.c:129:20: warning: array subscript 1 is above array bounds of 'struct layer_status[1]' [-Warray-bounds] v2: corrected previous patch dependecies so it builds Signed-off-by: Edmund Dea <edmund.j.dea@intel.com> Signed-off-by: Anitha Chrisanthus <anitha.chrisanthus@intel.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.kernel.org/project/dri-devel/patch/20210728003126.1425028-13-anitha.chrisanthus@intel.com/Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 03 Oct, 2021 12 commits
-
-
Linus Torvalds authored
-
Chen Jingwen authored
In commit b212921b ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings") we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp. Unfortunately, this will cause kernel to fail to start with: 1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already Failed to execute /init (error -17) The reason is that the elf interpreter (ld.so) has overlapping segments. readelf -l ld-2.31.so Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000002c94c 0x000000000002c94c R E 0x10000 LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0 0x00000000000021e8 0x0000000000002320 RW 0x10000 LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00 0x00000000000011ac 0x0000000000001328 RW 0x10000 The reason for this problem is the same as described in commit ad55eac7 ("elf: enforce MAP_FIXED on overlaying elf segments"). Not only executable binaries, elf interpreters (e.g. ld.so) can have overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go back to MAP_FIXED in load_elf_interp. Fixes: 4ed28639 ("fs, elf: drop MAP_FIXED usage from elf_map") Cc: <stable@vger.kernel.org> # v4.19 Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: Chen Jingwen <chenjingwen6@huawei.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus Torvalds authored
Pull ext4 fixes from Ted Ts'o: "Fix a number of ext4 bugs in fast_commit, inline data, and delayed allocation. Also fix error handling code paths in ext4_dx_readdir() and ext4_fill_super(). Finally, avoid a grabbing a journal head in the delayed allocation write in the common cases where we are overwriting a pre-existing block or appending to an inode" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: recheck buffer uptodate bit under buffer lock ext4: fix potential infinite loop in ext4_dx_readdir() ext4: flush s_error_work before journal destroy in ext4_fill_super ext4: fix loff_t overflow in ext4_max_bitmap_size() ext4: fix reserved space counter leakage ext4: limit the number of blocks in one ADD_RANGE TLV ext4: enforce buffer head state assertion in ext4_da_map_blocks ext4: remove extent cache entries when truncating inline data ext4: drop unnecessary journal handle in delalloc write ext4: factor out write end code of inline file ext4: correct the error path of ext4_write_inline_data_end() ext4: check and update i_disksize properly ext4: add error checking to ext4_ext_replay_set_iblocks()
-
Linus Torvalds authored
The objtool warning that the kvm instruction emulation code triggered wasn't very useful: arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception in that it helpfully tells you which symbol name it had trouble figuring out the relocation for, but it doesn't actually say what the unknown symbol type was that triggered it all. In this case it was because of missing type information (type 0, aka STT_NOTYPE), but on the whole it really should just have printed that out as part of the message. Because if this warning triggers, that's very much the first thing you want to know - why did reloc2sec_off() return failure for that symbol? So rather than just saying you can't handle some type of symbol without saying what the type _was_, just print out the type number too. Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types") Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com/Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
The recent change to make objtool aware of more symbol relocation types (commit 24ff6525: "objtool: Teach get_alt_entry() about more relocation types") also added another check, and resulted in this objtool warning when building kvm on x86: arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception The reason seems to be that kvm_fastop_exception() is marked as a global symbol, which causes the relocation to ke kept around for objtool. And at the same time, the kvm_fastop_exception definition (which is done as an inline asm statement) doesn't actually set the type of the global, which then makes objtool unhappy. The minimal fix is to just not mark kvm_fastop_exception as being a global symbol. It's only used in that one compilation unit anyway, so it was always pointless. That's how all the other local exception table labels are done. I'm not entirely happy about the kinds of games that the kvm code plays with doing its own exception handling, and the fact that it confused objtool is most definitely a symptom of the code being a bit too subtle and ad-hoc. But at least this trivial one-liner makes objtool no longer upset about what is going on. Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types") Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com/ Cc: Borislav Petkov <bp@suse.de> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Wanpeng Li <wanpengli@tencent.com> Cc: Jim Mattson <jmattson@google.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "Here are some small misc driver fixes for 5.15-rc4. They are in two "groups": - ipack driver fixes for issues found by Johan Hovold - interconnect driver fixes for reported problems All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: ipack: ipoctal: fix module reference leak ipack: ipoctal: fix missing allocation-failure check ipack: ipoctal: fix tty-registration error handling ipack: ipoctal: fix tty registration race ipack: ipoctal: fix stack information leak interconnect: qcom: sdm660: Add missing a2noc qos clocks dt-bindings: interconnect: sdm660: Add missing a2noc qos clocks interconnect: qcom: sdm660: Correct NOC_QOS_PRIORITY shift and mask interconnect: qcom: sdm660: Fix id of slv_cnoc_mnoc_cfg
-
Linus Torvalds authored
Merge tag 'driver-core-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are some driver core and kernfs fixes for reported issues for 5.15-rc4. These fixes include: - kernfs positive dentry bugfix - debugfs_create_file_size error path fix - cpumask sysfs file bugfix to preserve the user/kernel abi (has been reported multiple times.) - devlink fixes for mdiobus devices as reported by the subsystem maintainers. Also included in here are some devlink debugging changes to make it easier for people to report problems when asked. They have already helped with the mdiobus and other subsystems reporting issues. All of these have been linux-next for a while with no reported issues" * tag 'driver-core-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: kernfs: also call kernfs_set_rev() for positive dentry driver core: Add debug logs when fwnode links are added/deleted driver core: Create __fwnode_link_del() helper function driver core: Set deferred probe reason when deferred by driver core net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD driver core: fw_devlink: Improve handling of cyclic dependencies cpumask: Omit terminating null byte in cpumap_print_{list,bitmask}_to_buf debugfs: debugfs_create_file_size(): use IS_ERR to check for error
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Borislav Petkov: - Tell the compiler to always inline is_percpu_thread() - Make sure tunable_scaling buffer is null-terminated after an update in sysfs - Fix LTP named regression due to cgroup list ordering * tag 'sched_urgent_for_v5.15_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched: Always inline is_percpu_thread() sched/fair: Null terminate buffer when updating tunable_scaling sched/fair: Add ancestors of unthrottled undecayed cfs_rq
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Borislav Petkov: - Make sure the destroy callback is reset when a event initialization fails - Update the event constraints for Icelake - Make sure the active time of an event is updated even for inactive events * tag 'perf_urgent_for_v5.15_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/core: fix userpage->time_enabled of inactive events perf/x86/intel: Update event constraints for ICX perf/x86: Reset destroy callback on event init failure
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull objtool fix from Borislav Petkov: - Handle symbol relocations properly due to changes in the toolchains which remove section symbols now * tag 'objtool_urgent_for_v5.15_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Teach get_alt_entry() about more relocation types
-
Linus Torvalds authored
Merge tag 'hwmon-for-v5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Fixed various potential NULL pointer accesses in w8379* drivers - Improved error handling, fault reporting, and fixed rounding in thmp421 driver - Fixed error handling in ltc2947 driver - Added missing attribute to pmbus/mp2975 driver - Fixed attribute values in pbus/ibm-cffps, occ, and mlxreg-fan drivers - Removed unused residual code from k10temp driver * tag 'hwmon-for-v5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field hwmon: (pmbus/mp2975) Add missed POUT attribute for page 1 mp2975 controller hwmon: (pmbus/ibm-cffps) max_power_out swap changes hwmon: (occ) Fix P10 VRM temp sensors hwmon: (ltc2947) Properly handle errors when looking for the external clock hwmon: (tmp421) fix rounding for negative values hwmon: (tmp421) report /PVLD condition as fault hwmon: (tmp421) handle I2C errors hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs hwmon: (k10temp) Remove residues of current and voltage
-
git://git.samba.org/ksmbdLinus Torvalds authored
Pull ksmbd server fixes from Steve French: "Eleven fixes for the ksmbd kernel server, mostly security related: - an important fix for disabling weak NTLMv1 authentication - seven security (improved buffer overflow checks) fixes - fix for wrong infolevel struct used in some getattr/setattr paths - two small documentation fixes" * tag '5.15-rc3-ksmbd-fixes' of git://git.samba.org/ksmbd: ksmbd: missing check for NULL in convert_to_nt_pathname() ksmbd: fix transform header validation ksmbd: add buffer validation for SMB2_CREATE_CONTEXT ksmbd: add validation in smb2 negotiate ksmbd: add request buffer validation in smb2_set_info ksmbd: use correct basic info level in set_file_basic_info() ksmbd: remove NTLMv1 authentication ksmbd: fix documentation for 2 functions MAINTAINERS: rename cifs_common to smbfs_common in cifs and ksmbd entry ksmbd: fix invalid request buffer access in compound ksmbd: remove RFC1002 check in smb2 request
-
- 02 Oct, 2021 12 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Five fairly minor fixes and spelling updates, all in drivers. Even though the ufs fix is in tracing, it's a potentially exploitable use beyond end of array bug" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: csiostor: Add module softdep on cxgb4 scsi: qla2xxx: Fix excessive messages during device logout scsi: virtio_scsi: Fix spelling mistake "Unsupport" -> "Unsupported" scsi: ses: Fix unsigned comparison with less than zero scsi: ufs: Fix illegal offset in UPIU event trace
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: "A few block fixes for this release: - Revert a BFQ commit that causes breakage for people. Unfortunately it was auto-selected for stable as well, so now 5.14.7 suffers from it too. Hopefully stable will pick up this revert quickly too, so we can remove the issue on that end as well. - Add a quirk for Apple NVMe controllers, which due to their non-compliance broke due to the introduction of command sequences (Keith) - Use shifts in nbd, fixing a __divdi3 issue (Nick)" * tag 'block-5.15-2021-10-01' of git://git.kernel.dk/linux-block: nbd: use shifts rather than multiplies Revert "block, bfq: honor already-setup queue merges" nvme: add command id quirk for apple controllers
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fixes from Jens Axboe: "Two fixes in here: - The signal issue that was discussed start of this week (me). - Kill dead fasync support in io_uring. Looks like it was broken since io_uring was initially merged, and given that nobody has ever complained about it, let's just kill it (Pavel)" * tag 'io_uring-5.15-2021-10-01' of git://git.kernel.dk/linux-block: io_uring: kill fasync io-wq: exclusively gate signal based exit on get_signal() return
-
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimmLinus Torvalds authored
Pull libnvdimm fixes from Dan Williams: "A fix for a regression added this cycle in the pmem driver, and for a long standing bug for failed NUMA node lookups on ARM64. This has appeared in -next for several days with no reported issues. Summary: - Fix a regression that caused the sysfs ABI for pmem block devices to not be registered. This fails the nvdimm unit tests and dax xfstests. - Fix numa node lookups for dax-kmem memory (device-dax memory assigned to the page allocator) on ARM64" * tag 'libnvdimm-fixes-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nvdimm/pmem: fix creating the dax group ACPI: NFIT: Use fallback node id when numa info in NFIT table is incorrect
-
Dave Wysochanski authored
In cachefiles_mark_object_buried, the dentry in question may not have an owner, and thus our cachefiles_object pointer may be NULL when calling the tracepoint, in which case we will also not have a valid debug_id to print in the tracepoint. Check for NULL object in the tracepoint and if so, just set debug_id to MAX_UINT as was done in 2908f5e1 ("fscache: Add a cookie debug ID and use that in traces"). This fixes the following oops: FS-Cache: Cache "mycache" added (type cachefiles) CacheFiles: File cache on vdc registered ... Workqueue: fscache_object fscache_object_work_func [fscache] RIP: 0010:trace_event_raw_event_cachefiles_mark_buried+0x4e/0xa0 [cachefiles] .... Call Trace: cachefiles_mark_object_buried+0xa5/0xb0 [cachefiles] cachefiles_bury_object+0x270/0x430 [cachefiles] cachefiles_walk_to_object+0x195/0x9c0 [cachefiles] cachefiles_lookup_object+0x5a/0xc0 [cachefiles] fscache_look_up_object+0xd7/0x160 [fscache] fscache_object_work_func+0xb2/0x340 [fscache] process_one_work+0x1f1/0x390 worker_thread+0x53/0x3e0 kthread+0x127/0x150 Fixes: 2908f5e1 ("fscache: Add a cookie debug ID and use that in traces") Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: linux-cachefs@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
5.15-rc1 crashes with blank screen when booting up on two ThinkPads using i915. Bisections converge convincingly, but arrive at different and suprising "culprits", none of them the actual culprit. netconsole (with init_netconsole() hacked to call i915_init() when logging has started, instead of by module_init()) tells the story: kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! with RSI: ffffffff814d408b pointing to sw_fence_dummy_notify(). I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that function needs to be 4-byte aligned. Fixes: 62eaf0ae ("drm/i915/guc: Support request cancellation") Signed-off-by: Hugh Dickins <hughd@google.com> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Nadezda Lutovinova authored
If driver read tmp value sufficient for (tmp & 0x08) && (!(tmp & 0x80)) && ((tmp & 0x7) == ((tmp >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-3-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignments] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
Nadezda Lutovinova authored
If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-2-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multipline alignment] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
Nadezda Lutovinova authored
If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-1-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
Vadim Pasternak authored
Add missed attribute for reading POUT from page 1. It is supported by device, but has been missed in initial commit. Fixes: 2c6fcbb2 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210927070740.2149290-1-vadimp@nvidia.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
Brandon Wyman authored
The bytes for max_power_out from the ibm-cffps devices differ in byte order for some power supplies. The Witherspoon power supply returns the bytes in MSB/LSB order. The Rainier power supply returns the bytes in LSB/MSB order. The Witherspoon power supply uses version cffps1. The Rainier power supply should use version cffps2. If version is cffps1, swap the bytes before output to max_power_out. Tested: Witherspoon before: 3148. Witherspoon after: 3148. Rainier before: 53255. Rainier after: 2000. Signed-off-by: Brandon Wyman <bjwyman@gmail.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210928205051.1222815-1-bjwyman@gmail.com [groeck: Replaced yoda programming] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
Eddie James authored
The P10 (temp sensor version 0x10) doesn't do the same VRM status reporting that was used on P9. It just reports the temperature, so drop the check for VRM fru type in the sysfs show function, and don't set the name to "alarm". Fixes: db4919ec ("hwmon: (occ) Add new temperature sensor type") Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210929153604.14968-1-eajames@linux.ibm.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
- 01 Oct, 2021 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull s390 fix from Vasily Gorbik: "One fix for 5.15-rc4: Avoid CIO excessive path-verification requests, which might cause unwanted delays" * tag 's390-5.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cio: avoid excessive path-verification requests
-