Messages in this thread | | | From | Ohad Ben-Cohen <> | Date | Wed, 29 Dec 2010 11:46:25 +0200 | Subject | Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly |
| |
On Wed, Dec 29, 2010 at 11:39 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote: > On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >> On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras >> <felipe.contreras@gmail.com> wrote: >>> user-space crashed, not kernel-space; the code would continue to run >>> and eventually release the lock. >> >> So you'll have to be more specific about the scenario you are describing. >> >> If there's a user thread that is still running the proc_*_dma() >> function, and we agree that this thread keeps running until completion >> and then returns to user space, what's the problem ? > > The problem is if the user-space process crashes exactly in the middle > of it, *before* completing. With locks there's no problem, as > proc_un_map() would wait for the lock in my patch. In your patch it > would not wait, just return -EBUSY.
We have two threads.
One called proc_un_map(), and one called proc_begin_dma().
The first crashed, but the second didn't. it still holds the bridge device open. When it will exit, and release the device, then drv_remove_all_resources() will be called, and all the map_obj's will be cleaned.
> >> If that user thread will crash, drv_remove_all_resources() will clean >> up all map_obj's. > > Not if a proc_*_dma() is still running.
It will be called after it will return, and its thread will exit (or crash).
| |