* Ard Biesheuvel wrote:
> On Mon, 1 Jun 2020 at 15:24, Ingo Molnar wrote:
> >
> > Linus,
> >
> > Please pull the latest efi/core git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
&g
Linus,
Please pull the latest perf/core git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-core-2020-06-01
# HEAD: 5cde265384cad739b162cf08afba6da8857778bd perf/x86/rapl: Add AMD
Fam17h RAPL support
Kernel side changes:
- Add AMD Fam17h RAPL support
-
ool: is_fentry_call() crashes if call has no destination
objtool: UNWIND_HINT_RET_OFFSET should not check registers
objtool: Add support for intra-function calls
Ingo Molnar (3):
objtool: Constify 'struct elf *' parameters
objtool: Rename elf_read() to elf_open_read()
objt
,
Ingo
-->
Alex Shi (1):
locking/rtmutex: Remove unused rt_mutex_cmpxchg_relaxed()
Gustavo A. R. Silva (1):
locking/lockdep: Replace zero-length array with flexible-array
Ingo Molnar (1):
mm/swap: Use local_lock for protection
Julia Cartwright
Linus,
Please pull the latest efi/core git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-2020-06-01
# HEAD: e9524fb97ab5b41b85e1d3408f8e513433798f3c efi/x86: Don't blow away
existing initrd
The EFI changes for this cycle are:
- preliminary changes for
Linus,
Please pull the latest core/rcu git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-2020-06-01
# HEAD: cb3cb6733fbd8fd8d2c716095fdca42dadba2063 Merge branch 'WIP.core/rcu'
into core/rcu, to pick up two x86/entry dependencies
The RCU updates for this
may be used.
Also add a kprobes blacklist for modules.
Signed-off-by: Ingo Molnar
Thanks,
Ingo
-->
Masami Hiramatsu (4):
kprobes: Lock kprobe_mutex while showing kprobe_blacklist
kprobes: Support __kprobes blacklist in modules
kprobes: Supp
The following commit has been merged into the locking/core branch of tip:
Commit-ID: b01b214136ac3e4746b7f76c0f204ae4b445
Gitweb:
https://git.kernel.org/tip/b01b214136ac3e4746b7f76c0f204ae4b445
Author:Ingo Molnar
AuthorDate:Wed, 27 May 2020 22:11:15 +02:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 1f8db4150536431b031585ecc2a6793f69245de2
Gitweb:
https://git.kernel.org/tip/1f8db4150536431b031585ecc2a6793f69245de2
Author:Ingo Molnar
AuthorDate:Thu, 28 May 2020 11:01:34 +02:00
Committer
The following commit has been merged into the irq/core branch of tip:
Commit-ID: d77aeb5d403d379ff458e04fc07b5b86700270f2
Gitweb:
https://git.kernel.org/tip/d77aeb5d403d379ff458e04fc07b5b86700270f2
Author:Ingo Molnar
AuthorDate:Mon, 01 Jun 2020 09:45:27 +02:00
Committer
* Al Viro wrote:
> On Thu, May 28, 2020 at 11:34:38AM -0700, Linus Torvalds wrote:
> > On Thu, May 28, 2020 at 12:03 AM Ingo Molnar wrote:
> > >
> > > I'm wondering, shouldn't we also zero-initialize the dump data to
> > > begin with? See the patch below
* Al Viro wrote:
> IOW, copy_xstate_to_kernel()/copy_xstate_to_user() needs not only to map
> from compacted format to standard one; it also needs to compensate for
> that "we might skip saving the components that are in init state; we'll
> report which ones got skipped by way of
* Al Viro wrote:
> On Thu, May 28, 2020 at 09:02:55AM +0200, Ingo Molnar wrote:
>
> > Looks good to me.
> >
> > I'm wondering, shouldn't we also zero-initialize the dump data to
> > begin with? See the patch below (untested).
>
> Note that t
* Ingo Molnar wrote:
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index 13f25e241ac4..25d489bc9453 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -1733,7 +1733,7 @@ static int fill_thread_core_info(struct
> > elf_thread_core_i
* Ingo Molnar wrote:
>
> * Al Viro wrote:
>
> > xstate note on boxes with xsaves support can leak uninitialized data
> > into coredumps
> >
> > The following changes since commit 4e89b7210403fa4a8acafe7c602b6212b7af6c3b:
> >
> > fix multi
* Al Viro wrote:
> xstate note on boxes with xsaves support can leak uninitialized data
> into coredumps
>
> The following changes since commit 4e89b7210403fa4a8acafe7c602b6212b7af6c3b:
>
> fix multiplication overflow in copy_fdtable() (2020-05-19 18:29:36 -0400)
>
> are available
forward solution is to upgrade kfree_mult to a long.
Since this depends on CONFIG_RCU_PERF_TEST
BTW., could we please also rename this code from 'PERF_TEST'/'perf test'
to 'PERFORMANCE_TEST'/'performance test'? At first glance I always
mistakenly believe that it's somehow related to perf, while it
* Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> After a lengthy discussion [1] it turned out that RCU does not need a full
> rcu_irq_enter/exit() when RCU is already watching. All it needs if
> NOHZ_FULL is active is to check whether the tick needs to be restarted.
>
> This allows to
* Paul E. McKenney wrote:
> > + if (!tick_nohz_full_cpu(rdp->cpu) ||
> > + !READ_ONCE(rdp->rcu_urgent_qs) ||
> > + READ_ONCE(rdp->rcu_forced_tick)) {
> > + // RCU doesn't need nohz_full help from this CPU, or it is
> > + // already getting that help.
> > +
* Matthew Wilcox wrote:
> On Mon, May 25, 2020 at 08:29:54AM +0200, Ingo Molnar wrote:
> > > +void radix_tree_preload_end(void)
> > > +{
> > > + local_unlock(_tree_preloads.lock);
> > > +}
> > > +EXPORT_SYMBOL(radix_tree_preload_end);
> >
/pub/scm/linux/kernel/git/efi/efi.git
> tags/efi-changes-for-v5.8
>
> for you to fetch changes up to 9241dfe7f2772fc73c82eb950afb1c795d2c012c:
>
> efi/x86: Drop the special GDT for the EFI thunk (2020-05-24 00:25:15 +0200)
>
> Cc: Ingo Molnar ,
The following commit has been merged into the x86/entry branch of tip:
Commit-ID: d121f9483b18c423037ce6088feba24ae83891d1
Gitweb:
https://git.kernel.org/tip/d121f9483b18c423037ce6088feba24ae83891d1
Author:Ingo Molnar
AuthorDate:Mon, 25 May 2020 09:42:41 +02:00
Committer
* Sebastian Andrzej Siewior wrote:
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -5,11 +5,13 @@
>
> #ifndef _ZCOMP_H_
> #define _ZCOMP_H_
> +#include
>
> struct zcomp_strm {
> /* compression/decompression buffer */
> void *buffer;
> struct
* Sebastian Andrzej Siewior wrote:
> zcomp::stream is per-CPU pointer, pointing to struct zcomp_strm which
> contains two pointer. Having struct zcomp_strm allocated directly as
> per-CPU memory would avoid one additional memory allocation and a
> pointer dereference.
> This also also
* Sebastian Andrzej Siewior wrote:
> From: Mike Galbraith
>
> send_msg() disables preemption to avoid out-of-order messages. As the
> code inside the preempt disabled section acquires regular spinlocks,
> which are converted to 'sleeping' spinlocks on a PREEMPT_RT kernel and
> eventually
* Ingo Molnar wrote:
> ( The other departure from spinlocks is that the 'spinlock_t' name,
> without underscores, while making the API names such as spin_lock()
> with an underscore, was a conscious didactic choice. Applying that
> principle to local locks gives us th
* Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner
>
> To address this PREEMPT_RT introduced the concept of local_locks which are
> strictly per CPU.
> +++ b/include/linux/locallock_internal.h
> @@ -0,0 +1,90 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_LOCALLOCK_H
* Sebastian Andrzej Siewior wrote:
> From: Ingo Molnar
>
> The various struct pagevec per CPU variables are protected by disabling
> either preemption or interrupts across the critical sections. Inside
> these sections spinlocks have to be acquired.
> diff --git a/mm/
* Sebastian Andrzej Siewior wrote:
> The radix-tree and idr preload mechanisms use preempt_disable() to protect
> the complete operation between xxx_preload() and xxx_preload_end().
>
> As the code inside the preempt disabled section acquires regular spinlocks,
> which are converted to
* Mel Gorman wrote:
> The following two patches optimise try_to_wake_up() when the wakee is
> descheduling. In a vanilla kernel, there can be excessive time spent
> spinning on p->on_rq. This is fine if it's a strictly synchronous wakeup
> and the waker is going to sleep but in other cases,
* Ard Biesheuvel wrote:
> On Sun, 24 May 2020 at 17:08, Ingo Molnar wrote:
> >
> >
> > * Ard Biesheuvel wrote:
> >
> > > The .got.plt section contains the part of the GOT which is used by PLT
> > > entries, and which gets updated lazily by
* Ard Biesheuvel wrote:
> Eliminate all GOT entries in the decompressor binary, by forcing hidden
> visibility for all symbol references, which informs the compiler that
> such references will be resolved at link time without the need for
> allocating GOT entries.
>
> To ensure that no GOT
* Ard Biesheuvel wrote:
> The .got.plt section contains the part of the GOT which is used by PLT
> entries, and which gets updated lazily by the dynamic loader when
> function calls are dispatched through those PLT entries.
>
> On fully linked binaries such as the kernel proper or the
The following commit has been merged into the locking/kcsan branch of tip:
Commit-ID: eba9c444d34c9f10cbb463329c2c8e14f2adff25
Gitweb:
https://git.kernel.org/tip/eba9c444d34c9f10cbb463329c2c8e14f2adff25
Author:Ingo Molnar
AuthorDate:Mon, 13 Apr 2020 11:03:05 +02:00
* Thomas Hellstrom wrote:
> On 10/22/19 10:17 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > n commit
> >
> > 6fee2a0be0ec ("x86/cpu/vmware: Fix platform detection VMWARE_PORT macro")
> >
> > Fixes tag
> >
> > Fixes: b4dd4f6e3648 ("Add a header file for hypercall definitions")
>
> The
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo/Thomas,
>
> Please consider pulling,
>
> Best regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 39b656ee9f2ce41eb969c86525f9a2a63fefac5b:
>
> Merge tag
* Peter Zijlstra wrote:
> On Mon, Oct 21, 2019 at 11:01:04AM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > Employ the fact that all text must be within a s32 displacement of one
> > > another to shrink the text_poke_loc::addr
* Peter Zijlstra wrote:
> Ftrace was one of the last W^X violators (and KLP it seems). These here
> patches
> move it over to the generic text_poke() interface and thereby get rid of this
> oddity.
>
> The first 6 or so patches are more or less the same as in v3, except it has
> the
> bugs
* Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > * Second step: update all but the first byte of the patched range.
> > */
> > for (do_sync = 0, i = 0; i < nr_entries; i++) {
> > - if (tp[i].len - sizeof(int3) > 0) {
>
* Peter Zijlstra wrote:
> Employ the fact that all text must be within a s32 displacement of one
> another to shrink the text_poke_loc::addr field. Make it relative to
> _stext.
>
> This then shrinks struct text_poke_loc to 16 bytes, and consequently
> increases TP_VEC_MAX from 170 to 256.
>
* Peter Zijlstra wrote:
>* Second step: update all but the first byte of the patched range.
>*/
> for (do_sync = 0, i = 0; i < nr_entries; i++) {
> - if (tp[i].len - sizeof(int3) > 0) {
> + int len = text_opcode_size(tp[i].opcode);
> +
> +
* Peter Zijlstra wrote:
> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -35,18 +35,19 @@ static void bug_at(unsigned char *ip, in
> BUG();
> }
>
> -static void __jump_label_set_jump_code(struct jump_entry *entry,
> -
* Amit Kucheria wrote:
> This allows HW drivers that depend on cpufreq-dt to initialise earlier.
My obsessive-compulsive in-brain spellchecker noticed that the title says
'initialize' (US spelling), while the comment uses 'initialise' (UK
spelling). Just in case this is not some post-Brexit
* Alexey Budankov wrote:
> + /*
> + * PMU specific parts of task perf context may require
> + * additional synchronization, at least for proper Intel
> + * LBR callstack data profiling;
> +
* Vincent Guittot wrote:
> Several wrong task placement have been raised with the current load
> balance algorithm but their fixes are not always straight forward and
> end up with using biased values to force migrations. A cleanup and rework
> of the load balance will help to handle such UCs
* Paul E. McKenney wrote:
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -383,20 +383,22 @@ do {
> \
> } while (0)
>
> /**
> - * rcu_swap_protected() - swap an RCU and a regular pointer
> - *
* Linus Torvalds wrote:
> What you doing the merge does is to turn the multiple merge bases into
> just one point: the thing you merged against now becomes the common
> merge point, and now you have a "two endpoints" for the diffstat: the
> thing you merged against, and your end result are now
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo/Thomas,
>
> Please consider pulling,
>
> Best regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675:
>
> Linux 5.4-rc3 (2019-10-13
* Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (native perf)
> failed like this:
>
> make: execvp: ./check-headers.sh: Permission denied
>
> Caused by commit
>
> 05f2f277053d ("Merge branch 'x86/core'")
>
> which somehow removed execute
* Linus Torvalds wrote:
> On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel wrote:
> >
> > We can generate entropy on almost any CPU, even if it doesn't provide a
> > high-resolution timer for random_get_entropy(). As long as the CPU is
> > not idle, it changed the register file every few cycles.
The following commit has been merged into the perf/core branch of tip:
Commit-ID: ae79d5588a04aec9dc4b0c6df700d131447306e0
Gitweb:
https://git.kernel.org/tip/ae79d5588a04aec9dc4b0c6df700d131447306e0
Author:Ingo Molnar
AuthorDate:Sat, 19 Oct 2019 09:15:27 +02:00
Committer
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> Best regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit f733c6b508bcaa3441ba1eacf16efb9abd47489f:
>
> perf/core: Fix inheritance of
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 68e7a4d66b0ce04bf18ff2ffded5596ab3618585 sched/vtime: Fix
guest/system mis-accounting on task switch
Two fixes: a guest-cputime
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 52e92f409dede388b7dc3ee13491fbf7a80db935 perf/x86/cstate: Add Tiger
Lake CPU support
Mostly tooling fixes, but also a couple of
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: 8d7c6ac3b2371eb1cbc9925a88f4d10efff374de x86/cpu: Add Comet Lake to
the Intel CPU models header
A handful of fixes: a kexec linking
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: 6184488a19be96d89cb6c36fb4bc277198309484 x86: Use the correct SPDX
License Identifier in headers
Fix a couple of SPDX tags in x86
* Andy Lutomirski wrote:
> On Tue, Oct 8, 2019 at 3:41 PM Sami Tolvanen wrote:
> >
> > This patch set changes x86 syscall wrappers and related functions to
> > use function types that match sys_call_ptr_t. This fixes indirect call
> > mismatches with Control-Flow Integrity (CFI) checking.
>
Ralf Ramsauer
> AuthorDate:Mon, 07 Oct 2019 14:38:19 +02:00
> Committer: Ingo Molnar
> CommitterDate: Mon, 07 Oct 2019 17:35:56 +02:00
>
> x86/jailhouse: Enable platform UARTs only if available
Never mind this commit notification - I pulled the two commits for the
t
* kan.li...@linux.intel.com wrote:
> Performance impact:
> The processing time may increase with the LBR stitching approach
> enabled. The impact depends on the number of samples with stitched LBRs.
>
> For sqlite's tcltest,
> perf record --call-graph lbr -- make tcltest
> perf report
* Frederic Weisbecker wrote:
> Extracted from a larger queue that fixes kcpustat on nohz_full, these
> two patches have value on their own as they remove two write barriers
> on nohz_full context switch.
>
> Frederic Weisbecker (2):
> vtime: Rename vtime_account_system() to
* Arvind Sankar wrote:
> With the barrier in there, is there any reason to *not* inline the
> function? barrier_data() is an asm statement that tells the compiler
> that the asm uses the memory that was set to zero, thus preventing it
> from removing the memset even if nothing else uses that
* Jonathan Cameron wrote:
> Done in a somewhat different fashion to arm64.
> Here the infrastructure for memoryless domains was already
> in place. That infrastruture applies just as well to
> domains that also don't have a CPU, hence it works for
> Generic Initiator Domains.
>
> In common
* Alexander Shishkin wrote:
> Commit
>
> b43762ef010 ("perf: Allow normal events to output AUX data")
Missing 'a', the proper SHA1 is:
ab43762ef010 ("perf: Allow normal events to output AUX data")
:-)
> forgets to configure aux_output relation in the inherited groups, which
>
* Ingo Molnar wrote:
> > All the other reasons would require a fairly egregious kernel bug, hence
> > the speculation that the #GP is due to a non-canonical address. Something
> > like the following would be more precise, though highly unlikely to ever
> > be exercis
* Sean Christopherson wrote:
> On Fri, Oct 04, 2019 at 07:39:08AM -0700, Dave Hansen wrote:
> > On 10/4/19 6:45 AM, Changbin Du wrote:
> > > +static inline bool is_canonical_addr(u64 addr)
> > > +{
> > > +#ifdef CONFIG_X86_64
> > > + int shift = 64 - boot_cpu_data.x86_phys_bits;
> >
> > I
* Hans de Goede wrote:
> Hi,
>
> On 07-10-2019 15:09, Ingo Molnar wrote:
> >
> > * Hans de Goede wrote:
> >
> > > Hi,
> > >
> > > On 07-10-2019 10:50, Hans de Goede wrote:
> > > > Hi,
> > > >
> > > &g
* Ingo Molnar wrote:
>
> * Hans de Goede wrote:
>
> > Hi,
> >
> > On 07-10-2019 10:50, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 07-10-2019 05:09, Arvind Sankar wrote:
> > > > Hi, arch/x86/purgatory/purgatory.ro ha
* Kirill A. Shutemov wrote:
> On Mon, Oct 07, 2019 at 03:06:17PM +0200, Ingo Molnar wrote:
> >
> > * Anshuman Khandual wrote:
> >
> > > This adds a test module which will validate architecture page table
> > > helpers
> > > and accessor
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo/Thomas,
>
> Please consider pulling, mostly small fixes, just one extra
> header copied due to linux/fs.h now having parts of it moved to
> linux/fscrypt.h that then needs syncing so that tooling continues to
> build on older systems.
>
>
* Hans de Goede wrote:
> Hi,
>
> On 07-10-2019 10:50, Hans de Goede wrote:
> > Hi,
> >
> > On 07-10-2019 05:09, Arvind Sankar wrote:
> > > Hi, arch/x86/purgatory/purgatory.ro has an undefined symbol
> > > memzero_explicit. This has come from commit 906a4bb97f5d ("crypto:
> > > sha256 - Use
* Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of
* Peter Zijlstra wrote:
> IIRC the recordmcount variant from Steve was also rewriting JMP8 to NOP2
> at build time.
>
> I dug this here link out of my IRC logs:
>
> https://lore.kernel.org/lkml/1318007374.4729.58.ca...@gandalf.stny.rr.com/
Ancient indeed ...
> Looking at that, part of the
[ Sorry, fixed the Cc:lkml line. ]
* Peter Zijlstra wrote:
> These here patches are something I've been poking at for a while,
> enabling jump_label to use 2 byte jumps/nops.
>
> It _almost_ works :-/
>
> That is, you can build some kernels with it (x86_64-defconfig for
> example works
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: b9023b91dd020ad7e093baa5122b6968c48cc9e0 tick: broadcast-hrtimer:
Fix a race in bc_set_next
Fix a broadcast-timer handling race
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 73956fc07dd7b25d4a33ab3fdd6247c60d0b237c membarrier: Fix RCU locking
bug caused by faulty merge
Fix a merge bug that resulted in
or:Mathieu Desnoyers
> AuthorDate:Thu, 19 Sep 2019 13:37:02 -04:00
> Committer: Ingo Molnar
> CommitterDate: Wed, 25 Sep 2019 17:42:30 +02:00
>
> sched/membarrier: Fix p->mm->membarrier_state racy load
> + rcu_read_unlock();
> if
* Arvind Sankar wrote:
> On Sat, Sep 28, 2019 at 12:41:29PM +0000, Ingo Molnar wrote:
> >
> > * Randy Dunlap wrote:
> >
> > > On 9/3/19 8:50 AM, Andreas Smas wrote:
> > > > Hi,
> > > >
> > > > For me, kernels bu
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: ca14c996afe7228ff9b480cf225211cc17212688 x86/purgatory: Disable the
stackleak GCC plugin for the purgatory
A kexec fix for the case
* Randy Dunlap wrote:
> On 9/3/19 8:50 AM, Andreas Smas wrote:
> > Hi,
> >
> > For me, kernels built including this commit
> > b059f801a937 (x86/purgatory: Use CFLAGS_REMOVE rather than reset
> > KBUILD_CFLAGS)
> >
> > results in kexec() failing to load the kernel:
> >
> > kexec: Undefined
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 4892f51ad54ddff2883a60b6ad4323c1f632a9d6 sched/fair: Avoid redundant
EAS calculation
The changes are:
- Apply a number of
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 44e09568cf2d874cb2a8e2ac35acf71a9ae3402b
Gitweb:
https://git.kernel.org/tip/44e09568cf2d874cb2a8e2ac35acf71a9ae3402b
Author:Ingo Molnar
AuthorDate:Wed, 25 Sep 2019 08:38:57 +02:00
Committer
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: e430d802d6a3aaf61bd3ed03d9404888a29b9bf9 timer: Read jiffies once
when forwarding base clk
Fixes a timer expiry bug that would
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 26acf400d2dcc72c7e713e1f55db47ad92010cc2 perf unwind: Fix libunwind
build failure on i386 systems
The only kernel change is comment
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo/Thomas,
>
> Please consider pulling,
>
> Best regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 2b32769700f857a8e608a8ee24080833889965b9:
>
> Merge tag
I'm not 100% sure though - so I've added a few more Cc:s ...
I've also cleaned up the pmd_read_atomic() some more to make it more
readable - see the patch below.
Thanks,
Ingo
==>
From: Ingo Molnar
Date: Wed, 25 Sep 2019 08:38:57 +0200
Subject: [PATCH] x86/mm:
* Song Liu wrote:
>
>
> > On Sep 17, 2019, at 4:35 PM, Linus Torvalds
> > wrote:
> >
> > On Tue, Sep 17, 2019 at 4:29 PM Song Liu wrote:
> >>
> >> How about we just do:
> >>
> >> diff --git i/arch/x86/mm/pti.c w/arch/x86/mm/pti.c
> >> index b196524759ec..0437f65250db 100644
> >> ---
* Eric W. Biederman wrote:
> Ingo Molnar writes:
>
> > - Split it into finer grained steps (3 instead of 2 patches per
> >movement), for easier review and bisection testing:
> >
> > toplevel: Move ipc/ to kernel/ipc/: move the files
> >
* Ingo Molnar wrote:
> Oh, that's a pleasant surprise, I didn't expect _100%_ support! :-)
>
> So I started working on this today and whipped up three of these
> movements, in a 100% scripted fashion.
>
> You can have a sneak preview at the result in this tree:
>
>
* tim.b...@sony.com wrote:
> > -Original Message-
> > From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM
> >
> > * Linus Torvalds wrote:
> >
> > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > > wrote:
> >
* Shuah Khan wrote:
> Right. What you suggesting is very similar to and more complete than
> what I have been thinking about and proposed at the KS kselftest track.
>
> i.e move tools/testing/selftests to kselftest at the root level. I like
> your idea of moving tools/testing up to root and
* Greg KH wrote:
> On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
> >
> > * Linus Torvalds wrote:
> >
> > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > > wrote:
> > > >
> > > > Sorry about that. I am sur
* Shuah Khan wrote:
> I am exploring the possibility to move selftests to a better location
> or add a git alias so it can be found easily. With the addition of
> KUnit and future work that is planned to connect kselftest and KUnit,
> it would make sense have selftests to be in a location
* Linus Torvalds wrote:
> On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> wrote:
> >
> > Sorry about that. I am surprised that none of the other reviewers
> > brought this up.
>
> I think I'm "special".
>
> There was some other similar change a few years ago, which I
> absolutely hated
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo/Thomas,
>
> Please consider pulling,
>
> Best regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 351a1f5c8afa13ea5cfcdae543f6596ef8ebdbd9:
>
> Merge tag
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo/Thomas,
>
> Please consider pulling,
>
> Best regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit e336b4027775cb458dc713745e526fa1a1996b2a:
>
> kprobes: Prohibit probing
* Randy Dunlap wrote:
> On 9/17/19 6:38 AM, Patrick Bellasi wrote:
> >
> > On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
> >
> >> * Randy Dunlap wrote:
> >>
> >>> On 9/16/19 3:38 PM, Mark Brown wrote:
* Randy Dunlap wrote:
> On 9/16/19 3:38 PM, Mark Brown wrote:
> > Hi all,
> >
> > Changes since 20190915:
> >
>
> on x86_64:
>
> when CONFIG_CGROUPS is not set:
>
> CC kernel/sched/core.o
> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
>
{
> __aligned_u64 stack_size;
> __aligned_u64 tls;
> };
> +#endif
Acked-by: Ingo Molnar
Thanks,
Ingo
* Dave Hansen wrote:
> On 9/13/19 2:54 AM, Kirill A. Shutemov wrote:
> > The next major release of distributions expected to have
> > CONFIG_X86_5LEVEL=y.
>
> It's probably worth noting that this exposes to two kinds of possible
> performance issues:
>
> First is the overhead of having the
Linus,
Please pull the latest x86-vmware-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-vmware-for-linus
# HEAD: f7b15c74cffd760ec9959078982d8268a38456c4 input/vmmouse: Update the
backdoor call with support for new instructions
This tree updates
301 - 400 of 32618 matches
Mail list logo
