On Tue, Dec 28, 2010 at 4:48 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
