Emard writes: > I have conducted another series of tests on dvb-kernel > 4 parallel processes: > > 0: szap -r zdf > 1: dvb0_0 promisc on/off and hw ether redefine endless loop > 2: dvb0_0 add/remove endless loop > 3: alevt-date -vbi /dev/dvb/adapter0/dvr0 endless loop > > There were plenty of race conditions possible.
Not really, since szap only calls filter setting routines at the very beginning, alevt-date not at all. I'll see if I can hack something else together tomorrow. Note that this also can only happen if another process is just allocating/setting/changing a filter and in just that moment when it has downed the semaphore in dvb_demux.c the softirq which handles the networking is triggered and calls the set_multicast_list() function in dvb_net. Then, the call which sets the section filter for the multicast list will use a down_interruptible() in dvb_demux.c which will fail and thus call schedule() which causes an oops in schedule() because set_multicast_list() is called during interrupt. Also cf. /usr/src/linux/Documentation/networking/netdevices.txt which states that sleeping is not allowed here. > dvb-kernel survived that test. Please post crashme > code sample which can attempt to cause the oops for > the budget modules. This is of course a bug in the upper DVB layers and not the budget modules. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
