Build fixes for gcc 6

gcc 5 doesn't seem to care about these, but gcc 6 does and that results in a build failure.

Fixes bbbe6bf6037d ("perf tools: Introduce regs_query_register_offset() ...")

Signed-off-by Ben Hutchings <[email protected]>

---
 tools/perf/arch/x86/util/dwarf-regs.c | 38 ++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 21 deletions(-)

tools/perf/arch/x86/util/dwarf-regs.c +17 -21

index 9223c16..fe1e516 100644
@@ -55,26 +55,10 @@ struct pt_regs_offset {
 
 #define REG_OFFSET_END {.name = NULL, .offset = 0}
 
+/* TODO: switching by dwarf address size */
 #ifdef __x86_64__
-# define REG_OFFSET_NAME_64(n, r) {.name = n, .offset = offsetof(struct pt_regs, r)}
-# define REG_OFFSET_NAME_32(n, r) {.name = n, .offset = -1}
-#else
-# define REG_OFFSET_NAME_64(n, r) {.name = n, .offset = -1}
-# define REG_OFFSET_NAME_32(n, r) {.name = n, .offset = offsetof(struct pt_regs, r)}
-#endif
-
-static const struct pt_regs_offset x86_32_regoffset_table[] = {
-	REG_OFFSET_NAME_32("%ax",	eax),
-	REG_OFFSET_NAME_32("%cx",	ecx),
-	REG_OFFSET_NAME_32("%dx",	edx),
-	REG_OFFSET_NAME_32("%bx",	ebx),
-	REG_OFFSET_NAME_32("$stack",	esp),	/* Stack address instead of %sp */
-	REG_OFFSET_NAME_32("%bp",	ebp),
-	REG_OFFSET_NAME_32("%si",	esi),
-	REG_OFFSET_NAME_32("%di",	edi),
-	REG_OFFSET_END,
-};
 
+#define REG_OFFSET_NAME_64(n, r) {.name = n, .offset = offsetof(struct pt_regs, r)}
 static const struct pt_regs_offset x86_64_regoffset_table[] = {
 	REG_OFFSET_NAME_64("%ax",	rax),
 	REG_OFFSET_NAME_64("%dx",	rdx),

@@ -94,12 +78,24 @@ static const struct pt_regs_offset x86_64_regoffset_table[] = {
 	REG_OFFSET_NAME_64("%r15",	r15),
 	REG_OFFSET_END,
 };
-
-/* TODO: switching by dwarf address size */
-#ifdef __x86_64__
 #define regoffset_table x86_64_regoffset_table
+
 #else
+
+#define REG_OFFSET_NAME_32(n, r) {.name = n, .offset = offsetof(struct pt_regs, r)}
+static const struct pt_regs_offset x86_32_regoffset_table[] = {
+	REG_OFFSET_NAME_32("%ax",	eax),
+	REG_OFFSET_NAME_32("%cx",	ecx),
+	REG_OFFSET_NAME_32("%dx",	edx),
+	REG_OFFSET_NAME_32("%bx",	ebx),
+	REG_OFFSET_NAME_32("$stack",	esp),	/* Stack address instead of %sp */
+	REG_OFFSET_NAME_32("%bp",	ebp),
+	REG_OFFSET_NAME_32("%si",	esi),
+	REG_OFFSET_NAME_32("%di",	edi),
+	REG_OFFSET_END,
+};
 #define regoffset_table x86_32_regoffset_table
+
 #endif
 
 /* Minus 1 for the ending REG_OFFSET_END */

Em Tue, Jan 19, 2016 at 09:33:06PM +0000, Ben Hutchings escreveu:

Quoted 2 lines

gcc 5 doesn't seem to care about these, but gcc 6 does and that results in a build failure.

Ben, please CC the people on the CC list for the patch that introduces the problem, Wang, He, can I have your Acked-by?

- Arnaldo

I think this problem is not introduced by my patch. In fact there's a fundamental problem in get_arch_regstr() that it is impossible to switch sub ISA.

Not only x86_64 and x86_32, I think on arm64 we also have this problem when we try to setup uprobes on arm32 code. For me the later problem is more important because there are many legacy arm32 applications on Android platform (and I have already seen the buggy unwind result in this case. It is another problem though).

So I suggest us to solve this problem first before considering gcc 6 Werror. At least x86_32_regoffset_table and x86_64_regoffset_table should both be compiled no matter which ISA we select for perf.

Thank you.

Em Thu, Jan 21, 2016 at 12:43:04PM +0800, Wangnan (F) escreveu:

Quoted 9 lines

I think this problem is not introduced by my patch. In fact there's a fundamental problem in get_arch_regstr() that it is impossible to switch sub ISA.

Not only x86_64 and x86_32, I think on arm64 we also have this problem when we try to setup uprobes on arm32 code. For me the later problem is more important because there are many legacy arm32 applications on Android platform (and I have already seen the buggy unwind result in this case. It is another problem though).

Humm, and possibly to do something with arm code on a x86 workstation, even if just analysis, yeah, I think these functions should take as an argument the desired architecture instead of assuming it is the one in the machine issuing the commands.

Quoted 2 lines

So I suggest us to solve this problem first before considering gcc 6 Werror. At least x86_32_regoffset_table and x86_64_regoffset_table

Quoted 3 lines

should both be compiled no matter which ISA we select for perf.

Thank you.

But... I think that the unflexible original code has a bug, one that makes it not work when using gcc6 :-\

So I think we should make it build in gcc6, using that patch (or does it have some other problem?) so that at least doing what we can do now can be done for those using gcc6.

Then fix these shortcomings you detected.

From: Wangnan (F) [mailto:[email protected]]

Quoted 8 lines · Arnaldo Carvalho de Melo

Em Tue, Jan 19, 2016 at 09:33:06PM +0000, Ben Hutchings escreveu:

Quoted 2 lines

gcc 5 doesn't seem to care about these, but gcc 6 does and that results in a build failure.

Ben, please CC the people on the CC list for the patch that introduces the problem, Wang, He, can I have your Acked-by?

- Arnaldo

This patch lead me find a bug in original code.

If both perf and target ELF binary is x86_64, following command works okay:

 # perf probe -v -n --exec /tmp/oxygen_root/lib64/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval timeout
 <SNIP>
 Opening /sys/kernel/debug/tracing//uprobe_events write=1
 Writing event: p:probe_libc/pselect
/home/w00229757/oxygen_root-w00229757/lib64/libc-2.18.so:0xdfef0
data=-216(%sp):u64 exceptfds=%cx:u64 readfds=%si:u64 writefds=%dx:u64
nfds=%di:s32 sigmask=%r9:u64 tval=-232(%sp):u64 timeout=%r8:u64
 <SNIP>

But if the library is x86_32, result is incorrect:

  # perf probe -v -n --exec /tmp/oxygen_root/lib32/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval
  <SNIP>
  Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330 data=-172(%si):u64
exceptfds=+16(%si):u32 readfds=+8(%si):u32 writefds=+12(%si):u32
nfds=+4(%si):s32 sigmask=+24(%si):u32 tval=-180(%si):u64
timeout=+20(%si):u32
  <SNIP>

We know that (%si) is used to passing arguments. Here we should see '%sp' or '$stack'.

Use a x86_32 perf we get currect result:

# ~/perf probe -v -n --exec /tmp/oxygen_root/lib32/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval
<SNIP>
Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330 data=-172($stack):u64 exceptfds=+16($stack):u32 readfds=+8($stack):u32 writefds=+12($stack):u32 nfds=+4($stack):s32 sigmask=+24($stack):u32 tval=-180($stack):u64
<SNIP>

Use a small test program to check the result:

#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <memory.h>

 static struct {
        fd_set r, w, e;
        struct timespec ts;
        sigset_t m;

} s;

int main()

 {
        memset(&s, '\0', sizeof(s));

        pselect(0, &s.r, &s.w, &s.e, &s.ts, &s.m);
        return 0;

}

# gcc -m32 -g ./test_pselect.c

Use x86_32 perf:

# ./perf probe -v  --exec /tmp/oxygen_root/lib32/libc.so.6 pselect data
exceptfds readfds writefds nfds sigmask tval
Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330
data=-172($stack):u64 exceptfds=+16($stack):u32 readfds=+8($stack):u32
writefds=+12($stack):u32 nfds=+4($stack):s32 sigmask=+24($stack):u32
tval=-180($stack):u64
Added new event:
  probe_libc:pselect   (on pselect in
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so with data exceptfds
readfds writefds nfds sigmask tval)

You can now use it in all perf tools, such as:

perf record -e probe_libc:pselect -aR sleep 1

# ./perf record -e probe_libc:pselect ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
# ./perf script
           a.out 25336 [006] 64588.457597: probe_libc:pselect:
(f7663330) data=0xf772e00000000000 exceptfds=0x8049880 readfds=0x8049780
writefds=0x8049800 nfds=0 sigmask=0x8049908 tval=0x0

Switch to x86_64 perf:

 # ./perf probe -v  --exec /tmp/oxygen_root/lib32/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval
 <SNIP>
 Opening /sys/kernel/debug/tracing//uprobe_events write=1
Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330 data=-172(%si):u64
exceptfds=+16(%si):u32 readfds=+8(%si):u32 writefds=+12(%si):u32
nfds=+4(%si):s32 sigmask=+24(%si):u32 tval=-180(%si):u64
Added new event:
  probe_libc:pselect   (on pselect in
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so with data exceptfds
readfds writefds nfds sigmask tval)

You can now use it in all perf tools, such as:

perf record -e probe_libc:pselect -aR sleep 1

# ./perf record -e probe_libc:pselect ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
# ./perf script
           a.out 25599 [002] 64759.743554: probe_libc:pselect:
(f76e7330) data=0x0 exceptfds=0x0 readfds=0x0 writefds=0x0 nfds=0
sigmask=0x0 tval=0x0

Sad...

I think this problem is not introduced by my patch. In fact there's a fundamental problem in get_arch_regstr() that it is impossible to switch sub ISA.

Not only x86_64 and x86_32, I think on arm64 we also have this problem when we try to setup uprobes on arm32 code. For me the later problem is more important because there are many legacy arm32 applications on Android platform (and I have already seen the buggy unwind result in this case. It is another problem though).

So I suggest us to solve this problem first before considering gcc 6 Werror. At least x86_32_regoffset_table and x86_64_regoffset_table should both be compiled no matter which ISA we select for perf.

Thank you.

Quoted 42 lines

From: Wangnan (F) [mailto:[email protected]]

Quoted 8 lines · Arnaldo Carvalho de Melo

Em Tue, Jan 19, 2016 at 09:33:06PM +0000, Ben Hutchings escreveu:

Quoted 2 lines

gcc 5 doesn't seem to care about these, but gcc 6 does and that results in a build failure.

Ben, please CC the people on the CC list for the patch that introduces the problem, Wang, He, can I have your Acked-by?

- Arnaldo

This patch lead me find a bug in original code.

If both perf and target ELF binary is x86_64, following command works okay:

  # perf probe -v -n --exec /tmp/oxygen_root/lib64/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval timeout
  <SNIP>
  Opening /sys/kernel/debug/tracing//uprobe_events write=1
  Writing event: p:probe_libc/pselect
/home/w00229757/oxygen_root-w00229757/lib64/libc-2.18.so:0xdfef0
data=-216(%sp):u64 exceptfds=%cx:u64 readfds=%si:u64 writefds=%dx:u64
nfds=%di:s32 sigmask=%r9:u64 tval=-232(%sp):u64 timeout=%r8:u64
  <SNIP>

But if the library is x86_32, result is incorrect:

   # perf probe -v -n --exec /tmp/oxygen_root/lib32/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval
   <SNIP>
   Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330 data=-172(%si):u64
exceptfds=+16(%si):u32 readfds=+8(%si):u32 writefds=+12(%si):u32
nfds=+4(%si):s32 sigmask=+24(%si):u32 tval=-180(%si):u64
timeout=+20(%si):u32
   <SNIP>

We know that (%si) is used to passing arguments. Here we should see '%sp' or '$stack'.

Use a x86_32 perf we get currect result:

Quoted 9 lines

# ~/perf probe -v -n --exec /tmp/oxygen_root/lib32/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval
<SNIP>
Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330 data=-172($stack):u64 exceptfds=+16($stack):u32 readfds=+8($stack):u32 writefds=+12($stack):u32 nfds=+4($stack):s32 sigmask=+24($stack):u32 tval=-180($stack):u64
<SNIP>

Ah, I see. Uprobes may not check the target binary is in 32bit mode. Since the stack of x86-64 and x86-32 on pt_regs are different, (regs->sp points stack on x86-64, &(regs->pt) points stack on x86-32) uprobes would better checking and change the behavior.

But anyway, it is also fixed by changing perf's register table.

Quoted 77 lines

Use a small test program to check the result:

  #include <sys/time.h>
  #include <sys/types.h>
  #include <unistd.h>
  #include <memory.h>

  static struct {
         fd_set r, w, e;
         struct timespec ts;
         sigset_t m;
  } s;

  int main()
  {
         memset(&s, '\0', sizeof(s));

         pselect(0, &s.r, &s.w, &s.e, &s.ts, &s.m);
         return 0;

}

# gcc -m32 -g ./test_pselect.c

Use x86_32 perf:

# ./perf probe -v  --exec /tmp/oxygen_root/lib32/libc.so.6 pselect data
exceptfds readfds writefds nfds sigmask tval
Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330
data=-172($stack):u64 exceptfds=+16($stack):u32 readfds=+8($stack):u32
writefds=+12($stack):u32 nfds=+4($stack):s32 sigmask=+24($stack):u32
tval=-180($stack):u64
Added new event:
   probe_libc:pselect   (on pselect in
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so with data exceptfds
readfds writefds nfds sigmask tval)

You can now use it in all perf tools, such as:

perf record -e probe_libc:pselect -aR sleep 1

# ./perf record -e probe_libc:pselect ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
# ./perf script
            a.out 25336 [006] 64588.457597: probe_libc:pselect:
(f7663330) data=0xf772e00000000000 exceptfds=0x8049880 readfds=0x8049780
writefds=0x8049800 nfds=0 sigmask=0x8049908 tval=0x0

Switch to x86_64 perf:

  # ./perf probe -v  --exec /tmp/oxygen_root/lib32/libc.so.6 pselect
data exceptfds readfds writefds nfds sigmask tval
  <SNIP>
  Opening /sys/kernel/debug/tracing//uprobe_events write=1
Writing event: p:probe_libc/pselect
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so:0xd1330 data=-172(%si):u64
exceptfds=+16(%si):u32 readfds=+8(%si):u32 writefds=+12(%si):u32
nfds=+4(%si):s32 sigmask=+24(%si):u32 tval=-180(%si):u64
Added new event:
   probe_libc:pselect   (on pselect in
/tmp/oxygen_root-w00229757/lib32/libc-2.18.so with data exceptfds
readfds writefds nfds sigmask tval)

You can now use it in all perf tools, such as:

perf record -e probe_libc:pselect -aR sleep 1

# ./perf record -e probe_libc:pselect ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
# ./perf script
            a.out 25599 [002] 64759.743554: probe_libc:pselect:
(f76e7330) data=0x0 exceptfds=0x0 readfds=0x0 writefds=0x0 nfds=0
sigmask=0x0 tval=0x0

Quoted 5 lines

Sad...

I think this problem is not introduced by my patch. In fact there's a fundamental problem in get_arch_regstr() that it is impossible to switch sub ISA.

Right, but I guess this can fixed by switching %sp (for x86-64) and +0(%sp) (for x86-32) instead of $stack.

From: Wangnan (F) [mailto:[email protected]]

Quoted 7 lines · 平松雅巳 / HIRAMATU，MASAMI

Quoted 4 lines

From: Wangnan (F) [mailto:[email protected]]
I think this problem is not introduced by my patch. In fact there's a fundamental problem in get_arch_regstr() that it is impossible to switch sub ISA.

Right, but I guess this can fixed by switching %sp (for x86-64) and +0(%sp) (for x86-32) instead of $stack.

It may not work.

No matter how we change regoffset_table, when get_arch_regstr() get a register number 4, how can it know whether we are looking for x86_32 register and return $stack or return %si for x86_64?

The fundamental problem is: we need a way to map dwarf's register number to register names so uprobe know which register we are looking for, but the API we designed for this can't distinguish the sub ISAs dwarf are using.

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

Quoted 3 lines · Ben Hutchings

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

Quoted 5 lines · Markus Trippelsdorf

Quoted 3 lines · Ben Hutchings

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

Quoted 5 lines

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Quoted 12 lines · Ben Hutchings

Quoted 10 lines · Markus Trippelsdorf

Quoted 3 lines · Ben Hutchings

gcc 6 warns about various things in tools/perf  and with -Werror these turn into build failures.  One of them is a real though not very serious bug.

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

Quoted 2 lines

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Well, the author of the code thinks otherwise:

https://lkml.org/lkml/2015/12/14/269

Quoted 12 lines · Markus Trippelsdorf

Quoted 10 lines · Ben Hutchings

Quoted 3 lines

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

Quoted 2 lines

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Well, the author of the code thinks otherwise:

https://lkml.org/lkml/2015/12/14/269

Em Tue, Jan 19, 2016 at 11:00:50PM +0100, Markus Trippelsdorf escreveu:

Quoted 18 lines · Ben Hutchings

Quoted 6 lines · Markus Trippelsdorf

Quoted 5 lines · Ben Hutchings

Quoted 3 lines

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

Quoted 8 lines

Quoted 5 lines

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Well, the author of the code thinks otherwise:

Quoted 1 line

https://lkml.org/lkml/2015/12/14/269

Right, I saw those and I think I haven't processed them because I was waiting for those to be broken up in separate patches after I read Ingo's comment about one of them fixing up a real bug, a part that the original autor, mfleming even acked, could you please break it down into multiple patches?

Em Tue, Jan 19, 2016 at 07:28:51PM -0300, Arnaldo Carvalho de Melo escreveu:

Quoted 19 lines

Em Tue, Jan 19, 2016 at 11:00:50PM +0100, Markus Trippelsdorf escreveu:

Quoted 18 lines · Ben Hutchings

Quoted 6 lines · Markus Trippelsdorf

Quoted 5 lines · Ben Hutchings

Quoted 3 lines

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

Quoted 8 lines

Quoted 5 lines

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Well, the author of the code thinks otherwise:

Quoted 7 lines

Quoted 1 line

https://lkml.org/lkml/2015/12/14/269

Right, I saw those and I think I haven't processed them because I was waiting for those to be broken up in separate patches after I read Ingo's comment about one of them fixing up a real bug, a part that the original autor, mfleming even acked, could you please break it down into multiple patches?

Alternatively I can do it for the patch acked by Matt and use the other patches from Ben, that even have the Fixes: tags (yay, those are appreciated!).

Em Tue, Jan 19, 2016 at 11:00:50PM +0100, Markus Trippelsdorf escreveu:

Quoted 18 lines · Ben Hutchings

Quoted 6 lines · Markus Trippelsdorf

Quoted 5 lines · Ben Hutchings

Quoted 3 lines

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

Quoted 8 lines

Quoted 5 lines

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Well, the author of the code thinks otherwise:

Quoted 1 line

https://lkml.org/lkml/2015/12/14/269

Right, I saw those and I think I haven't processed them because I was waiting for those to be broken up in separate patches after I read Ingo's comment about one of them fixing up a real bug, a part that the original autor, mfleming even acked, could you please break it down into multiple patches?

Quoted 19 lines

Em Tue, Jan 19, 2016 at 11:00:50PM +0100, Markus Trippelsdorf escreveu:

Quoted 18 lines · Ben Hutchings

Quoted 6 lines · Markus Trippelsdorf

Quoted 5 lines · Ben Hutchings

Quoted 3 lines

gcc 6 warns about various things in tools/perf and with -Werror these turn into build failures. One of them is a real though not very serious bug.

Quoted 8 lines

Quoted 5 lines

I've already send patches for 1,2 and 4. See:
https://lkml.org/lkml/2015/12/14/460

Not sure what happened with them. Also your patch number 4 is wrong, you should just delete the semicolon.

I think that the busy-wait, intentional or not, may be a necessary part of the test case.

Well, the author of the code thinks otherwise:

Quoted 7 lines

Quoted 1 line

https://lkml.org/lkml/2015/12/14/269

Right, I saw those and I think I haven't processed them because I was waiting for those to be broken up in separate patches after I read Ingo's comment about one of them fixing up a real bug, a part that the original autor, mfleming even acked, could you please break it down into multiple patches?

https://lkml.org/lkml/2015/12/14/460
https://lkml.org/lkml/2015/12/14/461
https://lkml.org/lkml/2015/12/14/465