nt nature of issues with
> running EUDPATESVN: temporal failure due to lack of entropy (-EAGAIN)
> and potentially persistent problem when getting unexpected error codes
> (-EIO).
Makes sense!
Thanks,
Ingo
sn't ...
Furthermore, in the sgx_open() error paths we can then run into
sgx_dec_usage_count(), which will merrily underflow the counter into
negative:
+void sgx_dec_usage_count(void)
+{
+ atomic64_dec(&sgx_usage_count);
+}
How is this all supposed to work?
Thanks,
Ingo
t'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
sgx_open(): returns 0 on successful increase, -EBUSY on
failure
Could we at least standardize sgx_inc_usage_count() on -EBUSY in the
failure case, so it's a more obvious pattern:
+ ret = sgx_inc_usage_count();
+ if (ret < 0)
+ return ret;
Thanks,
Ingo
9, 0x8007, 0 },
So it should be obvious at a glance that this new line doesn't follow
the coding convention of the surrounding lines...
Thanks,
Ingo
> if (child == 0) {
> - printf("[RUN]\tchild: check that we inherited permissions\n");
> + printf("[RUN]\tchild: check that if we inherited
> permissions\n");
Wot?
Thanks,
Ingo
Despite this, the existing SGX code will try to reclaim pages
> that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.
>
> But otherwise it looks great:
>
> Acked-by: Dave Hansen
Thanks, I've applied this fix to tip:x86/sgx, with the TL;DR paragraph
added in.
Thanks,
Ingo
ons(-)
Why have you ignored this request I made:
>> Finally, it would be nice to quote the before/after output of the
>> leak detection tool you are using.
?
Thanks,
Ingo
he perror(),
presumably so that file-leak detection in Valgrind or whatever tool you
are using doesn't trigger.
But here it's done after the perror() call, why? It's perfectly fine to
close the mapping fd straight after an mmap() call.
Finally, it would be nice to quote the before/after output of the leak
detection tool you are using.
Thanks,
Ingo
close(fd);
> perror("mmap");
We should unconditionally close 'fd' after the mmap() call, not just in
the perror() branch.
Thanks,
Ingo
r cleanup of resources is a good practice
- and in more complicated tools it's useful to fix even these
semi-false-positives, to make sure other warnings don't get missed.
Having said that, the error/cleanup control flow here doesn't look
overly clean here to begin with, so I'd suggest fixing that (with goto
labels or such) - which would fix the file_fd 'leak' as a happy side
effect.
Thanks,
Ingo
.sakki...@linux.intel.com/
Because this experience reflects arguably poor usability: people see
'SGX' in their /proc/cpuinfo file, think that their hardware is 'SGX
enabled' and are wondering why the hell the /dev/sgx_enclave device
node is not created, right?
I also Cc:-ed m
720 deletions(-)
Thank you very much for doing this - this series is a very big step
forward in this area.
I've applied your series to tip:x86/fpu with minor edits to the
changelogs, and if all goes fine it should all go upstream in the v6.15
merge window in a couple of weeks.
Thanks,
Ingo
gt; + * @EXECMEM_TYPE_MAX:
> + */
> +enum execmem_type {
> + EXECMEM_DEFAULT,
> + EXECMEM_MODULE_TEXT = EXECMEM_DEFAULT,
> + EXECMEM_KPROBES,
> + EXECMEM_FTRACE,
> + EXECMEM_BPF,
> + EXECMEM_TYPE_MAX,
> +};
s/explcitly
/explicitly
Thanks,
Ingo
void *wr_addr = module_writable_address(mod, addr);
or so, since we have to pass 'addr' to the module code anyway.
The text patching code is pretty complex already.
Thanks,
Ingo
oduction workloads that exhibit
> significant contention on the spinlock and an almost order of magnitude
> reduction for mean uprobe execution time is observed (28 -> 3.5 microsecs).
Have you considered/measured per-CPU RW semaphores?
Thanks,
Ingo
ecks for negative values
generates similarly fast machine code compared to checking for 0, if
the value is also used (which it is in most cases here). What am I
missing? We seem to be going through a lot of unnecessary hoops, and
some of that is in the runtime path.
Thanks,
Ingo
is a race somewhere.
> + * Note that this is probably an unnecessary cache miss in the fast
> path.
> + */
> + if (WARN_ON_ONCE(raw_cpu_read(osq_node.next) != NULL))
> + raw_cpu_write(osq_node.next, NULL);
The fix-uppery and explanation about something that shouldn't happen is
excessive: please just put a plain WARN_ON_ONCE() here - which we can
remove in a release or so.
Thanks,
Ingo
older compiler may generate more
> complex code. However, I do have some doubt as to the benefit of this patch
> at the expense of making the code a bit more complex.
GCC-11 is plenty of a look-back window in terms of compiler efficiency:
latest enterprise distros use GCC-11 or newer, while recent desktop
distros use GCC-13. Anything older won't matter, because no major
distribution is going to use new kernels with old compilers.
Thanks,
Ingo
sysfs_match_string(), which
> completely removes the need to make a copy of the val string.
>
> I'll submit the patch right after this email.
Thank you - that looks a far more thorough cleanup indeed.
Ingo
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
warning, the other improves an
ambiguous/confusing kernel log message.
Thanks,
Ingo
-->
Arnd Bergmann (1):
lockdep: Address clang -Wformat warning printing for %hd
Tetsuo Handa (1):
lockdep: Add a missing initialization hint to the "INFO: Trying to
regi
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
mutex_lock_io_nested() method to map to mutex_lock_io()
instead of mutex_lock().
Right now nothing uses this API explicitly, but this is an accident waiting to
happen.
Thanks,
Ingo
-->
Thomas Gleixner (1):
locking/mutex: Fix non debug version of mutex_lock_io_nes
on to the additional field in
> perf_event_attr, I think it'll give us the simplest and most
> flexible option.
Sounds good to me - it's also probably measurably faster than copying
the not-so-small-anymore perf_attr structure.
Thanks,
Ingo
sig_info?
The idea would be to create a stable, per-signal snapshot of whatever
the perf_attr state is at the moment the event happens and the signal
is generated - which is roughly what user-space wants, right?
Thanks,
Ingo
es the interrupt distribution model be more
>* like LRU than MRU (the short-term load is more even across CPUs).
>*/
This and many more comment typos are already fixed in the latest x86
tree, which you can find at:
git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
Thanks,
Ingo
* 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
>
m as 'typos' and create churn to
'fix' them...
'data-structure' or 'datastructure' are both perfectly readable, just
like 'fast-path' or 'fastpath', 'cache-miss' or 'cachemiss' and a
million other examples.
Thanks,
Ingo
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&
tation as
well.
So the probability of false positive remaining is in fact higher, and
going forward we should see a better S/N ratio of this warning. Most
of which will never be seen by upstream maintainers, as the mishaps
will stay at the individual developer level. :-)
Thanks,
Ingo
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
* Randy Dunlap wrote:
> > New version attached. Can I add your Reviewed-by?
>
> Sure.
> Reviewed-by: Randy Dunlap
-v3 attached, the only change is the addition of your Reviewed-by.
This would be for -mm I suppose, if Andrew agrees too?
Thanks,
Ingo
===
@@ -25,7 +25,7 @@ static void hv_qlock_kick(int cpu)
>
> static void hv_qlock_wait(u8 *byte, u8 val)
> {
> - unsigned long msr_val;
> + unsigned long msr_val __maybe_unused;
> unsigned long flags;
Please don't add new __maybe_unused annotations to the x86 tree -
improve the flow instead to help GCC recognize the initialization
sequence better.
Thanks,
Ingo
* 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
n;
The existing nomenclature in that code is:
static int f_cos(FPU_REG *st0_ptr, u_char tag)
static void fcos(FPU_REG *st0_ptr, u_char st0_tag)
So I'd suggest naming the variant with a return value f_sin().
Thanks,
Ingo
pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
> - pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
> - pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
This is indeed rather ugly - and the other patch that removes a debug
check seems counterproductive as well.
Do we know how many genuine bugs -Wstringop-overread-warning has
caught or is about to catch?
I.e. the real workaround might be to turn off the -Wstringop-overread-warning,
until GCC-11 gets fixed?
Thanks,
Ingo
* 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
* 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
#x27;,
not 'resumed' ...
See how I fixed most arch/x86/ typo fixes in tip:x86/cleanups:
d9f6e12fb0b7: ("x86: Fix various typos in comments")
163b099146b8: ("x86: Fix various typos in comments, take #2")
These single file typo fixes are a bad idea for another reason as
well, as they create a lot of unnecessary churn.
Thanks,
Ingo
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
,
Ingo
-->
Andy Shevchenko (1):
genirq/irq_sim: Fix typos in kernel doc (fnode -> fwnode)
Thomas Gleixner (1):
genirq: Disable interrupts for force threaded handlers
kernel/irq/irq_sim.c | 4 ++--
kernel/irq/manage.c | 4
2 files changed, 6 inse
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
bugs unearthed by the perf fuzzer.
Thanks,
Ingo
-->
Kan Liang (2):
perf/x86/intel: Fix a crash caused by zero PEBS status
perf/x86/intel: Fix unchecked MSR access error caused by VLBR_EVENT
arch/x86/events/intel/core.c | 3 +++
arch/x86/events/intel/d
& modules right. Hopefully.
- WW mutex fixes
Thanks,
Ingo
-->
Peter Zijlstra (3):
static_call: Fix static_call_set_init()
static_call: Align static_call_is_init() patching condition
static_call: Fix static_call_update() sanity check
Waiman
e
Thanks,
Ingo
-->
Ard Biesheuvel (1):
efi: use 32-bit alignment for efi_guid_t literals
Lv Yunlong (1):
firmware/efi: Fix a use after bug in efi_mem_reserve_persistent
Shawn Guo (1):
efivars: respect EFI_UNSUPPORTED return from firmware
drivers/firmware/e
* 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
k_canary value?
This would further isolate the syscall kernel stack offsets of
separate execution contexts from each other, should an attacker find a
way to estimate or influence likely RDTSC values.
Thanks,
Ingo
in ww_mutex test")
As these bugs are basically limited to a debugging facility.
( But we could also merge them into v5.12, if you think it's
justified. No strong opinions either way. )
Thanks,
Ingo
s revert the last patch.
I zapped that 3rd commit from locking/urgent yesterday already, so we
can cleanly apply the 4 patches from this series.
Thanks,
Ingo
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
_icr_write(u32 low, u32 id)
>
> static u32 hv_apic_read(u32 reg)
> {
> - u32 reg_val, hi;
> + u32 hi __maybe_unused;
> + u32 reg_val;
>
> switch (reg) {
> case APIC_EOI:
Why and under what config does this function trigger the warning?
Thanks,
Ingo
lso consistent with
the other existing externs were used *in the same header file*
already.
I.e. there's nothing more sloppy than mixing different styles within
the same header. Checkpatch needs to be fixed or ignored here.
Thanks,
Ingo
* 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-
-next should pick this up automatically. (Assuming everything else is
fine.)
Thanks,
Ingo
; > 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
ally round up sigaltstack size if it's too small?
This would be more robust, as it would fix applications that use
MINSIGSTKSZ but don't use the new AT_MINSIGSTKSZ facility.
I.e. does AT_MINSIGSTKSZ have any other uses than avoiding the
segfault if MINSIGSTKSZ is used to create a small signal stack?
Thanks,
Ingo
egs *regs);
> +void crash_smp_send_stop(void);
Please follow the 'extern' convention used for prototype declarations
in that header file.
Thanks,
Ingo
ably those could all be converted to wake_up_process() as well.
It's a very small kernel code size optimization. There's about 3 such
places, could be converted in a single patch.
Thanks,
Ingo
ere is agreement.
I was look at:
x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states
didn't see any IBT logic - it's essentially all shadow stack state.
Which is not surprising, forward call edge integrity protection (IBT)
requires very little state, does it?
With IBT there's no nesting, no stack - the IBT state machine
basically requires the next instruction to be and ENDBR instruction,
and that's essentially it, right?
Thanks,
Ingo
askable
Interrupt), and the IBS counter overflows during the entry into the Core C6
(CC6) state, the interrupt may be
issued, but an invalid value of the valid bit may be restored when the core
exits CC6.
Potential Effect on System
The operating system may receive interrupts due to an IBS counter event,
including NMI, and not observe an
valid IBS register. Console messages indicating "NMI received for unknown
reason" have been observed on
Linux systems.
Suggested Workaround: None
Fix Planned: No fix planned
lovely.
Thanks,
Ingo
* 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
> >
< 0);
The patch doesn't quite do what the title & changelog claims...
Thanks,
Ingo
queue_head(bit_wait_table + i);
Meta suggestion: maybe the CONFIG_BASE_SMALL ugliness could be folded
into alloc_large_system_hash() itself?
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> static wait_queue_head_t *page_waitqueue(struct page *page)
> {
> - return &page_wait_table[hash_ptr(page, PAGE_WAIT_TABLE_BITS)];
> + return &page_wait_table[hash_ptr(page, page_wait_table_bits)];
> }
I'm wondering whether you've tried to make this NUMA aware through
page->node?
Seems like another useful step when having a global hash ...
Thanks,
Ingo
return 0;
> + }
> +
> + rq->ticks_without_resched++;
So AFAICS this will only really do something useful on full-nohz
kernels with sufficiently long scheduler ticks, right?
On other kernels the scheduler tick interrupt, when it returns to
user-space, will trigger a reschedule if it sees a need_resched.
Thanks,
Ingo
"CPU %d: need_resched set for > %llu ns (%d ticks) "
> + "without schedule\n",
> + cpu, latency, cpu_rq(cpu)->ticks_without_resched);
> +}
Could you please put the 'sched:' prefix into scheduler warnings.
Let's have a bit of a namespace structure in new warnings.
Thanks,
Ingo
irq based hrtimers")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Maybe you meant
>
> Fixes: 5da70160462e ("hrtimer: Implement support for softirq based hrtimers")
Thanks - fixed.
Ingo
xposed to any ABI anywhere.
I did a (non-exhaustive) search of tooling, and there doesn't appear
to be any accidental exposure.
The in-kernel ABI interaction appears to be the following:
- In __perf_event_header_size() we only use fields within
perf_sample_data to size the header. Alignme
lper annotation or hook-script that
can be embedded in the kernel Git tree to avoid or at least warn about
particularly nasty bugs?
Thanks,
Ingo
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 un
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
ly end in tears.
- Fix energy/power events on Intel SPR platforms
- Simplify the uprobes resume_execution() logic
- Misc smaller fixes.
Thanks,
Ingo
-->
Jim Mattson (1):
perf/x86/kvm: Add Cascade Lake Xeon steppings to isolation_ucodes[]
Kan Liang (5):
an up task priority related defines, remove *USER_*PRIO and
USER_PRIO()
- Simplify the sched_init_numa() deduplication sort
- Documentation updates
- Fix EAS bug in update_misfit_status(), which degraded the quality
of energy-balancing
- Smaller cleanups
Thanks,
management in the procfs code & clean up
the API.
Thanks,
Ingo
-->
Will Deacon (6):
mm: proc: Invalidate TLB after clearing soft-dirty page state
tlb: mmu_gather: Remove unused start/end arguments from tlb_finish_mmu()
tlb: mmu_gather: In
y file
Thanks,
Ingo
-->
Akira Yokosawa (2):
tools/memory-model: Remove redundant initialization in litmus tests
tools/memory-model: Fix typo in klitmus7 compatibility table
Alejandro Colomar (1):
futex: Change utime parameter to be 'const ... *'
le, and refscale.
Plus does an allmodconfig build.
- nolibc fixes for the torture tests
Thanks,
Ingo
-->
Frederic Weisbecker (17):
tools/rcutorture: Make identify_qemu_vcpus() independent of local language
rcu/nocb: Turn enabled/offload states into
ot reached the tip auto-latest branch yet and so is not in
> linux-next.
This fix should be there now as:
e972d92d52a1: ("sched/topology: Fix sched_domain_topology_level alloc in
sched_init_numa()")
Thanks,
Ingo
* 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-m
1 - 100 of 11800 matches
Mail list logo
