How to handle Hotplug with UIO userspace driver

[greg@kroah.com (Greg KH)]

On Wed, Nov 26, 2014 at 12:33:41PM -0800, Mandeep Sandhu wrote:
>     > While the kernel driver has no problem with hot-removal, I see that if I
>     > "unregister" our UIO driver in response to the removal, then the mapping
>     for
>     > the hardware's physical memory would become "invalid" (done by UIO on
>     > unregsiter). This could possibly cause the user-space process to crash
>     due to
>     > illegal memory access.
> 
>     You should just get 0xff on the memory reads, right?? You can catch the
>     signal for invalid memory accesses.
> 
> 
> Wouldn't I get an illegal memory access, as UIO would've removed the mappings
> that it setup when I registered the UIO driver? I saw the userspace process
> segfault after removal.

I don't know, never tried it.  What about catching the signal for this?

>     > Is there a "standard" way to handle this scenario, i.e for hotpluggable
>     > hardware using UIO?
> 
>     Your kernel driver knows when the device is removed, so have it tell
>     userspace this.? Or, just tie into libudev and have your userspace
>     program be notified when the device goes away.
> 
> 
> Right. This is what I'm trying to do using a udev "remove" rule.

No, just have libudev tell you about the problem, don't create a whole
new rule for this, that's overkill and messy and not dynamic at all.

> Although the
> question still remains, what will happen if the device is being actively
> accessed _before_ the signal reaches the process. Is it safe to do
> "uio_unregister_device" while a userspace process is accessing the device?

I don't know, try it and see :)

> I saw a patch for this very situation (UIO & hotplug) being discussed on LKML
> almost 4 yrs back, although I don't see it in my kernel version - 3.16.0
> (Ubuntu?3.16.0-24-generic).
> The LKML link:
> 
> https://lkml.org/lkml/2010/9/20/21
> 
> Wouldn't this solve the issue? I wonder why it didn't make it into mainline?

No idea, that UIO maintainer must be really lazy and never apply patches :)

Try that series on your kernel and see what happens.  If it works,
please resend that patch series.

thanks,

greg k-h