lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 28 Dec 2010 14:24:03 +0200 From: Felipe Contreras <felipe.contreras@...il.com> To: Ohad Ben-Cohen <ohad@...ery.com> Cc: Felipe Contreras <felipe.contreras@...ia.com>, linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org, greg@...ah.com, omar.ramirez@...com, fernando.lugo@...com, nm@...com, ameya.palande@...ia.com, h-kanigeri2@...com Subject: Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly On Tue, Dec 28, 2010 at 2:18 PM, Ohad Ben-Cohen <ohad@...ery.com> wrote: > On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras > <felipe.contreras@...il.com> wrote: >> I haven't investigated why that happens, but kernel-space should not >> panic regardless of what user-space does. > > Agree of course. But that's not what we were discussing... Well, hopefully after applying your patch it would be easier to figure that out. >>> Anyhow, a thread that is calling proc_*_dma() will both increase the >>> reference count and decrease it back before going back to user space. >>> Otherwise your patch would be problematic as well - who will unlock >>> the mutex you take in proc_*_dma() ? >> >> I'm saying that user-space might crash *before* proc_*_dma() finishes, >> before the reference count has been decreased. >> >> In my patch there would be no issue because proc_un_map() would wait >> until proc_*_dma() has released the lock. > > But what will happen if, as you say, user-space would crash before > proc_*_dma() has released the lock ? how could proc_un_map() run ? user-space crashed, not kernel-space; the code would continue to run and eventually release the lock. > This is all good, and I have no problem with it. As I said, I don't > resist your patch as a temporary fix. But it doesn't mean I like it... Yeah, so the chances of getting this fixed on 2.6.37 are dimmed. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists