Open() system call causes internal error

[Pasam]

Hi, Post deploying this driver I had tried to read the device file enumerated at /dev/U3V0 from a user application and just included some validating print statement to check whether the device file could be opened as shown in the code below.the open system call is causing the system to generate the internal error and the process hangs. when i run dmesg i observe the following bug: BUG:Unable to handle Kernel NULL pointer dereference at(null) The system generates an internal errror. However I get a Device file Opened succesfully message but the user process hangs. Any suggestion on what could be prob and whats the solution is very much helpful.Thanks in advance

[katieensign]

Thanks for reaching out about this -- unfortunately I haven't seen or heard about anything similar. Can you provide a bit more information about your setup?

• What distro and kernel version are you using?
• Can you post your exact usermode code that's opening the file handle and indicate at which point the crash is happening?
• Can you post the entire dmesg output relating to the issue?

Any additional information you can provide will help narrow down what could be going wrong.

Thank you, Katie

[Pasam]

Hi Katie, Thanks for your response.I would like to point out at a possible bug ,regarding default consideration of presence of event interface on the device side by the driver.Kindly Note that as per the U3V standard presence of event interface on the device is optional.But the driver tries to lock the mutex related to event interface although not created , because no such interface exists if the device does not advertise the presence in its associated descriptors.I would urge you try the driver with the Device that doesnot contain event interface.I would like to remind you that in the u3v_core.c ,enumerate_u3v_interfaces checks for the presence of interfaces through scanning the associated descriptors, and initializes the corresponding mutexes.If Device does'nt have event interface no such mutex would be initialized.But in other functions such as u3v_delete,its assuming that mutex related to event interface is always initialized and is locking it to destroy the associated data. This caused the above reported Kernel Oops message by me back in August this year.Kindly rectify the problem after verifying the validity of my point.Including a flag based locking of mutexes solved my isssue that set a flag when event inteface present and initialize it,destroy it or lock only if the flag is set.This takes into account the possible absence of event interface on the device and ensures no bug even in this case

[katieensign]

Yes, that makes sense and definitely seems like an issue. I will make a fix — thanks for following up with those details.

[katieensign]

Thanks so much for your detailed description of the issue here. I've incorporated a fix in the newest release (1.3.0) and added more details in the release notes. Please let me know if you run into any other issues.