I'm looking at segfaults with fipvlan, and there seem to be some serious
issues with patches applied Dec 2 2013.
Is anyone testing fipvlan at all? I'm worried that these got in, but
more so that they've been undetected for so long.
If you use the vlan create option, it will segfault in
create_and_start_vlan() at line 647
> } else {
> vlan = lookup_vlan(fcf->ifindex, fcf->vlan);
> if (vlan) {
> FIP_LOG_DBG("VLAN %s.%d already exists as %s\n",
> real_dev->ifname, fcf->vlan, vlan->ifname);
> return 0;
if vlan already exists, this exits
(so we can't start fcoe on an existing vlan dev either?)
> }
> snprintf(vlan_name, IFNAMSIZ, "%s.%d%s",
> real_dev->ifname, fcf->vlan, config.suffix);
> rc = vlan_create(fcf->ifindex, fcf->vlan, vlan_name);
> if (rc < 0) {
> printf("Failed to create VLAN device %s\n\t%s\n",
> vlan_name, strerror(-rc));
> return rc;
> }
> printf("Created VLAN device %s\n", vlan_name);
created, but vlan variable still NULL
> }
> if (!config.start)
> return rc;
>
> if (!vlan->running) {
segfault on NULL dereference
I was working up a patch to fix that, and then ended up with a segfault
in lookup_fcf() from rtnl_recv_newlink() line 421
lookup_fcf:
>static struct fcf *lookup_fcf(struct fcf_list_head *head, int ifindex,
> uint16_t vlan, unsigned char *mac)
>{
> struct fcf *fcf;
>
> TAILQ_FOREACH(fcf, head, list_node)
> if ((ifindex == fcf->ifindex) && (vlan == fcf->vlan) &&
> (memcmp(mac, fcf->mac_addr, ETHER_ADDR_LEN) == 0))
> return fcf;
> return NULL;
>}
rtnl_recv_newlink:
> if (!iff->fcoe_started &&
> lookup_fcf(head, ifindex, iff->vid, NULL)) {
the memcmp in lookup_fcf will segfault on that NULL mac argument
_______________________________________________
fcoe-devel mailing list
[email protected]
http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
