Re: [PATCH] mm, kasan: don't poison boot memory

On Tue, Feb 23, 2021 at 04:16:44PM -0500, George Kennedy wrote: > > > On 2/23/2021 3:09 PM, Mike Rapoport wrote: > > On Tue, Feb 23, 2021 at 01:05:05PM -0500, George Kennedy wrote: > > > On 2/23/2021 10:47 AM, Mike Rapoport wrote: > > > > > > It now crashes here: > > > > > > [    0.051019] ACPI

[PATCH v2] x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()

Background == EPC section is covered by one or more SRAT entries that are associated with one and only one PXM (NUMA node). The motivation behind this patch is to provide basic elements of building allocation scheme based on this premise. It does not try to fully address NUMA. For instanc

Re: [PATCH] x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()

This doesn't look like it addresses all of the suggestions that I made two days ago. Is that coming in v3?

[BUG] Race between policy reload sidtab conversion and live conversion

I'm seeing a race during policy load while the "regular" sidtab conversion is happening and a live conversion starts to take place in sidtab_context_to_sid(). We have an initial policy that's loaded by systemd ~0.6s into boot and then another policy gets loaded ~2-3s into boot. That second policy

[PATCH 0/6] firmware: qcom_scm: Fix SMCCC detection on sc7180

The firmware that ships on sc7180 devices doesn't implement the smc call that tells the kernel what calling convention is available. Instead, the firmware returns an error code indicating the call isn't implemented (that makes my head spin). To smooth things out here let's implement a small workaro

[PATCH 2/6] firmware: qcom_scm: Reduce locking section for __get_convention()

We shouldn't need to hold this spinlock here around the entire SCM call into the firmware and back. Instead, we should be able to query the firmware, potentially in parallel with other CPUs making the same convention detection firmware call, and then grab the lock to update the calling convention d

[PATCH 3/6] firmware: qcom_scm: Workaround lack of "is available" call on SC7180

Some SC7180 firmwares don't implement the QCOM_SCM_INFO_IS_CALL_AVAIL API, so we can't probe the calling convention. We detect the legacy calling convention on these firmwares, because the availability call always fails and legacy is the fallback. This leads to problems where the rmtfs driver fails

[PATCH 5/6] firmware: qcom_scm: Fix kernel-doc function names to match

These functions were renamed but the kernel doc didn't follow along. Fix it. Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd

[PATCH 4/6] firmware: qcom_scm: Suppress sysfs bind attributes

We don't want userspace ejecting this driver at runtime. Various other drivers call into this code because it provides the mechanism to communicate with the secure world on qcom SoCs. It should probe once and be present forever after that. Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold

[PATCH 1/6] firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool

Make __qcom_scm_is_call_available() return bool instead of int. The function has "is" in the name, so it should return a bool to indicate the truth of the call being available. Unfortunately, it can return a number < 0 which also looks "true", but not all callers expect that and thus they think a c

[PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM

These scm calls are never used outside of legacy ARMv7 based platforms. That's because PSCI, mandated on arm64, implements them for modern SoCs via the PSCI spec. Let's move them to the legacy file and only compile the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide stubs and fail

Re: [PATCH] mm, kasan: don't poison boot memory

On 2/23/2021 4:32 PM, Mike Rapoport wrote: diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 7bdc0239a943..c118dd54a747 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1551,6 +1551,7 @@ void __init acpi_boot_table_init(void) if

Re: [PATCH] drm/panel: kd35t133: allow using non-continuous dsi clock

On Sat, 6 Feb 2021 14:50:20 +0100, Heiko Stuebner wrote: > The panel is able to work when dsi clock is non-continuous, thus > the system power consumption can be reduced using such feature. > > Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags. > > Also the flag actually becomes necessary a

Re: linux-next: build warning in Linus' tree

Hi all, On Thu, 18 Feb 2021 22:47:57 + "Ernst, Justin" wrote: > > Hi, > We made a special effort to squash the unexpected indentation warnings in > c159376490ee > (https://lore.kernel.org/lkml/20201130214304.369348-1-justin.er...@hpe.com/), > so I was surprised to see this again. > Commit:

Re: [BUG] Race between policy reload sidtab conversion and live conversion

On 2021-02-23 15:43:48, Tyler Hicks wrote: > I'm seeing a race during policy load while the "regular" sidtab > conversion is happening and a live conversion starts to take place in > sidtab_context_to_sid(). > > We have an initial policy that's loaded by systemd ~0.6s into boot and > then another

[PATCH] dt-bindings: display: mediatek,dpi: Convert to use graph schema

Update the mediatek,dpi binding to use the graph schema. Missed this one from the mass conversion since it's not part of drm-misc. Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Matthias Brugger Cc: CK Hu Cc: Jitao shi Cc: dri-de...@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Signed

Re: [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO

On Tuesday, February 23, 2021 4:26:44 PM EST Arnd Bergmann wrote: > On Tue, Feb 23, 2021 at 9:46 PM Julian Braha wrote: > > > > I have other similar patches that I intend to submit. What should I do, > > going forward? Should I use "depends on CRYPTO" for cases like these? > > Should I resubmit th

[PATCH] hugetlb: fix uninitialized subpool pointer

Gerald Schaefer reported a panic on s390 in hugepage_subpool_put_pages() with linux-next 5.12.0-20210222. Call trace: hugepage_subpool_put_pages.part.0+0x2c/0x138 __free_huge_page+0xce/0x310 alloc_pool_huge_page+0x102/0x120 set_max_huge_pages+0x13e/0x350 hugetlb_sysctl_handler_common+0xd8

Re: linux-next: build warnings after merge of the origin tree

Hi all, On Fri, 19 Feb 2021 17:01:13 +0100 Paolo Bonzini wrote: > > On 19/02/21 16:33, Vitaly Kuznetsov wrote: > > Stephen Rothwell writes: > >> > >> Building Linus' tree, today's linux-next build (htmldocs) produced > >> these warnings: > >> > >> Documentation/virt/kvm/api.rst:4537: WARNING: Un

linux-next: manual merge of the risc-v tree with Linus' tree

Hi all, Today's linux-next merge of the risc-v tree got a conflict in: drivers/soc/Makefile between commit: 89d4f98ae90d ("ARM: remove zte zx platform") from Linus' tree and commits: 08734e0581a5 ("riscv: Use vendor name for K210 SoC support") e134d426e1a3 ("soc: canaan: Sort the Make

RE: [PATCH 1/1] scsi: storvsc: Enable scatterlist entry lengths > 4Kbytes

From: Vitaly Kuznetsov Sent: Tuesday, February 23, 2021 6:30 AM > > Michael Kelley writes: > > > storvsc currently sets .dma_boundary to limit scatterlist entries > > to 4 Kbytes, which is less efficient with huge pages that offer > > large chunks of contiguous physical memory. Improve the alg

RE: linux-next: build warning in Linus' tree

> Hi all, > > On Thu, 18 Feb 2021 22:47:57 + "Ernst, Justin" > wrote: > > > > Hi, > > We made a special effort to squash the unexpected indentation warnings in > > c159376490ee > (https://lore.kernel.org/lkml/20201130214304.369348-1-justin.er...@hpe.com/), > so I was surprised to > see thi

Re: [GIT PULL] idmapped mounts for v5.12

The pull request you sent on Sat, 13 Feb 2021 14:00:42 +0100: > g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux > tags/idmapped-mounts-merged-v5.12 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7d6beb71da3cc033649d641e1e608713b8220290 Thank you! --

Re: [GIT PULL] percpu changes for v5.12-rc1

The pull request you sent on Tue, 23 Feb 2021 03:27:41 +: > git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu.git for-5.12 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/aa8e3291729fd885351af0b077330721d4bf5db9 Thank you! -- Deet-doot-dot, I am a bot.

Re: [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO

On Tue, Feb 23, 2021 at 10:54 PM Julian Braha wrote: > On Tuesday, February 23, 2021 4:26:44 PM EST Arnd Bergmann wrote: > > On Tue, Feb 23, 2021 at 9:46 PM Julian Braha wrote: > > > > > > I have other similar patches that I intend to submit. What should I do, > > > going forward? Should I use "d

Re: [GIT PULL] GFS2 changes for 5.12

The pull request you sent on Tue, 23 Feb 2021 20:34:29 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git > tags/gfs2-for-5.12 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f6e1e1d1e149802ed4062fa514c2d184d30aacdf Thank you! -- Deet-doot-

[PATCH] arm64: dts: mediatek: fix reset GPIO level on pumpkin

The tca6416 chip is active low. Fix the reset-gpios value. Fixes: e2a8fa1e0faa ("arm64: dts: mediatek: fix tca6416 reset GPIOs in pumpkin") Signed-off-by: Fabien Parent --- arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/a

[git pull] Input updates for v5.12-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Mostly existing driver fixes plus a new driver for game controllers directly connected to Nintendo 64, and an enhancement for keyboards driven by

Re: [PATCH 1/2] dt-bindings: mediatek: mmsys: add mt1867 binding

Hi Matthias, Pinging you in case you didn't see @Chun-Kuang Hu's question for you. Thanks, Best regards, Fabien On Sun, Jan 10, 2021 at 12:18 AM Chun-Kuang Hu wrote: > > Hi, Matthias: > > Rob Herring 於 2020年10月31日 週六 上午3:17寫道： > > > > On Tue, 27 Oct 2020 17:06:29 +0100, Fabien Parent wrote: >

Re: [PATCH] recordmcount: use w8 to read relp->r_info in arm64_is_fake_mcount

On Mon, 22 Feb 2021 15:50:19 + "chenjun (AM)" wrote: > Hi > > There is no problem when I use aarch64_be(gcc v10.2). Because gcc v10.2 use > __patchable_function_entries > instead of __mcount. I am not sure when the change happened. But you are still saying that this patch needs to be appli

Re: [PATCH RFC 0/4] Add support for synchronous signals on perf events

On Tue, 23 Feb 2021 at 21:27, Andy Lutomirski wrote: > > On Feb 23, 2021, at 6:34 AM, Marco Elver wrote: > > > > The perf subsystem today unifies various tracing and monitoring > > features, from both software and hardware. One benefit of the perf > > subsystem is automatically inheriting events

[PATCH v5 bpf-next 1/6] bpf: enable task local storage for tracing programs

To access per-task data, BPF programs usually creates a hash table with pid as the key. This is not ideal because: 1. The user need to estimate the proper size of the hash table, which may be inaccurate; 2. Big hash tables are slow; 3. To clean up the data properly during task terminations,

[PATCH v5 bpf-next 0/6] bpf: enable task local storage for tracing programs

This set enables task local storage for non-BPF_LSM programs. It is common for tracing BPF program to access per-task data. Currently, these data are stored in hash tables with pid as the key. In bcc/libbpftools [1], 9 out of 23 tools use such hash tables. However, hash table is not ideal for many

[PATCH v5 bpf-next 2/6] bpf: prevent deadlock from recursive bpf_task_storage_[get|delete]

BPF helpers bpf_task_storage_[get|delete] could hold two locks: bpf_local_storage_map_bucket->lock and bpf_local_storage->lock. Calling these helpers from fentry/fexit programs on functions in bpf_*_storage.c may cause deadlock on either locks. Prevent such deadlock with a per cpu counter, bpf_tas

[PATCH v5 bpf-next 5/6] bpf: runqslower: prefer using local vmlimux to generate vmlinux.h

Update the Makefile to prefer using $(O)/vmlinux, $(KBUILD_OUTPUT)/vmlinux (for selftests) or ../../../vmlinux. These two files should have latest definitions for vmlinux.h. Acked-by: Andrii Nakryiko Signed-off-by: Song Liu --- tools/bpf/runqslower/Makefile | 5 - 1 file changed, 4 insertio

[PATCH v5 bpf-next 4/6] selftests/bpf: test deadlock from recursive bpf_task_storage_[get|delete]

Add a test with recursive bpf_task_storage_[get|delete] from fentry programs on bpf_local_storage_lookup and bpf_local_storage_update. Without proper deadlock prevent mechanism, this test would cause deadlock. Signed-off-by: Song Liu --- .../bpf/prog_tests/task_local_storage.c | 23 ++

[PATCH v5 bpf-next 3/6] selftests/bpf: add non-BPF_LSM test for task local storage

Task local storage is enabled for tracing programs. Add two tests for task local storage without CONFIG_BPF_LSM. The first test stores a value in sys_enter and read it back in sys_exit. The second test checks whether the kernel allows allocating task local storage in exit_creds() (which it should

Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api

> > which is not cool because it will make the > > asynchronous effort a no-op. Is there a way we can include caller > > thread metadata(task_struct pointer?) when it enqueues the work so > > that the RT worker thread won't preempt the caller thread when that > > queued work gets scheduled? Probabl

[PATCH v5 bpf-next 6/6] bpf: runqslower: use task local storage

Replace hashtab with task local storage in runqslower. This improves the performance of these BPF programs. The following table summarizes average runtime of these programs, in nanoseconds: task-local hash-prealloc hash-no-prealloc handle__sched_wakeup 125

Re: [External] Re: [PATCH v16 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

On Tue, Feb 23, 2021 at 04:41:28PM +0100, Oscar Salvador wrote: > On Tue, Feb 23, 2021 at 11:50:05AM +0100, Oscar Salvador wrote: > > > CPU0: CPU1: > > > set_compound_page_dtor(HUGETLB_PAGE_DTOR); > > > memory_failure_hugetlb > > > get_hwp

[PATCH v2 0/2] scripts/gdb: clarify the platforms supporting lx_current and add arm64 support

lx_current depends on per_cpu current_task variable which exists on x86 only. so it actually works on x86 only. the 1st patch documents this clearly; the 2nd patch adds support for arm64. Barry Song (2): scripts/gdb: document lx_current is only supported by x86 scripts/gdb: add lx_current supp

[PATCH v2 1/2] scripts/gdb: document lx_current is only supported by x86

x86 is the only architecture which has per_cpu current_task: arch$ git grep current_task | grep -i per_cpu x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task); x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) cacheline_aligned = x86/kernel/cp

[PATCH v2 2/2] scripts/gdb: add lx_current support for arm64

arm64 uses SP_EL0 to save the current task_struct address. While running in EL0, SP_EL0 is clobbered by userspace. So if the upper bit is not 1 (not TTBR1), the current address is invalid. This patch checks the upper bit of SP_EL0, if the upper bit is 1, lx_current() of arm64 will return the derefr

[GIT PULL] clang-lto (part 2) for v5.12-rc1

Hi Linus, Please pull this Clang LTO x86 enablement series for v5.12-rc1. Full disclosure: while this has _not_ been in linux-next (since it initially looked like the objtool dependencies weren't going to make v5.12), it has been under daily build and runtime testing by Sami for quite some time. T

[PATCH] dt-bindings: arm64: dts: mediatek: Add mt8516-pumpkin board

Add binding documentation for the MT8516 Pumpkin board. Signed-off-by: Fabien Parent --- Documentation/devicetree/bindings/arm/mediatek.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediat

Re: [BUG] Race between policy reload sidtab conversion and live conversion

On 2021-02-23 15:50:56, Tyler Hicks wrote: > On 2021-02-23 15:43:48, Tyler Hicks wrote: > > I'm seeing a race during policy load while the "regular" sidtab > > conversion is happening and a live conversion starts to take place in > > sidtab_context_to_sid(). > > > > We have an initial policy that'

Re: [PATCH v3 5/6] platform/x86: Add intel_skl_int3472 driver

Hi Laurent On 23/02/2021 20:04, Laurent Pinchart wrote: > + > +/* > + * Here follows platform specific mapping information that we can pass to > + * the functions mapping resources to the sensors. Where the sensors have > + * a power enable pin defined in DSDT we need to provide a supply name so >

Re: [REGRESSION] "add a disk_uevent helper" breaks booting Andorid w/ dynamic partitions

On Mon, Feb 22, 2021 at 10:31 PM Christoph Hellwig wrote: > > Please try the patch below: > > --- > From 85943345b41ec04f5a9e92dfad85b0fb24e2d2eb Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig > Date: Tue, 23 Feb 2021 07:28:22 +0100 > Subject: block: don't skip empty device in in disk_uevent

Re: [REGRESSION] "add a disk_uevent helper" breaks booting Andorid w/ dynamic partitions

Applied, thanks. -- Jens Axboe

Re: general protection fault in xfrm_user_rcv_msg_compat

On Tue, Feb 23, 2021 at 6:55 AM syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > HEAD commit:a99163e9 Merge tag 'devicetree-for-5.12' of git://git.kern.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11a6fccad0 > kerne

Re: [PATCH] hugetlb: fix uninitialized subpool pointer

On Tue, Feb 23, 2021 at 01:55:44PM -0800, Mike Kravetz wrote: > Gerald Schaefer reported a panic on s390 in hugepage_subpool_put_pages() > with linux-next 5.12.0-20210222. > Call trace: > hugepage_subpool_put_pages.part.0+0x2c/0x138 > __free_huge_page+0xce/0x310 > alloc_pool_huge_page+0x102/0

Re: [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid

On Fri, Feb 19, 2021, David Edmondson wrote: > If the VM entry/exit controls for loading/saving MSR_EFER are either > not available (an older processor or explicitly disabled) or not > used (host and guest values are the same), reading GUEST_IA32_EFER > from the VMCS returns an inaccurate value. >

[PATCH v2 1/1] scsi: storvsc: Enable scatterlist entry lengths > 4Kbytes

storvsc currently sets .dma_boundary to limit scatterlist entries to 4 Kbytes, which is less efficient with huge pages that offer large chunks of contiguous physical memory. Improve the algorithm for creating the Hyper-V guest physical address PFN array so that scatterlist entries with lengths > 4K

Re: [PATCH v2 03/10] mm: don't pass "enum lru_list" to lru list addition functions

On Tue, 26 Jan 2021 15:14:38 -0700 Yu Zhao wrote: > On Tue, Jan 26, 2021 at 10:01:11PM +, Matthew Wilcox wrote: > > On Fri, Jan 22, 2021 at 03:05:53PM -0700, Yu Zhao wrote: > > > +++ b/mm/swap.c > > > @@ -231,7 +231,7 @@ static void pagevec_move_tail_fn(struct page *page, > > > struct lruvec

Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup

On Mon, Feb 22, 2021 at 11:22 PM Christoph Hellwig wrote: > > On Tue, Feb 23, 2021 at 08:04:08AM +0100, Christoph Hellwig wrote: > > The problem is that the blk-crypto fallback code calls bio_split > > with a NULL bioset. That was aready broken before, as the mempool > > needed to guarantee forwa

Re: [PATCH] hugetlb: fix uninitialized subpool pointer

On 2/23/21 2:45 PM, Oscar Salvador wrote: > On Tue, Feb 23, 2021 at 01:55:44PM -0800, Mike Kravetz wrote: >> Gerald Schaefer reported a panic on s390 in hugepage_subpool_put_pages() >> with linux-next 5.12.0-20210222. >> Call trace: >> hugepage_subpool_put_pages.part.0+0x2c/0x138 >> __free_huge

Re: [PATCH] hugetlb: fix uninitialized subpool pointer

On 2021-02-23 23:55, Mike Kravetz wrote: Yes, that is the more common case where the once active hugetlb page will be simply added to the free list via enqueue_huge_page(). This path does not go through prep_new_huge_page. Right, I see. Thanks -- Oscar Salvador SUSE L3

Re: [PATCH v4 00/16] Overhaul multi-page lookups for THP

Do you feel this patchset is ready to merge up? https://lore.kernel.org/linux-mm/f6914405b49d9...@google.com/ was addressed by 0060ef3b4e6dd ("mm: support THPs in zero_user_segments"), yes? "mm/truncate,shmem: Handle truncates that split THPs" and "mm/filemap: Return only head pages f

Re: [PATCH v2 2/3] KVM: x86: dump_vmcs should not conflate EFER and PAT presence in VMCS

On Fri, Feb 19, 2021, David Edmondson wrote: > Show EFER and PAT based on their individual entry/exit controls. > > Signed-off-by: David Edmondson > --- > arch/x86/kvm/vmx/vmx.c | 19 ++- > 1 file changed, 10 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c

Re: [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid

On Tue, Feb 23, 2021 at 2:51 PM Sean Christopherson wrote: > > On Fri, Feb 19, 2021, David Edmondson wrote: > > If the VM entry/exit controls for loading/saving MSR_EFER are either > > not available (an older processor or explicitly disabled) or not > > used (host and guest values are the same), r

Re: general protection fault in vmx_vcpu_run (2)

syzbot has bisected this issue to: commit 167dcfc08b0b1f964ea95d410aa496fd78adf475 Author: Lorenzo Stoakes Date: Tue Dec 15 20:56:41 2020 + x86/mm: Increase pgt_buf size for 5-level page tables bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13fe3ea8d0 start commit:

Re: [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid

On Fri, Feb 19, 2021 at 6:46 AM David Edmondson wrote: > > If the VM entry/exit controls for loading/saving MSR_EFER are either > not available (an older processor or explicitly disabled) or not > used (host and guest values are the same), reading GUEST_IA32_EFER > from the VMCS returns an inaccur

Re: [PATCH 3/3] kbuild: Add a build check for missing gitignore entries

On Tue, Feb 23, 2021 at 10:14 AM Rob Herring wrote: > > Any non-phony targets need to be in gitignore. The normal way to check > this is doing an in-tree build and running git-status which is easy to > miss. Git provides an easy way to check whether a file is ignored with > git-check-ignore. Let's

Re: [PATCH] hugetlb: fix uninitialized subpool pointer

On 2/23/21 2:58 PM, Oscar Salvador wrote: > On 2021-02-23 23:55, Mike Kravetz wrote: >> Yes, that is the more common case where the once active hugetlb page >> will be simply added to the free list via enqueue_huge_page(). This >> path does not go through prep_new_huge_page. > > Right, I see. >

Why do kprobes and uprobes singlestep?

A while back, I let myself be convinced that kprobes genuinely need to single-step the kernel on occasion, and I decided that this sucked but I could live with it. it would, however, be Really Really Nice (tm) if we could have a rule that anyone running x86 Linux who single-steps the kernel (e.g.

Re: [PATCH v4 00/16] Overhaul multi-page lookups for THP

On Tue, Feb 23, 2021 at 02:58:36PM -0800, Andrew Morton wrote: > Do you feel this patchset is ready to merge up? I think so. > https://lore.kernel.org/linux-mm/f6914405b49d9...@google.com/ > was addressed by 0060ef3b4e6dd ("mm: support THPs in > zero_user_segments"), yes? Correct. >

[PATCH v6 01/16] remoteproc: Remove useless check in rproc_del()

Whether started at probe() time or thereafter from the command line, a remote processor needs to be shut down before the final cleanup phases can happen. Otherwise the system may be left in an unpredictable state where the remote processor is expecting the remoteproc core to be providing services

Re: [PATCH v2 1/2] ima: Free IMA measurement buffer on error

Hi all, > > > > > > > > This is not the correct way to submit patches for inclusion in the > > > > stable kernel tree. Please read: > > > > > > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > > > for how to do this properly. > > > > > > > Thanks for t

[PATCH v6 00/16] remoteproc: Add support for detaching a remote processor

Following the work done here [1], this set provides support for the remoteproc core to release resources associated with a remote processor without having to switch it off. That way a platform driver can be removed or the application processor power cycled while the remote processor is still operat

Re: [GIT PULL] More ACPI updates for v5.12-rc1

The pull request you sent on Tue, 23 Feb 2021 21:07:10 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > acpi-5.12-rc1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/628af43984feeecfe086ae885ab407bd0e7c329e Thank you! -- Deet-doot-dot,

Re: [GIT PULL] More power management updates for v5.12-rc1

The pull request you sent on Tue, 23 Feb 2021 21:05:26 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > pm-5.12-rc1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/005d3bd9e332faa976320cfaa2ae0637c8e94c51 Thank you! -- Deet-doot-dot, I

[PATCH v6 03/16] remoteproc: Add new RPROC_ATTACHED state

Add a new RPROC_ATTACHED state to take into account scenarios where the remoteproc core needs to attach to a remote processor that is booted by another entity. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen --- drivers/remoteproc/remoteproc_sysfs.c | 1 + in

Re: [PULL REQUEST]: dmaengine updates for 5.12-rc1

The pull request you sent on Tue, 23 Feb 2021 09:45:20 +0530: > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git > tags/dmaengine-5.12-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/143983e585073f18fbe3b7d30ed0f92cfc218cef Thank you! -- Deet-do

[PATCH v6 02/16] remoteproc: Rename function rproc_actuate()

Rename function rproc_actuate() to rproc_attach(). That way it is easy to understand that it does the opposite of rproc_detach(). Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen --- drivers/remoteproc/remoteproc_core.c | 8 1 file changed, 4 inserti

Re: [GIT PULL] HID for 5.12

The pull request you sent on Tue, 23 Feb 2021 11:53:51 +0100 (CET): > git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/69aea9d2843669387d100e353b5113d1adc9502f Thank you! -- Deet-doot-dot, I am a bot.

[PATCH v6 05/16] remoteproc: Add new get_loaded_rsc_table() to rproc_ops

Add a new get_loaded_rsc_table() operation in order to support scenarios where the remoteproc core has booted a remote processor and detaches from it. When re-attaching to the remote processor, the core needs to know where the resource table has been placed in memory. Signed-off-by: Mathieu Poiri

[PATCH v6 06/16] remoteproc: stm32: Move resource table setup to rproc_ops

Move the setting of the resource table installed by an external entity to rproc_ops::get_loaded_rsc_table(). This is to support scenarios where a remote processor has been started by the core but is detached at a later stage. To re-attach the remote processor, the address of the resource table ne

[PATCH v6 04/16] remoteproc: Properly represent the attached state

There is a need to know when a remote processor has been attached to rather than booted by the remoteproc core. In order to avoid manipulating two variables, i.e rproc::autonomous and rproc::state, get rid of the former and simply use the newly introduced RPROC_ATTACHED state. Signed-off-by: Math

Re: [git pull] Input updates for v5.12-rc0

The pull request you sent on Tue, 23 Feb 2021 14:19:12 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e0fbd25bb37e7bb1f5ad9c9f7e5fc89152aec87e Thank you! -- Deet-doot-dot, I am a bot. ht

[PATCH v6 08/16] remoteproc: Add new detach() remoteproc operation

Add an new detach() operation in order to support scenarios where the remoteproc core is going away but the remote processor is kept operating. This could be the case when the system is rebooted or when the platform driver is removed. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewe

Re: [GIT PULL] clang-lto (part 2) for v5.12-rc1

The pull request you sent on Tue, 23 Feb 2021 14:32:23 -0800: > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > tags/clang-lto-v5.12-rc1-part2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/414eece95b98b209cef0f49cfcac108fd00b8ced Thank you! -- Dee

Re: [GIT] Sparc

The pull request you sent on Tue, 23 Feb 2021 13:21:26 -0800 (PST): > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git > refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6dd580b93da8de5cab4ac1f24f343086318b664e Thank you! -- Deet-doot-d

Re: [PATCH 3/6] firmware: qcom_scm: Workaround lack of "is available" call on SC7180

On 2/23/2021 2:45 PM, Stephen Boyd wrote: Some SC7180 firmwares don't implement the QCOM_SCM_INFO_IS_CALL_AVAIL API, so we can't probe the calling convention. We detect the legacy calling convention on these firmwares, because the availability call always fails and legacy is the fallback. This le

[PATCH] staging: rt8192u: Move constant in comparison to the RHS

Fixes checkpatch warning: WARNING: Comparisons should place the constant on the right side of the test Signed-off-by: Simone Serra --- drivers/staging/rtl8192u/r8192U_wx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r8192U_wx.c b/drivers/staging

[PATCH v6 15/16] remoteproc: Properly deal with a detach request when attached

This patch introduces the capability to detach a remote processor that has been attached by the remoteproc core. For that to happen a rproc::ops::detach() operation needs to be available. Signed-off-by: Mathieu Poirier --- New for V6: - The RPROC_RUNNING -> RPROC_DETACHED transition is no longer

arch/x86/include/asm/syscall_wrapper.h:83:14: warning: no previous prototype for '__x64_sys_process_madvise'

-randconfig-r012-20210223 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecb8ac8b1f146915aa6b96449b66dd48984caacc git remote add linus https

[PATCH v6 10/16] remoteproc: Introduce function rproc_detach()

Introduce function rproc_detach() to enable the remoteproc core to release the resources associated with a remote processor without stopping its operation. Signed-off-by: Mathieu Poirier --- New for V6: - Checking for rproc->state has been removed. They have been moved to calling functions. -

[PATCH v6 09/16] remoteproc: Introduce function __rproc_detach()

Introduce function __rproc_detach() to perform the same kind of operation as rproc_stop(), but instead of switching off the remote processor using rproc->ops->stop(), it uses rproc->ops->detach(). That way it is possible for the core to release the resources associated with a remote processor whil

[PATCH v6 07/16] remoteproc: stm32: Move memory parsing to rproc_ops

From: Arnaud POULIQUEN Some actions such as memory resources reallocation are needed when trying to reattach a co-processor. Use the prepare() operation for these actions. Co-developed-by: Mathieu Poirier Signed-off-by: Mathieu Poirier Signed-off-by: Arnaud POULIQUEN --- drivers/remoteproc/r

RE: RE: [PATCH v22 3/4] scsi: ufs: Prepare HPB read for cached sub-region

> > +static int ufshpb_fill_ppn_from_page(struct ufshpb_lu *hpb, > > +struct ufshpb_map_ctx *mctx, int pos, > > +int len, u64 *ppn_buf) > > +{ > > + struct page *page; > > + int index, offset; > > + int copied

[PATCH v3] mm/mmap: Don't unlock VMAs in remap_file_pages()

Since this call uses MAP_FIXED, do_mmap() will munlock the necessary range. There is also an error in the loop test expression which will evaluate as false and the loop body has never execute. Signed-off-by: Liam R. Howlett Acked-by: Hugh Dickins --- mm/mmap.c | 18 +- 1 file c

linux-next: build warning after merge of the amdgpu tree

Hi all, After merging the amdgpu tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 'dm_set_vblank': drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5439:33: warning: unused variable 'd

[PATCH v6 16/16] remoteproc: Refactor rproc delete and cdev release path

Refactor function rproc_del() and rproc_cdev_release() to take into account the current state of the remote processor when choosing the state to transition to. Signed-off-by: Mathieu Poirier --- New for V6: - The RPROC_RUNNING -> RPROC_DETACHED transition is no longer permitted. to avoid dealin

Re: [PATCH 3/6] firmware: qcom_scm: Workaround lack of "is available" call on SC7180

Quoting Jeffrey Hugo (2021-02-23 15:38:38) > On 2/23/2021 2:45 PM, Stephen Boyd wrote: > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > > index 21e07a464bd9..9ac84b5d6ce0 100644 > > --- a/drivers/firmware/qcom_scm.c > > +++ b/drivers/firmware/qcom_scm.c > > @@ -144,6 +14

Re: [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid

On Tue, Feb 23, 2021, Jim Mattson wrote: > On Tue, Feb 23, 2021 at 2:51 PM Sean Christopherson wrote: > > > > On Fri, Feb 19, 2021, David Edmondson wrote: > > > If the VM entry/exit controls for loading/saving MSR_EFER are either > > > not available (an older processor or explicitly disabled) or n

Re: [PATCH] cert: Add kconfig dependency for validate_trust

Eric Snowberg wrote: > The kernel test robot reports when building with Kconfig > CONFIG_INTEGRITY_PLATFORM_KEYRING defined and > CONFIG_SYSTEM_DATA_VERIFICATION undefined: > > ld.lld: error: undefined symbol: pkcs7_validate_trust > referenced by blacklist.c:128 (certs/blacklist.c:128) >

[PATCH v6 14/16] remoteproc: Properly deal with a stop request when attached

Allow a remote processor that was started by another entity to be switched off by the remoteproc core. For that to happen a rproc::ops::stop() operation needs to be available. Signed-off-by: Mathieu Poirier --- New for V6: - Removed state check in rproc_shutdown() as it is already done in in c

[PATCH v6 13/16] remoteproc: Properly deal with a start request when attached

This patch takes into account scenarios where a remote processor has been attached to when receiving a "start" command from sysfs. As with the case with the running state, the command can't be carried out if the remote processor is already in operation. Signed-off-by: Mathieu Poirier Reviewed-by

[PATCH v6 12/16] remoteproc: Properly deal with a kernel panic when attached

The panic handler operation of registered remote processors should also be called when remote processors have been attached to. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen --- drivers/remoteproc/remoteproc_core.c | 6 +- 1 file changed, 5 insertions(+

[PATCH v6 11/16] remoteproc: Properly deal with the resource table when attached

If it is possible to detach the remote processor, keep an untouched copy of the resource table. That way we can start from the same resource table without having to worry about original values or what elements the startup code has changed when re-attaching to the remote processor. Signed-off-by:

<    3   4   5   6   7   8   9   10   11   >