Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ata_channel_destroy(): free the channel #237

Merged
merged 1 commit into from
Jan 17, 2025

Conversation

mcimerman
Copy link
Contributor

@mcimerman mcimerman commented Nov 10, 2024

While browsing the ATA code again, I noticed that the initial call to calloc() doesn't have a free() pair.

@mcimerman
Copy link
Contributor Author

Looking back at this PR, I think we should free() the channel only when rc == EOK.

What do you think?

@mcimerman
Copy link
Contributor Author

I think this seems more reasonable. After my previous PR #236, ata_bd_fini_irq(chan) is called even though there was an error, and the current PR is wrong again (due to the break), as it frees the channel even when an error occurs.

Here it is fixed, let me know if it looks ok and I will force push to my branch so you can pull it:

/** Destroy ATA channel. */
errno_t ata_channel_destroy(ata_channel_t *chan)
{
	int i;
	errno_t rc;

	ata_msg_debug(chan, ": ata_channel_destroy()");

	fibril_mutex_lock(&chan->lock);

	for (i = 0; i < MAX_DEVICES; i++) {
		rc = ata_device_remove(&chan->device[i]);
		if (rc != EOK) {
			ata_msg_error(chan, "Unable to remove device %d.", i);
			fibril_mutex_unlock(&chan->lock);
			return rc;
		}
	}

	ata_bd_fini_irq(chan);
	fibril_mutex_unlock(&chan->lock);
	free(chan);

	return rc;
}

@zmmaj
Copy link

zmmaj commented Jan 10, 2025

When will be this usable, since HelenOS did not see physical hard disc... Ide do not work Sata, same..

@le-jzr
Copy link
Contributor

le-jzr commented Jan 16, 2025

I think this seems more reasonable. After my previous PR #236, ata_bd_fini_irq(chan) is called even though there was an error, and the current PR is wrong again (due to the break), as it frees the channel even when an error occurs.

I looked at what's happening when error is returned from the function, and it seems to me that the whole error path is just underspecified and inconsistently handled. Right now, not freeing on error seems like the safe choice (there might be leaks in some circumstances, but no crashes). Though eventually, someone should probably look through the entire driver stack and better specify what should happen in error cases, because the current handling doesn't feel right to me.

@mcimerman mcimerman force-pushed the ata-chan-destroy-free branch from a450088 to 167c5c1 Compare January 16, 2025 13:13
@mcimerman mcimerman force-pushed the ata-chan-destroy-free branch from 167c5c1 to 9e7e1dc Compare January 16, 2025 13:15
@le-jzr le-jzr merged commit b8fd951 into HelenOS:master Jan 17, 2025
@le-jzr
Copy link
Contributor

le-jzr commented Jan 17, 2025

LGTM. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants