Em 20-05-2011 10:04, Devin Heitmueller escreveu: > On Friday, May 20, 2011, Dmitri Belimov <d.belimov@xxxxxxxxx> wrote: >> Hi Devin >> >> snip >> >>> NACK! >>> >>> I don't think this patch is correct. Concurrency problems are >>> expected to be handled in the upper layers, as there are usually much >>> more significant problems than just this case. For example, if this >>> is a race between V4L2 and DVB, it is the responsibility of bridge >>> driver to provide proper locking. >>> ... >> >> I see two different way add mutex to function where firmware is loaded or to >> xc5000_set_analog_params >> >> Both of this is working I already test it. >> >> What you think about it?? ... >> [ 110.010686] [<f81cb6d8>] ? set_mode_freq+0xe4/0xff [tuner] >> [ 110.010689] [<f81cb8d4>] ? tuner_s_std+0x26/0x5aa [tuner] >> [ 110.010692] [<f81cb8ae>] ? tuner_s_std+0x0/0x5aa [tuner] Hmm... this is probably caused by the BKL removal patches. Basically, tuner_s_std is being called without holding dev->lock. The fix is simple, but requires some care: we need either to convert saa7134 to the v4l2 core support (probably not an easy task) or to review all places where dev->lock should be used, e. g. at (almost all) ioctls, and at the other file ops (open, close, mmap, etc). This driver is complex, due to the mpeg optional module used on some devices. So, maybe the in-core locking schema is not the proper way to fix it. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
