Hi Johannes Stezenbach schrieb: > On Sat, Jun 04, 2005 at 09:48:13PM +0200, Peter Beutner wrote: > >>i recently stumbled over these two little bugs in the dvb_core code: >>1. >>As the FE_SET_FRONTEND ioctl is asynchronous it is not guaranteed that >>the tuner is already reconfigured when the next ioctl occurs. In case of >>the FE_READ_STATUS ioctl this would return the signal status of the >>previous,now obsolete tuning to the user. Which is kind of bad for apps >>which do something like: >>tune(); >>while(!has_lock()) >> sleep(500); >>read_data(); >>Prevent this by automatically returning zero if frontend state is FE_RETUNE. > > > Hm, nice catch. Did you actually manage to hit this race? yes, I ccasionally saw it when using tzap. The first line reports a HAS_LOCK, while the second(and sometimes third) shows no signal lock and next one finally has the lock again. > > >>2. >>In dvb_dmxdev_filter_start if we go out because of an error, release >>previously allocated demux_feed. > > > This is a bit subtle. The feed is released in dvb_demux_release() (when > the device is closed). What was the problem you were trying to fix with > this patch? The problem is if you change the pid filter without closing the demux device. For example when changing the channel. Consider the following sequence: tune(); ioctl(DMX_SET_PES_FILTER); ioctl(DMX_START); ... ioctl(DMX_STOP); tune(); ioctl(DMX_SET_PES_FILTER); ioctl(DMX_START); ... (xine does it this way for example) As the status of the filter isn't set to DMXDEV_STATE_GO if an error occurs in dvb_dmx_filter_start, it wont be released in dvb_dmx_filter_stop. Because the number of filters is limited, it will run out of filters after zapping through a few channels Btw just ~5 lines above the one i changed with the patch, there is exactly the same situation. And there it is done the way as the patch does it. Peter > Thanks, > Johannes > > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > >
