* Pavel Machek wrote:
> Hi!
>
> > > > > I updated to todays next... and boot crashes with
> > > > >
> > > > > ..
> > > > > Call Trace:
> > > > > kick_ilb
> > > > > trigger_load_balance
> > > > > ? active_load..
> > > > > scheduler_tick
> > > > > update_process_times
> > > > >
* Kees Cook wrote:
> On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/x86/mm/pgtable.c
> >
> > between commit:
> >
> > 184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")
> >
> > from
* Kees Cook wrote:
> On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/x86/mm/pgtable.c
> >
> > between commit:
> >
> > 184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")
> >
> > from
hi Nicholas,
I was wondering about this paragraph:
> Using on-stack completions for code that calls any of the _timeout or
> _interruptible/_killable variants is not advisable as they will require
> additional synchronization to prevent the on-stack completion object in
> the timeout/signal
hi Nicholas,
I was wondering about this paragraph:
> Using on-stack completions for code that calls any of the _timeout or
> _interruptible/_killable variants is not advisable as they will require
> additional synchronization to prevent the on-stack completion object in
> the timeout/signal
* Hans de Goede wrote:
> +int iosf_mbi_block_punit_i2c_access(void)
> +{
> + unsigned long start, end;
> + int ret = 0;
> + u32 sem;
> +
> + if (WARN_ON(!mbi_pdev || !iosf_mbi_sem_address))
> + return -ENXIO;
> +
> +
* Hans de Goede wrote:
> +int iosf_mbi_block_punit_i2c_access(void)
> +{
> + unsigned long start, end;
> + int ret = 0;
> + u32 sem;
> +
> + if (WARN_ON(!mbi_pdev || !iosf_mbi_sem_address))
> + return -ENXIO;
> +
> +
Greg,
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: 184d47f0fd365108bd06ab26cdb3450b716269fd x86/mm: Avoid VLA in
pgd_alloc()
An intel_rdt memory access fix and a VLA fix in pgd_alloc().
Greg,
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: 184d47f0fd365108bd06ab26cdb3450b716269fd x86/mm: Avoid VLA in
pgd_alloc()
An intel_rdt memory access fix and a VLA fix in pgd_alloc().
Greg,
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: e054637597ba36d3729ba6a3a3dd7aad8e2a3003 mm, sched/numa: Remove
remaining traces of NUMA rate-limiting
Cleanup of dead code left
Greg,
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: e054637597ba36d3729ba6a3a3dd7aad8e2a3003 mm, sched/numa: Remove
remaining traces of NUMA rate-limiting
Cleanup of dead code left
Greg,
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: c1883f10cfe05c707cce46d6999411c50a2413ca Merge tag
'perf-urgent-for-mingo-4.19-20181005' of
Greg,
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: c1883f10cfe05c707cce46d6999411c50a2413ca Merge tag
'perf-urgent-for-mingo-4.19-20181005' of
Greg,
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: e054637597ba36d3729ba6a3a3dd7aad8e2a3003 mm, sched/numa: Remove
remaining traces of NUMA rate-limiting
Cleanup of dead code left
Greg,
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: e054637597ba36d3729ba6a3a3dd7aad8e2a3003 mm, sched/numa: Remove
remaining traces of NUMA rate-limiting
Cleanup of dead code left
Greg,
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: c1883f10cfe05c707cce46d6999411c50a2413ca Merge tag
'perf-urgent-for-mingo-4.19-20181005' of
Greg,
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: c1883f10cfe05c707cce46d6999411c50a2413ca Merge tag
'perf-urgent-for-mingo-4.19-20181005' of
Commit-ID: 0c373344b5c1eaa9e186368a32a169a2802be3ca
Gitweb: https://git.kernel.org/tip/0c373344b5c1eaa9e186368a32a169a2802be3ca
Author: Ingo Molnar
AuthorDate: Thu, 11 Oct 2018 10:36:23 +0200
Committer: Ingo Molnar
CommitDate: Thu, 11 Oct 2018 10:36:23 +0200
sched/completions
Commit-ID: 0c373344b5c1eaa9e186368a32a169a2802be3ca
Gitweb: https://git.kernel.org/tip/0c373344b5c1eaa9e186368a32a169a2802be3ca
Author: Ingo Molnar
AuthorDate: Thu, 11 Oct 2018 10:36:23 +0200
Committer: Ingo Molnar
CommitDate: Thu, 11 Oct 2018 10:36:23 +0200
sched/completions
ns(-)
If the problem is fixed then the e820 revert looks good to me:
Acked-by: Ingo Molnar
The other patches need review and acks from MM folks, and the series (assuming
all patches are
fine - I only looked at the e820 one) is -mm material I suppose?
Thanks,
Ingo
ns(-)
If the problem is fixed then the e820 revert looks good to me:
Acked-by: Ingo Molnar
The other patches need review and acks from MM folks, and the series (assuming
all patches are
fine - I only looked at the e820 one) is -mm material I suppose?
Thanks,
Ingo
* Sandipan Das wrote:
> Hi Jiri,
>
> Yes, this happens when entry->map is NULL. While your fix seems correct, the
> following commit from Milian Wolff had already addressed this. I think this
> was pulled in with one of Arnaldo's recent perf/urgent updates.
>
> ff4ce2885af8 ("perf report:
* Sandipan Das wrote:
> Hi Jiri,
>
> Yes, this happens when entry->map is NULL. While your fix seems correct, the
> following commit from Milian Wolff had already addressed this. I think this
> was pulled in with one of Arnaldo's recent perf/urgent updates.
>
> ff4ce2885af8 ("perf report:
* Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel, in event of maximum
> frequency
* Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel, in event of maximum
> frequency
nst char *fmt, ...)
> console_verbose();
> bust_spinlocks(1);
> va_start(args, fmt);
> - vsnprintf(buf, sizeof(buf), fmt, args);
> + len = vscnprintf(buf, sizeof(buf), fmt, args);
> va_end(args);
> +
> + if (len && buf[len - 1] =
nst char *fmt, ...)
> console_verbose();
> bust_spinlocks(1);
> va_start(args, fmt);
> - vsnprintf(buf, sizeof(buf), fmt, args);
> + len = vscnprintf(buf, sizeof(buf), fmt, args);
> va_end(args);
> +
> + if (len && buf[len - 1] =
* Yi Sun wrote:
> On 18-10-09 12:54:27, Ingo Molnar wrote:
> >
> > * Yi Sun wrote:
> >
> > > Follow PV spinlock mechanism to implement the callback functions
> > > to allow the CPU idling and kicking operations on Hype
* Yi Sun wrote:
> On 18-10-09 12:54:27, Ingo Molnar wrote:
> >
> > * Yi Sun wrote:
> >
> > > Follow PV spinlock mechanism to implement the callback functions
> > > to allow the CPU idling and kicking operations on Hype
* Yi Sun wrote:
> Follow PV spinlock mechanism to implement the callback functions
> to allow the CPU idling and kicking operations on Hyper-V.
> +#if defined(CONFIG_SMP)
> + smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> +#endif
What's wrong with using the common pattern of:
* Yi Sun wrote:
> Follow PV spinlock mechanism to implement the callback functions
> to allow the CPU idling and kicking operations on Hyper-V.
> +#if defined(CONFIG_SMP)
> + smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> +#endif
What's wrong with using the common pattern of:
t; Signed-off-by: Phil Auld
> Fixes: c06f04c70489 ("sched: Fix potential near-infinite
> distribute_cfs_runtime() loop")
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: sta...@vger.kernel.org
> ---
>
> This is easy to reproduce with a handful of cpu consu
t; Signed-off-by: Phil Auld
> Fixes: c06f04c70489 ("sched: Fix potential near-infinite
> distribute_cfs_runtime() loop")
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: sta...@vger.kernel.org
> ---
>
> This is easy to reproduce with a handful of cpu consu
* Joerg Roedel wrote:
> Hi Arnd,
>
> On Tue, Oct 09, 2018 at 09:33:56AM +0200, Arnd Bergmann wrote:
> > Ah, cool, thanks for the analysis. Is the patch already reverted?
> > I.e. should I send a replacement patch, or a relative fix, or is
> > someone else already on it?
>
> Kees sent a fix
* Joerg Roedel wrote:
> Hi Arnd,
>
> On Tue, Oct 09, 2018 at 09:33:56AM +0200, Arnd Bergmann wrote:
> > Ah, cool, thanks for the analysis. Is the patch already reverted?
> > I.e. should I send a replacement patch, or a relative fix, or is
> > someone else already on it?
>
> Kees sent a fix
* Mel Gorman wrote:
> On Sat, Oct 06, 2018 at 04:53:19PM +0530, Srikar Dronamraju wrote:
> > With Commit efaffc5e40ae ("mm, sched/numa: Remove rate-limiting of automatic
> > NUMA balancing migration"), we no more require migrate lock and its
> > initialization. Its redundant. Hence remove it.
* Mel Gorman wrote:
> On Sat, Oct 06, 2018 at 04:53:19PM +0530, Srikar Dronamraju wrote:
> > With Commit efaffc5e40ae ("mm, sched/numa: Remove rate-limiting of automatic
> > NUMA balancing migration"), we no more require migrate lock and its
> > initialization. Its redundant. Hence remove it.
* Josh Poimboeuf wrote:
> > 4. Would a command line parameter be reasonable `disable_unwind`, so people
> > could decrease their boot time with distribution kernels, and easily turn it
> > back on, when they need a stacktrace without having to rebuild the Linux
> > kernel?
>
> I think a boot
* Josh Poimboeuf wrote:
> > 4. Would a command line parameter be reasonable `disable_unwind`, so people
> > could decrease their boot time with distribution kernels, and easily turn it
> > back on, when they need a stacktrace without having to rebuild the Linux
> > kernel?
>
> I think a boot
* Josh Poimboeuf wrote:
> On Mon, Oct 08, 2018 at 12:34:17PM -0500, Josh Poimboeuf wrote:
> > > 4. Would a command line parameter be reasonable `disable_unwind`, so
> > > people
> > > could decrease their boot time with distribution kernels, and easily turn
> > > it
> > > back on, when they
* Josh Poimboeuf wrote:
> On Mon, Oct 08, 2018 at 12:34:17PM -0500, Josh Poimboeuf wrote:
> > > 4. Would a command line parameter be reasonable `disable_unwind`, so
> > > people
> > > could decrease their boot time with distribution kernels, and easily turn
> > > it
> > > back on, when they
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 7c5314b88da6d5af98239786772a1c44cc5eb67d:
>
> perf/x86/intel: Add quirk for Goldmont Plus
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 7c5314b88da6d5af98239786772a1c44cc5eb67d:
>
> perf/x86/intel: Add quirk for Goldmont Plus
Commit-ID: 22245bdf0ad805d6c29f82b6d5e977ee94bb2166
Gitweb: https://git.kernel.org/tip/22245bdf0ad805d6c29f82b6d5e977ee94bb2166
Author: Ingo Molnar
AuthorDate: Mon, 8 Oct 2018 10:41:59 +0200
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:45:02 +0200
x86/segments: Introduce
Commit-ID: ec3a94188df7d28b374868d9a2a0face910e62ab
Gitweb: https://git.kernel.org/tip/ec3a94188df7d28b374868d9a2a0face910e62ab
Author: Ingo Molnar
AuthorDate: Mon, 8 Oct 2018 10:41:59 +0200
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:45:04 +0200
x86/fsgsbase/64: Clean up
Commit-ID: 22245bdf0ad805d6c29f82b6d5e977ee94bb2166
Gitweb: https://git.kernel.org/tip/22245bdf0ad805d6c29f82b6d5e977ee94bb2166
Author: Ingo Molnar
AuthorDate: Mon, 8 Oct 2018 10:41:59 +0200
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:45:02 +0200
x86/segments: Introduce
Commit-ID: ec3a94188df7d28b374868d9a2a0face910e62ab
Gitweb: https://git.kernel.org/tip/ec3a94188df7d28b374868d9a2a0face910e62ab
Author: Ingo Molnar
AuthorDate: Mon, 8 Oct 2018 10:41:59 +0200
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:45:04 +0200
x86/fsgsbase/64: Clean up
* Chang S. Bae wrote:
> The CPU and node number will be written, as early enough,
> to the segment limit of per CPU data and TSC_AUX MSR entry.
> The information has been retrieved by vgetcpu in user space
> and will be also loaded from the paranoid entry, when
> FSGSBASE enabled.
>
> The new
* Chang S. Bae wrote:
> The CPU and node number will be written, as early enough,
> to the segment limit of per CPU data and TSC_AUX MSR entry.
> The information has been retrieved by vgetcpu in user space
> and will be also loaded from the paranoid entry, when
> FSGSBASE enabled.
>
> The new
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 5d05dfd13f20b01a3cd5d293058baa7d5c1583b6:
>
> Merge tag 'perf-urgent-for-mingo-4.19-20180918' of
>
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 5d05dfd13f20b01a3cd5d293058baa7d5c1583b6:
>
> Merge tag 'perf-urgent-for-mingo-4.19-20180918' of
>
* Borislav Petkov wrote:
> On Fri, Oct 05, 2018 at 11:31:08AM +0200, Ingo Molnar wrote:
> >
> > * Nadav Amit wrote:
> >
> > > > Are you using defconfig or a reasonable distro-config for your tests?
> > >
> > > I think it is best to
* Borislav Petkov wrote:
> On Fri, Oct 05, 2018 at 11:31:08AM +0200, Ingo Molnar wrote:
> >
> > * Nadav Amit wrote:
> >
> > > > Are you using defconfig or a reasonable distro-config for your tests?
> > >
> > > I think it is best to
* Ingo Molnar wrote:
> Linus,
... and Greg as well!! ;-)
Thanks,
Ingo
ps. script fixed.
* Ingo Molnar wrote:
> Linus,
... and Greg as well!! ;-)
Thanks,
Ingo
ps. script fixed.
Greg,
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: 02e425668f5c9deb42787d10001a3b605993ad15 x86/vdso: Fix vDSO syscall
fallback asm constraint regression
Misc fixes:
- fix various
Greg,
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: 02e425668f5c9deb42787d10001a3b605993ad15 x86/vdso: Fix vDSO syscall
fallback asm constraint regression
Misc fixes:
- fix various
Greg,
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: 37355bdc5a129899f6b245900a8eb944a092f7fd sched/numa: Migrate pages
to local nodes quicker early in the lifetime of a task
These
Greg,
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: 37355bdc5a129899f6b245900a8eb944a092f7fd sched/numa: Migrate pages
to local nodes quicker early in the lifetime of a task
These
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: d7cbbe49a9304520181fb8c9272d1327deec8453 perf/x86/amd/uncore: Set
ThreadMask and SliceMask for L3 Cache perf events
Misc fixes:
-
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: d7cbbe49a9304520181fb8c9272d1327deec8453 perf/x86/amd/uncore: Set
ThreadMask and SliceMask for L3 Cache perf events
Misc fixes:
-
Greg,
Please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
# HEAD: e4a02ed2aaf447fa849e3254bfdb3b9b01e1e520 locking/ww_mutex: Fix
runtime warning in the WW mutex selftest
A fix in the ww_mutex
Greg,
Please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
# HEAD: e4a02ed2aaf447fa849e3254bfdb3b9b01e1e520 locking/ww_mutex: Fix
runtime warning in the WW mutex selftest
A fix in the ww_mutex
t
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Philippe Ombredanne
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20181003213100.189959-11-na...@vmware.com
Signed-off-by: Ingo Molnar
commit dfc243615d43bb477d1d16a0064fc3d69ade5b3a
Author: Nadav Amit
Date: Wed Oct 3 14:
t
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Philippe Ombredanne
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20181003213100.189959-11-na...@vmware.com
Signed-off-by: Ingo Molnar
commit dfc243615d43bb477d1d16a0064fc3d69ade5b3a
Author: Nadav Amit
Date: Wed Oct 3 14:
* Waiman Long wrote:
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index b0d0b51c4d85..1fd82ff99c65 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -99,13 +99,8 @@ struct lock_class {
>*/
> unsigned intversion;
* Waiman Long wrote:
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index b0d0b51c4d85..1fd82ff99c65 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -99,13 +99,8 @@ struct lock_class {
>*/
> unsigned intversion;
* Nadav Amit wrote:
> > Another, separate question I wanted to ask: how do we ensure that the
> > kernel stays fixed?
> > I.e. is there some tooling we can use to actually measure whether there's
> > bad inlining decisions
> > done, to detect all these bad patterns that cause bad GCC code
* Nadav Amit wrote:
> > Another, separate question I wanted to ask: how do we ensure that the
> > kernel stays fixed?
> > I.e. is there some tooling we can use to actually measure whether there's
> > bad inlining decisions
> > done, to detect all these bad patterns that cause bad GCC code
* h...@zytor.com wrote:
> Ingo: I wasn't talking necessarily about the specifics of each bit, but
> rather the general
> concept about being able to use macros in inlines...
Ok, agreed about that part - and some of the patches did improve readability.
Also, the 275 lines macros.s is a lot
* h...@zytor.com wrote:
> Ingo: I wasn't talking necessarily about the specifics of each bit, but
> rather the general
> concept about being able to use macros in inlines...
Ok, agreed about that part - and some of the patches did improve readability.
Also, the 275 lines macros.s is a lot
* Nadav Amit wrote:
> I can run some tests. (@hpa: I thought you asked about the -pipe overhead;
> perhaps I misunderstood).
Well, tests are unlikely to show the overhead of extra lines of this
magnitude, unless done very carefully, yet the added bloat exists and is not
even
mentioned by the
* Nadav Amit wrote:
> I can run some tests. (@hpa: I thought you asked about the -pipe overhead;
> perhaps I misunderstood).
Well, tests are unlikely to show the overhead of extra lines of this
magnitude, unless done very carefully, yet the added bloat exists and is not
even
mentioned by the
* Nadav Amit wrote:
> Finally, note that it’s not as if the binary always becomes smaller.
> Overall, with the full patch-set it is slightly bigger. But still, that’s
> how it was supposed to be if gcc wasn’t doing things badly.
So what I cited was the changelog for the refcount patch, which
* Nadav Amit wrote:
> Finally, note that it’s not as if the binary always becomes smaller.
> Overall, with the full patch-set it is slightly bigger. But still, that’s
> how it was supposed to be if gcc wasn’t doing things badly.
So what I cited was the changelog for the refcount patch, which
* h...@zytor.com wrote:
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for
> cleaning up the inline asm in general.
Sorry but that's just plain false. For example this patch:
x86: cpufeature: use macros instead of inline assembly
... adds an
* h...@zytor.com wrote:
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for
> cleaning up the inline asm in general.
Sorry but that's just plain false. For example this patch:
x86: cpufeature: use macros instead of inline assembly
... adds an
* Ingo Molnar wrote:
> I'm also somewhat annoyed at the fact that this series carries a boatload
> of reviewed-by's and acked-by's, yet none of those reviewers found it
> important to point out the large chasm that is gaping between description
> and reality.
Another problem I j
* Ingo Molnar wrote:
> I'm also somewhat annoyed at the fact that this series carries a boatload
> of reviewed-by's and acked-by's, yet none of those reviewers found it
> important to point out the large chasm that is gaping between description
> and reality.
Another problem I j
istic, it might still happen, any decade
now.
[ mingo: Wrote new changelog. ]
Tested-by: Kees Cook
Signed-off-by: Nadav Amit
Acked-by: Peter Zijlstra (Intel)
Cc: Borislav Petkov
Cc: Jan Beulich
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20181003213100.189959-5-na...@vmware.com
Signed-off-by: Ingo Molnar
---
istic, it might still happen, any decade
now.
[ mingo: Wrote new changelog. ]
Tested-by: Kees Cook
Signed-off-by: Nadav Amit
Acked-by: Peter Zijlstra (Intel)
Cc: Borislav Petkov
Cc: Jan Beulich
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20181003213100.189959-5-na...@vmware.com
Signed-off-by: Ingo Molnar
---
* Jann Horn wrote:
> Hi!
>
> I noticed that X86-64 is using the generic string functions from
> lib/string.c for things like strlen(), strchr(), memcmp() and so on.
> Is that an intentional omission, because they're not considered worth
> optimizing, or is this an oversight? The kernel
* Jann Horn wrote:
> Hi!
>
> I noticed that X86-64 is using the generic string functions from
> lib/string.c for things like strlen(), strchr(), memcmp() and so on.
> Is that an intentional omission, because they're not considered worth
> optimizing, or is this an oversight? The kernel
* Peter Zijlstra wrote:
> On Tue, Oct 02, 2018 at 04:19:19PM -0400, Waiman Long wrote:
> > +DEFINE_PER_CPU(unsigned long [MAX_LOCKDEP_KEYS], lock_class_ops);
>
> > @@ -179,9 +181,30 @@ DECLARE_PER_CPU(struct lockdep_stats, lockdep_stats);
> > }
* Peter Zijlstra wrote:
> On Tue, Oct 02, 2018 at 04:19:19PM -0400, Waiman Long wrote:
> > +DEFINE_PER_CPU(unsigned long [MAX_LOCKDEP_KEYS], lock_class_ops);
>
> > @@ -179,9 +181,30 @@ DECLARE_PER_CPU(struct lockdep_stats, lockdep_stats);
> > }
* Tim Chen wrote:
> Thanks for the corrections. I'll update the patchset.
Please also go beyond the direct review feedback me and Thomas gave, and
pro-actively look out
for similar patterns of mistakes in these patches and in all future patches you
send.
As Thomas's and my review made it
* Tim Chen wrote:
> Thanks for the corrections. I'll update the patchset.
Please also go beyond the direct review feedback me and Thomas gave, and
pro-actively look out
for similar patterns of mistakes in these patches and in all future patches you
send.
As Thomas's and my review made it
* Masayoshi Mizuma wrote:
> This patch series are adding an kernel parameter to change
> the padding size used for KASLR. It is useful for memory hotplug
> capable system. User can adjust the padding size to use it.
>
> It is better if the padding size is calculated automatically,
> however,
* Masayoshi Mizuma wrote:
> This patch series are adding an kernel parameter to change
> the padding size used for KASLR. It is useful for memory hotplug
> capable system. User can adjust the padding size to use it.
>
> It is better if the padding size is calculated automatically,
> however,
* Peter Zijlstra wrote:
> On Tue, Oct 02, 2018 at 10:10:48AM -0400, Waiman Long wrote:
> > One alternative is to group it under CONFIG_DEBUG_LOCKDEP again. This
> > metric was originally under CONFIG_DEBUG_LOCKDEP, but was moved to
> > CONFIG_LOCKDEP when trying to make other lock debugging
* Peter Zijlstra wrote:
> On Tue, Oct 02, 2018 at 10:10:48AM -0400, Waiman Long wrote:
> > One alternative is to group it under CONFIG_DEBUG_LOCKDEP again. This
> > metric was originally under CONFIG_DEBUG_LOCKDEP, but was moved to
> > CONFIG_LOCKDEP when trying to make other lock debugging
* Nadav Amit wrote:
> at 1:58 AM, Rasmus Villemoes wrote:
>
> > On 2018-09-18 23:28, Nadav Amit wrote:
> >
> >> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> >> index 8f6e7eb8ae9f..944fa3bc9376 100644
> >> --- a/arch/x86/Makefile
> >> +++ b/arch/x86/Makefile
> >> @@ -214,8 +214,8 @@
* Nadav Amit wrote:
> at 1:58 AM, Rasmus Villemoes wrote:
>
> > On 2018-09-18 23:28, Nadav Amit wrote:
> >
> >> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> >> index 8f6e7eb8ae9f..944fa3bc9376 100644
> >> --- a/arch/x86/Makefile
> >> +++ b/arch/x86/Makefile
> >> @@ -214,8 +214,8 @@
* Peter Zijlstra wrote:
> On Fri, Sep 28, 2018 at 01:53:20PM -0400, Waiman Long wrote:
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index ca002c0..7a0ed1d 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -139,6 +139,7 @@ static
* Peter Zijlstra wrote:
> On Fri, Sep 28, 2018 at 01:53:20PM -0400, Waiman Long wrote:
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index ca002c0..7a0ed1d 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -139,6 +139,7 @@ static
"\t.long 0\t# \n" \
> + _DPRINTK_ASM_KEY_INIT \
> + ".popsection\n" \
> + ".endif\n" \
> + : : "i" (KBUILD_MODNAME), "i" (__func__), \
> +"i" (__FILE__), "i" (fmt), \
> +"i" (_DPRINTK_FLAGS_LINENO_INIT))
> +
> +#endif /* _ASM_X86_DYNAMIC_DEBUG_H */
> +
Reviewed-by: Ingo Molnar
Thanks,
Ingo
"\t.long 0\t# \n" \
> + _DPRINTK_ASM_KEY_INIT \
> + ".popsection\n" \
> + ".endif\n" \
> + : : "i" (KBUILD_MODNAME), "i" (__func__), \
> +"i" (__FILE__), "i" (fmt), \
> +"i" (_DPRINTK_FLAGS_LINENO_INIT))
> +
> +#endif /* _ASM_X86_DYNAMIC_DEBUG_H */
> +
Reviewed-by: Ingo Molnar
Thanks,
Ingo
h
> +++ b/include/linux/jump_label.h
> @@ -132,6 +132,8 @@ struct module;
>
> #ifdef HAVE_JUMP_LABEL
>
> +#define __JUMP_TYPE_FALSE0
> +#define __JUMP_TYPE_TRUE 1
> #define JUMP_TYPE_FALSE 0UL
> #define JUMP_TYPE_TRUE 1UL
> #define JUMP_TYPE_LINKED 2UL
Looks sane!
Reviewed-by: Ingo Molnar
Thanks,
Ingo
h
> +++ b/include/linux/jump_label.h
> @@ -132,6 +132,8 @@ struct module;
>
> #ifdef HAVE_JUMP_LABEL
>
> +#define __JUMP_TYPE_FALSE0
> +#define __JUMP_TYPE_TRUE 1
> #define JUMP_TYPE_FALSE 0UL
> #define JUMP_TYPE_TRUE 1UL
> #define JUMP_TYPE_LINKED 2UL
Looks sane!
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
> memblock.reserved") breaks movable_node kernel option because it
> changed the memory gap range to reserved memblock. So, the node
> is marked as Normal zone even if the
1201 - 1300 of 32618 matches
Mail list logo
