Messages in this thread | | | Date | Wed, 29 Dec 2010 11:42:20 +0200 | Subject | Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly | From | Felipe Contreras <> |
| |
On Tue, Dec 28, 2010 at 4:48 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: > On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras > <felipe.contreras@gmail.com> wrote: >> On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >>> I still don't know how exactly you triggered the bug: is gst-dsp >>> multithreaded ? and one of its threads invoked proc_un_map() while >>> another thread called proc_begin_dma() ? >> >> I haven't investigated why that happens > > Btw, I still think you should look into this. > > The kernel panic will be solved, but you may still have a race there > that can lead to data corruption: if proc_un_map will be fast enough, > it will acquire the proc_lock mutex before proc_begin_dma(), and then > you will miss a cache operation.
Aquiring the lock is the first thing done; if proc_un_map() aquires the lock first, it's because it was run first, and thus a problem for user-space. If user-space wants the cache operation, it must run proc_begin_dma() first, there's nothing kernel-space can do to fix that.
-- Felipe Contreras
| |