ifconfig up/down an interface repeatedly causes a kdl

[kallisti5]

gcc4 image, hrev44859

running: ifconfig <device> down ifconfig <device> up ifconfig <device> down . .

will result in a KDL. Reproduced several times.

Same thing happens on wired vs wireless interfaces

[jackburton]

I found out that the KDL doesn't happen if I remove the ipv6 module. After having a look at the code, I suspect that the culprit is the function ipv6_setsockopt() in src/add-ons/kernel/network/protocols/ipv6.cpp

at line 1240 it calls sDatalinkModule->get_interface_with_address() but, unlike the ipv4 equivalent code, it does not call sDatalinkModule->put_interface(interface).

ipv6:

	struct net_interface* interface
		= sDatalinkModule->get_interface_with_address(
			(sockaddr*)address);
	if (interface == NULL) {
		delete address;
		return EADDRNOTAVAIL;
	}

	delete protocol->multicast_address;
	protocol->multicast_address = (struct sockaddr*)address;
	return B_OK;

cf. ipv4:

	struct net_interface* interface
		= sDatalinkModule->get_interface_with_address(
			(sockaddr*)address);
	if (interface == NULL) {
		delete address;
		return EADDRNOTAVAIL;
	}

	delete protocol->multicast_address;
	protocol->multicast_address = (struct sockaddr*)address;
	sDatalinkModule->put_interface(interface);
	return B_OK;

I don't have a development system at hand, but maybe somebody can comment on this, or even commit the fix.

[axeld]

This is definitely a bug that should be fixed. Not sure if it's the culprit for this ticket, but it may be. I may have time to look into this in about a week.

[umccullough]

Sorry for ticket spam, I meant to set that High :(

[jackburton]

Replying to axeld:

This is definitely a bug that should be fixed. Not sure if it's the culprit for this ticket, but it may be. I may have time to look into this in about a week.

In fact, I just tried and it doesn't fix the issue in question. Oh well, at least I found another problem.

[axeld]

You could have committed it directly, though :-) I've done so now in hrev45154, thanks!

[jackburton]

Replying to axeld:

You could have committed it directly, though :-) I've done so now in hrev45154, thanks!

Yeah, but when finally I got access to the development machine, and saw that it didn't fix the bug in question, I lost a bit of enthusiasm. :)

[axeld]

I reproduced this issue as well using the debug heap, but unfortunately, this didn't help. I did not get a nice stack trace out of this, either.

I've digged in a little, and it looks to me like the hash table has been corrupted somehow: the crash does not always happens at the same spot, but jumps around at different hash table methods. This might either mean that the multicast implementation uses the hash incorrectly, or that the hash implementation itself is at fault.

[jackburton]

Replying to axeld:

I reproduced this issue as well using the debug heap, but unfortunately, this didn't help. I did not get a nice stack trace out of this, either.

I've digged in a little, and it looks to me like the hash table has been corrupted somehow: the crash does not always happens at the same spot, but jumps around at different hash table methods. This might either mean that the multicast implementation uses the hash incorrectly, or that the hash implementation itself is at fault.

Now that you said that... CID 610870 and CID 610871 are about the multicast implementation and the use of the hash table. I'm not very familiar with that code, so I haven't checked if they reference actual problems, but they might be worth checking.

[jackburton]

Should be fixed in hrev45220, could someone confirm ?

[jackburton]

I'm closing this, tested on three different systems and can't reproduce it anymore. hrev45220 indeed fixed this.