Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1722244 > unrolled thread

tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

Started byMike Galbraith <efault@gmx.de>
First post2017-08-29 11:00 +0200
Last post2017-08-31 21:30 +0200
Articles 20 on this page of 29 — 2 participants

Back to article view | Back to linux.kernel

Contents

  tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-29 11:00 +0200
    Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-29 18:00 +0200
      Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-29 20:20 +0200
        Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-29 20:50 +0200
          Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-30 07:10 +0200
            Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-30 18:40 +0200
              Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-30 19:20 +0200
                Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-30 19:40 +0200
                  Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-30 20:00 +0200
                    Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-30 21:20 +0200
                      Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-30 21:50 +0200
                        Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-31 04:20 +0200
                          Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-31 04:30 +0200
                            Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-31 05:20 +0200
                              Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-31 06:10 +0200
                                Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-31 06:20 +0200
                                  Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-31 06:40 +0200
                                  Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-31 16:00 +0200
                                    Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-31 19:10 +0200
                                      Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-08-31 19:30 +0200
                                        Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-31 20:50 +0200
                                          Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-09-01 09:00 +0200
                                            Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-09-01 15:20 +0200
                                              Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-09-01 19:20 +0200
                                                Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-09-01 20:00 +0200
                                                  Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-09-01 21:00 +0200
                                                    Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm:  Implement fast refcount overflow protection Mike Galbraith <efault@gmx.de> - 2017-09-01 21:30 +0200
                                                    Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-09-01 21:50 +0200
                                    Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement  fast refcount overflow protection Kees Cook <keescook@chromium.org> - 2017-08-31 21:30 +0200

Page 1 of 2  [1] 2  Next page →

#1722244 — tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-29 11:00 +0200
Subjecttip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ujKxj-oP-7@gated-at.bofh.it>
Greetings,

Take 2 of KVM bisect as you work fingered $subject.  Take 1 was stymied
by build dependencies (aa5d1b81, df340524) which I foolishly tried to
skip, leading git bisect to end up handing me a list of commits that
might be busted.  During take 2, I added those two as required.

Symptom is a few splats as below, with box finally hanging.  Network
comes up, but neither ssh nor console login is possible.

[    4.105048] ------------[ cut here ]------------
[    4.106072] WARNING: CPU: 4 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
[    4.107969] Modules linked in: autofs4(E)
[    4.109328] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G            E   4.13.0.g44e89e4-tip-default #27
[    4.111075] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[    4.114119] task: ffff88018ee743c0 task.stack: ffffc90000cc0000
[    4.115481] RIP: 0010:netlink_sock_destruct+0x82/0xa0
[    4.116698] RSP: 0018:ffff880246103eb0 EFLAGS: 00010206
[    4.117997] RAX: 0000000000000300 RBX: ffff880236f1f000 RCX: 000077ff80000000
[    4.120657] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246
[    4.123145] RBP: ffff880236f1f000 R08: 000400010000b630 R09: 0000b6290000b621
[    4.125139] R10: 000400010000b630 R11: 0000b6290000b621 R12: 0000000000000202
[    4.126866] R13: ffffffff81cf1440 R14: ffff88018ee743c0 R15: ffffffff815e0fd0
[    4.128731] FS:  0000000000000000(0000) GS:ffff880246100000(0000) knlGS:0000000000000000
[    4.130206] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.131581] CR2: 000055c7ab255df0 CR3: 0000000236fd9001 CR4: 00000000001606e0
[    4.133066] Call Trace:
[    4.133919]  <IRQ>
[    4.134836]  __sk_destruct+0x21/0x190
[    4.136016]  rcu_process_callbacks+0x23e/0x880
[    4.137050]  ? rebalance_domains+0x182/0x2b0
[    4.138050]  __do_softirq+0xc8/0x287
[    4.139174]  irq_exit+0xd5/0xe0
[    4.140252]  smp_apic_timer_interrupt+0x64/0x140
[    4.141880]  apic_timer_interrupt+0x96/0xa0
[    4.143290]  </IRQ>
[    4.144214] RIP: 0010:native_safe_halt+0x2/0x10
[    4.145990] RSP: 0018:ffffc90000cc3ed8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[    4.147449] RAX: ffffffff816d4820 RBX: ffff88018ee743c0 RCX: 0000000000000000
[    4.148626] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    4.151061] RBP: 0000000000000004 R08: 000000008e8d302a R09: 0000000000000000
[    4.153687] R10: 0000000000000006 R11: 0000000000000005 R12: ffff88018ee743c0
[    4.155587] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[    4.157462]  ? __sched_text_end+0x5/0x5
[    4.158869]  default_idle+0x18/0x110
[    4.160348]  do_idle+0x15e/0x1f0
[    4.161734]  cpu_startup_entry+0x5f/0x70
[    4.163211]  start_secondary+0x14c/0x180
[    4.164716]  secondary_startup_64+0xa5/0xa5
[    4.165730] Code: 00 00 85 c0 75 25 8b 83 44 01 00 00 85 c0 75 10 48 83 bb e0 02 00 00 00 75 02 5b c3 0f ff 5b c3 0f ff 0f 1f 80 00 00 00 00 eb e5 <0f> ff eb d7 48 89 de 48 c7 c7 e0 e6 ab 81 31 c0 5b e9 25 ca af 
[    4.168787] ---[ end trace 79aa32f0718d3fc7 ]---

git bisect start
# good: [9c3a815f471a84811cf8021cf64aae3b8081dfde] page waitqueue: always add new entries at the end
git bisect good 9c3a815f471a84811cf8021cf64aae3b8081dfde
# bad: [44e89e4e15d60159fc09e8f1cbbcd952729edef7] Merge branch 'WIP.x86/fpu'
git bisect bad 44e89e4e15d60159fc09e8f1cbbcd952729edef7
# good: [702e97621ec7e7a36034ebd7a446af04f59d6dee] Merge tag 'for-linus' of git://linux-c6x.org/git/projects/linux-c6x-upstreaming
git bisect good 702e97621ec7e7a36034ebd7a446af04f59d6dee
# bad: [4318414db869639c928a4ffc100585efbb5552a9] Merge branch 'locking/core'
git bisect bad 4318414db869639c928a4ffc100585efbb5552a9
# good: [438a13906508d7453ee93ff3afe25ef72b99140d] Merge branch 'efi/core'
git bisect good 438a13906508d7453ee93ff3afe25ef72b99140d
# bad: [e26f34a407aec9c65bce2bc0c838fabe4f051fc6] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS truly non-interactive
git bisect bad e26f34a407aec9c65bce2bc0c838fabe4f051fc6
# good: [d89e588ca4081615216cc25f2489b0281ac0bfe9] locking: Introduce smp_mb__after_spinlock()
git bisect good d89e588ca4081615216cc25f2489b0281ac0bfe9
# good: [383a4bc88849b804385162e81bf704f8f9690a87] locking/lockdep: Make print_circular_bug() aware of crossrelease
git bisect good 383a4bc88849b804385162e81bf704f8f9690a87
# good: [907dc16d7e23ec81a126c9585435494fa1b3a4b7] locking/lockdep: Fix the rollback and overwrite detection logic in crossrelease
git bisect good 907dc16d7e23ec81a126c9585435494fa1b3a4b7
# bad: [0f0a22260d613b4ee3f483ee1ea6fa27f92a9e40] locking/lockdep: Reword title of LOCKDEP_CROSSRELEASE config
git bisect bad 0f0a22260d613b4ee3f483ee1ea6fa27f92a9e40
# bad: [d0541b0fa64b36665d6261079974a26943c75009] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING
git bisect bad d0541b0fa64b36665d6261079974a26943c75009
# bad: [7a46ec0e2f4850407de5e1d19a44edee6efa58ec] locking/refcounts, x86/asm: Implement fast refcount overflow protection
git bisect bad 7a46ec0e2f4850407de5e1d19a44edee6efa58ec
# first bad commit: [7a46ec0e2f4850407de5e1d19a44edee6efa58ec] locking/refcounts, x86/asm: Implement fast refcount overflow protection

[toc] | [next] | [standalone]

#1722574

FromKees Cook <keescook@chromium.org>
Date2017-08-29 18:00 +0200
Message-ID<ujR5L-4uX-1@gated-at.bofh.it>
In reply to#1722244
On Tue, Aug 29, 2017 at 1:50 AM, Mike Galbraith <efault@gmx.de> wrote:
> Take 2 of KVM bisect as you work fingered $subject.  Take 1 was stymied
> by build dependencies (aa5d1b81, df340524) which I foolishly tried to
> skip, leading git bisect to end up handing me a list of commits that
> might be busted.  During take 2, I added those two as required.
>
> Symptom is a few splats as below, with box finally hanging.  Network
> comes up, but neither ssh nor console login is possible.
>
> [    4.105048] ------------[ cut here ]------------
> [    4.106072] WARNING: CPU: 4 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
> [    4.107969] Modules linked in: autofs4(E)
> [    4.109328] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G            E   4.13.0.g44e89e4-tip-default #27
> [    4.111075] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
> [    4.114119] task: ffff88018ee743c0 task.stack: ffffc90000cc0000
> [    4.115481] RIP: 0010:netlink_sock_destruct+0x82/0xa0
> [    4.116698] RSP: 0018:ffff880246103eb0 EFLAGS: 00010206
> [    4.117997] RAX: 0000000000000300 RBX: ffff880236f1f000 RCX: 000077ff80000000
> [    4.120657] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246
> [    4.123145] RBP: ffff880236f1f000 R08: 000400010000b630 R09: 0000b6290000b621
> [    4.125139] R10: 000400010000b630 R11: 0000b6290000b621 R12: 0000000000000202
> [    4.126866] R13: ffffffff81cf1440 R14: ffff88018ee743c0 R15: ffffffff815e0fd0
> [    4.128731] FS:  0000000000000000(0000) GS:ffff880246100000(0000) knlGS:0000000000000000
> [    4.130206] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    4.131581] CR2: 000055c7ab255df0 CR3: 0000000236fd9001 CR4: 00000000001606e0
> [    4.133066] Call Trace:
> [    4.133919]  <IRQ>
> [    4.134836]  __sk_destruct+0x21/0x190
> [    4.136016]  rcu_process_callbacks+0x23e/0x880
> [    4.137050]  ? rebalance_domains+0x182/0x2b0
> [    4.138050]  __do_softirq+0xc8/0x287
> [    4.139174]  irq_exit+0xd5/0xe0
> [    4.140252]  smp_apic_timer_interrupt+0x64/0x140
> [    4.141880]  apic_timer_interrupt+0x96/0xa0
> [    4.143290]  </IRQ>
> [    4.144214] RIP: 0010:native_safe_halt+0x2/0x10
> [    4.145990] RSP: 0018:ffffc90000cc3ed8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
> [    4.147449] RAX: ffffffff816d4820 RBX: ffff88018ee743c0 RCX: 0000000000000000
> [    4.148626] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> [    4.151061] RBP: 0000000000000004 R08: 000000008e8d302a R09: 0000000000000000
> [    4.153687] R10: 0000000000000006 R11: 0000000000000005 R12: ffff88018ee743c0
> [    4.155587] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [    4.157462]  ? __sched_text_end+0x5/0x5
> [    4.158869]  default_idle+0x18/0x110
> [    4.160348]  do_idle+0x15e/0x1f0
> [    4.161734]  cpu_startup_entry+0x5f/0x70
> [    4.163211]  start_secondary+0x14c/0x180
> [    4.164716]  secondary_startup_64+0xa5/0xa5
> [    4.165730] Code: 00 00 85 c0 75 25 8b 83 44 01 00 00 85 c0 75 10 48 83 bb e0 02 00 00 00 75 02 5b c3 0f ff 5b c3 0f ff 0f 1f 80 00 00 00 00 eb e5 <0f> ff eb d7 48 89 de 48 c7 c7 e0 e6 ab 81 31 c0 5b e9 25 ca af
> [    4.168787] ---[ end trace 79aa32f0718d3fc7 ]---

Ah-ha, found the tip-bot commit now that disables the x86 refcount
implementation. Can you boot with CONFIG_REFCOUNT_FULL=y?

Can you send me your .config and details on the machine?

Also, what is above the "cut here" line (which is very misleading, as
things above that line tend to be very important)?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1722678 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-29 20:20 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ujThf-63v-11@gated-at.bofh.it>
In reply to#1722574
On Tue, 2017-08-29 at 18:55 +0200, Mike Galbraith wrote:
> On Tue, 2017-08-29 at 08:58 -0700, Kees Cook wrote:
> > 
> > Ah-ha, found the tip-bot commit now that disables the x86 refcount
> > implementation. Can you boot with CONFIG_REFCOUNT_FULL=y?
> 
> Will do in the A.M.

(It's A.M. somewhere..)  That boots fine.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1722692

FromKees Cook <keescook@chromium.org>
Date2017-08-29 20:50 +0200
Message-ID<ujTKh-6eS-3@gated-at.bofh.it>
In reply to#1722678
On Tue, Aug 29, 2017 at 11:10 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Tue, 2017-08-29 at 18:55 +0200, Mike Galbraith wrote:
>> On Tue, 2017-08-29 at 08:58 -0700, Kees Cook wrote:
>> >
>> > Ah-ha, found the tip-bot commit now that disables the x86 refcount
>> > implementation. Can you boot with CONFIG_REFCOUNT_FULL=y?
>>
>> Will do in the A.M.
>
> (It's A.M. somewhere..)  That boots fine.

Okay, thanks! I think we've seen this before, but couldn't reproduce
it. The issue is:

static void netlink_sock_destruct(struct sock *sk)
{
...
        WARN_ON(refcount_read(&sk->sk_wmem_alloc));
...
}

Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
disabled)?

I'll try again to reproduce this...

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723024 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-30 07:10 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<uk3qh-44H-5@gated-at.bofh.it>
In reply to#1722692
On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> disabled)?

Nogo.

...
[  OK  ] Mounted /abuild.
[  OK  ] Mounted /homer.
[  OK  ] Mounted /home/git.
[  OK  ] Mounted /usr/local/src.
[  OK  ] Mounted /usr/local/gcc.
[  OK  ] Mounted /usr/local/lib/albumcovers.
[  OK  ] Mounted /usr/local/lib/mp3.
[  OK  ] Mounted /usr/local/ltp.
[  OK  ] Started SuSEfirewall2 phase 2.
         Starting Locale Service...
[   44.901304] ------------[ cut here ]------------
[   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
[   44.902679] Modules linked in: nf_log_ipv6(E) xt_comment(E) nf_log_ipv4(E) rpcsec_gss_krb5(E) nfsv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) dns_resolver(E) nfs(E) fscache(E) af_packet(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ipt_REJECT(E) xt_pkttype(E) xt_tcpudp(E) iptable_filter(E) ip6table_mangle(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) libcrc32c(E) ip6table_filter(E) ip6_tables(E) x_tables(E) snd_hda_codec_generic(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) snd_timer(E) joydev(E) snd(E) ppdev(E) soundcore(E) parport_pc(E) crct10dif_pclmul(E) 8139too(E) crc32_pclmul(E) ghash_clmulni_intel(E) 8139cp(E) pcbc(E) aesni_intel(E)
[   44.908297]  i2c_piix4(E) mii(E) parport(E) aes_x86_64(E) crypto_simd(E) glue_helper(E) pcspkr(E) cryptd(E) button(E) qemu_fw_cfg(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) ext4(E) crc16(E) mbcache(E) jbd2(E) ata_generic(E) hid_generic(E) usbhid(E) ata_piix(E) virtio_balloon(E) virtio_rng(E) virtio_blk(E) virtio_console(E) qxl(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) ahci(E) fb_sys_fops(E) ttm(E) libahci(E) uhci_hcd(E) ehci_pci(E) crc32c_intel(E) ehci_hcd(E) libata(E) serio_raw(E) virtio_pci(E) virtio_ring(E) drm(E) usbcore(E) virtio(E) floppy(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[   44.913190] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G        W   E   4.13.0.g94a2d62-tip-default #45
[   44.915217] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[   44.916073] task: ffff88018ee78400 task.stack: ffffc90000cc8000
[   44.916742] RIP: 0010:netlink_sock_destruct+0x82/0xa0
[   44.917291] RSP: 0018:ffff880246143eb0 EFLAGS: 00010206
[   44.917818] RAX: 0000000000000300 RBX: ffff8802370a6800 RCX: 000077ff80000000
[   44.918497] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246
[   44.919093] RBP: ffff8802370a6800 R08: 0000000000000001 R09: 0000000000011000
[   44.919826] R10: 0000000000001104 R11: 0000000000011bf8 R12: 0000000000000202
[   44.920486] R13: ffffffff81cf1440 R14: ffff88018ee78400 R15: ffffffff815e0f30
[   44.921138] FS:  0000000000000000(0000) GS:ffff880246140000(0000) knlGS:0000000000000000
[   44.921861] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   44.922419] CR2: 0000563972a82768 CR3: 000000011d25a005 CR4: 00000000001606e0
[   44.923079] Call Trace:
[   44.923503]  <IRQ>
[   44.923786]  __sk_destruct+0x21/0x190
[   44.924160]  rcu_process_callbacks+0x23e/0x880
[   44.924583]  ? rebalance_domains+0xf4/0x2b0
[   44.925147]  __do_softirq+0xc8/0x287
[   44.925620]  irq_exit+0xd5/0xe0
[   44.926072]  smp_apic_timer_interrupt+0x64/0x140
[   44.926602]  apic_timer_interrupt+0x96/0xa0
[   44.927138]  </IRQ>
[   44.927512] RIP: 0010:native_safe_halt+0x2/0x10
[   44.928104] RSP: 0018:ffffc90000ccbed8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[   44.928897] RAX: ffffffff816d46e0 RBX: ffff88018ee78400 RCX: 0000000000000000
[   44.931217] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[   44.932064] RBP: 0000000000000005 R08: 000000008e8d32c4 R09: 0000000000000000
[   44.932757] R10: 0000000000000006 R11: 0000000000000005 R12: ffff88018ee78400
[   44.933423] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[   44.934187]  ? __sched_text_end+0x5/0x5
[   44.934609]  default_idle+0x18/0x110
[   44.935041]  do_idle+0x15e/0x1f0
[   44.935455]  cpu_startup_entry+0x5f/0x70
[   44.935934]  start_secondary+0x14c/0x180
[   44.936445]  secondary_startup_64+0xa5/0xa5
[   44.936933] Code: 00 00 85 c0 75 25 8b 83 44 01 00 00 85 c0 75 10 48 83 bb e0 02 00 00 00 75 02 5b c3 0f ff 5b c3 0f ff 0f 1f 80 00 00 00 00 eb e5 <0f> ff eb d7 48 89 de 48 c7 c7 d8 e6 ab 81 31 c0 5b e9 d5 ca af 
[   44.938829] ---[ end trace bcf2d20b852804b6 ]---
[  OK  ] Started Locale Service.
[  OK  ] Started Postfix Mail Transport Agent.
[  OK  ] Started Command Scheduler.
[  OK  ] Started X Display Manager.
[  OK  ] Started Virtualization daemon.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.
...zzzzzz

[toc] | [prev] | [next] | [standalone]

#1723491

FromKees Cook <keescook@chromium.org>
Date2017-08-30 18:40 +0200
Message-ID<ukec3-2f2-17@gated-at.bofh.it>
In reply to#1723024
On Tue, Aug 29, 2017 at 10:02 PM, Mike Galbraith <efault@gmx.de> wrote:
> On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
>> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
>> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
>> disabled)?
>
> Nogo.

Thanks for checking!

> [   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0

This is so odd if 14afee4b6092 is reverted. What is line 374 for you
in net/netlink/af_netlink.c?

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723520 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-30 19:20 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ukeOK-2Hq-9@gated-at.bofh.it>
In reply to#1723491
On Wed, 2017-08-30 at 09:35 -0700, Kees Cook wrote:
> On Tue, Aug 29, 2017 at 10:02 PM, Mike Galbraith <efault@gmx.de> wrote:
> > On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> >> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> >> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> >> disabled)?
> >
> > Nogo.
> 
> Thanks for checking!
> 
> > [   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
> 
> This is so odd if 14afee4b6092 is reverted. What is line 374 for you
> in net/netlink/af_netlink.c?

374         WARN_ON(atomic_read(&sk->sk_rmem_alloc));

That line is unchanged by 14afee4b6092.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1723533

FromKees Cook <keescook@chromium.org>
Date2017-08-30 19:40 +0200
Message-ID<ukf86-2PE-17@gated-at.bofh.it>
In reply to#1723520
On Wed, Aug 30, 2017 at 10:13 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Wed, 2017-08-30 at 09:35 -0700, Kees Cook wrote:
>> On Tue, Aug 29, 2017 at 10:02 PM, Mike Galbraith <efault@gmx.de> wrote:
>> > On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
>> >> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
>> >> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
>> >> disabled)?
>> >
>> > Nogo.
>>
>> Thanks for checking!
>>
>> > [   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
>>
>> This is so odd if 14afee4b6092 is reverted. What is line 374 for you
>> in net/netlink/af_netlink.c?
>
> 374         WARN_ON(atomic_read(&sk->sk_rmem_alloc));
>
> That line is unchanged by 14afee4b6092.

Uuuuhmm. Wow, now I'm really baffled. I thought you were getting the
warn from the next line with the refcount usage... I will keep
digging. Thanks!

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723545 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-30 20:00 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ukfrs-2W1-5@gated-at.bofh.it>
In reply to#1723533
On Wed, 2017-08-30 at 10:32 -0700, Kees Cook wrote:
> On Wed, Aug 30, 2017 at 10:13 AM, Mike Galbraith <efault@gmx.de> wrote:
> > On Wed, 2017-08-30 at 09:35 -0700, Kees Cook wrote:
> >> On Tue, Aug 29, 2017 at 10:02 PM, Mike Galbraith <efault@gmx.de> wrote:
> >> > On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> >> >> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> >> >> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> >> >> disabled)?
> >> >
> >> > Nogo.
> >>
> >> Thanks for checking!
> >>
> >> > [   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
> >>
> >> This is so odd if 14afee4b6092 is reverted. What is line 374 for you
> >> in net/netlink/af_netlink.c?
> >
> > 374         WARN_ON(atomic_read(&sk->sk_rmem_alloc));
> >
> > That line is unchanged by 14afee4b6092.
> 
> Uuuuhmm. Wow, now I'm really baffled. I thought you were getting the
> warn from the next line with the refcount usage... I will keep
> digging. Thanks!

I just double checked freshly pulled tip (rapidly moving target), and
it's definitely nogo with CONFIG_ARCH_HAS_REFCOUNT=y and 14afee4b6092
reverted.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1723610

FromKees Cook <keescook@chromium.org>
Date2017-08-30 21:20 +0200
Message-ID<ukgGR-3SG-9@gated-at.bofh.it>
In reply to#1723545
On Wed, Aug 30, 2017 at 10:55 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Wed, 2017-08-30 at 10:32 -0700, Kees Cook wrote:
>> On Wed, Aug 30, 2017 at 10:13 AM, Mike Galbraith <efault@gmx.de> wrote:
>> > On Wed, 2017-08-30 at 09:35 -0700, Kees Cook wrote:
>> >> On Tue, Aug 29, 2017 at 10:02 PM, Mike Galbraith <efault@gmx.de> wrote:
>> >> > On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
>> >> >> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
>> >> >> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
>> >> >> disabled)?
>> >> >
>> >> > Nogo.
>> >>
>> >> Thanks for checking!
>> >>
>> >> > [   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
>> >>
>> >> This is so odd if 14afee4b6092 is reverted. What is line 374 for you
>> >> in net/netlink/af_netlink.c?
>> >
>> > 374         WARN_ON(atomic_read(&sk->sk_rmem_alloc));
>> >
>> > That line is unchanged by 14afee4b6092.
>>
>> Uuuuhmm. Wow, now I'm really baffled. I thought you were getting the
>> warn from the next line with the refcount usage... I will keep
>> digging. Thanks!
>
> I just double checked freshly pulled tip (rapidly moving target), and
> it's definitely nogo with CONFIG_ARCH_HAS_REFCOUNT=y and 14afee4b6092
> reverted.

Okay, thanks for double-checking. I'd be curious to see if it would
help to revert any of these too:

fb5c2c17a556 net: convert packet_fanout.sk_ref from atomic_t to refcount_t
b4217b82893c net: convert netlbl_lsm_cache.refcount from atomic_t to refcount_t
c122e14df2d6 net: convert net.passive from atomic_t to refcount_t
edcb691871b2 net: convert inet_frag_queue.refcnt from atomic_t to refcount_t
717d1e993ad8 net: convert fib_rule.refcnt from atomic_t to refcount_t
8c9814b97002 net: convert unix_address.refcnt from atomic_t to refcount_t
433cea4d9bbb net: convert netpoll_info.refcnt from atomic_t to refcount_t
7658b36f1b31 net: convert in_device.refcnt from atomic_t to refcount_t
8851ab526791 net: convert ip_mc_list.refcnt from atomic_t to refcount_t
41c6d650f653 net: convert sock.sk_refcnt from atomic_t to refcount_t
14afee4b6092 net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
2638595afccf net: convert sk_buff_fclones.fclone_ref from atomic_t to refcount_t
633547973ffc net: convert sk_buff.users from atomic_t to refcount_t
53869cebce4b net: convert nf_bridge_info.use from atomic_t to refcount_t
6343944bc105 net: convert neigh_params.refcnt from atomic_t to refcount_t
9f23743017d1 net: convert neighbour.refcnt from atomic_t to refcount_t
1cc9a98b59ba net: convert inet_peer.refcnt from atomic_t to refcount_t

What I find so strange about this is that it's tripping a warning in
an atomic_t state, and works fine with FULL or "none". x86-refcount
has almost identical behavior to "none" (though obviously, this seems
like those differences must be the source of the bug), but FULL is
much more aggressive. So some silent x86-refcount issue is causing a
side-effect in af_netlink... Something very subtle is happening here.
(So subtle I can't reproduce it yet, sadly...)

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723624

FromKees Cook <keescook@chromium.org>
Date2017-08-30 21:50 +0200
Message-ID<ukh9U-44p-3@gated-at.bofh.it>
In reply to#1723610
On Wed, Aug 30, 2017 at 12:19 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Aug 30, 2017 at 10:55 AM, Mike Galbraith <efault@gmx.de> wrote:
>> On Wed, 2017-08-30 at 10:32 -0700, Kees Cook wrote:
>>> On Wed, Aug 30, 2017 at 10:13 AM, Mike Galbraith <efault@gmx.de> wrote:
>>> > On Wed, 2017-08-30 at 09:35 -0700, Kees Cook wrote:
>>> >> On Tue, Aug 29, 2017 at 10:02 PM, Mike Galbraith <efault@gmx.de> wrote:
>>> >> > On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
>>> >> >> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
>>> >> >> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
>>> >> >> disabled)?
>>> >> >
>>> >> > Nogo.
>>> >>
>>> >> Thanks for checking!
>>> >>
>>> >> > [   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
>>> >>
>>> >> This is so odd if 14afee4b6092 is reverted. What is line 374 for you
>>> >> in net/netlink/af_netlink.c?
>>> >
>>> > 374         WARN_ON(atomic_read(&sk->sk_rmem_alloc));
>>> >
>>> > That line is unchanged by 14afee4b6092.
>>>
>>> Uuuuhmm. Wow, now I'm really baffled. I thought you were getting the
>>> warn from the next line with the refcount usage... I will keep
>>> digging. Thanks!
>>
>> I just double checked freshly pulled tip (rapidly moving target), and
>> it's definitely nogo with CONFIG_ARCH_HAS_REFCOUNT=y and 14afee4b6092
>> reverted.

With CONFIG_ARCH_HAS_REFCOUNT=y and this patch, do you get an earlier splat?

diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index c076f710de4c..569d97a4c3e8 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -72,6 +72,8 @@ bool ex_handler_refcount(const struct
exception_table_entry *fixup,
                bool zero = regs->flags & X86_EFLAGS_ZF;

                refcount_error_report(regs, zero ? "hit zero" : "overflow");
+       } else {
+               refcount_error_report(regs, "silent saturation");
        }

        return true;

The difference between none, FULL, and x86-refcount is the saturation
semantics. none has, obviously, none, and FULL pins values either to
zero or UINT_MAX, depending on various things. x86-refcount saturates
to INT_MIN / 2, but it should only get there after overflow or
unexpected zeroing (both cases would WARN). So if there's some other
path to hitting saturation that could put some refcount_t into a state
that is different from none and FULL, and maybe that side-effect
results in the af_netlink WARN. (I can't see _how_ yet, though.)

So if the above patch does NOT throw a new WARN, then that'll be even weirder.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723772 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-31 04:20 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<uknfj-84l-3@gated-at.bofh.it>
In reply to#1723624
On Wed, 2017-08-30 at 12:46 -0700, Kees Cook wrote:
> 
> With CONFIG_ARCH_HAS_REFCOUNT=y and this patch, do you get an earlier splat?

Yup, first gripe below.

[    2.448393] refcount_t silent saturation at skb_unref.part.36+0x12/0x1a in (haveged)[136], uid/euid: 0/0
[    2.454975] ------------[ cut here ]------------
[    2.456452] WARNING: CPU: 1 PID: 136 at kernel/panic.c:612 refcount_error_report+0xa0/0xa4
[    2.456452] Modules linked in: scsi_mod(E+) autofs4(E)
[    2.456456] CPU: 1 PID: 136 Comm: (haveged) Tainted: G            E   4.13.0.g152d54a-tip-default #47
[    2.456456] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[    2.456457] task: ffff880137f65640 task.stack: ffffc9000093c000
[    2.456458] RIP: 0010:refcount_error_report+0xa0/0xa4
[    2.456459] RSP: 0018:ffffc9000093fa38 EFLAGS: 00010282
[    2.456459] RAX: 000000000000005c RBX: ffffffff81a33864 RCX: 0000000000000830
[    2.456459] RDX: 0000000000000001 RSI: 0000000000000082 RDI: 0000000000000246
[    2.456460] RBP: ffffc9000093fb88 R08: 000000008e8d4f61 R09: 0000000000000000
[    2.456462] R10: 0000000000000000 R11: ffff880137f61600 R12: ffff880137f65640
[    2.456463] R13: 0000000000000000 R14: 0000000000000004 R15: 0000000000000006
[    2.456464] FS:  00007f5a33a14880(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
[    2.456464] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.456464] CR2: 00007ffe37ca0c88 CR3: 0000000137f74005 CR4: 00000000001606e0
[    2.456467] Call Trace:
[    2.456478]  ex_handler_refcount+0x63/0x70
[    2.456479]  fixup_exception+0x32/0x40
[    2.456482]  do_trap+0x11b/0x180
[    2.456493]  do_error_trap+0x70/0xd0
[    2.456497]  ? skb_unref.part.36+0x10/0x1a
[    2.456502]  ? idr_get_free+0xcb/0x2f0
[    2.456505]  invalid_op+0x1e/0x30
[    2.456510] RIP: 0010:skb_unref.part.36+0x12/0x1a
[    2.456510] RSP: 0018:ffffc9000093fc30 EFLAGS: 00010202
[    2.456510] RAX: 0000000000000002 RBX: 0000000000000000 RCX: ffff880137df9ee4
[    2.456511] RDX: ffff880137df0518 RSI: ffff880137df9e00 RDI: ffff880137df9e00
[    2.456511] RBP: ffff880137df9e00 R08: ffff880137e30018 R09: ffffffff816b91f0
[    2.456511] R10: 0000000000000017 R11: 00000000fffffff4 R12: 0000000000000000
[    2.456512] R13: ffff88013a4e9000 R14: 0000000000000000 R15: ffff880137e30000
[    2.456513]  ? cleanup_uevent_env+0x10/0x10
[    2.456520]  kfree_skb+0x3f/0xa0
[    2.456525]  netlink_broadcast_filtered+0x2c8/0x420
[    2.456530]  ? cleanup_uevent_env+0x10/0x10
[    2.456531]  kobject_uevent_env+0x476/0x650
[    2.456540]  device_add+0x41e/0x5f0
[    2.456550]  netdev_register_kobject+0x8e/0x170
[    2.456553]  register_netdevice+0x27a/0x3d0
[    2.456557]  register_netdev+0x16/0x30
[    2.456562]  loopback_net_init+0x48/0xa0
[    2.456567]  ops_init+0x39/0x110
[    2.456568]  setup_net+0x85/0x130
[    2.456569]  copy_net_ns+0xb9/0x1f0
[    2.456571]  create_new_namespaces+0x11a/0x1b0
[    2.456577]  unshare_nsproxy_namespaces+0x55/0xa0
[    2.456578]  SyS_unshare+0x18d/0x330
[    2.456581]  entry_SYSCALL_64_fastpath+0x1a/0xa5
[    2.456584] RIP: 0033:0x7f5a320669f7
[    2.456585] RSP: 002b:00007ffcd1e10908 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[    2.456585] RAX: ffffffffffffffda RBX: 000000000159ae48 RCX: 00007f5a320669f7
[    2.456586] RDX: 000000000000000b RSI: 00007ffcd1e10910 RDI: 0000000040000000
[    2.456588] RBP: 00007ffcd1e10cf0 R08: 0000000000000001 R09: 00000000015b8d20
[    2.456588] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000
[    2.456588] R13: 00000000ffffffff R14: 00000000ffffffff R15: 0000000000000000
[    2.456589] Code: 10 09 00 00 48 8b 95 80 00 00 00 49 8d 8c 24 f0 0a 00 00 41 89 c1 44 89 2c 24 48 89 de 48 c7 c7 80 70 a3 81 31 c0 e8 bd f1 05 00 <0f> ff eb 88 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 49 89 
[    2.456599] ---[ end trace d3215cc8334d8520 ]---

[toc] | [prev] | [next] | [standalone]

#1723775

FromKees Cook <keescook@chromium.org>
Date2017-08-31 04:30 +0200
Message-ID<uknoZ-8a0-7@gated-at.bofh.it>
In reply to#1723772
On Wed, Aug 30, 2017 at 7:09 PM, Mike Galbraith <efault@gmx.de> wrote:
> On Wed, 2017-08-30 at 12:46 -0700, Kees Cook wrote:
>>
>> With CONFIG_ARCH_HAS_REFCOUNT=y and this patch, do you get an earlier splat?
>
> Yup, first gripe below.
>
> [    2.448393] refcount_t silent saturation at skb_unref.part.36+0x12/0x1a in (haveged)[136], uid/euid: 0/0
> [    2.454975] ------------[ cut here ]------------
> [    2.456452] WARNING: CPU: 1 PID: 136 at kernel/panic.c:612 refcount_error_report+0xa0/0xa4
> [    2.456452] Modules linked in: scsi_mod(E+) autofs4(E)
> [    2.456456] CPU: 1 PID: 136 Comm: (haveged) Tainted: G            E   4.13.0.g152d54a-tip-default #47
> [    2.456456] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
> [    2.456457] task: ffff880137f65640 task.stack: ffffc9000093c000
> [    2.456458] RIP: 0010:refcount_error_report+0xa0/0xa4
> [    2.456459] RSP: 0018:ffffc9000093fa38 EFLAGS: 00010282
> [    2.456459] RAX: 000000000000005c RBX: ffffffff81a33864 RCX: 0000000000000830
> [    2.456459] RDX: 0000000000000001 RSI: 0000000000000082 RDI: 0000000000000246
> [    2.456460] RBP: ffffc9000093fb88 R08: 000000008e8d4f61 R09: 0000000000000000
> [    2.456462] R10: 0000000000000000 R11: ffff880137f61600 R12: ffff880137f65640
> [    2.456463] R13: 0000000000000000 R14: 0000000000000004 R15: 0000000000000006
> [    2.456464] FS:  00007f5a33a14880(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
> [    2.456464] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.456464] CR2: 00007ffe37ca0c88 CR3: 0000000137f74005 CR4: 00000000001606e0
> [    2.456467] Call Trace:
> [    2.456478]  ex_handler_refcount+0x63/0x70
> [    2.456479]  fixup_exception+0x32/0x40
> [    2.456482]  do_trap+0x11b/0x180
> [    2.456493]  do_error_trap+0x70/0xd0
> [    2.456497]  ? skb_unref.part.36+0x10/0x1a
> [    2.456502]  ? idr_get_free+0xcb/0x2f0
> [    2.456505]  invalid_op+0x1e/0x30
> [    2.456510] RIP: 0010:skb_unref.part.36+0x12/0x1a
> [    2.456510] RSP: 0018:ffffc9000093fc30 EFLAGS: 00010202
> [    2.456510] RAX: 0000000000000002 RBX: 0000000000000000 RCX: ffff880137df9ee4
> [    2.456511] RDX: ffff880137df0518 RSI: ffff880137df9e00 RDI: ffff880137df9e00
> [    2.456511] RBP: ffff880137df9e00 R08: ffff880137e30018 R09: ffffffff816b91f0
> [    2.456511] R10: 0000000000000017 R11: 00000000fffffff4 R12: 0000000000000000
> [    2.456512] R13: ffff88013a4e9000 R14: 0000000000000000 R15: ffff880137e30000
> [    2.456513]  ? cleanup_uevent_env+0x10/0x10
> [    2.456520]  kfree_skb+0x3f/0xa0
> [    2.456525]  netlink_broadcast_filtered+0x2c8/0x420
> [    2.456530]  ? cleanup_uevent_env+0x10/0x10
> [    2.456531]  kobject_uevent_env+0x476/0x650
> [    2.456540]  device_add+0x41e/0x5f0
> [    2.456550]  netdev_register_kobject+0x8e/0x170
> [    2.456553]  register_netdevice+0x27a/0x3d0
> [    2.456557]  register_netdev+0x16/0x30
> [    2.456562]  loopback_net_init+0x48/0xa0
> [    2.456567]  ops_init+0x39/0x110
> [    2.456568]  setup_net+0x85/0x130
> [    2.456569]  copy_net_ns+0xb9/0x1f0
> [    2.456571]  create_new_namespaces+0x11a/0x1b0
> [    2.456577]  unshare_nsproxy_namespaces+0x55/0xa0
> [    2.456578]  SyS_unshare+0x18d/0x330
> [    2.456581]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> [    2.456584] RIP: 0033:0x7f5a320669f7
> [    2.456585] RSP: 002b:00007ffcd1e10908 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
> [    2.456585] RAX: ffffffffffffffda RBX: 000000000159ae48 RCX: 00007f5a320669f7
> [    2.456586] RDX: 000000000000000b RSI: 00007ffcd1e10910 RDI: 0000000040000000
> [    2.456588] RBP: 00007ffcd1e10cf0 R08: 0000000000000001 R09: 00000000015b8d20
> [    2.456588] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000
> [    2.456588] R13: 00000000ffffffff R14: 00000000ffffffff R15: 0000000000000000
> [    2.456589] Code: 10 09 00 00 48 8b 95 80 00 00 00 49 8d 8c 24 f0 0a 00 00 41 89 c1 44 89 2c 24 48 89 de 48 c7 c7 80 70 a3 81 31 c0 e8 bd f1 05 00 <0f> ff eb 88 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 49 89
> [    2.456599] ---[ end trace d3215cc8334d8520 ]---

Interesting! Can you try with 633547973ffc3 ("net: convert
sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
running haveged will help me trigger this on my system...

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723785 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-31 05:20 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ukobo-h0-7@gated-at.bofh.it>
In reply to#1723775
On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:

> Interesting! Can you try with 633547973ffc3 ("net: convert
> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
> running haveged will help me trigger this on my system...

With that (plus 230cd1279d001 fix to it) reverted, vbox boots.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1723797

FromKees Cook <keescook@chromium.org>
Date2017-08-31 06:10 +0200
Message-ID<ukoXL-Lg-9@gated-at.bofh.it>
In reply to#1723785
On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith <efault@gmx.de> wrote:
> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
>
>> Interesting! Can you try with 633547973ffc3 ("net: convert
>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
>> running haveged will help me trigger this on my system...
>
> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.

Wonderful! Thank you so much for helping track this down.

So, it seems that sk_buff.users will need some more special attention
before we can convert it to refcount.

x86-refcount will saturate with refcount_dec_and_test() if the result
is negative. But that would mean at least starting at 0. FULL should
have WARNed in this case, so I remain slightly confused why it was
missed by FULL.

Ingo, I'm not sure the best path for this. It seems we need to revert
230cd1279d001 and 633547973ffc3 and then we can restore
ARCH_HAS_REFCOUNT.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723798

FromKees Cook <keescook@chromium.org>
Date2017-08-31 06:20 +0200
Message-ID<ukp7r-Oj-1@gated-at.bofh.it>
In reply to#1723797
On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith <efault@gmx.de> wrote:
>> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
>>
>>> Interesting! Can you try with 633547973ffc3 ("net: convert
>>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
>>> running haveged will help me trigger this on my system...
>>
>> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
>
> Wonderful! Thank you so much for helping track this down.
>
> So, it seems that sk_buff.users will need some more special attention
> before we can convert it to refcount.
>
> x86-refcount will saturate with refcount_dec_and_test() if the result
> is negative. But that would mean at least starting at 0. FULL should
> have WARNed in this case, so I remain slightly confused why it was
> missed by FULL.

Actually, if this is a race condition it's possible that FULL is slow
enough to miss it...

I bet something briefly takes the refcount negative, and with
unchecked atomics, it come back up positive again during the race.
FULL may miss the race, and x86-refcount will catch it and saturate...

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1723805 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-31 06:40 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ukpqN-X4-1@gated-at.bofh.it>
In reply to#1723798
On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote:
> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook <keescook@chromium.org> wrote:
> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith <efault@gmx.de> wrote:
> >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
> >>
> >>> Interesting! Can you try with 633547973ffc3 ("net: convert
> >>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
> >>> running haveged will help me trigger this on my system...
> >>
> >> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
> >
> > Wonderful! Thank you so much for helping track this down.
> >
> > So, it seems that sk_buff.users will need some more special attention
> > before we can convert it to refcount.
> >
> > x86-refcount will saturate with refcount_dec_and_test() if the result
> > is negative. But that would mean at least starting at 0. FULL should
> > have WARNed in this case, so I remain slightly confused why it was
> > missed by FULL.
> 
> Actually, if this is a race condition it's possible that FULL is slow
> enough to miss it...
> 
> I bet something briefly takes the refcount negative, and with
> unchecked atomics, it come back up positive again during the race.
> FULL may miss the race, and x86-refcount will catch it and saturate...

Hm, I'll go have a stare.. not that that's likely to turn anything up,
memory ordering stares usually inducing a zombie like state.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1724263 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-31 16:00 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ukyaL-6kL-55@gated-at.bofh.it>
In reply to#1723798
On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote:
> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook <keescook@chromium.org> wrote:
> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith <efault@gmx.de> wrote:
> >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
> >>
> >>> Interesting! Can you try with 633547973ffc3 ("net: convert
> >>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
> >>> running haveged will help me trigger this on my system...
> >>
> >> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
> >
> > Wonderful! Thank you so much for helping track this down.
> >
> > So, it seems that sk_buff.users will need some more special attention
> > before we can convert it to refcount.
> >
> > x86-refcount will saturate with refcount_dec_and_test() if the result
> > is negative. But that would mean at least starting at 0. FULL should
> > have WARNed in this case, so I remain slightly confused why it was
> > missed by FULL.
> 
> Actually, if this is a race condition it's possible that FULL is slow
> enough to miss it...
> 
> I bet something briefly takes the refcount negative, and with
> unchecked atomics, it come back up positive again during the race.
> FULL may miss the race, and x86-refcount will catch it and saturate...

(gdb) list *in6_dev_get+0x1e
0xffffffff8166d3de is in in6_dev_get (./arch/x86/include/asm/refcount.h:52).
47                      : "cc", "cx");
48      }
49
50      static __always_inline void refcount_inc(refcount_t *r)
51      {
52              asm volatile(LOCK_PREFIX "incl %0\n\t"
53                      REFCOUNT_CHECK_LT_ZERO
54                      : [counter] "+m" (r->refs.counter)
55                      : : "cc", "cx");
56

gdb) list *in6_dev_get+0x10
0xffffffff8166d3d0 is in in6_dev_get (./include/net/addrconf.h:318).
313     {
314             struct inet6_dev *idev;
315
316             rcu_read_lock();
317             idev = rcu_dereference(dev->ip6_ptr);
318             if (idev)
319                     refcount_inc(&idev->refcnt);
320             rcu_read_unlock();
321             return idev;
322 

That's from kernel with no revert, but your silent saturation patch
still applied, AND built with gcc-6.3.1.  Kernel traps, but it boots
and works, as does kernel built with gcc-7.0.1.  Remove your silent
saturation patch, kernel doesn't notice a thing, just works.

With gcc-4.8.5, trap means you're as good as dead, with the other two,
trap means the intended.  Compiler, constraints, dark elves.. pick one.

Full first splat from bootable gcc-6.3.1 built kernel.

[    1.293962] NET: Registered protocol family 10
[    1.294635] refcount_t silent saturation at in6_dev_get+0x25/0x104 in swapper/0[1], uid/euid: 0/0
[    1.295616] ------------[ cut here ]------------
[    1.296120] WARNING: CPU: 0 PID: 1 at kernel/panic.c:612 refcount_error_report+0x94/0x9e
[    1.296950] Modules linked in:
[    1.297276] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0.g152d54a-tip-default #53
[    1.299179] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[    1.300743] task: ffff88013ab84040 task.stack: ffffc9000062c000
[    1.301825] RIP: 0010:refcount_error_report+0x94/0x9e
[    1.302804] RSP: 0018:ffffc9000062fc10 EFLAGS: 00010282
[    1.303791] RAX: 0000000000000055 RBX: ffffffff81a34274 RCX: ffffffff81c605e8
[    1.304991] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246
[    1.306189] RBP: ffffc9000062fd58 R08: 0000000000000000 R09: 0000000000000175
[    1.307392] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88013ab84040
[    1.308583] R13: 0000000000000000 R14: 0000000000000004 R15: ffffffff81a256c8
[    1.309768] FS:  0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
[    1.311052] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.312100] CR2: 00007f4631fe8df0 CR3: 0000000137d09003 CR4: 00000000001606f0
[    1.313301] Call Trace:
[    1.314012]  ex_handler_refcount+0x63/0x70
[    1.314893]  fixup_exception+0x32/0x40
[    1.315737]  do_trap+0x8c/0x170
[    1.316519]  do_error_trap+0x70/0xd0
[    1.317340]  ? in6_dev_get+0x23/0x104
[    1.318172]  ? netlink_broadcast_filtered+0x2bd/0x430
[    1.319156]  ? kmem_cache_alloc_trace+0xce/0x5d0
[    1.320098]  ? set_debug_rodata+0x11/0x11
[    1.320964]  invalid_op+0x1e/0x30
[    1.322520] RIP: 0010:in6_dev_get+0x25/0x104
[    1.323631] RSP: 0018:ffffc9000062fe00 EFLAGS: 00010202
[    1.324614] RAX: ffff880137de2400 RBX: ffff880137df4600 RCX: ffff880137de24f0
[    1.325793] RDX: ffff88013a5e4000 RSI: 00000000fffffe00 RDI: ffff88013a5e4000
[    1.326964] RBP: 00000000000000d1 R08: 0000000000000000 R09: ffff880137de7600
[    1.328150] R10: 0000000000000000 R11: ffff8801398a4df8 R12: 0000000000000000
[    1.329374] R13: ffffffff82137872 R14: 014200ca00000000 R15: 0000000000000000
[    1.330547]  ? set_debug_rodata+0x11/0x11
[    1.331392]  ip6_route_init_special_entries+0x2a/0x89
[    1.332369]  addrconf_init+0x9e/0x203
[    1.333173]  inet6_init+0x1af/0x365
[    1.333956]  ? af_unix_init+0x4e/0x4e
[    1.334753]  do_one_initcall+0x4e/0x190
[    1.335555]  ? set_debug_rodata+0x11/0x11
[    1.336369]  kernel_init_freeable+0x189/0x20e
[    1.337230]  ? rest_init+0xd0/0xd0
[    1.337999]  kernel_init+0xa/0xf7
[    1.338744]  ret_from_fork+0x25/0x30
[    1.339500] Code: 48 8b 95 80 00 00 00 41 55 49 8d 8c 24 f0 0a 00 00 45 8b 84 24 10 09 00 00 41 89 c1 48 89 de 48 c7 c7 60 7a a3 81 e8 07 de 05 00 <0f> ff 58 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 55 48 89 e5 41 56 
[    1.342243] ---[ end trace b5d40c0fccce776c ]---

[toc] | [prev] | [next] | [standalone]

#1724428

FromKees Cook <keescook@chromium.org>
Date2017-08-31 19:10 +0200
Message-ID<ukB8C-8op-19@gated-at.bofh.it>
In reply to#1724263
On Thu, Aug 31, 2017 at 6:58 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote:
>> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook <keescook@chromium.org> wrote:
>> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith <efault@gmx.de> wrote:
>> >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
>> >>
>> >>> Interesting! Can you try with 633547973ffc3 ("net: convert
>> >>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
>> >>> running haveged will help me trigger this on my system...
>> >>
>> >> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
>> >
>> > Wonderful! Thank you so much for helping track this down.
>> >
>> > So, it seems that sk_buff.users will need some more special attention
>> > before we can convert it to refcount.
>> >
>> > x86-refcount will saturate with refcount_dec_and_test() if the result
>> > is negative. But that would mean at least starting at 0. FULL should
>> > have WARNed in this case, so I remain slightly confused why it was
>> > missed by FULL.
>>
>> Actually, if this is a race condition it's possible that FULL is slow
>> enough to miss it...
>>
>> I bet something briefly takes the refcount negative, and with
>> unchecked atomics, it come back up positive again during the race.
>> FULL may miss the race, and x86-refcount will catch it and saturate...
>
> (gdb) list *in6_dev_get+0x1e
> 0xffffffff8166d3de is in in6_dev_get (./arch/x86/include/asm/refcount.h:52).
> 47                      : "cc", "cx");
> 48      }
> 49
> 50      static __always_inline void refcount_inc(refcount_t *r)
> 51      {
> 52              asm volatile(LOCK_PREFIX "incl %0\n\t"
> 53                      REFCOUNT_CHECK_LT_ZERO
> 54                      : [counter] "+m" (r->refs.counter)
> 55                      : : "cc", "cx");
> 56
>
> gdb) list *in6_dev_get+0x10
> 0xffffffff8166d3d0 is in in6_dev_get (./include/net/addrconf.h:318).
> 313     {
> 314             struct inet6_dev *idev;
> 315
> 316             rcu_read_lock();
> 317             idev = rcu_dereference(dev->ip6_ptr);
> 318             if (idev)
> 319                     refcount_inc(&idev->refcnt);
> 320             rcu_read_unlock();
> 321             return idev;
> 322
>
> That's from kernel with no revert, but your silent saturation patch
> still applied, AND built with gcc-6.3.1.  Kernel traps, but it boots
> and works, as does kernel built with gcc-7.0.1.  Remove your silent
> saturation patch, kernel doesn't notice a thing, just works.
>
> With gcc-4.8.5, trap means you're as good as dead, with the other two,
> trap means the intended.  Compiler, constraints, dark elves.. pick one.

Oh! So it's gcc-version sensitive? That's alarming. Is this mapping correct:

4.8.5: WARN, eventual kernel hang
6.3.1, 7.0.1: WARN, but continues working

> Full first splat from bootable gcc-6.3.1 built kernel.
>
> [    1.293962] NET: Registered protocol family 10
> [    1.294635] refcount_t silent saturation at in6_dev_get+0x25/0x104 in swapper/0[1], uid/euid: 0/0

That's an _increment_ saturation? Which means the result must be
negative, so it started from least -2.

> [    1.295616] ------------[ cut here ]------------
> [    1.296120] WARNING: CPU: 0 PID: 1 at kernel/panic.c:612 refcount_error_report+0x94/0x9e
> [    1.296950] Modules linked in:
> [    1.297276] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0.g152d54a-tip-default #53
> [    1.299179] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
> [    1.300743] task: ffff88013ab84040 task.stack: ffffc9000062c000
> [    1.301825] RIP: 0010:refcount_error_report+0x94/0x9e
> [    1.302804] RSP: 0018:ffffc9000062fc10 EFLAGS: 00010282
> [    1.303791] RAX: 0000000000000055 RBX: ffffffff81a34274 RCX: ffffffff81c605e8
> [    1.304991] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246
> [    1.306189] RBP: ffffc9000062fd58 R08: 0000000000000000 R09: 0000000000000175
> [    1.307392] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88013ab84040
> [    1.308583] R13: 0000000000000000 R14: 0000000000000004 R15: ffffffff81a256c8
> [    1.309768] FS:  0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
> [    1.311052] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    1.312100] CR2: 00007f4631fe8df0 CR3: 0000000137d09003 CR4: 00000000001606f0
> [    1.313301] Call Trace:
> [    1.314012]  ex_handler_refcount+0x63/0x70
> [    1.314893]  fixup_exception+0x32/0x40
> [    1.315737]  do_trap+0x8c/0x170
> [    1.316519]  do_error_trap+0x70/0xd0
> [    1.317340]  ? in6_dev_get+0x23/0x104
> [    1.318172]  ? netlink_broadcast_filtered+0x2bd/0x430
> [    1.319156]  ? kmem_cache_alloc_trace+0xce/0x5d0
> [    1.320098]  ? set_debug_rodata+0x11/0x11
> [    1.320964]  invalid_op+0x1e/0x30
> [    1.322520] RIP: 0010:in6_dev_get+0x25/0x104
> [    1.323631] RSP: 0018:ffffc9000062fe00 EFLAGS: 00010202
> [    1.324614] RAX: ffff880137de2400 RBX: ffff880137df4600 RCX: ffff880137de24f0
> [    1.325793] RDX: ffff88013a5e4000 RSI: 00000000fffffe00 RDI: ffff88013a5e4000
> [    1.326964] RBP: 00000000000000d1 R08: 0000000000000000 R09: ffff880137de7600
> [    1.328150] R10: 0000000000000000 R11: ffff8801398a4df8 R12: 0000000000000000
> [    1.329374] R13: ffffffff82137872 R14: 014200ca00000000 R15: 0000000000000000
> [    1.330547]  ? set_debug_rodata+0x11/0x11
> [    1.331392]  ip6_route_init_special_entries+0x2a/0x89
> [    1.332369]  addrconf_init+0x9e/0x203
> [    1.333173]  inet6_init+0x1af/0x365
> [    1.333956]  ? af_unix_init+0x4e/0x4e
> [    1.334753]  do_one_initcall+0x4e/0x190
> [    1.335555]  ? set_debug_rodata+0x11/0x11
> [    1.336369]  kernel_init_freeable+0x189/0x20e
> [    1.337230]  ? rest_init+0xd0/0xd0
> [    1.337999]  kernel_init+0xa/0xf7
> [    1.338744]  ret_from_fork+0x25/0x30
> [    1.339500] Code: 48 8b 95 80 00 00 00 41 55 49 8d 8c 24 f0 0a 00 00 45 8b 84 24 10 09 00 00 41 89 c1 48 89 de 48 c7 c7 60 7a a3 81 e8 07 de 05 00 <0f> ff 58 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 55 48 89 e5 41 56
> [    1.342243] ---[ end trace b5d40c0fccce776c ]---

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1724444 — Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

FromMike Galbraith <efault@gmx.de>
Date2017-08-31 19:30 +0200
SubjectRe: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection
Message-ID<ukBrZ-4T-31@gated-at.bofh.it>
In reply to#1724428
On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote:
> 
> Oh! So it's gcc-version sensitive? That's alarming. Is this mapping correct:
> 
> 4.8.5: WARN, eventual kernel hang
> 6.3.1, 7.0.1: WARN, but continues working

Yeah, that's correct.  I find that troubling, simply because this gcc
version has been through one hell of a lot of kernels with me.  Yeah, I
know, that doesn't exempt it from having bugs, but color me suspicious.

	-Mike

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web