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

Fix os crash caused by optoe when class switch #413

Merged
merged 2 commits into from
Jul 16, 2024

Conversation

philo-micas
Copy link
Contributor

@philo-micas philo-micas commented Jul 2, 2024

Why:
When the device is initially set to optoe2, there is an option ->client [1]. If echo 3>dev_class is manually set at this time, as for optoe3, option ->client [1] is meaningless but the content is still the address data of optoe2, accessing an illegal address will occur, causing the device to crash.

How:
Set option->client[1] to NULL when unregistering device

Closes:#412

@philo-micas philo-micas requested a review from a team as a code owner July 2, 2024 06:08
@paulmenzel
Copy link
Contributor

Issue link:#412

Please use:

Closes: #412

@paulmenzel
Copy link
Contributor

Could you please add the description to the commit message (git commit --amend && git push -f).

philo-micas added a commit to philo-micas/sonic-linux-kernel that referenced this pull request Jul 3, 2024
When the device is initially set to optoe2, there is an option->client[1].
If echo 3>dev_class is manually set at this time, as for optoe3, option->client[1] is meaningless
but the content is still the address data of optoe2, accessing an illegal address will occur, causing the device to crash.

Set option ->client[1] to NULL when unregistering device

Signed-off-by: philo <philo@micasnetworks.com>
@philo-micas philo-micas force-pushed the master-for-optoe branch 2 times, most recently from 9031ab7 to ff0c049 Compare July 3, 2024 01:55
@philo-micas
Copy link
Contributor Author

philo-micas commented Jul 3, 2024

Could you please add the description to the commit message (git commit --amend && git push -f).

@paulmenzel @lguohan @prgeor Ok,thanks, has updated. Help arrange review for this PR, thanks!

@philo-micas
Copy link
Contributor Author

As mentioned in issue:sonic-net/sonic-buildimage#19525

When the device is initially set to optoe2, there is an option->client[1].
If echo 3>dev_class is manually set at this time, as for optoe3, option->client[1] is meaningless
but the content is still the address data of optoe2, accessing an illegal address will occur, causing the device to crash.

Therefore, set option->client[1] to NULL when unregistering device

Signed-off-by: philo <philo@micasnetworks.com>
@saiarcot895 saiarcot895 merged commit 98e4af9 into sonic-net:master Jul 16, 2024
6 checks passed
philo-micas added a commit to philo-micas/sonic-linux-kernel that referenced this pull request Jul 17, 2024
Why:
When the device is initially set to optoe2, there is an option ->client [1]. If echo 3>dev_class is manually set at this time, as for optoe3, option ->client [1] is meaningless but the content is still the address data of optoe2, accessing an illegal address will occur, causing the device to crash.

How:
Set option->client[1] to NULL when unregistering device

Closes: sonic-net#412

Signed-off-by: philo <philo@micasnetworks.com>
Co-authored-by: Saikrishna Arcot <sarcot@microsoft.com>
philo-micas added a commit to philo-micas/sonic-linux-kernel that referenced this pull request Jul 18, 2024
Why:
When the device is initially set to optoe2, there is an option ->client [1]. If echo 3>dev_class is manually set at this time, as for optoe3, option ->client [1] is meaningless but the content is still the address data of optoe2, accessing an illegal address will occur, causing the device to crash.

How:
Set option->client[1] to NULL when unregistering device

Closes: sonic-net#412

Signed-off-by: philo <philo@micasnetworks.com>
Co-authored-by: Saikrishna Arcot <sarcot@microsoft.com>
qiluo-msft pushed a commit to sonic-net/sonic-buildimage that referenced this pull request Sep 21, 2024
### Why I did it

### How I did it
We try to use Linux kernel drivers to replace our drivers, except for some drivers that we have implemented ourselves.
For this purpose, we have submitted the following PR to the sonic-linux-kernel repository:
sonic-net/sonic-linux-kernel#411
sonic-net/sonic-linux-kernel#413
sonic-net/sonic-linux-kernel#417
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants