On 2017.12.25 at 10:54 +0100, Pavel Machek wrote:
> On Mon 2017-12-25 09:47:48, Markus Trippelsdorf wrote:
> > On 2017.12.24 at 23:37 +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > > > 4.15-rcX is broken, but that had o
On 2017.12.24 at 23:37 +0100, Pavel Machek wrote:
> Hi!
>
> > > > > > 4.15-rcX is broken, but that had other problems so lets not go
> > > > > > there.
> > > > > >
> > > > > > 4.14 is broken.
> > > > >
> > > > > And what exactly does happen?
> > > >
> > > > Suspend looks ok. I believe there's
On 2017.11.09 at 10:22 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 09, 2017 at 09:17:49AM +0100, Jiri Olsa escreveu:
> > Reply-To:
> > In-Reply-To: <20171109081319.GB236@x4>
> >
> > On Thu, Nov 09, 2017 at 09:13:19AM +0100, Markus Trippelsdorf wrote:
&
On 2017.11.05 at 15:40 +0100, Ingo Molnar wrote:
> 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
>
> Jiri Olsa (1):
> perf tools: Unwind properly location after REJECT
The patch
On 2017.10.23 at 11:48 +0300, Dan Carpenter wrote:
> This business of moving the error code to the bottom of the function
> just makes the code less readable. I know you never listen to anyone,
> but you should stop doing it.
How long have we to put up with this?
He just keeps sending these crap
On 2017.10.16 at 18:06 -0700, Andy Lutomirski wrote:
> On Mon, Oct 16, 2017 at 3:15 AM, Borislav Petkov wrote:
> > On Mon, Oct 16, 2017 at 10:39:17AM +0800, kernel test robot wrote:
> >>
> >> Greeting,
> >>
> >> FYI, we noticed a -61.0% regression of will-it-scale.per_process_ops due
> >> to comm
On 2017.10.13 at 13:39 +0200, Prakash Punnoor wrote:
> after some use (eg. compiling packages) the machine locks up hard. Magic
> SysRq doesn't work.
>
> I had trouble bisecting the offending commit. This is my third try. And
> it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from
internal superblock flags") the lazytime mount option doesn't get passed
on anymore.
Fix the issue by handling the option in do_mount().
Reviewed-by: Lukas Czerner
Signed-off-by: Markus Trippelsdorf
---
fs/
On 2017.10.09 at 09:50 -0700, Andy Lutomirski wrote:
> Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way
> lazy: when running a kernel thread (including the idle thread), the
> kernel keeps using the last user mm's page tables without attempting
> to maintain user TLB coherence at
On 2017.09.30 at 10:20 -0400, Brian Gerst wrote:
> On Sat, Sep 30, 2017 at 8:47 AM, Markus Trippelsdorf
> wrote:
> > On 2017.09.30 at 13:53 +0200, Borislav Petkov wrote:
> >> On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote:
> >> > On Sat, Sep 30, 2
On 2017.09.30 at 13:53 +0200, Borislav Petkov wrote:
> On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote:
> > On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote:
> > > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote:
> > > > Any hints how to debug this?
> > >
On 2017.09.19 at 17:25 +0200, Lukas Czerner wrote:
> On Tue, Sep 19, 2017 at 12:37:24PM +0200, Markus Trippelsdorf wrote:
> > Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from
> > internal superblock flags") the lazytime mount option didn&#x
On 2017.09.22 at 13:54 +0200, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 11:35:33AM +0200, Markus Trippelsdorf wrote:
> > > It seems to work. Simply returning "I (idle)" from get_task_state() in
> > > fs/proc/array.c when the state is TASK_IDLE does the trick.
On 2017.09.21 at 16:41 +0200, Markus Trippelsdorf wrote:
> On 2017.09.21 at 14:30 +0200, Peter Zijlstra wrote:
> > On Thu, Sep 21, 2017 at 01:08:42PM +0200, Markus Trippelsdorf wrote:
> > > On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote:
> > > > On 2017.0
On 2017.09.21 at 14:30 +0200, Peter Zijlstra wrote:
> On Thu, Sep 21, 2017 at 01:08:42PM +0200, Markus Trippelsdorf wrote:
> > On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote:
> > > On 2017.09.11 at 06:11 -0700, Tejun Heo wrote:
> > > > Hello,
> > >
On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote:
> On 2017.09.11 at 06:11 -0700, Tejun Heo wrote:
> > Hello,
> >
> > On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote:
> > > Since:
> > >
> > > commit c5a94a618e7ac86b20f53d
Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from
internal superblock flags") the lazytime mount option didn't get passed
on anymore.
Fix the issue by handling the option in do_mount().
Signed-off-by: Markus Trippelsdorf
---
fs/namespace.c | 3 ++-
1
The lazytime option didn't get passed on when using current util-linux,
which passes MS_LAZYTIME in the mountflags directly.
Fix the issue by handling the option in do_mount().
Signed-off-by: Markus Trippelsdorf
---
fs/namespace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On 2017.09.16 at 09:55 -0700, Greg KH wrote:
> On Sat, Sep 16, 2017 at 08:25:03AM +0200, Markus Trippelsdorf wrote:
> > On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote:
> > > On 2017.09.15 at 11:56 -0700, Greg KH wrote:
> > > > The
ry minimum. The default for
EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/.
Fixes: 5620a0d1aac ("firmware: delete in-kernel firmware")
Signed-off-by: Markus Trippelsdorf
---
Makefile | 2 +-
drivers/base/Kconfig | 5 +
firmware/.gitignore | 6
On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote:
> On 2017.09.15 at 11:56 -0700, Greg KH wrote:
> > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261:
> >
> > Linux 4.13 (2017-09-03 13:56:17 -0700)
> >
> > are available in the
On 2017.09.15 at 11:56 -0700, Greg KH wrote:
> The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261:
>
> Linux 4.13 (2017-09-03 13:56:17 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/
> tags/fi
On 2017.09.09 at 11:26 -0700, Linus Torvalds wrote:
> On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf
> wrote:
> >
> > I think the issue gets fixed by:
> >
> > # wrmsr -a 0xc0010015 0x118
> >
> > Setting bit 3 of the Hardware Configuration
On 2017.09.11 at 06:11 -0700, Tejun Heo wrote:
> Hello,
>
> On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote:
> > Since:
> >
> > commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc
> > Author: Peter Zijlstra
> > Date: Wed Aug 23 13:58:44
Since:
commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc
Author: Peter Zijlstra
Date: Wed Aug 23 13:58:44 2017 +0200
workqueue: Use TASK_IDLE
all worker threads are in D state. They all show up when using "magic
SysRq w". In htop they all have big fat red 'D' in the state column.
Is th
On 2017.09.09 at 20:26 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote:
> > # wrmsr -a 0xc0010015 0x118
>
> I know but I'd still like to see the exact error signature.
>
> So please clear that bit 3 and try to ca
On 2017.09.09 at 19:36 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote:
> > Hmm, the output is exactly the same as before your patch.
>
> Bah, that patch doesn't account for the fact that we're rereading th
On 2017.09.09 at 19:05 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote:
> > Also tried the following patch. It does not help.
>
> Ok, another theory. This one still needs to be fixed properly but that
> for later.
&g
On 2017.09.09 at 16:43 +0200, Markus Trippelsdorf wrote:
> On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote:
> > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > > > # rdmsr -a 0x0410
> > >
> > > 3fff
> > > 0
>
On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > > # rdmsr -a 0x0410
> >
> > 3fff
> > 0
> > 0
> > 0
>
> WTF?! Those should be equal on every CPU. Yi
On 2017.09.09 at 16:07 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote:
> > > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4:
> > > fa1b0c0f
> > > mce: [Hardware Error]: TSC b75d6ef4ad
On 2017.09.09 at 15:37 +0200, Markus Trippelsdorf wrote:
> On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote:
> > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> > > It doesn't work. Compiling in a text console just freezes the machine
> >
On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> > It doesn't work. Compiling in a text console just freezes the machine
> > before any MCE gets printed.
>
> Ok, let's turn off all s
On 2017.09.09 at 12:18 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote:
> > Unfortunately the machine hangs in the BIOS after the first warm-reset.
> > Probably when it encounters an MCE it doesn't expect. I have to
> >
On 2017.09.08 at 14:47 -0700, Andy Lutomirski wrote:
> On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf
> wrote:
> > On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
> >> wrote:
> >>
On 2017.09.08 at 23:56 +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
> > Any chance you could test with CONFIG_DEBUG_VM=y? There are lots of
> > potentially useful assertions in that code.
> >
> > Can you also post your /proc/cpuinfo? And can yo
On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
> wrote:
> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> >> >
> >> > * M
On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> >
> > * Markus Trippelsdorf wrote:
> >
> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > > > On Fri, Sep 08, 2017 at 10:05:36AM
On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
>
> * Markus Trippelsdorf wrote:
>
> > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > > On Fri, Sep 08, 2017 at 08:
On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > >
> > > CC+ Bo
On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote:
> On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > > On 2017.09.05 at 10:
On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > > Any ideas on how to debug this
On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > Any ideas on how to debug this further?
> > >
> > > So you have a (real) serial line on that
On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote:
> > Current mainline git (24e700e291d52bd2) hangs when building software
> > concurrently (for example perf).
> > The issue is not 100% reproducible (so
Current mainline git (24e700e291d52bd2) hangs when building software
concurrently (for example perf).
The issue is not 100% reproducible (sometimes building perf succeeds),
so bisecting will not work.
Magic SysRq key doesn't work and there is nothing in the logs.
Enabling CONFIG_PROVE_LOCKING makes
On 2017.07.31 at 13:04 +0100, Alan Cox wrote:
> On Wed, 26 Jul 2017 06:54:01 +0900
> Satoru Takeuchi wrote:
>
> > # I'm a LKML subscriber, but not a x86 list subscriber
> >
> > I found the following new linux kernel bugzilla about Ryzen related problem.
> > Since many developers don't check this
On 2017.07.08 at 14:12 +0100, Al Viro wrote:
> On Sat, Jul 08, 2017 at 11:56:44AM +0200, Markus Trippelsdorf wrote:
> > Since:
> > commit 67d7ddded322db99f451a7959d56ed6c70a6c4aa
> > Author: Al Viro
> > Date: Sun May 14 20:53:13 2017 -0400
> >
> >
Since:
commit 67d7ddded322db99f451a7959d56ed6c70a6c4aa
Author: Al Viro
Date: Sun May 14 20:53:13 2017 -0400
waitid(2): leave copyout of siginfo to syscall itself
the glibc posix/tst-waitid.c testcase fails:
markus@x4 glibc-build % ./posix/tst-waitid
waitid WNOHANG on stopped status 0
On 2017.07.04 at 10:31 -0500, Goldwyn Rodrigues wrote:
>
>
> On 07/04/2017 02:45 AM, Markus Trippelsdorf wrote:
> > On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote:
> >> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
> >> Aut
On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote:
> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
> Author: Goldwyn Rodrigues
> Date: Tue Jun 20 07:05:49 2017 -0500
>
> btrfs: nowait aio support
>
> apparently breaks several shell r
commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
Author: Goldwyn Rodrigues
Date: Tue Jun 20 07:05:49 2017 -0500
btrfs: nowait aio support
apparently breaks several shell related features on my system.
In zsh history stopped working, because no new entries are added
a
On 2017.05.19 at 17:48 +0200, Peter Zijlstra wrote:
> On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote:
> > On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
>
> > > But it does that after building the tst-robustpi8 thing, so I seem to
> > > have all I need here.
> >
> > Great, have fun
On 2017.05.18 at 09:40 +0200, Peter Zijlstra wrote:
> On Wed, May 17, 2017 at 07:36:46PM +0200, Markus Trippelsdorf wrote:
> > Since:
> > commit cfafcd117da0216520568c195cb2f6cd1980c4bb
> > Author: Peter Zijlstra
> > Date: Wed Mar 22 11:35:58 2017 +0100
> >
&g
Since:
commit cfafcd117da0216520568c195cb2f6cd1980c4bb
Author: Peter Zijlstra
Date: Wed Mar 22 11:35:58 2017 +0100
futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
glibc's nptl/tst-robustpi8 testcase fails:
glibc-build % ./nptl/tst-robustpi8
tst-robustpi8: ../nptl/pthread_mute
On 2017.05.09 at 21:00 -0600, Jens Axboe wrote:
> On 05/09/2017 08:20 PM, Markus Trippelsdorf wrote:
> > On 2017.05.10 at 11:24 +1000, Stephen Rothwell wrote:
> >> Hi Jens,
> >>
> >> After merging the block tree, today's linux-next build (arm
>
On 2017.05.10 at 11:24 +1000, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> block/elevator.c: In function 'elv_iosched_store':
> block/elevator.c:1102:2: warning: ignoring return value of 'strstr
ply adding KERN_CONTs.
Signed-off-by: Markus Trippelsdorf
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 396c042e9d0e..cc30a74e4adb 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -846,7 +846,7 @@ void signal_fault(struct pt_regs *regs, void __user *fr
On 2017.03.04 at 17:01 +0100, Paolo Valente wrote:
> Hi,
> at last, here is my first patch series meant for merging. It adds BFQ
> to blk-mq. Don't worry, in this message I won't bore you again with
> the wonderful properties of BFQ :)
I gave BFQ a quick try. Unfortunately it hangs when I try to d
On 2017.03.01 at 17:39 +, Ard Biesheuvel wrote:
> On 1 March 2017 at 00:00, Laura Abbott wrote:
> > On 02/25/2017 03:50 AM, Ard Biesheuvel wrote:
> >>
> >>
> >>> On 25 Feb 2017, at 11:23, Ard Biesheuvel
> >>> wrote:
> >>>
>
On 2017.02.25 at 09:11 +, Ard Biesheuvel wrote:
> On 25 February 2017 at 08:18, Markus Trippelsdorf
> wrote:
> >
> > Why not simply get rid of the ilog2_NaN thing altogether?
> >
>
> That would remove the issue, sure. But we lose an opportunity to spot
&g
On 2017.02.24 at 15:33 -0800, Laura Abbott wrote:
> On 02/24/2017 01:45 PM, Ard Biesheuvel wrote:
> > On 24 February 2017 at 21:25, John Stultz wrote:
> >> On Thu, Feb 23, 2017 at 10:43 AM, Laura Abbott wrote:
> >>> Hi,
> >>>
> >>> Fedora was previously carrying a workaround for a gcc7 issue repo
On 2017.02.22 at 11:44 -0700, Jens Axboe wrote:
> On 02/22/2017 11:42 AM, Linus Torvalds wrote:
> > On Wed, Feb 22, 2017 at 10:26 AM, Linus Torvalds
> > wrote:
> >>
> >> And dammit, IF YOU DON'T EVEN KNOW, WHY THE HELL ARE YOU ASKING THE POOR
> >> USER?
> >
> > Basically, I'm pushing back on con
On 2017.01.23 at 09:38 +1000, Dave Airlie wrote:
>
> Alex Deucher (8):
> drm/radeon/si: load special ucode for certain MC configs
> drm/amdgpu/si: load special ucode for certain MC configs
> drm/amdgpu: drop oland qu
On 2016.12.26 at 12:06 +0100, Markus Trippelsdorf wrote:
> On 2016.12.26 at 08:45 +0100, Markus Trippelsdorf wrote:
> > On 2016.12.25 at 14:39 +0100, Thomas Gleixner wrote:
> > > Linus,
> > >
> > > please pull the latest smp-urgent-for-linus git tree from:
>
On 2016.12.26 at 08:45 +0100, Markus Trippelsdorf wrote:
> On 2016.12.25 at 14:39 +0100, Thomas Gleixner wrote:
> > Linus,
> >
> > please pull the latest smp-urgent-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/
On 2016.12.25 at 14:39 +0100, Thomas Gleixner wrote:
> Linus,
>
> please pull the latest smp-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> smp-urgent-for-linus
>
> Thomas Gleixner (11):
> cpu/hotplug: Prevent overwriting of callbacks
T
On 2016.12.20 at 10:32 -0800, h...@zytor.com wrote:
> On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf
> wrote:
> >On 2016.12.20 at 03:10 -0800, H. Peter Anvin wrote:
> >> On 12/20/16 02:00, Markus Trippelsdorf wrote:
> >> > On 2016.12.20 at 01:30 -0800,
On 2016.12.20 at 03:10 -0800, H. Peter Anvin wrote:
> On 12/20/16 02:00, Markus Trippelsdorf wrote:
> > On 2016.12.20 at 01:30 -0800, H. Peter Anvin wrote:
> >> I'd strongly prefer a non-data-dependent solution, specifically adding
> >> at the top of sort_r
On 2016.12.20 at 01:30 -0800, H. Peter Anvin wrote:
> I'd strongly prefer a non-data-dependent solution, specifically adding
> at the top of sort_relocs():
>
> if (!r->count)
> return;
>
> However, by my reading of the C and POSIX standards, this is a gcc
> error: qsort() should do nothing if
On 2016.12.19 at 17:52 +0100, Markus Trippelsdorf wrote:
> On 2016.12.19 at 17:18 +0100, Markus Trippelsdorf wrote:
> > Running the latest kernel git tree, I get buffer overflow warnings when
> > I try to run "perf top":
> >
> > *** buffer overflow detecte
On 2016.12.19 at 17:18 +0100, Markus Trippelsdorf wrote:
> Running the latest kernel git tree, I get buffer overflow warnings when
> I try to run "perf top":
>
> *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf terminated
>
>
> __GI_raise
Running the latest kernel git tree, I get buffer overflow warnings when
I try to run "perf top":
*** buffer overflow detected ***: /usr/src/linux/tools/perf/perf terminated
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 }
(gdb) bt
#0 __GI_raise (sig=sig@en
Commit-ID: 7ebb916782949621ff6819acf373a06902df7679
Gitweb: http://git.kernel.org/tip/7ebb916782949621ff6819acf373a06902df7679
Author: Markus Trippelsdorf
AuthorDate: Thu, 15 Dec 2016 13:45:13 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:50:24 +0100
x86/tools: Fix
not used for ELF_BITS == 64,
so there is no point in trying to sort it.
Fixed by guarding the sort_relocs(&relocs16) call.
Signed-off-by: Markus Trippelsdorf
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 0c2fae8d929d..73eb7fd4aec4 100644
--- a/arch/x86/tools/relocs.c
+
On 2016.11.09 at 10:10 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu:
> > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote:
> > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf
> > > wrote:
>
On 2016.11.09 at 10:11 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu:
> > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> > > Hello,
> > >
> > > This patches fix problems in hierarchy output
On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote:
> Hello,
>
> On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf
> wrote:
> > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> >>
> >> This patches fix problems in hierarchy output Markus reported some
>
On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
>
> This patches fix problems in hierarchy output Markus reported some
> time ago. The code is available on the 'perf/hierarchy-fix-v1' branch
> in my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
>
> Any feed
On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> Hello,
>
> This patches fix problems in hierarchy output Markus reported some
> time ago. The code is available on the 'perf/hierarchy-fix-v1' branch
> in my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
>
>
On 2016.11.04 at 15:24 +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-04 07:37:02 [-0400], Austin S. Hemmelgarn wrote:
> > > clued enough to have known better. Reassigning bug reports in question
> > > from gcc-6 to linux is beyond stupid; Balint is either being deliberately
> > > obtuse, or
On 2016.10.19 at 12:25 +0200, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote:
> > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
>
> > > This is also an entirely different class of optimizations than the whole
> > > pointer arithmetic is only valid inside an obj
On 2016.10.24 at 19:00 +0200, Markus Trippelsdorf wrote:
> On 2016.10.25 at 01:21 +0900, Namhyung Kim wrote:
> > The perf report/top on TUI supports horizontal scrolling using LEFT and
> > RIGHT keys. But it calculate the number of columns incorrectly when
> > hierarchy mo
On 2016.10.25 at 01:21 +0900, Namhyung Kim wrote:
> The perf report/top on TUI supports horizontal scrolling using LEFT and
> RIGHT keys. But it calculate the number of columns incorrectly when
> hierarchy mode is enabled so that keep pressing RIGHT key can make the
> output disappeared. In the h
On 2016.10.24 at 15:02 +0900, Namhyung Kim wrote:
> On Mon, Oct 24, 2016 at 07:53:12AM +0200, Markus Trippelsdorf wrote:
> > On 2016.10.24 at 13:55 +0900, Namhyung Kim wrote:
> > > Hi,
> > >
> > > Sorry for late reply.
> > >
> > > On Mon,
On 2016.10.24 at 13:55 +0900, Namhyung Kim wrote:
> Hi,
>
> Sorry for late reply.
>
> On Mon, Oct 10, 2016 at 07:54:27PM +0200, Markus Trippelsdorf wrote:
> > On 2016.10.08 at 13:21 +0200, Markus Trippelsdorf wrote:
> > > On 2016.10.07 at 07:09 +0200, Markus
On 2016.10.19 at 08:55 -0700, Linus Torvalds wrote:
> On Wed, Oct 19, 2016 at 8:37 AM, Markus Trippelsdorf
> wrote:
> >
> > This is a gcc bug, see:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
>
> Well, in the meantime we apparently have to live with i
On 2016.10.17 at 19:38 +0100, Will Deacon wrote:
> Hi all,
>
> I'm seeing an arm64 build failure with -rc1 and GCC trunk, although I
> believe that the new compiler behaviour at the heart of the problem
> has the potential to affect other architectures and other pieces of
> kernel code relying on
On 2016.10.18 at 22:29 +0200, Markus Trippelsdorf wrote:
> On 2016.10.18 at 22:23 +0200, Borislav Petkov wrote:
> > Hey Al,
> >
> > I see the gazillion warnings below when building -rc1 here.
> >
> > When I revert
> >
> > 784d5699eddc ("x86:
On 2016.10.18 at 22:23 +0200, Borislav Petkov wrote:
> Hey Al,
>
> I see the gazillion warnings below when building -rc1 here.
>
> When I revert
>
> 784d5699eddc ("x86: move exports to actual definitions")
>
> the warnings are gone.
I'm seeing the same thing on ppc64le with an allmodconfig.
-
Since:
commit 6556bdacf646fcaa0586123ba85412de1c8f0eee
Author: Marcin Niestroj
Date: Fri Sep 9 10:42:02 2016 +0200
mfd: tps65217: Add support for IRQs
I get an build failure on pcc64le for allmodconfig:
ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
scripts/Makefile.mo
On 2016.10.12 at 23:18 -0700, Linus Torvalds wrote:
> On Oct 12, 2016 23:07, "Markus Trippelsdorf" wrote:
> >
> > This is nf_register_net_hook at net/netfilter/core.c:106
>
> The "*regs" access?
Yeah.
105 entry->orig_ops = reg;
106 ent
On 2016.10.13 at 08:02 +0200, Markus Trippelsdorf wrote:
> On 2016.10.11 at 04:57 -0400, David Miller wrote:
> > From: Linus Torvalds
> > Date: Mon, 10 Oct 2016 22:47:50 -0700
> >
> > > On Mon, Oct 10, 2016 at 10:39 PM, Linus Torvalds
> > > wrote:
>
On 2016.10.11 at 04:57 -0400, David Miller wrote:
> From: Linus Torvalds
> Date: Mon, 10 Oct 2016 22:47:50 -0700
>
> > On Mon, Oct 10, 2016 at 10:39 PM, Linus Torvalds
> > wrote:
> >>
> >> I guess I will have to double-check that the slub corruption is gone
> >> still with that fixed.
> >
> > S
On 2016.10.08 at 13:21 +0200, Markus Trippelsdorf wrote:
> On 2016.10.07 at 07:09 +0200, Markus Trippelsdorf wrote:
> > On 2016.10.07 at 06:56 +0200, Markus Trippelsdorf wrote:
> > > On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote:
> > > > On 2016.10.07 at 1
On 2016.10.07 at 07:09 +0200, Markus Trippelsdorf wrote:
> On 2016.10.07 at 06:56 +0200, Markus Trippelsdorf wrote:
> > On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote:
> > > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote:
> > > > On Fri, Oct 07, 20
On 2016.10.07 at 15:55 +0200, Thomas Gleixner wrote:
> On Fri, 7 Oct 2016, Markus Trippelsdorf wrote:
> > On 2016.10.06 at 13:52 +0200, Markus Trippelsdorf wrote:
> > > On 2016.10.06 at 12:48 +0100, One Thousand Gnomes wrote:
> > > > On Thu, 6 Oct 2016 13:27:37 +02
On 2016.10.06 at 13:52 +0200, Markus Trippelsdorf wrote:
> On 2016.10.06 at 12:48 +0100, One Thousand Gnomes wrote:
> > On Thu, 6 Oct 2016 13:27:37 +0200
> > Markus Trippelsdorf wrote:
> >
> > > On current trunk I get during boot:
> > >
> > > [
On 2016.10.07 at 06:56 +0200, Markus Trippelsdorf wrote:
> On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote:
> > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote:
> > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote:
> > > > On 2016.10.0
On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote:
> On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote:
> > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote:
> > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote:
> > > > On Thu, Oct 06, 20
On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote:
> On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote:
> > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote:
> > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus Trippelsdorf wrote:
> > > > Scrol
1 - 100 of 362 matches
Mail list logo
