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: <496565EC904933469F292DDA3F1663E602F49E29A6@dlee06.ent.ti.com>
Date:	Tue, 26 Oct 2010 15:01:02 -0500
From:	"Guzman Lugo, Fernando" <fernando.lugo@...com>
To:	Felipe Contreras <felipe.contreras@...ia.com>,
	"felipe.contreras@...il.com" <felipe.contreras@...il.com>
CC:	"gregkh@...e.de" <gregkh@...e.de>,
	"hiroshi.doyu@...ia.com" <hiroshi.doyu@...ia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event
 interruptible

 

> -----Original Message-----
> From: Felipe Contreras [mailto:felipe.contreras@...ia.com] 
> Sent: Tuesday, October 26, 2010 2:27 PM
> To: Guzman Lugo, Fernando; 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:
> > > 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?
> > 
> > Maybe sending a signal to yourselft and having a dummy 
> signal Handle 
> > should work, it that would not like good.
> 
> Signals on libraries is a no-no.
> 
> > I am thinking On having a ioctl to create and set an event the you 
> > could Something like this:
> > 
> > struct dsp_notification events[3];
> > 
> > proc_register_notify(proc, event_type, &events[0]); ...
> > proc_register_notify(proc, event_type, &events[1]); ...
> > Sync_open_event(&events[2]);
> > 
> > 
> > second thread:
> > 
> > 	mgr_wait_for_bridge_events(proc, events, 3, index);
> > 
> > 	if (index == 2) 
> > 		/* main thread force exit */
> > 
> > 
> > Main thread:
> > 
> > 	/* if some execption happened then finish the second thread */
> > 	sync_set_event(events[2]);
> > 
> > 	pthread_join(...);
> > 
> > 
> > However it is in progess a task for change replacing 
> dspbridge sync.c 
> > Module with event_fd to signal events to userspace. Where 
> now simple 
> > File descriptor will be used as event elements. So the 
> > mgr_wait_for_bridge_events Will be implemented using 
> "select" system call inside to wait for multiple events.
> > So you will be able to do something like this:
> > 
> > int events[3];
> > 
> > proc_register_notify(proc, event_type, &events[0]); ...
> > proc_register_notify(proc, event_type, &events[1]); ...
> > events[2] = eventfd(0, 0);
> > 
> > 
> > second thread:
> > 
> > 	mgr_wait_for_bridge_events(proc, events, 3, index);
> > 
> > 	if (index == 2) 
> > 		/* main thread force exit */
> > 
> > Main thread:
> > 
> > 	/* if some execption happened then finish the second thread */
> > 	write(events[2], "s", 1);
> > 
> > 	pthread_join(...);
> > 
> > You won't need any aditional ioctl in order to do what you 
> want to do.
> > 
> > So, I think it is not worth to make much changes to some 
> module that 
> > will Dissapear (my patch is just a fix it is not implementing 
> > something new), It is just a matter of time to that task is 
> finished 
> > and tested properly And then send to LO.
> 
> All right, that makes sense. I just wanted to make suere you 
> are aware of that need.

Sure, that need will cover soon.

Thanks and regards,
Fernando.

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