- Linux-stable-mirror - lists.linaro.org

[PATCH] drm: Handle unexpected holes in color-eviction

by Chris Wilson

During eviction, the driver may free more than one hole in the drm_mm due to the side-effects in evicting the scanned nodes. However, drm_mm_scan_color_evict() expects that the scan result is the first available hole (in the mru freed hole_stack list): kernel BUG at drivers/gpu/drm/drm_mm.c:844! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core lpc_ich snd_pcm e1000e mei_me prime_numbers mei CPU: 1 PID: 1490 Comm: gem_userptr_bli Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1 Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A08 02/19/2008 RIP: 0010:drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: 0018:ffff880057a573f8 EFLAGS: 00010287 RAX: ffff8800611f5980 RBX: ffff880057a575d0 RCX: dffffc0000000000 RDX: 00000000029d5000 RSI: 1ffff1000af4aec1 RDI: ffff8800611f5a10 RBP: ffff88005ab884d0 R08: ffff880057a57600 R09: 000000000afff000 R10: 1ffff1000b5710b5 R11: 0000000000001000 R12: 1ffff1000af4ae82 R13: ffff8800611f59b0 R14: ffff8800611f5980 R15: ffff880057a57608 FS: 00007f2de0c2e8c0(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2ddde1e000 CR3: 00000000609b2000 CR4: 00000000000006e0 Call Trace: ? drm_mm_scan_remove_block+0x330/0x330 ? drm_mm_scan_remove_block+0x151/0x330 i915_gem_evict_something+0x711/0xbd0 [i915] ? igt_evict_contexts+0x50/0x50 [i915] ? nop_clear_range+0x10/0x10 [i915] ? igt_evict_something+0x90/0x90 [i915] ? i915_gem_gtt_reserve+0x1a1/0x320 [i915] i915_gem_gtt_insert+0x237/0x400 [i915] __i915_vma_do_pin+0xc25/0x1a20 [i915] eb_lookup_vmas+0x1c63/0x3790 [i915] ? i915_gem_check_execbuffer+0x250/0x250 [i915] ? trace_hardirqs_on_caller+0x33f/0x590 ? _raw_spin_unlock_irqrestore+0x39/0x60 ? __pm_runtime_resume+0x7d/0xf0 i915_gem_do_execbuffer+0x86a/0x2ff0 [i915] ? __kmalloc+0x132/0x340 ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915] ? drm_ioctl_kernel+0x12e/0x1c0 ? drm_ioctl+0x662/0x980 ? eb_relocate_slow+0xa90/0xa90 [i915] ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915] ? __might_fault+0xea/0x1a0 i915_gem_execbuffer2_ioctl+0x3cc/0x760 [i915] ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] ? lock_acquire+0x3c0/0x3c0 ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] drm_ioctl_kernel+0x12e/0x1c0 drm_ioctl+0x662/0x980 ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] ? drm_getstats+0x20/0x20 ? debug_check_no_obj_freed+0x2a6/0x8c0 do_vfs_ioctl+0x170/0xe70 ? ioctl_preallocate+0x170/0x170 ? task_work_run+0xbe/0x160 ? lock_acquire+0x3c0/0x3c0 ? trace_hardirqs_on_caller+0x33f/0x590 ? _raw_spin_unlock_irq+0x2f/0x50 SyS_ioctl+0x36/0x70 ? do_vfs_ioctl+0xe70/0xe70 do_syscall_64+0x18c/0x5d0 entry_SYSCALL_64_after_hwframe+0x26/0x9b RIP: 0033:0x7f2ddf13b587 RSP: 002b:00007fff15c4f9d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2ddf13b587 RDX: 00007fff15c4fa20 RSI: 0000000040406469 RDI: 0000000000000003 RBP: 00007fff15c4fa20 R08: 0000000000000000 R09: 00007f2ddf3fe120 R10: 0000000000000073 R11: 0000000000000246 R12: 0000000040406469 R13: 0000000000000003 R14: 00007fff15c4fa20 R15: 00000000000000c7 Code: 00 00 00 4a c7 44 22 08 00 00 00 00 42 c7 44 22 10 00 00 00 00 48 81 c4 b8 00 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b 0f 0b <0f> 0b 31 c0 eb c0 4c 89 ef e8 9a 09 41 ff e9 1e fe ff ff 4c 89 RIP: drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: ffff880057a573f8 We can trivially relax this assumption, by searching the hole_stack for the scan result and warn instead if the driver called us without any result. Fixes: 3fa489dabea9 ("drm: Apply tight eviction scanning to color_adjust") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v4.11+ --- drivers/gpu/drm/drm_mm.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 186c4e90cc1c..89eef1bb4ddc 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -836,9 +836,24 @@ struct drm_mm_node *drm_mm_scan_color_evict(struct drm_mm_scan *scan) if (!mm->color_adjust) return NULL; - hole = list_first_entry(&mm->hole_stack, typeof(*hole), hole_stack); - hole_start = __drm_mm_hole_node_start(hole); - hole_end = hole_start + hole->hole_size; + /* + * The hole found during scanning should ideally be the first element + * in the hole_stack list, but due to side-effects in the driver it + * may not be. + */ + list_for_each_entry(hole, &mm->hole_stack, hole_stack) { + hole_start = __drm_mm_hole_node_start(hole); + hole_end = hole_start + hole->hole_size; + + if (hole_start <= scan->hit_start && + hole_end >= scan->hit_end) + break; + } + + /* We should only be called after we found the hole previously */ + DRM_MM_BUG_ON(&hole->hole_stack == &mm->hole_stack); + if (unlikely(&hole->hole_stack == &mm->hole_stack)) + return NULL; DRM_MM_BUG_ON(hole_start > scan->hit_start); DRM_MM_BUG_ON(hole_end < scan->hit_end); -- 2.16.1

7 years, 4 months

3
3
0 0

Re: Linux 3.16.54: suspend stops working.

by Takashi Iwai

On Mon, 19 Feb 2018 16:06:55 +0100, Andres Bertens wrote: > > Hi there! > > If of any interest to you, upgrading to linux 3.16.54 from 3.16.53, > suspend stops working. The same is for upgrading from linux 4.4.114 to > 4.4.115. > > Checking pm-utils log: > > /usr/lib/pm-utils/pm-functions: line 259: echo: write error: Resource > temporarily unavailable > > And line 259 is: > do_suspend() { echo -n "mem" >/sys/power/state; } > > > > Reverting patch: > commit 02cbce8576a31df8fca54aaec91ee081076bd79d > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Tue Jan 9 23:11:03 2018 +0100 > > ALSA: seq: Make ioctls race-free > > commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream. > > makes it work again! Just a blind shot: could you try the patch below instead? And, are you using some sequencer audio stuff? thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] ALSA: seq: Make ioctls race-free (revised) The ALSA sequencer ioctls have no protection against racy calls while the concurrent operations may lead to interfere with each other. As reported recently, for example, the concurrent calls of setting client pool with a combination of write calls may lead to either the unkillable dead-lock or UAF. As a slightly big hammer solution, this patch introduces the mutex to make each ioctl exclusive. Although this may reduce performance via parallel ioctl calls, usually it's not demanded for sequencer usages, hence it should be negligible. Reported-by: Luo Quan <a4651386(a)163.com> Reviewed-by: Kees Cook <keescook(a)chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/seq/seq_clientmgr.c | 7 ++++++- sound/core/seq/seq_clientmgr.h | 1 + 2 files changed, 7 insertions(+), 1 deletion(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create rwlock_init(&client->ports_lock); mutex_init(&client->ports_mutex); INIT_LIST_HEAD(&client->ports_list_head); + mutex_init(&client->ioctl_mutex); /* find free slot in the client table */ spin_lock_irqsave(&clients_lock, flags); @@ -2220,11 +2221,15 @@ static int snd_seq_do_ioctl(struct snd_s static long snd_seq_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct snd_seq_client *client = file->private_data; + long ret; if (snd_BUG_ON(!client)) return -ENXIO; - return snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_lock(&client->ioctl_mutex); + ret = snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_unlock(&client->ioctl_mutex); + return ret; } #ifdef CONFIG_COMPAT --- a/sound/core/seq/seq_clientmgr.h +++ b/sound/core/seq/seq_clientmgr.h @@ -59,6 +59,7 @@ struct snd_seq_client { struct list_head ports_list_head; rwlock_t ports_lock; struct mutex ports_mutex; + struct mutex ioctl_mutex; int convert32; /* convert 32->64bit */ /* output pool */

7 years, 4 months

1
0
0 0

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

by Paolo Bonzini

On 19/02/2018 14:35, David Woodhouse wrote: > On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote: >>> Hardware seems like a reasonable place to get the default value (cf. >>> the VMX capability MSRs). >> >> There are some differences: >> >> - a zero value for ARCH_CAPABILITIES should be safe, while a zero value >> for VMX capabilities doesn't really make sense. On the contrary, a >> nonzero value for ARCH_CAPABILITIES is not safe across live migration. > > Any VMM which is going to support live migration surely needs to pay at > least a small amount of attention to the features it exposes? Exposing > the ARCH_CAPABILITIES CPUID bit without actually looking at the > contents of the associated MSR which that bit advertises would be... a > little strange, would it not? I think what we should do is simply backport Tom Lendacky's series to 4.14 and 4.9 ASAP, and add ARCH_CAPABILITIES support there. Then the question of the default becomes moot, more or less. Paolo > I don't see why we care so much about the *default* value, in that > context.

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [STABLE 4.9.y PATCH 0/9] Backport of KVM Speculation Control support

by David Woodhouse

I've put together a linux-4.9.y branch at http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9… Most of it is fairly straightforward, apart from the IBPB on context switch for which Tim has already posted a candidate. I wanted some more review on my backports of the KVM bits though, including some extra historical patches I pulled in. Ashok Raj (1): KVM/x86: Add IBPB support David Hildenbrand (1): KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail David Matlack (1): KVM: nVMX: mark vmcs12 pages dirty on L2 exit Jim Mattson (1): KVM: nVMX: Eliminate vmcs02 pool KarimAllah Ahmed (3): KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL Paolo Bonzini (2): KVM: VMX: introduce alloc_loaded_vmcs KVM: VMX: make MSR bitmaps per-VCPU arch/x86/kvm/cpuid.c | 21 +- arch/x86/kvm/cpuid.h | 31 +++ arch/x86/kvm/svm.c | 116 ++++++++ arch/x86/kvm/vmx.c | 730 +++++++++++++++++++++++++++------------------------ arch/x86/kvm/x86.c | 1 + 5 files changed, 554 insertions(+), 345 deletions(-) -- 2.7.4

7 years, 4 months

5
19
0 0

Applied "ASoC: rt5651: Fix regcache sync errors on resume" to the asoc tree

by Mark Brown

The patch ASoC: rt5651: Fix regcache sync errors on resume has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 18 Feb 2018 23:01:44 +0100 Subject: [PATCH] ASoC: rt5651: Fix regcache sync errors on resume The ALC5651 does not like multi-write accesses, avoid them. This fixes: rt5651 i2c-10EC5651:00: Unable to sync registers 0x27-0x28. -121 Errors on resume (and all registers after the registers in the error not being synced). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/codecs/rt5651.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c index 831b297978a4..45a73049cf64 100644 --- a/sound/soc/codecs/rt5651.c +++ b/sound/soc/codecs/rt5651.c @@ -1722,6 +1722,7 @@ static const struct regmap_config rt5651_regmap = { .num_reg_defaults = ARRAY_SIZE(rt5651_reg), .ranges = rt5651_ranges, .num_ranges = ARRAY_SIZE(rt5651_ranges), + .use_single_rw = true, }; #if defined(CONFIG_OF) -- 2.16.1

7 years, 4 months

1
0
0 0

[PATCH v3 3/3] x86/xen: add pvh specific rsdp address retrieval function

by Juergen Gross

Add pvh_get_root_pointer() for Xen PVH guests to communicate the address of the RSDP table given to the kernel via Xen start info. This makes the kernel boot again in PVH mode after on recent Xen the RSDP was moved to higher addresses. So up to that change it was pure luck that the legacy method to locate the RSDP was working when running as PVH mode. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/xen/enlighten_pvh.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 436c4f003e17..aa1c6a6831a9 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -6,6 +6,7 @@ #include <asm/io_apic.h> #include <asm/hypervisor.h> #include <asm/e820/api.h> +#include <asm/x86_init.h> #include <asm/xen/interface.h> #include <asm/xen/hypercall.h> @@ -16,15 +17,20 @@ /* * PVH variables. * - * xen_pvh and pvh_bootparams need to live in data segment since they - * are used after startup_{32|64}, which clear .bss, are invoked. + * xen_pvh pvh_bootparams and pvh_start_info need to live in data segment + * since they are used after startup_{32|64}, which clear .bss, are invoked. */ bool xen_pvh __attribute__((section(".data"))) = 0; struct boot_params pvh_bootparams __attribute__((section(".data"))); +struct hvm_start_info pvh_start_info __attribute__((section(".data"))); -struct hvm_start_info pvh_start_info; unsigned int pvh_start_info_sz = sizeof(pvh_start_info); +static u64 pvh_get_root_pointer(void) +{ + return pvh_start_info.rsdp_paddr; +} + static void __init init_pvh_bootparams(void) { struct xen_memory_map memmap; @@ -71,6 +77,8 @@ static void __init init_pvh_bootparams(void) */ pvh_bootparams.hdr.version = 0x212; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ + + x86_init.acpi.get_root_pointer = pvh_get_root_pointer; } /* -- 2.13.6

7 years, 4 months

1
0
0 0

[PATCH v3 2/3] x86/acpi: add a new x86_init_acpi structure to x86_init_ops

by Juergen Gross

Add a new struct x86_init_acpi to x86_init_ops. For now it contains only one init function to get the RSDP table address. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/include/asm/acpi.h | 7 +++++++ arch/x86/include/asm/x86_init.h | 9 +++++++++ arch/x86/kernel/x86_init.c | 5 +++++ 3 files changed, 21 insertions(+) diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index 11881726ed37..6609dd7289b5 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -31,6 +31,7 @@ #include <asm/mmu.h> #include <asm/mpspec.h> #include <asm/realmode.h> +#include <asm/x86_init.h> #ifdef CONFIG_ACPI_APEI # include <asm/pgtable_types.h> @@ -133,6 +134,12 @@ static inline bool acpi_has_cpu_in_madt(void) return !!acpi_lapic; } +#define ACPI_HAVE_ARCH_GET_ROOT_POINTER +static inline u64 acpi_arch_get_root_pointer(void) +{ + return x86_init.acpi.get_root_pointer(); +} + #else /* !CONFIG_ACPI */ #define acpi_lapic 0 diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index fc2f082ac635..2e2c34d2bb00 100644 --- a/arch/x86/include/asm/x86_init.h +++ b/arch/x86/include/asm/x86_init.h @@ -131,6 +131,14 @@ struct x86_hyper_init { }; /** + * struct x86_init_acpi - x86 ACPI init functions + * @get_root_pointer: get RSDP address + */ +struct x86_init_acpi { + u64 (*get_root_pointer)(void); +}; + +/** * struct x86_init_ops - functions for platform specific setup * */ @@ -144,6 +152,7 @@ struct x86_init_ops { struct x86_init_iommu iommu; struct x86_init_pci pci; struct x86_hyper_init hyper; + struct x86_init_acpi acpi; }; /** diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c index 1151ccd72ce9..9e4e994a4836 100644 --- a/arch/x86/kernel/x86_init.c +++ b/arch/x86/kernel/x86_init.c @@ -30,6 +30,7 @@ int __init iommu_init_noop(void) { return 0; } void iommu_shutdown_noop(void) { } bool __init bool_x86_init_noop(void) { return false; } void x86_op_int_noop(int cpu) { } +u64 u64_x86_init_noop(void) { return 0; } /* * The platform setup functions are preset with the default functions @@ -91,6 +92,10 @@ struct x86_init_ops x86_init __initdata = { .x2apic_available = bool_x86_init_noop, .init_mem_mapping = x86_init_noop, }, + + .acpi = { + .get_root_pointer = u64_x86_init_noop, + }, }; struct x86_cpuinit_ops x86_cpuinit = { -- 2.13.6

7 years, 4 months

1
0
0 0

[PATCH v3 1/3] acpi: introduce acpi_arch_get_root_pointer() for getting rsdp address

by Juergen Gross

Add an architecture specific function to get the address of the RSDP table. Per default it will just return 0 indicating falling back to the current mechanism. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- drivers/acpi/osl.c | 5 ++++- include/linux/acpi.h | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 3bb46cb24a99..ff812243bac3 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -189,12 +189,15 @@ early_param("acpi_rsdp", setup_acpi_rsdp); acpi_physical_address __init acpi_os_get_root_pointer(void) { - acpi_physical_address pa = 0; + acpi_physical_address pa; #ifdef CONFIG_KEXEC if (acpi_rsdp) return acpi_rsdp; #endif + pa = acpi_arch_get_root_pointer(); + if (pa) + return pa; if (efi_enabled(EFI_CONFIG_TABLES)) { if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 968173ec2726..15bfb15c2fa5 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -623,6 +623,13 @@ bool acpi_gtdt_c3stop(int type); int acpi_arch_timer_mem_init(struct arch_timer_mem *timer_mem, int *timer_count); #endif +#ifndef ACPI_HAVE_ARCH_GET_ROOT_POINTER +static inline u64 acpi_arch_get_root_pointer(void) +{ + return 0; +} +#endif + #else /* !CONFIG_ACPI */ #define acpi_disabled 1 -- 2.13.6

7 years, 4 months

1
0
0 0

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

by Arnd Bergmann

On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen(a)linux.intel.com> wrote: > On 12/06/2017 07:03 AM, Arnd Bergmann wrote: >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd(a)arndb.de> wrote: >> >>> This changes the type to u64 in the architecture-independent dummy, >>> and to pteval_t in the x86 specific portion that is used when KAISER >>> is enabled, ensuring that the flags can always fit. Unfortunately, >>> pteval_t is not provided by most other architectures, so we are >>> a little bit inconsistent here. >> >> I ran into a new regression with my patch applied, after doing more randconfig >> builds: >> >> In file included from /git/arm-soc/include/linux/kaiser.h:5, >> from /git/arm-soc/arch/x86/events/intel/ds.c:4: >> arch/x86/include/asm/kaiser.h:34:10: error: unknown type name >> 'pteval_t'; did you mean 'dev_t'? >> >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h. > > Hi Arnd, > > Are you hitting this in -next? > > The newest version of this code has a single kpti_init() function that > shouldn't have any of these problems. Coming back to an old thread... I did some randconfig testing on 4.9.80, and now I see the same problem there, since that version uses the KAISER patches rather than PTI: /git/arm-soc/arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct': /git/arm-soc/arch/x86/include/asm/pgtable_types.h:208:24: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define __PAGE_KERNEL (__PAGE_KERNEL_EXEC | _PAGE_NX) ^ /git/arm-soc/arch/x86/kernel/ldt.c:81:6: note: in expansion of macro '__PAGE_KERNEL' __PAGE_KERNEL); ^~~~~~~~~~~~~ I also saw another warning: /git/arm-soc/arch/x86/mm/kaiser.c: In function 'kaiser_init': /git/arm-soc/arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot' undeclared (first use in this function); did you mean 'massage_pgprot'? I can send this as proper patches for inclusion in 4.9-stable, unless someone has a better idea or finds a problem Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> diff --git a/include/linux/kaiser.h b/include/linux/kaiser.h index 58c55b1589d0..b56c19010480 100644 --- a/include/linux/kaiser.h +++ b/include/linux/kaiser.h @@ -32,7 +32,7 @@ static inline void kaiser_init(void) { } static inline int kaiser_add_mapping(unsigned long addr, - unsigned long size, unsigned long flags) + unsigned long size, u64 flags) { return 0; } --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,7 +13,6 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); -extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) @@ -23,4 +22,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) static inline bool vsyscall_enabled(void) { return false; } #endif +extern unsigned long vsyscall_pgprot; + #endif /* _ASM_X86_VSYSCALL_H */ Arnd

7 years, 4 months

2
5
0 0

[PATCH v4] extcon: int3496: process id-pin first so that we start with the right status

by Hans de Goede

Some other drivers may be waiting for our extcon to show-up, exiting their probe methods with -EPROBE_DEFER until we show up. These drivers will typically get the cable state directly after getting the extcon, this commit changes the int3496 code to wait for the initial processing of the id-pin to complete before exiting probe() with 0, which will cause devices waiting on the defered probe to get reprobed. This fixes a race where the initial work might still be running while other drivers were already calling extcon_get_state(). Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: -Add Fixes tag Changes in v3: -Fix oops on probe by scheduling the work too early Changes in v4: -Ugh sorry about this, but we cannot call extcon_set_state() before extcon_dev_register() at all because before registration the cable array is not yet allocated. Instead wait for the initial processing of the id-pin to complete before exiting probe(). --- drivers/extcon/extcon-intel-int3496.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c index c8691b5a9cb0..191e99f06a9a 100644 --- a/drivers/extcon/extcon-intel-int3496.c +++ b/drivers/extcon/extcon-intel-int3496.c @@ -153,8 +153,9 @@ static int int3496_probe(struct platform_device *pdev) return ret; } - /* queue initial processing of id-pin */ + /* process id-pin so that we start with the right status */ queue_delayed_work(system_wq, &data->work, 0); + flush_delayed_work(&data->work); platform_set_drvdata(pdev, data); -- 2.14.3

7 years, 4 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror