* Reshetova, Elena wrote:
> > > Yes, meaning is different, see above.
> >
> > So that's rather convoluted:
> >
> > atomic64_inc_not_zero(): returns 1 on successful increase, 0 on
> > failure
> > sgx_inc_usage_count(): returns 0 on successful increase, 1 on
> > failure
> >
* Elena Reshetova wrote:
> @@ -19,10 +19,15 @@ static int sgx_open(struct inode *inode, struct file
> *file)
> struct sgx_encl *encl;
> int ret;
>
> + ret = sgx_inc_usage_count();
> + if (ret)
> + return -EBUSY;
So if sgx_inc_usage_count() returns nonzero, it
* Reshetova, Elena wrote:
>
> > * Elena Reshetova wrote:
> >
> > > @@ -19,10 +19,15 @@ static int sgx_open(struct inode *inode, struct file
> > *file)
> > > struct sgx_encl *encl;
> > > int ret;
> > >
> > > + ret = sgx_inc_usage_count();
> > > + if (ret)
> > > + return -EBUSY;
>
* Elena Reshetova wrote:
> Add a flag indicating whenever ENCLS[EUPDATESVN] SGX instruction
> is supported. This will be used by SGX driver to perform CPU
> SVN updates.
>
> Signed-off-by: Elena Reshetova
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/kernel/cpu/scattered
* Sukrut Heroorkar wrote:
> Fixes a small grammatical error in the print message.
No it doesn't.
> signed-off-by: Sukrut Heroorkar
> ---
> tools/testing/selftests/x86/ioperm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/x86/ioperm.c
> b
* Dave Hansen wrote:
> Thanks for sending this, Andrew!
>
> I think I'll probably add a slightly shorter summary:
>
> tl;dr: SGX page reclaim touches the page to copy its contents to
> secondary storage. SGX instructions do not gracefully handle machine
> checks. Despite this, the existing SG
* Malaya Kumar Rout wrote:
> Exception branch returns without closing
> the file descriptors 'file_fd' and 'fd'
>
> Signed-off-by: Malaya Kumar Rout
> ---
> tools/testing/selftests/x86/lam.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Why have you ignored this request I
* Malaya Kumar Rout wrote:
> Exception branch returns without closing
> the file descriptors 'file_fd' and 'fd'
>
> Signed-off-by: Malaya Kumar Rout
> ---
> tools/testing/selftests/x86/lam.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/self
* Malaya Kumar Rout wrote:
> @@ -1189,9 +1191,10 @@ void *allocate_dsa_pasid(void)
>
> wq = mmap(NULL, 0x1000, PROT_WRITE,
> MAP_SHARED | MAP_POPULATE, fd, 0);
> - if (wq == MAP_FAILED)
> + if (wq == MAP_FAILED){
> + close(fd);
>
* Peter Zijlstra wrote:
> On Mon, Mar 24, 2025 at 06:17:50PM +0530, Malaya Kumar Rout wrote:
> > Static Analyis for bench_htab_mem.c with cppcheck:error
> > tools/testing/selftests/x86/lam.c:585:3:
> > error: Resource leak: file_fd [resourceLeak]
> > tools/testing/selftests/x86/lam.c:593:3:
> >
and have spent some time researching where
my /dev/sgx_enclave file went on SGX-enabled hardware.
Related links:
https://github.com/intel/linux-sgx/issues/837
https://patchwork.kernel.org/project/platform-driver-x86/patch/20180827185507.17087-3-jarkko.sakki...@linux.intel.com/
[
* Chang S. Bae wrote:
> Hi all,
>
> This series proposes a rework of xstate-related tests to improve
> maintainability and expand test coverage.
>
> == Motivation: Addressing Missing and New XSTATE Tests ==
>
> With the introduction of AMX, a new test suite [1] was created to verify
> dynami
* Mike Rapoport wrote:
> +/**
> + * enum execmem_type - types of executable memory ranges
> + *
> + * There are several subsystems that allocate executable memory.
> + * Architectures define different restrictions on placement,
> + * permissions, alignment and other parameters for memory that c
* Mike Rapoport wrote:
> for (s = start; s < end; s++) {
> void *addr = (void *)s + *s;
> + void *wr_addr = addr + module_writable_offset(mod, addr);
So instead of repeating this pattern in a dozen of places, why not use a
simpler method:
void
* Jonathan Haslam wrote:
> Active uprobes are stored in an RB tree and accesses to this tree are
> dominated by read operations. Currently these accesses are serialized by
> a spinlock but this leads to enormous contention when large numbers of
> threads are executing active probes.
>
> This p
* David Laight wrote:
> per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number.
> This requires the cpu number be 64bit.
> However the value is osq_lock() comes from a 32bit xchg() and there
> isn't a way of telling gcc the high bits are zero (they are) so
> there will always be an instru
* David Laight wrote:
> When osq_lock() returns false or osq_unlock() returns static
> analysis shows that node->next should always be NULL.
> This means that it isn't necessary to explicitly set it to NULL
> prior to atomic_xchg(&lock->tail, curr) on extry to osq_lock().
>
> Just in case ther
* Waiman Long wrote:
> On 12/29/23 15:57, David Laight wrote:
> > this_cpu_ptr() is rather more expensive than raw_cpu_read() since
> > the latter can use an 'offset from register' (%gs for x86-84).
> >
> > Add a 'self' field to 'struct optimistic_spin_node' that can be
> > read with raw_cpu_r
* Hans de Goede wrote:
> >> Which IMHO is much more readable then what has landed now. But since
> >> v2 has already landed I guess the best thing is just to stick with
> >> what we have upstream now...
> >
> > Well, how about we do a delta patch with all the changes you suggested?
> > I'm
instead of consulting the input
> struct cper_sec_mem_err record. So change to rely on hardware whenever
> support is available.
>
> Link:
> https://lore.kernel.org/r/7ed50fd8-521e-cade-77b1-738b8bfb8...@oracle.com
>
> Reviewed-by: Dan Williams
> Reviewed-by: Ing
lidation_bits & CPER_MEM_VALID_PA_MASK)
> + lsb = find_first_bit((const unsigned long *)
> + &mem_err->physical_addr_mask, PAGE_SHIFT);
I think we can write this in a shorter form and in a single line:
lsb = find_first_bit((void *)&a
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: c2209ea55612efac75de0a58ef5f7394fae7fa0f
Gitweb:
https://git.kernel.org/tip/c2209ea55612efac75de0a58ef5f7394fae7fa0f
Author:Ingo Molnar
AuthorDate:Tue, 20 Apr 2021 09:47:42 +02:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 27743f01e391ee1d80e3be2a09237507b965f91b
Gitweb:
https://git.kernel.org/tip/27743f01e391ee1d80e3be2a09237507b965f91b
Author:Ingo Molnar
AuthorDate:Tue, 20 Apr 2021 10:03:02 +02:00
* Paul E. McKenney wrote:
> Hello, Ingo!
>
> This pull request contains changes for RCU, KCSAN, and LKMM. You can
> pull the entire group using branch for-mingo. Or, if you prefer, you
> can pull them separately, using for-mingo-rcu to pull the RCU changes,
> for-mingo-kcsan to pull the KCSA
Linus,
Please pull the latest locking/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2021-04-11
# HEAD: 6d48b7912cc72275dc7c59ff961c8bac7ef66a92 lockdep: Address clang
-Wformat warning printing for %hd
Two minor fixes: one for a Clang warn
with new GCC packages that turn on
-fcf-protection
- Fix SME memory encryption PTE encoding bug - AFAICT the code worked on
4K page sizes (level 1) but had the wrong shift at higher page level orders
(level 2 and higher).
Signed-off-by: Ingo Molnar
Thanks,
Ingo
Linus,
Please pull the latest locking/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2021-03-28
# HEAD: 291da9d4a9eb3a1cb0610b7f4480f5b52b1825e7 locking/mutex: Fix non
debug version of mutex_lock_io_nested()
Fix the non-debug mutex_lock_io
* Marco Elver wrote:
> > Yeah, so why cannot we allocate enough space from the signal
> > handler user-space stack and put the attr there, and point to it
> > from sig_info?
> >
> > The idea would be to create a stable, per-signal snapshot of
> > whatever the perf_attr state is at the moment
* Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 3:05 PM Marco Elver wrote:
> >
> > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > >
> > > One last try, I'll leave it alone now, I promise :-)
> >
> > This looks like it does what you suggested, thanks! :-)
> >
> > I'll still need to t
* Bhaskar Chowdhury wrote:
> s/preferrable/preferable/
> s/serivced/serviced/
> s/distributon/distribution/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/x86/kernel/apic/apic.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/a
* Steven Rostedt wrote:
> On Tue, 23 Mar 2021 12:11:50 +0100
> Ingo Molnar wrote:
>
> > -v2 attached - I preemptively added your Reviewed-by as well, if
> > that's fine. :-)
> >
> > Thanks,
> >
> > Ingo
> >
> > ===
Fix ~59 single-word typos in the tracing code comments, and fix
the grammar in a handful of places.
Signed-off-by: Ingo Molnar
Reviewed-by: Randy Dunlap
Link: https://lore.kernel.org/r/2021034546.ga1981...@gmail.com
---
arch/microblaze/include/asm/ftrace.h | 2 +-
arch/nds32/kernel
Here's the delta between -v1 and -v2, in case you already have -v1 or
want to review the changes only:
---
tools/perf/arch/arm64/util/machine.c | 8
tools/perf/examples/bpf/augmented_raw_syscalls.c | 4 ++--
tools/perf/pmu-events/arch/powerpc/power8/metrics.j
* Ingo Molnar wrote:
> Fix ~81 single-word typos in the perf tooling code - accumulated over the
> years.
Found a few more:
=>
From: Ingo Molnar
Date: Sun, 21 Mar 2021 12:37:34 +0100
Subject: [PATCH] perf tools: Fix various typos in comments
Fix ~124 single-word ty
* Shaokun Zhang wrote:
> Commit 0cd39f4600ed ("locking/seqlock, headers: Untangle the spaghetti
> monster")
> introduces 'struct ww_acquire_ctx' again, remove the repeated declaration.
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
>
* Paul E. McKenney wrote:
> > > * there are no read-side primitives analogous to rcu_read_lock() and
> > > * rcu_read_unlock() because this primitive is intended to determine
> > > * that all tasks have passed through a safe state, not so much for
> > > - * data-strcuture synchronization.
>
ver' is correct spelling too, I'll leave this one alone.
> > * trace_array_printk() can be used, as it will not add noise to the
> > * top level tracing buffer.
>
> and at first I skipped over these, but I'll go back and mention them anyway:
Fixed.
-v2 attache
* Michael Kelley wrote:
> From: Ingo Molnar Sent: Monday, March 22, 2021
> 2:08 PM
> >
> > * Xu Yihang wrote:
> >
> > > Fixes the following W=1 kernel build warning(s):
> > > arch/x86/hyperv/hv_spinlock.c:28:16: warning: variable 'msr_val&
* Martin Sebor wrote:
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow.
> GCC 11 breaks it out as a separate warning to make it easier to
> control. Both wa
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 4bf07f6562a01a488877e05267808da7147f44a5
Gitweb:
https://git.kernel.org/tip/4bf07f6562a01a488877e05267808da7147f44a5
Author:Ingo Molnar
AuthorDate:Mon, 22 Mar 2021 22:39:03 +01:00
Hi Paul,
Was working on automation to make it a bit more straightforward to fix
typos within comments (which we tend to reintroduce during
development), and here are the ones it found in the RCU code.
Thanks,
Ingo
=>
From: Ingo Molnar
Date: Mon, 22 Mar 2021 23:57:26 +0
Fix ~59 single-word typos in the tracing code comments.
Signed-off-by: Ingo Molnar
Cc: Steven Rostedt
Cc: linux-kernel@vger.kernel.org
---
arch/microblaze/include/asm/ftrace.h | 2 +-
arch/nds32/kernel/ftrace.c | 2 +-
arch/powerpc/include/asm/ftrace.h| 4 ++--
arch/sh
===>
From: Ingo Molnar
Date: Mon, 22 Mar 2021 21:52:03 +0100
Subject: [PATCH] mm: Fix typos in comments
Fix ~94 single-word typos in locking code comments, plus a few
very obvious grammar mistakes.
Signed-off-by: Ingo Molnar
Reviewed-by: Matthew Wilcox (Oracle)
Reviewed-by: Randy D
* Xu Yihang wrote:
> Fixes the following W=1 kernel build warning(s):
> arch/x86/hyperv/hv_spinlock.c:28:16: warning: variable ‘msr_val’ set but not
> used [-Wunused-but-set-variable]
> unsigned long msr_val;
>
> As Hypervisor Top-Level Functional Specification states in chapter 7.5
> Virt
* Matthew Wilcox wrote:
> On Mon, Mar 22, 2021 at 03:51:52AM +0100, Ingo Molnar wrote:
> > +++ b/mm/huge_memory.c
> > @@ -1794,7 +1794,7 @@ bool move_huge_pmd(struct vm_area_struct *vma,
> > unsigned long old_addr,
> > /*
> > * Returns
> > * - 0
* Randy Dunlap wrote:
> On 3/21/21 7:51 PM, Ingo Molnar wrote:
> >
> > Fix ~93 single-word typos in locking code comments, plus a few very
> > obvious grammar mistakes.
> >
> > Signed-off-by: Ingo Molnar
> > Cc: Andrew Morton
> > Cc: Rik van R
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building with 'make W=1', gcc points out that casting between
> incompatible function types can be dangerous:
>
> arch/x86/math-emu/fpu_trig.c:1638:60: error: cast between incompatible
> function types from ‘int (*)(FPU_REG *, u_char)’ {aka ‘
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc-11 warns about using string operations on pointers that are
> defined at compile time as offsets from a NULL pointer. Unfortunately
> that also happens on the result of fix_to_virt(), which is a
> compile-time constant for a constantn input
* Bhaskar Chowdhury wrote:
> s/resued/reused/
>
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> Changes from V1:
> As Ingo found the correct word for replacement, so incorporating.
>
> arch/x86/include/asm/kvm_host.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/
* Bhaskar Chowdhury wrote:
> On 23:55 Sun 21 Mar 2021, Ingo Molnar wrote:
> >
> > * Randy Dunlap wrote:
> >
> > >
> > >
> > > On Mon, 22 Mar 2021, Bhaskar Chowdhury wrote:
> > >
> > > >
> > > > s/swishes/sw
The following commit has been merged into the irq/core branch of tip:
Commit-ID: a359f757965aafd0f58570de95dc6bc06cf12a9c
Gitweb:
https://git.kernel.org/tip/a359f757965aafd0f58570de95dc6bc06cf12a9c
Author:Ingo Molnar
AuthorDate:Mon, 22 Mar 2021 04:21:30 +01:00
Committer
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 97258ce902d1e1c396a4d7c38f6ae7085adb73c5
Gitweb:
https://git.kernel.org/tip/97258ce902d1e1c396a4d7c38f6ae7085adb73c5
Author:Ingo Molnar
AuthorDate:Mon, 22 Mar 2021 03:55:50 +01:00
Committer
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 3b03706fa621ce31a3e9ef6307020fde4e6aae16
Gitweb:
https://git.kernel.org/tip/3b03706fa621ce31a3e9ef6307020fde4e6aae16
Author:Ingo Molnar
AuthorDate:Thu, 18 Mar 2021 13:38:50 +01:00
Committer
The following commit has been merged into the locking/core branch of tip:
Commit-ID: e2db7592be8e83df47519116621411e1056b21c7
Gitweb:
https://git.kernel.org/tip/e2db7592be8e83df47519116621411e1056b21c7
Author:Ingo Molnar
AuthorDate:Mon, 22 Mar 2021 02:35:05 +01:00
Fix ~93 single-word typos in locking code comments, plus a few very
obvious grammar mistakes.
Signed-off-by: Ingo Molnar
Cc: Andrew Morton
Cc: Rik van Riel
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
include/linux/mm.h | 2 +-
include/linux/vmalloc.h | 4 ++--
mm
* Randy Dunlap wrote:
>
>
> On Mon, 22 Mar 2021, Bhaskar Chowdhury wrote:
>
> >
> > s/swishes/switch/
>
> should be 'switches'
Correct - this patch exchanged a typo for a grammar mistake...
Thanks,
Ingo
* Randy Dunlap wrote:
>
>
> On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:
>
> >
> > s/resued/resumed/
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
>
>
> > ---
> > arch/x86/include/asm/kvm_host.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > d
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 163b099146b85d1b05bd2eaa045acbeee25c29e4
Gitweb:
https://git.kernel.org/tip/163b099146b85d1b05bd2eaa045acbeee25c29e4
Author:Ingo Molnar
AuthorDate:Sun, 21 Mar 2021 22:28:53 +01:00
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: c681df88dcb12b1efd7e4efcfe498c5e9c31ce02
Gitweb:
https://git.kernel.org/tip/c681df88dcb12b1efd7e4efcfe498c5e9c31ce02
Author:Ingo Molnar
AuthorDate:Sun, 21 Mar 2021 23:32:33 +01:00
Linus,
Please pull the latest irq/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-2021-03-21
# HEAD: 81e2073c175b887398e5bca6c004efa89983f58d genirq: Disable interrupts
for force threaded handlers
A change to robustify force-threaded IRQ handle
Fix ~81 single-word typos in the perf tooling code - accumulated over the years.
Signed-off-by: Ingo Molnar
---
tools/perf/Documentation/perf-buildid-cache.txt | 2 +-
tools/perf/Documentation/perf-report.txt| 2 +-
tools/perf/Documentation/perf-top.txt | 2 +-
tools/perf
Linus,
Please pull the latest perf/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-2021-03-21
# HEAD: 2dc0572f2cef87425147658698dce2600b799bd3 perf/x86/intel: Fix
unchecked MSR access error caused by VLBR_EVENT
Boundary condition fixes for bug
Linus,
Please pull the latest locking/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2021-03-21
# HEAD: 38c93587375053c5b9ef093f4a5ea754538cba32 static_call: Fix
static_call_update() sanity check
Locking fixes:
- Get static calls & module
Linus,
Please pull the latest efi/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
efi-urgent-2021-03-21
# HEAD: 429257a430a0e81e9979256e0db718e35e7d9cee Merge tag
'efi-urgent-for-v5.12-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi
* Len Brown wrote:
> On Wed, Mar 17, 2021 at 6:45 AM Ingo Molnar wrote:
> >
> >
> > * Ingo Molnar wrote:
> >
> > >
> > > * Chang S. Bae wrote:
> > >
> > > > During signal entry, the kernel pushes data onto the normal us
* Kees Cook wrote:
> Allow for a randomized stack offset on a per-syscall basis, with roughly
> 5-6 bits of entropy, depending on compiler and word size. Since the
> method of offsetting uses macros, this cannot live in the common entry
> code (the stack offset needs to be retained for the life
* Waiman Long wrote:
> This is a follow-up patch series for the previous patchset on fixing
> locktorture ww_mutex test problem [1]. The first 3 patches of that
> series were merged into tip. It turns out that the last one of the
> three wasn't quite right. So this patch series revert the last
* Waiman Long wrote:
> This is a follow-up patch series for the previous patchset on fixing
> locktorture ww_mutex test problem [1]. The first 3 patches of that
> series were merged into tip. It turns out that the last one of the
> three wasn't quite right. So this patch series revert the last
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: d9f6e12fb0b7fcded0bac34b8293ec46f80dfc33
Gitweb:
https://git.kernel.org/tip/d9f6e12fb0b7fcded0bac34b8293ec46f80dfc33
Author:Ingo Molnar
AuthorDate:Thu, 18 Mar 2021 15:28:01 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 7aacb8c62f621e9f6f1b5f11bb19eb37ddbf00e2
Gitweb:
https://git.kernel.org/tip/7aacb8c62f621e9f6f1b5f11bb19eb37ddbf00e2
Author:Ingo Molnar
AuthorDate:Thu, 18 Mar 2021 13:38:50 +01:00
Committer
* Xu Yihang wrote:
> Fixes the following W=1 kernel build warning(s):
> arch/x86/hyperv/hv_apic.c:58:15: warning: variable ‘hi’ set but not used
> [-Wunused-but-set-variable]
>
> Reported-by: Hulk Robot
> Signed-off-by: Xu Yihang
> ---
> arch/x86/hyperv/hv_apic.c | 3 ++-
> 1 file changed,
* Peter Zijlstra wrote:
> Now, the C people figured that distinction was useless and allowed
> sloppiness. But I still think there's merrit to that. And as
> mentioned earlier, it is consistent with variable declarations.
Fully agreed, and my other point was that it's also consistent with
t
* Arnd Bergmann wrote:
> On Wed, Mar 17, 2021 at 9:45 AM Ingo Molnar wrote:
> > * Ingo Molnar wrote:
> > > * Jiapeng Chong wrote:
> > >
> > > > Fix the following coccicheck warnings:
> > > >
> > > > ./kernel/sched/core.c:8039:2-
* Borislav Petkov wrote:
> On Thu, Mar 18, 2021 at 05:49:21AM +1100, Stephen Rothwell wrote:
> > That fixes the powerpc build for me, thanks.
>
> Thx, adding your Tested-by and pushing out.
I've pushed this out into tip:auto-latest as well, so that tomorrow's
-next should pick this up automa
; > https://git.kernel.org/tip/873d7c4c6a920d43ff82e44121e54053d4edba93
> > Author:Nicholas Piggin
> > AuthorDate:Wed, 17 Mar 2021 17:54:27 +10:00
> > Committer: Ingo Molnar
> > CommitterDate: Wed, 17 Mar 2021 09:32:30 +01:00
>
> Groan. This does not even compile and Nichola
* Ingo Molnar wrote:
>
> * Chang S. Bae wrote:
>
> > During signal entry, the kernel pushes data onto the normal userspace
> > stack. On x86, the data pushed onto the user stack includes XSAVE state,
> > which has grown over time as new features and larger regis
* Chang S. Bae wrote:
> During signal entry, the kernel pushes data onto the normal userspace
> stack. On x86, the data pushed onto the user stack includes XSAVE state,
> which has grown over time as new features and larger registers have been
> added to the architecture.
>
> MINSIGSTKSZ is a
* He Ying wrote:
> We found these warnings in kernel/panic.c by using sparse tool:
> warning: symbol 'panic_smp_self_stop' was not declared.
> warning: symbol 'nmi_panic_self_stop' was not declared.
> warning: symbol 'crash_smp_send_stop' was not declared.
>
> To avoid them, add declarations f
* Mike Galbraith wrote:
> On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
> > Why not just use wake_up_process().
>
> IMO this is not an improvement. There are other places where explicit
> TASK_NORMAL is used as well, and they're all perfectly clear as is.
Arguably those could all be co
* Yu, Yu-cheng wrote:
> On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
> > On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
> > > Control-flow Enforcement (CET) is a new Intel processor feature that
> > > blocks
> > > return/jump-oriented programming attacks. Details are in "Intel 64
* Kim Phillips wrote:
> On 3/16/21 2:53 PM, Peter Zijlstra wrote:
> > On Tue, Mar 16, 2021 at 04:45:02PM +0100, Jiri Olsa wrote:
> >> hi,
> >> when running 'perf top' on AMD Rome (/proc/cpuinfo below)
> >> with fedora 33 kernel 5.10.22-200.fc33.x86_64
> >>
> >> we got unknown NMI messages:
> >>
* Ingo Molnar wrote:
>
> * Jiapeng Chong wrote:
>
> > Fix the following coccicheck warnings:
> >
> > ./kernel/sched/core.c:8039:2-5: WARNING: Use BUG_ON instead of if
> > condition followed by BUG.
> >
> > Reported-by: Abaci Robot
> >
* Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./kernel/sched/core.c:8039:2-5: WARNING: Use BUG_ON instead of if
> condition followed by BUG.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> kernel/sched/core.c | 3 +--
> 1 file changed, 1 insertion(
* Nicholas Piggin wrote:
> The page waitqueue hash is a bit small (256 entries) on very big systems. A
> 16 socket 1536 thread POWER9 system was found to encounter hash collisions
> and excessive time in waitqueue locking at times. This was intermittent and
> hard to reproduce easily with the s
* Josh Don wrote:
> +static inline u64 resched_latency_check(struct rq *rq)
> +{
> + int latency_warn_ms = READ_ONCE(sysctl_resched_latency_warn_ms);
> + bool warn_only_once = (latency_warn_ms ==
> RESCHED_DEFAULT_WARN_LATENCY_MS);
> + u64 need_resched_latency, now = rq_clock(rq);
* Josh Don wrote:
> From: Paul Turner
>
> CPU scheduler marks need_resched flag to signal a schedule() on a
> particular CPU. But, schedule() may not happen immediately in cases
> where the current task is executing in the kernel mode (no
> preemption state) for extended periods of time.
>
>
* Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> eca8f0c80a00 ("hrtimer: Update softirq_expires_next correctly after
> __hrtimer_get_next_event()")
>
> Fixes tag
>
> Fixes: da70160462e ("hrtimer: Implement support for softirq based hrtimers")
>
> has these problem(s):
>
> - Ta
* Alexei Starovoitov wrote:
> > This seems to be it... (completely untested)
> >
> > ---
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index 3f7f89ea5e51..918a296d2ca2 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -1032,7
* Linus Torvalds wrote:
> But I also can heartily just recommend that people who already _did_
> start on rc1 to rebase their current - hopefully not extensive - work.
Thanks for the heads-up - we just rebased about 50 commits in -tip to
avoid this bug: our normal workflow is to jump on -rc1
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: dd75cba56151cb3b9dc7eac0221c9b1967f6ddb5
Gitweb:
https://git.kernel.org/tip/dd75cba56151cb3b9dc7eac0221c9b1967f6ddb5
Author:Ingo Molnar
AuthorDate:Tue, 02 Mar 2021 08:02:43 +01:00
Committer
* Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Mon, Mar 01, 2021 at 08:16:12PM +0100, Jürgen Groß wrote:
> > > >https://lkml.kernel.org/r/20210220231712.2475218-2-na...@vmware.com
> > >
> > > They are already in tip locking/core (
* Peter Zijlstra wrote:
> On Mon, Mar 01, 2021 at 08:16:12PM +0100, Jürgen Groß wrote:
> > >https://lkml.kernel.org/r/20210220231712.2475218-2-na...@vmware.com
> >
> > They are already in tip locking/core (Ingo applied them).
>
> I'm very tempted to undo that :-(
Sorry about that - I'm s
arch_send_call_function_ipi_mask(cfd->cpumask_ipi);
>
> Which will avoid the IPI when @last_cpu is idle.
I turned this into the additional patch below, on top of Nadav's series.
Thanks,
Ingo
===>
From: Ingo Molnar
Date: Tue, 2 M
Linus,
Please pull the latest perf/core git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-core-2021-02-17
# HEAD: 8bcfdd7cad3dffdd340f9a79098cbf331eb2cd53 Merge branch 'perf/kprobes'
into perf/core, to pick up finished branch
The performance event updates for
Linus,
Please pull the latest sched/core git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-core-2021-02-17
# HEAD: c5e6fc08feb2b88dc5dac2f3c817e1c2a4cafda4 sched,x86: Allow
!PREEMPT_DYNAMIC
Scheduler updates for v5.12:
[ NOTE: unfortunately this tree had to
Linus,
Please pull the latest core/mm git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-mm-2021-02-17
# HEAD: 8cf55f24ce6cf90eb8828421e15e9efcd508bd2c x86/ldt: Use
tlb_gather_mmu_fullmm() when freeing LDT page-tables
These changes fix MM (soft-)dirty bit manag
Linus,
Please pull the latest locking/core git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-core-2021-02-17
# HEAD: 3765d01bab73bdb920ef711203978f02cd26e4da Merge branch
'for-mingo-lkmm' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu i
Linus,
Please pull the latest core/rcu git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-2021-02-17
# HEAD: 2b392cb11c0db645ba81a08b6a2e96c56ec1fc64 Merge branch
'for-mingo-nolibc' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into cor
* Stephen Rothwell wrote:
> Hi Peter,
>
> On Mon, 1 Feb 2021 15:40:12 +0100 Peter Zijlstra wrote:
> >
> > On Mon, Feb 01, 2021 at 01:04:30PM +, Valentin Schneider wrote:
> > > On 01/02/21 20:09, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > >
> > > Hi Stephen,
> > >
> > > >
* Paul E. McKenney wrote:
> Hello, Ingo!
>
> This pull request contains changes for RCU, KCSAN, LKMM, and nolibc.
> You can pull the entire group using branch for-mingo. Or, if you prefer,
> you can pull them separately, using for-mingo-rcu to pull the RCU changes,
> for-mingo-kcsan to pull t
1 - 100 of 11508 matches
Mail list logo
