Re: X lock up 2019-04-19 snapshot with Intel graphics
On Sat, Apr 20, 2019 at 04:42:29PM +0200, Matthias Schmidt wrote:
> Hi,
>
> * Jonathan Gray wrote:
> >
> > There is some kind of use after free or double free that triggers only
> > when opting into the 'intel' driver on recent hardware instead of the
> > 'modesetting' default.
> >
> > As you are using xf86-video-intel you are likely hitting that.
> > Doesn't trigger on machines I can easily use serial on like x61.
> >
> > here is a trace provided by sthen@
> >
> > login: kernel: protection fault trap, code=0
> > Stopped at linux_root_RB_NEXT+0x23:movq0(%rcx),%rcx
> > ddb{0}> sh reg
> > rdi 0x80eb1228
> > rsi 0x10
> > rbp 0x800022335d70
> > rbx 0x80eb1228
> > rdx 0xfe0003ff1e32
> > rcx 0xdeafbeaddeafbead
> > rax 0xdeafbeaddeafbead
> > r8 0x7f
> > r90x81dce788sched_lock
> > r10 0xde411193c377fb0c
> > r11 0xdef8fb561704900e
> > r12 0x80eb1200
> > r13 0x80eb1200
> > r14 0x80efe028
> > r15 0x80eb1200
> > rip 0x814db7c3linux_root_RB_NEXT+0x23
> > cs 0x8
> > rflags 0x10282__ALIGN_SIZE+0xf282
> > rsp 0x800022335d60
> > ss 0x10
> > linux_root_RB_NEXT+0x23:movq0(%rcx),%rcx
> > ddb{0}> ps /o
> > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> > 482804 44419 350x12 03 Xorg
> > 186441 838637320x23 0x4801 mongod
> > * 27314 7158 0 0x14000 0x2000K i915
> > ddb{0}> tr
> > linux_root_RB_NEXT(80eb1228) at linux_root_RB_NEXT+0x23
> > i915_vma_destroy(80efe028) at i915_vma_destroy+0x15d
> > __i915_gem_free_objects(8011a000,80f009f8) at
> > __i915_gem_free_objects+0xc3
> > __i915_gem_free_work(8011de90) at __i915_gem_free_work+0x5b
> > taskq_thread(801ef300) at taskq_thread+0x4d
> > end trace frame: 0x0, count: -5
>
> I was hit by the bug as well on a Thinkpad T450s while I was about to
> move my xorg.conf config for the Intel driver away. Interestingly, I
> was on ttyC0 and restarting xenodm.
>
> Here is the backtracke (transcript by hand):
>
> linux_root_RB_NEXT() at linux_root_RB_NEXT+0x23
> i915_vma_destroy() at i915_vma_destroy+0x15d
> i915_ppgtt_release() at i915_oogtt_release+0x7f
> i915_gem_context_free() at i915_gem_context_free+0x3e
> contexts_free_worker() at contexts_free_worker+0x4d
> taskq_thread() at taskq_thread+0x4d
This should be fixed in the latest snapshot.
Re: ospfd: passive p2p interfaces don't work
Remi Locherer(remi.loche...@relo.ch) on 2019.04.22 11:14:30 +0200:
> Hi Stefan
>
> On Tue, Apr 09, 2019 at 04:16:32PM +0200, Stefan Sperling wrote:
> > I want to announce a host-route to the address of a tun0 interface
> > over OSPF. The config snippet I use for this looks like:
> >
> > interface tun0:217.197.85.96 {
> > passive
> > depend on carp0
> > }
> >
> > With this configuration, the tun interface is permanently marked DOWN
> > and the route is not announced:
> >
> > Interface AddressState HelloTimer Linkstate Uptimenc ac
> > tun0217.197.85.96/32 DOWN - active 00:00:00 0 0
> >
> > If I omit 'passive' it works as expected:
> >
> > interface tun0:217.197.85.96 {
> > depend on carp0
> > }
> >
> > Interface AddressState HelloTimer Linkstate Uptimenc ac
> > tun0217.197.85.96/32 P2P00:00:06 active 00:02:13 0 0
> >
> > However, osfpd now sends useless OSPF packets, and my logs are being
> > spammed with the message:
> > send_packet: error sending packet on interface tun0: Permission denied
> >
> > I believe this is a bug. I expect to be able to announce the address
> > of a passive point-to-point interface with ospfd.
> >
>
> The problem is that ospfd only originates the LSA you need when the interface
> is in state IF_STA_POINTTOPOINT. But when the interface is passive it is in
> state IF_STA_DOWN.
>
> I think we should check the status of the link instead.
>
> The diff below does that and adds the "depend on" logic.
>
> OK?
yes, ok benno@
> Remi
>
>
> Index: ospfe.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
> retrieving revision 1.103
> diff -u -p -r1.103 ospfe.c
> --- ospfe.c 27 Sep 2018 12:34:06 - 1.103
> +++ ospfe.c 22 Apr 2019 09:08:53 -
> @@ -900,7 +900,8 @@ orig_rtr_lsa(struct area *area)
> if (ibuf_add(buf, _link, sizeof(rtr_link)))
> fatalx("orig_rtr_lsa: ibuf_add failed");
> }
> - if (iface->state & IF_STA_POINTTOPOINT) {
> + if ((iface->flags & IFF_UP) &&
> + LINK_STATE_IS_UP(iface->linkstate)) {
> log_debug("orig_rtr_lsa: stub net, "
> "interface %s", iface->name);
> bzero(_link, sizeof(rtr_link));
> @@ -912,7 +913,11 @@ orig_rtr_lsa(struct area *area)
> rtr_link.data = iface->mask.s_addr;
> }
> rtr_link.type = LINK_TYPE_STUB_NET;
> - rtr_link.metric = htons(iface->metric);
> + if (iface->dependon[0] != '\0' &&
> + iface->depend_ok == 0)
> + rtr_link.metric = MAX_METRIC;
> + else
> + rtr_link.metric = htons(iface->metric);
> num_links++;
> if (ibuf_add(buf, _link, sizeof(rtr_link)))
> fatalx("orig_rtr_lsa: ibuf_add failed");
>
Re: ospfd: passive p2p interfaces don't work
On Mon, Apr 22, 2019 at 11:14:30AM +0200, Remi Locherer wrote:
> On Tue, Apr 09, 2019 at 04:16:32PM +0200, Stefan Sperling wrote:
> > I believe this is a bug. I expect to be able to announce the address
> > of a passive point-to-point interface with ospfd.
> >
>
> The problem is that ospfd only originates the LSA you need when the interface
> is in state IF_STA_POINTTOPOINT. But when the interface is passive it is in
> state IF_STA_DOWN.
>
> I think we should check the status of the link instead.
>
> The diff below does that and adds the "depend on" logic.
>
> OK?
Yes, with this diff it all works as expected. Thanks a lot!
ok stsp@
> Remi
>
>
> Index: ospfe.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
> retrieving revision 1.103
> diff -u -p -r1.103 ospfe.c
> --- ospfe.c 27 Sep 2018 12:34:06 - 1.103
> +++ ospfe.c 22 Apr 2019 09:08:53 -
> @@ -900,7 +900,8 @@ orig_rtr_lsa(struct area *area)
> if (ibuf_add(buf, _link, sizeof(rtr_link)))
> fatalx("orig_rtr_lsa: ibuf_add failed");
> }
> - if (iface->state & IF_STA_POINTTOPOINT) {
> + if ((iface->flags & IFF_UP) &&
> + LINK_STATE_IS_UP(iface->linkstate)) {
> log_debug("orig_rtr_lsa: stub net, "
> "interface %s", iface->name);
> bzero(_link, sizeof(rtr_link));
> @@ -912,7 +913,11 @@ orig_rtr_lsa(struct area *area)
> rtr_link.data = iface->mask.s_addr;
> }
> rtr_link.type = LINK_TYPE_STUB_NET;
> - rtr_link.metric = htons(iface->metric);
> + if (iface->dependon[0] != '\0' &&
> + iface->depend_ok == 0)
> + rtr_link.metric = MAX_METRIC;
> + else
> + rtr_link.metric = htons(iface->metric);
> num_links++;
> if (ibuf_add(buf, _link, sizeof(rtr_link)))
> fatalx("orig_rtr_lsa: ibuf_add failed");
Re: ospfd: passive p2p interfaces don't work
Hi Stefan
On Tue, Apr 09, 2019 at 04:16:32PM +0200, Stefan Sperling wrote:
> I want to announce a host-route to the address of a tun0 interface
> over OSPF. The config snippet I use for this looks like:
>
> interface tun0:217.197.85.96 {
> passive
> depend on carp0
> }
>
> With this configuration, the tun interface is permanently marked DOWN
> and the route is not announced:
>
> Interface AddressState HelloTimer Linkstate Uptimenc ac
> tun0217.197.85.96/32 DOWN - active 00:00:00 0 0
>
> If I omit 'passive' it works as expected:
>
> interface tun0:217.197.85.96 {
> depend on carp0
> }
>
> Interface AddressState HelloTimer Linkstate Uptimenc ac
> tun0217.197.85.96/32 P2P00:00:06 active 00:02:13 0 0
>
> However, osfpd now sends useless OSPF packets, and my logs are being
> spammed with the message:
> send_packet: error sending packet on interface tun0: Permission denied
>
> I believe this is a bug. I expect to be able to announce the address
> of a passive point-to-point interface with ospfd.
>
The problem is that ospfd only originates the LSA you need when the interface
is in state IF_STA_POINTTOPOINT. But when the interface is passive it is in
state IF_STA_DOWN.
I think we should check the status of the link instead.
The diff below does that and adds the "depend on" logic.
OK?
Remi
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.103
diff -u -p -r1.103 ospfe.c
--- ospfe.c 27 Sep 2018 12:34:06 - 1.103
+++ ospfe.c 22 Apr 2019 09:08:53 -
@@ -900,7 +900,8 @@ orig_rtr_lsa(struct area *area)
if (ibuf_add(buf, _link, sizeof(rtr_link)))
fatalx("orig_rtr_lsa: ibuf_add failed");
}
- if (iface->state & IF_STA_POINTTOPOINT) {
+ if ((iface->flags & IFF_UP) &&
+ LINK_STATE_IS_UP(iface->linkstate)) {
log_debug("orig_rtr_lsa: stub net, "
"interface %s", iface->name);
bzero(_link, sizeof(rtr_link));
@@ -912,7 +913,11 @@ orig_rtr_lsa(struct area *area)
rtr_link.data = iface->mask.s_addr;
}
rtr_link.type = LINK_TYPE_STUB_NET;
- rtr_link.metric = htons(iface->metric);
+ if (iface->dependon[0] != '\0' &&
+ iface->depend_ok == 0)
+ rtr_link.metric = MAX_METRIC;
+ else
+ rtr_link.metric = htons(iface->metric);
num_links++;
if (ibuf_add(buf, _link, sizeof(rtr_link)))
fatalx("orig_rtr_lsa: ibuf_add failed");
