linux-kernel - RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1288112260-notmuch-felipe.contreras@nokia.com>
Date:	Tue, 26 Oct 2010 20:03:22 +0300
From:	Felipe Contreras <felipe.contreras@...ia.com>
To:	fernando.lugo@...com, felipe.contreras@...il.com
Cc:	gregkh@...e.de, hiroshi.doyu@...ia.com,
	linux-kernel@...r.kernel.org, andy.shevchenko@...il.com,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

fernando.lugo@...com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > <x0095840@...com> wrote:
> > > So that avoid non-killable process.
> > 
> > It would be useful to interrupt these tasks from user-space. 
> > A separate ioctl to do that would be needed.
> 
> I don't see use case where that could be needed. It is only
> To avoid a nonkillable task in the case the user pass an infinite
> Timeout.
> 
> If you have some test case where that ioctl would be needed
> Please share it in order to find the best solution.

Well, imagine the application is using a library to access the DSP, and
the library has a dedicated thread listening for DSP events in a loop.
This happens to be how libomxil-ti and gst-dsp work.

Now, the thread received the last message, but has set a timeout of 10s,
or even worst, no timeout at all.

After realizing that was the last message, the main thread decides to
shut down, but it has to wait for the DSP thread to join. Unfortunately
the DSP thread is stuck waiting for events, and there's nothing that can
be done.

However, if we have a separate ioctl to interrupt that task, then the
main thread can issue that ioctl, and unlock the DSP thread without
having to wait 10s, or forever.

Does that make sense?

-- 
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/