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

[Coverity CID :186842] Memory - illegal accesses in /drivers/interrupt_controller/plic.c #8699

Closed
mandarcthorat1 opened this issue Jul 3, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@mandarcthorat1
Copy link
Contributor

commented Jul 3, 2018

Static code scan issues seen in File: /drivers/interrupt_controller/plic.c
Category: Memory - illegal accesses
Function: plic_irq_handler
Component: Drivers
CID: 186842
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

@agross-oss

This comment has been minimized.

Copy link
Collaborator

commented Jul 5, 2018

It seems to me like there are some missing #idfefs around the irq += RISCV_MAX_GENERIC_IRQ; keying off of CONFIG_RISCV_HAS_PLIC. However there might be issues with the PLIC_IRQS count. With coverity thinking this only has 32 IRQS, it appears the failing platform is the one without the HAS_PLIC configured.

It'd be good to have the original committer comment or look into this.

@nashif

This comment has been minimized.

Copy link
Member

commented Jul 31, 2018

@kgugala can you please have a look?

@nashif

This comment has been minimized.

Copy link
Member

commented Aug 14, 2018

@kgugala ping

@nashif nashif added this to the v1.13.0 milestone Aug 26, 2018

@kgugala

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2018

@nashif sorry for stalling this, I was on holidays. I'll take a look on that.

@ceolin

This comment has been minimized.

Copy link
Member

commented Aug 31, 2018

guys, this is not a bug. The invalid memory access that coverity is complaining will never happen because _irq_spurious(NULL); will be called first and this function never returns

...
_NanoFatalErrorHandler(_NANO_ERR_SPURIOUS_INT, &_default_esf);

Question, should I add a return after this so any static analyzer will complain or we can just close this issue (here and in coverity)

@nashif

This comment has been minimized.

Copy link
Member

commented Aug 31, 2018

lets close.. mark it as invalid in coverity please.

@nashif nashif closed this Aug 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.