Re: kmemleak: Found object by alias at 0xffff888107b65918

2025-01-10 Thread Borislav Petkov
On Thu, Jan 09, 2025 at 03:40:59PM -0500, Alex Deucher wrote: > Possibly fixed by this patch? > https://lore.kernel.org/lkml/CAJZ5v0i=ap+w4QZ8f2DsaHY6D=XUEuSNjyQ-2_=dgolfzjd...@mail.gmail.com/T/ Yap, it does. You can add Reported-by: Borislav Petkov (AMD) Tested-by: Borislav Petkov (AMD

kmemleak: Found object by alias at 0xffff888107b65918

2025-01-09 Thread Borislav Petkov
Hi folks, this is rc6 + tip/master, machine is Carrizo laptop. full dmesg attached. Thx. ... [ 13.271015] [drm] DM_PPLIB:level : 8 [ 13.271658] [drm] Display Core v3.2.310 initialized on DCE 11.0 [ 13.351651] kmemleak: Found object by alias at 0x888107b65918 [ 13.35236

Re: [PATCH 1/7] vsprintf: Add %pTN to print task name

2024-12-13 Thread Borislav Petkov
On Fri, Dec 13, 2024 at 10:35:03AM +0200, Kalle Valo wrote: > I agree, it makes the code harder to read for someone who is not > familiar with all the %p magic we have (like me). +1 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] drm/amd: Use a constant format string for amdgpu_ucode_request

2024-10-28 Thread Borislav Petkov
On Mon, Aug 05, 2024 at 04:12:48PM -0400, Alex Deucher wrote: > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c > > index fbc2852278e1..6162582d0aa2 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c > > +++ b/drivers/gpu/dr

Re: dw_mipi_dsi-stm.c:(.text+0x8db9a3): undefined reference to `clk_hw_unregister'

2024-09-10 Thread Borislav Petkov
On Tue, Sep 10, 2024 at 12:48:49PM +0200, Raphael Gallais-Pou wrote: > Unless I am mistaken, the link you provided refers to a PowerPC linker error: Ah, the kernel test robot is doing other architectures now too, sorry about that. In any case, I am triggering it on x86 too. > What do you mean by

Re: dw_mipi_dsi-stm.c:(.text+0x8db9a3): undefined reference to `clk_hw_unregister'

2024-09-09 Thread Borislav Petkov
On Mon, Sep 09, 2024 at 08:57:57AM +0200, Raphael Gallais-Pou wrote: > Arnd Bergmann sent a patch regarding this issue on x86 that I merged several > weeks ago. > > https://lore.kernel.org/lkml/20240719075454.3595358-1-a...@kernel.org/ > https://lore.kernel.org/all/c3d0757a-07c0-4f83-9f06-c3ad205a

Re: [REGRESSION] soft lockup on boot starting with kernel 6.10 / commit 5186ba33234c9a90833f7c93ce7de80e25fac6f5

2024-09-09 Thread Borislav Petkov
On Sun, Sep 08, 2024 at 11:53:56PM -0700, Hugues Bruant wrote: > Hi, > > I have discovered a 100% reliable soft lockup on boot on my laptop: > Purism Librem 14, Intel Core i7-10710U, 48Gb RAM, Samsung Evo Plus 970 > SSD, CoreBoot BIOS, grub bootloader, Arch Linux. > > The last working release is

dw_mipi_dsi-stm.c:(.text+0x8db9a3): undefined reference to `clk_hw_unregister'

2024-09-05 Thread Borislav Petkov
Hi all, this fires in my randbuilds here: vmlinux.o: warning: objtool: adis16400_write_raw() falls through to next function adis16400_show_serial_number() ld: vmlinux.o: in function `dw_mipi_dsi_stm_remove': dw_mipi_dsi-stm.c:(.text+0x8db9a3): undefined reference to `clk_hw_unregister' ld: vmlin

WARNING: CPU: 0 PID: 8 at drivers/video/fbdev/core/fbmem.c:467 unregister_framebuffer+0x45/0x160 (was: Re: BUG: kernel NULL pointer dereference, address: 0000000000000000 on boot with linux-next-20240

2024-09-02 Thread Borislav Petkov
Fixing subject and recipients and leaving the whole mail untouched. On Sun, Sep 01, 2024 at 05:01:28PM +0200, V, Narasimhan wrote: > [AMD Official Use Only - AMD Internal Distribution Only] > > Hi, > > Seeing the following warning and bug on boot with linux-next-20240829 > > WARNING: CPU: 0 PID

Re: [PATCH 1/2] drm/vmwgfx: Fix missing HYPERVISOR_GUEST dependency

2024-06-17 Thread Borislav Petkov
On Mon, Jun 17, 2024 at 01:51:23PM -0700, Alexey Makhalov wrote: > Not really a gcc related, but the matter of a config file. It is > reproducible if CONFIG_HYPERVISOR_GUEST not set, but CONFIG_DRM_VMWGFX=y. > And this combination was allowed before the fix. Using their config: $ grep -E "(CONFIG

Re: [PATCH 2/2] iio: dac: Fix dependencies of AD9739A

2024-06-17 Thread Borislav Petkov
On Mon, Jun 17, 2024 at 01:48:38PM -0700, Alexey Makhalov wrote: > > Don't get discouraged, though, when fixing something that is not in our > > immediate area of interest! > > > > :-) > > Lesson learned and noted for next time to address only related/new warnings > and errors. Thanks! I actually

Re: [PATCH 1/2] drm/vmwgfx: Fix missing HYPERVISOR_GUEST dependency

2024-06-17 Thread Borislav Petkov
On Mon, Jun 17, 2024 at 11:07:09AM +0200, Borislav Petkov wrote: > On Sat, Jun 15, 2024 at 06:25:10PM -0700, Alexey Makhalov wrote: > > VMWARE_HYPERCALL alternative will not work as intended without > > VMware guest code initialization. > > > > Reported-by: ke

Re: [PATCH 1/2] drm/vmwgfx: Fix missing HYPERVISOR_GUEST dependency

2024-06-17 Thread Borislav Petkov
On Sat, Jun 15, 2024 at 06:25:10PM -0700, Alexey Makhalov wrote: > VMWARE_HYPERCALL alternative will not work as intended without > VMware guest code initialization. > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202406152104.fxakp1mb-...@intel.com/ > Signed

Re: [PATCH 2/2] iio: dac: Fix dependencies of AD9739A

2024-06-17 Thread Borislav Petkov
On Sat, Jun 15, 2024 at 06:25:11PM -0700, Alexey Makhalov wrote: > 0-DAY CI Kernel Test automation reported an issue: > >ld: drivers/base/regmap/regmap-spi.o: in function `regmap_spi_read': >regmap-spi.c:(.text+0xf): undefined reference to `spi_write_then_read' >ld: drivers/base/regmap

Re: [PATCH v11 8/8] x86/vmware: Add TDX hypercall support

2024-06-14 Thread Borislav Petkov
On Fri, Jun 14, 2024 at 11:32:16AM -0700, Alexey Makhalov wrote: > > > On 6/14/24 9:19 AM, Dave Hansen wrote: > > On 6/14/24 09:14, Borislav Petkov wrote: > > > On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote: > > ... > > > >

Re: [PATCH v11 8/8] x86/vmware: Add TDX hypercall support

2024-06-14 Thread Borislav Petkov
On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote: > On 6/13/24 12:16, Alexey Makhalov wrote: > > +unsigned long vmware_tdx_hypercall(unsigned long cmd, > > + unsigned long in1, unsigned long in3, > > + unsigned long in4, unsigned

Re: [PATCH v11 1/8] x86/vmware: Introduce VMware hypercall API

2024-06-13 Thread Borislav Petkov
On Wed, Jun 12, 2024 at 03:11:54PM -0700, Alexey Makhalov wrote: > Borislav, please review v11 implementation of 1/8 based on your proposal. > I'm waiting for your feedback before sending full v11 patchset. Sorry about that - -ETOOMUCHEMAIL. :-( Yeah, that patch looks all good and regular now, an

Re: [PATCH v10 1/8] x86/vmware: Introduce VMware hypercall API

2024-06-03 Thread Borislav Petkov
On Wed, May 29, 2024 at 05:44:32PM -0700, Alexey Makhalov wrote: > While most of the vmware_hypercall callers are executed after alternative > patching applied, there are small amount of hypercalls running before that. > Only for them we have the logic of analyzing vmware_hypercall_mode as a > defa

Re: [PATCH v10 1/8] x86/vmware: Introduce VMware hypercall API

2024-05-27 Thread Borislav Petkov
On Thu, May 23, 2024 at 12:14:39PM -0700, Alexey Makhalov wrote: > +#define VMWARE_HYPERCALL \ > + ALTERNATIVE_3("", \ > + "jmp .Lport_call%=", X86_FEATURE_HYPERVISOR, \ > +

Re: [PATCH v9 3/8] x86/vmware: Introduce VMware hypercall API

2024-05-07 Thread Borislav Petkov
On Mon, May 06, 2024 at 02:53:00PM -0700, Alexey Makhalov wrote: > +#define VMWARE_HYPERCALL \ > + ALTERNATIVE_3("cmpb $" \ > + __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) \ > +

Re: [PATCH v9 1/8] x86/vmware: Move common macros to vmware.h

2024-05-07 Thread Borislav Petkov
On Mon, May 06, 2024 at 02:52:58PM -0700, Alexey Makhalov wrote: > +#define VMWARE_HYPERVISOR_PORT 0x5658 > +#define VMWARE_HYPERVISOR_PORT_HB(VMWARE_HYPERVISOR_PORT | \ > + VMWARE_HYPERVISOR_HB) You can't help yourself not sneaking in any cha

Re: [PATCH v9 2/8] x86/vmware: Move common macros to vmware.h

2024-05-05 Thread Borislav Petkov
On Wed, Apr 24, 2024 at 04:14:07PM -0700, Alexey Makhalov wrote: > +#define VMWARE_CMD_GETVERSION10 > +#define VMWARE_CMD_GETHZ 45 > +#define VMWARE_CMD_GETVCPU_INFO 68 > +#define VMWARE_CMD_STEALCLOCK91 Ok, what part in "* first patch: sol

Re: [PATCH v9 1/8] x86/vmware: Correct macro names

2024-04-25 Thread Borislav Petkov
On Wed, Apr 24, 2024 at 04:14:06PM -0700, Alexey Makhalov wrote: > VCPU_RESERVED and LEGACY_X2APIC are not VMware hypercall commands. > These are bits in return value of VMWARE_CMD_GETVCPU_INFO command. > Change VMWARE_CMD_ prefix to GETVCPU_INFO_ one. And move bit-shift > operation to the macro bo

Re: [PATCH v8 1/7] x86/vmware: Move common macros to vmware.h

2024-04-24 Thread Borislav Petkov
On Mon, Apr 22, 2024 at 03:56:50PM -0700, Alexey Makhalov wrote: > Move VMware hypercall macros to vmware.h. This is a prerequisite for > the introduction of vmware_hypercall API. No functional changes besides > exporting vmware_hypercall_mode symbol. Well, I see more. So code movement patches sh

amdgpu kmemleaks

2024-02-27 Thread Borislav Petkov
Hi folks, anyone interested in a bunch of amdgpu kmemleak reports from latest Linus tree + tip? GPU is: [ 11.317312] [drm] amdgpu kernel modesetting enabled. [ 11.363627] [drm] initializing kernel modesetting (CARRIZO 0x1002:0x9874 0x103C:0x807E 0xC4). [ 11.364077] [drm] register mmio bas

Re: [PATCH v6 0/7] VMware hypercalls enhancements

2024-01-09 Thread Borislav Petkov
On Tue, Jan 09, 2024 at 12:40:45AM -0800, Alexey Makhalov wrote: > v5->v6 change: > - Added ack by Kirill A. Shutemov in patch 7. Please do not spam. Adding someone's Ack does not mean you have to resend the whole thing immediately again. While waiting, please read Documentation/process/submittin

Re: [PATCH] drm/nouveau/kms/nv50-: Don't allow inheritance of headless iors

2023-12-14 Thread Borislav Petkov
this by verifying that we actually know that there's a head > assigned to an ior before allowing it to be inherited through nvif. This > -should- hopefully fix the WARN_ON on GT218 reported by Borislav. > > Signed-off-by: Lyude Paul > Cc: Borislav Petkov > --- > driv

Re: nouveau 0000:01:00.0: drm_WARN_ON(!found_head)

2023-12-13 Thread Borislav Petkov
On Wed, Dec 13, 2023 at 12:39:36PM +0100, Borislav Petkov wrote: > We're getting close to releasing so I guess we either debug this or shut > up the WARN. Not only that - panic_on_warn turns this into an explosion so you don't want that in a released kernel. -- Regards/Gruss,

Re: nouveau 0000:01:00.0: drm_WARN_ON(!found_head)

2023-12-13 Thread Borislav Petkov
On Tue, Dec 12, 2023 at 10:35:51PM -0500, Paul Dufresne wrote: > https://gitlab.freedesktop.org/drm/nouveau/-/issues/282 Let's add more folks who were involved in 1b477f42285e ("drm/nouveau/kms: Add INHERIT ioctl to nvkm/nvif for reading IOR state") Apparently, someone wants to know that the lo

Re: nouveau 0000:01:00.0: drm_WARN_ON(!found_head)

2023-12-12 Thread Borislav Petkov
On Sat, Nov 11, 2023 at 01:03:23PM +0100, Borislav Petkov wrote: > Hi, > > this is ontop of Linus' tree from the 4th (lemme know if I should try > the latest) on one of my test boxes: > > nouveau :01:00.0: vgaarb: deactivate vga console > Console: switching to

Re: [PATCH v2 5/6] drm/vmwgfx: Use vmware_hypercall API

2023-12-05 Thread Borislav Petkov
On Fri, Dec 01, 2023 at 03:24:51PM -0800, Alexey Makhalov wrote: > Switch from VMWARE_HYPERCALL macro to vmware_hypercall API. > Eliminate arch specific code. > > drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h: implement arm64 variant > of vmware_hypercall here for now. The move of these functions to >

Re: [PATCH v2 2/6] x86/vmware: Introduce vmware_hypercall API

2023-12-04 Thread Borislav Petkov
On Fri, Dec 01, 2023 at 03:24:48PM -0800, Alexey Makhalov wrote: > Introducing vmware_hypercall family of functions as a common > implementation to be used by the VMware guest code and virtual > device drivers in architecture independent manner. > > By analogy with KVM hypercall API, vmware_hyperc

Re: [PATCH v2 1/6] x86/vmware: Move common macros to vmware.h

2023-12-04 Thread Borislav Petkov
On Fri, Dec 01, 2023 at 03:24:47PM -0800, Alexey Makhalov wrote: > Move VMware hypercall macros to vmware.h as a preparation step > for the next commit. No functional changes besides exporting "next commit" in git is ambiguous. Get rid of such formulations. -- Regards/Gruss, Boris. https://

Re: [PATCH v2 6/6] x86/vmware: Add TDX hypercall support

2023-12-04 Thread Borislav Petkov
On Fri, Dec 01, 2023 at 03:24:52PM -0800, Alexey Makhalov wrote: > +#ifdef CONFIG_INTEL_TDX_GUEST > +/* __tdx_hypercall() is not exported. So, export the wrapper */ > +void vmware_tdx_hypercall_args(struct tdx_module_args *args) > +{ > + __tdx_hypercall(args); > +} > +EXPORT_SYMBOL_GPL(vmware_t

nouveau 0000:01:00.0: drm_WARN_ON(!found_head)

2023-11-11 Thread Borislav Petkov
Hi, this is ontop of Linus' tree from the 4th (lemme know if I should try the latest) on one of my test boxes: nouveau :01:00.0: vgaarb: deactivate vga console Console: switching to colour dummy device 80x25 nouveau :01:00.0: NVIDIA GT218 (0a8280b1) CE: hpet increased min_delta_ns to 2011

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-17 Thread Borislav Petkov
On Thu, Aug 17, 2023 at 12:24:45PM +0200, Karol Herbst wrote: > simply throw a > > printk(KERN_WARNING "nvkm_uconn_uevent %u\n", outp->info.location); > > inside drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c:104 after that > mentioned comment. diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-17 Thread Borislav Petkov
On Thu, Aug 17, 2023 at 12:00:47PM +0200, Karol Herbst wrote: > btw, what would help is to know where `nvkm_uconn_uevent` actually > fails, or rather, are you running into this "/* TODO: support DP IRQ > on ANX9805 and remove this hack. */" condition? Send me a diff, I'll run it here and catch out

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-17 Thread Borislav Petkov
On Thu, Aug 17, 2023 at 01:18:12AM +0200, Karol Herbst wrote: > do you have one of these? https://en.wikipedia.org/wiki/DMS-59 Ah, DMS == Dual Monitor Solution :-) Yap, that's exactly what the GPU has. And the Y-cable is 2xDVI. It is a Dell workstation and it came this way, meaning I haven't done

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Wed, Aug 16, 2023 at 11:27:05PM +0200, Karol Herbst wrote: > that GPU has only a `DMS-59` connector, is that right? No clue. How do I figure that out? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Wed, Aug 16, 2023 at 04:57:28PM +0200, Karol Herbst wrote: > Do you have any connectors listed in "/sys/class/drm"? tree /sys/class/drm/ /sys/class/drm/ ├── card0 -> ../../devices/pci:00/:00:02.0/:03:00.0/drm/card0 ├── renderD128 -> ../../devices/pci:00/:00:02.0/:03:00.

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote: > Mind sharing your kernel logs with that patch applied? I suspect your > system boots up but you might just not have the connector available or > something? It could be that you have one of those GPUs affected by the > original change a

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Wed, Aug 16, 2023 at 12:11:57PM +0200, Borislav Petkov wrote: > Does that help? Btw, note that this is *plain* -rc5, without your patch. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Wed, Aug 16, 2023 at 12:03:44PM +0200, Borislav Petkov wrote: > On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote: > > Mind sharing your kernel logs with that patch applied? I suspect your > > system boots up but you might just not have the connector available or &g

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote: > Mind sharing your kernel logs with that patch applied? I suspect your > system boots up but you might just not have the connector available or > something? It could be that you have one of those GPUs affected by the > original change a

Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

2023-08-16 Thread Borislav Petkov
On Mon, Aug 14, 2023 at 04:49:32PM +0200, Karol Herbst wrote: > We can't simply free the connector after calling drm_connector_init on it. > We need to clean up the drm side first. > > It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp: > PIOR DP uses GPIO for HPD, not PMGR AUX

Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")

2023-08-08 Thread Borislav Petkov
On Tue, Aug 08, 2023 at 12:39:32PM +0200, Karol Herbst wrote: > ahh, that would have been good to know :) Yeah, I didn't see it before - it would only freeze. Only after I added the printk you requested. > Mind figuring out what's exactly NULL inside nvif_object_mthd? Or > rather what line `nvif_

Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")

2023-08-07 Thread Borislav Petkov
On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote: > in what way does it stop? Just not progressing? That would be kinda > concerning. Mind tracing with what arguments `nvkm_uevent_add` is > called with and without that patch? Well, me dumping those args I guess made the box not freeze

2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")

2023-08-06 Thread Borislav Petkov
Hi folks, the patch in $Subject breaks booting here on one of my test boxes, see below. Reverting it ontop of -rc4 fixes the issue. Thx. [3.580535] ACPI: \_PR_.CP04: Found 4 idle states [3.585694] ACPI: \_PR_.CP05: Found 4 idle states [3.590852] ACPI: \_PR_.CP06: Found 4 idle states

Re: [PATCH] drm/radeon: Disable outputs when releasing fbdev client

2023-06-09 Thread Borislav Petkov
nd the modesetting > code when the framebuffer got displayed. It only got unpinned once by > the fbdev helper radeon_fbdev_destroy_pinned_object(). Hence TTM's BO- > release function complains about the pin counter. Forcing the outputs > off also undoes the modesettings pin incre

WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326 ttm_bo_release+0x27e/0x2d0 [ttm]

2023-06-03 Thread Borislav Petkov
Hi, this below triggers with the latest Linus tree: 51f269a6ecc7 ("Merge tag 'probes-fixes-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace") ... [ 16.173593] [drm] radeon kernel modesetting enabled. [ 16.173743] radeon :29:00.0: vgaarb: deactivate vga console

Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask

2023-06-02 Thread Borislav Petkov
On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: > As described in the commit message, this only works on bare metal due to the > PAT bit not being needed for WC mappings. > > Making this patch Xen specific would try to cure the symptoms without fixing > the underlying problem: _PAGE_

Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask

2023-05-31 Thread Borislav Petkov
On Fri, May 19, 2023 at 08:36:34PM +0200, Janusz Krzysztofik wrote: > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 15ae4d6ba4768..56466afd04307 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -654,8 +654,10 @@ static

call to __compiletime_assert_1441 declared with attribute error: FIELD_PREP: mask is not constant

2022-11-18 Thread Borislav Petkov
Hi, I'm getting this on latest Linus master with gcc (SUSE Linux) 7.5.0: DESCEND objtool CALLscripts/checksyscalls.sh CC [M] drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o In file included from :0:0: In function ‘__guc_context_policy_add_priority.isra.45’, inlined from ‘__guc_co

[PATCH 11/11] drm/i915: Fix undefined behavior due to shift overflowing the constant

2022-04-05 Thread Borislav Petkov
From: Borislav Petkov Fix: In file included from :0:0: drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function ‘intel_guc_send_mmio’: ././include/linux/compiler_types.h:352:38: error: call to ‘__compiletime_assert_1047’ \ declared with attribute error: FIELD_PREP: mask is not constant

[PATCH 04/11] drm/r128: Fix undefined behavior due to shift overflowing the constant

2022-04-05 Thread Borislav Petkov
From: Borislav Petkov Fix: drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’: drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce to an integer constant case R128_PM4_64BM_64VCBM_64INDBM: ^~~~ drivers/gpu/drm/r128/r128_cce.c:418:2: error: case

Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
On Tue, Sep 28, 2021 at 02:01:57PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Yes. But, since the check is related to TDX, I just want to confirm whether > you are fine with naming the function as intel_*(). Why is this such a big of a deal?! There's amd_cc_platform_has() and intel_cc_platform_h

Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Just read it. If you want to use cpuid_has_tdx_guest() directly in > cc_platform_has(), then you want to rename intel_cc_platform_has() to > tdx_cc_platform_has()? Why? You simply do: if (cpuid_has_tdx_guest()

Re: [PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Intel CC support patch is not included in this series. You want me > to address the issue raised by Joerg before merging it? Did you not see my email to you today: https://lkml.kernel.org/r/yvl4zughfsh1q...@zn.tnic ?

[PATCH 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
Signed-off-by: Borislav Petkov --- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/kernel/sev.c | 6 +++--- arch/x86/mm/mem_encrypt.c | 24 +++- arch/x86/realmode/init.c | 3 +-- 4 files changed, 7 insertions(+), 28 deletions(-) diff --git

[PATCH 6/8] x86/sev: Replace occurrences of sev_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
-by: Borislav Petkov --- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/kernel/crash_dump_64.c| 4 +++- arch/x86/kernel/kvm.c | 3 ++- arch/x86/kernel/kvmclock.c | 4 ++-- arch/x86/kernel/machine_kexec_64.c | 4 ++-- arch/x86/kvm/svm/svm.c | 3

[PATCH 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
sev_active() that are really geared towards detecting if SME is active. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/x86/include/asm/kexec.h | 2 +- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/kernel/machine_kexec_64.c | 15 --- arch/x86/kernel

[PATCH 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

2021-09-28 Thread Borislav Petkov
implementation of mem_encrypt_active(), cc_platform_has() does not need to be implemented in s390 (the config option ARCH_HAS_CC_PLATFORM is not set). Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/powerpc/include/asm/mem_encrypt.h | 5 - arch/powerpc/platforms/pseries/svm.c| 5

[PATCH 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

2021-09-28 Thread Borislav Petkov
: Borislav Petkov Acked-by: Michael Ellerman --- arch/powerpc/platforms/pseries/Kconfig | 1 + arch/powerpc/platforms/pseries/Makefile | 2 ++ arch/powerpc/platforms/pseries/cc_platform.c | 26 3 files changed, 29 insertions(+) create mode 100644 arch/powerpc/platforms

[PATCH 3/8] x86/sev: Add an x86 version of cc_platform_has()

2021-09-28 Thread Borislav Petkov
From: Tom Lendacky Introduce an x86 version of the cc_platform_has() function. This will be used to replace vendor specific calls like sme_active(), sev_active(), etc. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/x86/Kconfig | 1 + arch/x86/include

[PATCH 1/8] x86/ioremap: Selectively build arch override encryption functions

2021-09-28 Thread Borislav Petkov
nally, phys_mem_access_encrypted() is conditionally built as well, but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is not set. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/x86/include/asm/io.h | 8 arch/x86/mm/ioremap.c | 2 +- 2

[PATCH v4 0/8] Implement generic cc_platform_has() helper function

2021-09-28 Thread Borislav Petkov
From: Borislav Petkov Hi all, here's v4 of the cc_platform_has() patchset with feedback incorporated. I'm going to route this through tip if there are no objections. Thx. Tom Lendacky (8): x86/ioremap: Selectively build arch override encryption functions arch/cc: Introduce a f

[PATCH 2/8] arch/cc: Introduce a function to check for confidential computing features

2021-09-28 Thread Borislav Petkov
: Tom Lendacky Signed-off-by: Borislav Petkov --- arch/Kconfig| 3 ++ include/linux/cc_platform.h | 88 + 2 files changed, 91 insertions(+) create mode 100644 include/linux/cc_platform.h diff --git a/arch/Kconfig b/arch/Kconfig index

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-24 Thread Borislav Petkov
On Fri, Sep 24, 2021 at 12:41:32PM +0300, Kirill A. Shutemov wrote: > On Thu, Sep 23, 2021 at 08:21:03PM +0200, Borislav Petkov wrote: > > On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote: > > > Unless we find other way to guarantee RIP-relative a

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-23 Thread Borislav Petkov
On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote: > Unless we find other way to guarantee RIP-relative access, we must use > fixup_pointer() to access any global variables. Yah, I've asked compiler folks about any guarantees we have wrt rip-relative addresses but it doesn't look

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-22 Thread Borislav Petkov
On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote: > Not fine, but waiting to blowup with random build environment change. Why is it not fine? Are you suspecting that the compiler might generate something else and not a rip-relative access? -- Regards/Gruss, Boris. https:/

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-21 Thread Borislav Petkov
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote: > I still believe calling cc_platform_has() from __startup_64() is totally > broken as it lacks proper wrapping while accessing global variables. Well, one of the issues on the AMD side was using boot_cpu_data too early and the In

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-21 Thread Borislav Petkov
On Tue, Sep 21, 2021 at 12:04:58PM -0500, Tom Lendacky wrote: > Looks like instrumentation during early boot. I worked with Boris offline to > exclude arch/x86/kernel/cc_platform.c from some of the instrumentation and > that allowed an allyesconfig to boot. And here's the lineup I have so far, I'd

Re: BUG: unable to handle kernel paging request in drm_fb_helper_damage_work

2021-09-20 Thread Borislav Petkov
On Mon, Sep 20, 2021 at 08:55:28PM +0800, Hao Sun wrote: > Hello, > > When using Healer to fuzz the latest Linux kernel, the following crash Your Healer thing - or whatever that next automated thing is which is trying to be smart - is not CCing the proper people: $ ./scripts/get_maintainer.pl -f

Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function

2021-09-16 Thread Borislav Petkov
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote: > I have a Intel variant patch (please check following patch). But it includes > TDX changes as well. Shall I move TDX changes to different patch and just > create a separate patch for adding intel_cc_platform_has()? Yes,

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

2021-09-15 Thread Borislav Petkov
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote: > Could you please provide more explicit explanation why inlining such an > helper is considered as bad practice and messy ? Tom already told you to look at the previous threads. Let's read them together. This one, for example: htt

Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function

2021-09-15 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:31PM -0500, Tom Lendacky wrote: > This patch series provides a generic helper function, cc_platform_has(), > to replace the sme_active(), sev_active(), sev_es_active() and > mem_encrypt_active() functions. > > It is expected that as new confidential computing technolo

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

2021-09-15 Thread Borislav Petkov
On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote: > I don't love it, a new C file and an out-of-line call to then call back > to a static inline that for most configuration will return false ... but > whatever :) Yeah, hch thinks it'll cause a big mess otherwise: https://lore.kern

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

2021-09-14 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index 18fe19916bc3..4b54a2377821 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

2021-09-14 Thread Borislav Petkov
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote: > Yes, see > https://lore.kernel.org/linuxppc-dev/20210914123919.58203...@canb.auug.org.au/T/#t Aha, more compiler magic stuff ;-\ Oh well, I guess that fix will land upstream soon. Thx. -- Regards/Gruss, Boris. https://pe

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

2021-09-14 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote: > Introduce a powerpc version of the cc_platform_has() function. This will > be used to replace the powerpc mem_encrypt_active() implementation, so > the implementation will initially only support the CC_ATTR_MEM_ENCRYPT > attribute. >

Re: [PATCH v3 3/8] x86/sev: Add an x86 version of cc_platform_has()

2021-09-11 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:34PM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/kernel/cc_platform.c b/arch/x86/kernel/cc_platform.c > new file mode 100644 > index ..3c9bacd3c3f3 > --- /dev/null > +++ b/arch/x86/kernel/cc_platform.c > @@ -0,0 +1,21 @@ > +// SPDX-License-Identifier

Re: [PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

2021-09-10 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:33PM -0500, Tom Lendacky wrote: > In prep for other confidential computing technologies, introduce a generic preparation > helper function, cc_platform_has(), that can be used to check for specific > active confidential computing attributes, like memory encryption. T

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-19 Thread Borislav Petkov
On Thu, Aug 19, 2021 at 10:52:53AM +0100, Christoph Hellwig wrote: > Which suggest that the name is not good to start with. Maybe protected > hardware, system or platform might be a better choice? Yah, coming up with a proper name here hasn't been easy. prot_guest_has() is not the first variant.

Re: [PATCH v2 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
On Tue, Aug 17, 2021 at 10:26:18AM -0500, Tom Lendacky wrote: > >>/* > >> - * If SME is active we need to be sure that kexec pages are > >> - * not encrypted because when we boot to the new kernel the > >> + * If host memory encryption is active we need to be sure that kexec > >> + * pa

Re: [PATCH v2 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
On Tue, Aug 17, 2021 at 09:46:58AM -0500, Tom Lendacky wrote: > I'm ok with letting the TDX folks make changes to these calls to be SME or > SEV specific, if necessary, later. Yap, exactly. Let's add the specific stuff only when really needed. Thx. -- Regards/Gruss, Boris. https://people.k

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-17 Thread Borislav Petkov
On Tue, Aug 17, 2021 at 10:22:52AM -0500, Tom Lendacky wrote: > I can change it to be an AMD/HYGON check... although, I'll have to check > to see if any (very) early use of the function will work with that. We can always change it later if really needed. It is just that I'm not a fan of such "pre

Re: [PATCH v2 09/12] mm: Remove the now unused mem_encrypt_active() function

2021-08-17 Thread Borislav Petkov
On Tue, Aug 17, 2021 at 12:22:33PM +0200, Borislav Petkov wrote: > This one wants to be part of the previous patch. ... and the three following patches too - the treewide patch does a single atomic :) replacement and that's it. -- Regards/Gruss, Boris. https://people.kernel.org/tg

Re: [PATCH v2 09/12] mm: Remove the now unused mem_encrypt_active() function

2021-08-17 Thread Borislav Petkov
On Fri, Aug 13, 2021 at 11:59:28AM -0500, Tom Lendacky wrote: > The mem_encrypt_active() function has been replaced by prot_guest_has(), > so remove the implementation. > > Reviewed-by: Joerg Roedel > Signed-off-by: Tom Lendacky > --- > include/linux/mem_encrypt.h | 4 > 1 file changed, 4

Re: [PATCH v2 07/12] x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
ture support is added for other memory encyrption > techonologies, the use of PATTR_GUEST_PROT_STATE can be updated, as > required, to specifically use PATTR_SEV_ES. > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Signed-off-by: Tom Lendacky > --- >

Re: [PATCH v2 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
On Fri, Aug 13, 2021 at 11:59:25AM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/kernel/machine_kexec_64.c > b/arch/x86/kernel/machine_kexec_64.c > index 8e7b517ad738..66ff788b79c9 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -167,7 +167,7

Re: [PATCH v2 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

2021-08-17 Thread Borislav Petkov
On Fri, Aug 13, 2021 at 11:59:24AM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index edc67ddf065d..5635ca9a1fbe 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char

Re: [PATCH v2 04/12] powerpc/pseries/svm: Add a powerpc version of prot_guest_has()

2021-08-17 Thread Borislav Petkov
On Fri, Aug 13, 2021 at 11:59:23AM -0500, Tom Lendacky wrote: > Introduce a powerpc version of the prot_guest_has() function. This will > be used to replace the powerpc mem_encrypt_active() implementation, so > the implementation will initially only support the PATTR_MEM_ENCRYPT > attribute. > > C

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-15 Thread Borislav Petkov
On Sun, Aug 15, 2021 at 08:53:31AM -0500, Tom Lendacky wrote: > It's not a cross-vendor thing as opposed to a KVM or other hypervisor > thing where the family doesn't have to be reported as AMD or HYGON. What would be the use case? A HV starts a guest which is supposed to be encrypted using the AM

Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

2021-08-14 Thread Borislav Petkov
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/protected_guest.h > b/arch/x86/include/asm/protected_guest.h > new file mode 100644 > index ..51e4eefd9542 > --- /dev/null > +++ b/arch/x86/include/asm/protected_guest.h > @@ -0,0 +1,29 @@

Re: [PATCH v2 02/12] mm: Introduce a function to check for virtualization protection features

2021-08-14 Thread Borislav Petkov
On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote: > In prep for other protected virtualization technologies, introduce a > generic helper function, prot_guest_has(), that can be used to check > for specific protection attributes, like memory encryption. This is > intended to eliminate h

Re: [PATCH v2 01/12] x86/ioremap: Selectively build arch override encryption functions

2021-08-14 Thread Borislav Petkov
ecrypted() > - memremap_is_efi_data() > - memremap_is_setup_data() > - early_memremap_is_setup_data() > > And finally, phys_mem_access_encrypted() is conditionally built as well, > but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is > not set. > > Cc: Thomas Gleixne

Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features

2021-07-28 Thread Borislav Petkov
On Wed, Jul 28, 2021 at 02:17:27PM +0100, Christoph Hellwig wrote: > So common checks obviously make sense, but I really hate the stupid > multiplexer. Having one well-documented helper per feature is much > easier to follow. We had that in x86 - it was called cpu_has_ where xxx is the feature bi

Re: [PATCH v2 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms

2021-06-03 Thread Borislav Petkov
o Acked-by: Borislav Petkov Btw, for the future, please CC everyone on the whole patchset - I had to go look at your 2/2 on lore to see what it does because I had only 1/2 in my mbox. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [syzbot] BUG: unable to handle kernel paging request in drm_fb_helper_damage_work (2)

2021-05-31 Thread Borislav Petkov
Looks DRM to me. CCed... On Mon, May 31, 2021 at 12:13:22AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:7ac3a1c1 Merge tag 'mtd/fixes-for-5.13-rc4' of git://git.k.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt

Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool

2021-01-09 Thread Borislav Petkov
> DRM_ERROR("Failed initializing VRAM heap.\n"); > -- Was finally able to test those during workstation hw maintenance so I was able to install a new kernel and reboot. Reported-by: Borislav Petkov Tested-by: Borislav Petkov Th

  1   2   3   4   >